An analysis of Suspicious Authentication activity from Azure Security Center

There are some readers after following this article to simulate alerts generated from Azure Security Center approaching me asking about one of the alerts they have seen named Suspicious authentication activity. They don’t know whether their testing virtual machines in Azure have been compromised or not.

This article is not going to provide you in-depth analysis to answer the question: has the virtual machine been compromised? because your environment is not similar to mine, as well as to give the concrete answer we would need to involve DFIR process. This article is going to explain analyst about what the alert is as well as what you should do to trace the event back. You will learn on how to write Kusto Query Language (KQL) to do an analysis.

Disclaimer: Azure Security Center provides number of black-box rules which we don’t know exactly what the signatures are used behind the scenes as well as what kind of ML algorithm or rule threshold for each alert. That said, this article could only give you as much as it could so you could conclude things yourself.

Pre-requisites

To simulate the alert as well as prepare an environment to follow this article, there are some pre-requisites:

  • A virtual machine that is exposed to Internet without any NSG restriction/or allow RDP port 3389 from any source.
  • Virtual Machine Standard pricing is enabled.
  • Azure Security Center data collection is configured to write log to a Log Analytics workspace.
  • Windows Security Event is collected (check Azure Security CenterSettingsData Collection).

After getting these things above completed, try to log into the virtual machine and then go to the Log Analytics workspace with the query below to verify if the agent is working:

or better to check directly SecurityEvent table

Understanding the alert

Once your virtual machine is exposed to the Internet you do need to wait for it to be scanned and get attacked. It may take a few hours or may be a day. Based on my observation it took a few hours until it has been visible to Internet bad actor.

First of all, Suspicious authentication activity is specifically believed to work on Windows OS only. For Linux it is Failed SSH brute force attack. This alert doesn’t mean to tell you what protocol was targeted. It only tells you that there was a brute-force attack using dictionary of predefined username and password on the indicated virtual machine (in my case it is winapp-vm).

The alert also gives you information about the attacker source IP, number of failed authentication attempts especially number of existing accounts used by source to sign in which may make you concerned. And finally it gives list of top accounts with failed sign in attempts in a specific period of time (between Start Time and End Time).

Alert Explained

First, you may want to extract the following info from the alert that may be helpful for your next step:

  • TimeGenerated: when an alert was generated in Log an
  • StartTime: this is not a suspicious event start time. It is when a rule was started.
  • ProcessingEndTime: similar to StartTime, this is not a suspicious event processing time. It is when a rule was processed somewhere before the alert was generated.
  • AlertName: name of the alert
  • SystemAlertId: a unique generated ID.
  • ResourceId: resource ID of the virtual machine
  • AlertType: it is an internal name of the alert. In this case it is Login_BF_ValidUserFailed (BF stands for Brute-Force)
  • Activity Start Time: this is a suspicious activity event start time.
  • Activity End Time: this is a suspicious activity event end time.
  • Attacker source IP: captured IP address where the brute-force was originated from.
  • Number of existing accounts used by source to sign in
  • Number of failed authentication attempts to host
  • Number of nonexistent accounts used by source to sign in
  • Top accounts with failed sign in attempts (count)
  • RDP session initiated successfully? it tells you during the suspicious event time if there was any successfully RDP session initiated.

Azure Portal UI provides you all of information above. However, I’d recommend you to get familiar with Kusto Query Language (KQL) and practice it as much as possible because you will definitely need it for hunting, detection and investigation when working with Azure especially Azure Sentinel.

Below is the query to explore the suspicious authentication activity alert from Azure Security Center

When you run the result you may notice  time variance between suspicious activity time versus the start time that alert was generated in Log Analytics workspace. The time you see inside of Extended Property is actually the suspicious event time.

You may be wondering how Azure Security Center could know that from the dictionary attack there was 1 account existed on the indicated virtual machine, as well as other information like RDP session initiated and top account failed attempt. As said from the beginning of the article, no concrete answer could have been made since the alert is a black-box one. However what we can guess is that Azure Security Center would have to rely on a data source to produce its prediction. The answer would be SecurityEvent data source where data collected from Azure Security Center is stored.

Security Event Log Analysis

In SecurityEvent table, specific to this case, we can acquire the following information:

  • What is the number of failed authentications ?
  • What are top accounts that were used in a failed logon ?
  • Is there an existing account that was part of the dictionary?
  • Was RDP session initiated succesfully? – based on EventId 4624, LogonTypeName

First, let’s practice some queries against SecurityEvent table to figure out the answer for each of the question above:

To count number of failed authentication we would only need to query Event ID 4625 – An account failed to log on

To query top accounts that were failed to sign in:

You might want to render to a piechart by adding | render piechart  to the query

The next question you’d like to answer is What are accounts that may be existed in those failed ones? In Windows security event there is a substatus code that would let you know if a user logon is misspelled or bad password – 0xc000006A. So if you see this substatus there is a 50% chance indicating a user is existed but bad password.

Use the following query to find 0xc000006A substatus in a authentication failure record

The next one is about RDP session initiation. There are some indicators to check:

  • Logon Type Number: normally RDP Logon Type is 10, but in the context of cloud you would normally see 3 – Network in Logon Type because your virtual machine would be RDP-ed from a different network. You might rely on 7 – Unlock but that is probably not case.
  • Event ID: it is still 4624 – no magic here.

This query couldn’t work well independently because you do need to see from the list of failed authentication accounts if any of them that were logged successfully from a historical data. So here is the query to check:

The query above simply filter all failed accounts during the suspicious event time (from Azure Security Center) and check from historical data of 30 days if any of them were successfully logged.

ASC Alert and SecurityEvent Mapping

You can manually check all top accounts used from Azure Security Center and then cross query against SecurityEvent table. However this is considered a time-consuming approach. You can technically extract list of accounts Azure Security Center finds and then cross check with SecurityEvent. Below is just the sample query to achieve:

The result would match with the ASC alert

From what we have investigated so far,  our belief would be that Azure Security Center also looks into SecurityEvent table and runs its query to extract information. You can get the exact number like what Azure Security Center gives you, as well as the thing that Azure Security Center says about existing account – in fact there is a built-in local account named  DEFAULTACCOUNT in Windows 10 (winapp-vm is a Windows 10 by the way)

The rule is till unrevealed thought.

Azure Sentinel

You may ask yourself if the rule for Suspicious authentication activity is good enough. Should we build our own rule in this case? First we need to look into Azure Sentinel built-in analytics rule to see if there is good one. As of this article, the following built-in rules that use SecurityEvent data source

  • (Preview) TI map File Hash to Security Event
  • Account added and removed from privileged groups
  • AD account with don’t expire password – disabled
  • AD user created password not set with 24-48 hours
  • Base64 encoded Windows process command-lines
  • Failed logon attempts within 10 mins
  • Group added to built in domain local or global group
  • Malware in the recycle bin
  • Malware in the recycle bin
  • New user created and added to the built-in administrators group
  • Potential Kerberoasting
  • Powershell Empire cmdlets seen in command line
  • Process executed from binary hidden in Base64 encoded file
  • Process executed from binary hidden in Base64 encoded file
  • Rare RDP Connections
  • RDP Nesting
  • Security Event log cleared
  • User account added to built in domain local or global group
  • User account added to built in domain local or global group

Look like we would need to build one scheduled analytics rule to experiment and to compare with future suspicious authentication activity alert from Azure Security Center.

You may need to tune the rule frequency and rule period appropriately.

Conclusion

Again, this article doesn’t seem to tell you about Azure Security Center. It doesn’t also give information about how to detect a RDP brute-force attack. It only provides an analysis with guesses to see whether what Azure Security Center sees would be similar to what we see when doing analysis.

Below are some references that you may need to check out to follow the article:

 

This entry was posted in Monitoring & Detection and tagged , , . Bookmark the permalink.

2 Responses to An analysis of Suspicious Authentication activity from Azure Security Center

  1. Pingback: Demystify alert generated by Azure Sentinel versus other 3rd products - Microsoft Azure Security Randomness

  2. Pingback: Get started with Azure Sentinel Notebooks - Microsoft Azure Security Randomness

Leave a Reply