Ransomware - Identifying Patient Zero

While having a ransom note dropped within plain sight of a user is a pretty clear sign that you have been hit, a ransomware attack in its early stages may not be as immediately obvious. Malware authors often construct their ransomware to wait until encryption is complete before letting the victim know. This is usually to avoid giving them a chance to limit the effect of the attack. Much of the time, if infected within a business environment, ransomware will affect a network share, on which it methodically encrypts files it has access to, silently, and in the background.

The identification of ransomware typically begins with users alerting the IT team that files are corrupted or files with unknown file extensions are being created. It will then be up to the IT team to find the source of infection in order to contain and limit the effect of an on-going attack. Considerations for containment of ransomware are outlined in Part 3 of this series.

The following sections aim to provide IT teams with a guide to combat on-going ransomware infections, and highlight the source of an infection where it is not immediately obvious and has not been flagged by an end user.

These tasks can be run in parallel and can be followed whether the infection is on-going or looks to have ceased. We recommend using a combination of multiple tasks to eliminate false positives. 

It is best to be familiar with these tasks (like all Incident Response processes) before engaging them in a real scenario, to make sure any kinks are identified, and expected behaviour (for your environment) is known ahead of time.

Review Security Alerts

Utilising existing security tools already embedded in the environment is a must. This includes reviewing AV logs for references to ransomware, incoming email logs (for malicious attachments) and proxy logs (for malware related alerts). Whilst this could provide a lot of data, these results can be correlated with other tasks in this article to increase accuracy of results.

Appeal for Information from Users and IT Support Teams

An often overlooked aspect to determine the root cause of an incident is consultation with the IT helpdesk and/or employees. Employees may often know well in advance if something strange is occurring on their computer, before the IT team. Users should always know who they can contact ahead of time should they notice anything strange on their computer.

It is best to provide a single point of contact, either a group email address or support number, which users can report issues to. This limits a flood of calls to individual members of the IT support team, which may take time off the investigation in hand.

Things to look out for when a user reports an issue:

• Files cannot be opened/found or are corrupted;

Example: Files cannot be opened/found or are corrupted

• Files with strange extensions appearing;
• Desktop background changed to ransom note;

Example: Desktop change

• Unbootable computer displaying a ransom note

If it is shown that the affected system is a user’s endpoint, an investigator may choose to ask the following questions of the user. Did they:

• Open any new documents around the timeframes involved;
• Click on an attachment or link in an email;
• Have any software crash recently;
• Visit any unfamiliar websites; or
• Have they had any popups relating to encryption?

Example: NanoLocker

Whilst this may generate lots of noise with users reporting any computer related problems, these leads may also be invaluable to the investigation. It is generally best to let users know it is better to come forward with and report unfamiliar events, than keeping quiet and hoping the problem fixes itself.

Once the threat has been identified and the risk remediated, users should be made aware of what to look for to limit exposure in the future.

Is The File Server Infected?

From the off, it may not always be clear whether the infection is running on a file share server or a host utilising the share. The following points may be followed to determine if the infection is taking place on the file server:

• Run an AntiVirus scan on the file server;
• Look for encrypted files in locations that are not exposed as shares, such as the local users’ desktop and system drive (usually C:). If these locations are infected/encrypted, it is likely that the fileserver is infected;
• Query the process listing for unknown processes (ideally comparing against a previously taken baseline);
• If the fileserver is taken offline, does the encryption stop?

Inspect File Ownership

To encrypt a file, ransomware must open and write back to a file, this means that the file ownership will change to the user who is infected. Additionally, the ransom note will also have the permissions of the infected user account. This file ownership information can assist in identifying the user and computers on which the ransomware is running. This step is mostly conducted on the file server on which the files are being encrypted.

The quickest way to identify the owner is to open the file properties of an encrypted file and view the owner in the “Details” tab.

CryptoLocker ransom note - username identified

CryptoLocker ransom note - SID provided

PowerShell can also be utilised to query the owner of the file:

Get-Acl ‘.\2017-finance_report.doc.wncry’ | Select Owner

With a username in hand, the associated user can be contacted directly. If the infection is on-going, and it is unknown which computer the user is logged in on, the Active Directory can be queried. Whilst Active Directory does not provide a way to do this natively, the following script can be utilised to provide a list of computers where the user is currently logged on.

NB: Depending on the size of the domain, this may take a while.

$username = "infected_username"
$computers = Get-ADComputer -Filter 'Enabled -eq $true' -Properties Enabled | Select Name
foreach ($comp in $computers) {
	$Computer = $comp.Name
	$ping = new-object System.Net.NetworkInformation.Ping
	$Reply = $null
	$Reply = $ping.send($Computer)
if ($Reply.status -like 'Success'){
		$proc = gwmi win32_process -computer $Computer -Filter "Name = 'explorer.exe'"
		ForEach ($p in $proc) {
			$temp = ($p.GetOwner()).User
				if ($temp -eq $Username){
					write-host "$Username is logged on $Computer"
				}
		}
}
}

In addition, this username may be utilised within the next section “Current File Share Sessions”. The username can be used as a filter to provide a listing of current open files by that user.

Once the offending user account or host is identified, processes in Part 3 of this series can be followed.

Current File Share Sessions

If the attack is currently ongoing against a network share, a query of open files and current sessions may often be useful. This will provide an overview of users, and the files they have open, which may include files being encrypted on the network share. Multiple connections to lots of files should be treated as suspicious, as should files of unknown file types being created.

To show current sessions, open the Computer Management console. This can either be viewed from the server exposing the file shares, or using the remote connection options from within the Computer Management console.

System Tools > Shared Folders > Sessions

System Tools > Shared Folders > Open Files

Alternatively, PowerShell could also be used to query open files. If the malware has a file extension that is associated with the encrypted files, a query parameter (-Match “extension_of_encrypted_files”) can be added to limit the amount of results returned:

Get-SmbOpenFile | Where-Object -Property ShareRelativePath -Match "extension_of_encrypted_files" | Select-Object ClientUserName,ClientComputerName,Path

Additionally, Get-SmbOpenFile output can be filtered based on the username:

Get-SmbOpenFile | Where-Object -Property ClientUserName -Match "infected_username" | Select-Object ClientComputerName,Path

Correlate File Access

Correlating the variety of shares being encrypted could also be used to identify a group of users that may be infected. For example, if files are being encrypted on the finance share and only finance users have access to that share, it is likely that the source of infection is utilising a finance user account.

However if there are multiple shares affected, determining which group is the common factor is critical. For the example below, if the Finance and Sales file shares are being encrypted, it is likely that the source is a Finance user because they are the only department that have access to both shares:

Targeted Anti-Virus Definition

Your anti-virus vendor can usually help with the creation of a targeted definition update (or manual signature creation) for the file extension associated with the encrypted files. This will assist investigators in identifying what systems are affected by the infection.

The definition update needs to be set to log the alert, and not delete or quarantine the file; otherwise files that could potentially be decrypted at a later stage will be lost. This update can then be pushed to all systems, which may provide a list of systems infected and may identify the source of infection.

Whilst in contact with your AV vendor, cover the following topics so they have a good overview of the present situation:

• Describe the problems you are having – access to, and corrupted files;
• Describe any current steps taken against the infection – have you disconnected hosts from the network or identified a user involved?;
• Describe the files being encrypted, and their extension;
• Location of files being encrypted – is it on a file share or a user’s computer?; and
• Size of business and the amount of hosts affected.

Examine Internet Facing Hosts

Context's Response team have investigated many instances involving externally facing services such as Terminal Services/Remote Desktop that have been compromised with weak passwords or worming malware, then infected with ransomware.. These types of attacks are usually automated, and an attacker has the ability to scan several million IP addresses each day looking for vulnerable systems. Check for recent logins to these services, and identify any user accounts who have connectivity to the wider corporate network to limit lateral movement of the infection.

Examples of Ransomware

Throughout the investigation against a new piece of malware, Context Response analysts will often submit the potentially malicious samples to a sandbox designed to conduct quick and automated analysis. This, in many cases provides a good starting point for analytical work to be conducted. Context have a purpose built, open source tool named CAPE (Configuration and Payload Extraction) which assists in our efforts to provide a quick snapshot of whether a sample is malicious. Should an unknown executable be discovered on the network, it may be uploaded for analysis at https://cape.contextis.com/submit/.

Below are a couple of examples held on our public CAPE instance, which relate to ransomware in particular.
Most exhibit behaviours of writing files to disk, and changing file extensions of user documents:

WannaCryptor: https://cape.contextis.com/analysis/7240/
CryptoShield: https://cape.contextis.com/analysis/4509/
Locky: https://cape.contextis.com/analysis/3579/
BadRabbit: https://cape.contextis.com/analysis/3007/
NanoLocker: https://cape.contextis.com/analysis/806/

If you would like to build a CAPE instance, the project is hosted on GitHub – pull requests welcomed: https://github.com/ctxis/CAPE

A dedicated blogpost regarding CAPE is upcoming – follow the blog roll to be notified!

In Part 3 of this series we will be identifying the steps to take if ransomware has been detected in your environment...