In this post we will be discussing Group Policy attacks, basing the threat hunt on a ransomware investigation undertaken by the Sophos X-Ops Incident Response team earlier this year. We will cover malicious behaviors associated with Active Directory and Group Policy attacks, showing you how to investigate and remediate some of these threats.
Much of the material in this post is also covered in the video “Identifying Group Policy Attacks,” now showing on our new Sophos X-Ops YouTube channel. The video shows a hunt and remediation (using Sophos Live Response — a key feature of Sophos Intercept X Advanced with XDR, our standard investigation tool, though hunters can replicate these steps on any Windows shell).
This post walks through the same material, but provides the onscreen information in a reader-friendly format.
The case
In the Cyclops ransomware case under discussion, the threat actor gained initial access to the environment by leveraging a ProxyShell vulnerability to breach an unpatched Exchange server. Four days after achieving initial access, the threat actor began executing their attack using encoded PowerShell commands from the web shell on the Exchange server.
The attacker proceeded to disable endpoint protection as a defense evasion technique, and to clear Windows event logs and internet browser history. The attacker then leveraged Remote Desktop Protocol (RDP) to perform lateral movement to additional machines on the network. Both Cobalt Strike command-and-control malware as well as AnyDesk remote access software were installed on multiple machines to maintain access. A day later, the attacker used their network access to exfiltrate data to multiple cloud storage hosting providers.
After that, the attacker leveraged Active Directory Group Policy to distribute the Cyclops ransomware binary to machines on the domain, also creating a Group Policy to execute the ransomware binary using scheduled tasks. In the final stage of the attack, the attacker deleted volume shadow copy backups. Machines on the domain ran the scheduled task, executing the Cyclops ransomware binary, encrypting files, and leaving ransom notes.
Why target Group Policy?
Group Policy attacks are an indication of a larger Active Directory attack. In a Group Policy attack, threat actors may leverage existing Group Policy Objects, such as UNC path, to execute malicious payloads from less-secure locations preset on a GPO, or the interception of user passwords set via Group Policy with the vulnerable cpassword attribute.
Once a threat actor has escalated privileges, they often create GPOs to accomplish goals at scale, such as disabling of core security software and features including firewalls, antivirus, security updates, and logging. They may also use GPOs for deployment of malicious tools through the creation of scheduled tasks, startup or login scripts, or services to maintain persistence and execute malware.
Happy hunting
Investigators begin a ransomware investigation-and-remediation process by collecting whatever victim testimonies and forensic data are available. Using the tools at hand, they search for indicators of compromise in the standard forensic artifacts, such as Windows event logs, PowerShell history, startup items, shellbags, scheduled tasks, shim cache, and so forth.
When performing an analysis, if synchronized or reoccurring evidence is found, it may be a key indication of a Group Policy attack. For example, when a scheduled task or file execution is seen on multiple machines, it indicates remote execution or the use of Group Policy. When system logs indicating the use of software deployment tools or Windows Management Instrumentation are not present, it serves as an indication that Group Policy was likely compromised. This use of malicious synchronizing is especially evident during triage, when persistent scheduled tasks reappear on systems after being removed.
Once a Group Policy attack is suspected, investigators should look at the Group Policy objects on the domain controller, using the PowerShell command get-GPO -All to list them all. Filtering those results
Get-GPO -All | Sort-Object ModificationTime -Descending | Format-Table DisplayName, ModificationTime, CreationTime
allows the investigator to see modification and creation times, seeking intersections with other facts of the case. Sorting by the date on which files were last modified can lead to any GPOs created or modified by the threat actor. At this point, it is useful for the investigator to generate a GPO report for further investigation.
Get-GPOReport -All -ReportType Html -Path "C:\Windows\Temp\Sophos_GPOReport.html”
Examining the GPO report we can discern the purpose of any Group Policy objects with suspicious names. In the Cyclops case anonymized for our video, we identified three suspicious-looking GPOs, which for anonymization purposes we call “Pawn,” “Rook,” and “Queen.”
- In the case of Pawn, the attacker used the GPO to install a scheduled task on domain computers to run the program rook.exe.
- The Rook GPO is used to copy the rook.exe file to domain-joined machines from an administrative share on the file server. Since it would make sense for the attacker to do exactly that with malware, we immediately go to the local system to see if a copy is still available, using Get-ItemProperty “C:\Windows\rook.exe”. If it is available, an investigator can get the hash value for this file (using Get-FileHash “C:\Windows\rook.exe”) and check it against VirusTotal to see if it’s known to be malicious; this hash also provides the means to block the file in the environment. It’s wise of course to retain a sample of the malware for further forensic analysis.
- The Queen GPO configures Windows Firewall states to Off. It also appears that Queen disables Windows Defender’s antimalware protections, including real-time scanning ability.
Making it better
Once malicious behaviors in your environment are identified, containment and remediation can begin via the Group Policy Management tool on the Active Directory management server.
First, address the Queen, which is undermining Windows Firewall and Windows Defender operations. Disabling this policy will prevent these settings from overriding the default local Windows settings.
Next it’s Rook’s turn to be taken off the board. Disabling this policy will prevent the malware rook.exe from being copied to any additional machines on the network. The malware executable should also be blacklisted in the global settings for the entire network. This will eliminate the malware’s ability to be executed in the future – form a new attacker attempt, for instance, or in case an infected backup attempts to re-load the executable. (Good backup hygiene is an important topic for defenders to consider, but it lies slightly outside the scope of this article.)
Finally, remediate the malicious scheduled task named Pawn. Disabling this GPO prevents additional deployments of the scheduled task to computers on the domain. Following these remediation steps will help prevent the spread of malicious activity throughout the network.
All three of these steps involve disabling malicious GPOs, but that’s not enough; proper remediation will involve taking steps that will perform the opposite action(s) as those taken by the malicious GPOs. This can itself be done at scale with GPOs or other device management platforms. Another option, which some enterprises may prefer, is rollback. If you choose the latter, inspection of the archived material for infection or unwanted alteration is strongly recommended.
Acknowledgements
Elida Leite and Rajat Wason contributed to this research.
