The Fine Art of Frustrating the Adversary

What it is

A Cisco Talos Cybersecurity Awareness Month roundup, with eight named Talos researchers (Pierre, Martin, Nick, Ryan, Michael, Doug, David, Vanja) each contributing one frustration tactic tied to a specific attack-chain stage.

How it works

Beyond what the summary covers, several contributors give mechanisms the summary doesn't:

• Pierre (identity/access): restrict which accounts can log into critical servers, alert on unauthorized connection attempts, require distinct credentials/auth for sensitive systems, use protected enclaves, and alert on any change to admin users or admin groups.
• Martin (early deception): build honeypot email accounts specifically from expired domains with previously-leaked addresses, or seed fictional employee identities where spammers/adversaries are likely to find them — generating early threat intel before real employees are targeted.
• Doug (social engineering): defenders/users should pre-enumerate which real-life events would genuinely require immediate action, then define an independent verification channel (e.g., calling a school's known number rather than one supplied in a message) rather than trusting the message itself.
• Ryan's detection-engineering methodology (behind the ATT&CK/Summiting the Pyramid references already summarized) is a four-step process: identify highest-impact techniques for your environment, map the procedures that implement them, isolate the behaviors that persist across tooling changes, then build analytics that account for encoding/obfuscation.

What to do

• Allowlist approved RMM tools via Windows Defender Application Control, AppLocker, or EDR; block/alert on unapproved ones (AnyDesk, ScreenConnect, Atera).
• Monitor/alert on changes to administrative users and groups; require separate auth for sensitive systems.
• Build honeypot accounts from expired/leaked-address domains to catch targeting early.
• For AI agents: issue per-session identity and short-lived credentials, route traffic through an independent gateway, and block access to cloud metadata/Kubernetes APIs unless explicitly required. Watch for: unexpected writes to package registries/paste sites/file-sharing services, repo creation or dataset commits, calls to Kubernetes/VPN/DoH relay endpoints, public services used as C2/dead-drops, credential discovery followed by cross-account activity, and rapid destination changes or DNS pinning.
• For dead-drop/EtherHiding C2: block malicious domains/URLs via DNS filtering, secure web gateways, or firewall rules using published indicators; for blockchain-contract-based C2, either block public blockchain/RPC access entirely (if not needed for business) or monitor/allowlist known contracts if RPC access is required.

Caveats

Talos states explicitly that none of these actions stops every adversary or fits every environment — the value is added friction/cost and detection opportunity, not guaranteed prevention. Blockchain-contract blocking is noted as harder than domain blocking since it requires RPC-level visibility to distinguish one contract from other traffic.