Device Code Flow is a great feature. You are signed in on a machine that does not have any UI but need to connect to an Azure or Microsoft 365 resource? No problem, device code flow to the rescue. All major PowerShell cmdlets, the az tools and many other tools support this authentication flow.
What makes it so flexible and great? You can go to https://microsoft.com/devicelogin enter a generated code that is displayed on another device and sign-in using your normal user and bam, you are in.
Since a few weeks I recognized an uptick in Entra ID Protection alerts regarding “Anonymous IP address” detections. Normally this is a high-fidelity indicator that someone is using a Tor browser or some other method to cover their tracks. While this behavior is totally fine in a private setting, in enterprise IT the use of such anonymizers is not considered baseline behavior.
While analyzing the related alerts for common patterns I stumbled upon the IP address information.
A few months ago in November 2023 PowerShell 7.2 was made “General Available” in Azure Automation. One important feature was yet missing from the documentation: deployment using Bicep or ARM templates.
As confirmed by Microsoft, the API was already supporting this behind the scenes.
Yes, both Bicep and ARM template support is available. After I checked with a few people to no avail, Jan-Henrik finally gave my the right hint.
In part one I focused mostly on detecting offensive security tools like AzureHound, GraphRunner, and PurpleKnight. In part two I will go into more depth how you can use the now available information for hunting and how to correlate it with other datasets to gain deeper insights.
Correlate Graph activities with other log sources While the MicrosoftGraphActivityLogs alone is a trove of information, correlating it with other logs makes it an even more interesting data source.
When working with Microsoft Entra there are many log sources you can use to detect usage and changes to the environment and the assets within it. Most of them can be forwarded using the diagnostic settings to different targets for better analysis capabilities or long term storage.
In many cases a Microsoft Sentinel or Log Analytics workspace is the target of choice, but also other SIEM solutions can benefit from this stream of log data.
The challenge Most of us analyzing Azure AD SignIn logs have been there. You come across a failed sign-in, but the ResultDescription is not really helpful, but only shows “Other”.
Other? But what other? When using the Entra ID portal UI most of those error codes will perfectly translate to a more helpful error message.
What the sign-in logs cannot do, the portal UI is able to So how can you have the same experience when using KQL?
