Exploring the Identity & Access dashboard in Azure Security Center

In Azure Security Center you can use the Identity & Access dashboard to explore more details about your identity posture. In this dashboard you have a snapshot of your identity related activities as shown in the example below:

Just by looking at this dashboard you can draw some conclusions, for example, all failed logons were due an invalid username or password. However, by looking at the accounts under Failed logons section, I can see that none of these accounts exist in my environment (off course, you need knowledge of the environment to conclude that). This can be an indication that there was attempt to brute force the authentication by trying different username and passwords. But what if this was a large organization, and you just don't know all accounts? The follow up question may be: is it possible to know if it was just the username that was wrong? Yes, there is! Follow the steps below to find out:

1. In the Identity & Access dashboard, click the Failed Logon Reasons chart.

2. Log analytics search will open with the result for the following query:

SecurityEvent | where AccountType == 'User' and EventID == 4625 and (FailureReason has '2313')

3. Below you have an example of the query result:

4. Click show more in one of the records.

For this example, the FailureReason field is %%2313, which means Unknown user name or bad password. The %% numbers you see in the FailureReason field are replacement string placeholders used to put localized values in when generating the display text for messages. Microsoft-Windows-Security-Auditing uses the msobjs.dll for storing those localized values. To find out what this code means you can use the open source tool msgdump and dump the message table from msobjs.dll to a txt file (big thanks to Ted Hardy for showing me how to make this conversion):

msgdump %windir%\system32\msobjs.dll > msobjsdll.txt

After that open the file and search for the code, in my case 2313:

This is cool, but still not showing if it was only the user name that was wrong! True, and for that you should look at the SubStatus field:

The status for this one is 0xc0000064, which means: User logon with misspelled or bad user account. How do I know? Well, this is the easy part, is documented here, and if you don’t find in there, you can find it here. With that we can conclude that it was really a bad username, which increases the likelihood that this was a dictionary attack (which is basically a brute force). Keep in mind that this is just one step in the investigation, in the same record make sure to review the source of this authentication (computer, IP, process). Also take advantage of other Security Center capabilities, such as Security Alerts, Security Incidents, and use the Investigation feature to find all the entities involved in the attack.