System compromise: assessing and containing an incident

📑

First, the compromise must be assessed, then the severity of the incident, its scope, its impact, and its criticality. Let’s see how.

System compromise assessment

Prerequisites for assessing a system compromise

To assess a system compromise, those involved must have access to the administration, information system, and security equipment monitoring tools. They must also be aware of the organization’s business priorities and the list of emergency contacts. External assistance may be required to assess the incident.

In addition, the victim organization must open a logbook and ensure that it is stored outside the compromised information system, on an external medium, a shared file in the cloud, in paper format, etc., and record the actions taken to respond to the incident. The log must include:

The date and time of the action or event
The name of the person or department that detected or reported the event
A detailed description of the action or event

Its purpose is to record the timeline of the incident’s handling, track the steps taken to remedy it, and evaluate their effectiveness. It must also include any actions taken to connect to the compromised endpoints.

But first, how do you define a system compromise? And then, how do you assess the scope of the incident, its impact, and its criticality?

Assessing system compromise

This step allows you to identify the system affected by the incident, which parts of the information system are affected, to anticipate disruptions to the organization’s activity, and to take the appropriate measures to resolve the incident.

It also involves defining the parts of the information system that have been compromised, whether resources are affected, whether there are risks to other connected systems, and whether the organization’s activity may be disrupted.

System compromise: assessing the incident

Identify the affected system

The system can be identified by its IP address, and it is necessary to check whether the IP subnet concerned is part of the addresses used on the information system, or whether the report points to a machine that may be masking others (router, proxy, DNS server, firewall, or NAT).

The system can also be identified by the endpoint name, or from information collected by a SOC or EDR that may have triggered an alert.

Collect basic system configuration information

All information relating to the system configuration is also essential for identifying it: OS and version, time synchronization system (if any), business applications installed, presence of potentially vulnerable applications, etc.

Confirm the validity of the system compromise report

To avoid wasting time on steps related to a false alert, certain points deserve further verification, particularly the temporal consistency. It is necessary to confirm whether the architecture and configuration of the system at the time of the report correspond to the information collected in the report, the consistency of the timestamp, the fact that the system was indeed in production at the time of the report, and so on.

Confirming system compromise

To confirm the incident, information from logs is useful for searching for events or comparing the information in the report with:

Information from the firewall, CDN, or proxy servers if the report is a network flow
EDR or antivirus data if the report concerns illegitimate behavior
Traces related to flows
Any changes to services exposed by the system
Illegitimate use of user accounts
Cloud infrastructure logs
Etc.

Assess the scope of the system compromise

Once a system compromise has been confirmed, the scope of the incident can be assessed by identifying the function and connectivity of the compromised asset(s): workstation, server, VM, hypervisor, Internet connection, etc. This phase also makes it possible to define more precisely the part of the information system that has been affected, and even whether administrative resources are involved.

Assess the impact and urgency of resolving the incident

Attackers taking control of an endpoint can have consequences for business activities or critical services, and for business operations. It can lead to risks to the image of the organization, data, or even people, and have an impact on regulatory requirements. These factors also help to define the degree of urgency with which to respond.

Depending on the chances of escalation, the risks to the organization’s business, and to security measures on the whole, the incident can be classified as a common anomaly, minor or major incident, or even a cyber crisis. The next steps involve containing the system compromise.

Containing a system compromise

Expert advice

When containing a system compromise, local connections, RDP and SSH, or any interactive session with the compromised device should be avoided, especially with a privileged account!

If remote actions are impossible, it is better to consider:

Actions via EDR or remote management software that do not open the system (such as Remote Monitoring and Management tool – RMM)

A local connection via a physical, out-of-band, or hypervisor console with an administrator account that is local only to the affected system

As a last resort, a network connection that does not compromise the administrators’ passwords (PowerShell Remoting, Windows Remote Shell, or RDP in Restricted Admin mode)

All these connection actions must be logged in the logbook.

Limit the spread of the compromise

Freeze the situation

If the unavailability of the infected machine does not pose a problem for the rest of the information system and the organization’s activity, this machine must be shut down with explicit notification that it needs to be kept off or paused. It can also be disconnected from the network physically or via an EDR.

If the compromised machine cannot be made unavailable, it must at least be isolated from the internal network to prevent the attack from spreading to the rest of the information system.

Business teams need to be notified of the potential impact of the operations in progress.

Reset user credentials suspected of being compromised

All user and administrator accounts in the suspected domain must be disabled.

Accounts with the same name on other machines and those used on infected machines, as well as cloud accounts, must be reset, and account sessions revoked. Note: if the machine requires a second factor, it must be suspended for the duration of the investigation.

Finally, if the compromised server contains private SSH keys, then the public keys elsewhere in the network must be deleted.

Reset secrets related to the infected machine

If the infected machine contains certificates, they should be revoked and the revocation verified.

If it contains API tokens, the tokens must be revoked and, if necessary, new ones deployed on other instances sharing the same key.

If the machine is registered in an Active Directory, the machine account must be disabled.

Preserve the organization’s essential assets

Backups must be secured in the event of an incident, both to restore information system services and to assist with investigations. Access must be validated, and if there is a risk of compromise, access must be restricted.

Preserve evidence in the event of system compromise

Preserving traces may involve:

A virtual machine, in which case a snapshot of the machine in pause mode must be taken, including memory export if available
A physical machine, in which case a forensic sample can be taken using an EDR, a forensic agent, the administration service, or a sampling tool

Traces from equipment logs are also necessary: firewall, VPN gateway, proxy, CDN, EDR, antivirus, AD, etc. The longest possible data retention period and verbosity will be assets for analysts.

At this stage of containment, the attacker’s actions cannot yet be identified precisely. Only an in-depth analysis will allow these elements to be understood, and this may require the intervention of external resources such as a CERT or a CSIRT.

Go deeper into incident analysis, and see all our EDR can do to help: