Security Monitoring with Attack Behavior Based Signatures
Monday, May 25, 2015
Coaches and athletes both gather intelligence against their upcoming opponent by watching game film. Based on what they learn, they adjust their strategies to account for their opponent’s strengthens, weaknesses, and tendencies. The analogy about watching game film does not translate well to information security. In sports, the film study is to identify a single opponent’s tendencies while in information security there is no film for the numerous threats a company is up against on a weekly basis. However, the concept of watching an opponent's techniques to identify tendencies does translate. These tendencies are how they compromise systems and by identifying tendencies enables a company to adjust their security monitoring program. Companies can have the visibility to detect threats in their environment even when those threats are new or unknown. Attaining this level of visibility is possible by leveraging attack behavior based signatures in security monitoring.
SearchSecurity defines an attack vector as "a path or means by which a hacker (or cracker) can gain access to a computer or network server in order to deliver a payload or malicious outcome." Based on this definition, the attack vector is broken down into three separate components. The path or means is the exploit used, the payload is the outcome of the exploit, and the delivery mechanism is what delivers the exploit and/or the payload to the target. The definition combines the delivery mechanism and exploit together but in reality these are separated.
As defenders, exploring attack vectors enables us to better protect systems, detect when systems are under attack, and determine how systems are compromised. The Compromised Root Cause Analysis Model goes in to detail about identifying and understanding the artifacts left on a compromised system to determine the attack vector used in the attack. This post goes in to detail about how exploring attack vectors can be used to determine when systems are under attack.
When attacking a system the attacker is constrained to the environment they are targeting. In this environment, certain actions behave a certain way every time they are performed. The behavior is dictated by the operating system and the action performed results in the operating system behaving a certain way. This behavior occurs every time the action is performed making the activity detectable. The attacker controls the exploit and payload so these can be changed making detection harder. However, the delivery mechanism component of the attack vector is susceptible to security monitoring in the Windows operating system. The delivery mechanism is dependent on the operating system and this is the environment the attacker is constrained to. Each time the attacker uses that delivery mechanism results in the same activity occurring in the operating system. This is the activity detected when using attack behavior based signatures.
To elaborate on delivery mechanisms resulting in the same activity an example is needed. Word documents are a mechanism used by attackers to compromise systems. The exploits in Word documents vary from macros to hyperlinks to Microsoft Word exploits. The payloads vary even more since an attacker can use anything. Case in point, some attackers use the Dridex malware as the payload while other attackers use the Dyre malware. Traditional signature detection mechanisms try to keep pace with the changes attackers introduce in the exploit or payload. Attack behavior based signatures instead focus on the delivery mechanism’s interaction with the operating system. The activity caused by the Word document executing in the Windows operating system to deliver malware. This behavior remains the same no matter how much obfuscation or encryption attackers use to conceal the exploit and/or payload. To demonstrate this behavior what follows is a walkthrough of the activity of a malicious Word document being used as a delivery mechanism and the activity is monitored with the Microsoft Sysmon software. The sampled used in this walkthrough is the malicious document MD5 d89c0affa2c1b5eff1bfe55b011bbaa8 obtained from Malwr.com.
To compromise a system the malicious document needs to be executed. The picture below shows what occurs when the document is executed by the user. Upon execution, the user's shell (Explorer.exe) creates a process for the program that is the default reader for Word documents (files ending in .doc). In this instance and similar to most systems in enterprise environments, the default reader is Microsoft Word and the program's executable is named WINWORD.EXE.
At some point after the WINWORD.EXE process creation the exploit in the document is ran. Again, the exploit varies from macros to links to Microsoft Word exploits to embedded executables. Regardless of the exploit used, the activity of using Word as a delivery mechanism is the same and is shown in the picture below. Microsoft Word creates a child process for the payload of the attack. In this instance, WINWORD.EXE creates the process for the file kiramin86.exe inside a user profile's temp folder.
This is the activity that is susceptible to security monitoring. Microsoft Word (WINWORD.EXE) being the parent of another process that is a Windows binary (i.e. exe, pif, dll). Depending on the organization, this activity is the anomaly since Microsoft Word may rarely be the parent process of another executable or try to execute another executable. This is the type of activity attack behavior based signatures can focus on to detect new and unknown threats. The signature can be narrowed down even further to make it more accurate - such as focusing on executables in user profiles - but in essence this is the activity being detected. The signature is able to detect attack vectors using Word documents delivery mechanisms even if the exploit and payloads are different.
Attack behavior based signatures are not only limited to detecting the attack vector’s delivery mechanism. The concept can be applied to other techniques used by the attacker. At times attackers leverage techniques to bypass Windows User Account Control (UAC). UAC is a feature in Windows where every application ran under an administrator user account only runs in the context of a standard user. Bypassing UAC is a way for attackers to elevate their standard user privileges to administrator privileges. (For more information on UAC see the post UAC Impact on Malware.) The malicious document used in the previous walkthrough delivers the Dridex malware and this malware has a UAC bypass.
The May 12, 2015 post A New UAC Bypass Method that Dridex Uses outlines the current technique Dridex uses to bypass UAC. The article stated the following about how Dridex uses the application compatibility database to bypass UAC:
"An application compatibility database is a file that configures execution rules for applications that have compatibility issues. These files have an extension of sdb. Dridex leverages this feature to bypass UAC."
".Dridex uses the sdbinst command to install/uninstall application compatibility databases to install $$$.sdb."
This UAC bypass technique is constrained to the Windows environment and results in the same activity occurring in the operating system. The picture below shows the activity. The sbdinst.exe process is created and the commandline used to create the process points to an application compatibility database file (.sdb) inside the user profile. It’s activity that occurs every time so it is susceptible to detection through security monitoring. The signature’s logic could be the image value containing “sdbinst.exe” and the commandline containing .sdb file in a user profile.
To leverage attack behavior based signatures in security monitoring to detect new and unknown threats is achievable. The approach requires technology to provide visibility on enterprise end points and the backend needs technology for the collection and analysis of the logs from the endpoints. The technology on the end point needs to provide visibility involving the Windows process and files the process interact with. This article leveraged Microsoft Sysmon utility since it is freely available to anyone and was suggested to me by Harlan Carvey. Other options are available for the end points including possibly existing agents that may already be deployed in enterprises. The technology for the collection and analysis of logs from the end points need to support regex or wildcards for querying the logs to identify the attack patterns. Attack behavior based signatures tend to focus on characteristics of processes involved in the attack activity. For malicious documents with Microsoft Word installed on the endpoint, the focus is on WINWORD.EXE and not necessarily the entire file path since this executable can be located in different folders (i.e. 32bit versus 64bit Word programs). Regex or wildcards support in queries enables this type of flexibility when building detection signatures.
Another consideration is attack behavior based signatures need to be used in layers customized to an enterprise. The walkthrough only demonstrated one signature for Word documents but there are numerous other attack vectors to account for. Each attack vector needs to be customized to the enterprise to account for the software installed on their endpoints. Further customization is needed since y their nature attack behavior based signatures results in false positives. The signatures detect patterns in the activity involving Windows processes. This activity can be either malicious or normal behavior. To identify false positives triage processes need to evaluate the activity flagged by the signatures to determine if they are false positives or security events. For reoccurring false positives, the signatures need to be tuned to reduce the noise from normal behavior.
Despite the technology, process, and customization challenges, leveraging attack behavior based signatures in security monitoring can be an effective approach for detecting new and unknown threats. The techniques used by attackers are constrained to our environments and their techniques cause activity on our systems that may be susceptible to detection. It just requires us to identify the activity susceptible to detection, build signatures to detect it, and then share with others to help them improve their monitoring capabilities.
Attack Vectors
SearchSecurity defines an attack vector as "a path or means by which a hacker (or cracker) can gain access to a computer or network server in order to deliver a payload or malicious outcome." Based on this definition, the attack vector is broken down into three separate components. The path or means is the exploit used, the payload is the outcome of the exploit, and the delivery mechanism is what delivers the exploit and/or the payload to the target. The definition combines the delivery mechanism and exploit together but in reality these are separated.
As defenders, exploring attack vectors enables us to better protect systems, detect when systems are under attack, and determine how systems are compromised. The Compromised Root Cause Analysis Model goes in to detail about identifying and understanding the artifacts left on a compromised system to determine the attack vector used in the attack. This post goes in to detail about how exploring attack vectors can be used to determine when systems are under attack.
When attacking a system the attacker is constrained to the environment they are targeting. In this environment, certain actions behave a certain way every time they are performed. The behavior is dictated by the operating system and the action performed results in the operating system behaving a certain way. This behavior occurs every time the action is performed making the activity detectable. The attacker controls the exploit and payload so these can be changed making detection harder. However, the delivery mechanism component of the attack vector is susceptible to security monitoring in the Windows operating system. The delivery mechanism is dependent on the operating system and this is the environment the attacker is constrained to. Each time the attacker uses that delivery mechanism results in the same activity occurring in the operating system. This is the activity detected when using attack behavior based signatures.
Delivery Mechanism: Malicious Word Document
To elaborate on delivery mechanisms resulting in the same activity an example is needed. Word documents are a mechanism used by attackers to compromise systems. The exploits in Word documents vary from macros to hyperlinks to Microsoft Word exploits. The payloads vary even more since an attacker can use anything. Case in point, some attackers use the Dridex malware as the payload while other attackers use the Dyre malware. Traditional signature detection mechanisms try to keep pace with the changes attackers introduce in the exploit or payload. Attack behavior based signatures instead focus on the delivery mechanism’s interaction with the operating system. The activity caused by the Word document executing in the Windows operating system to deliver malware. This behavior remains the same no matter how much obfuscation or encryption attackers use to conceal the exploit and/or payload. To demonstrate this behavior what follows is a walkthrough of the activity of a malicious Word document being used as a delivery mechanism and the activity is monitored with the Microsoft Sysmon software. The sampled used in this walkthrough is the malicious document MD5 d89c0affa2c1b5eff1bfe55b011bbaa8 obtained from Malwr.com.
To compromise a system the malicious document needs to be executed. The picture below shows what occurs when the document is executed by the user. Upon execution, the user's shell (Explorer.exe) creates a process for the program that is the default reader for Word documents (files ending in .doc). In this instance and similar to most systems in enterprise environments, the default reader is Microsoft Word and the program's executable is named WINWORD.EXE.
At some point after the WINWORD.EXE process creation the exploit in the document is ran. Again, the exploit varies from macros to links to Microsoft Word exploits to embedded executables. Regardless of the exploit used, the activity of using Word as a delivery mechanism is the same and is shown in the picture below. Microsoft Word creates a child process for the payload of the attack. In this instance, WINWORD.EXE creates the process for the file kiramin86.exe inside a user profile's temp folder.
This is the activity that is susceptible to security monitoring. Microsoft Word (WINWORD.EXE) being the parent of another process that is a Windows binary (i.e. exe, pif, dll). Depending on the organization, this activity is the anomaly since Microsoft Word may rarely be the parent process of another executable or try to execute another executable. This is the type of activity attack behavior based signatures can focus on to detect new and unknown threats. The signature can be narrowed down even further to make it more accurate - such as focusing on executables in user profiles - but in essence this is the activity being detected. The signature is able to detect attack vectors using Word documents delivery mechanisms even if the exploit and payloads are different.
Technique Detection: Bypassing UAC
Attack behavior based signatures are not only limited to detecting the attack vector’s delivery mechanism. The concept can be applied to other techniques used by the attacker. At times attackers leverage techniques to bypass Windows User Account Control (UAC). UAC is a feature in Windows where every application ran under an administrator user account only runs in the context of a standard user. Bypassing UAC is a way for attackers to elevate their standard user privileges to administrator privileges. (For more information on UAC see the post UAC Impact on Malware.) The malicious document used in the previous walkthrough delivers the Dridex malware and this malware has a UAC bypass.
The May 12, 2015 post A New UAC Bypass Method that Dridex Uses outlines the current technique Dridex uses to bypass UAC. The article stated the following about how Dridex uses the application compatibility database to bypass UAC:
"An application compatibility database is a file that configures execution rules for applications that have compatibility issues. These files have an extension of sdb. Dridex leverages this feature to bypass UAC."
".Dridex uses the sdbinst command to install/uninstall application compatibility databases to install $$$.sdb."
This UAC bypass technique is constrained to the Windows environment and results in the same activity occurring in the operating system. The picture below shows the activity. The sbdinst.exe process is created and the commandline used to create the process points to an application compatibility database file (.sdb) inside the user profile. It’s activity that occurs every time so it is susceptible to detection through security monitoring. The signature’s logic could be the image value containing “sdbinst.exe” and the commandline containing .sdb file in a user profile.
Leveraging Attack Behavior Based Signatures
To leverage attack behavior based signatures in security monitoring to detect new and unknown threats is achievable. The approach requires technology to provide visibility on enterprise end points and the backend needs technology for the collection and analysis of the logs from the endpoints. The technology on the end point needs to provide visibility involving the Windows process and files the process interact with. This article leveraged Microsoft Sysmon utility since it is freely available to anyone and was suggested to me by Harlan Carvey. Other options are available for the end points including possibly existing agents that may already be deployed in enterprises. The technology for the collection and analysis of logs from the end points need to support regex or wildcards for querying the logs to identify the attack patterns. Attack behavior based signatures tend to focus on characteristics of processes involved in the attack activity. For malicious documents with Microsoft Word installed on the endpoint, the focus is on WINWORD.EXE and not necessarily the entire file path since this executable can be located in different folders (i.e. 32bit versus 64bit Word programs). Regex or wildcards support in queries enables this type of flexibility when building detection signatures.
Another consideration is attack behavior based signatures need to be used in layers customized to an enterprise. The walkthrough only demonstrated one signature for Word documents but there are numerous other attack vectors to account for. Each attack vector needs to be customized to the enterprise to account for the software installed on their endpoints. Further customization is needed since y their nature attack behavior based signatures results in false positives. The signatures detect patterns in the activity involving Windows processes. This activity can be either malicious or normal behavior. To identify false positives triage processes need to evaluate the activity flagged by the signatures to determine if they are false positives or security events. For reoccurring false positives, the signatures need to be tuned to reduce the noise from normal behavior.
Despite the technology, process, and customization challenges, leveraging attack behavior based signatures in security monitoring can be an effective approach for detecting new and unknown threats. The techniques used by attackers are constrained to our environments and their techniques cause activity on our systems that may be susceptible to detection. It just requires us to identify the activity susceptible to detection, build signatures to detect it, and then share with others to help them improve their monitoring capabilities.
Labels:
detection
Posts
Excellent post, Corey. Thanks for sharing this information; if nothing else, it should demonstrate to others the incredible capability offered in monitoring process creation/execution, not only as a security mechanism, but also simply for understanding what's going on on systems, and being able to troubleshoot issues.
The blog should have been about, "Despite the technology, process, and customization challenges", which is the real issue here. Writing detection/prevention signatures is the easy part.
Go try convincing engineering and operations that you need full process monitoring on ALL systems to get Sysmon working on an environment that's 50k - 300k users. I agree you could start monitoring your critical assets, but those are also some of the hardest to get additional software installed on. It's not impossible.
There is often disconnect between blogging and the real world. Memory forensics is a perfect example of this. Blog: Execute malware on a system, dump memory 10 seconds later, and, "Wow, look at all these artifacts" vs. Real world: Malwre runs. It's identified 5 - 220 days later. In the meantime the user has rebooted the system 5+ times. Oh, we don't have the bandwidth in Thailand to pull it back? Wait, we don't have F-Response either? Oh.. What? Event logs have been overwritten? When you have the help desk staff acquire the memory for you to analyze they logged into it with their own creds effectively logging out the curernt user or maybe they even rebooted it again because, "something wasn't working right".
Most organizations don't even have fully functioning SIEM tool(s) to process this data. Sure, they might have one, but they are always in a state of deployment and seem to never actually get there. In the meantime their "SIEM expert" left the company because they got frustranted. To top it off it's owned by operations and engineering, not the security team(s) and they limit your searches becasue operations first and all that good stuff. Then you have a data analytics team that's in charge of managing "big data", but what that means is they could care less whether or not your timestamps are normalized. . Wait, what about sysmon? Oh, it was too loud and we aren't allowing it anymore or we would need to upgrade the entire Splunk stack and that's $100k+ on a good day.
Nothing against your post. It is good information. I am just saying, that there are bigger challenges here that seem to be overlooked by the fantasy land of blogging vs. the real world.
I think it would do the community some good if people actually spoke about "real issues" such as the few you seemed to skip (technology, process, and customization challenges).
great post
First of all nice post....
This post gives me an idea of creating another use case for detecting embedded malicious executables in a document not just dependent of AV...
Is there a way to use the native event/audit logging in Win2008/2012 to achieve this events to be generated? From the enterprise operational point of view, its almost impossible to implement sysmon even for 2 servers due to EPS (event per second) and storage.
Im hoping you can share some of your thoughts to achieve it... Nice post again.
Please continue to post like this especially detecting exploitation, its a good input in creating a use case for SIEM.
@Anonymous
I don't see how your comment is relevant. Blog posts like this one are in fact, "real world", and at the level that hundreds of organizations and gov agencies are at. They are also at the level that organizations *must* be at if they hope to defend against "real"/sophisticated attacks.
If your org is failing at basic processes like having proper logging, pre-deploying acquisition tools, agents, etc. then it means your company just does not care about security and/or needs to find a CISO that is competent. Rolling security into deployments and getting engineering/devops into the process is fairly trivial compared to actual securiy challenge that companies face.
Bloggers at the cutting edge of DFIR shouldn't dumb down their posts to please the lowest common denominator of companies that fail at security 101.
@anon,
Thanks for leaving such a detailed comment along with sharing the hurdles it seemed you encountered trying to build out security monitoring. I’ll try to address each point and if you do have any questions please feel free to hit me up offline.
> The blog should have been about
The purpose of the blog was to focus on the detection technique. It’s a technique I haven’t seen discussed publically so I opted to exclude those things to prevent any distractions from the point of the post. The technique can be carried out with different technology so I decided against trying to discuss something that may cause a distraction.
> Go try convincing engineering and operations that you need full process monitoring on ALL systems to get Sysmon working
In this post I used Sysmon to demonstrate the technique. I couldn’t get around not using any tool so I picked one that is free. Other tools can be used such as Carbon Black or anti-virus products.
> environment that's 50k - 300k users
This size environment isn’t one I have encountered yet
> There is often disconnect between blogging and the real world.
Is this a reference that my blog post is not the real world? If so, I’m doing exactly what I described here with very good results in the "real world". However, the tech I’m using not Sysmon but I used for the post what I have available to myself with my own resources
> Malwre runs. It's identified 5 - 220 days later.
This is where this technique comes in to play. It can detect malware in minutes instead of days. This focuses on the actual attack vector used to initially compromise the system. I agree about the challenges with memory forensics though.
> To top it off it's owned by operations and engineering, not the security team(s)
To me this seems to be the problem right here. The technology at this point is an operations tool and not a security tool. Trying to make it fit security needs after the fact will be difficult.
> Wait, what about sysmon?
Again, Sysmon was only an example. I'm doing what I described using the existing antivirus product and it avoided any issues with operations.
> I am just saying, that there are bigger challenges here that seem to be overlooked by the fantasy land of blogging vs. the real world.
I don’t think I follow the “fantasy land” comment. What I described in this post is actually being done in the real world. Due to being a personal blog, I couldn't directly talk about how I actually pulled this off. If my CFP gets accepted at a certain con I’ll go in to detail on the technology part. My organization gave me the greenlight to discuss it. As for this blog, I keep a strong separation between my personal research/etc.. and the work I do for my employer. The research is the same but how it is implemented in my employer and what I have available with my own resources will be different.
> I think it would do the community some good if people actually spoke about "real issues" such as the few you seemed to skip (technology, process, and customization challenges).
The purpose of the post was the detection technique and it is a very real issue. How can one identify an unknown threat if they have nothing else to go on? It's an issue I faced and I explained in this post how I addressed a part of the issue. Those other issues were not the point of this post.
@anon #2
> detecting embedded malicious executables
Don't forget to account for the other document viewers such as Adobe Reader, Excel, Powerpoint, etc..
> Is there a way to use the native event/audit logging in Win2008/2012 to achieve this events to be generated?
I haven't tested this at all to see how to accomplish this. Process tracking auditing may work but I haven't tested if it records the info needed to detect on this. I also don't have access to a large testing environment to test to see how the rest of the use case needs to be built out.
> Im hoping you can share some of your thoughts to achieve it
Short version. I opted to use the existing anti-virus product. The benefits was it was already deployed, someone else manages the agents, and the way it works reduces the EPS. The AV doesn't record every process nor every file the processes interact with. It only records the processes interacting with items inside certain folders. These folders is where malware initially gets dropped on a system. This made implementing this pretty easy. Agents were already deployed and managed; I just had to request a few logging changes to get this info. This wasn't my first choice but it ended up being the best choice.
The EPS hit is pretty low compared to bringing in all processes across all systems. Different types of behavior based rules are in place to detect different kinds of techniques used in attacks.
> From the enterprise operational point of view
If AV isn't an option for you. Try Process auditing with malicious Word documents to see if it records the activity. If it does, do you have the ability to use filters to drop logs at your backend system? On my SIEM, I use filters for other logs to get rid of noise. It drops a bunch of stuff I don't need and it helps on avoiding increasing the EPS for no reason.
> Nice post again
Thanks and thanks for taking the time to leave a comment