Enterprise Dark Web Monitoring and Threat Intelligence: A Practical Implementation Guide

Enterprise cybersecurity in Türkiye has undergone a fundamental shift over the past three years. Attacks are no longer observed as they arrive, but hours before — ransomware groups negotiate on leak sites weeks before announcements, initial access brokers sell VPN access, credential marketplaces circulate 50 million Turkish user records. Reactive defence is no longer enough; proactive threat intelligence has become the spine of corporate security. The KVKK 72-hour breach-notification obligation, the BDDK Information Systems Regulation's threat-monitoring requirement, the TI requirement in cyber-insurance policies — all make this shift mandatory.

Within our threat intelligence, OSINT research and data fusion services we have built or operated dark web monitoring + TI programmes for 14 enterprise customers in the last 24 months — across finance, healthcare, energy, e-commerce and the public sector. In this article we walk through the seven practical steps of an enterprise dark web monitoring + TI programme in order: scope definition, source map, collection architecture, IoC normalisation and scoring, leak-case response flow, KVKK-compliant processing, continuous maturity.

1. Scope definition — what to monitor, what not to

The first question is not tool choice; it is what are we monitoring?. The wrong scope produces either signal pollution (5,000 alerts a week, real threats lost) or blind spots (a critical leak learned from the news six months later).

Five core monitoring areas:

Area	Key queries	Source priority
Credential leak	Org domain + employee emails	Combo lists, breach dumps, COMB v2/v3
Brand abuse	Brand name, product name, logo, domain variants	Phishing kit markets, typo-squat domains
IAB listing	Org name, sector, "VPN access", "domain admin"	Exploit.in, XSS, RAMP, BreachForums
Ransomware leak	Org name, customer/supplier names	LockBit, Cl0p, BlackBasta, ALPHV leak sites
Source code / IP leak	Repo URL, GitHub org, internal hostname	Paste sites, GitHub leaks, dark-forum uploads

Secondary areas (extensions): executive names (CEO/CTO doxxing), customer lists, vendor info, internal documentation, API key/cert leaks.

Keyword discipline: a generic term like eCloud produces thousands of false positives; organisation-specific terms like eCloud Tech, e-cloud.web.tr, @e-cloud.web.tr yield real signal. A negative-keyword list is also mandatory (e.g. exclude the generic eCloud Computing).

Practical recommendation: start the first pilot with 5 areas × 30-50 keywords. After 8-12 weeks run an alert-ratio analysis and calibrate. Mature enterprise level is around 80-150 keywords.

2. Source map — where the dark web actually lives

The dark web is not monolithic; it's an ecosystem of distinct networks + forums + marketplaces.

Main networks:

• Tor hidden services (.onion): the largest dark-web ecosystem. ~85% of ransomware leak sites, forums and marketplaces live here. Access: Tor browser or programmatic (Stem library, Python).
• I2P: Tor alternative, smaller but anonymous. Some Russian forums and markets.
• Freenet: niche, academic + activist; low priority for corporate monitoring.
• Clear web dark forums: BreachForums, RaidForums (down), nulled.to, etc. Not on Tor but carrying the dark-web culture.
• Telegram channels: in 2022-2024 there was a big migration of dark-web actors to Telegram. ALPHV/BlackCat, LockBit, credential vendors, IABs are active on Telegram. In modern monitoring, Telegram is at least as critical as Tor.
• Discord / Matrix: secondary comms, invite-only servers.

Main ecosystems:

Ecosystem	Type	Access	Content type
Exploit.in	Forum	Tor + membership	IAB, malware, exploits
XSS.is	Forum	Tor + membership	Russian, IAB, exploits
BreachForums (v3)	Forum	Clear/Tor	Data leaks, combo lists
RAMP	Forum	Tor + reputation	Ransomware-related
LockBit leak site	Leak	Tor	Victim list + samples
Cl0p leak site	Leak	Tor	Victim list + countdown
Genesis Market (down) → successors	Market	Tor	Bot access, browser fingerprints
Russian Market	Market	Clear/Tor	Credentials, cookies, RDP
Telegram: ALPHV / LockBit / Conti rebirth	Channel	Telegram	Pre-leak announcements, recruitment

Language distribution: Russian 45-55%, English 30-35%, Chinese 5-8%, Turkish ~2-4% (growing). Attack coordination against Turkish organisations is mostly in Russian or English; the Turkish-language community sits more around card fraud and identity markets.

Source currency: forums are closed and reborn every 6-18 months (BreachForums v1 → v2 → v3 → v4 pattern). The monitoring list must stay alive; a monthly source-audit meeting is standard.

3. Collection architecture — SaaS, self-hosted, hybrid

Three architectural options:

A — SaaS-based (fastest start)

Provider	Strength	Enterprise licence (annual)
Recorded Future	Broad coverage, automated IoC, premium feeds	USD 60K-300K
Flashpoint	Insider threat + extremist + fraud	USD 50K-200K
Intel 471	IAB + ransomware specialist	USD 40K-180K
KELA	Israel-based, IAB + leak	USD 30K-150K
Searchlight Cyber (formerly Searchlight)	UK, dark-web specific	USD 35K-150K
DarkOwl	Data size + index	USD 25K-100K
Flare	Modern UX, SMB-mid friendly	USD 15K-80K

Pro: operational in 1-2 weeks, minimal team training, the vendor keeps adding sources. Con: organisation data flows to the vendor (DPA + KVKK review mandatory), scope limited to what the vendor offers, pricing scales aggressively.

B — Self-hosted (max control)

Stack:

• Tor proxy (privoxy, torsocks) + Python Stem library
• Crawler: Scrapy, Selenium (for forum login), custom
• Storage: Elasticsearch + S3 backup
• Visualisation: Kibana, Grafana
• Alerts: ElastAlert, Watchman, custom Lambda

Pro: full data control, ideal for KVKK, fully customisable source list, no vendor lock-in. Con: build 3-5 months, ops 1-2 FTE, coverage continually regresses (new sources added by hand), forum-account management is complex (CAPTCHA, reputation, OPSEC).

C — Hybrid (recommended enterprise pattern)

SaaS for broad coverage (Recorded Future or similar), self-hosted custom crawlers for critical sources, unified on MISP. 11 of the 14 projects we built in the last 24 months chose this pattern.

Topology:

[SaaS provider API] ──┐
                      ├──> [MISP] ──> [SIEM] ──> [SOC + SOAR]
[Self-hosted Tor crawler] ──┘                       │
                                                    ▼
                                            [Alert dashboard + analyst review]

MISP (Malware Information Sharing Platform, open source) normalises all IoCs, deduplicates, applies scoring, exchanges with sector sharing groups (closed MISP for BDDK-member banks, TÜBİTAK BİLGEM-USOM coordination). Membership is free + organisational registration.

OPSEC is critical: the dark web crawler should run from a separate VPN/proxy + dedicated VM, not from the org IP block. Forum accounts must not use employee names/emails — use a separate identity (persona). Skipping this detail turns the organisation itself into a target.

4. IoC normalisation, scoring, lifecycle

Raw data is just data; unprocessed IoCs turn the SIEM into garbage (thousands of false positives). Three layers:

Layer 1 — Normalise: IoC formats (IP, domain, URL, hash MD5/SHA1/SHA256, email, BTC address, etc.) are converted to STIX 2.1. MISP performs this conversion by default.

Layer 2 — Scoring: each IoC gets a source-trust + age + context score:

Factor	High	Medium	Low
Source trust	Premium TI (Recorded Future, Mandiant)	Open feed (OTX, Abuse.ch)	Forum scraping, unverified
Age	<7 days	7-30 days	>30 days (expire)
Context	Signed malware sample + reverse engineered	Forum-post mention	Name reference only
Confidence	90-100	60-90	<60

Low-scoring IoCs do not go to the SIEM (visible on the dashboard only); high-scoring trigger automatic block/quarantine + alert.

Layer 3 — Lifecycle (TTL):

• High-confidence IP: 30-day block
• Medium confidence: 14 days
• Phishing domain: 7 days (short-lived)
• Malware hash: permanent (hash doesn't change)
• Without an auto-expire mechanism the SIEM fills up with stale IoCs in 6 months.

False-positive feedback loop: when a SOC analyst marks an IoC as false positive, its MISP score is lowered and it stops alerting. Without this discipline the team falls into "ignore all alerts" mode in 3 months (alert fatigue) — and real threats are missed.

Our SOC operations article details this IoC-SOC integration.

5. Leak-case response flow — what to do once you find it

The real value of monitoring is in the response to the leak found. If you do nothing after finding, value is zero. Five typical scenarios + response flows:

Scenario 1: Employee credentials in a combo list

1. Verify: is the email + password pair real? Have I Been Pwned API + internal AD check.
2. Affected user identification: how many employees, which systems.
3. Action: force password reset, mandatory MFA, session invalidation, 30-day strict login monitoring.
4. KVKK notice: inform the employee (Art. 10), if needed file 72-hour breach notification with the Board (Art. 12).
5. Target time: alert → full action within 4 hours.

Scenario 2: Org name in an IAB listing

1. Forum-post analysis: type of access (VPN, RDP, domain admin, web shell), price, seller reputation.
2. Internal audit: VPN logs + AD audit + remote-access logs for the last 30-90 days.
3. Hypothesis verification: real compromise or bluff?
4. Action: rotate all remote-access credentials, force MFA, firewall reset, mobilise IR team.
5. Target time: alert → full action within 24 hours (IAB to ransomware is 7-21 days on average, but hurry).

Scenario 3: Org name on a ransomware leak site (sample not yet published)

1. Verify: is there a countdown, which group (LockBit/Cl0p/BlackBasta).
2. Internal forensics: is there an active breach?
3. Crisis team: CEO + CISO + legal + PR + IR vendor meeting.
4. Negotiation decision: contact vendor (Coveware, Mandiant, etc.) or not.
5. KVKK notice preparation: customer/employee notification text, Board notification.
6. PR preparation: if a public statement is needed.
7. Target time: alert → crisis meeting within 2 hours.

Scenario 4: Brand abuse (phishing domain)

1. Domain takedown: registrar abuse report, hosting provider, USOM coordination in Türkiye.
2. Browser blocklist: Google Safe Browsing, Microsoft SmartScreen submission.
3. Customer notice: warning via the relevant channel.
4. Target time: alert → takedown submission within 8 hours, actual removal in 1-7 days.

Scenario 5: Source code / API key leak

1. Verify: is the key live?
2. Immediate revocation (within seconds).
3. Audit: 90-day key-usage log, any anomalies.
4. Code repository scrub: BFG Repo-Cleaner or similar to clean commit history.
5. Target time: alert → revocation within 15 minutes.

Our incident response service provides playbooks + tabletop exercises for these five scenarios.

6. KVKK-compliant processing — when you hold leak data in your hands

Dark web monitoring contains personal data: employee emails, leaked customer lists, phone numbers, national ID, IBAN. Downloading and processing this data is a KVKK processing activity; legal basis + security measures are mandatory.

Seven disciplines:

1. Legal basis in writing: Art. 5/2 legitimate interest (organisational security) or processing for user notification purposes. Policy document + VERBİS Data Controller registry.

2. Data minimisation: only organisation-specific fields are taken from a leak; generic records (a competitor's employee data) are dropped. Non-organisation PII is not retained.

3. Access control: the dark-web data store is accessed only by authorised security analysts (max 3-5 people) under RBAC + MFA + audit log.

4. Retention period: 90 days hot (alert + investigation), then a hashed reference + 12-month archive (metadata only: "this user appeared in source Y on date X"; raw data deleted).

5. Encryption: all storage (Elasticsearch index, S3 backup, MISP DB) AES-256 at rest + TLS 1.3 in transit.

6. Cross-border transfer: SaaS-vendor data locations are typically US/EU. DPA + Standard Contractual Clauses in the contract, Turkish translation.

7. Breach-notification integration: if the leak you find shows a real KVKK breach (organisation customer data leaked), the organisation files with the Board within 72 hours + notifies affected users. The process is automated as notification → record → evidence chain.

Our OSINT research service integrates these seven disciplines into organisational policy together with the contract annex.

7. Continuous maturity — metrics, threat hunting, team training

Dark web monitoring + TI is not a set-and-forget system; it is a living discipline. The real work begins after the first six months.

KPI dashboard (weekly):

Metric	Target	Meaning
Alert volume	Trend tracking	Spikes signal tuning needs
Mean Time To Detect (MTTD)	<24 hours	Leak published → noticed
Mean Time To Action (MTTA)	<4 hours (P1)	Noticed → first action
False-positive rate	<20%	High → keyword/scoring tuning
Verified leak count / month	Sector baseline	Effective coverage indicator
Sources monitored	Grows continuously	Coverage growth
Takedown success rate	60%+	Brand-abuse operation quality

Threat hunting (proactive, not alert-driven):

• Monthly hypothesis: "Which sector has FIN7 been targeting in the last 6 months? Are we close?" → MITRE ATT&CK Groups + dark-web search → organisation-specific risk assessment.
• "Which of our suppliers appeared on a leak forum in the last 90 days?" → third-party risk surfacing.
• "Which former-employee credentials still appear active?" → AD audit + revocation cycle.

Team training:

• Monthly dark-web update brief (new forum, new group, new TTP).
• 6-month certification target: SANS FOR578 (Cyber Threat Intelligence), GIAC GCTI, CREST CRTIA.
• Annual conferences: SANS CTI Summit, FIRST Conference, Black Hat, BSides Istanbul.
• OPSEC drill: every analyst does a personal OPSEC audit every 6 months (email, social media, persona separation).

Post-incident review: a blameless retro after every P1 leak — what we caught, what we saw late, which source was missing, which keyword to add. Retrospective notes go into a closed wiki.

Practical summary — starting checklist

The correct order for your first production dark web monitoring + TI programme:

1. Scope definition: 5 areas × 30-50 keywords. Negative keywords mandatory.
2. Source map: Tor + Telegram + clear-web dark forums. Don't skip Telegram.
3. Collection architecture: SMB → SaaS (Recorded Future / Flare / KELA); enterprise → hybrid (SaaS + self-hosted + MISP).
4. OPSEC: dark-web crawler from a separate IP + persona; no org IP/identity.
5. IoC scoring + TTL: source trust + age + context. Low scoring doesn't go to SIEM.
6. MISP: all IoCs in one hub; sector sharing (BDDK, USOM) active.
7. Response playbooks: written for the 5 scenarios (credential / IAB / ransomware / brand abuse / source code).
8. KVKK policy: legal basis, retention, encryption, access control, breach-notification integration.
9. KPI dashboard: weekly MTTD/MTTA/FP; monthly trend review.
10. Continuous maturity: threat hunting (weekly), training (certifications), post-incident review (after every P1).

This list is the minimum discipline. On top come sector-specific additions (BDDK Threat Intelligence Regulation compliance for banks, additional special-data protections for healthcare, classified-information handling for defence). The value of dark web monitoring is not in owning the tools; it is in turning what you find into action, fast, honestly and lawfully.

Our team in Şanlıurfa Karaköprü has built and operates dark web monitoring + TI programmes in finance, healthcare, energy, e-commerce and the public sector through threat intelligence, OSINT research and data fusion services. For an enterprise dark web monitoring pilot, TI programme assessment or maturity audit of your existing monitoring system, you can reach us through the contact form — the first assessment call is free of charge.

---

eCloud Tech — A team based in Şanlıurfa, Türkiye, working on enterprise software, AI, blockchain and cybersecurity. Building Tomorrow.