Onderzoek en herstel Sophos ITDR Dark Web Intelligence

Dark Web Intelligence toont de lekgegevens die Sophos heeft verzameld voor de geconfigureerde domeinen. Het doel van dit runbook is niet om elke hit als actuele accounttoegang te behandelen. Eerst worden identiteit, tijdsreferentie, wachtwoordtype en lekstatus gecontroleerd. Vervolgens wordt alleen via een goedgekeurd proces gereageerd voor de identiteit die daadwerkelijk gekoppeld is.

Credential Leaks met de status Active verhogen de Risk Score van een identiteit. Historische records blijven echter zichtbaar, ook wanneer ze inactief zijn. De tabel dient daarom zowel als een werkend overzicht van huidige risico’s als als bewijs van oudere ontdekkingen.

Snel proces

1. Open My Products > Identity > Dark Web Intelligence en documenteer de standaardfilters.
2. Geef prioriteit aan een actieve registratie en registreer Source, gekoppelde identiteit, wachtwoordtype en Publish Date, Leaked Date en Breach Date.
3. Controleer waarom de registratie Active is; beschouw niet elke rij als een uniek account of wachtwoord.
4. Vergelijk voor een bijbehorende Finding de weergegeven ernst met de matrix aan de hand van accounttype, wachtwoordtype en MFA-sterkte.
5. Bevestig verantwoordelijkheid en goedkeuring. Voer pas daarna de geschikte, reeds goedgekeurde reactie uit.
6. Herstel de aanmeldgegevens in de verantwoordelijke Identity Provider via het goedgekeurde proces. Gebruik Finding of de status van lekkage niet als vervanging voor dat herstel.
7. Controleer na minstens één cyclus van 15 minuten opnieuw de status, de Finding en de Risk Score en documenteer het bewijs.

Weergaven en standaardfilters

Rechtstreekse toegang

My Products > Identity > Dark Web Intelligence

Bij het direct openen van deze pagina wordt de tabel gefilterd op lekkagestatus Active en identiteitsstatus Active. Maak vóór het onderzoeken een screenshot of notitie van de actieve filters. Een lege standaardweergave bewijst niet dat er geen historische lekkagegegevens zijn; voor deze controle kunt u de statusfilters bewust verbreden.

Toegang via Identity Overview

Identity Overview > Credential Leaks

Als u op een metriek in de widget Credential Leaks klikt, wordt Dark Web Intelligence geopend met een weergave die bij de metriek past:

Breached Email Accounts en Unique Passwords Breached zijn de totale statistieken van de onderliggende gegevens. Er is geen extra tabelfilter dat hun unieke telmethode volledig in kaart brengt. Daarom kan de statistiek niet exact worden gereconstrueerd uit de tabelrijen die zichtbaar zijn na het klikken.

Interpreteer statistieken correct

De meetwaarden bovenaan Dark Web Intelligence hebben betrekking op actieve lekken:

Deze waarden gebruiken verschillende eenheden: bronnen, lekregistraties, accounts en unieke wachtwoorden. Ze kunnen niet eenvoudig worden opgeteld of gevalideerd door gewoon de rijen in de tabel te tellen.

Onderzoek een lekrecord

1. Definieer de reikwijdte

Noteer eerst de filters en sortering. Voor de eerste triage zijn in ieder geval deze kenmerken relevant:

• Lekstatus Active of Inactive
• Identiteitsstatus en verbonden identiteit
• Plaintext of Hashed
• Admin-, niet-admin- of VIP-context, indien aangegeven
• Source
• Publish Date, Leaked Date en Breach Date
• geassocieerde Finding, indien aanwezig

Geef niet alleen prioriteit aan de nieuwste tijdstempel in de tabel. Een record met nieuwe Publish Date kan oudere inhoud bevatten, vooral voor combolijsten.

2. Open details

Klik op het veld Source. Het detailpaneel toont aanvullende informatie over het lek en, indien beschikbaar, de gekoppelde identiteit. Voordat u reageert, moeten de tabelrij en het detailpaneel naar dezelfde bron en identiteit verwijzen.

Als er geen identiteit is toegewezen, blijft het record relevant voor het historisch onderzoek, maar wordt het als inactief beschouwd. Actions is in dit geval uitgeschakeld. Wijs geen identiteit toe op basis van een gok, en onderneem geen actie tegen een account met een vergelijkbare naam.

3. Onderscheid de datumvelden

Publish Date

De tijd waarop Sophos het lekrecord voor het eerst vond in de gegevens die het analyseerde. Het verwijst noch naar de tijd van publieke beschikbaarheid, noch noodzakelijkerwijs naar de tijd van het incident.

Leaked Date

De datum waarop de dataset openbaar beschikbaar werd. Deze datum wordt vergeleken met de laatste wachtwoordwijziging om te beoordelen of het risico van de inloggegevens actueel is.

Breach Date

De tijd waarop de onderliggende inbreuk plaatsvond. Het biedt context over het incident, maar kan mogelijk niet beschikbaar zijn.

Een ontbrekende Breach Date maakt Leaked Date niet de bevestigde inbraaktijd. Evenzo bewijst een nieuwe Publish Date niet dat het wachtwoord recentelijk is gecompromitteerd. Voor de statuslogica is het cruciaal of de laatste wachtwoordwijziging voor of na de relevante eerste-lektijd is.

4. Duplicaten en combolijsten beoordelen

Dezelfde persoon kan in meerdere rijen binnen één bron voorkomen. Veelvoorkomende redenen zijn:

• de persoon verschijnt meerdere keren in de oorspronkelijke dataset;
• dezelfde inhoud werd herkend in een generieke bron zoals een combolist;
• oudere lekgegevens worden opnieuw zichtbaar in een later gevonden verzameling.

Meerdere rijen duiden daarom niet automatisch op meerdere gecompromitteerde accounts of meerdere actuele wachtwoordcompromitteringen. Vergelijk voor elke rij de bron, datum, het wachtwoordtype en de gekoppelde identiteit. De metrieken Emails en Unique Passwords passen deduplicatielogica toe; de tabelrijen worden niet op dezelfde manier gededupliceerd.

Wanneer een lek Active of Inactive is

Een lek is Active als aan beide voorwaarden wordt voldaan:

1. Het record kan worden gekoppeld aan een actieve identiteit in een geconfigureerde Identity Provider.
2. De laatste wachtwoordwijziging van het bijbehorende account vond plaats vóór het tijdstip van het eerste lek.

Active duidt daarom op een risico rond aanmeldgegevens dat nog steeds relevant is. Alleen de status bewijst niet dat er een succesvolle aanmelding door een derde partij of een lopende aanval heeft plaatsgevonden.

Een lek is Inactive als ten minste een van de gedocumenteerde scenario’s van toepassing is:

• Er is geen overeenkomende identiteit in de geconfigureerde Identity Providers.
• De meest recente wachtwoordwijziging is na de lekdatum.
• Het wachtwoord van het account is onlangs gewijzigd.
• Het account is gedeactiveerd of verwijderd.
• Een gerelateerde Finding heeft de status Resolved of Dismissed gekregen.

Historische gegevens over gemonitorde domeinen worden verzameld en bewaard. Een inactieve dataset is daarom noch fout, noch irrelevant vanwege de ouderdom. Het kan verklaren waarom dezelfde persoon of bron meerdere keren voorkomt.

Wanneer een Finding wordt gemaakt

Sophos beschrijft de volgende verwerking voor Findings over gecompromitteerde accounts:

1. Sophos controleert of er een actieve identiteit bestaat in de geconfigureerde Identity Providers.
2. Sophos bepaalt aan de hand van beschikbare historische gegevens wanneer de platte tekstwaarde of hash voor het eerst is gelekt. Dit is bedoeld om oude inhoud in nieuwe combolists te herkennen.
3. Met een platte-tekstwaarde vergelijkt Sophos de waarde met de wereldwijde wachtwoordcomplexiteitsvereisten van Microsoft Entra ID om ongeldige waarden uit te sorteren.
4. Sophos vergelijkt het tijdstip waarop het wachtwoord voor het eerst is gelekt met de laatste wachtwoordwijziging. Als het eerste lek na die wijziging plaatsvond, maakt Sophos een Finding aan.

Findings worden alleen gemaakt voor actieve identiteiten. De ruwe gegevens blijven zichtbaar op Dark Web Intelligence zelfs als er geen actieve identiteit is gekoppeld.

Ernstmatrix voor accountcompromittering

Volgens Sophos hangt de ernst van Finding af van het type account, het type wachtwoord en de sterkte van MFA:

De matrix geeft prioriteit aan het werk, maar vervangt geen beoordeling van het individuele geval. Vooral voor beheerdersaccounts moet de daadwerkelijke accountassociatie worden bevestigd voordat er wordt gereageerd. Een lagere graad van ernst betekent niet dat geen herstelmaatregelen nodig zijn.

Het omgaan met wachtwoordwaarden

Sophos verklaart geen wachtwoorden in platte tekst of hashwaarden op te slaan en deze waarden ook niet uit Identity Providers te kunnen verzamelen. Sophos past tijdens het verzamelen zijn eigen hash toe op waargenomen waarden en categoriseert vervolgens de dataset als Plaintext of Hashed. Volgens Sophos maakt deze methode het mogelijk om unieke waarden en afgeleide indicatoren te bepalen zonder de onderliggende wachtwoordwaarde op te slaan.

Operationeel betekent dit:

• Plaintext beschrijft het type gelekte inhoud dat is waargenomen, niet een wachtwoord dat beschikbaar is in Sophos Fusion (voorheen Sophos Central).
• Probeer de oorspronkelijke waarde niet te herstellen vanuit Sophos Fusion, schermafbeeldingen of exports.
• Kopieer geen verdachte wachtwoorden, hashwaarden of nieuwe inloggegevens in tickets, notities of chatberichten.
• Stel een nieuw wachtwoord in uitsluitend via het goedgekeurde proces van de Identity Provider en behandel het in het bedoelde wachtwoordsysteem.

Geautoriseerde reactie en herstelmaatregelen

Beslis voordat u actie onderneemt

Voordat u Actions gebruikt, moet aan alle volgende voorwaarden zijn voldaan:

• De gekoppelde identiteit wordt duidelijk bevestigd door het detailpaneel.
• De accounteigenaar, het accounttype en de bedrijfsfunctie zijn bekend.
• De huidige lekkagestatus, het wachtwoordtype en drie datumvelden zijn gecontroleerd.
• Response Actions zijn geautoriseerd voor de tenant.
• De persoon die de handeling uitvoert, is gemachtigd voor de specifieke identiteit en het verwachte effect.
• De verantwoordelijke servicemanager of systeembeheerder is betrokken bij accounts met verhoogde bevoegdheden of gedeelde accounts.

Als een van deze voorwaarden ontbreekt, wordt er geen actie ondernomen. Het record wordt doorgegeven aan de verantwoordelijke persoon in het Identity- of Security-team met de tijdstempel, filterstatus en details van de ontbrekende goedkeuring.

Reageer in Dark Web Intelligence

Als Response Actions zijn geautoriseerd, zijn ze beschikbaar voor gekoppelde identiteiten in de tabel of in de lekdetail:

1. Open de juiste rij of het detailpaneel van de bevestigde identiteit.
2. Selecteer Actions.
3. Selecteer alleen de reeds goedgekeurde Response Action.
4. Bekijk en volg alle instructies en bevestigingen op het scherm.
5. Documenteer actie, operator, timing, doelidentiteit en zichtbaar resultaat, maar leg geen inloggegevens vast.

Gebruik uitsluitend Response Actions die in de tenant beschikbaar en door de organisatie geautoriseerd zijn. Als er geen geschikte identiteit bestaat, blijft Actions uitgeschakeld; dit mag niet worden omzeild.

Herstel het inlogrisico

Technisch herstel vindt plaats via de Identity Provider die verantwoordelijk is voor het account en het goedgekeurde proces voor aanmeldgegevens:

1. Controleer de laatste wachtwoordwijziging en de accountstatus van de bevestigde identiteit tegenover de lekdatum.
2. Als het niet mogelijk is uit te sluiten dat de in de lek waargenomen inloggegevens nog geldig zijn, start of voer dan een geautoriseerde wachtwoordwijziging uit voor precies dit account.
3. Als een account is uitgeschakeld of verwijderd, bevestig dan de status van de provider in plaats van het account te heractiveren voor herstel.
4. Als het record niet aan een identiteit is gekoppeld, behandel het dan als een historisch, inactief lek en raad niet naar de identiteit van het account.
5. Verwerk een gekoppelde Finding pas volgens het voorgeschreven proces nadat het daadwerkelijke herstel van de aanmeldgegevens is gedocumenteerd. Gebruik Dismissed alleen na een technisch gedocumenteerde beslissing, niet om de wachtrij te verkorten.

Leid uit de lekregistratie geen aanvullende account-, sessie-, MFA- of directorywijzigingen af. Dergelijke maatregelen vereisen een afzonderlijk bevestigde reden en de daarvoor vereiste goedkeuring.

Cyclus van 15 minuten en validatie

Sophos controleert Dark Web Intelligence elke 15 minuten. Sophos houdt continu lekresultaten in de gaten en verzamelt deze; als een actief lek wordt gedetecteerd, wordt er meestal binnen 15 minuten een Finding gegenereerd. “Meestal” is geen gegarandeerde maximale tijd.

Registreer na het herstel niet onmiddellijk een definitief succes. Ga in plaats daarvan als volgt te werk:

1. Registreer de voltooiingstijd van de wachtwoordwijziging of de bevestigde accountwijziging met tijdzone.
2. Wacht minstens op een volledige cyclus van 15 minuten. Houd er rekening mee dat het verwerken van bijgewerkte Identity Provider-gegevens door Sophos extra tijd kan vergen.
3. Heropen My Products > Identity > Dark Web Intelligence.
4. Zoek naar dezelfde identiteit en bron met dezelfde filters.
5. Controleer of het lek is veranderd van Active naar Inactive en of de weergegeven identiteitsstatus correct is.
6. Controleer de bijbehorende Finding afzonderlijk. Het ontbreken van een nieuwe Finding is onvoldoende bewijs als het lek nog steeds Active is.
7. Controleer de Risk Score van de identiteit als een opvolgsignaal. Het is niet het primaire bewijs van de wijziging van het wachtwoord.
8. Documenteer de beginwaarde, actie, voltooiingstijd, validatietijd en eindstatus.

Acceptatiecriteria

De verwerking is pas voltooid wanneer:

• Identiteit en lekbron zijn duidelijk gedocumenteerd;
• wachtwoordtype en datumsvelden zijn geëvalueerd;
• het herstel van de aanmeldgegevens is bevestigd in de verantwoordelijke Identity Provider of het account is aantoonbaar uitgeschakeld of verwijderd;
• het verholpen lekkageregister is na verwerking niet langer Active;
• de bijbehorende Finding is afgehandeld via een gecontroleerd proces;
• er staan geen geheime waarden in de documentatie.

Als het record Active blijft na meerdere cycli van 15 minuten, controleer dan eerst opnieuw de werkelijke laatste wachtwoordwijziging, de accountstatus en de gekoppelde identiteit. Als deze informatie correct is en de status nog steeds niet kan worden verklaard, moeten de filterstatus, bron, alle drie de datumsvelden, identiteitreferentie, Finding-referentie en tijdstempel worden vastgelegd. Escaleer daarna naar Sophos-ondersteuning. Breng geen verdere accountwijzigingen aan op basis van een gok.

Triageformulier

Tenant / omgeving:
Validatietijd met tijdzone:
Pad en actieve filters:
Source:
Gekoppelde identiteit:
Identiteitsstatus:
Accounttype: Admin / Niet-Admin / onduidelijk
VIP-monitoring: ja / nee / onduidelijk
Wachtwoordtype: Plaintext / Hashed
Lekstatus vóór actie:
Publish Date:
Leaked Date:
Breach Date: Waarde / niet beschikbaar
Meerdere regels of combolijstcontext:
Finding-referentie en ernst:
Laatste wachtwoordwijziging volgens Identity Provider:
Goedkeuring van reactie:
Geautoriseerde actie uitgevoerd:
Voltooiingstijd met tijdzone:
Validatie na 15-minuten cyclus:
Lekstatus na de maatregel:
Finding-status na de actie:
Risk Score als een opvolgingssignaal:
Open afwijking / escalatie:

Vermijd veelgemaakte fouten

• Tel elke tabelrij als een afzonderlijk account: Duplicaten en combolijsten kunnen meerdere regels voor dezelfde persoon creëren.
• Publish Date gelezen als Breach Date: De drie datumvelden beschrijven verschillende gebeurtenissen; Breach Date kan ontbreken.
• Inactive interpreteren als verwijderd: Historische gegevens blijven intact en kunnen verder zichtbaar zijn.
• Een lege standaardweergave als veilig beschouwen: Bij rechtstreekse toegang worden standaard alleen actieve lekken van actieve identiteiten getoond.
• Sluit een Finding handmatig in plaats van te herstellen: Een statuswijziging verandert geen enkele logingegevens in de Identity Provider.
• Actions forceren zonder een gekoppelde identiteit: Zonder een overeenkomende identiteit is de knop opzettelijk uitgeschakeld.
• Verwar Plaintext met een opvraagbaar wachtwoord: Sophos zegt dat noch platte tekstwaarden, noch hashwaarden worden opgeslagen.
• Verwacht een onmiddellijke update: De controle draait in een cyclus van 15 minuten; upstream-identiteitsgegevens kunnen extra verwerkingstijd vereisen.