# Wat zijn datalekken?

Gegevenslekken die uw werknemers treffen, worden op twee verschillende manieren weergegeven, afhankelijk van of hun exploiteerbaarheid is bevestigd of niet.

## Gegevenslekken met bevestigde exploiteerbaarheid

Dit zijn de meest kritieke gegevenslekken, wat betekent dat een aanvaller ze direct zou kunnen gebruiken als die ze in handen krijgt. Gezien hun kritieke aard wordt voor elk ervan een aparte kwetsbaarheid aangemaakt in de resultaten van Stoïk External Scan.

### Kwetsbaarheid "Geldige gebruikersgegevens gevonden in een gegevenslek/MO365/Fortinet"

Onze External Scan waarschuwt u als de in ons tabblad Gegevenslek gevonden inloggegevens nog actief zijn.

Concreet worden klantinloggegevens die op het Dark Web zijn gelekt nu automatisch getest op de relevante URL om hun geldigheid te verifiëren, dankzij een interne Stoïk-ontwikkeling met generatieve AI.

Als de geldigheid wordt bevestigd, wordt tijdens de analyse van Stoïk External Scan een kwetsbaarheid met de classificatie "hoog" aangemaakt, zodat gebruikers worden aangemoedigd hun inloggegevens bij te werken.

De gebruikersnaam en URL worden dan weergegeven in Stoïk Protect (het wachtwoord kan op uitdrukkelijk verzoek worden gedeeld aan <protect@stoik.io>).

<figure><img src="/files/74fa25ae5acac5e96a98720ff15d99e2fd87e7f1" alt=""><figcaption></figcaption></figure>

Aangezien dit een kwetsbaarheid met de classificatie "hoog" is, zullen de CERT-analisten van Stoïk u proactief per e-mail op de hoogte brengen als een waarschuwing van dit type verschijnt.

### Hoe bevestigt Stoïk het exploiteerbaarheidspotentieel van het lek?

De gegevenslekken die door Stoïk worden getest, komen voornamelijk uit twee bronnen:

**Lekken uit wachtwoorddatabases (combolijsten)**

Deze databases zijn verzamelingen inloggegevens (e-mailadressen, wachtwoorden) die uit meerdere eerdere lekken zijn verzameld en zonder duidelijke context zijn samengevoegd. Voorbeeld: <xavier@stoik.io> / M0t2Pa$$ / supersite.com

Deze combolijsten onthullen niet altijd de exacte website waar de inloggegevens zijn gelekt. Daardoor is het moeilijk om de inloggegevens op de genoemde dienst te testen. In dit geval test Stoïk de inloggegevens automatisch op kritieke en veelgebruikte diensten zoals Microsoft 365 (O365) of Fortinet VPN (als deze dienst door de verzekerde wordt gebruikt).

{% hint style="info" %}
We testen de inloggegevens niet rechtstreeks op de genoemde site, tenzij die met zekerheid bekend is, zoals in het geval van log-stealers (zie hieronder).
{% endhint %}

**Lekken door malware (stealers)**

Stealers zijn malware die op gecompromitteerde machines is geïnstalleerd en lokaal gebruikte inloggegevens ophaalt. Deze lekken zijn veel nauwkeuriger: ze bevatten doorgaans de volgende drie elementen: e-mail / wachtwoord / exacte inlog-URL. Voorbeeld: <xavier@stoik.io> / M0t2Pa$$ / <https://supersite.com/loginpage.php>

Wanneer de URL duidelijk is geïdentificeerd, worden de inloggegevens rechtstreeks op de betreffende site getest, naast Microsoft 365 (O365) en Fortinet VPN. Deze nauwkeurigheid vermindert het aantal fout-positieven sterk en richt zich effectief op de risico's van actieve compromittering.

Samenvatting van de controles uitgevoerd door Stoïk:

| Lektype               | Beschikbare gegevens             | Controle door Stoïk          |
| --------------------- | -------------------------------- | ---------------------------- |
| **Combolijst**        | E-mail + wachtwoord (of website) | Alleen O365 + Fortinet       |
| **Stealer-logboeken** | E-mail + wachtwoord + URL gelekt | URL gelekt + O365 + Fortinet |

Als de betreffende URL Fortinet of O365 is, heet de weergegeven kwetsbaarheid "(...) gevonden in een Fortinet/Microsoft Office 365-datalek". Anders heet de weergegeven kwetsbaarheid "(...) gevonden in een datalek", en wordt de URL vermeld in de details van de kwetsbaarheid.

Standaard wordt er geen kwetsbaarheid aangemaakt als de resultaten van de controles door Stoïk leeg zijn, maar het lek wordt nog steeds weergegeven in het tabblad "Gegevenslek".

## Gegevenslekken waarvan de exploiteerbaarheid nog moet worden bevestigd

### De resultaten begrijpen

`Externe scan` > `Resultaten` > `Gegevenslekken` geeft een overzicht van alle gegevenslekken die bij uw werknemers zijn gedetecteerd, ongeacht of hun exploiteerbaarheid al is bevestigd.

De weergegeven datum komt doorgaans overeen met het moment waarop onze tool het datalek heeft gedetecteerd, niet met de werkelijke datum van het lek.

Door op een specifiek datalek te klikken, krijgt u toegang tot gedetailleerde resultaten. Hier zijn twee voorbeelden van hoe u de resultaten kunt interpreteren:

**"IP" en "wachtwoord"**

Voor dit voorbeeld moet u begrijpen dat voor het e-mailadres <craig.maxwell@my-company.com> het wachtwoord in platte tekst en het IP-adres zijn gelekt tijdens het Adobe Data Breach 2024-datalek voor het domein my-company.com.

<figure><img src="/files/b80ea0e4850265ebef696804ec064f312db4d0b7" alt=""><figcaption></figcaption></figure>

**"Wachtwoord" en "Versleuteld wachtwoord"**

Voor dit voorbeeld moet u begrijpen dat voor het e-mailadres <emma.gaucher@my-company.com> het wachtwoord in platte tekst ("password") en de hash ("versleuteld wachtwoord") zijn gelekt op meerdere websites van onbekende herkomst, vandaar de term "combolijsten".

<figure><img src="/files/bfa60c8e7f63a154dea5b7caef263816f2a43093" alt=""><figcaption></figcaption></figure>

### Waarom verschijnt een voormalige werknemer in het tabblad Gegevenslek?

Als u een waarschuwing ziet over een account dat is gekoppeld aan een werknemer die niet langer bij het bedrijf werkt, zijn daarvoor verschillende logische redenen.

**Oorsprong:** Dit is geen Active Directory-account of bedrijfs-e-mailadres dat direct actief is in uw IT-systeem, maar eerder een gebruikersaccount van een derde partij dat een adres uit uw domein gebruikt, bijvoorbeeld <john@your-company.com> dat is geregistreerd op een externe site, zoals <https://random.saas>.

Dit type account kan toebehoren aan:

* Een voormalige werknemer die een SaaS-account heeft aangemaakt met zijn werkadres.
* Een account dat nog actief is in een SaaS-toepassing, waarvan het werk-e-mailadres nog geldig is.
* Een extern account dat is aangemaakt zonder verificatie van het e-mailadres, wat op bepaalde platforms mogelijk is.

**Reden voor detectie:** De waarschuwing wordt door Stoïk gegenereerd omdat het e-mailadres van het account is gekoppeld aan uw domeinnaam of het wachtwoord dat aan dit account is gekoppeld, is verschenen in een openbaar datalek.

Daarom kan dit account, zelfs als het van een voormalige werknemer is of niet wordt beheerd door uw IT-afdeling:

* Nog steeds aan uw bedrijf worden gefactureerd (gebruikelijk bij SaaS-abonnementen).
* Toegang hebben tot interne gegevens, als er geen intrekking heeft plaatsgevonden.
* Een risico op indirecte compromittering vormen (hergebruik van wachtwoorden, bounce-aanval).

**Aanbeveling:** In deze situatie:

* Ga na of het account nog actief is in de betreffende toepassing.
* Trek het account in of deactiveer het als u er controle over heeft.
* Neem indien nodig contact op met de SaaS-leverancier om verwijdering te verzoeken.
* Werk uw procedures voor het vertrek van werknemers bij zodat ook het systematisch intrekken van accounts van derden is opgenomen.

### Waarom is er een waarschuwing voor een werkstation dat niet van ons is?

{% hint style="info" %}
Ook als de betreffende werkplek u niet rechtstreeks betreft, is de waarschuwing relevant als activiteit wordt gedetecteerd die verband houdt met uw domein of organisatie.

Elke ongebruikelijke activiteit kan wijzen op: ongeoorloofd gebruik, mogelijke compromittering, slecht beheer van toegang van derden.
{% endhint %}

U kunt een cyberbeveiligingswaarschuwing ontvangen voor een werkstation dat niet in uw IT-inventaris staat. Dat lijkt misschien verrassend, maar er zijn verschillende mogelijke verklaringen voor deze situatie.

**Een persoonlijk apparaat van een werknemer**

* **Oorsprong:** Een werknemer kan, vrijwillig of uit gewoonte, via een persoonlijk apparaat (persoonlijke computer, tablet, enz.) toegang hebben tot werkbronnen.
* **Reden voor detectie:** De waarschuwing wordt door Stoïk gegenereerd omdat dit werkstation niet is beveiligd of bewaakt door uw IT-teams en daardoor een kwetsbaar toegangspunt voor aanvallen kan vormen (ransomware, gegevensdiefstal).
* **Aanbeveling:** Vraag uw werknemer dit gebruik te beperken of zijn/haar apparaat te beveiligen (versleuteling, antivirus, sterk wachtwoord, enz.). Het wordt sterk aanbevolen om uw beleid voor het gebruik van persoonlijke apparaten (BYOD) te herzien als u dat nog niet hebt gedaan.

**Werkstation van een dienstverlener of onderaannemer**

* **Oorsprong:** Het is mogelijk dat een dienstverlener (externe IT-ondersteuning, consultant, freelancer, enz.) vanaf zijn eigen werkstation toegang heeft tot uw gegevens of systemen.
* **Reden voor detectie:** De waarschuwing wordt door Stoïk gegenereerd omdat het om uw diensten of uw domein gaat. Het werkstation wordt als risicovol beschouwd als het gecompromitteerd of slecht beschermd is.
* **Aanbeveling:** Controleer of deze dienstverlener nog actief is binnen het bedrijf. Zo niet, trek dan zijn of haar toegang in. Zorg anders dat aan hun kant goede beveiligingspraktijken zijn ingevoerd.

**Gedeeld of openbaar werkstation (hotel, terminal, internetcafé, enz.)**

* **Oorsprong:** In sommige zeldzame gevallen kan toegang tot uw diensten plaatsvinden vanaf een openbaar of gedeeld terminal: hotelterminal, pc in een vergaderruimte, enz.
* **Reden voor detectie:** De waarschuwing wordt door Stoïk gegenereerd omdat deze machines sterk blootstaan aan malware of keyloggers. Dit komt doordat verbindingen zelden versleuteld of privé zijn.
* **Aanbeveling:** Herinner uw werknemers eraan nooit een openbare computer te gebruiken om toegang te krijgen tot kritieke bronnen, of in elk geval een VPN en versleutelde verbindingen te gebruiken.

### Waarom komt de meldingsdatum van een lek niet altijd overeen met de datum van compromittering?

Gebruikers vragen zich vaak af waarom er tijd zit tussen de datum van een datalek (of gestolen wachtwoord) en de datum waarop de Stoïk-waarschuwing wordt ontvangen. De belangrijkste reden is dat wachtwoorden niet onmiddellijk openbaar worden gemaakt.

Inloggegevens die door infostealers zijn gestolen (kwaadaardige software die wachtwoorden uit browsers, wachtwoordbeheerders of systeemcaches kan halen) worden inderdaad niet altijd direct gedeeld op de forums of marktplaatsen die wij monitoren.

In de praktijk wordt gestolen informatie eerst verkocht in besloten kringen of afgeschermde groepen en wordt deze pas na enkele weken of zelfs maanden openbaar beschikbaar. Dan detecteert ons systeem het en waarschuwt het u.

### Waarom tonen sommige datalekken een onbekende bron?

**Oorsprong:** U kunt datalekken in uw Stoïk Protect-interface zien verschijnen zonder duidelijke aanduiding van hun oorsprong. In dat geval staat de bron vermeld als "Combolist", wat betekent dat die onbekend of niet verifieerbaar is.

Een combolijst is een enorme verzameling identificatiegegevens (e-mailadressen, wachtwoorden, soms andere gegevens) die uit verschillende lekken zijn samengebracht. Deze bestanden worden door cybercriminelen opnieuw verpakt en vervolgens doorverkocht of gedeeld op forums, zonder dat altijd de oorsprong van de gegevens wordt vermeld.

**Reden voor detectie:** De waarschuwing wordt door Stoïk gegenereerd omdat, zelfs als de exacte bron onbekend is, het risico reëel is. De identificatiegegevens (e-mail + wachtwoord) werken namelijk nog steeds op bepaalde diensten, waardoor ze kunnen worden misbruikt voor een credential stuffing-aanval of toegang kunnen geven tot een SaaS die in uw bedrijf wordt gebruikt.

## Wat te doen bij een waarschuwing voor een datalek?

* Wijzig het wachtwoord onmiddellijk.
* Als u de dienst niet herkent, controleer dan het interne gebruik van het genoemde e-mailadres.
* Schakel multifactorauthenticatie (MFA) in als u dat nog niet hebt gedaan.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.stoik.io/help/help-nl/preventietools/what-is-the-external-scan/what-are-data-leaks.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
