My new blog is XINTRA.ORG/BLOG

  Full blog post link: https://www.xintra.org/blog/lateral-movement-entraid-cross-tenant-synchronization

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

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

  In this brilliant blog ( https://aadinternals.com/post/phishing/ ) by @DrAzureAD, he introduced a method of phishing M365 accounts that threat actors can leverage by abusing device code authentication. There have been a lot of great blogs citing this technique but not much written about the detection… which is why I am here 🙂 The reason I am writing about this technique is that it’s significantly more difficult to detect than OAuth abuse for malicious application registrations. The reason for this is, the entire premise of the phish occurs within the microsoftonline.com namespace and does not redirect the user to any third-party website and there is no need for any 3rd party application authorization/registration. This method of phishing also bypasses MFA requirements as the attacker gains access to the user’s refresh and access token. I wanted to revisit this technique and blog about a detection for this type of attack. As usual, I’ve broken this blog post into two sections: At...

  Hello naughty sysadmin... I've been watching your search history this Summer O_o How do you detect when a user deletes their chrome history and is there a way to forensically recover it? The answer is… it depends. 😈 A good indicator for recovering what a user was doing when they deleted their chrome browser history is by checking inside the C:\Users\<name>\AppData\Local\Google\Chrome\User Data\Default\Sessions folder. The two files you need to look at are named: Session_<Webkit/Chrome date> Tabs_<Webkit/Chrome date> The session file stores session information and the tabs file stores what tabs they had opened. In a certain situation when a user CLEARS their Chrome history, what they were browsing can persist within these files.  There are a few potential cases that could have occurred, and we will go through all of them: A user cleared their history and did not use Chrome since A user clears their history and re-opened ONE new session A user clears th...