Chapter 2: ManageEngine's plan of action

Drafting policies

Organizations should have two things, an incident response policy and a ransomware prevention and response checklist (like this one). These are non-negotiable. What should your incident response policy include? And, what other ransomware-related policies should you have? Let's look at a few types:

• Incident response policy: This is the main guide to handling ransomware. A well-defined policy will dictate what constitutes a ransomware attack, roles and responsibilities, concerning standards or laws, order of notification, processes that should be carried out, the time frame for each process, and what needs to be documented and how it should be stored.
• Ransom demand policy: Do you pay the ransom or not? Review the reports to assess the value and sensitivity of compromised information, laws the information is bound by, ransom amount, recovery or restoration costs, and how much damage it would cause the organization. The board should make such decisions after thorough evaluation of these parameters.
• Ransomware prevention policy: This covers your boilerplate do's and don't's, learnings from past incidents (if any), and what employees must do to reduce the possibility of incident occurrence. Employees must be advised to follow the best practices (read Chapter 3) recommended by the organization.

Roles and responsibilities

Every organization must have a cybersecurity readiness team to manage incident response (IR). To execute an IR plan, you require a chain of command and clearly documented roles and responsibilities that employees can step into the moment disaster strikes.

Our framework

ManageEngine employs a four-step approach to tackle ransomware attacks: centralize, detect, resolve, and recover.

Step 2: Detect

Ransomware is hard to detect while it's in recon mode. It's discovered when the malware is in some stage of execution like encrypting files, locking the system, or in some cases, displaying the ransom note. At this juncture, the next step is to identify and isolate the infected systems.

Anti-ransomware solutions use rules or scores to determine whether an entity is engaging in malicious or routine activities. Let's take an example. Software installed on a device only takes information related to its needs, which means it has a low risk score. A malicious software sent by an attacker won't know the difference between useful information and irrelevant files, so it collects everything available for the attacker to evaluate later. When the anti-ransomware solution spots this kind of activity, like an EXE accessing multiple files across folders, the risk score goes up. If a file modification or encryption activity resembling a ransomware attack is registered, an alert will be triggered. Alerts that have the same pattern across devices are then automatically grouped together and reported as an incident along with a list of the devices and files involved.

Detection also includes root cause analysis (RCA). To proceed with resolution and recovery, you should be able to answer questions like:

• How did the ransomware enter the network?
• What kind of attack was deployed?
• Is the hacker trying to communicate? If yes, where and how?
• Can we identify the variant based on the techniques used?

A number of solutions refer to MITRE ATT&CK®: the Holy Grail of ransomware protection. MITRE, the non-profit behind the framework, refers to it as a "globally accessible knowledge base of adversary behavior." MITRE ATT&CK is free for all and contains information on almost every attack technique possible.

Some attack techniques mentioned in the MITRE ATT&CK matrix for enterprises.

Indicators of compromise (IoCs) and indicators of attack (IoAs)

IoCs are digital footprints or forensic evidence that suggest a network breach. Examples include IP addresses, multiple requests for the same file, and irregular traffic.

IoAs highlight ongoing events that could be a security breach. These focus on the intention and technique of attack. Examples include interactions between public servers and internal hosts, persistent communication between internal hosts, and unauthorized system changes.

IoCs	IoAs
Reactive and static in nature	Proactive and dynamic in nature
Indicates system has been compromised	Indicates an attack is underway
Primarily used for initial triage and providing valuable insight on attacks that have occurred	Beneficial in real time, especially in zero-day exploits with limited background information

IoCs and IoAs put together can provide better clarity on ransomware attacks.

Step 4: Recover

Restore clean data that hasn't been in contact with the malware from your backup. Check for IoCs in the backup before you do so. ManageEngine's UEM solution implements the anti-ransomware feature to obtain shadow copies of all the files on an endpoint periodically, even when it is in use. In case of an incident, the actions carried out by the malware are reversed and all infected files are reverted to the most recent copy of the file stored.

If you have encrypted files, consult websites like No More Ransom to find out if decryptors are available for the ransomware strain that affected your organization. What happens if you're unable to decrypt a file? Store a copy of the encrypted file and wait. There's a good chance you may find the decryption key somewhere down the line. There's also a possibility of re-entry so do not lower your guard. Increase vigilance and stay alert even after returning to normalcy.

Decryptor key from the No More Ransom project

Sound like a lot? Here's a decision tree to make your ransomware response decision-making process a little easier.

Ransomware incident response decision tree

Use case #1: Blocking ransomware

Here's a scenario where our anti-ransomware solution detected and successfully thwarted a potential ransomware attack. An employee received an email that mimicked a message from a lead. This contained an EXE file attachment. Unfortunately, the employee believed it to be legitimate and clicked on the attachment, which allowed the ransomware to enter the system.

The malware, a CryptBot, had two motives. First, it had to bypass the EDR solution. Second, it had to encrypt files in the system. A CryptBot uses a dropper technique that can schedule tasks or run a file that can encrypt other files. Once the malware entered the system, it worked alongside system start or reboot and executed a series of commands. At this point, the anti-ransomware tool triggered an alert. Because the IT team has instructed the tool to block any suspicious actions automatically, it stopped the parent and child processes, preventing the ransomware from establishing its presence.

The alert triggered by the tool was raised as a ticket on our help desk. Since the detected suspicious activity was in fact ransomware, the sysadmin contacted the affected user and collected the device. Their first responsibility was to verify if the EDR or anti-ransomware solution was active on the device. After confirmation, the device was sent to the level-2 technician for file and device analysis.

The sysadmin conducted a final device check to verify a clean bill of health: The system is clean, all software is up to date, and any vulnerabilities have been patched. The device was then returned to the user and the ticket closed.

Use case #2: False positive

A hurdle we've faced with building our own tool is identifying and reducing the number of false alerts. When a user initiates a program that the tool identifies as suspicious, it triggers an alert and stops the program execution. For instance, some of ManageEngine's solutions use remcom.exe, a remote communication file. It is often used in remote product support. Remcom occasionally deletes Volume Shadow Snapshot (VSS) copies—an action ransomware also relies on to inhibit system recovery. This creates confusion in the anti-ransomware tool's rule engine, causing it to flag OpManager's activity as an incident.

The sysadmin examines the ticket raised and evaluates four main parameters in each situation:

• directory
• file hash (hash whitelisting)
• source
• parent process

If the file is legitimate, the program is allowed to run. The sysadmin modifies rules in the rule engine by creating an ML-based exclusion for the specific path and pattern used by the program. This prevents repeated false positives, and the technician can close the ticket.

Use case #3: Ransomware infected

Let's take an example where the EDR and anti-ransomware solution fails to detect the malware until it begins its attack. A user accidentally downloads malware (via a suspicious link) which deletes original files and encrypts copies. The user only realizes this when they're unable to access their files. The hacker then displays a ransom note threatening to withhold the decryption key and erase the files if a ransom is not paid.

The user notifies sysadmin who then isolates that device from the network before the malware moves laterally across systems. Here, two factors must be evaluated:

• Are there clean images of the infected data? - Yes
• Do the files contain customer details or any other sensitive/critical information? - No

Since there are untouched copies of the data in question, the board decides not to pay and proceeds with recovery and restoration instead. The sysadmin uninstalls the system and conducts a complete wipe. Upon re-installation, the tool reverses any actions taken by the malware and attempts to recover the original files or restore files from backup. If the technician can identify which strain of ransomware has affected the system, they can attempt to find a decryption key and unlock files.

In some cases, the tool deletes the malicious file but the scheduled tasks (if any) may be left behind. The task can continue its goal and encrypt more files. So, the technician's job doesn't end with verifying malware eradication. They also have to confirm that the tasks have been deleted and the system registry is clean. This can be done with the help of sandbox testing. A sample of the malware can be submitted to a testing solution that simulates the malware. After running the sample in a contained environment, it provides a detailed analysis and behavior graph on how the ransomware works and actions it takes. The input is examined at a machine level which helps the technician look for areas where the ransomware may have caused damage.

After a final scan, the device is returned to the user. The process is completed with a thorough analysis and report, documenting the attack, its effects, and solutions.