fooUser appearing in Sentinel device logs

[OJA]

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?

[#2]

Please open a ticket.

Also, run the following to show exactly which tables fooUser is showing up in:

search "fooUser"
| distinct $table

[#3]

@Rod_Trent 

Hi Rod, it occurs to my organisation as well. It appears in the following table. 

Most of them are in the InitiatingProcessAccountUpn field name. 

[#4]

I spotted this today in our logs too. Had me very confused.

[#5]

Replying to keep tabs on this as I've recently seen this as well

[#6]

Just a heads-up. This part of an open, active ticket now.

[#7]

Replying to keep abreast of this as well. Just noticed this new user in our Cloud Apps portal.

[#8]

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.

[#9]

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-enroll... 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.

[#10]

Excellent blog here, too: https://call4cloud.nl/2022/09/foouser-meets-the-cosmic-autopilot-user/

[#11]

I've reinstated the original post as we have gotten word from Microsoft that this is reported as a bug.

[#12]

@OJA 

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

[#13]

Yes, 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.

[#14]

@Brok3NSpear Very good and valid points made here.

[#15 · Accepted solution]

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.'

[#16]

Do 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.

[#17]

@Brok3NSpear 

I no longer see fooUser in my tenant. You may need to open a ticket with MSFT.

[#18]

We 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.