Detecting Fake Events in Azure Sign-in Logs

Threat actors can create and populate fake logs in the Azure sign-in logs that look like legitimate events

The parameters they can spoof in the logs include (and are not limited to):
  • Timestamp of when the events are generated
  • User account
  • IP addresses
  • Network location type
During forensic investigations, analysts may not be aware that some of the logs are not “legitimate” and start recording indicators of compromise that are not necessarily “real”. Further, this raises the question of “trust” regarding log sources – highlighting that during forensic investigations, it’s always best practice to utilise multiple sources rather than solely relying on one source.

This technique has previously been written about by @DrAzureAD in his blog post here and was also covered by Secureworks Counter Threat Unit here.

As per @DrAzureAD’s blog, this attack can be conducted TWO ways; the second method being harder to detect than the first:

  • Method 1: An attacker gains local admin / domain admin privileges on an AD FS server and proceeds to generates FAKE logs in Azure.
  • Method 2: An attacker who has compromised a global administrator account can create a FAKE Azure AD Health Agent on their attacker machine and generate fake logs. This option is possible for tenants not using AD FS at all.

This blog post aims to cover the following (with more of an emphasis on detection): 

  • Attack Overview (for both methods)
  • Detection Methodology (for both methods)


I will conduct this attack on two tenants I own to show you that it’s possible in these two scenarios:

  • A hybrid tenant –
  • A fully cloud based tenant (no on-premises) –

For more background and details on how these attacks are possible please refer to @DrAzureAD and @Secureworks write-up as they cover this in extensive detail.

METHOD 1: Hijacking ADFS to register fake events
This attack is conducted on my hybrid tenant “”.
Since March 2021, the Azure AD Connect Health agent on AD FS servers (responsible for monitoring on-premises infrastructure) will read all Event ID 1200 in the Security.evtx showing “logon events” and upload these events to blob storage. These events will then appear in the Azure sign-in logs (generally within 30 minutes).

Essentially, to generate fake events and send them into Azure sign-in logs, the attacker needs to get a service access token. This can be fetched by generating a FAKE POST request to “” with the following information:

  • The agent key (HKLM:\SOFTWARE\Microsoft\ADHealthAgent\AgentKey)
  • Tenant ID (HKLM:\SOFTWARE\Microsoft\ADHealthAgent\TenantId)
  • Machine ID (HKLM:\SOFTWARE\Microsoft\Microsoft Online\Reporting\MonitoringAgent\MachineIdentity)

The attacker can then use this token to get a blob storage URL with a SAS token. The attacker then fetches an event publisher key and uploads the “fake” events to blob storage.  Finally, the attacker sends the signature to the events hub by deriving the signature key from the Agent Key (fetched previously).

Luckily for us, this entire process has been abstracted away by @DrAzureAD in AADInternals and the attack looks something like this...

Fetch details required for generating a service access token:

Generate fake events and send into blob storage:

These will then populate in the portal roughly 30 minutes later.

Method 2: Full attack conducted on attacker machine

This attack is conducted on my cloud-only tenant “”.
As mentioned, this method is slightly harder to detect and DOES NOT REQUIRE the tenant to use AD FS. To perform this attack, the attacker needs to have the pre-requisite of a Global Administrator account (I have tested this using other administrator roles and it’s still limited to Global Administrator only). Using the compromised account, the attacker will perform the following tasks:

  • Register a new hybrid health service – which will show up under the Azure AD Connect Health portal
  • Register an AD FS server (this will generate the agent key and details needed to fetch the service access token)
  • Generate fake events (as per method 1)

I have conducted this entire attack on a Windows 10 virtual machine (you do not need to use a server to do this). To register a new hybrid health service:

This will then show up inside the Azure Portal (below). Note that the status is unmonitored and doesn’t have a Last Updated timestamp.

To correct this, we need to register a new AD FS server which will be my attacker Windows 10 machine. 

Once these files are generated, when you refresh the Azure Active Directory Connect Health portal you will see that the status is now “healthy”.

Now we have a fake “AD FS” on a tenant that’s fully cloud based. Let’s now generate some fake events and send it into the Sign-in Logs.

To be a little sneakier, let’s now remove the service and agent completely. 

After around 30 minutes, looking inside the Azure portal for the sign-in logs we can confirm that these events have now been added:


In general, despite the fact there are two methods of performing this attack, I would focus on using the following methodology as a guidance:

  • Detect sign-in events in Azure sign-in logs with no application / resource set – this is how the malicious events will look using AADInternals
  • Detect an ABSENCE of ADFS Event ID 1200 that correlates with logons recorded in Azure Sign-in logs
  • Detect the creation of a new server in the Azure Hybrid Health Service
  • Detect the deletion of a server in the Azure Hybrid Health Service
  • Review all the current ADFS services in Azure Active Directory Connect Health for any signs of malicious services registered
  • Detect the use of AADInternals via endpoint forensics

Step 1: Detecting Malicious Sign-in Events (Sign-in Logs)
When AADInternals is used to create forged sign-ins, there is a limit on the number of parameters the tool takes. The result of this, is the fact that the Application and Resource on the logs generated will appear as “NotApplicable” or “NotSet”. As such, a detection for this will be to hunt for the following:

  • Application / Application ID: NotApplicable
  • Resource: NotSet
  • Resource ID: urn:federation:MicrosoftOnline
  • Token Issuer Type: Federated (ADFS)
  • Authentication Details.Authentication Method: Forms Authentication

If you’re curious about what Forms Authentication means – here’s a Microsoft write-up about it.

This is a screenshot of how this event appears:

Step 2: Detecting an Absence of Event ID 1200 on the AD FS Server
Note, this only applies if Method 1 was used by the threat actors to conduct this attack (i.e. compromising an on-premise AD FS server and generating the spoofed events).

For every logon event, the AD FS server will generate a correlating Event ID 1200 in the Security.evtx file. However, because we are spoofing the events, this correlating event ID will not be triggered on the AD FS server.

On my AD FS server where I conducted this attack, there are NO event ID 1200 for Sombra or Henry that match the fake events I generated.

The implication of this detection is that, in order to find malicious activity, the defender needs to keep in mind a few things:

  • Do not match the timestamp between the AD FS Event ID 1200 with the timestamp in the Azure Sign-In logs because the timestamp can be spoofed

  • Focus on looking for IP addresses and other details that can match the AD FS event with the Azure Sign-in event

  • Ensure that these logs are being ingested in a SIEM so you can cross correlate these logs with the Azure Sign-in logs

3. Detect the creation of a new server in the Azure Hybrid Health Service
This can be used to detect Method 2, where a threat actor registers a malicious Azure Hybrid Health Service on their attacker VM. The logs that will reveal this event is stored inside the Azure Portal’s Directory Activity logs.

To access these logs, you go to this location: [Any Subscription] > Activity Log > Toggle “Activity” to “Directory Activity”

You want to look for the event:

  • Operation Name: Creates a Server AND Updates a service
  • Event Initiated By: Global Admin account that was compromised
  • Scope: /providers/Microsoft.ADHybridHealthService/services/AdFederationService-[domain]
  • Ipaddr: Threat actor IP
  • Resource Type.Value: Microsoft.ADHybridHealthService/services
  • Status: Succeeded

This is what the events look like inside the portal:


4. Detect the deletion of a server in the Azure Hybrid Health Service
As above, this is also used to detect Method 2, in the advent that the threat actors proceeded to remove and deregister the malicious Azure Hybrid Health Service from their attacker machine. The events for this are also logged in the Azure Directory Activity logs.

  • Operations: Deletes a server AND Deletes service
  • Event Initiated By: Global Admin account that was compromised 
  • Scope: /providers/Microsoft.ADHybridHealthService/services/AdFederationService-[domain]
  • Ipaddr: Threat actor IP
  • Resource Type.Value: Microsoft.ADHybridHealthService/services
  • Status: Succeeded

5. Review all the current ADFS services in Azure Active Directory Connect Health for any signs of malicious services registered

Honestly, the Directory Activity Logs are sufficient for this detection (see steps 3 and 4), however, any registered Azure Active Directory Hybrid Health services will show up in the Azure portal under “Azure Active Directory Connect Health”. If you visit the service that you think is malicious, you will see the ADFS server name that’s registered. I would perform the following checks:

  • Check that all of these ADFS servers are legitimate – i.e. follow your organisation naming convention to try find one that is anomalous.

  • AADInternals sets a default “Last Booted” and “Last Uploaded” time of 1/1/1 24:00:00


6. Detect the use of AADInternals via endpoint forensics

I really don’t want to turn this into an endpoint forensics blog post because I could go on and on about various artefacts. So, I will only cover main detection cases if EDR is present on AD FS servers, and you don’t really have any command line logging. Keep in mind the following detection will not apply if the threat actors performed a PowerShell downgrade attack.

The log sources to focus on are:

  • Microsoft Windows PowerShell Operational.evtx
  • Microsoft Powershell.evtx
  • Powershell ConsoleHost History

Microsoft Windows PowerShell Operational.evtx

Focus on event ID 4104 with the event “Execute a Remote Command” where the script block contains references to AADInternals.

Microsoft Powershell.evtx
Focus on event ID 800 “Pipeline Execution Details” where the logs also show reference to AADInternals scripts.

ConsoleHost History
In the directory “%appdata%\Roaming\Microsoft\Windows\PowerShell\PSReadLine” you will see the commands issued under the context of the user. In this instance, you can see the commands I executed as the attacker on the AD FS server.

Et voila, this is all there is to it 😊 Good luck and catch baddies UwU xx

P.S I'm sorry for the obscenely designed cover photo, just email your complaints to "". And in regards to my choice of forged IP - blame it on my (de)generation. 




Popular posts from this blog

Forensic Analysis of AnyDesk Logs

How to Reverse Engineer and Patch an iOS Application for Beginners: Part I

Successful 4624 Anonymous Logons to Windows Server from External IPs?