How to Detect an APT (Advanced Persistent Threat)

Not too long ago, a company called Digital Bond found itself in a unique position to analyze an interesting and common form of an APT. Digital Bond is a research and consulting firm, which performs security architecture and policy audits, as well as application assessments for control system vendors to help them develop secure SCADA environments. Anyway, Digital Bond was a target of a spear phishing attack not too long ago.

The attackers created an email lure that was specifically crafted to target people and companies in the industrial control community. The email (shown below) was a fake email that referenced a vulnerability in field devices, and it urged readers to download the full report.

LogRhythm blog Figure 1: Spear Phishing email lure

The attachment (I’m holding my hands up and making air quotes here) looked harmless enough, with the name Leveragint_Ethernet_Card_Vulnerabilities_in_Field_Devices.pdf.

I say “attachment,” with quotes around it because it’s not actually an attachment at all, it’s just a link to an external site, designed to fool a busy SOC analyst who is just skimming over the emails in their inbox. This would be the first indicator that should trigger your internal alarm.

Next, the link downloads a zip file that looks harmless, and once decompressed, it contains the file Leveragint_Ethernet_Card_Vulnerabilities_in_Field_Devices.pdf.exe. Now, combined with your first alarm, the .exe should be a dead giveaway that something is wrong. Fortunately for the analysts at Digital Bond, the attackers were unsuccessful in their attack. But, you have to wonder whether, given the fact that this type of spear phishing campaign still exists, someone, somewhere is falling victim to it.

After all, if you cast a large enough net, you’re bound to catch something. So, the savvy researchers over at Digital Bond took this opportunity to study this malware in a secure lab environment. They found out that the first thing this malware did was create a new file called spoolsvr.exe and develop a registry key to maintain persistence. It’s important to note that this new file did not have a malicious payload. Instead, what happened was that this executable just downloaded a new configuration from a remote server.

Below, you can see the HTTP request along with it’s response. At first glance, it looks harmless. However, the HTML tags contain a bunch of garbage, and it turns out that this website ( actually contained configuration values encoded within the head , title and body tags. The values are encoded in base64 and XOR’d with a simple 1 byte key – that key being 0x42, which is something easily bruteforce-able and easy to figure out. Once decoded, the head tag translated to download, then sleep. The title revealed the name of the soon to be downloaded file, tanghl.exe. Then, the body tag gave way to the PE contents of the new malicious payload.

LogRhythm blog Figure 2: Malicious Get Request and Response

At the time, this new piece of malware, was only detectable by three out of 42 anti-virus tools tested by virustotal.

This new malware could do some boring stuff, such as install a key logger, or it could try to be a little more stealthy and setup an SSH tunnel outbound over 443 to exfiltrate some data. In this specific case, the APT turned out to be a RAT tool that just connected back to a C&C server by making HTTP requests to random numeric .asp files. The malicious communication was done through a base64 encoded value in the cookie header of the HTTP request.

LogRhythm blog Figure 3: Persistent communication back to C&C server

So, what can be done to detect APTs like this? The good news is that they leave behind a plethora of log evidence. Evidence that is available across many different dimensions, or log sources throughout the environment. For example:

  • If you’re an MS Exchange Server company, the message tracking log would have detailed the suspicious email coming in
  • File integrity monitoring devices would document the creation of new files
  • IIS/Apache/Web servers would show the communication with external sites
  • Proxy logs can be configured to show contents of http requests
  • Finally, if you’ve got NetFlow, you can access details of persistent communication with a C&C server as well as number of bytes transferred

The most important step here would be to utilize real-time analytics or behavioral monitoring to tie these events together. Only then can you start building baselines of normal user, account, host, and application behavior. Following this, you should compare those baselines against steady-state activity in real time to detect any anomalies.

After this, automated processes will make it abundantly clear, in this case, that we have received an email from a known spamming address. Then, we see a process starting up that has never started up on this host before. Followed by an immediate outbound connection to an external web server that we’ve never talked to before. While we might not know that this activity is 100 percent malicious, it’s suspicious enough to generate a high priority alert and have an analyst go check it out.

Thus, by combining real-time analytics and monitoring behavioral changes across the network, organizations could significantly reduce the risk of an attack.