Incident Response Playbook:

Dark Web Breaches

Contents
Introduction ............................................................................................................................................................................................ 3
1. Roles and responsibilities ..................................................................................................................................................4
2. Preparation ................................................................................................................................................................................. 5
3. Detection ..................................................................................................................................................................................... 6
4. Procedure workflow .............................................................................................................................................................. 7
5. Response playbooks ............................................................................................................................................................10
5.1 Data exfiltration playbook .................................................................................................................................................10
5.2 Account compromise playbook ....................................................................................................................................13
5.3 Remote access compromise playbook ....................................................................................................................16
6. Lessons learned from CTI findings ..............................................................................................................................19
Appendix. Diagram guidelines ..................................................................................................................................................... 21

2
 Introduction
Applying the widely-used approach to incident response from the NIST Framework, we can split
the Dark Web monitoring lifecycle into seven stages, provided in the figure below.

PREPARATION DETECTION ANALYSIS CONTAINMENT ERADICATION RECOVERY POST ACTIVITY

Prepare Define detection Investigate Isolate Eliminate Restore systems Attempt to

the people, scenarios for CTI and assess compromised components to normal determine
processes, and cases and CTI alerts systems and involved in the operation, specifically what
technologies in required take initial incident and confirm that happened, why it
the organization tools/services actions to address the everything is happened, and
required to prevent further main root cause functioning what can be
manage CTI damage correctly done to avoid
incidents recurrence
efficiently

In terms of incident management, Cyber Threat Intelligence (CTI) is considered

to be a valuable source of information about potential incidents. Meanwhile, threat intelligence
related to Dark Web findings includes additional steps for analyzing and verifying the found
information, as well as evaluating the threat level.

After the incident is confirmed, the team can respond to the threat using the relevant IR playbooks.
In this document, we will consider a Dark Web monitoring procedure involving these teams:

● CTI (Cyber Threat Intelligence)

● SOC (Security Operations Center)

● IR (Incident Response)

Depending on the structure of your cybersecurity team, these roles can be combined or split – but
the overall procedure will stay the same.

When it comes to Dark Web monitoring, it's essential for companies to consult with legal experts
and adhere to the laws and regulations applicable in their region. Additionally, transparent and
ethical practices should guide the approach to cybersecurity and data protection. If you
encounter any difficulties with a step, don't hesitate to reach out to experts specializing in Dark
Web threats and incident response. You can continue progressing through the steps, but it's
important to remember that seeking their assistance can help you address the threat more
effectively.

3
1. Roles and responsibilities
This procedure was developed as a reference for the following security roles:

Procedure roles

Incident
CTI Analyst SOC Analyst Responder

Handles and performs initial Thoroughly investigates CTI Performs the necessary
processing of CTI alerts, verifies findings, verifies threats within threat response actions.
found information, assesses threats a protected environment,
based on external information, creates an information security
passes findings to the SOC team. incident.

RACI (Responsible, Accountable, Consulted, and Informed) matrix

Action CTI SOC IR

Prepare and tune the detection mechanism R C C

Handle and evaluate CTI alerts R I I

Investigation C R I

Containment I I R

Eradication I I R

Lessons learned C C R

R — Responsible A — Accountable C — Consulted I — Informed

4
2. Preparation
Set up monitoring of the Dark Web for information related to your company:
● Names of company/subsidiaries + partners/suppliers
● Shortened names/abbreviations
● Domains of the company/subsidiaries + partners/suppliers
● IP address ranges
● Industry/geolocation

Compile a list of relevant Dark Web resources where you will look for information.

Deploy infrastructure:
● VPN, Tor
● External virtual hosts for obtaining the data
● Register special accounts on forums for intelligence purposes, since some of the forums
require an account, making it more difficult for law enforcement or researchers to access
the resource and acting as an entry barrier to casual visitors

Or use solutions designed for such tasks, like Kaspersky

Digital Footprint Intelligence.

5
3. Detection
CTI detection usually involves sending an automatic alert when certain information is found on the
Dark Web or in data dumps. The confidence of the alert can vary depending on its type.

Alert Type Ways to Monitor Effectively

Company name mentioned Tracks mentions of the company name,

1 on the Dark Web abbreviations, or short names in target forums.

Company domain mentioned Tracks mentions of company domains

2 on the Dark Web in target forums.

Company domain mentioned

Tracks mentions of company account
3 in databases of compromised
domains in dumps of compromised accounts.
credentials

Sometimes the malicious actor doesn't

Similar company profile mention the exact name but rather gives
4 mentioned on the Dark Web some characteristics of the company (region/
industry/size/revenue/system types) to hide
their identity and activity.

Same set of alerts as above, but tracking your

partners/suppliers/subcontractors/
5 Same as 1–4
anyone else with access to your
infrastructure.

Dedicated services for Dark Web monitoring, such as Kaspersky Digital Footprint Intelligence, can
monitor all the alert types mentioned in the table.

6
4. Procedure workflow
The procedure starts with the "Analysis" stage of incident response.

Preparation Lessons learned

False positive
Dark Web •User rating
monitoring
alert End •Former activity
•Presence on other forums
1. Verification •Community gratitude
•Top's of interests
•"Successful" activity
•Date of publication
•Is it related to your company
2. Threat 3. Attacker Profiling 4. Threat Evaluation or your supplier/partners?
Identification •Has it been posted before?
•Impact information (size,
CTI

format, value, volume of data)

•Deal conditions

•Accounts
Threat Attacker Threat Artifacts 5. Extraction •System
type Profile Level of artifacts •IP/Protocols
•Access type
•Data samples

6a. Continuous Dark Web monitoring 6. Raising an incident

SOC

7. Investigation

Account Data exfiltration

compromise playbook
playbook

8. Containment

Remote access
compromise
playbook
IR Team

9. Eradication

10. Recovery

7
Step Description

1. Verification
The first step in processing a CTI alert is verifying the found information.
This especially concerns the data the relevance of which cannot be confirmed directly.
Points for verification:
● Direct mentions of the company with relevant proofs.
● If the company was not mentioned, assess indirect pieces of data (mentions
of company geolocation, industry, size, revenue, list of systems).
● Find original posts – a lot of posts are reshared. If you know the resource
where the data was initially mentioned but now the post cannot be found,
it may have been deleted and the data sold.
● Compile a full list of mentions.

2. Threat identification
Identify the threat type described in the data. What information is being sold? It could be:
● Compromised accounts
● Remote access
● Company data

3. Attacker profiling
Build a new attacker profile – or update an existing one – with the following information:
● Author registration date.
● Author rating (if the forum supports such feature).
● Previous activity. Search for other messages of the author.
● Presence on other forums. Search for the same username on other resources.
● Community gratitude. Check the author's relationship with other
members. Check reactions and comments to the author's posts.
● Topics of interests. Is the current topic related to the author's main area
of interest?
● "Successful" activity. Try to find any evidence that previous offers were
successfully sold.
Based on the collected data, build or update the attacker profile.

8
Step Description

4. Threat evaluation
Evaluate the risk associated with the threat:
● Check the date of the offer.
● Check if this information was published before.
● Analyze the offer's price, data volume and value, and access or account types.
● Deal conditions: is it for free or for sale, is it sold to one buyer only.
Check if the information is related to your company or to third parties
(partners/subcontractors/suppliers/etc.).
Based on the collected data, identify the threat level.

5. Extraction of artifacts
Identify all the valuable information in the offer. Key artifacts to look for:
● Account names
● Systems and applications mentioned
● IPs/protocols
● Access type
● Data samples

6. Raising an incident
Create an incident for the Security Operation Center (SOC) team to investigate further. From
this point on, CTI findings are processed according to the SOC's standard incident response
procedures.

7—10. The next steps of the workflow (Investigation, Containment, Eradication, Recovery) are
handled by the SOC and IR teams and determined by the relevant playbook according to the
identified threat type:
● Sale of compromised accounts → Account compromise
● Sale of remote access → Remote access compromise
● Sale of company data → Data exfiltration

9
5. Response playbooks
5.1 Data exfiltration playbook
Incident

Data samples

1. Verify data samples

2. Data origin
confirmed? x no 2a. Close incident

End
Not
confirmed

yes IOCs

3. Identify source optional 3a. Run deep

system(s) forensics
Data samples
Analysis. Investigation

4. Scope the breach

4a. Notify 5. Identify system

compromise vector

Insider Attack
• Data owner and data custodian
• Compromised system owner
• Management 6b
• Stakeholders
• Affected partners 6a. Identify an insider Identify initial vector
• Regulators

6a
Vulnerability
Check insider Identify compromised
accesses hosts and accounts
Insider
access
Identify accessible
data

Compromised
Check insider accounts
access log
Containment

Next steps for insider- 7. Lock accounts 8. Isolate Vulnerability

handling procedure compromised hosts management

Tools/malware
7b. Rest passwords Accounts
Eradication

Privileges
Scheduled tasks
Services

9b. Monitor 9a. Verify 9. Eliminate attacker's

continuously eradication presence
Recovery

10. Recover

10
Data exfiltration playbook steps

Step Description

1. Verify data samples

Check the breached data samples to verify that the data belongs to your company.

2. Confirm data origin

If verification shows that the breached data does not belong to your company, the incident
should be closed as a false positive.

3. Identify source system(s)

Based on the data samples, compile a list of systems that handle this data.
Pay attention to the format, metadata, and technical fields if available (some systems can
process the same data, but in different formats).

3a. Run deep forensics

If possible, initiate digital forensics procedures for the identified systems. This will help
identify other systems compromised by the attacker.

4. Scope the breach

Identify the potential scope of compromise by analyzing the list of compromised systems
and data processed there.

4a. Notify the responsible stakeholders

according to your communication matrix. Common audiences for data breach cases are:
● System owners
● Data owners or custodians
● Management
● Affected partners
● Authorities, if the data falls under their regulations
● Clients

5. Define the vector of system compromise

Conduct a thorough investigation to define the system(s) compromise vector.
It can be either insider activity or an attack.

11
Step Description

6. Run the appropriate investigation procedures for the identified compromise vector
Based on the results of this investigation, compile a list of affected/compromised accounts
and a list of compromised hosts.

6a. In case of insider activity:

● Identify the insider.
● Identify their level of access for all company systems.
● Identify all data potentially accessible for this person.
● Check the insider's action logs to identify additional access rights and the type
of information the person requested.
● Carry out your company procedure for handling insider cases.

6b. In case of an attack, identify the initial attack vector and attack path within your network.
Compile a list of systems fully or partially controlled by the attacker.
In case of exploited vulnerabilities, carry out the proper management procedures to prevent
further exploitation.

7. Lock accounts
Regardless of the initial compromise vector, lock any compromised or insider accounts.
Also, reset passwords for the accounts before unlocking them.

8. Isolate compromised hosts

In case of an attack, isolate any hosts under the attacker's control.

9. Eliminate the presence of the attacker in the infrastructure

Perform various eradication steps according to your findings.
Verify eradication through continuous monitoring of identified IOCs. For an identified insider
threat, set up monitoring of access attempts from all insider accounts.

10. Recover
Carry out recovery procedures.

12
5.2 Account compromise playbook
Incident

1. Identify 2a. Communicate

compromised account(s) with account owners

Third party
•Email subject
•Filenames
•Corporate/partner/client/other account •File hashes
•System/application •User-agents
•domain/local/service/admin •IPs/FQDNs
•URLs

2. Check 6a. Determine

•bruteforce attempts
account types compromised
Analysis. Investigation

•abnormal authentications
data/resources
•phishing attempts
IOCs
•malware alerts

•abnormal system
3. Check possible 4. Collect IOCs and data access
compromise vectors •abnormal sources
of authentication

affected:
3a. Run deep 5. Identify other 6. Check behavior •hosts
forensics compromised accounts of compromised accounts •applications/systems
•data

•valid accounts
7. Prioritize accounts •privileges
for further response •behavior
List of accounts
Containment

8a. Communicate 8. Lock accounts

with account owners

8b. Reset
passwords
Eradication

9b. Monitor 9a. Verify 9. Eliminate

continuously eradication attacker's presence
Recovery

10. Recover

13
Account compromise playbook steps

Step Description

1. Identify compromised account(s)

Based on the provided information (access type, system), identify compromised accounts
and/or systems.

2. Check account types

● Corporate/partner/client/other account
● System/application
● Domain/local/service/admin

3. Check possible compromise vectors

Analyze authentication logs of accounts for:
● Bruteforce attempts
● Authentication anomalies (non-typical hosts/systems, authentication methods,
protocols, client applications, etc.)
● Phishing attempts on affected users
Check malware and EDR alerts for hosts associated with compromised accounts.

3a. Run deep forensics

In case accounts were compromised through system compromise, initiate forensics
procedures for the compromised systems. This will help identify the initial attack vector and
IOCs.

4. Collect IOCs
for identified compromised systems and accounts.
IOCs can be:
● Phishing email subjects
● Malware filenames
● File hashes of malware
● User-Agent strings of web clients used by malware
● IPs/FQDNs
● URLs accessed by users

14
Step Description

5. Define other compromised accounts based on the collected IOCs.

6. Check behavior and access history of compromised accounts

for anomalies in authentication methods and system or data access.
Identify affected:
● Hosts
● Applications/systems
● Data

7. Prioritize accounts for further response based on:

● Account validity
● Account privileges
● Signs of malicious behavior

8. Lock accounts
Lock the compromised accounts.

8a. Inform owners of accounts

about the compromise and any actions taken.

8b. Reset passwords

for the compromised accounts before unlocking them.

9. Eliminate the presence of the attacker in the infrastructure

Perform various eradication steps according to your findings.
Verify eradication through continuous monitoring of identified IOCs.

10. Recover
Carry out recovery procedures.

15
5.3 Remote access compromise playbook

Incident
•Accounts
•External IPs
•Service, port
•User-Agent/app version
•Authentication methods
•Geolocation
1. Identify
exposed system(s)

IOCs

2. Check
Analysis. Investigation

for anomalies/
Anomalies found 3. Check other
unauthorized access systems •Compromised system owner
•Management
•Stakeholders
No sign of external access •Affected partners
•Regulators

2a. Check 4. Notify

for insider

Sign of insider List

of accounts 5. Analyze actions 5a. Identify
of compromised compromised
accounts data/resources

2b. Insider 6. Identify system

procedure compromise vector
Vulnerability

7. Limit remote 6a .Vulnerability

access management
Containment

8. Lock
compromised
accounts

8a. Reset
passwords
Eradication

Tools/malware
Accounts
9b. Monitor 9a. Verify 9. Eliminate Privileges
continuously eradication attacker's presence Scheduled tasks
Services
Recovery

10. Recover

16
Remote Access playbook steps

Step Description

1. Identify exposed systems

Based on the provided information (access type, prerequisites), identify systems for which
access is being sold.

2. Check for anomalies/unauthorized access

For the identified systems, analyze access logs and look for anomalies.

In case anomalies are detected, collect IOCs to check for access. Here's a list of typical
indicators:

● Account names

● External IPs or IP pools

● Services, ports, protocols

● User-Agent strings, application fingerprints

● Authentication methods

● Geolocation profile

2a. Check for the possibility of an insider

If there are no signs of abnormal access to the system, conduct an investigation under the
hypothesis that access is being sold by an insider.
Identify personnel with the required level of access, and check their activities.

3. Check other systems

Look for the collected IOCs in the access logs of other systems.

4. Notify the relevant stakeholders

according to your communication matrix. Common audiences to notify about system

compromise are:

● System owners

● Management

● Affected partners

● Authorities, if the affected system falls under their regulations

17
Step Description

5. Analyze the actions of compromised accounts

Analyze the actions and behavior of compromised accounts.
Check if there are any signs that the accounts are already being used by the attackers.
Compile a list of accessed resources, systems and data by the compromised account.

6. Identify the system compromise vector

Conduct a thorough investigation to define the system compromise vector.
It can be either insider activity or an attack.

7. Limit remote access to compromised systems

Depending on the criticality of the system and access to it, different approaches can be
applied for containing the attack:
● Fully disable remote access.
● Enable two-factor authentication.
● Limit remote access by specific IPs/network segments/user groups.

8. Lock accounts
Lock the compromised accounts.

8a. Reset passwords

for the compromised accounts before unlocking them.

9. Eliminate the presence of the attacker in infrastructure

Perform various eradication steps according to your findings.

10. Recover
Carry out recovery procedures.

18
6. Lessons learned from
CTI findings
The "Post-incident activity" stage for CTI alerts includes standard "lessons learned" tasks based
on the results of the incident investigation, but also some specific steps to update threat
landscape information and adjust CTI alerts.

Dark web
incident closed

1. Perform 1a. Review 1b. Review 1c. Review

root-cause prevention remote access internal access
analysis measures rights rights

2a. Update
2. Update detection
threat model mechanisms

User-caused
or user-targeted
threat?
3a. Plan
security
awareness
training

4. Update
alert/incident
context enrichment
procedure

5. Update
response plan

End

19
Post-incident activity playbook steps

Step Description

1. Perform root-cause analysis

of the circumstances that led to the incident.
This step includes listing which measures and controls are missing and preparing an action
plan to prevent similar incidents occurring in the future.
Key elements:
● Prevention measures
● Remote access rights
● Internal access rights

2. Update the threat model base

with new information. Update threat levels.
This involves:
● Updating severity levels for specific threat actors
● Reviewing the threat profile for affected systems
Also, this step often involves designing and implementing new detection mechanisms.

3. Analyze the nature of the threat and whether it could be caused by an internal user error.
If yes, plan an appropriate awareness training.

4. Update alert/incident context enrichment procedure

Analyze what data was missing at each step of the CTI alert and incident processing. Pay
special attention to steps involving cross-team information exchange.
Plan actions to provide the required context next time.

5. Update the response plan

Update the current procedure and playbooks according to identified flaws or required
improvements.

20
Appendix. Diagram guidelines
The following table provides a reference for the diagram elements used in the playbooks above.

Category Element Description

Event Start event – indicates where a particular playbook starts.

Event End event – indicates where the playbook ends.

Task An integration task that can be automated.

Task A manual action carried out by the T1/T2/T3 analyst

according to some particular instructions.

Task A task assigned to an analyst or other participant.

Gateway
x Only one of the paths can be taken based on the workflow
logic.

Gateway Multiple paths can be taken without an order of priority.

Sub-procedure A collapsed sub-procedure which is executed separately

to assist the playbook flow.

www.kaspersky.com/

www.securelist.com

© 2023 AO Kaspersky Lab.

All rights reserved. Registered trademarks and service

marks are the property of their respective owners

21