Last Updated: 2022-03-14 07:40:07 UTC
by Didier Stevens (Version: 1)
It's about 2 years ago that Xavier wrote a diary entry ("Keep an Eye on Command-Line Browsers") mentioning that curl was now build into Windows.
And since then, we see the occasional malicious script using curl to communicate. Like the one analysed in diary entry "Infostealer in a Batch File".
I sometimes hunt for curl generated traffic (in proxy logs for example) by searching for curl's User Agent String: curl/<version-number>.
The user agent string does not tell you what operating system it is. So you have to distinguish curl requests from Linux machines and Windows machines with other info, like asset information, or TLS fingerprinting (if HTTPS is used), or looking at other traffic from the same IP, ...
And of course, curl can be configured with another User Agent String, using option -A (--user-agent).
But that is not the case in the BAT file that Xavier analysed. The malicious author uses -H options to add JSON headers, but not to change the user agent string:
So with this particular malicious script, it's rather easy to detect (especially if you are in a network environment without Linux machines): search for curl UAS.
If you are in a corporate environment, there's something else to know about curl on Windows. Although curl has many proxy options, curl is not able to auto detect proxies. In other words, if you run curl on Windows in a network environment that requires the use of a proxy to access the Internet, curl will not communicate with said proxy, unless it is configured explicitly to use a specific proxy (hostname, IP address, port, ...).
And that is the case with the malicious script Xavier wrote about: there are no proxy options in that script, so when curl is executed, it will issue a DNS request for discord[.]com, and if it gets a reply with an IP address, it will connect directly to that IP address.
Although the automatic detection of proxies has been on curl's TODO list for some years now, it is still not implemented. There have been PRs like this one, but it has not been merged into curl's code base.
This means that if an attacker wants to use curl in your corporate environment with proxies, the attacker needs to know the name/ip address of one proxy in your environment and configure that explicitly via curl's proxy options.
If your proxy requires authentitation, curl is capable to do this. Not only with explicit credentials, but also with single-sign-on. At least on Windows with SSPI.