The grey zone: how attackers live off your own tools, and why prevention alone stopped being enough

The grey zone#

Most security conversations still assume a binary world. Something is malicious or it is benign. A file is bad or good. A process is allowed or blocked.

Modern intrusions do not live there. They live in the grey zone: the enormous middle ground where an action is technically legitimate, performed by a legitimate tool, under a legitimate account, over legitimate infrastructure, and is still part of an attack.

The tooling that decides "bad or good" struggles in the grey zone because there is nothing intrinsically bad to find. PowerShell is not malware. AnyDesk is not malware. A Cloudflare tunnel is not malware. A domain admin logging into a domain controller is not malware. An attacker who chains those four things together has just owned your estate, and every individual event may look like a Tuesday.

This is the shift I keep running into. The question is no longer "did something malicious execute?" It is "did the right person do that, for the right reason, in the right order, at the right time?" That is a judgement, not a signature, and judgement is exactly what a lot of security programmes never resourced.

Living off the what?#

The industry has grown a small vocabulary for grey zone tradecraft, and the terms are worth knowing because they describe slightly different problems.

Living off the land (LOTL) is the umbrella. The attacker uses what is already there instead of bringing their own toolkit.

LOLBins (living off the land binaries) are the signed, built-in operating system utilities repurposed for attack: powershell.exe, cmd.exe, wmic, certutil, bitsadmin, regsvr32, mshta, rundll32, and increasingly curl.exe and tar.exe, which shipped into Windows years ago and still get less behavioural scrutiny than the classics. The community LOLBAS project catalogues well over a hundred of these, and the list keeps growing.

Dual-use tools are legitimate commercial software abused for attacker purposes: remote monitoring and management (RMM) agents, remote access tools, network scanners, archivers, tunnelling clients, password recovery utilities. They are not "hacking tools". Your IT team probably uses several of them.

Living off trusted sites and services (LOTS) covers the infrastructure equivalent: command and control through Cloudflare tunnels, Telegram, Discord, GitHub, Dropbox, OneDrive, Google services, or a paid VPS in a region you do business with. Blocking "suspicious domains" does not help when the callback goes to a hostname your users already need.

LOOBins are the macOS cousins. Cisco Talos published research in April 2026 formalising native Apple primitives such as osascript and AppleEvents as a living off the land toolkit with very little detection coverage, which matters as Mac fleets keep growing in the enterprise.

BYOVD (bring your own vulnerable driver) is the aggressive end of the same idea: load a legitimately signed but vulnerable kernel driver and use it to blind or kill the endpoint agent that would otherwise have caught the rest.

The pattern across all of these is identical. Borrow trust rather than defeat it.

Why the grey zone works so well#

Five structural reasons, and none of them are fixable with a better blocklist.

1. Trust is inherited, not evaluated. A Microsoft-signed binary passes reputation checks because Microsoft signed it. That signature says nothing about intent.

2. Attacker activity is indistinguishable from administration. Enumerate accounts, query the directory, copy a tool to a share, schedule a task, run something remotely, compress a folder, upload it. That is either a compromise or a Tuesday night maintenance window, depending on context you cannot get from the process alone.

3. Blocking is politically and operationally expensive. You cannot simply remove PowerShell, WMI, RDP, or your RMM agent. They are load bearing. Every "block it" recommendation collides with a team that needs it, so you end up with exceptions, and exceptions are where the grey zone lives.

4. Identity has become the front door. Sophos X-Ops analysed 661 incident response and managed detection cases from November 2024 to October 2025 and found 67% were rooted in identity attacks, with MFA missing in 59% of cases and brute force (15.6%) drawing almost level with exploitation (16%) as initial access. When the attacker logs in with valid credentials, the authentication log records success. Not a failure. Not an alert. Success.

5. The tooling trend confirms it. In the same body of casework, Impacket accounted for 36% of all observed tools and rose 83% year on year, while Cobalt Strike faded to barely inside the top 35. The most abused remote access tool was AnyDesk, the most abused scanner was SoftPerfect Network Scanner, and the most abused archiver was WinRAR. Meanwhile, external telemetry has been telling the same story from a different angle: roughly four in five detections are now malware-free, PowerShell and the command shell rank among the most observed techniques, and the previous year's Sophos casework recorded a 126% increase in the abuse of unique living off the land binaries.

Read those together and the conclusion is uncomfortable. The prevention stack is not being defeated by better malware. It is being stepped around by activity it was never designed to adjudicate.

What this looks like in a real incident#

August 2026 gave us an almost perfect specimen, and it is worth walking through because it is a grey zone attack from end to end.

An authentication bypass in the N-able N-central RMM platform (CVE-2026-18577, following an incomplete fix for CVE-2026-18556) let an unauthenticated attacker take administrative control of the management console. From there they did not need an exploit chain or a custom implant. They used the product's own Take Control feature, which is exactly what the product is for, to reach managed endpoints, including a backup server, domain controllers, and application servers.

Then came the persistence, and this is the part that should change how you think about containment. Rather than dropping a bespoke backdoor, the actor pushed six legitimate remote access tools onto reachable endpoints: AnyDesk, TacticalRMM, TeamViewer, RustDesk, SimpleHelp, and HopToDesk. They also installed the legitimate Cloudflare Tunnel client and renamed it to look like a Microsoft updater (MicrosoftEdgeUpdate64.exe, msmp.exe, and in a related case conhost.exe), giving persistent outbound access that blends into ordinary update traffic. Accounts were created, admin passwords were reset, and an EDR-evasion driver was staged from a remote support tool's own ProgramData directory to terminate the security vendor's scanner process.

Now count the malware. Almost none until the very end. Count the legitimate products. Seven or more, all of which could plausibly exist in a real IT estate.

Two lessons fall out of it.

First, patching closed the entry point and changed nothing about the six independent ways back in. If your response to a management platform advisory is "hotfix applied, ticket closed", you may have locked the front door while the attacker holds keys to the side entrances.

Second, notice who caught it. The vendor's own account of the incident says the original zero-day exploitation was spotted on July 31 by managed detection and response monitoring in a customer environment, in real time, before a CVE existed. Not a signature. Not a patch. Someone watching behaviour and deciding it was wrong.

The prevention ceiling#

I want to be precise here, because "prevention is dead" is a lazy take and it is wrong. Prevention is the single highest-return thing you can spend on. Phishing-resistant MFA, patched internet-facing systems, removed standing admin, blocked categories of routinely abused tooling, hardened RMM access, retained logs: those measures stop entire classes of attack from ever needing a human response, which is cheaper than any incident.

The honest framing is that prevention has a ceiling, and grey zone tradecraft is built to operate above it.

• You cannot block your way out of dual-use. powershell.exe, curl.exe, RDP, WMI, and your RMM agent stay.
• Individual events are innocent. Only the sequence, actor, timing, and target reveal intent, and that requires correlation across identity, endpoint, network, and cloud.
• Valid credentials produce successful authentications, not failures.
• BYOVD can neutralise the sensor that was supposed to be your safety net.
• Detection engineering that pattern-matches single techniques gets outpaced. Chained LOLBins and newer utilities slip through rules written for certutil and Squiblydoo.
• Someone still has to decide. Every high-fidelity grey zone detection ends in an ambiguous alert that a human has to adjudicate with business context: was that admin meant to be in that server at 02:00?

That last point is the crux. Technology can surface the ambiguity. It cannot resolve it. An alert that says "unusual remote execution to a domain controller from an admin account" is not a verdict, it is a question. If nobody is on shift to answer it, the tooling worked and the attack still succeeded.

The clock is the argument#

The timing data is where the MDR case stops being philosophical.

Median dwell time in that 661-case dataset sat at three days, driven partly by attackers accelerating and partly by defenders detecting faster. Split by case origin, the difference is stark: all-cause MDR cases had a median dwell time of two days, versus five days for incident response cases, and non-ransomware IR cases ran to six. Once inside, attackers reached the Active Directory server in about 3.4 hours. Other vendor telemetry puts hands-on-keyboard breakout time at roughly half an hour, with outliers measured in seconds.

Then the part that decides whether your staffing model is a strategy or a hope: 88% of ransomware deployments and 79% of data exfiltration happened outside normal business hours, with the four busiest hours between 11pm and 3am, accounting for over a third of observed attack starts.

Put the two facts next to each other. Attackers reach your identity crown jewels in a few hours, they act deliberately at 1am on a Sunday, and the median gap between intrusion and detection is measured in days. A business-hours SOC, or an IT team with security as a side quest, is structurally unable to close that gap. The attacker chose the window precisely because you are not in it.

What MDR actually adds#

Strip the marketing and managed detection and response is four capabilities that grey zone attacks specifically require.

1. Continuous human watch. Not "we get alerts". Someone is looking at 2am on a bank holiday, because that is when it happens.

2. Context and correlation. A grey zone verdict needs identity signals, endpoint telemetry, network egress, cloud audit logs, and knowledge of what normal looks like in your estate, stitched into one narrative. certutil downloading a file is a shrug. certutil downloading a file two minutes after an unusual sign-in from a new ASN, on a server that never runs it, followed by a scheduled task, is an incident.

3. Threat hunting for the absence of evidence. Grey zone intrusions do not generate a satisfying IOC to search for. Hunting has to be hypothesis led: which hosts have a renamed tunnelling client, which endpoints gained a second RMM agent this month, which service accounts started interactive logons, which admin sessions cluster outside change windows.

4. Authority and the ability to act. Detection without response is a very expensive alarm. The reason the MDR dwell time is lower is not just faster noticing, it is faster containment: isolate the host, revoke the sessions, disable the account, kill the tunnel, before ransomware deployment becomes the next step.

None of that replaces the prevention stack. It sits on top of it and covers the ceiling. Prevention decides how many attacks need a human. Detection and response decides what happens to the ones that do.

What I would do about it#

Practical, in rough order of value.

Prevention that raises the floor

• Phishing-resistant MFA everywhere it fits, and validate the configuration rather than trusting the checkbox.
• Kill standing privilege. Just-in-time admin, separate admin identities, no domain admin for daily work.
• Reduce internet exposure of identity and management surfaces. RMM consoles, RDP gateways, and VPN portals should not be casually reachable.
• Block or tightly control categories that are routinely abused and rarely needed. Python on non-developer workstations is a good example given Impacket's dependency on it.
• Approve remote access tooling explicitly. One RMM, one remote support tool, documented. Everything else is an alert by definition.

Visibility that makes judgement possible

• Turn on and retain the telemetry that grey zone detection needs: PowerShell script block logging, process creation with command lines, Windows security logs, identity provider sign-in and audit logs, DNS and egress. Missing telemetry is a recurring theme in incident reports for a reason.
• Baseline your own administration. You cannot spot abnormal admin behaviour if nobody wrote down what normal looks like.
• Extend coverage to macOS and Linux rather than assuming Windows parity is enough.

Detection and response that closes the gap

• Get 24/7 coverage. Staff it or buy it, but stop pretending an unmonitored 1am is acceptable risk when the data says 1am is peak.
• Write detections for sequences and context, not single binaries.
• Agree containment authority in advance. If your analyst has to wait for a change board to isolate a host at 3am, you have not bought response, you have bought notification.
• Hunt monthly for the specific artefacts of grey zone persistence: unexpected RMM agents, renamed tunnelling clients, new local admins, odd scheduled tasks and services, suspicious kernel drivers loaded from user-writable directories.
• After any management platform advisory, treat it as a compromise assessment, not just a patch. Assume persistence was established before you patched.

Closing#

The grey zone is not a clever new attack technique. It is a strategic realisation by attackers that trust is easier to borrow than to break. Use the binaries you found, the admin tools IT already deployed, the credentials that already work, the SaaS platforms already allow-listed, and the hours nobody is watching.

Against that, "we have a good stack" is an incomplete answer. Prevention narrows the ways in and shrinks the blast radius, and it remains the best money in security. But the residual risk after prevention is almost entirely made of legitimate things being used illegitimately, and resolving that ambiguity is a human, continuous, contextual job.

That is the case for managed detection and response, and it is not really a product argument. It is arithmetic. Attackers get to your directory in hours, work while you sleep, and leave nothing obviously malicious behind. If nobody is watching at 2am with enough context to make a call and enough authority to pull the plug, the grey zone stays theirs.

References#

Sources and further reading for the claims above.

• Sophos X-Ops, 2026 Active Adversary Report (661 IR and MDR cases)
• Sophos X-Ops, N-able N-central exploitation results in RMM tool deployment
• N-able, N-central security update and indicators of compromise
• Help Net Security, Attackers exploit N-able N-central flaw (CVE-2026-18577)
• Cisco Talos, Bad Apples: weaponizing native macOS primitives
• LOLBAS Project, living off the land binaries, scripts and libraries
• GTFOBins, the Unix equivalent for living off the land
• MITRE ATT&CK T1218, System Binary Proxy Execution
• MITRE ATT&CK T1078, Valid Accounts
• MITRE ATT&CK T1219, Remote Access Tools
• CISA, PRC state-sponsored actors living off the land (Volt Typhoon advisory)
• CISA, Known Exploited Vulnerabilities catalog
• CrowdStrike, Global Threat Report (malware-free intrusion data)
• Red Canary, Threat Detection Report (most observed techniques)