Forum Discussion
OJA
Apr 19, 2023Copper Contributor
fooUser appearing in Sentinel device logs
Hi,
I noticed from an alert in MS Security Center there is an account called fooUser@<domain> that seems to do a lot of client operations outside of what I understand the account is for, which is Intune enrollment in Autopilot. https://call4cloud.nl/2022/09/foouser-meets-the-cosmic-autopilot-user/
But I'm seeing process creations, file creations etc.. This started the 11th of April on a single device and has since escalated to over a hundred. The first device was actually in an Autopilot process when the events started to get logged, but now there are a lot of machines that have been active for a long time where the logs are coming in from as well.
The following query is what I used to find the events in Advanced hunting:
search in (DeviceEvents,DeviceFileCertificateInfo,DeviceFileEvents,DeviceImageLoadEvents,DeviceInfo,DeviceLogonEvents,DeviceNetworkEvents,DeviceNetworkInfo,DeviceProcessEvents,DeviceRegistryEvents) "fooUser" | sort by TimeGenerated asc
Do anyone else see this behavior?
The backend Team at inTune is working on a fix for the issue currently. Here was the official answer of what occurred:
'This user does not represent a security threat. As part of the DLP (Data Loss Prevention) service, an attempt is made to identify users associated with machines. Recently, changes were implemented to the fallback method for WAM user fetching. In hybrid join scenarios, there are instances in which a domain user cannot successfully be resolved to an AAD (Azure Active Directory) user identity and in these instances, the auto-join identity (foouser) is returned. Microsoft is evaluating both short- and long-term solution to filter out DLP requests and alerts associated with foouser.'
- Brok3NSpearBrass ContributorDo we know if this fix has been released yet as we are still seeing alerts in MCAS (MS Defender for Cloud Apps) for foouser seeing uploading/downloading, but no idea as to exactly who the users really is.
- Peter FieldCopper ContributorWe are still seeing it, and still have a ticket open for it. It depends on the table, but you may find the actual user in another field for the same event, i.e., username may be right while the UPN is wrong.
Microsoft's response of "does not represent a security threat" may be true, but is doesn't stop this being a security risk for alerts we can't attribute, or alerts that aren't firing at all because of the broken relationship between tables. - TechNashvilleBrass Contributor
- TechNashvilleBrass Contributor
The backend Team at inTune is working on a fix for the issue currently. Here was the official answer of what occurred:
'This user does not represent a security threat. As part of the DLP (Data Loss Prevention) service, an attempt is made to identify users associated with machines. Recently, changes were implemented to the fallback method for WAM user fetching. In hybrid join scenarios, there are instances in which a domain user cannot successfully be resolved to an AAD (Azure Active Directory) user identity and in these instances, the auto-join identity (foouser) is returned. Microsoft is evaluating both short- and long-term solution to filter out DLP requests and alerts associated with foouser.'
- Brok3NSpearBrass Contributor
Have a support ticket open with MS for this also.
Some things that I was concerned with was the huge amount of data seen in use by the foouser account across over 500+ apps seen in Defender for Cloud Apps (MCAS)
Example, why is foouser account seen to be using (upload and download) for Gmail if it's just used for Intune enrollment? How can we determine which actual user is involved in certain activity when MCAS just shows the foouser account?
If we ever did have a major incident and the foouser UPN account was being shown in the logs instead of the actual users UPN (as we are currently seeing at times) wouldn't this be a big issue in regards to collecting forensic investigation logs in regards to the actual user, as all we can see is the foouser instead. This would also be a great way for a bad actor to hide their tracks, by hiding in plain sight. It's that part that concerns me, especially when thinking about potential data exfiltration.
I can also see that it is seen on 128 devices (never more) but less at the W/E (potentially where users machines are off) - what is significant about the number 128 as we have way more Intune enrolled machines that that, so would have expected this to be seen on all devices?
It shows in 11 tables for us when checking Rod_Trent query:
search "fooUser"
| distinct $table
Glad this is getting some traction though from MS- TechNashvilleBrass Contributor
Brok3NSpear Very good and valid points made here.
- OJACopper ContributorYes, spot on. It looks a lot like impersonation which makes it quite alarming. It's also frustrating when support reps don't seem to immediately grasp the concern. One would think they would know the Windows ecosystem well enough to understand that this type of sudden appearance of an obscure account name should trigger immediate escalation.
Even though the name is used in certain Intune processes, that's definitely not what it is mostly known for.
Good catch with the 128 devices, I see the exact same thing.
I noticed that when I opened a file on a computer, fooUser would show up in events for creating the link to the file in the "Recent files" section in Explorer and similar actions that the system performs behind the scenes during such user activites.
- OJACopper ContributorI've reinstated the original post as we have gotten word from Microsoft that this is reported as a bug.
- TechNashvilleBrass Contributor
Hello. Just a bit of an update to those other worry warts out there. This is definitely NOT a security issue. I did some preliminary troubleshooting with the Defender Team and I do not fully understand the whole issue as of yet, but the fooUser is a part of the Intune MDM enrollment process. If you take a look at this doc, you will see the fooUser mentioned. https://techcommunity.microsoft.com/t5/intune-customer-success/support-tip-understanding-auto-enrollment-in-a-co-managed/ba-p/834780 We also found fooUser in my registry. I am planning to jump back into it with the Defender Team tomorrow to see if we can get that username to not show up in the data somehow.
- Rod_Trent
Microsoft
Excellent blog here, too: https://call4cloud.nl/2022/09/foouser-meets-the-cosmic-autopilot-user/
- TechNashvilleBrass Contributor
Same as everyone else here. Seeing fooUser in some tables and in Defender for Cloud apps. Most will understand why this would be alarming to anyone who administers a domain. I've opened a ticket with Azure support and will report back what I learn.
- Chuck_VidalCopper ContributorReplying to keep tabs on this as I've recently seen this as well
- Rod_Trent
Microsoft
Just a heads-up. This part of an open, active ticket now.- Aaron MyersBrass Contributor
Replying to keep abreast of this as well. Just noticed this new user in our Cloud Apps portal.
- Rod_Trent
Microsoft
Please open a ticket.
Also, run the following to show exactly which tables fooUser is showing up in:
search "fooUser"
| distinct $table- jasonchristCopper Contributor
Hi Rod, it occurs to my organisation as well. It appears in the following table.
Most of them are in the InitiatingProcessAccountUpn field name.
- Peter160Copper Contributor
I spotted this today in our logs too. Had me very confused.