Malicious DNS Queries by APT - A Case Study

Hello Everyone,

Ever got any malicious URLs? Couldn’t figure out what’s going on?

This email documents suspicious DNS query attempts which were allegedly malicious according to an Advisory shared by the Australian Government.

Background: 

The Australian Govt. shared an advisory with a customer which has a very competent team of IT security experts.

The only SHA value mentioned in their advisory was a DLL which basically tried to download additional code from one or more C2s, allegedly the shellcode for Meterpreter so that it can establish a connection back with the attackers to further instruct the listener to carry out additional instructions. The URLs were all down and we could never lay hands on the listed DLL which was not present on the machine exhibiting suspicious behaviour. 

But the customer’s network appliances were seeing a several machines trying to resolve some of the above listed URLs. Although the URLs were down, this sparked a curiosity for the customer to find out the root cause of these requests.

At first I wasn’t entirely convinced that the DNS queries are actually happening. But they were quite adamant and got me proof in the form of a live packet capture. 

17:39:39.350792 PortA, IN: IP 172.16.100.253.25507 > 8.8.8.8.53: 23201+ A? sql.juliettemeier[.]com. (39)

17:39:39.398681 PortA, OUT: IP 8.8.8.8.53 > 172.16.100.253.25507: 23201 ServFail 0/0/0 (39)

17:39:39.582570 PortA, IN: IP 172.16.100.253.6967 > 8.8.4.4.53: 22044+ A? api.valentineharper[.]com. (41)

17:39:39.631429 PortA, OUT: IP 8.8.4.4.53 > 172.16.100.253.6967: 22044 ServFail 0/0/0 (41) 

and logs from their DNS server - 

2019-07-05 10:56:17 query (127.0.0.1 udp) api.valentineharper[.]com IN A

2019-07-05 10:56:17 local api.valentineharper[.]com 3600 IN A 127.0.0.1

Investigation:

Malware Avengers, assemble – 

• Autoruns – I couldn’t spot any suspicious malware load-points under Run Keys, Scheduled Tasks or WMI.

• Process Monitor – Surprisingly, this tool did not help me with the process which was sending out the UDP REQUEST packets for a DNS resolution of the malicious URLs in question.

• Wireshark – This tool is process agnostic, hence I could only see and confirm the attempts of reaching out to the URLs in question.

• Sysmon – The latest DNS logging feature in v10 of this tool wasn’t applicable for Windows 7.. drat.

• Netmon – Same story as Wireshark – Ideally, we should’ve been able to identify the process behind the DNS requests but I’m suspecting the resolution failure to be a cause of incomplete logging.

The machine was protected with Sophos Enterprise Console which has been deemed obsolete and we are advising customers to migrate towards Sophos Central.

So the constant to and fro of these logs and evidences were not getting us anywhere. Desperation kicked in and I decided to do what we call Deep Dive IR/Threat Hunting. This is not a general course of action but as the advisory was shared by the AU government themselves for the Automotive Industry coupled with the fact that this customer is an automotive firm, I decided to go at this malware all guns blazing. 

But those URLs were down DNS resolution was failing. The active malware was cleverly hiding itself and attempting to contact certain URLs but they were down. I decided to respond to these requests using Imaginary C2. This tool has been developed by one of our brilliant Labs Researchers. [https://github.com/felixweyne] 

“Imaginary C2 is a python tool which aims to help in the behavioral (network) analysis of malware. Imaginary C2 hosts a HTTP server which captures HTTP requests towards selectively chosen domains/IPs. Additionally, the tool aims to make it easy to replay captured Command-and-Control responses/served payloads.”

As soon as there was an active exchange of network traffic between the Client and a known malicious server, Sophos immediately gave us a lead.

But it seemed to be a dead-end. Whaaaa.. A Digitally Signed Executable by Adobe having Zero detections on VirusTotal!

Cross-referencing the AV logs at C:\ProgramData\Sophos Anti-Virus\Logs\SAV.TXT for more clues, 

20190807 162345 File "C:\program files (x86)\microsoft cdo for windows library\cdosys.exe" belongs to virus/spyware 'C2/Generic-B'. Threat ID: 1175017554. No action taken.

20190807 162354 File "C:\program files (x86)\microsoft cdo for windows library\cdosys.exe" belongs to virus/spyware 'C2/Generic-B'.

20190807 162354 Virus/spyware 'C2/Generic-B' is not removable. 

Upon checking Threat ID, I could confirm that it was pointing to a C2 server and confirms the URL. 

For geeks, this is how debug HIPS logs look during the simulated successful C2 communication [One of the malicious URLs listed in the advisory]- 

20190807 052144 RSDEBUG: L"ProcessPath: \\device\\harddiskvolume2\\program files (x86)\\microsoft cdo for windows library\\cdosys.exe" 

20190807 052144 RSDEBUG: L"SNTP PassedPath: \\device\\harddiskvolume2\\program files (x86)\\microsoft cdo for windows library\\cdosys.exe" 

20190807 052144 RSDEBUG: L"PID: \x001c\x000b\x0000\x0000"

20190807 052144 RSDEBUG: L"TID: 6668"

20190807 052144 RSDEBUG: L"URL: http[://]rest[.]ernestlabrie[.]com/Ihuel-Kobu-Anhud-Avesi-Vhuje-27003"

20190807 052144 RSDEBUG: L"Labs URI ID: nil"

20190807 052144 RSDEBUG: L"LocalAddress: 192.168.30.175"

20190807 052144 RSDEBUG: L"LocalPort: 53383"

20190807 052144 RSDEBUG: L"RemoteAddress: 192.168.30.10" //My dummy C2 Server

20190807 052144 RSDEBUG: L"RemotePort: 80"

20190807 052144 RSDEBUG: L"Protocol: 6"

20190807 052144 RSDEBUG: L"Threat name: nil"

20190807 052144 RSDEBUG: L"Risk level: nil"

20190807 052144 RSDEBUG: L"Universal Category: nil"

20190807 052144 RSDEBUG: L"Detailed Category: nil"

20190807 052144 RSDEBUG: L"Headers: POST /Ihuel-Kobu-Anhud-Avesi-Vhuje-27003 HTTP/1.1\x000d\x000aUser-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; .NET4.0E; Media Center PC 6.0)\x000d\x000aHost: rest[.]ernestlabrie[.]com\x000d\x000aContent-Length: 24\x000d\x000aConnection: Keep-Alive\x000d\x000aCache-Control: no-cache\x000d\x000a\x000d\x000a"

Now that we have the executable file, let’s look closely at the Autoruns logs once again to find the persistence mechanism and -

Why would an Adobe signed executable have a Scheduled Task named “Microsoft CDO for Windows Library@cameron_hede”? Doesn’t make sense, right? To the advanced bad guys – it does. We Endearingly call them APT Groups, who prefer to keep a low profile to evade raising any red flags. But to our keen eyes, they stood out like a sore thumb..

Conclusion:

This peculiar technique has been termed as DLL-sideloading. We are suspecting this to be a Korplug RAT.

“The Korplug RAT is known to use this side-loading trick by abusing legitimate digitally signed executables and is a way to stay under the radar, since a trusted application with a valid signature among startup items is less likely to raise suspicion.”

“The two files figure in a tried-and-tested trick called ‘DLL side-loading’, which consists in co-opting a legitimate application’s library-loading process by planting a malicious DLLinside the same folder as the signed executable,” the ESET blog post explains. “This is a way to remain under the radar, since a trusted application with a valid signature is less likely to arouse suspicion.”

A complete analysis was performed by SophosLabs and our Product Teams which resulted in publishing signatures against the DLLs and .DB3 file. We also studied the technique to better the efficacy of our Intercept X.

A summary of all the files involved in this attack with their corresponding detection names –

Any questions, feedback and (positive) criticism are welcome. A special thanks to Andrew O'Donnell.