Jordy HerberPassword spray klinkt als een oude aanval, maar ik zie dit vaak bij klanten: iedereen denkt dat MFA het probleem oplost en toch blijven er verdachte sign-ins, legacy protocolpogingen en succesvolle validaties opduiken. De aanval is niet verdwenen. De aanval is trager, meer gedistribueerd en beter vermomd geworden.
De oude SIEM-regel ‘meer dan vijf mislukte logins op één account’ is hier bijna waardeloos. Een moderne spray probeert één of twee wachtwoorden tegen veel accounts, wisselt IP-adressen, gebruikt cloudhosting en wacht lang genoeg om niet op te vallen. In Microsoft 365 ziet dit eruit als ruis. In de praktijk gaat dit vaak mis bij organisaties die alleen naar losse events kijken en niet naar gedrag over meerdere uren of dagen.
Deze herschreven blog gebruikt het Microsoft Digital Defense Report 2025 als dreigingscontext, maar vertaalt het vooral naar een Microsoft Security-aanpak die je kunt bouwen: Entra ID Protection, Conditional Access, Defender XDR en Sentinel KQL. Geen awareness-poster als hoofdoplossing, maar identity controls, logging en detectie die een SOC daadwerkelijk kan gebruiken.
| Praktijkopmerking: Ik zie dit vaak bij klanten: de tooling staat deels aan, maar de koppeling tussen identity, cloud, data en SOC-proces ontbreekt. Juist daar vallen moderne aanvallen doorheen. |
Diagram: conceptflow voor de blog
Onderstaand diagram kan als visuele basis in de blog worden gebruikt. Voor publicatie kun je dit vervangen door een eigen ITCowboys-visual of een Mermaid-render.
Waarom dit onderwerp nu speelt
Het MDDR 2025 laat zien dat password spray nog steeds een groot deel van identity-aanvallen bepaalt. Microsoft beschrijft dat een klein aantal ASNs verantwoordelijk is voor een groot deel van de schadelijke spray-activiteit. Dat is een belangrijk praktisch punt: blokkeren op één IP-adres is niet genoeg, maar ASN, hostingprovider, proxy-infrastructuur en gebruikersgedrag worden veel waardevoller.
Aanvallers combineren credential dumps, infostealerdata en OSINT. Ze hoeven niet meer te gokken met duizenden wachtwoorden. Ze testen een kleine set waarschijnlijke wachtwoorden tegen accounts die ze vooraf hebben geselecteerd. Denk aan finance, servicedesk, beheerders, mailboxen met gedelegeerde rechten en gebruikers met veel toegang tot SharePoint of Teams.
Mijn advies is om password spray niet als ‘mislukte login’ te behandelen, maar als eerste fase van een bredere identity kill chain. De echte vraag is niet alleen wie er faalde met aanmelden. De vraag is: wie werd getest, vanaf welke infrastructuur, is er later een succesvolle login, en welke data of applicatie is daarna geraakt?
Wat je moet weten: brute force is niet hetzelfde als password spray
Brute force concentreert veel pogingen op één account. Password spray concentreert één of enkele wachtwoorden op veel accounts. Die nuance bepaalt je detectieontwerp. Account lockout helpt tegen brute force, maar low-and-slow spray blijft vaak onder lockoutdrempels.
In Entra ID betekent dit dat je over meerdere assen moet correleren: IPAddress, UserPrincipalName, AppDisplayName, ResultType, UserAgent, Conditional Access status, RiskLevelDuringSignIn en tijdvensters. In Defender XDR kun je hetzelfde patroon vanuit IdentityLogonEvents, CloudAppEvents en incident-correlatie bekijken.
Dit klinkt klein, maar heeft impact op je SOC proces. Als je alle failures als losse alerts behandelt, verdrinkt het SOC. Als je ze groepeert op aanvalsinfrastructuur en vervolgens verrijkt met successen, risicosignalen en privilege, krijg je minder alerts en betere incidenten.
Architectuur: van identity logging naar incident
De basis begint bij logging. SigninLogs en AuditLogs moeten naar Microsoft Sentinel. Defender XDR moet identity- en cloudsignalen correleren. Entra ID Protection moet risk detections leveren. Zonder die basis zie je wel events, maar mis je de context.
De detectieflow bestaat uit vijf stappen: verzamel sign-ins, groepeer failures over tijd, zoek naar succesvolle login na spray, verrijk met user risk en privilege, en automatiseer de eerste response. Response hoeft niet meteen ‘account blokkeren’ te zijn. Je kunt starten met een incident, een tag, een risk review, een password reset voor specifieke gebruikers of een Logic App die de manager en SOC informeert.
Voor beheerders is de lat hoger. Admins moeten phishing-resistant MFA gebruiken, bij voorkeur FIDO2/passkeys of certificate-based authentication, afgedwongen via Conditional Access authentication strengths. Push-MFA met alleen goedkeuren is geen eindstation meer.
Configuratie in een Microsoft 365 E5 demo tenant
Klikpad: Microsoft Entra admin center > Protection > Conditional Access. Maak minimaal beleid voor MFA voor alle gebruikers, block legacy authentication en require phishing-resistant MFA voor privileged roles. Begin in Report-only, maar laat beleid niet maanden in Report-only staan. Dat zie ik te vaak.
Klikpad: Microsoft Entra admin center > Protection > Identity Protection. Controleer Risk detections, Risky users en Risky sign-ins. Let erop dat password spray-detectie niet elke mislukte poging toont, maar vooral relevant wordt wanneer Microsoft een succesvolle credential validation in je tenant ziet.
Klikpad: Microsoft Sentinel > Content hub > Microsoft Entra ID > Data connector. Stuur SigninLogs, AuditLogs en NonInteractiveUserSignInLogs naar je Log Analytics workspace. Voor Defender XDR gebruik je het Microsoft Defender portal en Advanced Hunting voor snelle hunting, en Sentinel voor rule lifecycle, incidentproces en SOAR.
Praktijkvoorbeeld: van ruis naar één bruikbaar incident
Stel je hebt in een tenant 7.000 gebruikers en je ziet op maandagochtend 1.300 mislukte aanmeldingen. De klassieke reactie is een alert op volume. Dat levert direct ruis op, want mobiele clients, verlopen wachtwoorden en oude Outlook-profielen veroorzaken ook failures. De betere aanpak is om eerst de verdeling te bekijken. Hoeveel unieke gebruikers zijn geraakt per IP? Hoeveel pogingen per gebruiker? Zijn er veel verschillende apps? Is er één ResultType dominant of wisselt het patroon?
Bij password spray wil je vooral de infrastructuur zien. Eén IP dat vijftig gebruikers test is interessant. Tien IP’s uit dezelfde hostingprovider die ieder vijf gebruikers testen is misschien nog interessanter. Als je ASN-data of IP reputation kunt toevoegen, wordt de detectie veel sterker. Dat kan via threat intelligence, watchlists of een enrichment-stap in Sentinel.
De escalatie komt pas echt wanneer er een succes volgt. Een succesvolle login vanaf dezelfde infrastructuur, dezelfde UserAgent of kort na dezelfde mislukte poging betekent dat de aanvaller waarschijnlijk een geldig wachtwoord heeft gevonden. Op dat moment moet de incidentseverity omhoog. Niet omdat de gebruiker per se volledig gecompromitteerd is, maar omdat de identity aantoonbaar bruikbaar is voor de aanvaller.
Een tweede escalatiecriterium is privilege. Een mislukte spray op een gewone gebruiker is vervelend. Een mislukte spray op een Application Administrator, Exchange Administrator of helpdeskaccount is belangrijker. Gebruik daarom een Sentinel watchlist voor privileged users en high-value groups. Daarmee voorkom je dat alle gebruikers hetzelfde gewicht krijgen.
Een derde criterium is downstream gedrag. Heeft de gebruiker na de verdachte login mailboxregels aangemaakt? Is er een OAuth-consent gegeven? Zijn er veel SharePoint-bestanden geopend? Dat is waarom identity-detectie gekoppeld moet worden aan OfficeActivity, AuditLogs en CloudAppEvents. Password spray is zelden het einddoel.
Niveau 400: tuning, edge cases en query-performance
Gebruik bij grote tenants niet direct dcount over enorme tijdvensters zonder filtering. Begin met ResultType != 0, beperk apps waar nodig en aggregeer per tijdvak. Daarna kun je joins doen met successen, risky sign-ins of watchlists. Als je te breed begint, wordt de query duur en traag, en belandt hij uiteindelijk niet als analytics rule in productie.
Let op serviceaccounts en gedeelde mailboxen. Sommige accounts genereren structureel vreemde patronen door oude clients of applicatiekoppelingen. De oplossing is niet om ze blind uit te sluiten. De oplossing is om ze te classificeren, legacy auth te verwijderen en uitzonderingen met einddatum te gebruiken. Elke permanente uitzondering wordt vroeg of laat een blinde vlek.
NonInteractiveUserSignInLogs zijn belangrijker geworden. Veel token- en clientgedrag zit niet in alleen interactieve SigninLogs. Als je alleen naar interactieve aanmeldingen kijkt, mis je refresh token patronen en sommige clientflows. Voor goede identity hunting wil je interactieve, non-interactieve en auditdata combineren.
Conditional Access-resultaten moeten onderdeel zijn van triage. Een failure waarbij CA de poging blokkeert is anders dan een failure vanwege fout wachtwoord. Een success waarbij CA niet is toegepast of waarbij een trusted location is gebruikt, verdient extra aandacht. Trusted locations kunnen nuttig zijn, maar worden gevaarlijk als ze brede uitzonderingszones worden.
Maak van de KQL-query niet automatisch een high severity alert. Begin met medium, gebruik entity mapping op account en IP, voeg custom details toe en schrijf duidelijke triage-instructies. SOC-analisten moeten binnen vijf minuten kunnen zien: wie is geraakt, waar kwam het vandaan, was er succes en welke response hoort erbij.
Voor response gebruik je bij voorkeur gestandaardiseerde stappen: revoke sessions, require password reset, user risk confirm compromised, temporary block sign-in indien nodig, en controle op mailboxregels en OAuth grants. Automatiseer alleen blokkeren wanneer je false-positive risico acceptabel is.
Implementatieplan in drie sprints
Sprint 1 is zichtbaarheid. Controleer of SigninLogs, AuditLogs en NonInteractiveUserSignInLogs binnenkomen in Sentinel. Zet daarnaast een Defender XDR huntingquery klaar voor IdentityLogonEvents. Maak nog geen harde blokkades op basis van de eerste queryresultaten, maar gebruik de output om normale ruis te leren kennen: oude clients, shared devices, serviceaccounts en mislukte mobiele aanmeldingen.
Sprint 2 is preventie. Blokkeer legacy authentication, zet Conditional Access voor MFA en maak een aparte authentication strength voor privileged roles. Controleer uitzonderingen alsof het kwetsbaarheden zijn. Elke uitzondering heeft een eigenaar, reden en einddatum nodig. Zonder die discipline wordt Conditional Access op papier sterk, maar in productie poreus.
Sprint 3 is response. Maak een Sentinel analytics rule met entity mapping voor account en IP. Voeg custom details toe zoals FailedUsers, SuccessCount en HasSuccessAfterSpray. Koppel een playbook dat sessies kan intrekken of een ticket met vaste triagestappen aanmaakt. Test met een labaccount voordat je automatische acties inschakelt.
Technisch voorbeeld
De voorbeelden hieronder zijn bedoeld als startpunt. Test altijd met je eigen logging, tijdzones, naming conventions en false-positive patroon. Maak van een hunt-query pas een analytics rule als je eigenaar, severity, response en uitzonderingen hebt vastgelegd.
KQL
// Sentinel: low-and-slow password spray over meerdere IP’s
let lookback = 3d;
let thresholdUsers = 15;
SigninLogs
| where TimeGenerated > ago(lookback)
| where ResultType != 0
| where AppDisplayName !has “Windows Sign In”
| extend Failure = tostring(ResultDescription)
| summarize
FailedUsers=dcount(UserPrincipalName),
FailedAttempts=count(),
Users=make_set(UserPrincipalName, 50),
Apps=make_set(AppDisplayName, 20),
ResultTypes=make_set(ResultType, 20)
by IPAddress, bin(TimeGenerated, 2h)
| where FailedUsers >= thresholdUsers
| join kind=leftouter (
SigninLogs
| where TimeGenerated > ago(lookback)
| where ResultType == 0
| summarize SuccessfulUsers=make_set(UserPrincipalName, 20), SuccessCount=count() by IPAddress
) on IPAddress
| extend HasSuccessAfterSpray = iff(SuccessCount > 0, true, false)
| project TimeGenerated, IPAddress, FailedUsers, FailedAttempts, HasSuccessAfterSpray, SuccessCount, SuccessfulUsers, Apps, ResultTypes, Users
| order by FailedUsers desc, FailedAttempts desc
KQL
// Defender XDR Advanced Hunting: password spray + legacy protocol hints
IdentityLogonEvents
| where Timestamp > ago(7d)
| where ActionType in (“LogonFailed”, “LogonSuccess”)
| summarize
Failed=countif(ActionType == “LogonFailed”),
Success=countif(ActionType == “LogonSuccess”),
TargetedUsers=dcount(AccountUpn),
Users=make_set(AccountUpn, 50)
by IPAddress, LogonType, bin(Timestamp, 6h)
| where Failed > 50 and TargetedUsers > 10
| extend Risk = case(Success > 0, “High – success na spray”, Failed > 250, “Medium – hoog volume”, “Low”)
| order by Risk asc, Failed desc
Mapping: password spray naar controls
| Probleem | Microsoft control | Waarom dit werkt |
| Low-and-slow spray | Sentinel UEBA + KQL over lange vensters | Je correleert gedrag in plaats van losse failures. |
| Succesvolle validatie | Entra ID Protection | Risk detections helpen bepalen of de identity echt geraakt is. |
| Legacy authentication | Conditional Access block legacy auth | Oude protocollen kunnen moderne MFA-bescherming omzeilen. |
| Admin targeting | Phishing-resistant MFA + PIM | Beperkt impact als credentials toch bekend zijn. |
| Herhaalde infrastructuur | ASN/IP reputation + Defender TI | Je groepeert aanvalsinfrastructuur boven individuele IP’s. |
Veelgemaakte fouten
- Alleen alerten op veel pogingen per account. Dat mist de essentie van spray.
- MFA-uitzonderingen voor serviceaccounts laten bestaan zonder eigenaar, einddatum of logging.
- Conditional Access in Report-only laten staan omdat niemand eigenaar van de impactanalyse is.
- Geen onderscheid maken tussen gewone gebruikers, beheerders en accounts met brede datarechten.
- Succesvolle login na spray niet als apart escalatiecriterium behandelen.
Advies vanuit de praktijk
Mijn advies is om dit onderwerp niet als los project te behandelen. Koppel het aan je SOC-proces, je identity governance, je cloud governance en waar relevant je Purview data security-aanpak. De techniek is belangrijk, maar ownership bepaalt of het blijft werken.
Begin klein en meetbaar. Kies één high-value scenario, bouw één goede detectie, test één responsepad en leg vast wie eigenaar is. Daarna schaal je uit. Dat werkt beter dan tien half afgemaakte policies die niemand durft aan te zetten.
Conclusie
Password Spray & Credential Abuse in 2025: detecteren waar aanvallers écht inloggen is geen onderwerp voor alleen awareness of alleen tooling. De kern is dat moderne aanvallen misbruik maken van normale processen: aanmelden, toestemming geven, data openen, scripts uitvoeren, cloudrechten gebruiken en incidenten te laat correleren. Microsoft Security helpt hier sterk bij, maar alleen als je de signalen over identity, endpoint, cloud en data samenbrengt. Maak logging betrouwbaar, maak detections herhaalbaar, automatiseer de eerste response waar de zekerheid hoog genoeg is en gebruik Purview-context om data-impact te begrijpen.
Volg ITCowboys voor de volgende technische deep dive. In de komende blogs pak ik meer Microsoft Security, XDR, Sentinel, Identity en Purview onderwerpen op vanuit de praktijk.
Bronnenlijst
De hyperlinks hieronder zijn gebruikt voor broncontrole en release-status.