1. Blog
  2. Managed Detection & Response
  3. Cybersecurity incident: the right reflexes

Cybersecurity incident: the right reflexes

To make digital investigation teams work easier, the right reflexes must be adopted both before and after a cyber-attack.

The numerous incident operations that Orange Cyberdefense have been able to carry out have made it possible to identify recurring behavior of victims, the aim of which remains fast operational restoration of IT equipment. However, these actions, which are influenced by business constraints, can slow down or even block the incident’s analysis. The purpose of this article is to present and explain the common errors we have observed, as well as the good practices to apply in order to successfully carry out the incident response service, while still maintaining minimal impact on the company’s production.

Error #1: Deleting evidence

Turning off the machine without making a rational copy of the RAM*.

On an operating system, some data is persistent when the computer is restarted while others are volatile and disappear when shut down. Among these volatile data:

  • established network connections;
  • ongoing processes and their resources.

Malicious code can be executed directly from a process, without writing on the disk. For example, the MS17-10 vulnerability, better known as EthernalBlue, which exploits a flaw in the SMBv1 protocol allows arbitrary code (RCE**) to be executed directly in the Windows kernel. The attacker is then able to modify any process to divert it from its initial operation, without writing a file on the disk.

Recommended good practice
In this case, we recommend making a logical copy of the RAM before shutting down the workstation, which will allow to find the modified kernel structures and thus to identify the initial compromise vector.


Running an anti-virus scan on the entire disk without taking any precautions

The use of an anti-virus is strongly recommended, if you follow some rules of proper operation:

  • configure it so that it updates its signature database regularly;
  • allow the recovery of items that have been quarantined.

An obsolete signature base will indeed reduce the detection field of recent threats.

Recommended good practice
Following the infection, removing the threat must be put into effect as soon as possible, after systematic quarantine of any undesirable element. Indeed, the analyst will be able to retrieve the elements it contains and proceed to their identification. In most cases, this identification is finer than an antiviral signature, which is often generic. In turn, the precise identification of the family to which a malicious code belongs to can provide a cluster of clues to the initial compromise vector, as these two factors are, to some extent, correlated.


Voluntarily deleting the user’s activity data

Naturally, an employee is reluctant to share his activity history on his professional machine, whether it is his navigation history, his documents, his temporary download folder or the installed software.

Uninstalling a pirated version of the software or deleting browser history, for example, will not remove the final load of the deployed malicious code, but will slow down the identification of the source of the compromise. For example, the chronological analysis of the attacker’s actions may even be blocked when the user has deleted a phishing e-mail, and the only evidence we have is in the form of an archive of that user’s mailbox.

Recommended good practice
Keep activity history, even the malicious mail used to carry out the cyber-attack.


Error #2: Mismanagement of logs

Storing logs only on the compromised machine

By default, a server (Windows or Linux) logs its events on its own file system. The use of log outsourcing tools ensures the integrity of logs in case of machine compromise (deletion and/or modification of logs).

Indeed, an attacker with administrator rights on a machine can modify logs. A person in a hurry or one who does not need to be discreet will simply delete them, and thus remove a valuable source of information away from the analyst. A more discreet person will want to hide their traces by subtly modifying the logs. This change will greatly reduce the level of confidence and trust in the evidence.

For example, we were confronted with an incident response mission on a fleet of machines affected by a ransomware. All disk partitions had been encrypted, making them unusable.

Recommended good practice
Keep the logs on an external disk, remaining accessible in case of a cyber-attack.


Retaining logs for too short periods

To short a retention period for logs can prevent the original source of a compromise from being found.

Recommended good practice
A balance must be found between the desired retention time, the level of verbosity and the size allocated to the logs, as these three factors influence each other. It should also be noted that the level of verbosity should not be too low in order to be able to correctly use the recorded data. An overly refined log that does not contain security events is unusable.


Using formats that are too complicated to use

The retention format is also an element not to be overlooked. For example, hundreds of PDF pages containing user’s events are not the most appropriate format to send data to process. Also, screenshots or even newspaper photos taken by telephone are not ideal.

Recommended good practice
A format as close as possible to that generated by the machine is the most suitable for analysis, in order to guarantee the traceability chain.


Tools that generate traces similar to an attacker

In order to facilitate the execution of day-to-day business tasks, people may be tempted to use third-party tools. These tools are not part of the package provided by the IT team and post-mortem analysis of a machine can lead to false leads, greatly slowing down the analysis.

We think of tools like PsExec, a Swiss Army knife used by system administrators but also by attackers to make lateral movements in the company’s internal network.

Recommended good practice
Use only the security tools provided by your company’s security protocol.


Error #3: Poor delay management in the evidence-gathering phase

Delay between incident detection and evidence gathering

Companies that do not have an up-to-date inventory may encounter difficulties to physically identify a workstation that needs to be collected (for example because of a remote worker, or because they may have many sites around the world).

The main risks associated with this collection latency are the loss of the oldest traces (event log rotation).

Recommended good practice
Collect data on a regular basis and carry out inventories, updated regularly, to enable digital investigation teams to start their investigation as soon as possible.


To sum up

As we have seen, securing evidence rapidly following a compromise is essential to ensure that an incident response service is carried out under the best possible conditions. This security requires a logical copy of the RAM, as well as a physical copy of the hard disk in case of suspicion. Once this collection step has been completed, a reinstallation of the service or even the operating system can be carried out without risking the loss of evidence useful for analysis.

Before the incident, we recommend that you regularly check your ability to isolate one or more machines, as well as to read the event logs saved in a simple way.


*Random Access Memory

**Remote Code Execution