Snare_Post-Breach-Remediation

Author: Rhys Thornton, Solutions Consultant (EMEA), Snare

Post-Breach Remediation 

Blocking a cyber threat before it has a chance to gain a foothold within your corporate infrastructure is the primary objective of many leading tools on the market today (including Snare), but what happens when those tools fail to detect a threat actor on the first pass? Whether it’s an entirely new threat, or a variation on an existing one, it is just as important to have a solid remediation process and tools to confirm your company data is not at risk. 

With the FBI and CISA both issuing a warning regarding an increase in the number of ransomware attacks (FBI and CISA Issue Conti Warning – Infosecurity Magazine (infosecurity-magazine.com)) being confident in your remediation process is vital. 

Snare products, combined with the enhanced logging capabilities of Sysmon, can provide enriched log data that can assist organisations with ensuring any remediation attempts have been successful. By monitoring the IOCs left behind by an existing breach, Snare and Sysmon can not only check for application hashes and malicious DNS requests across your infrastructure, they can also alert you to these events in realtime. By teaching Snare what IOCs to look for, realtime alerts can be triggered when any system in your organisation exhibits symptoms of the existing breach. 

In this article I am going to focus on 2 specific features from Sysmons logging capability, these are:  

Event ID 1: Process creation 

The process creation event provides extended information about a newly created process. The full command line provides context on the process execution. The ProcessGUID field is a unique value for this process across a domain to make event correlation easier. The hash is a full hash of the file with the algorithms in the HashType field.  

Event ID 22: DNSEvent (DNS query) 

This event is generated when a process executes a DNS query, whether the result is successful or fails, cached or not. The telemetry for this event was added for Windows 8.1 so it is not available on Windows 7 and earlier. 

More details on other events can be found here: Sysmon – Windows Sysinternals | Microsoft Docs 

Using these 2 events, we will be able to search our entire estate for any systems running a malicious process with a matching hash, as well as monitoring for any known malicious DNS requests that the application might make. This allows us to verify that remediation attempts have been successful (if we have no further events logged) or allows us to jump into action if we do see this occurring on other systems.   

Pre-requisites  

The following pre-requisites are required to follow along with the article:  

  • Sysmon needs to be installed on all systems and correctly configured to capture the required events. 
  • Snare agents need to be installed along side Sysmon. Along with the correct audit policies to capture Sysmon events (default Snare Agent audit policies will capture this)  
  • Snare Central installed and configured as a destination for our Snare agents. This enables us to monitor, search and get realtime alerts on logs as they are created. 

Disclaimers 

This article is designed to give an indication of the capabilities of Snare and Sysmon combined. The steps detailed in this article may not be valid for all cyber threats and each threat should be evaluated on a case-by-case basis with security professionals. 

Threat 

For the purposes of this article, I have created a simple program called “MaliciousApplication”. This application doesn’t do anything particularly special other than make specific DNS requests. As part of the initial breach, we identified this program to be the root cause of our issues and the DNS requests it makes are going to C&C servers on the internet. 

Steps have been taken to isolate and remediate the initial machine, but we don’t know if the malicious application had the opportunity to spread throughout our systems. Instead of requiring manual remediation/investigation across our entire estate (which can take considerable time) we can monitor for the particular IOCs (program hash and DNS requests) and check/monitor our entire estate for them. 

Searching estate for persistent threats 

As per the pre-requisites, I have Snare agents and Sysmon installed and configured on all my systems. All Snare agents are configured to send logging data to Snare Central, which is the centralised repository for event data.  

During the initial remediation we identified the below “Process Create” log as the initial inception point for the malicious application.   

Post Breach Remediation_1

Along with malicious DNS request below:

Post Breach Remediation_2

These 2 logs provide a huge amount of detail, along with a number of key data points we can use to monitor our infrastructure.  

Key data points to monitor:  

  • ParentCommandLine, this allows us to see the process that initiated the malicious code. Allowing us to further trace the root cause (for this article it will be Explorer.exe as I manually opened the program) 
  • Hashes, this provides us with a hash of the malicious program and a way to search for similar instances across our estate 
  • CommandLine, this allows to see any extended options specified in the startup of the application. This can sometimes contain extra information relevant to the breach. 
  • ProcessGuid, this allows to correlate other events to this process (such as DNS events) so we can perform a search for the GUID and get all events that relate to the process. 

Using the “Hashes” value stored within the payload of the log, we can utilise the search functionality of Snare Central to look for a process running with a matching hash.  

As you can see from the below screenshot, I have entered the hash into the search: 

Post Breach Remediation_3

As I have “All Systems” selected, Snare Central will look for this hash in any logs generated from all systems. If we receive any results, it indicates that the malicious application was able to replicate itself and we need to take remediation steps immediately. 

Th below results table shows there are 3 instances of this process being started on another system (the 4th log is the initial breach). 

Post Breach Remediation_4

To see any other actions this process took, we can expand out the record to see its details and select the ProcessGuid. 

Post Breach Remediation_5

Then perform another search on the ProcessGuid, the screenshot below shows the results:  

Post Breach Remediation_5

Here we can see the entire lifecycle of the process. When it starts, the DNS requests it makes to “malicious.int.rhyss.uk” and finally the process exiting. We also have the IP address of the system stored in the “System” field, making It easy to identify affected machines. 

Realtime alerts when IOCs occur 

Snare Central also has the capability to monitor inbound log data and trigger email alerts in the event a specific log is received. This is completely configurable using the report builder and can allow us to receive an email alert as soon as a process starts that matches the malicious hash. 

 To do this I am going to create a new report called “MaliciousApplication Alert”. Then configure the report as per the below screenshot: 

Post Breach Remediation_7

I have specified some criteria on the report to only match records created by Sysmon and its “Create Process” event ID. The hash is then passed in to ensure we only return results that match.  

Finally, I have added the “Realtime Alert” object to the report and ticked “Send Email Alerts”. This means as soon as an event is received that matches the above criteria, an email will be sent to any recipients I specify. 

Below is a screenshot of the email generated after running the malicious application on another system. 

Post Breach Remediation_8

Here I can see all the information related to this particular log, such as the date/time of the event and the system the event occurred on. This provides all the information needed to start remediating the affected system immediately. 

Minimise Negative Financial Impacts of System Downtime

With the number of cyber security incidents growing, it has never been more important to ensure that post breach, all remediation attempts have been effective. This ensures the business can regain trust within IT operations and minimise any negative financial impacts of system downtime. The steps outlined in this article can be applied to a number of common threats being actively exploited today, providing organisations with the detailed logging data they need to effectively remediate. 

The powerful combination of Snare and Sysmon provides organisations with detailed logging data they need to be effective at this.  

 

If you would like to know more, please use the contact our team, here.