Azure Command Line Forensics - Host Based Artifacts

On most of the on-premises to cloud lateral movement compromises I’ve worked relating to Azure, threat actors typically leverage a bunch of different command-line focused tools. They use these tools to perform enumeration of the victim’s Azure environment, backdooring active directory, various persistence techniques and lateral movement. These are generally a combination or one of the following (this is not a comprehensive list... just examples):

• AADInternals
• Azure CLI
• AzureAD PowerShell

Threat actors run these tools on servers and hosts of interest i.e. AD FS servers, AD CS servers to abuse pass-through authentication or abuse identity federation. The Azure CLI has also been leveraged by attackers to perform various enumeration / reconnaissance style attacks.

If you want more detailed information around how to detect and perform attacks against Azure and Microsoft 365, check out my "Attacking and Defending Azure / M365" course.


High-Level Methodology
First to perform this analysis, I baseline the modules installed via PowerShell to form an understanding of what logs to focus on during the investigation. Then once I figure this out, I focus on:

1. Baselining the user accounts leveraged on the system to access Azure (parsing the .json files). This will allow you to figure out what accounts to focus the analysis on during the investigation. Also keep in mind attackers can delete / alter this file.
2. Review commands logged in the Azure CLI logs
3. Review commands logged in the Azure AD logs
4. Reviewing PowerShell log artifacts (not covered in this blog because there are so many write-ups about this)
5. Cross correlate host-logs with cloud logs to fill in gaps in analysis

The best situation here is an understanding that in order to get a full picture of the attack, where an attacker has leveraged on-premise modules, the analyst should perform a combination of cloud-based log analysis and also understand the on-premise artifacts that might fill in gaps in the logs or the timeline.


Why Perform Azure Host-Based Command-line Logging
I felt like I needed to write this section because I imagined some people asking me this T_T. So, depending on the log settings of the victim organisation and the type of Azure AD / M365 license, there are a lot of benefits of performing command-line forensics on hosts with a focus on Azure-related artifacts. These benefits include:

• Understanding what commands were successfully executed and which commands were not
• If the organisation isn’t forwarding logs to a SIEM, these artifacts allow the analyst to analyze older Azure commands logged that may no longer be accessible in the tenant that are still relevant to the investigation.
• Some organisations have not enabled relevant and NECESSARY diagnostic logging settings to view telemetry such as blobs being accessed, or keys being viewed from key vaults and are missing a treasure trove of forensic data that these logs fill in.

Forensic Methodology

PREWORK: Figure out what modules may be relevant for analysis
An attacker may have NEVER used ADDInternals, Az CLI, MSOnline or anything like this on the system. But you should still review what modules are installed and figure out if you need to perform command-line forensics. Without going into too much detail (because there are so many write-ups on this) you can check what modules are installed by doing the following

• Running $env:PSModulePath

• Reviewing “typical” module installation paths (examples below but not limited to the following)
  C:\Users\<username\Documents\PowerShell\Modules
  C:\Windows\System32\WindowsPowerShell\v1.0\Modules

• Reviewing the Windows Powershell.evtx
  Focusing on Event IDs 800 and 400 to detect pipeline execution or the start of a PowerShell host process. As you can see from the logs below, AADInternals was executed and present on the environment running under the user “lina”.

• Reviewing the Microsoft Windows Powershell.evtx
  Focusing on Event IDs 4104 and 4103 which highlight remote command execution and pipeline execution.

1. Baseline accounts used to access Azure from the host
Where Azure CLI has been utilised on the host, a particular folder location will be created under the context of the user account “C:\Users\<username>\.azure”. This folder will contain a file name “azureProfile.json” which stores information regarding properties of Azure subscriptions / users that were accessed on the host. This is extremely valuable information because you can use these timestamps and user accounts to check the relevant Azure AD / Sign-in and UAL logs to piece together the timeline of malicious activity.

There are other files along with this which are used by Azure CLI to keep state on the disk (to avoid asking the user nonstop for their credentials

• Az.json
• Az.sess

If you open up the “azureProfile.json” file you will see the following:




As you can see below it stores interesting information relating to access – giving the blue teamer a good understanding of accounts to focus on.



2. Review the Azure CLI logs for signs of malicious commands being executed
If you have a rough idea of the compromise window, the command logs are stored in the following directory “C:\Users\<username>\.azure\commands” and they are listed in a very easy to understand format of “<Date>-<command>.log”.




This log below is showing evidence of changing / modifying permissions to the Key Vault using the account "cole@inversecos.onmicrosoft.com". This is ironically a sign of attempted privilege abuse on the account - but the log shows that the command threw an error and stated that this user did not have the permissions to grant permissions to the vault.




However, 2 minutes later, the attacker using the account “cole@inversecos.onmicrosoft.com” succeeded and was able to grant these permissions:




Similarly, this log here shows the threat actors listening the keys inside a specific key vault, however this attempt to access the key was unsuccessful.




This telemetry is interesting from a forensic standpoint because you’re able to timeline or gain visibility into what the attackers were attempting to do, with CLEAR messages showing you if the commands were executed successfully or not. This, coupled with a list of accounts that were used to access the Az CLI allow the analyst to figure out what accounts to prioritise when it comes to reviewing cloud-based logs.


3. Review Azure AD PowerShell logs for signs of malicious commands being executed
If the attacker used Azure AD PowerShell, the logs will be stored in this directory: C:\Users\<username>\AppData\Local\Microsoft\AzureAD\Powershell. Please note that the AADInternals tool also leverages some of these modules which results in logs in this directory as well. So this is not evidence of a user specifically leveraging Azure AD, but could be a combination of direct use of the Azure AD module or through the use of another PowerShell tool which relies on this module.



The files here are stored in a text document and show interesting telemetry around what commands were executed. As per the screenshot below, you can see the user was executing commands relating to GetGroups and Get-AzureADDevice



Because I was the attacker in this instance, I knew these were executed via AADInternals – for those instances you need to cross correlate these timestamps with the evidence you can see in other PowerShell logs to figure out the trigger for these commands. You can do this via PowerShell related forensics:

• Windows Powershell.evtx logs
• Microsoft Windows PowerShell Operational.evtx logs
• PSReadLine PowerShell logs (consolehost_history.txt file)

Lastly, if you want to learn about different attacks in Azure and Microsoft 365, check out my "Attacking and Defending Azure / M365" course UwU <3

good luck and have fun 
xx