A threat actor just ran a textbook attack on your colleagues and your cloud storage simultaneously, and most security teams would have caught it too late. UNC6692, newly documented by researchers at Dark Reading, combines Microsoft Teams social engineering, AWS S3 abuse, and a custom malware family called “Snow” into a single campaign. The specific combination matters because it shows how attackers exploit the gap between your identity controls and your network-layer defenses. Automated ipban-style blocking belongs in that gap, and this campaign is a sharp reminder of why.

How UNC6692 Actually Gets In

The entry point is a Teams message, not an email. That distinction trips up organizations that built their phishing awareness training entirely around inbox threats. UNC6692 impersonates IT helpdesk contacts, starts a legitimate-looking support conversation, and walks the target through steps that end with Snow malware on the machine. Teams is trusted by default inside most environments; users are conditioned to follow instructions from people who appear to be internal support staff.

Once Snow lands, the command-and-control infrastructure doesn’t phone home to some sketchy VPS. It uses AWS S3 buckets. That’s a deliberate choice. S3 traffic blends into the background noise of every modern enterprise network. Blocking it at the firewall isn’t a real option without crippling legitimate operations. The attacker is counting on your allowlisting doing their work for them.

This is the threat pattern worth internalizing: the social engineering phase bypasses your email filters, the malware delivery bypasses your attachment scanning, and the C2 traffic bypasses your egress blocklist. Three successive layers of bypass, all engineered around predictable defensive gaps.

Where Automated Blocking Still Applies

When attackers use legitimate cloud services as infrastructure, perimeter IP blocking loses some of its bite. But that doesn’t make behavioral IP controls irrelevant. It just changes where they apply.

Snow malware, like most RAT-class payloads, needs to do follow-on work after initial execution. That follow-on phase typically involves:

• Credential harvesting and authentication probes against internal services
• Lateral movement attempts across adjacent hosts
• Staged data exfiltration, often with brief high-volume bursts to cloud endpoints
• Persistence installation that generates abnormal write activity on network shares

Every one of those behaviors generates network-layer signals. A host that suddenly starts hammering RDP, SMB, or SSH against a dozen internal IPs in a short window is doing something your ipban configuration should flag and act on automatically. The attacker got past your perimeter. Automated behavioral blocking is what limits how far they get from there.

The same logic applies to authentication abuse. If Snow harvests credentials and uses them to authenticate against your VPN, your email, or your admin panel, rate-limiting and failed-authentication blocking at the network layer can detect that abuse even when the credentials themselves are valid. Legitimate users don’t attempt to authenticate from five different source IPs in ninety seconds.

Harden the Environment Before the Next Campaign

UNC6692 is documented now, but the techniques are transferable. Another group will run the same playbook next month with a different malware family and a different cloud provider. Here’s what to do before that happens.

Lock down Teams external access first

Microsoft Teams allows external users to initiate contact with your employees by default in many tenant configurations. That’s the front door UNC6692 walked through. Review your Teams external access policies and disable inbound contact from unmanaged external tenants unless there’s a specific business requirement. If you must allow external Teams contact, restrict it to specific federated domains you control.

Enable call recording and message logging for Teams channels where IT support interactions happen. Social engineering campaigns leave artifacts. You want those artifacts preserved and searchable when you’re doing incident response.

On the network side, treat any host that begins generating repeated authentication failures against internal services as a candidate for automated quarantine, regardless of what the credentials look like. A compromised host using valid credentials still behaves differently than a legitimate user. Authentication rate, source IP consistency, time-of-day patterns, and service access breadth are all signals worth measuring.

Segment your internal DNS and S3 routing. If a workstation has no legitimate reason to resolve or connect to S3 bucket endpoints it has never touched before, that outbound connection should trigger an alert, not silently succeed. Allowlisting known S3 endpoints and alerting on novel ones is unglamorous work, but it directly addresses the C2 channel UNC6692 is using.

For broader security hardening: audit which internal services are exposed to lateral movement. RDP, SMB, and WinRM between workstations in the same segment is a common blind spot. If your endpoint firewall policy allows workstation-to-workstation RDP, you’re handing attackers a free lateral movement path. Restrict those protocols to specific jump hosts or admin subnets and enforce it at the host firewall level, not just the network edge.

The Silk Typhoon extradition news this week is a useful reminder that nation-state tradecraft eventually filters down to less sophisticated groups. The techniques UNC6692 is using right now, trusted-platform abuse, cloud-based C2, layered bypass engineering, are not exotic. They’re the operational baseline. Your defenses need to match that baseline before the next campaign, not after.

Sources

• UNC6692 Combines Social Engineering, Malware, Cloud Abuse – Dark Reading
• Chinese Silk Typhoon Hacker Extradited to U.S. Over COVID Research Cyberattacks – The Hacker News