From Threat Report to Detection Scenario: Simulating UNC6692’s Post-Compromise Tactics on BlackNoise

In December 2025, Google’s Threat Intelligence Group (GTIG) published a detailed analysis of UNC6692, a newly identified threat cluster responsible for a multi-stage intrusion campaign combining social engineering and a custom modular malware suite (the SNOW ecosystem), and a methodical move through a corporate Windows environment to fully compromise the victim’s Active Directory domain.

Every post-access phase, from initial reconnaissance to the final exfiltration of NTDS.dit, is described with technical precision, including tooling, implementation methods and infrastructure. That level of detail makes it an ideal source for building a threat-informed detection scenario on BlackNoise.

The aim is simple: convert a real, observed attack chain into an executable simulation, so that Blue Teams can test their detection capabilities against the exact TTPs documented in the wild, before an actual threat actor does.

BlackNoise operates under an admits to the breach model. This scenario does not simulate the initial phishing phase; there is no Teams message and no credential harvesting page. The simulation begins at the point where the attacker already has a foothold on a Windows endpoint with local administrator privileges.

This is intentional. The value of the scenario lies in what happens after the perimeter is breached: reconnaissance, preparation for lateral movement, credential dumping, and exfiltration. These are the phases in which detection gaps have the most severe consequences, and where most organisations realise they are blind.

UNC6692 operates as an organised external threat actor with a clear and reproducible methodology. Rather than relying on exploit chains or zero-day vulnerabilities, the group combines social engineering to gain initial access with native Windows tools for all subsequent activities. Once inside, they proceed methodically, using legitimate system binaries and trusted cloud platforms at every stage.

What makes UNC6692 particularly relevant for detection engineering is its systematic misuse of legitimate cloud services Throughout the entire intrusion lifecycle, payload delivery, C2 communication and data exfiltration all took place via trusted platforms (AWS S3 buckets, a Heroku WebSocket endpoint). As GTIG notes in its report:

«By hosting malicious components on trusted cloud platforms, attackers can often bypass traditional network reputation filters and blend in with the high volume of legitimate cloud traffic.»

This is not a new concept, but UNC6692 carries it out with operational discipline. Every layer of their infrastructure was designed to resemble normal enterprise cloud traffic. The implications for defenders are clear: domain reputation and IP blocklists offer no warning against this threat profile. Detection must be moved upstream.

The UNC6692 campaign is a concrete example of a wider defensive challenge that the GTIG report defines precisely:

«This ‘living off the cloud’ strategy allows attackers to disguise malicious operations within a high volume of encrypted traffic from reputable sources, making detection based on domain reputation or IP blocking increasingly ineffective. Defenders must now look beyond process monitoring to gain clear visibility into browser activity and unauthorised cloud traffic.»

This observation shaped the development of this scenario. The exfiltration event – data transferred to an attacker-controlled S3 bucket via HTTPS – is structurally identical to legitimate AWS traffic generated by hundreds of enterprise applications every day. Detecting it requires behavioural analysis of cloud egress traffic, not signature matching.

The scenario is designed to bring that question out into the open: Does your detection stack have visibility into what leaves your network via cloud storage, and can it distinguish between authorised and unauthorised transfers?

BlackNoise scenarios are built from a library of discrete technical events, each of which is mapped to a MITRE ATT&CK technique. The construction of this scenario followed a strict principle: Every selected event must be directly linked to the GTIG report, either as an explicitly described action or as an immediate technical prerequisite for a documented action.

Two categories of events were defined:

• Tier 1 – Strict coverage: events described directly in the article.

• Tier 2 – Extended cover: events that are a necessary technical prerequisite for a documented action (e.g., enabling Restricted Admin mode in the registry is the direct prerequisite for Pass-The-Hash over RDP, which UNC6692 explicitly utilised).

The final scenario contains 14 events (+1 for prior system authentication) across seven MITRE ATT&CK tactics, structured to reflect the realistic chronological progression of the documented intrusion, including slow, covert network scans and deliberate pauses between offensive phases.

The table below maps each BlackNoise event to the specific section of the GTIG report that led to its inclusion. The 14 events are organised in a logical MITRE ATT&CK sequence across seven tactics.

Running this scenario on BlackNoise provides quantifiable answers to the following detection questions:

1. Can you detect post-compromise reconnaissance? Events 1–3 execute standard CMD commands (systeminfo, net user, nltest). Taken in isolation, these are indistinguishable from legitimate administrative activity; only behavioural correlation (unusual parent process, unexpected user context) will flag them.

2. Do your network security controls detect slow internal scans? Events 4–5 use stealthy TCP scan techniques with delays between requests. Signature-based detection optimised for fast scanners will fail to detect them at all. Detection requires flow analysis or behavioural baselines.

3. Is your registry monitoring configured for pre-PTH setup? Event 10 (Enable Restricted Admin) is a clear indicator of an impending Pass-The-Hash attack. If this registry change goes undetected, the lateral movement to the DC is likely to succeed unchallenged.

4. Does your EDR flag LOLBin-based LSASS dumping? Event 11 uses comsvcs.dll MiniDump — a fully native Windows method. The quality of detection here is directly dependent on the level of detail in the EDR configuration.

5. Can you detect credential extraction at domain level? Event 13 (NTDS dump) is the most severe action in the scenario. Security gaps here mean that an attacker can walk away with every domain credential hash without being detected.

6. Is data exfiltration to cloud storage visible? Event 14 sends data to an AWS S3 bucket via HTTPS. This traffic is structurally identical to legitimate SaaS traffic. As GTIG notes, detection based on domain reputation or IP blocking is ineffective in this case. Detecting this transfer requires DLP inspection or proxy-based behavioural analysis at the cloud egress point, and the ability to distinguish between authorised and unauthorised cloud storage destinations.

The UNC6692 scenario is a direct translation of a documented, real-world intrusion into a BlackNoise simulation. It does not invent TTPs or extrapolate beyond the source material; every event is based on a specific technical action or prerequisite described in the GTIG report. The ‘assume breach’ framework keeps the focus where it matters most: the post-access phase, where detection failures have the most severe operational consequences.

For Blue Teams, this scenario offers something more valuable than a generic attack simulation: a ground-truth benchmark against a known adversary. Running it reveals not only whether alerts are triggered, but also whether the detection logic is correctly tuned for the specific challenge posed by UNC6692 – an attacker who generates no suspicious domains, no known-bad IP addresses and no unusual file signatures, yet manages to extract an entire Active Directory.

—–

Source for this scenario: Google Threat Intelligence Group, «UNC6692 Custom Malware»

https://cloud.google.com/blog/topics/threat-intelligence/unc6692-social-engineering-custom-malware