De Amerikaanse Cybersecurity and Infrastructure Security Agency (CISA) publiceerde de uitkomsten van twee red team-assessments die gelijktijdig werden uitgevoerd bij twee organisaties in kritieke sectoren. Hoewel het red team werkte met vergelijkbare technieken, waren de verdedigingsresultaten opvallend verschillend. Juist dat contrast maakt het rapport zo bruikbaar: het laat zien hoe belangrijk mensen, processen en zichtbaarheid zijn voor daadwerkelijke detectie.
In de advisory, met referentie AA26-237A en de titel “A Tale of Two SOCs”, bespreekt CISA hoe beide organisaties op domeinniveau volledig werden gecompromitteerd. Toch werd de ene organisatie later getroffen dan de andere—en in één geval bleef de activiteit vrijwel volledig onopgemerkt. Daarmee draait de kernvraag om: hoe werkt een SOC als de tooling wel aanwezig lijkt, maar de samenhang ontbreekt?
Wat CISA met de red team-tests wilde aantonen
Volgens CISA voerde het team twee assessments tegelijk uit, met “similar tradecraft” (vergelijkbare aanvalsmethode). Beide doelen werden op domeinniveau volledig gecompromitteerd. Daarnaast raakte het red team gevoelige bedrijfssystemen (SBSs) en cloudresources. Kortom: de aanvallen werden niet gestopt voordat ze konden doorstoten; de verschillen ontstonden in de detectie en respons.
De eerste target (organisatie A) valt onder de Government Services and Facilities Sector. De tweede target (organisatie B) valt onder de Water and Wastewater Systems Sector.
Organisatie A: volledig binnen, maar geen signalen die iets deden
Bij organisatie A begon de toegang via een webapplicatie met standaard- of default credentials voor een set ingebouwde accounts. Daarmee kon het red team phishing e-mails versturen vanuit een intern adres en uiteindelijk landen op vier werkstations.
Daarna volgde privilege escalation. CISA noemt daarbij twee belangrijke knelpunten: een default Machine Account Quota (waardoor elke domeingebruiker machine accounts kon toevoegen) en een verkeerd geconfigureerde Active Directory Certificate Services (AD CS) certificate template. De combinatie leverde een route op voor het misbruiken van certificaataanvragen—een type aanval dat in het rapport wordt gelinkt aan de ESC1-categorie.
Vervolgens bereikte het team drie gevoelige bedrijfssystemen door credentials te gebruiken die in cleartext waren opgeslagen. CISA noemt expliciet gedecrypteerde database-configuratiebestanden en bovendien statische AWS-toegangssleutels die nooit verlopen. In de cloud stal het red team daarnaast een Primary Refresh Token.
Ook misbruikte het team Entra ID-applicaties met hogere rechten. Daarmee kon het team de e-mail van het security-team lezen en controleren of verdedigers de activiteit al hadden opgemerkt. Ondanks die zichtbare impact stelt CISA dat organisatie A het geheel niet detecteerde.
Waarom niet? Volgens CISA werden de meldingen overschaduwd door “thousands of false-positive alerts” die voortkwamen uit normale bedrijfsprocessen. Veel van die meldingen hadden bovendien een hogere severity dan de signalen die het red team genereerde. Daarnaast werkte de organisatie met meerdere SOC’s en endpoint-tools die volgens CISA geen gedeelde visibility hadden. Ook waren escalatieprocedures niet op orde en had het securityteam beperkte bevoegdheden om direct actie te ondernemen. Een echt relevante alert op een System Center Configuration Manager (SCCM)-server werd als false positive terzijde geschoven, omdat verdedigers niet konden achterhalen van wie het systeem was.
De fouten die CISA als “enablers” ziet bij organisatie A
CISA noemt de volgende zwakheden als belangrijkste factoren waardoor de aanval bij organisatie A door kon gaan:
- Machine Account Quota stond standaard: elke domeinuser kon machine accounts toevoegen.
- AD CS certificate templates waren verkeerd geconfigureerd, waardoor certificate requests mogelijk waren voor elke gebruiker (ESC1).
- Cleartext credentials voor service- en databaseaccounts stonden op bereikbare systemen.
- Statische cloud access keys liepen nooit af en token-revocation was niet ingericht.
- Over-permissioned Entra ID-applicaties konden e-mail lezen over alle gebruikers heen.
Organisatie B: dezelfde route, maar snelle insluiting
Bij organisatie B zag CISA een ander verdedigingsbeeld terwijl het red team een vergelijkbare insteek gebruikte. Het SOC herkende de phishing payloads op het moment dat ze werden uitgevoerd. Vervolgens werden de getroffen werkstations binnen 2 tot 20 minuten geïsoleerd. Daardoor werd command-and-control (C2) afgekapt voordat de dreiging zich verder kon verspreiden.
Doordat de foothold werd onderbroken, verschoof het engagementmodel. CISA beschrijft dat CISA’s trusted agents toen een red team payload op een aangewezen niet-privileged host uitvoerden, om toegang te repliceren die het team anders via de initiële keten had verkregen. Met andere woorden: de aanval werd niet “over dezelfde lijn” verder uitgerold, maar opnieuw gecontroleerd getest.
Ook bij organisatie B kwam het red team dezelfde onderliggende problemen tegen. CISA noemt onder meer cleartext credentials voor een domein serviceaccount in een SCCM-configuratiebestand, met rechten die doorliepen tot over de domeincontroller. Met die rechten kon het red team een DCSync-aanval doen en het krbtgt-geheim ophalen.
Daarbij bereikte het team ook een bastion host in de OT (Operational Technology) demilitarized zone. Deze host blokkeerde echter outbound internettoegang, waardoor er geen C2-kanaal tot stand kwam. Het red team ging bovendien niet de OT-systemen zelf in.
Waarom het verschil ontstond: mensen en procedures, niet de tooling
Een belangrijke conclusie van CISA is dat het gat tussen beide uitkomsten niet primair aan de aanvalstechnieken lag. CISA schrijft dat het verschil te maken had met de mensen en processen rond de ingezette tools.
Daarmee komt het rapport neer op een praktische les: detection tools zijn alleen effectief wanneer processen en verantwoordelijkheden goed aansluiten. Als meldingen verdrinken in ruis, als visibility versnipperd is, of als niemand bevoegd is om door te pakken, dan kan zelfs “veel data” toch leiden tot weinig echte detectie.
Wil je dit vertalen naar je eigen omgeving? Dan helpt het om te onderzoeken of je SOC-inrichting voorkomt dat alerts verdampen. In het verleden zijn er bij vergelijkbare thema’s al concrete issues besproken, zoals hoe je SOC-bewijs bouwt in situaties waar niet alles direct als alertqueue verschijnt—zie bijvoorbeeld het artikel over AI SOC zonder alertqueue: van backlog naar bewijs.
Wat je nu kunt doen: lessen uit twee SOC’s
Het rapport is geen checklist “koop tool X en klaar”. Het is eerder een lens op je verdediging: kun je snel herkennen, goed escaleren, en acties uitvoeren zonder dat je organisatie vastloopt in false positives of organisatorische frictie?
1) Verminder ruis en maak signalen herkenbaar
Organisatie A verloor volgens CISA het overzicht door duizenden false positives uit normale bedrijfsactiviteiten. Het is dus niet genoeg om detectie te hebben; je moet ook zorgen dat teams snel onderscheid kunnen maken tussen “drukte” en “dynamiek die er echt toe doet”.
2) Zorg voor gedeelde visibility tussen SOC’s en endpointtools
Bij organisatie A waren meerdere SOC’s en endpointtools zonder gedeelde zichtbaarheid. Dat betekent dat vergelijkbare gebeurtenissen elkaar niet versterken. Maak daarom duidelijk waar data naartoe gaat, wie het bekijkt en hoe context wordt samengebracht.
3) Maak escalatieprocedures praktisch en test ze
CISA noemt dat er bij organisatie A geen adequate escalatieprocedures waren en dat de autoriteit om te handelen beperkt was. Dat is precies het soort organisatiekenmerk dat incidentrespons vertraagt. Probeer escalatieroutes daarom te oefenen in tabletop- of red team-oefeningen.
4) Reageer op de eerste stap: insluiting wint
Organisatie B liet zien dat isoleren van werkstations na herkenning van phishing in korte tijd C2 kan afknijpen. Het lijkt eenvoudig, maar het vraagt om duidelijke playbooks en korte lijntjes binnen het SOC.
5) Let op identiteits- en credential-risico’s
Beide organisaties werden kwetsbaar door dezelfde klassen problemen: default configuraties (zoals machine account quotas), misbruikbare certificate templates (AD CS) en credentials die in cleartext of als statische keys beschikbaar waren. Ook permissies in Entra ID speelden mee. Het is dus verstandig om gericht te kijken naar identiteit, certificaatconfiguraties en de manier waarop secrets worden opgeslagen.
Als je meer wilt lezen over het belang van correct geconfigureerde identity en misconfiguraties in de keten, dan sluit dit onderwerp ook aan bij eerdere analyses zoals MFA-valkuil: authenticatie is geen identiteit.
Conclusie: twee SOC’s, één duidelijke boodschap
De case “A Tale of Two SOCs” laat zien dat een SOC niet alleen wordt gebouwd met detectietools. De uitkomst wordt bepaald door de aansluiting tussen detectie, respons en organisatieprocessen. Organisatie A kwam volgens CISA vrijwel volledig door de aanval heen zonder dat signalen effectief werden opgepakt, mede door false positives, versnipperde visibility en zwakke escalatie.
Organisatie B daarentegen herkende de dreiging sneller en isoleerde getroffen systemen binnen minuten, waardoor verdere verspreiding werd voorkomen. Voor organisaties die hun weerbaarheid willen verbeteren betekent dit: investeer niet alleen in meer logging of meer alerts, maar vooral in betere samenhang, heldere procedures en snelle insluiting. Dat is hoe je van “alerts zien” naar “incidenten stoppen” gaat.
Bron: https://thehackernews.com/2026/08/cisa-red-team-compromised-two-critical.html
