Dark Web Monitoring as an Early Warning System

The criminal market is organised around division of labour. Infostealer malware exfiltrates credentials, session cookies and browser data from infected devices and bundles them into so-called stealer logs, which are traded on marketplaces and in Telegram channels; combolists aggregate email-password combinations from old and new leaks, and the leak sites of ransomware groups publish stolen data sets. Initial access brokers (IABs) turn such raw data into verified network access and sell it on – according to ENISA, with a trend towards low-priced, high-volume offerings in which the majority of accesses trade for under roughly 2,800 euros. The market is also remarkably resilient: after the takedown of the RedLine and META infostealers (Operation Magnus, October 2024), use of the Lumma stealer rose by more than 350 percent between the first and second half of 2024; ENISA continues to assess infostealers as a fixed link in the cybercriminal supply chain.

There is a measurable amount of time between data exfiltration and attack – and that window is exactly what monitoring addresses. According to the Verizon Data Breach Investigations Report 2026, 73 percent of the ransomware victims examined showed an infostealer or credential-leak event in the year before the attack; for half of those affected, the event occurred within 95 days before the attack. The BSI's 2025 report on the state of IT security in Germany underlines the connection as well: 72 percent of ransomware attacks reported in Germany were accompanied by data leaks, and both the number of leak victims and the number of credential thefts increased. Whoever detects compromised credentials before they are exploited can break the attack chain at its first link – at far lower effort than in incident response.

In practice, monitoring services deliver three classes of hits. First, compromised credentials of employees and customers from stealer logs, breach databases and combolists – often together with session cookies, the affected login URLs (such as VPN portals, SSO or admin interfaces) and details of the infected device. Second, mentions of the company in forums, on marketplaces and in Telegram channels, for example access offers from initial access brokers or discussions about planned attacks. Third, leaked data sets and documents on leak and paste sites, for instance following an incident at a service provider. What is typically monitored for this purpose are the organisation's own domains including subdomains, email addresses, IP ranges, and brand and product keywords. Only what surfaces in accessible sources becomes visible – exclusive direct sales between criminals naturally remain hidden.

A hit is initially just a data point – triage is what makes it actionable. It starts with verification (does the data set actually concern your own company, is the password still valid?) and prioritisation by account type and exposed service: privileged accounts and VPN and SSO access before non-critical portal logins. The standard playbook covers password resets, invalidation of active sessions and tokens, checking or enforcing multi-factor authentication, analysing affected systems for suspicious logins, and searching for the source of the leak, such as an infected endpoint or a third-party provider. If the assessment reveals a significant security incident or a personal data breach, reporting obligations apply: under NIS2 Art. 23, the early warning within 24 hours, the incident notification within 72 hours and the final report no later than one month after the notification; under GDPR Art. 33, notification to the supervisory authority without undue delay and, where feasible, within 72 hours. Monitoring alerts therefore belong firmly integrated into the existing incident response process.

Without context, dark web monitoring generates a lot of noise. Combolists recycle old leaks, so many hits concern passwords changed long ago or employees who have since left; private accounts registered with a company email address say little about the security of the corporate network, and similar-looking domains lead to false attributions. No provider can guarantee completeness – closed forums and private sales escape observation. The approach is also inherently reactive: whatever is found has already been exfiltrated, and there is no reliable way to "delete" it from circulation. Without a defined triage and response process, raw hits therefore mainly produce alert fatigue. The meaningful measure of success is not the number of hits, but the time from detection to effective action.

Neither NIS2 nor DORA requires dark web monitoring by name – but it contributes to concrete obligations. NIS2 (Directive (EU) 2022/2555) requires in Art. 21(2), among other things, policies on risk analysis (point (a)) and incident handling (point (b)); company-specific threat data from underground sources provides solid evidence for these. DORA (Regulation (EU) 2022/2554, applicable since 17 January 2025) explicitly obliges financial entities in Art. 13(1) to maintain capabilities and staff to gather information on vulnerabilities and cyber threats and to analyse their likely impact; threat-led penetration testing (TLPT, Art. 26) likewise builds on threat analyses. Dark web monitoring is thus an operational building block of cyber threat intelligence – complementing external attack surface management, vulnerability management and SOC detection, not replacing them.