Check Point’s analysis of the seized Gentlemen ransomware C2 server contained one finding that deserves more attention than it received: the group deploys ransomware via Group Policy Objects. The reporting covered this as a “sophisticated technique.” It is, but not in the sense that matters most for defenders.
GPO-based ransomware deployment is not an escalation of the attack. It is the final step of an attack that was already complete before the ransomware binary ever executed.
What GPO Deployment Actually Means
To create or modify a Group Policy Object that executes a binary on domain-joined systems, you need Active Directory write access at the OU or domain level. In practice, this means Domain Administrator or an equivalent delegated role. Standard user accounts cannot do it. Compromised workstations cannot do it alone. Even many server administrator accounts cannot do it.
When an attacker deploys ransomware via GPO, they have already:
- Gained an initial foothold in the network
- Escalated from that foothold to domain-level credentials
- Maintained access long enough to enumerate domain structure, identify organisational unit coverage, and configure policy
- Likely exfiltrated data and destroyed backups, because those activities precede encryption in every mature ransomware playbook
The ransomware event the SOC detects — file system encryption, volume shadow copy deletion, endpoint alerts firing across hundreds of machines simultaneously — is the sound of a door slamming after the attacker has already left with everything of value. The actual intrusion happened days or weeks earlier. The SOC missed it.
The Detection Problem
This is not a criticism of incident responders. It is a diagnosis of where the detection boundary sits.
Most enterprise security programmes are calibrated to detect impact — ransomware encryption, data exfiltration alerts, credential harvesting at scale. These detections fire. They fire loudly, often simultaneously, triggering major incidents. But by the time they fire, the useful investigation window — the period when the attacker’s foothold can be disrupted before serious damage occurs — has already closed.
The detection that matters for ransomware is not “ransomware is executing.” It is “an attacker has Domain Admin on our network.” That detection is much harder, much quieter, and much more likely to be suppressed by alert fatigue, misconfiguration, or coverage gaps in AD monitoring.
The signals were there. They are almost always there, in retrospect:
- A SystemBC beacon connecting to an external proxy every 30 minutes on a file server that should have no external connectivity
- A domain admin logon at 02:00 on a Thursday from a service account that normally never authenticates interactively
- A Group Policy Object created at 03:15, modifying startup scripts for a domain-wide OU, by a principal that has never touched Group Policy before
- Shadow copy deletion commands running via a newly registered scheduled task
These are all detectable events. They are rarely detected in time, because the detection infrastructure is weighted toward the end of the kill chain, not the middle.
What “Good” Detection Posture Looks Like
The organisations that catch ransomware operators before the encryption event share a common capability: they treat Domain Admin access as the detection perimeter, not ransomware execution.
This means:
Privileged account monitoring as a primary control, not an afterthought. Every interactive domain admin logon from a host that is not a privileged access workstation should be a high-fidelity alert. Every new domain admin group member addition should require out-of-band confirmation. Every service account with domain admin rights that authenticates interactively should trigger immediate investigation.
Group Policy change alerting. Changes to GPOs — especially the creation of new policies with executable payloads, or modifications to existing policies covering large OU scopes — should generate alerts reviewed within minutes, not hours. The window between GPO creation and ransomware execution is often the last opportunity for containment.
Lateral movement detection weighted toward AD infrastructure. Attackers moving toward domain controllers — via pass-the-hash, Kerberoasting, credential relay, or direct exploitation of AD RCE vulnerabilities — should be the highest-priority detection target in the environment. If CVE-2026-33826 exploitation is not generating alerts on domain controller RPC activity, the detection programme has a material gap.
Baseline and hunt for SystemBC and similar proxy malware. The 1,570 victim IPs in the Gentlemen’s C2 database represent organisations with active SystemBC beacons. They are pre-ransomware, not post. An organisation in that database that hunts and remediates the SystemBC infection prevents the ransomware event. An organisation that waits for the ransomware alert investigates a corpse.
The Gap That Keeps Widening
Ransomware operators have had years to optimise their attack sequences around enterprise detection patterns. GPO-based deployment is not new — it has appeared in Conti, LockBit, and multiple other RaaS operations. It persists as a technique because it works. It works because most enterprise detection programmes treat the domain as a monitored asset and Active Directory as a monitored-but-hard-to-baseline system, rather than treating Domain Admin access as the security perimeter it actually is.
The Gentlemen’s C2 server data makes the gap explicit: 1,570 organisations have already passed the point where the intervention that matters was possible. The moment to have stopped the attack was when SystemBC beaconed out, not when the GPO fired.
The question for security operations teams is not how to detect GPO-deployed ransomware faster. It is how to move the detection boundary back to the point where the outcome can still be changed.
That means Active Directory. Every time.