Anomaly detection and leak prevention — how signature-based analysis helps detect internal threats

The Devil You Know

Abuse of authority, the human factor, and violation of internal regulations are all reasons why a company risks facing a critical data leak or interference with the infrastructure. For example, in 2022, a Yahoo employee, with privileged access to the company’s data, stole intellectual property to pass it on to competitors — more than 500,000 files, including source code. Similar incidents have occurred in the past with Russian companies, including banks.

The culprits of such incidents can also be intruders who have gained access to privileged accounts. Theft of usernames and passwords is one of the most common attack methods. Monitoring the activity of privileged users is facilitated by PAM solutions. With their help, you can track who, when, and from where accessed an account, maintain logs, and conduct audits. In companies with PAM, security incidents occur 48% less. Reducing the number of incidents is helped by analyzing privileged users' actions based on signatures.

Signature Analysis

The PAM infrastructure analyzes processes in privileged sessions and presents them as events. Each event is described by the following properties:

1. Subject of the action — a privileged user who performed the operation;

2. Privileged account on behalf of which the operation is performed;

3. Resource — protected system where the event occurred;

4. Action being performed or performed;

5. Object of the action;

6. Privileged session during which the event occurred;

7. Event time.

   Read also:

   • How we revived DPED: An AI project to enhance mobile photos to DSLR-quality images

As a rule, simpler models with fewer properties (for example, those operating exclusively with commands run by the user) do not allow drawing a complete picture of what is happening within a session. Consequently, an effective control mechanism cannot be built on them.

A signature is a rule by which a PAM system identifies events as dangerous and automatically responds to them. Input conditions form the first five parameters from the list above, with grouping of the corresponding objects allowed (for example, a signature may specify certain groups of users, nodes, or a certain set of files). The signature also contains the type of PAM reaction to the recorded event. For example:

• If a user from a group of contractors working with Windows tries to perform actions on a Linux resource, the system may block them and terminate the session.

• If any user attempts to execute the rm -rf / command on a Linux resource or edit the /etc/shadow file, the system will block the operation.

• If the mimikatz.exe process is launched on a Windows resource, the system will notify IT security specialists, terminate the session, and block the user.

It may also happen that within the infrastructure there arises some set or chain of events which by themselves are not dangerous and not suspicious, but together can indicate a potential threat. To handle such a situation, the PAM system is capable of performing correlation — generating a generalized event based on the original ones. Examples of such "compound" threats may be:

• Opening multiple sessions to different resources by a single user and modifying system files on them. These are signs of a potential island hopping attack development: a probable attacker, “jumping” from one “island” node to another, increases the attack surface by infecting more and more infrastructure components.

• If a user changes a large number of system configuration files on a node within a short period, this may indicate an attempt to “implant” some unwanted software.

• If a user executes commands that allow debugging of processes (for example, procdump applied in Windows environment, gcore and/or gdb on Linux). Generally, isolated runs of such software are probably not problematic and should not trigger response mechanisms (otherwise there would be many false positives). But if many such operations are observed within a few hours, including on different nodes, it is quite likely that the user is not searching for software malfunction causes but trying to extract credentials from the OS memory and processes.

• If a user opens multiple sessions to database servers, and then a large outgoing traffic appears on network interfaces, there is a chance they are “leaking” databases.

The PAM system processes such events using correlation rules. They describe how events should be combined.

Specifically, the rule indicates which new event should be generated, which chain or combination of initial events must occur for this, within what time frame it must happen, and which attributes (for example, action subject, node, session) must match in the initial events. If all conditions are met, something potentially dangerous is happening, and the PAM system generates a new event that triggers a signature.

PAM system components

The architecture of such tools depends on the specific vendor. I will describe which components may be included in a PAM system using our solution as an example.

The first component is the proxy (Proxy), which manages privileged sessions. It also checks user data against a database of known threats and blocks potentially malicious actions. The second component of the PAM architecture is the secret store (Vault). It contains encrypted passwords, keys, and other data necessary for access to privileged accounts.

The third component is the session recorder (Session Recorder). It records videos of privileged sessions, logs text commands, and registers metadata. This information is stored either locally or in network storage.

Finally, the event processor (Event Processor) evaluates user actions based on signatures and sends commands to the proxy to terminate the session if a threat is detected. All recorded incidents are also reflected in the log. This way, the cybersecurity specialist can quickly assess the situation — whether there is a danger and whether a response is needed.

If you have any questions, feel free to ask them in the comments — let's discuss.