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

In December 2025, Google’s Threat Intelligence Group (GTIG) published a detailed analysis of UNC6692, a newly tracked threat cluster responsible for a multistage intrusion campaign combining social engineering, a custom modular malware suite (the SNOW ecosystem), and a methodical pivot 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, execution methods, and infrastructure. That level of detail makes it an ideal source for building a threat-informed detection scenario on BlackNoise.

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

BlackNoise operates under an assume breach model. This scenario does not simulate the initial phishing phase, no Teams message, no credential harvesting page. The simulation starts from 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 crossed: the reconnaissance, the lateral movement preparation, the credential dumping, and the exfiltration. These are the phases where detection gaps have the most severe consequences, and where most organizations discover they are blind.

UNC6692 operates as an organized external threat actor with a clear and replicable methodology. Rather than relying on exploit chains or zero-days, the group combines social engineering for initial access with native Windows tooling for everything that follows. Once inside, they move deliberately, using legitimate system binaries and trusted cloud platforms at every step.

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

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

This is not a new concept, but UNC6692 executes it with operational discipline. Every layer of their infrastructure was designed to look like normal enterprise cloud traffic. The implications for defenders are direct: domain reputation and IP blocklists provide no signal against this threat profile. Detection must move upstream.

The UNC6692 campaign is a concrete illustration of a broader defensive challenge that the GTIG report frames precisely:

« This ‘living off the cloud’ strategy allows attackers to blend malicious operations into a high volume of encrypted, reputably sourced traffic, 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 unauthorized cloud traffic. »

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

The scenario is designed to force that question into the open: does your detection stack have visibility into what leaves your network via cloud storage, and can it distinguish authorized from unauthorized transfers?

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

Two tiers of events were defined:

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

• Tier 2 – Extended coverage: events that are a required technical precondition 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 used).

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

The table below maps each BlackNoise event to the specific passage in the GTIG report that motivated its inclusion. The 14 events are organized in a logical MITRE ATT&CK progression across 7 tactics.

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

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

2. Do your network security controls catch slow internal scans? Events 4–5 use furtive TCP scan techniques with delays between requests. Signature-based detection tuned for fast scanners will miss them entirely. Detection requires flow analysis or behavioral baselines.

3. Is your registry monitoring configured for pre-PTH setup? Event 10 (Enable Restricted Admin) is a precise signal for an incoming Pass-The-Hash attack. If this registry modification goes undetected, the lateral movement to the DC will likely succeed uncontested.

4. Does your EDR flag LOLBin-based LSASS dumping? Event 11 uses comsvcs.dll MiniDump — a fully native Windows method. Detection quality here is a direct function of EDR configuration depth.

5. Can you detect domain-level credential extraction? Event 13 (NTDS dump) is the highest-severity action in the scenario. Blind spots here mean an attacker can walk out with every domain credential hash undetected.

6. Is exfiltration to cloud storage visible? Event 14 sends data to an AWS S3 bucket over HTTPS. This traffic is structurally identical to legitimate SaaS traffic. As GTIG notes, detection based on domain reputation or IP blocking is ineffective here. Catching this transfer requires DLP inspection or proxy-based behavioral analysis on cloud egress, and the ability to distinguish authorized from unauthorized 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 grounded in a specific technical action or prerequisite described in the GTIG report. The assume breach framing keeps the focus where it matters: 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 fire, but whether the detection logic is correctly tuned for the specific challenge UNC6692 represents, an attacker who generates no suspicious domains, no known-bad IPs, 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