In August, an Akamai researcher showed at DEF CON 34 how to take a commercial EDR —one of the big ones, the kind you buy so you can sleep at night— and turn it into the attacker's hiding place. The memory dump got the headlines. The part that should keep you up is the end of the report: one line of text in one file leaves the agent showing "SECURE" while your console stops receiving anything at all.
What Akamai found
The research is by Shahak Morag of Akamai's security team, presented at DEF CON 34 and published on the company's research blog on 7 August 2026. The subject was the SentinelOne agent, and the starting point is three COM objects the product exposes on the machine: SentinelHelper.1, SentinelUI.1 and SentinelAgent.1.
Inside the first one there is a method with a distinctly unshy signature: Dump(uint processId, string userDumpPath, string kernelDumpPath). You hand it a PID and it writes that process's memory dump wherever you tell it. The important detail: the method runs as a protected process (PPL) but only checks that the caller is a local administrator. It does not validate where it is being called from. The result: any local admin can dump the memory of any protected process on the machine —including Microsoft Defender itself— with no malicious driver and no operating system bug.
The reason that validation is missing is the most human part of the report. The other functions do check that the caller sits inside the product's installation directory; this one does not, and Akamai ties that to the product's own diagnostics script, DiagnosticsCollector.ps1, which runs under the PowerShell interpreter and therefore from a different directory. A legitimate support need that ended up leaving a door open. Almost all of them start that way.
SentinelOne fixed what was reported in agent version 26.1.1. If that were all, this post would be a three-line patching notice and would end here. It isn't.
The second half: install your own EDR and take away its microphone
The agent installer validates the site token —the string that says which tenant a machine belongs to— with a function called VerifyRegistrationSecret. The researchers fed it a Base64-encoded JSON with this content:
{
"url": "http://127.0.0.1:8888/",
"site_key": "abc123xyz"
}
The installation completed with no server listening on 8888 and no valid site key. The resulting agent does not work —it protects nothing— but it displays "SECURE". A fake EDR, signed, running with protected-process privileges, with the little green light on.
And the last step, which is the one that really matters if you run a fleet. Another COM method, GetAgentStatusJSON, returns among other things the mgmt-url field: the address of the console that agent reports to. With that, the attacker writes one line into C:\Windows\System32\drivers\etc\hosts resolving that address to 127.0.0.1. Akamai puts it plainly: this blocks all telemetry while not affecting the agent's appearance as being in a protected state.
We have written here about attackers who switch the EDR off by rebooting into safe mode. That, at least, shows: the agent stops being there. This is the opposite, and it's worse. The agent is still there, signed, green, filling its box in your coverage report. It has simply stopped talking to you.
The two signals are not worth the same
Here is, for us, the useful reading of all this, and it goes well beyond one product. When someone shows us how they keep track of security across their fleet, they almost always show us presence signals: the agent is installed, the process is running, the status says protected, coverage comes back all green. Every one of those signals originates on the endpoint. And whoever has local admin on the endpoint controls them.
There is one signal that does not originate there: absence. The fact that your console has gone three days without a single event from a given machine happens in your console, not on the machine. An attacker can fake what the agent says about itself; they cannot fabricate traffic that never arrives. It is the only signal in this entire chain that is still yours after the endpoint is compromised.
Put another way: "EDR deployed across 100% of the fleet" describes an inventory, not a security control. It measures how many agents were installed; it says nothing about how many are still talking to you.
The threshold you configured is the window you granted
Every EDR console has, on some tab, a setting along the lines of "alert if an agent has not reported for N days". That number is not a hygiene parameter. It is a contract: it is exactly how long you have agreed to be blind about a machine. If it is 7 days for laptops, you signed for 7 days.
And we know why it is set high: false positives. A laptop on holiday and a silenced laptop look exactly the same in the console, and nobody wants an alert every August. That is why the answer is not to lower the global threshold —that just produces alert fatigue— but to split the threshold by asset class:
- ✓A server that goes quiet for thirty minutes is not a server on holiday. It is an incident, and the threshold should be measured in minutes.
- ✓A quiet laptop that shows other signs of life —its user opens email, connects over VPN, picks up an IP in the office— is the combination that actually matters. Silence in the EDR plus activity anywhere else is an incident, and no single console makes that correlation on its own.
- ✓A quiet laptop with no other signal at all in August is probably in a drawer. That is the case that justifies the long threshold, and it is the only one.
The cheapest thing to detect is at the end of the chain
It is worth looking at this chain by cost. Understanding COM objects, protected processes and code signing is researcher work. Forging the site token requires having read the installer. But the step that blinds you —the one that turns a compromise into a week of open bar— is writing one line of text into a file. And that file has a hash and a modification date.
Monitoring the integrity of hosts is a control that already ships with any EDR and any decent RMM, costs no licence, generates almost no noise —except on developer machines, where VPN clients and container tooling do write to it, that file sits still— and on the fleets we review it is almost never switched on. In fairness: it is not a silver bullet. Anyone with admin rights can redirect traffic elsewhere (a local DNS server, a firewall rule). But it is the cheapest move for the attacker, which is exactly why it is the cheapest detection for you. Start there.
What we look at
When we review a client's EDR, these six things come up before the brand of the agent does:
- 1Alerting on missing telemetry, with a different threshold per asset class. If the number is still at its default, that is your accepted blind time.
- 2Inventory reconciliation. The machine list in the EDR console against an independent source: the directory, the device manager, the RMM, DHCP leases. What matters is never the overlap; it is the differences, in both directions.
- 3Alert when a new agent appears with a group or site token you do not recognise. Registering an agent should be an administrative act with a name attached, not a routine event nobody reads.
- 4Integrity monitoring on the
hostsfile, on servers and on workstations. Cheap, quiet and directly related to what we just described. - 5A minimum agent version written down as policy, not as a feeling. In this specific case, 26.1.1. "It's up to date" is not an answer; "no machine below X, and these three are" is.
- 6Someone actually watching the console. An absence alert that fires at three in the morning on a Saturday and waits until Monday is, from the attacker's point of view, identical to an alert that does not exist.
The first five are configuration, not a project: the second one is real work on a large fleet, but none of them needs anyone to sign off a budget. The sixth is what separates a purchased EDR from a managed EDR/MDR, and it is the one that is almost never solved. Detection with nobody behind it ends up as a historical record: it helps you reconstruct what happened, not prevent it.
What we are not going to say
- ✗We are not going to say this product is bad or that you should switch vendors. Akamai picked a major agent because that is where the finding has value, the vendor fixed it, and the report itself frames the problem as one of category design: locally reachable interfaces, installer logic and self-protection that were not hardened enough. None of these chains stops by buying a different agent.
- ✗We are not going to say this is a remote 0-day. It requires local admin, and that is a real barrier worth stating out loud. What Akamai describes happens after someone is already inside, and that is where it gets decided whether an incident costs you an afternoon or a week.
- ✗We have not reproduced this in a lab. What we describe is what Akamai published, read with the judgment of people who run other companies' fleets. If we ever build it, we will tell you with our own numbers.
The question the report leaves behind
The first half of the finding closes with a patch: you upgrade to 26.1.1 and that particular door is shut. The second half does not fully close with any version, because it describes what happens when anyone with local admin can install security software and decide which console it talks to. That does not get patched, it gets governed.
So the question we are left with is not "do you have EDR?". It is this one: if one of your machines stopped reporting right now, how long would it take someone to notice, and does that someone have a name? If the answer starts with "well, I suppose something would fire", you already know where to start.
Sources (verified): "Bring Your Own EDR: How to Turn a Commercial EDR into a Trojan Horse", Shahak Morag, Akamai security research blog, 7 August 2026 — the COM objects SentinelHelper.1, SentinelUI.1 and SentinelAgent.1, the Dump method signature, the DiagnosticsCollector.ps1 script, the VerifyRegistrationSecret validation, the mgmt-url field from GetAgentStatusJSON, the hosts file redirection and the fix in agent version 26.1.1: akamai.com. Presented at DEF CON 34 (Las Vegas, 6-9 August 2026, dates per defcon.org). The thresholds, the per-asset-class split and the detect-by-absence argument are our reading, not the report's.
Could you say how many of your machines have not reported in a week?
At everyWAN we run managed EDR/MDR and 24/7 monitoring for companies that do not have —and do not want— someone staring at a console at 3 a.m. We review thresholds, reconcile inventories, and put a name to whoever responds.
Microsoft 365
ES 
CAT 
EN