Onderzoekers beschrijven een actieve campagne die onder de codenaam UNK_CondorFiltration meer dan 5.700 accounts wist te benaderen binnen 28 Microsoft 365-tenants. Wat de zaak bijzonder maakt, is niet alleen het aantal betrokken accounts, maar vooral de manier waarop toegang werd verkregen: via TeamFiltration default passwords en kwetsbare, vergeten identiteiten.
Proofpoint stelt dat de aanvallen zich voornamelijk richtten op niet-menselijke identiteiten: unmanaged functional of service accounts. Daar ontbreken vaak de controles die je bij medewerkersaccounts wél verwacht, zoals MFA (multi-factor authentication) en regelmatig roteren van wachtwoorden.
Wat is TeamFiltration?
TeamFiltration wordt in de publicatie omschreven als een legitiem, cross-platform offensief framework. Het helpt een operator met handelingen zoals het opsommen (enumereren) van Entra ID-accounts, wachtwoorden testen (spraying), gegevens exfiltreren en achterdeuren installeren. Daarmee sluit het aan bij een aanpak die in cloud-omgevingen vaak voorkomt: niet eerst één specifieke gebruiker treffen, maar breed proberen toegang te krijgen met “gewoon” bekende of nog niet aangepaste credentials.
Belangrijk is dat TeamFiltration ook gebruikt kan worden voor defensieve testdoeleinden. In dit geval gaat het echter om kwaadaardige toepassing: de campagne gebruikt het framework om accounts te valideren en daarna door te pakken.
Waarom default passwords zo’n groot verschil maken
In deze campagne lijkt het dreigingsactor-patroon te leunen op het testen van default wachtwoorden en wachtwoorden die ooit zijn uitgereikt door IT-teams, maar daarna niet zijn geroteerd. Proofpoint benadrukt dat de impact dan vooral groot is bij identiteiten die minder vaak worden gecontroleerd dan gebruikersaccounts.
De reden: gebruikers moeten regelmatig hun wachtwoord wijzigen, terwijl serviceaccounts en functionele accounts vaak “blijven draaien” met dezelfde, oorspronkelijke gegevens. Als zo’n account vervolgens onopgemerkt blijft, ontstaat er een aanvalsvlak dat jarenlang kan bestaan zonder zichtbaar alarm.
Welke accounts werden getroffen (en welke niet)?
Proofpoint beschrijft dat de aanvallen 7 accounts compromisden. Daarbij ging het niet om individuele medewerkers, maar om unmanaged service- of functionele accounts. Dat verschil is essentieel: het onderstreept hoe het identiteitsperimeter zwakker kan zijn rond niet-menselijke accounts dan rond menselijke gebruikers.
Verder wijst de timing op mogelijk gedeelde credentials. Zo werden 6 van de 7 gecompromitteerde accounts binnen 7 minuten doorbroken. In de publicatie wordt dat geïnterpreteerd als aanwijzing voor een gedeelde of “standaard” wachtwoordset in plaats van een precies gerichte credential stuffing per account.
3 waves tussen eind juli en augustus 2026
Volgens de beschrijving ontvouwde de brute-force activiteit zich in drie waves van late juli tot augustus 2026. Een Chileense retailpartij kreeg daarbij het grootste aandeel van de waargenomen authenticatiegebeurtenissen.
- 21–24 juli: ongeveer 100–120 unieke accounts per dag, gericht op twee grote Chileense banken.
- 26–28 juli: een piek rond 1.520 accounts op 27 juli, waarna het aantal snel daalde; gericht op een andere grote financiële instelling.
- 13–16 augustus: piek rond 1.560 accounts op 15 augustus, gericht op een grote retailer; dit leidde uiteindelijk tot de zeven compromissen.
De campagne startte vanuit 1.487 unieke AWS EC2-bron-IP’s. Dat past bij een aanpak die infrastructuur verspreidt om brute-force of spraying minder opvallend te maken.
Doorbraak en doorwerking in Microsoft 365
Na een succesvolle compromis werd door de operator verder gewerkt binnen het Microsoft 365 ecosysteem. In de publicatie staat dat de actor, zodra toegang was verkregen, mogelijk toegang gebruikte tot Microsoft Office, OneDrive en Teams.
Dat betekent niet automatisch dat er al sprake was van exfiltratie, benadrukt Proofpoint. Alleen het bestaan van login-events is onvoldoende bewijs. Wel wijst het patroon op de intentie om informatie te verzamelen en eventueel later data naar buiten te brengen.
Daarnaast wordt beschreven dat de actor zeer snel opschakelde. Onder minder dan 2 minuten na een succesvol compromis werd er gepivot naar een Duitse VPN-node om de corporate VPN te benaderen, met een route naar een SAML 2.0 endpoint (vpn.[redacted].cl/SAML20/SP). Daarna werden ook stappen gezet richting de Azure Portal, het bekijken van SharePoint Online en het opvragen van Microsoft Graph API tokens.
Dit soort ketenaanpak laat zien hoe snel een identiteit kan omschakelen van “inloggen” naar “platform toegang” zodra de juiste rechten zijn geraakt.
Wat maakt deze case breder relevant?
Proofpoint ziet de campagne als een duidelijke herinnering aan een klassiek probleem: het “zwakste punt” in een enterprise identity perimeter is niet altijd een gephishte medewerker of een zero-day exploit. Vaak gaat het om vergeten accounts—met name serviceaccounts die ooit voor gemak zijn ingericht en daarna structureel niet meer worden nagelopen.
Die serviceaccounts worden in de publicatie expliciet aangeduid als aanvallend kwetsbaar omdat ze geen passende bescherming hebben (zoals MFA en wachtwoordrotatie) en mogelijk ook minder goed gemonitord worden.
Als je meer wilt lezen over hoe identiteiten en accounts misbruikt kunnen worden in cloudcontext, is dit ook relevant: AI-agents die het internet overnemen: hoe reëel is het? beschrijft bredere trends in geautomatiseerde aanvallen en de praktische risico’s daarvan. (Niet hetzelfde onderwerp, maar wel dezelfde les: automatisering maakt zwakke plekken belangrijker.)
Concreet: zo maak je service-accounts minder aantrekkelijk
De kern van het verhaal is helder: TeamFiltration default passwords is effectief wanneer identiteiten niet goed zijn beheerd. Je hoeft niet alles tegelijk te veranderen, maar je kunt gericht saneren en aanscherpen waar de risico’s het hoogst zijn.
1) Forceer MFA waar het kan
Als serviceaccounts toegang nodig hebben tot kritieke onderdelen van Microsoft 365, zet dan MFA en/of passende alternatieven in. Proofpoint benoemt expliciet dat er geen MFA aanwezig was bij de kwetsbare accounts.
2) Beheer en rotatie van wachtwoorden
Stel wachtwoordrotatie verplicht voor unmanaged functionele accounts waar dat nog niet gebeurt. Als accounts al lang dezelfde credentials gebruiken, behandel dat als een urgente correctie.
3) Zorg dat serviceaccounts gemonitord worden
In de publicatie wordt aangegeven dat de accounts ongecontroleerd bleven terwijl ze wel dezelfde wachtwoorden droegen. Dat betekent: implementeer logging en alerts rond aanmeldingen van serviceidentiteiten, zeker als er afwijkende locaties of volumes zichtbaar worden.
4) Review “dormante” en ongebruikte identiteiten
Ook al zijn accounts ooit functioneel ingezet, ze kunnen later “vergeten” raken. Maak daarom een periodieke inventarisatie: welke serviceaccounts zijn nog nodig, welke niet, en welke hebben verouderde toegang?
Waarom dit soort incidenten snel escaleren
Een extra waarschuwing uit de case is de snelheid. In korte tijd werd er niet alleen ingelogd, maar werd ook een vervolgroute gekozen richting VPN-toegang en platformbeheer (Azure Portal) en werd er gewerkt met Graph API tokens. Dat patroon maakt duidelijk dat je niet kunt volstaan met alleen “inlogblokken” achteraf; je hebt ook preventieve en detectieve maatregelen nodig vóórdat toegang tot kernsystemen ontstaat.
Overigens ziet de sector regelmatig dat aanvallen in de identiteitlaag juist door middel van tooling worden versneld. Een parallel met eerdere cloud-incidenten lees je bijvoorbeeld in: EvilTokens device-code phishing verstoord door Microsoft. Ook daar staat de identiteitslaag centraal, zij het met een andere aanvalstechniek.
Conclusie
De TeamFiltration campagne laat zien hoe een combinatie van default of niet-gerote wachtwoorden, ontbrekende MFA en onvoldoende monitoring kan leiden tot compromissen in Microsoft 365. Hoewel slechts 7 accounts daadwerkelijk werden overgenomen, maakte het totaal van 5.700+ benaderde accounts duidelijk dat de aanval vooral om schaal en validatie draaide.
De belangrijkste les is praktisch: kijk niet alleen naar gephishte medewerkers of “grote” exploits. Begin bij de accounts die het langst blijven bestaan zonder herbeoordeling—de unmanaged service- en functionele identiteiten—en verbeter daar de bescherming. Zo verklein je de kans dat tooling als TeamFiltration überhaupt succesvol kan worden.
Bron: https://thehackernews.com/2026/09/teamfiltration-compromises-seven.html
