Your Security Tools Can't See What's Already There

The LOTL Reality

Traditional security is built on a simple premise: bad guys bring bad tools. Detect the tools, stop the attack.

Living Off The Land breaks this model. The attacker uses what's already installed:

• PowerShell (on every Windows machine)

• WMI (built into the OS)

• SSH (now shipping with Windows)

• Certutil (certificate utility that also downloads files)

• Your admin tools (PsExec, Ansible, SCCM)

• Your vendor tools (Cisco Smart Install, VMware PowerCLI)

Salt Typhoon went further. They used the lawful intercept interfaces built into telecom equipment - the backdoors designed for court-ordered wiretaps. They wiretapped America using America's own wiretapping tools.

There's no malware hash to block. No C2 domain to sinkhole. No IOC to feed your threat intel platform.

Why Detection Fails

Your security stack is looking for anomalies in a sea of normal:

What EDR Sees	What It Means
powershell.exe started	Normal (happens 1000x/day)
Admin logged into router	Normal (NOC does this)
Data transferred to cloud	Normal (backup jobs)
Service account authenticated	Normal (automation)

The attacker's actions look identical to your IT team's actions because they're using the same tools, the same protocols, the same paths.

Signature-based detection is useless. Behavioral detection drowns in false positives. Your SOC is playing whack-a-mole with alerts that all look legitimate.

The Answer: Whitelist Your World

Stop trying to detect bad. Start enforcing known-good.

1. Whitelist Your Egress

Here's a question: Where should your network traffic actually go?

Most organizations have no idea. Traffic leaves their network, hits the default gateway, and the internet figures out the routing. That's insane.

The Fix:

Default egress policy: DENY ALL

Explicit allows: ├── Office 365 endpoints (Microsoft-published IP ranges) ├── Your SaaS vendors (known IP ranges) ├── Your cloud infrastructure (your IPs) ├── Vendor update servers (Microsoft, Cisco, etc.) └── Nothing else ```

When Salt Typhoon exfiltrates data, it has to go somewhere. If that somewhere isn't on your whitelist, the traffic dies at your firewall.

"But we can't possibly whitelist everything!"

• Domain controllers → only talk to known endpoints

• Network infrastructure → only talk to management stations

• PCI/regulated data → only talk to approved destinations

2. Whitelist Your Commands

PowerShell is dangerous because it can do anything. So constrain what it can do.

PowerShell Constrained Language Mode: ``powershell # Limits PowerShell to basic operations # No .NET, no COM, no arbitrary code $ExecutionContext.SessionState.LanguageMode = "ConstrainedLanguage" ``

AppLocker/WDAC: `` Allow: Signed scripts from IT Allow: Scripts in C:\AdminTools Deny: Everything else ``

The attacker has PowerShell. But PowerShell can only run scripts you've approved from locations you've blessed.

3. Whitelist Your Admin Paths

If your domain admin can log in from any workstation, so can the attacker who stole their credentials.

Enforce admin paths: `` Domain Admins → can ONLY log in from jump servers Jump servers → can ONLY be accessed from admin VLAN Admin VLAN → can ONLY be reached from specific workstations Those workstations → require hardware token + biometric ``

The attacker has domain admin creds. But those creds only work from a jump server they can't reach, which requires a hardware token they don't have.

4. Whitelist Your Network Flows

Your database server has no business talking to the internet. So enforce that.

Microsegmentation: `` Web servers → can talk to app servers on port 8080 App servers → can talk to DB on port 1433 DB servers → can talk to backup server on port 445 DB servers → CANNOT talk to internet (any port) ``

The attacker compromises your database. They try to exfiltrate data. The traffic is blocked because DB servers don't talk to the internet. Period.

5. Whitelist Your Authentication

Every authentication should be expected. Unexpected auth = alert.

What this looks like: `` svc_backup authenticates from backup-server-01 → Expected, allow svc_backup authenticates from workstation-47 → Unexpected, block + alert domain_admin authenticates at 2PM from jump server → Expected domain_admin authenticates at 3AM from VPN → Block + alert + wake someone up ``

The attacker has credentials. The credentials are valid. But they're using them from the wrong place at the wrong time. Blocked.

The Honey Token Advantage

Whitelisting tells you what's allowed. Honey tokens tell you when the whitelist failed.

Plant fake credentials everywhere: `` fake_admin in Active Directory (alerts if used) AWS_ACCESS_KEY in old config file (canary token) database_backup_pw in password manager (honeypot) [email protected] in breached credential lists (alerts on use) ``

The attacker does what attackers do: harvest credentials, try them. The moment they try a honey credential, you know you're compromised - before they find the real ones.

Zero false positives. Honey tokens are never used legitimately. Any use is hostile.

Implementation Priority

You can't whitelist everything overnight. Start here:

• Domain controllers

• Certificate authorities

• Network management systems

• Backup infrastructure

• Jump server requirements for privileged accounts

• Network segmentation for admin VLANs

• MFA everywhere (hardware tokens for admins)

• PowerShell logging (everything, everywhere)

• AppLocker/WDAC on servers

• Constrained language mode where possible

• East-west traffic controls

• Zero-trust network architecture

• Continuous verification

The Salt Typhoon Lesson

The telecoms that got breached had security tools. They had EDR. They had SIEM. They had SOCs.

They didn't have whitelists. They didn't enforce known-good. They let their routers talk to anywhere, their admins log in from anywhere, their traffic flow to anywhere.

Salt Typhoon lived in that "anywhere" for months.

• Legacy equipment not updated in years

• Router vulnerabilities with 7-year-old unpatched CVEs

• No segmentation between management and production

• Lawful intercept interfaces accessible from compromised systems

These aren't sophisticated attacks. They're walking through doors that should have been locked.

The Uncomfortable Truth

Whitelisting is hard. It requires knowing your environment - actually knowing it, not assuming you know it.

• Where does traffic need to go?

• Who needs to run what commands?

• Which systems talk to which systems?

• What does normal actually look like?

Most organizations can't answer these questions. So they default to permissive policies and hope detection catches the bad stuff.

Salt Typhoon proved that hope isn't a strategy.

Start Today

You don't need a massive project. Start with one question:

"Should my domain controllers be able to reach the internet?"

The answer is no. Block it. That's one whitelist rule. You're now more secure than you were yesterday.

Then ask the next question. And the next.

Every whitelist rule you implement is a door closed to the attacker. LOTL only works when the land is permissive. Make your land hostile.

---

The attacker is using your tools. Your network. Your credentials. The only advantage you have is that you know what "normal" should look like. Enforce it.

DugganUSA provides free threat intelligence at analytics.dugganusa.com/api/v1/stix-feed. But threat intel can't help you if your network lets everything talk to everything. Fix the architecture first.

---

Her name is Renee Nicole Good.