A l'agost, un investigador d'Akamai va ensenyar a la DEF CON 34 com agafar un EDR comercial —dels grans, dels que es compren per estar tranquil— i convertir-lo en l'amagatall de l'atacant. La part que es va endur els titulars va ser el bolcat de memòria. La que t'hauria de treure la son és el final de l'informe: una línia de text en un fitxer deixa l'agent mostrant «SECURE» mentre la teva consola deixa de rebre absolutament res.
El que Akamai va trobar
La recerca és de Shahak Morag, de l'equip de seguretat d'Akamai, es va presentar a la DEF CON 34 i es va publicar al blog de recerca de la companyia el 7 d'agost del 2026. L'objecte d'estudi va ser l'agent de SentinelOne, i el punt de partida són tres objectes COM que el producte exposa a la màquina: SentinelHelper.1, SentinelUI.1 i SentinelAgent.1.
Dins del primer hi ha un mètode amb una signatura molt poc tímida: Dump(uint processId, string userDumpPath, string kernelDumpPath). Li passes un PID i t'escriu el bolcat de memòria d'aquell procés on li diguis. El detall important: aquest mètode corre com a procés protegit (PPL) però només comprova que qui truca sigui administrador local. No valida des d'on se l'està cridant. Resultat: qualsevol administrador local pot bolcar la memòria de qualsevol procés protegit de la màquina —inclòs el mateix Microsoft Defender— sense driver maliciós i sense cap error del sistema operatiu.
El motiu que falti aquesta validació és el més humà de l'informe. La resta de funcions sí que comproven que qui truca sigui dins del directori d'instal·lació del producte; aquesta no, i Akamai ho lliga a un script de diagnòstic propi, DiagnosticsCollector.ps1, que s'executa sota l'intèrpret de PowerShell i per tant des d'un altre directori. Una necessitat legítima de suport que va acabar deixant una porta oberta. Gairebé totes comencen així.
SentinelOne va corregir el que es va reportar a la versió 26.1.1 de l'agent. Si això fos tot, aquest post seria un avís de pedaç de tres línies i s'acabaria aquí. No ho és.
La segona meitat: instal·lar el teu propi EDR i treure-li el micròfon
L'instal·lador de l'agent valida el site token —la cadena que diu a quin inquilí pertany aquella màquina— amb una funció anomenada VerifyRegistrationSecret. Els investigadors li van passar un JSON codificat en Base64 amb aquest contingut:
{
"url": "http://127.0.0.1:8888/",
"site_key": "abc123xyz"
}
La instal·lació es va completar sense que hi hagués cap servidor escoltant al 8888 i sense una clau de lloc vàlida. L'agent resultant no funciona —no protegeix res— però es mostra en «SECURE». Un EDR de mentida, signat, corrent amb privilegis de procés protegit, i amb el llumet verd posat.
I l'últim pas, que és el que de veritat importa per a qui opera un parc. Un altre mètode COM, GetAgentStatusJSON, retorna entre altres coses el camp mgmt-url: l'adreça de la consola a la qual aquell agent reporta. Amb aquesta dada, l'atacant escriu una línia a C:\Windows\System32\drivers\etc\hosts resolent aquella adreça a 127.0.0.1. Akamai ho descriu sense adorns: això bloqueja tota la telemetria sense afectar l'aparença que l'agent és en estat protegit.
Hem escrit aquí sobre atacants que apaguen l'EDR reiniciant en mode segur. Allò, si més no, es nota: l'agent deixa de ser-hi. Això és el contrari i és pitjor. L'agent continua allà, signat, en verd, ocupant la seva casella al teu informe de cobertura. Simplement ha deixat de parlar amb tu.
Els dos senyals no valen el mateix
Aquí hi ha, per a nosaltres, la lectura útil de tot això, i va molt més enllà d'un producte concret. Quan algú ens ensenya com controla la seguretat del seu parc, gairebé sempre ens ensenya senyals de presència: l'agent està instal·lat, el procés corre, l'estat diu protegit, la cobertura surt sencera en verd. Tots aquests senyals neixen a l'endpoint. I qui té administrador local a l'endpoint els controla.
Hi ha un senyal que no neix allà: l'absència. Que la teva consola porti tres dies sense rebre ni un sol esdeveniment d'una màquina concreta és un fet que passa a la teva consola, no a la màquina. L'atacant pot falsificar el que l'agent diu d'ell mateix; no pot fabricar trànsit que mai no arriba. És l'únic senyal de tota aquesta cadena que continua sent teu després que et comprometin l'endpoint.
Dit d'una altra manera: «EDR desplegat al 100 % del parc» descriu un inventari, no un control de seguretat. Mesura quants agents es van instal·lar; no diu res sobre quants continuen parlant amb tu.
El llindar que vas configurar és la finestra que vas concedir
Tota consola d'EDR té, en alguna pestanya, un ajust del tipus «avisar si un agent porta N dies sense reportar». Aquell número no és un paràmetre d'higiene. És un contracte: és exactament el temps que has acceptat estar cec sobre una màquina. Si tens 7 dies per a portàtils, has signat 7 dies.
I sabem per què està alt: pels falsos positius. Un portàtil de vacances i un portàtil silenciat es veuen exactament igual a la consola, i ningú no vol una alerta cada agost. Per això la solució no és abaixar el llindar global —això només produeix fatiga d'alertes—, sinó separar el llindar per classe d'actiu:
- ✓Un servidor que calla trenta minuts no és un servidor de vacances. És un incident, i el llindar s'hauria de mesurar en minuts.
- ✓Un portàtil callat que dóna altres senyals de vida —el seu usuari obre el correu, entra per VPN, agafa una IP a l'oficina— és la combinació que de veritat importa. Silenci a l'EDR més activitat en qualsevol altre sistema és un incident, i aquesta correlació no la fa cap consola tota sola.
- ✓Un portàtil callat i sense cap altre senyal a l'agost probablement sigui en un calaix. Aquest és el cas que justifica el llindar llarg, i és l'únic.
El més barat de detectar és al final de la cadena
Val la pena mirar aquesta cadena pel seu cost. Entendre els objectes COM, els processos protegits i la signatura de codi és feina d'investigador. Falsificar el site token requereix haver llegit l'instal·lador. Però el pas que et deixa cec —el que converteix un compromís en una setmana de barra lliure— és escriure una línia de text en un fitxer. I aquell fitxer té un hash i una data de modificació.
Vigilar la integritat de hosts és un control que ja ve en qualsevol EDR i en qualsevol RMM decent, no costa llicència, gairebé no genera soroll —tret de màquines de desenvolupament, on entre clients de VPN i entorns de contenidors sí que es toca, aquell fitxer es queda quiet— i als parcs que revisem gairebé mai no està activat. Amb honestedat: no és una bala de plata. Qui té administrador pot desviar el trànsit per altres llocs (un servidor DNS local, una regla de tallafocs). Però és el moviment més barat per a l'atacant, i per això és la detecció més barata per a tu. Comença per aquí.
El que mirem nosaltres
Quan revisem l'EDR d'un client, aquestes sis coses surten abans que la marca de l'agent:
- 1Alerta per absència de telemetria, amb llindar diferent per classe d'actiu. Si el número és a la configuració per defecte, aquell és el teu temps de ceguesa acceptat.
- 2Reconciliació d'inventaris. La llista de màquines de la consola de l'EDR contra una altra font independent: el directori, el gestor de dispositius, l'RMM, les concessions de DHCP. L'interessant mai no és la coincidència; són les diferències en els dos sentits.
- 3Alerta quan apareix un agent nou amb un grup o un token de lloc que no reconeixes. Una alta d'agent hauria de ser un acte administratiu amb nom i cognoms, no un esdeveniment rutinari que ningú no llegeix.
- 4Integritat del fitxer
hostsen servidors i en llocs de treball. Barat, silenciós i directament relacionat amb el que acabem d'explicar. - 5Un terra de versió de l'agent escrit com a política, no com a sensació. En aquest cas concret, 26.1.1. «Està actualitzat» no és una resposta; «cap màquina per sota de X, i aquestes tres ho estan» sí que ho és.
- 6Algú que miri la consola. Una alerta d'absència que salta un dissabte a les tres de la matinada i espera fins dilluns és, per a l'atacant, la mateixa alerta que no existeix.
Els cinc primers són configuració, no projecte: el segon porta la seva feina en un parc gran, però cap no necessita que ningú aprovi un pressupost. El sisè és el que separa un EDR comprat d'un EDR/MDR gestionat, i és el que gairebé mai no està resolt. La detecció sense ningú al darrere acaba sent un registre històric: serveix per reconstruir el que va passar, no per evitar-ho.
El que no direm
- ✗No direm que aquest producte sigui dolent ni que calgui canviar de fabricant. Akamai va triar un agent gran perquè és on la troballa té valor, el fabricant ho va corregir, i el mateix informe enquadra el problema com de disseny de la categoria: interfícies locals, lògica d'instal·lador i autoprotecció insuficientment endurides. Cap d'aquestes cadenes no s'atura comprant un altre agent.
- ✗No direm que això sigui un 0-day remot. Cal administrador local, i això és una barrera real que convé dir en veu alta. El que descriu Akamai passa després que algú hagi entrat, i aquí és on es decideix si un incident et costa una tarda o una setmana.
- ✗No hem reproduït això al laboratori. El que expliquem és el que publica Akamai, llegit amb el criteri de qui opera parcs aliens. Si algun dia ho muntem, ho explicarem amb els nostres propis números.
La pregunta que deixa l'informe
La primera meitat de la troballa es tanca amb un pedaç: actualitzes a 26.1.1 i aquella porta concreta queda tancada. La segona no es tanca del tot amb cap versió, perquè descriu el que passa quan qualsevol amb administrador local pot instal·lar programari de seguretat i decidir a quina consola parla. Això no es pedaça, es governa.
Així que la pregunta amb què ens quedem no és «tens EDR?». És aquesta altra: si una de les teves màquines deixés de reportar ara mateix, quant trigaria algú a assabentar-se'n, i aquest algú té nom? Si la resposta comença per «bé, suposo que saltaria alguna cosa», ja saps per on començar.
Fonts (verificades): «Bring Your Own EDR: How to Turn a Commercial EDR into a Trojan Horse», Shahak Morag, blog de recerca de seguretat d'Akamai, 7 d'agost del 2026 — objectes COM SentinelHelper.1, SentinelUI.1 i SentinelAgent.1, signatura del mètode Dump, l'script DiagnosticsCollector.ps1, la validació de VerifyRegistrationSecret, el camp mgmt-url de GetAgentStatusJSON, la redirecció pel fitxer hosts i la correcció a la versió 26.1.1 de l'agent: akamai.com. Presentat a la DEF CON 34 (Las Vegas, 6-9 d'agost del 2026, dates segons defcon.org). Els llindars, la separació per classe d'actiu i el criteri de detecció per absència són lectura nostra, no de l'informe.
Sabries dir quantes de les teves màquines porten una setmana sense reportar?
A everyWAN operem EDR/MDR gestionat i monitoratge 24/7 per a empreses que no tenen —ni volen tenir— algú mirant una consola de matinada. Revisem llindars, reconciliem inventaris i posem nom a qui respon.
Microsoft 365
ES 
CAT 
EN