SenseOn SOC Playbook: Ransomware
The following process is how managed providers of SenseOn should extend the investigation of incidents in end customer estates and contains best practice guidance for additional manual threat hunting and containment.
Process Flowchart
Identification
The following steps should be followed in the event of a ransomware incident in the estate.
- Initial identification can be accomplished through SenseOn case, SOC escalation or customer notification (e.g. a third party compromise or IOCs which trigger a SenseOn threat hunt of the estate). As ransomware will typically affect multiple systems, all affected resources should be identified. This can be achieved using the Hunt Lab queries in the Query Library with titles beginning with ‘Threat Hunting’ and searching for IOCs such as file names and network requests to associated malicious locations.
- The IOCs provided or discovered can be used to determine the scope of the ransomware attack in Hunt Lab and should be searched across the entire estate. Analysts should note additional IOCs they observe during this threat hunt. Analysis should be performed across areas including: Installed software, running processes, startup items, scheduled tasks and network connections.
- Additionally, IOCs should be checked using OSINT tools such as VirusTotal to determine the ransomware variant (if possible) and potentially discover additional IOCs from threat intelligence sources.
- The timeframe to search the environment will vary, as threat actors will often achieve initial access and remain dormant in the network to avoid immediate detection. We recommend beginning with a one-week historical search for the identified IOCs. If there are week-old artefacts, we recommend increasing the timeframe of the search until the approximate date of initial access is identified.
- Following confirmation of a ransomware attack, the customer’s disaster recovery plan should be enacted and communicated with the SenseOn MDR provider to ensure cohesion of triage efforts. Additionally, an incident timeline will be constructed and maintained by SenseOn and the customer to document progress towards containment and remediation.
- Once the scope of the attack, affected systems and users have been assessed, a sample of the malicious software should be retrieved for analysis of additional IOCs. This can be done via the ‘File Download’ Resilience script. Note: This should run in parallel to containment actions detailed on the following page, feeding any previously unidentified IOCs derived from this analysis into previous steps to ensure all affected systems are identified and contained in a timely manner.
Resilience Script Access: If you do not have access to the SenseOn Resilience script repository and are a SenseOn MDR provider or customer, contact the SenseOn support team for access.- Static analysis of the malware should be performed on isolated machines. A hash of the malware should first be made, which can then be checked against threat intelligence databases like VirusTotal to see if the malware strain has been seen before in the wild, this could save time by using work performed by others (where possible) and could yield valuable information like associated threat actors, how they operate and how the malware itself functions without having to observe the malware running.
- Following this the malware should be analysed dynamically. Dynamic analysis is the process of the running the malware in a safe and controlled environment to observe how it functions and to glean further information about it. Typically, this is done in a virtual environment, e.g. a virtual machine with monitoring software installed, like the SenseOn agent, that could be deployed to the virtual machine.
- Based on findings from the previous steps, patient zero of the attack should now be identified. Identifying patient zero is important for tracking threat actor behaviour and anticipating motives, in addition to assisting subsequent remediation.
- Identify signs of data exfiltration using the data exfiltration playbook as Ransomware actors will often exfiltrate data to act as a further leverage against the victim. Refer to the data exfiltration playbook for further information on this.
Containment
When containing a ransomware threat the following steps should be followed.
Assess the wider estate
Action for provider of SenseOn MDR
During the identification stage, IOCs should have become apparent as a result of investigation and analysis. These IOCs may be in the form of processes, programs, scheduled tasks, startup items, services or C2 locations which can then be used to assess the wider estate to verify that all affected devices have been found. This can be achieved using the Hunt Lab query library items with titles starting with ‘Threat Hunting’, or by following the steps detailed in the malware playbook.
Assess severity
Action for provider of SenseOn MDR
During customer onboarding, SenseOn recommends its MDR providers agree with customers which resources within the estate require permission before a remote session is established and what actions are permitted as part of containment activity.
This will allow for efficient and timely containment activities while minimising the risk for operational disruption. A high level example of such a matrix is shown below:
During the investigation, the SenseOn MDR provider will assess the sensitivity of impacted hosts to find how business critical the affected systems are. This will later help formulate a recovery plan as well as helping to understand which systems need to be addressed first, and help to identify how this can be done in a way that will minimally affect the business.
When containing a ransomware threat the following steps should be followed.
Isolate affected devices
Action for provider of SenseOn MDR
Isolate impacted systems from the network via Resilience. This can be achieved via using the quick actions feature or by manually running the ‘Isolation’ Resilience script. Following this, confirm isolation affected devices is successful by either:
- Verifying the assets are displayed as isolated in the Digital Estate view
- Confirming the isolation status is ‘True’ via the SenseOn
senseon.query_isolate()function in Resilience. Printing the result of this function is sufficient to confirm the isolation status. - Manually check that isolated devices are unable to make network connections other than to the SenseOn platform.
This will prevent further spread of the infection, stop any command and control connections being made to ransomware operators and disrupt any data exfiltration efforts.
User Account Containment
Action for customer
Any non-critical impacted user accounts should be disabled both on-premise and in the cloud such as Azure AD, to both prevent affected systems being further accessed and abused.
In addition to resetting these accounts, a check for, and removal of, backdoor accounts or accounts with newly elevated privileges should be performed. This can be achieved using the ‘Interesting Windows Event IDs’ Hunt Lab query, and by manually inspecting the Windows event and user account logs.
Further account containment guidance can be found in the recovery section of this guide.
Process Containment
Action for provider of SenseOn MDR
Any identified processes that are running on devices should be terminated by running the 'Process Control' Resilience script. Hunt lab should be utilised to check these processes have been stopped and have not restarted.
Block Attacker infrastructure
Action for customer
Customer to block identified IOCs across all non SenseOn MDR provider managed infrastructure such as firewalls and web filters.
Eradication
Preserve data
Action for customer
It is important to preserve any data that is volatile so that further analysis can take place after the incident has been recovered from. This is something the customer will need to make a decision on in terms of feasibility and effort required. In the SenseOn platform Long Term Telemetry Retention (LTTR) can be enabled to retain all SenseOn telemetry on a long term basis.
Run antivirus scans
Action for customer
Any antivirus solution deployed to devices across the estate should have their signatures and definitions updated. If the previously identified malicious hashes are not detected by the solution, report this to the vendor.
Once signatures have been updated following the above, run antivirus scans on devices to identify any malware that may have made its way onto the device as part of the attack. If malware is identified the malware playbook should be consulted and followed.
Artefact Removal
Action for provider of SenseOn MDR
Any malicious artefacts discovered during the identification phase should be removed from affected systems including:
- Malicious processes
- Startup items/registry keys
- Services
- Custom software
- Remote management tools
- Firewall rules
- File dropped locations such as OneDrive and network share folders
These should be removed using the Resilience scripts contained in the SenseOn repository.
Recovery
Restore systems
Action for customer
Systems should be reverted to a previous state from before the incident by using backups. If backups are unavailable then the machines should be rebuilt using an image or a clean, new installation of the operating system.
Once this has taken place, perform IOC checks using indicators uncovered during the identification phase against these systems to confirm no malicious artifacts are present. Following this, deploy relevant software or security patches addressing any vulnerabilities that were successfully exploited as part of the attack.
Setup monitoring
Action for provider of SenseOn MDR
Once the impacted systems have been restored, a plan for monitoring the impacted devices and the estate should be put in place. This should assess the devices, and the estate as a whole, for signs of previously seen IOCs to make sure that the previous incident has been remediated. Typically this would involve an hourly check for which hunt lab could be used to perform the task.
Review regulatory requirements
Action for customer
Review relevant regulatory and legislative documentation to assess whether any governing bodies should be notified of the incident. For example, often in ransomware incidents data will be exfiltrated by the threat actors in which case, in the UK, the Information Commissioner’s Office will likely need to be notified, however, this will depend on the type of data that was exfiltrated.
The data exfiltration playbook could be consulted for further detail on legislation and regulation.
Reset privileged accounts
Action for customer
Any highly privileged accounts and tokens should be reset, and in some instances these should be reset twice. For example, the KRBTGT account and the ADFS Token Sign Certificate should be reset twice, however the AzureADSSOACC$, all the Domain Controller machine accounts, and the AAD Sync account need only be reset once.
Further guidance on doing this can be found on the ‘SenseOn AD Recovery Guide’ confluence page.