We reported at the end of April and the beginning of May on an APT threat group leveraging a zero-day vulnerability in Internet Explorer via phishing email attacks. While Microsoft quickly released a patch to help close the door on future compromises, we have now observed the threat actors behind “Operation Clandestine Fox” shifting their point of attack and using a new vector to target their victims: social networking.

An employee of a company in the energy sector recently received an email with a RAR archive email attachment from a candidate. The attachment, ostensibly containing a resume and sample software program the applicant had written, was from someone we’ll call “Emily” who had previously contacted the actual employee via a popular social network.

FireEye acquired a copy of the suspicious email – shown below in Figure 1 – and attachment from the targeted employee and investigated. The targeted employee confirmed that “Emily” had contacted him via the popular social network, and that, after three weeks of back and forth messaging “she” sent her “resume” to his personal email address.  

Figure 1: Sample email illustrating how “Emily” attacks a victim employee

Working our way backwards, we reviewed “Emily’s” social network profile and noticed a few strange aspects that raised some red flags. For example, “her” list of contacts had a number of people from the victim’s same employer, as well as employees from other energy companies; “she” also did not seem to have many other “friends” that fit “her” alleged persona. “Her” education history also contained some fake entries.

Further research and discussions with the targeted company revealed that “Emily,” posing as a prospective employee, had also contacted other personnel at the same company. She had asked a variety of probing questions, including inquiring who the IT Manager was and what versions of software they ran – all information that would be very useful for an attacker looking to craft an attack.

It’s worth emphasizing that in the instances above, the attackers used a combination of direct contact via social networks as well as contact via email, to communicate with their intended targets and send malicious attachments. In addition, in almost all cases, the attackers used the target’s personal email address, rather than his or her work address. This could be by design, with a view toward circumventing the more comprehensive email security technologies that most companies have deployed, or also due to many people having their social network accounts linked to their personal rather than work email addresses.

Details – Email Attachment #1

The resume.rar archive contained three files: a weaponized version of the open-source TTCalc application (a mathematical big number calculator), a benign text copy of the TTCalc readme file, and a benign PDF of Emily’s resume. The resume was a nearly identical copy of a sample resume available elsewhere on the Internet. The file details are below.

Upon execution, ttcalc.exe drops the two files listed below, and also launches a legitimate copy of TTCalc v0.8.6 as a decoy:

%USERPROFILE%/Application Data/mt.dat
%USERPROFILE%/Start Menu/Programs/Startup/vc.bat

The file mt.dat is the actual malware executable, which we detect as Backdoor.APT.CookieCutter. Variants of this family of backdoor are also referred to as “Pirpi” in the security industry. In this case, the malware was configured to use the following remote servers for command and control:

• swe[.]karasoyemlak[.]com
• inform[.]bedircati[.]com (Note: This domain was also used during Operation Clandestine Fox)
• 122.49.215.108

Metadata for mt.dat:

Contents of vc.bat:

Details – Email Attachment #2

Through additional research, we were able to obtain another RAR archive email attachment sent by the same attackers to an employee of another company. Note that while there are a lot of similarities, such as the fake resume and inclusion of TTCalc, there is one major difference, which is the delivery of a completely different malware backdoor. The attachment name this time was “my resume and projects.rar,” but this time it was protected with the password “TTcalc.”

SETUP.exe is a self-extracting RAR, which opens the WinRAR window when executed, prompting the user for the location to extract the files. It writes them to a TTCalc folder and tries to launch ttcalcBAK.exe (the malware dropper), but the path is incorrect so it fails with an error message. All of the other files are benign and related to the legitimate TTCalc application.

The file ttcalcBAK.exe is also a self-extracting Rar which drops and launches chrome_frame_helper, which is a Backdoor.APT.Kaba (aka PlugX/Sogu) backdoor using a legitimate Chrome executable to load the malicious DLL via side-loading. Although this backdoor is used by multiple threat groups and is quite commonly seen these days, this is the first time we’ve observed this particular threat group using this family of malware. The malware was configured to communicate to the command and control domain www[.]walterclean[.]com (72.52.83.195 at the time of discovery) using the binary TCP protocol only. The file details are below, followed by the malware configuration.

Backdoor.APT.Kaba Malware Configuration:

PlugX Config (0x150c bytes):

Flags: False True False False False False True True True True False

Timer 1: 60 secs

Timer 2: 60 secs

C&C Address: www[.]walterclean[.]com:443 (TCP)

Install Dir: %ALLUSERSPROFILE%\chrome_frame_helper

Service Name: chrome_frame_helper

Service Disp: chrome_frame_helper

Service Desc: Windows chrome_frame_helper Services

Online Pass: 1234

Memo: 1234

Open Source Intel

The domain walterclean[.]com shares registration details with securitywap[.]com:

The following domains are registered to QQ360LEE@126.COM

Domain: walterclean[.]com
Create Date: 2014-03-26 00:00:00
Registrar: ENOM, INC.

Domain: securitywap[.]com
Create Date: 2014-03-26 00:00:00
Registrar: ENOM, INC.

Conclusion

In short, we attributed these attacks to the same threat actor responsible for “Operation Clandestine Fox,” based on the following linkages:

• The first-stage malware (mt.dat) is a slightly updated version of the Backdoor.APT.CookieCutter malware dropped during Operation Clandestine Fox
• Based on our intel, Backdoor.APT.CookieCutter has been used exclusively by this particular threat group
• Finally, the command and control domain inform[.]bedircati[.]com seen in this activity was also used during the Clandestine Fox campaign

Another evolutionary step for this threat group is that they have diversified their tool usage with the use of the Kaba/PlugX/Sogu malware – something we have never seen them do before.

As we have noted in other blog posts, APT threat actors take advantage of every possible vector to try to gain a foothold in the organizations they target. Social networks are increasingly used for both personal and business reasons, and are one more potential threat vector that both end-users and network defenders need to think about.

Unfortunately, it is very common for users to let their guard down when using social networks or personal email, since they don’t always treat these services with the same level of risk as their work email.  As more companies allow their employees to telecommute, or even allow them to access company networks and/or resources using their personal computers, these attacks targeting their personal email addresses pose significant risk to the enterprise.

Acknowledgements

The author would like to acknowledge the following colleagues for their contributions to this report: Josh Dennis, Mike Oppenheim, Ned Moran, and Joshua Homan.

With Apple’s purchase of Beats, Pfizer’s failed bids for AstraZeneca, and financial experts pointing to a rally in the M&A market, the last month was a busy one for mergers and acquisitions. Of course, when we first see headlines of a high profile company’s plans for a merger or acquisition, we rush to think of the strategic and industry implications of such a deal. But underneath the “what ifs” and “visions for the future,” is a darker side of M&A that doesn’t make the headlines: the routineness with which companies are breached and crucial data is stolen when two high-profile organizations look to join together.

Over the last few years, concerns over economic espionage have led to greater scrutiny of mergers and acquisitions involving foreign companies – particularly in industries with sensitive technologies and operations that could pose broader economic and security threats. However, entering into a merger or acquisition with a foreign company is not the only way nation-states conduct economic espionage via cyber means, nor are nation-states the only perpetrators of intellectual property theft.

From our experience responding to these breaches, we’ve seen targeted threat actors actively pursuing companies involved in mergers and acquisitions in two ways:

• Breaching one of the merging or acquired company’s subsidiaries’ and/or partners’ networks to ultimately gain access to the targeted company’s environment and information
• Compromising and stealing information from a company involved in business talks with a foreign enterprise in order to provide the other side with an insider advantage in the negotiations

From One Friend to Another: Taking Advantage of Trusted Relationships Between Companies

Some threat groups compromise an organization’s environment and then move laterally over a connected network to a partner or subsidiary, while others rely on social engineering tactics, such as the use of phishing emails that appear to be from employees at the partner company. We have seen China-based threat groups previously compromise targets by taking advantage of trusted relationships and bridged networks between companies. Regardless of their method of entry, these actors are often in search of the same thing: intellectual property and proprietary information that can provide their own constituents with a business advantage, whether through adopting a rival’s technology and products, securing advantageous prices, or any other tactic that could give them a leg up.

We investigated one incident in which two threat groups compromised a company shortly after it acquired a subsidiary. The threat actors used their access to the initial company’s network to move laterally to the subsidiary, which had recently developed a proprietary process for a significant new healthcare product. Once inside the subsidiary’s network, the threat groups stole data that included details on the product’s test results. We believe the threat groups sought to give that data to Chinese state-owned companies in that industry for fast-tracking the development of their own version of the groundbreaking product.

Cheating the System: Insider Advantages in Negotiations

We have also seen threat groups compromising organizations involved in merger or acquisition talks with Chinese entities, likely in an effort to steal data that could give negotiators and decision makers valuable insider information with which to manipulate the outcome of the proposed transaction. Unlike other types of economic espionage operations, the threat groups in this type of scenario are generally not in search of a company’s intellectual property. Instead, these actors look for data such as executive emails, negotiation terms, and business plans and information; all of which could benefit the negotiators by giving them insight into the victim company’s financial situation and negotiation strategy.

During one investigation, we found that a China-based threat group had compromised a company that was in the process of acquiring a Chinese subsidiary – a move that would have significantly increased the victim company’s manufacturing and retail capacity in the Chinese market. The threat actors accessed the email accounts of multiple employees involved in the negotiations in what was likely a search for information pertaining to the proceedings. We believe that the threat group then used the stolen information to inform Chinese decision makers involved in the acquisition process, as the Chinese government terminated the talks shortly after the data theft occurred.

What can we expect?

Companies involved in mergers and acquisitions need to be aware of the risks they face from threat actors intent on conducting economic espionage. Entering into a merger or acquisition with an organization that has unidentified intrusions and unaudited networks places a company at risk of compromise from threat actors who may be waiting to move laterally to the newly integrated target.

Similarly, companies, and the law firms representing them, involved in negotiations with Chinese enterprises face risks from threat groups seeking to provide the Chinese entity with an advantage in negotiations. Compromise and economic espionage can have profound impacts on a company’s finances and reputation at any time, but particularly when they are risking hundreds of millions to billions of dollars on M&A.

In many cases as well, there are broader issues of national security, so it’s imperative that companies seek to recognize and mitigate these risks as part of their M&A processes moving forward. Even governments sometimes attempt to mitigate these risks by conducting national security reviews and occasionally rejecting bids based on their findings.[i] Threat actors from many countries engage in economic espionage, making for a wide and varied threat landscape that cannot be handled by the government alone. For examples of just how diverse and crowded a space the targeted threat landscape is becoming, see our recent blog posts on Molerats, Saffron Rose, and Russia and Ukraine.

FireEye recently analyzed the capabilities of a variant of Havex (referred to by FireEye as “Fertger” or “PEACEPIPE”), the first publicized malware reported to actively scan OPC servers used for controlling SCADA (Supervisory Control and Data Acquisition) devices in critical infrastructure (e.g., water and electric utilities), energy, and manufacturing sectors.

While Havex itself is a somewhat simple PHP Remote Access Trojan (RAT) that has been analyzed by other sources, none of these have covered the scanning functionality that could impact SCADA devices and other industrial control systems (ICS). Specifically, this Havex variant targets servers involved in OPC (Object linking and embedding for Process Control) communication, a client/server technology widely used in process control systems (for example, to control water pumps, turbines, tanks, etc.).

Note: ICS is a general term that encompasses SCADA (Supervisory Control and Data Acquisition) systems, DCS (Distributed Control Systems), and other control system environments. The term SCADA is well-known to wider audiences, and throughout this article, ICS and SCADA will be used interchangeably.

Threat actors have leveraged Havex in attacks across the energy sector for over a year, but the full extent of industries and ICS systems affected by Havex is unknown. We decided to examine the OPC scanning component of Havex more closely, to better understand what happens when it’s executed and the possible implications.

OPC Testing Environment

To conduct a true test of the Havex variant’s functionality, we constructed an OPC server test environment that fully replicates a typical OPC server setup (Figure 1^[3]). As shown, ICS or SCADA systems involve OPC client software that interacts directly with an OPC server, which works in tandem with the PLC (Programmable Logic Controller) to control industrial hardware (such as a water pump, turbine, or tank). FireEye replicated both the hardware and software the OPC server setup (the components that appear within the dashed line on the right side of Figure 1).

On February 11, FireEye identified a zero-day exploit (CVE-2014-0322)  being served up from the U.S. Veterans of Foreign Wars’ website (vfw[.]org). We believe the attack is a strategic Web compromise targeting American military personnel amid a paralyzing snowstorm at the U.S. Capitol in the days leading up to the Presidents Day holiday weekend. Based on infrastructure overlaps and tradecraft similarities, we believe the actors behind this campaign are associated with two previously identified campaigns (Operation DeputyDog and Operation Ephemeral Hydra).

This blog post examines the vulnerability and associated attacks, which we have dubbed “Operation SnowMan.”

Exploit/Delivery analysis

After compromising the VFW website, the attackers added an iframe into the beginning of the website’s HTML code that loads the attacker’s page in the background. The attacker’s HTML/JavaScript page runs a Flash object, which orchestrates the remainder of the exploit. The exploit includes calling back to the IE 10 vulnerability trigger, which is embedded in the JavaScript.  Specifically, visitors to the VFW website were silently redirected through an iframe to the exploit at www.[REDACTED].com/Data/img/img.html.

Mitigation

The exploit targets IE 10 with Adobe Flash. It aborts exploitation if the user is browsing with a different version of IE or has installed Microsoft’s Experience Mitigation Toolkit (EMET). So installing EMET or updating to IE 11 prevents this exploit from functioning.

Vulnerability analysis

The vulnerability is a previously unknown use-after-free bug in Microsoft Internet Explorer 10. The vulnerability allows the attacker to modify one byte of memory at an arbitrary address. The attacker uses the vulnerability to do the following:

• Gain access to memory from Flash ActionScript, bypassing address space layout randomization (ASLR)
• Pivot to a return-oriented programing (ROP) exploit technique to bypass data execution prevention (DEP)

EMET detection

The attacker uses the Microsoft.XMLDOM ActiveX control to load a one-line XML string containing a file path to the EMET DLL. Then the exploit code parses the error resulting from the XML load order to determine whether the load failed because the EMET DLL is not present.  The exploit proceeds only if this check determines that the EMET DLL is not present.

ASLR bypass

Because the vulnerability allows attackers to modify memory to an arbitrary address, the attacker can use it to bypass ASLR. For example, the attacker corrupts a Flash Vector object and then accesses the corrupted object from within Flash to access memory. We have discussed this technique and other ASLR bypass approaches in our blog. One minor difference between the previous approaches and this attack is the heap spray address, which was changed to 0x1a1b2000 in this exploit.

Code execution

Once the attacker’s code has full memory access through the corrupted Flash Vector object, the code searches through loaded libraries gadgets by machine code. The attacker then overwrites the vftable pointer of a flash.Media.Sound() object in memory to point to the pivot and begin ROP. After successful exploitation, the code repairs the corrupted Flash Vector and flash.Media.Sound to continue execution.

Shellcode analysis

Subsequently, the malicious Flash code downloads a file containing the dropped malware payload. The beginning of the file is a JPG image; the end of the file (offset 36321) is the payload, encoded with an XOR key of 0×95. The attacker appends the payload to the shellcode before pivoting to code control. Then, when the shellcode is executed, the malware creates files “sqlrenew.txt” and “stream.exe”. The tail of the image file is decoded, and written to these files. “sqlrenew.txt” is then executed with the LoadLibraryA Windows API call.

ZxShell payload analysis

As documented above, this exploit dropped an XOR (0×95) payload that executed a ZxShell backdoor (MD5: 8455bbb9a210ce603a1b646b0d951bce). The compile date of the payload was 2014-02-11, and the last modified date of the exploit code was also 2014-02-11. This suggests that this instantiation of the exploit was very recent and was deployed for this specific strategic Web compromise of the Veterans of Foreign Wars website. A possible objective in the SnowMan attack is targeting military service members to steal military intelligence. In addition to retirees, active military personnel use the VFW website. It is probably no coincidence that Monday, Feb. 17, is a U.S. holiday, and much of the U.S. Capitol shut down Thursday amid a severe winter storm.

The ZxShell backdoor is a widely used and publicly available tool used by multiple threat actors linked to cyber espionage operations. This particular variant called back to a command and control server located at newss[.]effers[.]com. This domain currently resolves to 118.99.60.142. The domain info[.]flnet[.]org also resolved to this IP address on 2014-02-12.

Infrastructure analysis

The info[.]flnet[.]org domain overlaps with icybin[.]flnet[.]org and book[.]flnet[.]org via the previous resolutions to the following IP addresses:

• 58.64.200.178
• 58.64.200.179
• 103.20.192.4

We previously observed Gh0stRat samples with the custom packet flag “HTTPS” calling back to book[.]flnet[.]org and icybin[.]flnet[.]org. The threat actor responsible for Operation DeputyDog also used the “HTTPS” version of the Gh0st. We also observed another “HTTPS” Gh0st variant connecting to a related command and control server at me[.]scieron[.]com.

The me[.]scieron[.]com domain previously resolved to 58.64.199.22. The book[.]flnet[.]org domain also resolved to another IP in the same subnet 58.64.199.0/24. Specifically, book[.]flnet[.]org previously resolved to 58.64.199.27.

Others domain seen resolving to this same /24 subnet were dll[.]freshdns[.]org, ali[.]blankchair[.]com, and cht[.]blankchair[.]com. The domain dll[.]freshdns[.]org resolved to 58.64.199.25. Both ali[.]blankchair[.]com and cht[.]blankchair[.]com resolved to 58.64.199.22.

A number of other related domains resolve to these IPs and other IPs also in this /24 subnet. For the purposes of this blog, we’ve chosen to focus on those domains and IP that relate to the previously discussed DeputyDog and Ephemeral Hydra campaigns.

You may recall that dll[.]freshdns[.]org, ali[.]blankchair[.]com and cht[.]blankchair[.]com were all linked to both Operation DeputyDog and Operation Ephemeral Hydra. Figure 1 illustrates the infrastructure overlaps and connections we observed between the strategic Web compromise campaign leveraging the VFW’s website, the DeputyDog, and the Ephemeral Hydra operations.

Figure 1: Ties between Operation SnowMan, DeputyDog, and Ephemeral Hydra

Links to DeputyDog and Ephemeral Hydra

Other tradecraft similarities between the actor(s) responsible for this campaign and the actor(s) responsible for the DeputyDog/Ephemeral Hydra campaigns include:

• The use of zero-day exploits to deliver a remote access Trojan (RAT)
• The use of strategic web compromise as a vector to distribute remote access Trojans
• The use of a simple single-byte XOR encoded (0×95) payload obfuscated with a .jpg extension
• The use of Gh0stRat with the “HTTPS” packet flag
• The use of related command-and-control (CnC) infrastructure during the similar time frames

We observed many similarities from the exploitation side as well. At a high level, this attack and the CVE-2013-3163 attack both leveraged a Flash file that orchestrated the exploit, and would call back into IE JavaScript to trigger an IE flaw. The code within the Flash files from each attack are extremely similar. They build ROP chains and shellcode the same way, both choose to corrupt a Flash Vector object, have some identical functions with common typos, and even share the same name.

Conclusion

These actors have previously targeted a number of different industries, including:

• U.S. government entities
• Japanese firms
• Defense industrial base (DIB) companies
• Law firms
• Information technology (IT) companies
• Mining companies
• Non-governmental organizations (NGOs)

The proven ability to successfully deploy a number of different private and public RATs using zero-day exploits against high-profile targets likely indicates that this actor(s) will continue to operate in the mid to long-term.

FireEye recently analyzed the capabilities of a variant of Havex (referred to by FireEye as “Fertger” or “PEACEPIPE”), the first publicized malware reported to actively scan OPC servers used for controlling SCADA (Supervisory Control and Data Acquisition) devices in critical infrastructure (e.g., water and electric utilities), energy, and manufacturing sectors.

While Havex itself is a somewhat simple PHP Remote Access Trojan (RAT) that has been analyzed by other sources, none of these have covered the scanning functionality that could impact SCADA devices and other industrial control systems (ICS). Specifically, this Havex variant targets servers involved in OPC (Object linking and embedding for Process Control) communication, a client/server technology widely used in process control systems (for example, to control water pumps, turbines, tanks, etc.).

Note: ICS is a general term that encompasses SCADA (Supervisory Control and Data Acquisition) systems, DCS (Distributed Control Systems), and other control system environments. The term SCADA is well-known to wider audiences, and throughout this article, ICS and SCADA will be used interchangeably.

Threat actors have leveraged Havex in attacks across the energy sector for over a year, but the full extent of industries and ICS systems affected by Havex is unknown. We decided to examine the OPC scanning component of Havex more closely, to better understand what happens when it’s executed and the possible implications.

OPC Testing Environment

To conduct a true test of the Havex variant’s functionality, we constructed an OPC server test environment that fully replicates a typical OPC server setup (Figure 1^[3]). As shown, ICS or SCADA systems involve OPC client software that interacts directly with an OPC server, which works in tandem with the PLC (Programmable Logic Controller) to control industrial hardware (such as a water pump, turbine, or tank). FireEye replicated both the hardware and software the OPC server setup (the components that appear within the dashed line on the right side of Figure 1).

On February 11, FireEye identified a zero-day exploit (CVE-2014-0322)  being served up from the U.S. Veterans of Foreign Wars’ website (vfw[.]org). We believe the attack is a strategic Web compromise targeting American military personnel amid a paralyzing snowstorm at the U.S. Capitol in the days leading up to the Presidents Day holiday weekend. Based on infrastructure overlaps and tradecraft similarities, we believe the actors behind this campaign are associated with two previously identified campaigns (Operation DeputyDog and Operation Ephemeral Hydra).

This blog post examines the vulnerability and associated attacks, which we have dubbed “Operation SnowMan.”

Exploit/Delivery analysis

After compromising the VFW website, the attackers added an iframe into the beginning of the website’s HTML code that loads the attacker’s page in the background. The attacker’s HTML/JavaScript page runs a Flash object, which orchestrates the remainder of the exploit. The exploit includes calling back to the IE 10 vulnerability trigger, which is embedded in the JavaScript.  Specifically, visitors to the VFW website were silently redirected through an iframe to the exploit at www.[REDACTED].com/Data/img/img.html.

Mitigation

The exploit targets IE 10 with Adobe Flash. It aborts exploitation if the user is browsing with a different version of IE or has installed Microsoft’s Experience Mitigation Toolkit (EMET). So installing EMET or updating to IE 11 prevents this exploit from functioning.

Vulnerability analysis

The vulnerability is a previously unknown use-after-free bug in Microsoft Internet Explorer 10. The vulnerability allows the attacker to modify one byte of memory at an arbitrary address. The attacker uses the vulnerability to do the following:

• Gain access to memory from Flash ActionScript, bypassing address space layout randomization (ASLR)
• Pivot to a return-oriented programing (ROP) exploit technique to bypass data execution prevention (DEP)

EMET detection

The attacker uses the Microsoft.XMLDOM ActiveX control to load a one-line XML string containing a file path to the EMET DLL. Then the exploit code parses the error resulting from the XML load order to determine whether the load failed because the EMET DLL is not present.  The exploit proceeds only if this check determines that the EMET DLL is not present.

ASLR bypass

Because the vulnerability allows attackers to modify memory to an arbitrary address, the attacker can use it to bypass ASLR. For example, the attacker corrupts a Flash Vector object and then accesses the corrupted object from within Flash to access memory. We have discussed this technique and other ASLR bypass approaches in our blog. One minor difference between the previous approaches and this attack is the heap spray address, which was changed to 0x1a1b2000 in this exploit.

Code execution

Once the attacker’s code has full memory access through the corrupted Flash Vector object, the code searches through loaded libraries gadgets by machine code. The attacker then overwrites the vftable pointer of a flash.Media.Sound() object in memory to point to the pivot and begin ROP. After successful exploitation, the code repairs the corrupted Flash Vector and flash.Media.Sound to continue execution.

Shellcode analysis

Subsequently, the malicious Flash code downloads a file containing the dropped malware payload. The beginning of the file is a JPG image; the end of the file (offset 36321) is the payload, encoded with an XOR key of 0×95. The attacker appends the payload to the shellcode before pivoting to code control. Then, when the shellcode is executed, the malware creates files “sqlrenew.txt” and “stream.exe”. The tail of the image file is decoded, and written to these files. “sqlrenew.txt” is then executed with the LoadLibraryA Windows API call.

ZxShell payload analysis

As documented above, this exploit dropped an XOR (0×95) payload that executed a ZxShell backdoor (MD5: 8455bbb9a210ce603a1b646b0d951bce). The compile date of the payload was 2014-02-11, and the last modified date of the exploit code was also 2014-02-11. This suggests that this instantiation of the exploit was very recent and was deployed for this specific strategic Web compromise of the Veterans of Foreign Wars website. A possible objective in the SnowMan attack is targeting military service members to steal military intelligence. In addition to retirees, active military personnel use the VFW website. It is probably no coincidence that Monday, Feb. 17, is a U.S. holiday, and much of the U.S. Capitol shut down Thursday amid a severe winter storm.

The ZxShell backdoor is a widely used and publicly available tool used by multiple threat actors linked to cyber espionage operations. This particular variant called back to a command and control server located at newss[.]effers[.]com. This domain currently resolves to 118.99.60.142. The domain info[.]flnet[.]org also resolved to this IP address on 2014-02-12.

Infrastructure analysis

The info[.]flnet[.]org domain overlaps with icybin[.]flnet[.]org and book[.]flnet[.]org via the previous resolutions to the following IP addresses:

• 58.64.200.178
• 58.64.200.179
• 103.20.192.4

We previously observed Gh0stRat samples with the custom packet flag “HTTPS” calling back to book[.]flnet[.]org and icybin[.]flnet[.]org. The threat actor responsible for Operation DeputyDog also used the “HTTPS” version of the Gh0st. We also observed another “HTTPS” Gh0st variant connecting to a related command and control server at me[.]scieron[.]com.

The me[.]scieron[.]com domain previously resolved to 58.64.199.22. The book[.]flnet[.]org domain also resolved to another IP in the same subnet 58.64.199.0/24. Specifically, book[.]flnet[.]org previously resolved to 58.64.199.27.

Others domain seen resolving to this same /24 subnet were dll[.]freshdns[.]org, ali[.]blankchair[.]com, and cht[.]blankchair[.]com. The domain dll[.]freshdns[.]org resolved to 58.64.199.25. Both ali[.]blankchair[.]com and cht[.]blankchair[.]com resolved to 58.64.199.22.

A number of other related domains resolve to these IPs and other IPs also in this /24 subnet. For the purposes of this blog, we’ve chosen to focus on those domains and IP that relate to the previously discussed DeputyDog and Ephemeral Hydra campaigns.

You may recall that dll[.]freshdns[.]org, ali[.]blankchair[.]com and cht[.]blankchair[.]com were all linked to both Operation DeputyDog and Operation Ephemeral Hydra. Figure 1 illustrates the infrastructure overlaps and connections we observed between the strategic Web compromise campaign leveraging the VFW’s website, the DeputyDog, and the Ephemeral Hydra operations.

Figure 1: Ties between Operation SnowMan, DeputyDog, and Ephemeral Hydra

Links to DeputyDog and Ephemeral Hydra

Other tradecraft similarities between the actor(s) responsible for this campaign and the actor(s) responsible for the DeputyDog/Ephemeral Hydra campaigns include:

• The use of zero-day exploits to deliver a remote access Trojan (RAT)
• The use of strategic web compromise as a vector to distribute remote access Trojans
• The use of a simple single-byte XOR encoded (0×95) payload obfuscated with a .jpg extension
• The use of Gh0stRat with the “HTTPS” packet flag
• The use of related command-and-control (CnC) infrastructure during the similar time frames

We observed many similarities from the exploitation side as well. At a high level, this attack and the CVE-2013-3163 attack both leveraged a Flash file that orchestrated the exploit, and would call back into IE JavaScript to trigger an IE flaw. The code within the Flash files from each attack are extremely similar. They build ROP chains and shellcode the same way, both choose to corrupt a Flash Vector object, have some identical functions with common typos, and even share the same name.

Conclusion

These actors have previously targeted a number of different industries, including:

• U.S. government entities
• Japanese firms
• Defense industrial base (DIB) companies
• Law firms
• Information technology (IT) companies
• Mining companies
• Non-governmental organizations (NGOs)

The proven ability to successfully deploy a number of different private and public RATs using zero-day exploits against high-profile targets likely indicates that this actor(s) will continue to operate in the mid to long-term.

FireEye recently analyzed the capabilities of a variant of Havex (referred to by FireEye as “Fertger” or “PEACEPIPE”), the first publicized malware reported to actively scan OPC servers used for controlling SCADA (Supervisory Control and Data Acquisition) devices in critical infrastructure (e.g., water and electric utilities), energy, and manufacturing sectors.

While Havex itself is a somewhat simple PHP Remote Access Trojan (RAT) that has been analyzed by other sources, none of these have covered the scanning functionality that could impact SCADA devices and other industrial control systems (ICS). Specifically, this Havex variant targets servers involved in OPC (Object linking and embedding for Process Control) communication, a client/server technology widely used in process control systems (for example, to control water pumps, turbines, tanks, etc.).

Note: ICS is a general term that encompasses SCADA (Supervisory Control and Data Acquisition) systems, DCS (Distributed Control Systems), and other control system environments. The term SCADA is well-known to wider audiences, and throughout this article, ICS and SCADA will be used interchangeably.

Threat actors have leveraged Havex in attacks across the energy sector for over a year, but the full extent of industries and ICS systems affected by Havex is unknown. We decided to examine the OPC scanning component of Havex more closely, to better understand what happens when it’s executed and the possible implications.

OPC Testing Environment

To conduct a true test of the Havex variant’s functionality, we constructed an OPC server test environment that fully replicates a typical OPC server setup (Figure 1^[3]). As shown, ICS or SCADA systems involve OPC client software that interacts directly with an OPC server, which works in tandem with the PLC (Programmable Logic Controller) to control industrial hardware (such as a water pump, turbine, or tank). FireEye replicated both the hardware and software the OPC server setup (the components that appear within the dashed line on the right side of Figure 1).

As depicted in earlier FireEye blogs, advanced cyber attacks are no strangers to the Asia Pacific region. In this blog, we take a deeper look at some of the advanced persistent threat (APT) malware that have significant presence in the APAC region, starting with PlugX (we detect it as Backdoor.APT.Kaba).

The PlugX / Kaba malware is a well-known remote access tool (RAT) believed to have been around for several years that continues to evolve itself in new attack campaigns. It is often seen used in APT campaigns alongside two other infamous RATs – PoisonIvy and Taidoor. For this blog, FireEye Labs has investigated PlugX samples discovered throughout 2013 as well as recent variants detected between January and June 2014. Countries on both sides of the Pacific incuding the United States as well as Northeast Asian countries such as South Korea, Hong Kong, Japan and Taiwan were most hit by this malware, with attacks spanning multiple industry verticals. The top  5 most targeted verticals include Technology, Aerospace / Defense, Entertainment / Media, Telecommunications and Government (Federal).

Figure 1: PlugX / Kaba Detections (by Country)

Table 1: Top 5 Affected Verticals

Delivering the Attacks

PlugX is most commonly distributed via an exploit, but may also be delivered using a RAR self-extracting executable. Amanda Stewart has written an excellent blog and paper about the common components of the PlugX / Kaba RAT and how it capitalizes on the DLL side-loading technique. In general, the RAT consists of DLL components that are injected into the process memory of svchost.exe. To deliver the DLL components, a “dropper” must first be executed through the use of an exploit, or via social-engineering tactics over e-mail or web to entice the victims to load an executable file.

Figure 2: Primary PlugX “Dropper” File Types

While RTF files exploiting CVE-2012-0158 are nothing new, they are still most frequently used in the delivery of PlugX to its targets. The same vulnerability has also been exploited through Excel spreadsheets and Word document files. More recently, a Flash zero-day vulnerability has been exploited to deliver a PlugX payload.

Where an exploit is not used, RAR self-extracting executable (SFX) files were commonly used throughout 2013. These files often appear to have a Word or PDF icon and launch a decoy document that is displayed to the victim. The PlugX RAT is then loaded in the background without the user’s knowledge. While we have noticed a decrease in the use of this vector to deliver PlugX in 2014, it continues to be an effective technique for PlugX and other malware, so we do not expect its use to disappear entirely.

In the below example, the RAR SFX contains a script that loads the RAT (config.exe) and the decoy document (notice.doc).

Figure 3: RAR SFX Script and Files

Command and Control

We have found two dominant variants, SideBar and RasTLS, using 4 of the top 10 domains associated with the PlugX / Kaba command and control (C2) infrastructure. In fact, the 4 domains resolved to the same IP range based in Hong Kong likely operated by the same threat group(s).

Table 2: Top Domains used in PlugX / Kaba Callbacks

SideBar

The SideBar variant is delivered through RTF, Word and Excel files. Upon successfully exploitation, it drops “dw20.dll” to the %TEMP% folder. This “dw20.dll” continues to install the following files:

• %ALLUSERS%\WS\Gadget.exe (MD5: 6b97b3cd2fcfb4b74985143230441463)
• %ALLUSERS%\WS\SideBar.dll (MD5: 123e1841cc596c1f40e2e6693ea7dcac)
• %ALLUSERS%\WS\SideBar.dll.doc (MD5: a0c93bdc089e1338cc392108a0e57f2f)

A service registry key is created to start “Gadget.exe” upon reboot of the infected system.
“Gadget.exe” is part of a benign “TENCENT Sidebar” application digitally signed by “Tencent Technology(Shenzhen) Company Limited “. Using the DLL-side loading method, a malicious version of“SideBar.dll” is loaded and executes the exported function “Main”.

“SideBar.dll” is a loader for “SideBar.dll.doc”, executing code at offset 0. “SideBar.dll.doc” decodes a part of its own data and is responsible for deflating a backdoor component. It spawns a new svchost.exe process and injects the backdoor into memory. This backdoor component remains only in memory, and is never saved to disk.

Figure 4: Decompressing Encoded Data

Version information can often be found in PlugX’s process memory. In SideBar, a DWORD value storing the internal version number was 0×20120123. The path names found in the deflated backdoor’s process memory indicating that this PlugX variant is version 6.0:

• “d:\work\plug6.0(360)(gadget)”

The variant connects to fast.bacguarp.com and bbs.zuesinfo.com over port 8080.

RasTLS

While the RasTls variant is also dropped by document exploits, the dropped files are different. RasTls does not use the DLL side-loading method found in older variants [3]. The DWORD used to store the internal version number of RasTls was 0×20130810.

• %ALLUSERS%\DRM\RasTls\RasTls.exe

“RasTls.exe” spawns “svchost.exe” and injects a deflated backdoor component into memory. The deflated backdoor component in memory contains a “XV” marker, instead of “MZ” and “PE” as found in regular Windows portal executable (PE) files. This is because “RasTls.exe” manually loads each section of deflated file into memory, so the file does not have to be a complete PE image.

Figure 5: Backdoor Component with “XV” maker instead of “MZ” and “PE”

The variant doesn’t contain strings implying version. The variant accept commands like as “ST1”, “ST2”, “TT1”,”TT2” which are different from version 6.

In memory space in the “svchost.exe”, we can see the decoded configuration information:

Figure 6: Decoded Configuration Information

All RasTls variants have largely identical configuration and connects to scqf.bacguarp.com and scqf.zuesinfo.com over port 443. The “My_Name” mutex is also common to all RasTls variants.

PlugX Encryption Algorithm

PlugX has a variety of encryption algorithms used to encrypt its data across variants. However, the encryption style is largely similar as depicted in Figure 7.

Figure 7: PlugX Decryption Algorithm

In RasTls, the DWORD decryption key was found in the first four bytes of the encrypted string. It was also less aggressive in encrypting and hiding its data. In older variants such as “win3dx.DLL” (MD5: 7ADAE0335C9D6C9F3826CDE9747438B7), most API names were decrypted before loading and nullified after use. This makes understanding the malware slightly more difficult for malware analysts.

The supported functionalities are largely similar where it uses the identical command code. Below is a list of PlugX commands for file system manipulation:

• 0×3000: GetDiskRelatedInformation
• 0×3001: SearchDirectoryForFiles
• 0×3002: SearchDirectoryRecursively
• 0×3004: ReadFile
• 0×3007: WriteFile
• 0x300A: CreateDirectory
• 0x300C: CreateWindowsDesktop
• 0x300D: PerformSH_FileOperation
• 0x300E: ExpandEnvironmentVariable

Some improvements were made by its developers. For example, the key logger function was updated to utilize the GetRawInputData API to collect keystrokes. “RegisterRawInputDevices” and “GetRawInputData” were two of the few API names that remain encrypted in RasTls.

Figure 8: Updated Key Logging Component

PlugX / Kaba Trending

Figure 9 shows the trending of total PlugX / Kaba infections and their variants: SideBar and RasTLS. The spike in September 2013 was caused by SideBar. In 2014, we see SideBar and RasTLS on an inverse trend, with the latter on a steady increase.

Figure 9: Trending of Overall PlugX / Kaba , SideBar, RasTLS Infections

Figure 10 shows the distribution of SideBar/RasTls variants by country. The C2 servers are located in Hong Kong, where much of the attacks have occurred. We also find a variety of countries targeted by these variants. In some of the exploit documents delivering these variants, the content revolves around the theme of NGOs and socio-political events in China and Japan. These are content that would likely be of interest to the victims who would be opening the documents.

Figure 10: Distribution of SideBar/RasTls Variants by Country

Conclusion

The Asia Pacific region remains a highly attractive target of advanced cyber-attacks. Many threat groups  have a particular in interest in this region, and are likely continue to launch new attacks against targets here. We recommend that users in this region block access to the above C2 servers. FireEye Labs will continue to monitor and report on new PlugX / Kaba developments.

Less than a week after uncovering Operation SnowMan, the FireEye Dynamic Threat Intelligence cloud has identified another targeted attack campaign — this one exploiting a zero-day vulnerability in Flash. We are collaborating with Adobe security on this issue. Adobe has assigned the CVE identifier CVE-2014-0502 to this vulnerability and released a security bulletin.

As of this blog post, visitors to at least three nonprofit institutions — two of which focus on matters of national security and public policy — were redirected to an exploit server hosting the zero-day exploit. We’re dubbing this attack “Operation GreedyWonk.”

We believe GreedyWonk may be related to a May 2012 campaign outlined by ShadowServer, based on consistencies in tradecraft (particularly with the websites chosen for this strategic Web compromise), attack infrastructure, and malware configuration properties.

The group behind this campaign appears to have sufficient resources (such as access to zero-day exploits) and a determination to infect visitors to foreign and public policy websites. The threat actors likely sought to infect users to these sites for follow-on data theft, including information related to defense and public policy matters.

Discovery

On Feb. 13, FireEye identified a zero-day Adobe Flash exploit that affects the latest version of the Flash Player (12.0.0.4 and 11.7.700.261). Visitors to the Peter G. Peterson Institute for International Economics (www.piie[.]com) were redirected to an exploit server hosting this Flash zero-day through a hidden iframe.

We subsequently found that the American Research Center in Egypt (www.arce[.]org) and the Smith Richardson Foundation (www.srf[.]org) also redirected visitors the exploit server. All three organizations are nonprofit institutions; the Peterson Institute and Smith Richardson Foundation engage in national security and public policy issues.

Mitigation

To bypass Windows’ Address Space Layout Randomization (ASLR) protections, this exploit targets computers with any of the following configurations:

• Windows XP
• Windows 7 and Java 1.6
• Windows 7 and an out-of-date version of Microsoft Office 2007 or 2010

Users can mitigate the threat by upgrading from Windows XP and updating Java and Office. If you have Java 1.6, update Java to the latest 1.7 version. If you are using an out-of-date Microsoft Office 2007 or 2010, update Microsoft Office to the latest version.

These mitigations do not patch the underlying vulnerability. But by breaking the exploit’s ASLR-bypass measures, they do prevent the current in-the-wild exploit from functioning.

Vulnerability analysis

GreedyWonk targets a previously unknown vulnerability in Adobe Flash. The vulnerability permits an attacker to overwrite the vftable pointer of a Flash object to redirect code execution.

ASLR bypass

The attack uses only known ASLR bypasses. Details of these techniques are available from our previous blog post on the subject (in the “Non-ASLR modules” section).

For Windows XP, the attackers build a return-oriented programming (ROP) chain of MSVCRT (Visual C runtime) gadgets with hard-coded base addresses for English (“en”) and Chinese (“zh-cn” and “zh-tw”).

On Windows 7, the attackers use a hard-coded ROP chain for MSVCR71.dll (Visual C++ runtime) if the user has Java 1.6, and a hard-coded ROP chain for HXDS.dll (Help Data Services Module) if the user has Microsoft Office 2007 or 2010.

Java 1.6 is no longer supported and does not receive security updates. In addition to the MSVCR71.dll ASLR bypass, a variety of widely exploited code-execution vulnerabilities exist in Java 1.6. That’s why FireEye strongly recommends upgrading to Java 1.7.

The Microsoft Office HXDS.dll ASLR bypass was patched at the end of 2013. More details about this bypass are addressed by Microsoft’s Security Bulletin MS13-106 and an accompanying blog entry. FireEye strongly recommends updating Microsoft Office 2007 and 2010 with the latest patches.

Shellcode analysis

The shellcode is downloaded in ActionScript as a GIF image. Once ROP marks the shellcode as executable using Windows’ VirtualProtect function, it downloads an executable via the InternetOpenURLA and InternetReadFile functions. Then it writes the file to disk with CreateFileA and WriteFile functions. Finally, it runs the file using the WinExec function.

PlugX/Kaba payload analysis

Once the exploit succeeds, a PlugX/Kaba remote access tool (RAT) payload with the MD5 hash 507aed81e3106da8c50efb3a045c5e2b is installed on the compromised endpoint. This PlugX sample was compiled on Feb. 12, one day before we first observed it, indicating that it was deployed specifically for this campaign.

This PlugX payload was configured with the following command-and-control (CnC) domains:

• java.ns1[.]name
• adservice.no-ip[.]org
• wmi.ns01[.]us

Sample callback traffic was as follows:

POST /D28419029043311C6F8BF9F5 HTTP/1.1
Accept: */*
HHV1: 0
HHV2: 0
HHV3: 61456
HHV4: 1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; InfoPath.2; .NET CLR 2.0.50727; SV1)
Host: java.ns1.name
Content-Length: 0
Connection: Keep-Alive
Cache-Control: no-cache

Campaign analysis

Both java.ns1[.]name and adservice.no-ip[.]org resolved to 74.126.177.68 on Feb. 18, 2014. Passive DNS analysis reveals that the domain wmi.ns01.us previously resolved to 103.246.246.103 between July 4, 2013 and July 15, 2013 and 192.74.246.219 on Feb. 17, 2014.  java.ns1[.]name also resolved to 192.74.246.219 on February 18.

Further research uncovered a number of older malware samples connecting to the same domain wmi.ns01[.]us.

The Poison Ivy variants that connected to the domain wmi.ns01[.]us had the following unique configuration properties:

We found a related Poison Ivy sample (MD5 8936c87a08ffa56d19fdb87588e35952) with the same “java7” password, which was dropped by an Adobe Flash exploit (CVE-2012-0779). In this previous incident, visitors to the Center for Defense Information website (www.cdi[.]org — also an organization involved in defense matters — were redirected to an exploit server at 159.54.62.92.

This exploit server hosted a Flash exploit file named BrightBalls.swf (MD5 1ec5141051776ec9092db92050192758). This exploit, in turn, dropped the Poison Ivy variant. In addition to using the same password “java7,” this variant was configured with the mutex with the similar pattern of “YFds*&^ff” and connected to a CnC server at windows.ddns[.]us.

Using passive DNS analysis, we see the domains windows.ddns[.]us and wmi.ns01[.]us both resolved to 76.73.80.188 in mid-2012.

During another earlier compromise of the same www.cdi.org website, visitors were redirected to a Java exploit test.jar (MD5 7d810e3564c4eb95bcb3d11ce191208e). This jar file exploited CVE-2012-0507 and dropped a Poison Ivy payload with the hash (MD5 52aa791a524b61b129344f10b4712f52). This Poison Ivy variant connected to a CnC server at ids.ns01[.]us. The domain ids.ns01[.]us also overlaps with the domain wmi.ns01[.]us on the IP 194.183.224.75.

The Poison Ivy sample referenced above (MD5 fd69793bd63c44bbb22f9c4d46873252) was delivered via an exploit chain that began with a redirect from the Center for European Policy Studies (www.ceps[.]be). In this case, visitors were redirected from www.ceps[.]be to a Java exploit hosted on shop.fujifilm[.]be.

In what is certainly not a coincidence, we also observed www.arce[.]org (one of the sites redirecting to the current Flash exploit) also redirect visitors to the Java exploit on shop.fujifilm[.]be in 2013.

Conclusion

This threat actor clearly seeks out and compromises websites of organizations related to international security policy, defense topics, and other non-profit sociocultural issues. The actor either maintains persistence on these sites for extended periods of time or is able to re-compromise them periodically.

This actor also has early access to a number of zero-day exploits, including Flash and Java, and deploys a variety of malware families on compromised systems. Based on these and other observations, we conclude that this actor has the tradecraft abilities and resources to remain a credible threat in at least the mid-term.

As depicted in earlier FireEye blogs, advanced cyber attacks are no strangers to the Asia Pacific region. In this blog, we take a deeper look at some of the advanced persistent threat (APT) malware that have significant presence in the APAC region, starting with PlugX (we detect it as Backdoor.APT.Kaba).

The PlugX / Kaba malware is a well-known remote access tool (RAT) believed to have been around for several years that continues to evolve itself in new attack campaigns. It is often seen used in APT campaigns alongside two other infamous RATs – PoisonIvy and Taidoor. For this blog, FireEye Labs has investigated PlugX samples discovered throughout 2013 as well as recent variants detected between January and June 2014. Countries on both sides of the Pacific incuding the United States as well as Northeast Asian countries such as South Korea, Hong Kong, Japan and Taiwan were most hit by this malware, with attacks spanning multiple industry verticals. The top  5 most targeted verticals include Technology, Aerospace / Defense, Entertainment / Media, Telecommunications and Government (Federal).

Figure 1: PlugX / Kaba Detections (by Country)

Table 1: Top 5 Affected Verticals

Delivering the Attacks

PlugX is most commonly distributed via an exploit, but may also be delivered using a RAR self-extracting executable. Amanda Stewart has written an excellent blog and paper about the common components of the PlugX / Kaba RAT and how it capitalizes on the DLL side-loading technique. In general, the RAT consists of DLL components that are injected into the process memory of svchost.exe. To deliver the DLL components, a “dropper” must first be executed through the use of an exploit, or via social-engineering tactics over e-mail or web to entice the victims to load an executable file.

Figure 2: Primary PlugX “Dropper” File Types

While RTF files exploiting CVE-2012-0158 are nothing new, they are still most frequently used in the delivery of PlugX to its targets. The same vulnerability has also been exploited through Excel spreadsheets and Word document files. More recently, a Flash zero-day vulnerability has been exploited to deliver a PlugX payload.

Where an exploit is not used, RAR self-extracting executable (SFX) files were commonly used throughout 2013. These files often appear to have a Word or PDF icon and launch a decoy document that is displayed to the victim. The PlugX RAT is then loaded in the background without the user’s knowledge. While we have noticed a decrease in the use of this vector to deliver PlugX in 2014, it continues to be an effective technique for PlugX and other malware, so we do not expect its use to disappear entirely.

In the below example, the RAR SFX contains a script that loads the RAT (config.exe) and the decoy document (notice.doc).

Figure 3: RAR SFX Script and Files

Command and Control

We have found two dominant variants, SideBar and RasTLS, using 4 of the top 10 domains associated with the PlugX / Kaba command and control (C2) infrastructure. In fact, the 4 domains resolved to the same IP range based in Hong Kong likely operated by the same threat group(s).

Table 2: Top Domains used in PlugX / Kaba Callbacks

SideBar

The SideBar variant is delivered through RTF, Word and Excel files. Upon successfully exploitation, it drops “dw20.dll” to the %TEMP% folder. This “dw20.dll” continues to install the following files:

• %ALLUSERS%\WS\Gadget.exe (MD5: 6b97b3cd2fcfb4b74985143230441463)
• %ALLUSERS%\WS\SideBar.dll (MD5: 123e1841cc596c1f40e2e6693ea7dcac)
• %ALLUSERS%\WS\SideBar.dll.doc (MD5: a0c93bdc089e1338cc392108a0e57f2f)

A service registry key is created to start “Gadget.exe” upon reboot of the infected system.
“Gadget.exe” is part of a benign “TENCENT Sidebar” application digitally signed by “Tencent Technology(Shenzhen) Company Limited “. Using the DLL-side loading method, a malicious version of“SideBar.dll” is loaded and executes the exported function “Main”.

“SideBar.dll” is a loader for “SideBar.dll.doc”, executing code at offset 0. “SideBar.dll.doc” decodes a part of its own data and is responsible for deflating a backdoor component. It spawns a new svchost.exe process and injects the backdoor into memory. This backdoor component remains only in memory, and is never saved to disk.

Figure 4: Decompressing Encoded Data

Version information can often be found in PlugX’s process memory. In SideBar, a DWORD value storing the internal version number was 0×20120123. The path names found in the deflated backdoor’s process memory indicating that this PlugX variant is version 6.0:

• “d:\work\plug6.0(360)(gadget)”

The variant connects to fast.bacguarp.com and bbs.zuesinfo.com over port 8080.

RasTLS

While the RasTls variant is also dropped by document exploits, the dropped files are different. RasTls does not use the DLL side-loading method found in older variants [3]. The DWORD used to store the internal version number of RasTls was 0×20130810.

• %ALLUSERS%\DRM\RasTls\RasTls.exe

“RasTls.exe” spawns “svchost.exe” and injects a deflated backdoor component into memory. The deflated backdoor component in memory contains a “XV” marker, instead of “MZ” and “PE” as found in regular Windows portal executable (PE) files. This is because “RasTls.exe” manually loads each section of deflated file into memory, so the file does not have to be a complete PE image.

Figure 5: Backdoor Component with “XV” maker instead of “MZ” and “PE”

The variant doesn’t contain strings implying version. The variant accept commands like as “ST1”, “ST2”, “TT1”,”TT2” which are different from version 6.

In memory space in the “svchost.exe”, we can see the decoded configuration information:

Figure 6: Decoded Configuration Information

All RasTls variants have largely identical configuration and connects to scqf.bacguarp.com and scqf.zuesinfo.com over port 443. The “My_Name” mutex is also common to all RasTls variants.

PlugX Encryption Algorithm

PlugX has a variety of encryption algorithms used to encrypt its data across variants. However, the encryption style is largely similar as depicted in Figure 7.

Figure 7: PlugX Decryption Algorithm

In RasTls, the DWORD decryption key was found in the first four bytes of the encrypted string. It was also less aggressive in encrypting and hiding its data. In older variants such as “win3dx.DLL” (MD5: 7ADAE0335C9D6C9F3826CDE9747438B7), most API names were decrypted before loading and nullified after use. This makes understanding the malware slightly more difficult for malware analysts.

The supported functionalities are largely similar where it uses the identical command code. Below is a list of PlugX commands for file system manipulation:

• 0×3000: GetDiskRelatedInformation
• 0×3001: SearchDirectoryForFiles
• 0×3002: SearchDirectoryRecursively
• 0×3004: ReadFile
• 0×3007: WriteFile
• 0x300A: CreateDirectory
• 0x300C: CreateWindowsDesktop
• 0x300D: PerformSH_FileOperation
• 0x300E: ExpandEnvironmentVariable

Some improvements were made by its developers. For example, the key logger function was updated to utilize the GetRawInputData API to collect keystrokes. “RegisterRawInputDevices” and “GetRawInputData” were two of the few API names that remain encrypted in RasTls.

Figure 8: Updated Key Logging Component

PlugX / Kaba Trending

Figure 9 shows the trending of total PlugX / Kaba infections and their variants: SideBar and RasTLS. The spike in September 2013 was caused by SideBar. In 2014, we see SideBar and RasTLS on an inverse trend, with the latter on a steady increase.

Figure 9: Trending of Overall PlugX / Kaba , SideBar, RasTLS Infections

Figure 10 shows the distribution of SideBar/RasTls variants by country. The C2 servers are located in Hong Kong, where much of the attacks have occurred. We also find a variety of countries targeted by these variants. In some of the exploit documents delivering these variants, the content revolves around the theme of NGOs and socio-political events in China and Japan. These are content that would likely be of interest to the victims who would be opening the documents.

Figure 10: Distribution of SideBar/RasTls Variants by Country

Conclusion

The Asia Pacific region remains a highly attractive target of advanced cyber-attacks. Many threat groups  have a particular in interest in this region, and are likely continue to launch new attacks against targets here. We recommend that users in this region block access to the above C2 servers. FireEye Labs will continue to monitor and report on new PlugX / Kaba developments.

Introduction

Our worldwide sensor network provides researchers at FireEye Labs with unique opportunities to detect innovative tactics employed by malicious actors and protects our clients from these tactics. We recently uncovered a coordinated campaign targeting Internet infrastructure providers, a media organization, a financial services company, and an Asian government organization. The actor responsible for this campaign utilized legitimate digital certificates to sign their tools and employed innovative techniques to cloak their command and control traffic.

Hurricane Electric Redirection

In March of 2014, we detected Kaba (aka PlugX or SOGU) callback traffic to legitimate domains and IP addresses. Our initial conclusion was that this traffic was the result of malicious actors ‘sleeping’ their implants, by pointing their command and control domains at legitimate IP addresses. As this is a popular technique, we did not think much of this traffic at the time.

Further analysis revealed that the HTTP headers of the traffic in question contained a Host: entry for legitimate domains. As we have previously observed malware families that forge their HTTP headers to include legitimate domains in callback traffic, we concluded that the malware in this case was configured in the same way.

An example of the observed traffic is as follows:

POST /C542BB084F927229348B2A34 HTTP/1.1
Accept: */*
CG100: 0
CG103: 0
CG107: 61456
CG108: 1
User-Agent: Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C)
Host: www.adobe.com
Content-Length: 0
Cache-Control: no-cache

As we continued to see this odd traffic throughout the summer we began a search for malware samples responsible for this behavior. Via this research, we found a malware sample that we believe was responsible for at least some of the strange traffic that we had observed. The identified sample had the following properties:

MD5: 52d2d1ab9b84303a585fb81e927b9e01
Size: 180296
Compile Time: 2013-10-15 05:17:37
Import Hash: b29eb78c7ec3f0e89bdd79e3f027c029
.rdata: d7b6e412ba892e9751f845432625bbb0
.text: ed0dd6825e3536d878f39009a7777edc
.data: 1bc25d2f0f3123bedea254ea7446dd50
.rsrc: 91484aa628cc64dc8eba867a8493c859
.reloc: f1df8fa77b5abb94563d5d97e5ccb8e2
RT_VERSION: 9dd9b7c184069135c23560f8fbaa829adc7af6d2047cf5742b5a1e7c5c923cb9

This sample was signed with a legitimate digital certificate from the ‘Police Mutual Aid Association’. This certificate has a serial number of ‘06 55 69 a3 e2 61 40 91 28 a4 0a ff a9 0d 6d 10’.

Analysis of this Kaba sample revealed that it was configured to directly connect to both www.adobe.com and update.adobe.com. Obviously, this configuration does not make a lot of sense, as the actor would not be able to control their implants from anywhere on the Internet since they did not have direct control over these domains – unless the attackers were able to re-route traffic destined for these domains from specific victims. Indeed, further analysis of this Kaba variant revealed that it was also configured to use specific DNS resolvers. This sample was configured to resolve DNS lookups via Hurricane Electric’s nameservers of 216.218.130.2, 216.218.131.2, 216.218.132.2 and 216.66.1.2.

We found this interesting, so we investigated how these Hurricane Electric’s nameservers were configured. Subsequently, we found that anyone could register for a free account with Hurricane Electric’s hosted DNS service. Via this service, anyone with an account was able to register a zone and create A records for the registered zone and point those A records to any IP address they so desired. The dangerous aspect of this service is that anyone was able to hijack legitimate domains such as adobe.com. Although these nameservers are not recursors and were not designed to be queried directly by end users, they were returning results if queried directly for domains that were configured via Hurricane Electrics public DNS service. Furthermore, Hurricane Electric did not check if zones created by their users were already been registered or are otherwise legitimately owned by other parties.

As we continued this research, we identified 21 legitimate fully qualified domain names that had been hijacked via this technique by at least one APT actor. In addition to the adobe.com domain mentioned above, another one of the poisoned domains is www.outlook.com. A lookup of this domain via Google’s DNS resolvers returns expected results:

$ dig +short @8.8.8.8 www.outlook.com
www.outlook.com.glbdns2.microsoft.com.
www-nameast.outlook.com.
157.56.240.246
157.56.236.102
157.56.240.214
157.56.241.102
157.56.232.182
157.56.241.118
157.56.240.22

A quick lookup of these addresses reveal that Microsoft owns them:

157.56.240.246 | 8075 | 157.56.0.0/16 | MICROSOFT-CORP-MSN-A | US | MICROSOFT.COM | MICROSOFT CORPORATION
157.56.236.102 | 8075 | 157.56.0.0/16 | MICROSOFT-CORP-MSN-A | US | MICROSOFT.COM | MICROSOFT CORPORATION
157.56.240.214 | 8075 | 157.56.0.0/16 | MICROSOFT-CORP-MSN-A | US | MICROSOFT.COM | MICROSOFT CORPORATION
157.56.241.102 | 8075 | 157.56.0.0/16 | MICROSOFT-CORP-MSN-A | US | MICROSOFT.COM | MICROSOFT CORPORATION
157.56.232.182 | 8075 | 157.56.0.0/16 | MICROSOFT-CORP-MSN-A | US | MICROSOFT.COM | MICROSOFT CORPORATION
157.56.241.118 | 8075 | 157.56.0.0/16 | MICROSOFT-CORP-MSN-A | US | MICROSOFT.COM | MICROSOFT CORPORATION
157.56.240.22 | 8075 | 157.56.0.0/16 | MICROSOFT-CORP-MSN-A | US | MICROSOFT.COM | MICROSOFT CORPORATION

However, as recently as August 4, 2014 a lookup of the same www.outlook.com domain via Hurricane Electric’s resolvers returned entirely different results[1]:

$ dig +short @216.218.130.2 www.outlook.com
59.125.42.167

$ dig +short @216.218.131.2 www.outlook.com
59.125.42.167

$ dig +short @216.218.132.2 www.outlook.com
59.125.42.167

$ dig +short @216.66.1.2 www.outlook.com
59.125.42.167

$ whois -h asn.shadowserver.org ‘origin 59.125.42.167′
3462 | 59.125.0.0/17 | HINET | TW | HINET.NET | DATA COMMUNICATION BUSINESS GROUP

Passive DNS research on the 59.125.42.167 IP address revealed that multiple APT actors have previously used this IP address.

Additional researched uncovered more Kaba samples that were configured to leverage Hurricane Electric’s public DNS resolvers. Another sample has the following properties:

MD5: eae0391e92a913e757ac78b14a6f079f
Size: 184304
Compile Time: 2013-11-26 17:39:25
Import Hash: f749528b1db6fe5aee61970813c7bc18
Text Entry: 558bec83ec1056ff7508ff1518b00010
.rdata: 747abda5b3cd3494f056ab4345a909e4
.text: 475c20b8abc972710941ad6659492047
.data: d461f8f7b3f35b7c6855add6ae59e806
.rsrc: b195f57cb5e605cb719469492d9fe717
.reloc: d6b23cb71f214d33e56cf8f6a10c0c10
RT_VERSION: 9dd9b7c184069135c23560f8fbaa829adc7af6d2047cf5742b5a1e7c5c923cb9

This sample is signed with a recently expired digital certificate from ‘MOCOMSYS INC’. This certificate has a serial number of ‘03 e5 a0 10 b0 5c 92 87 f8 23 c2 58 5f 54 7b 80’.

This sample used Hurricane Electric’s public DNS resolvers to route traffic to the hijacked domains of www.adobe.com and update.adobe.com. We also noted that this sample was configured to connect directly to 59.125.42.168 – one IP address away from the IP that received traffic from the hijacked www.outlook.com domain.

Passive DNS research revealed that this IP hosted the same set of known APT domains listed above:

While this problem does not directly impact users of www.adobe.com, www.outlook.com, or users of the other affected domains, it should not be dismissed as inconsequential. Actors that adopt this tactic and obfuscate the destination of their traffic through localized DNS hijacks can significantly complicate the job of network defenders.

Via our sensor network, we observed the actor responsible for this activity conducting a focused campaign. We observed this actor target:

• Multiple Internet Infrastructure Service Providers in Asia and the United States
• A Media Organization based in the United States
• A financial institution based in Asia
• An Asian government organization

Google Code Command and Control

Furthermore, we also discovered this same actor conducting a parallel campaign that leveraged Google Code for command and control. On August 1, 2014 we observed a malicious self-extracting executable (aka sfxrar) file downloaded from 211.125.81.203. This file had the following properties:

MD5: 17bc9d2a640da75db6cbb66e5898feb1
Size: 282800 bytes

A valid certificate from ‘QTI INTERNATIONAL INC’ was used to sign this sfxrar. This certificate had a serial number of ‘2e df b9 fd cf a0 0c cb 5a b0 09 ee 3a db 97 b9’. The sfxrar contained the following files:

Setup.exe is a legitimate executable from Kaspersky used to load the Kaba (aka PlugX) files – msi.dll and msi.dll.dat.

These Kaba files are configured to connect to Google Code – specifically code.google.com/p/udom/. On August 1, this Google Code project contained the encoded command “DZKSGAAALLBACDCDCDOCBDCDCDOCCDADIDOCBDADDZJS”.

def NewPlugx_C2_redir_decode(s):

rvalue = “”
for x in range(0, len(s), 2):
tmp0 = (ord(s[x+1]) – 0×41) << 4

rvalue += chr(ord(s[x]) + tmp0 – 0×41)
return rvalue

The command ‘DZKSGAAALLBACDCDCDOCBDCDCDOCCDADIDOCBDADDZJS’ decodes to 222.122.208.10. In a live environment, the Kaba implant would then connect to this IP address via UDP.

Further analysis of project at code.google.com/p/udom/ revealed the project owner, 0x916ftb691u, created a number of other projects. We decoded the commands hosted at these linked projects and found that they issued the following decoded commands:

112.175.143.22
59.125.42.167
153.121.57.213
61.82.71.10
202.181.133.169
61.78.32.139
61.78.32.148
202.181.133.216
59.125.42.168
119.205.217.104
222.122.208.10
112.175.143.16
222.122.208.9
27.122.13.204

It is likely that other yet to be discovered Kaba variants are configured to connect to these related Google Code projects and then redirect to this list of IP addresses.

Passive DNS analysis of these IP addresses revealed connections to the following known malicious infrastructure:

Relationships Between Campaigns

As mentioned above the Kaba variant eae0391e92a913e757ac78b14a6f079f shared a common import hash of f749528b1db6fe5aee61970813c7bc18 with many of the samples listed in this post. This samples was to use Hurricane Electric’s nameservers as well as connect directly to the IP address 59.125.42.168.

Note that we identified the same C2 IP 59.125.42.168 via our analysis of the malicious Google Code projects. Specifically, the Google Project at code.google.com/p/tempzz/, which is linked to the project at code.google.com/p/udom/, issued an encoded command that decoded to 59.125.42.168.

We also identified another related Kaba variant that connected to code.google.com/p/updata-server. This variant had the following properties:

MD5: 50af349c69ae4dec74bc41c581b82459
Size: 180600 bytes
Compile Time: 2014-04-01 03:28:31
Import Hash: f749528b1db6fe5aee61970813c7bc18
.rdata: 103beeefae47caa0a5265541437b03a1
.text: e7c4c2445e76bac81125b2a47384d83f
.data: 5216d6e6834913c6cc75f40c8f70cff8
.rsrc: b195f57cb5e605cb719469492d9fe717
.reloc: f7d9d69b8d36fee5a63f78cbd3238414
RT_VERSION: 9dd9b7c184069135c23560f8fbaa829adc7af6d2047cf5742b5a1e7c5c923cb9

This sample was signed with a valid digital certificate from ‘PIXELPLUS CO., LTD’ and had a serial number of ‘0f e7 df 6c 4b 9a 33 b8 3d 04 e2 3e 98 a7 7c ce’.

In addition to sharing the same Import hash of f749528b1db6fe5aee61970813c7bc18 seen in other samples listed throughout this post, 50af349c69ae4dec74bc41c581b82459 contained a RT_VERSION resource of 9dd9b7c184069135c23560f8fbaa829adc7af6d2047cf5742b5a1e7c5c923cb9. This same RT_VERSION was used in a number of other related samples including:

Conclusion

These coordinated campaigns demonstrate that APT actors are determined to continue operations. As computer network defenders increase their capabilities to identify and block these campaigns by deploying more advanced detection technologies, threat actors will continue to adopt creative evasion techniques.

We observed the following evasion techniques in these campaigns:

• The use of legitimate digital certificates to sign malware
• The use of Hurricane Electrics public DNS resolvers to redirect command and control traffic
• The use of Google Code to obfuscate the location of command and control servers

While none of these techniques are necessarily new, in combination, they are certainly both creative and have been observed to be effective. Although the resultant C2 traffic can be successfully detected and tracked, the fact that the malware appears to beacon to legitimate domains may lull defenders into a false sense of security. Network defenders should continue to study the evolution of advanced threat actors, as these adversaries will continue to evolve in pursuit of their designated objectives.

Related MD5s
17bc9d2a640da75db6cbb66e5898feb1
eae0391e92a913e757ac78b14a6f079f
434b539489c588db90574a64f9ce781f
7e6c8992026a79c080f88103f6a69d2c
52d2d1ab9b84303a585fb81e927b9e01
787c6cf3cb18feeabe4227ec6b19db01
50af349c69ae4dec74bc41c581b82459
d51050cf98cc723f0173d1c058c12721

Digital Certificates
MOCOMSYS INC, (03 e5 a0 10 b0 5c 92 87 f8 23 c2 58 5f 54 7b 80)
PIXELPLUS CO., LTD., (0f e7 df 6c 4b 9a 33 b8 3d 04 e2 3e 98 a7 7c ce)
Police Mutual Aid Association (06 55 69 a3 e2 61 40 91 28 a4 0a ff a9 0d 6d 10)
QTI INTERNATIONAL INC (2e df b9 fd cf a0 0c cb 5a b0 09 ee 3a db 97 b9)
Ssangyong Motor Co. (1D 2B C8 46 D1 00 D8 FB 94 FA EA 4B 7B 5F D8 94)
jtc (72 B4 F5 66 7F 69 F5 43 21 A9 40 09 97 4C CC F8)

Footnotes
[1] As of August 4, 2014 Hurricane Electric was no longer returning answers for www.outlook.com or the other affected domains.
[2] This same encoding algorithm was previously described by Cassidian at http://blog.cassidiancybersecurity.com/post/2014/01/plugx-some-uncovered-points.html

Every day, computer network attackers leverage a Leviathan of compromised infrastructure, based in every corner of the globe, to play hide-and-seek with network security, law enforcement, and counterintelligence personnel.

This presentation draws a new map of Planet Earth, based not on traditional parameters, but on hacker command and control (C2) communications. The primary data points used in this worldwide cyber survey are more than 30 million malware callbacks to over 200 countries and territories over an 18-month period, from January 2013 to June 2014.

First, this talk covers the techniques that hackers use to communicate with compromised infrastructure across the globe. The authors analyze the domains, protocols, ports, and websites used for malicious C2. They explain how covert C2 works, and how attackers keep their communications hidden from network security personnel.

Second, this talk looks at strategic impact. The authors examine relationships between the targeted industries and countries and the first-stage malware servers communicating with them. Traffic analysis is used to deduce important relationships, patterns, and trends in the data. This section correlates C2 communications to traditional geopolitical conflicts and considers whether computer network activity can be used to predict real world events.

In conclusion, the authors consider the future of this Leviathan, including whether governments can subdue it – and whether they would even want to.

Attend this presentation on August 7 at 10:15am PT in South Seas GH. Make sure to use #BHUSA and @FireEye if you plan to tweet highlights from the talk.

To view the whitepaper, click here.

Introduction

The attackers referred to as APT12 (also known as IXESHE, DynCalc, and DNSCALC) recently started a new campaign targeting organizations in Japan and Taiwan. APT12 is believed to be a cyber espionage group thought to have links to the Chinese People’s Liberation Army. APT12′s targets are consistent with larger People’s Republic of China (PRC) goals. Intrusions and campaigns conducted by this group are in-line with PRC goals and self-interest in Taiwan. Additionally, the new campaigns we uncovered further highlight the correlation between APT groups ceasing and retooling operations after media exposure, as APT12 used the same strategy after compromising the New York Times in Oct 2012. Much like Darwin’s theory of biological evolution, APT12 been forced to evolve and adapt in order to maintain its mission.

The new campaign marks the first APT12 activity publicly reported since Arbor Networks released their blog “Illuminating The Etumbot APT Backdoor.” FireEye refers to the Etumbot backdoor as RIPTIDE. Since the release of the Arbor blog post, FireEye has observed APT12 use a modified RIPTIDE backdoor that we call HIGHTIDE. This is the second time FireEye has discovered APT12 retooling after a public disclosure. As such, FireEye believes this to be a common theme for this APT group, as APT12 will continue to evolve in an effort to avoid detection and continue its cyber operations.

FireEye researchers also discovered two possibly related campaigns utilizing two other backdoors known as THREEBYTE and WATERSPOUT. Both backdoors were dropped from malicious documents built utilizing the “Tran Duy Linh” exploit kit, which exploited CVE-2012-0158. These documents were also emailed to organizations in Japan and Taiwan. While APT12 has previously used THREEBYTE, it is unclear if APT12 was responsible for the recently discovered campaign utilizing THREEBYTE. Similarly, WATERSPOUT is a newly discovered backdoor and the threat actors behind the campaign have not been positively identified. However, the WATERSPOUT campaign shared several traits with the RIPTIDE and HIGHTIDE campaign that we have attributed to APT12.

Background

From October 2012 to May 2014, FireEye observed APT12 utilizing RIPTIDE, a proxy-aware backdoor that communicates via HTTP to a hard-coded command and control (C2) server. RIPTIDE’s first communication with its C2 server fetches an encryption key, and the RC4 encryption key is used to encrypt all further communication.

Figure 1: RIPTIDE HTTP GET Request Example

In June 2014, Arbor Networks published an article describing the RIPTIDE backdoor and its C2 infrastructure in great depth. The blog highlighted that the backdoor was utilized in campaigns from March 2011 till May 2014.

Following the release of the article, FireEye observed a distinct change in RIPTIDE’s protocols and strings. We suspect this change was a direct result of the Arbor blog post in order to decrease detection of RIPTIDE by security vendors. The changes to RIPTIDE were significant enough to circumvent existing RIPTIDE detection rules. FireEye dubbed this new malware family HIGHTIDE.

HIGHTIDE Malware Family

On Sunday August 24, 2014 we observed a spear phish email sent to a Taiwanese government ministry. Attached to this email was a malicious Microsoft Word document (MD5: f6fafb7c30b1114befc93f39d0698560) that exploited CVE-2012-0158. It is worth noting that this email appeared to have been sent from another Taiwanese Government employee, implying that the email was sent from a valid but compromised account.

Figure 2:  APT12 Spearphishing Email

The exploit document dropped the HIGHTIDE backdoor with the following properties:

The HIGHTIDE backdoor connected directly to 141.108.2.157. If you compare the HTTP GET request from the RIPTIDE samples (Figure 1) to the HTTP GET request from the HIGHTIDE samples (Figure 3) you can see the malware author changed the following items:

• User Agent
• Format and structure of the HTTP Uniform Resource Identifier (URI)

Figure 3: HIGHTIDE GET Request Example

Similar to RIPTIDE campaigns, APT12 infects target systems with HIGHTIDE using a Microsoft Word (.doc) document that exploits CVE-2012-0158. FireEye observed APT12 deliver these exploit documents via phishing emails in multiple cases. Based on past APT12 activity, we expect the threat group to continue to utilize phishing as a malware delivery method.

Figure 4: Identified exploit documents for HIGHTIDE 

When the file is opened, it drops HIGHTIDE in the form of an executable file onto the infected system.

RIPTIDE and HIGHTIDE differ on several points: executable file location, image base address, the User-Agent within the GET requests, and the format of the URI. The RIPTIDE exploit document drops its executable file into the C:\Documents and Settings\{user}\Application Data\Location folder while the HIGHTIDE exploit document drops its executable file into the C:\DOCUMENTS and SETTINGS\{user}\LOCAL SETTINGS\Temp\ folder. All but one sample that we identified were written to this folder as word.exe. The one outlier was written as winword.exe.

Research into this HIGHTIDE campaign revealed APT12 targeted multiple Taiwanese Government organizations between August 22 and 28.

THREEBYTE Malware Family

On Monday August 25, 2014 we observed a different spear phish email sent from lilywang823@gmail.com to a technology company located in Taiwan. This spear phish contained a malicious Word document that exploited CVE-2012-0158. The MD5 of the exploit document was e009b95ff7b69cbbebc538b2c5728b11.

Similar to the newly discovered HIGHTIDE samples documented above, this malicious document dropped a backdoor to C:\DOCUMENTS and SETTINGS\{user}\LOCAL SETTINGS\Temp\word.exe. This backdoor had the following properties:

This backdoor sent the following callback traffic to video[.]csmcpr[.]com:

Figure 5:  THREEBYTE GET Request Beacon

The THREEBYTE spear phishing incident (while not yet attributed) shared the following characteristics with the above HIGHTIDE campaign attributed to APT12:

• The THREEBYTE backdoor was compiled two days after the HIGHTIDE backdoors.
• Both the THREEBYTE and HIGHTIDE backdoors were used in attacks targeting organizations in Taiwan.
• Both the THREEBYTE and HIGHTIDE backdoors were written to the same filepath of C:\DOCUMENTS and SETTINGS\{user}\LOCAL SETTINGS\Temp\word.exe.
• APT12 has previously used the THREEBYTE backdoor.

WATERSPOUT Malware Family

On August 25, 2014, we observed another round of spear phishing emails targeting a high-technology company in Japan. Attached to this email was another malicious document that was designed to exploit CVE-2012-0158. This malicious Word document had an MD5 of 499bec15ac83f2c8998f03917b63652e and dropped a backdoor to C:\DOCUMENTS and SETTINGS\{user}\LOCAL SETTINGS\Temp\word.exe. The backdoor had the following properties:

The backdoor connects to a command and control server at icc[.]ignorelist[.]com.

Similar to RIPTIDE and HIGHTIDE, the WATERSPOUT backdoor is an HTTP-based backdoor that communicates with its C2 server.

Figure 6: Sample GET request for WATERSPOUT backdoor

Although there are no current infrastructure ties to link this backdoor to APT12, there are several data points that show a possible tie to the same actors:

• Same initial delivery method (spear phishing email) with a Microsoft Word Document exploiting CVE-2012-0158.
  • The same “Tran Duy Linh” Microsoft Word Exploit Kit was used in delivery of this backdoor.
• Similar Targets were observed where the threat actors utilized this backdoor.
  • Japanese Tech Company
  • Taiwanese Government Organizations
  • Organizations in the Asia-Pacific Region that are of Interest to China
• The WATERSPOUT backdoor was written to the same file path as the HIGHTIDE backdoors:
  • C:\DOCUMENTS and SETTINGS\{user}\LOCAL SETTINGS\Temp\word.exe
  • C:\DOCUMENTS and SETTINGS\{user}\LOCAL SETTINGS\Temp\winword.exe
• WATERSPOUT was compiled within two days of the last HIGHTIDE backdoor and on the same day as the THREEBYTE backdoor.

Although these points do not definitively tie WATERSPOUT to APT12, they do indicate a possible connection between the WATERSPOUT campaign, the THREEBYTE campaign, and the HIGHTIDE campaign attributed to APT12.

Conclusion
FireEye believes the change from RIPTIDE to HIGHTIDE represents a temporary tool shift to decrease malware detection while APT12 developed a completely new malware toolset. These development efforts may have resulted in the emergence of the WATERSPOUT backdoor.

Figure 7: Compile dates for all three malware families 

APT12’s adaptations to public disclosures lead FireEye to make several conclusions about this threat group:

• APT12 closely monitors online media related to its tools and operations and reacts when its tools are publicly disclosed.
• APT12 has the ability to adapt quickly to public exposures with new tools, tactics, and procedures (TTPs).
• Public disclosures may result in an immediate change in APT12’s tools. These changes may be temporary and FireEye believes they are aimed at decreasing detection of their tools until a more permanent and effective TTP change can be implemented (e.g., WATERSPOUT).

Though public disclosures resulted in APT12 adaptations, FireEye observed only a brief pause in APT12 activity before the threat actors returned to normal activity levels. Similarly, the public disclosure of APT12’s intrusion at the New York Times also led to only a brief pause in the threat group’s activity and immediate changes in TTPs. The pause and retooling by APT12 was covered in the Mandiant 2014 M-Trends report. Currently, APT12 continues to target organizations and conduct cyber operations using its new tools. Most recently, FireEye observed HIGHTIDE at multiple Taiwan-based organizations and the suspected APT12 WATERSPOUT backdoor at a Japan-based electronics company. We expect that APT12 will continue their trend and evolve and change its tactics to stay ahead of network defenders.

Note: IOCs for this campaign can be found here.

Lines of people, lines of parts. The modern production line is composed of individuals contributing to a larger process. This common manufacturing approach is efficient, effective, and profitable.

Now it appears cyber attack groups in the world’s largest manufacturing country are using a similar approach to infiltrate targeted networks and compromise data – collaborating for increased efficiency and effectiveness.

FireEye Labs have published a report – Operation Quantum Entanglement – that details two attack campaigns by different groups in separate regions of China, apparently operating in parallel.

The first group, named Moafee, appears to operate from the Guandong Province. Its targets include the military organizations and governments of countries with national interests in the South China Sea, including some within the U.S. defense industrial base. Moafee may have chosen its targets based on the rich resources of South China Sea region – the world’s second business sea-lane, according to Wikipedia – including rare earth metals, crude oil, and natural gas.

The second group, known as DragonOK, targets high-tech and manufacturing companies in Japan and Taiwan. This may indicate they’re acquiring trade secrets for a competitive economic advantage in the area. DragonOK appears to operate out of China’s Jiangsu Province.

It seems that both groups, while operating in distinctly different regions, either 1) collaborate, 2) receive the same training), 3) share a common toolkit supply chain, or 4) some combination of these scenarios, which means they are employing a ‘production line’-type approach to initiating cyber attacks to breach defenses.

Mirroring Each Other

Both campaigns use similar tools, techniques and procedures (TTPs) – including custom-built backdoors and remote-administration tools (RATs) to infiltrate their targets’ networks.

Moafee and DragonOK both use a well-known proxy tool – HUC Packet Transmit Tool (HTRAN) – to disguise their geographical locations. Both utilize password-protected documents and large file sizes to disguise their attacks. These approaches, along with other similarities in TTPs we’ll review below, seem to indicate the groups are affiliated in some way and have at least some commonality in their attack campaigns.

A third, separate group also appears to be using the same TTPs, including the same custom backdoors and RATs; however, FireEye researchers do not have enough insight to reliably report a definitive connection to the Moafee and DragonOK groups.

Hidden from Sight

Both Moafee and DragonOK favor spear-phishing emails as an attack vector, often employing a decoy to deceive the victim. The emails are well crafted and audience specific, even written in the intended victim’s native language.

Attachments are typically sent as an executable file embedded in a ZIP archive or a password-protected Microsoft Office document. We also observed both groups using decoy documents that are presented to the victim while the malware runs in the background.

The groups both use common, and multiple, methods to hide their activities. Employing sandbox environments, antivirus software and gateway firewalls, they do their best to remain unobtrusive. Methods include:

• checking for the number of core processors (and quitting if only one is detected);
• attaching password-protected documents and providing a password in the email contents; and
• sending large files padded with unnecessary null bites to slide past network- and host-based AV engines that can’t scan larger files.

Tools of the Trade 

The two different operators seem to share backdoors and RATs – some of which are custom; others are publicly available. Overlapping tools include:

• CT/NewCT/NewCT2
• Mongall
• Nflog
• PoisonIvy

We observed Moafee running HTRAN proxies on their multiple Command and Control (C2) servers – all operated on CHINANET, and hosted in Guangdong Province.

Like the Moafee group, we observed DragonOK running HTRAN to proxy their C2 servers, which are also operated on CHINANET but are hosted in the Jiangsu Province.

Summary

Primarily focused on governments and military operations of countries with interests in the South China Sea, Moafee likely chooses its targets based on region’s rich natural resources. By targeting high-tech and manufacturing operations in Japan and Taiwan, DragonOK may be acquiring trade secrets for a competitive economic advantage.

While their targets and missions appear different, our researchers found enough linking evidence to demonstrate a relationship between Moafee and DragonOK, and perhaps even a third attack group. By sharing TTPs and coordinating joint attacks, these advanced threat actors are leveraging China’s supply chain economic expertise to perform extensive worldwide espionage.

Summary

FireEye Research Labs identified a new Internet Explorer (IE) zero-day exploit used in targeted attacks.  The vulnerability affects IE6 through IE11, but the attack is targeting IE9 through IE11.  This zero-day bypasses both ASLR and DEP. Microsoft has assigned CVE-2014-1776 to the vulnerability and released security advisory to track this issue.

Threat actors are actively using this exploit in an ongoing campaign which we have named “Operation Clandestine Fox.” However, for many reasons, we will not provide campaign details. But we believe this is a significant zero day as the vulnerable versions represent about a quarter of the total browser market. We recommend applying a patch once available.
According to NetMarket Share, the market share for the targeted versions of IE in 2013 were:

IE 9      13.9%
IE 10    11.04%
IE 11     1.32%

Collectively, in 2013, the vulnerable versions of IE accounted for 26.25% of the browser market.  The vulnerability, however, does appear in IE6 through IE11 though the exploit targets IE9 and higher.

The Details

The exploit leverages a previously unknown use-after-free vulnerability, and uses a well-known Flash exploitation technique to achieve arbitrary memory access and bypass Windows’ ASLR and DEP protections.

Exploitation

• Preparing the heap

The exploit page loads a Flash SWF file to manipulate the heap layout with the common technique heap feng shui. It allocates Flash vector objects to spray memory and cover address 0×18184000. Next, it allocates a vector object that contains a flash.Media.Sound() object, which it later corrupts to pivot control to its ROP chain.

• Arbitrary memory access

The SWF file calls back to Javascript in IE to trigger the IE bug and overwrite the length field of a Flash vector object in the heapspray. The SWF file loops through the heapspray to find the corrupted vector object, and uses it to again modify the length of another vector object. This other corrupted vector object is then used for subsequent memory accesses, which it then uses to bypass ASLR and DEP.

• Runtime ROP generation

With full memory control, the exploit will search for ZwProtectVirtualMemory, and a stack pivot (opcode 0×94 0xc3) from NTDLL. It also searches for SetThreadContext in kernel32, which is used to clear the debug registers. This technique, documented here, may be an attempt to bypass protections that use hardware breakpoints, such as EMET’s EAF mitigation.

With the addresses of the aforementioned APIs and gadget, the SWF file constructs a ROP chain, and prepends it to its RC4 decrypted shellcode. It then replaces the vftable of a sound object with a fake one that points to the newly created ROP payload. When the sound object attempts to call into its vftable, it instead pivots control to the attacker’s ROP chain.

• ROP and Shellcode

The ROP payload basically tries to make memory at 0×18184000 executable, and to return to 0x1818411c to execute the shellcode.

0:008> dds eax
18184100  770b5f58 ntdll!ZwProtectVirtualMemory
18184104  1818411c
18184108  ffffffff
1818410c  181840e8
18184110  181840ec
18184114  00000040
18184118  181840e4

Inside the shellcode, it saves the current stack pointer to 0×18181800 to safely return to the caller.

mov     dword ptr ds:[18181800h],ebp

Then, it restores the flash.Media.Sound vftable and repairs the corrupted vector object to avoid application crashes.

18184123 b820609f06      mov     eax,69F6020h
18184128 90              nop
18184129 90              nop
1818412a c700c0f22169    mov     dword ptr [eax],offset Flash32_11_7_700_261!AdobeCPGetAPI+0x42ac00 (6921f2c0)
18184133 b800401818      mov     eax,18184000h
18184138 90              nop
18184139 90              nop
1818413a c700fe030000    mov     dword ptr [eax],3FEh ds:0023:18184000=3ffffff0

The shellcode also recovers the ESP register to make sure the stack range is in the current thread stack base/limit.

18184140 8be5            mov     esp,ebp
18184142 83ec2c          sub     esp,2Ch
18184145 90              nop
18184146 eb2c            jmp     18184174

The shellcode calls SetThreadContext to clear the debug registers. It is possible that this is an attempt to bypass mitigations that use the debug registers.

18184174 57              push    edi
18184175 81ece0050000    sub     esp,5E0h
1818417b c7042410000100  mov     dword ptr [esp],10010h
18184182 8d7c2404        lea     edi,[esp+4]
18184186 b9dc050000      mov     ecx,5DCh
1818418b 33c0            xor     eax,eax
1818418d f3aa            rep stos byte ptr es:[edi]
1818418f 54              push    esp
18184190 6afe            push    0FFFFFFFEh
18184192 b8b308b476      mov     eax,offset kernel32!SetThreadContext (76b408b3)
18184197 ffd0            call    eax

The shellcode calls URLDownloadToCacheFileA to download the next stage of the payload, disguised as an image.

Mitigation

Using EMET may break the exploit in your environment and prevent it from successfully controlling your computer. EMET versions 4.1 and 5.0 break (and/or detect) the exploit in our tests.
Enhanced Protected Mode in IE breaks the exploit in our tests. EPM was introduced in IE10.
Additionally, the attack will not work without Adobe Flash. Disabling the Flash plugin within IE will prevent the exploit from functioning.

Threat Group History

The APT group responsible for this exploit has been the first group to have access to a select number of browser-based 0-day exploits (e.g. IE, Firefox, and Flash) in the past. They are extremely proficient at lateral movement and are difficult to track, as they typically do not reuse command and control infrastructure. They have a number of backdoors including one known as Pirpi that we previously discussed here. CVE-2010-3962, then a 0-day exploit in Internet Explorer 6, 7, and 8 dropped the Pirpi payload discussed in this previous case.

As this is still an active investigation we are not releasing further indicators about the exploit at this time.

Acknowledgement: We thank Christopher Glyer, Matt Fowler, Josh Homan, Ned Moran, Nart Villeneuve and Yichong Lin for their support, research, and analysis on these findings.

Lines of people, lines of parts. The modern production line is composed of individuals contributing to a larger process. This common manufacturing approach is efficient, effective, and profitable.

Now it appears cyber attack groups in the world’s largest manufacturing country are using a similar approach to infiltrate targeted networks and compromise data – collaborating for increased efficiency and effectiveness.

FireEye Labs have published a report – Operation Quantum Entanglement – that details two attack campaigns by different groups in separate regions of China, apparently operating in parallel.

The first group, named Moafee, appears to operate from the Guandong Province. Its targets include the military organizations and governments of countries with national interests in the South China Sea, including some within the U.S. defense industrial base. Moafee may have chosen its targets based on the rich resources of South China Sea region – the world’s second business sea-lane, according to Wikipedia – including rare earth metals, crude oil, and natural gas.

The second group, known as DragonOK, targets high-tech and manufacturing companies in Japan and Taiwan. This may indicate they’re acquiring trade secrets for a competitive economic advantage in the area. DragonOK appears to operate out of China’s Jiangsu Province.

It seems that both groups, while operating in distinctly different regions, either 1) collaborate, 2) receive the same training), 3) share a common toolkit supply chain, or 4) some combination of these scenarios, which means they are employing a ‘production line’-type approach to initiating cyber attacks to breach defenses.

Mirroring Each Other

Both campaigns use similar tools, techniques and procedures (TTPs) – including custom-built backdoors and remote-administration tools (RATs) to infiltrate their targets’ networks.

Moafee and DragonOK both use a well-known proxy tool – HUC Packet Transmit Tool (HTRAN) – to disguise their geographical locations. Both utilize password-protected documents and large file sizes to disguise their attacks. These approaches, along with other similarities in TTPs we’ll review below, seem to indicate the groups are affiliated in some way and have at least some commonality in their attack campaigns.

A third, separate group also appears to be using the same TTPs, including the same custom backdoors and RATs; however, FireEye researchers do not have enough insight to reliably report a definitive connection to the Moafee and DragonOK groups.

Hidden from Sight

Both Moafee and DragonOK favor spear-phishing emails as an attack vector, often employing a decoy to deceive the victim. The emails are well crafted and audience specific, even written in the intended victim’s native language.

Attachments are typically sent as an executable file embedded in a ZIP archive or a password-protected Microsoft Office document. We also observed both groups using decoy documents that are presented to the victim while the malware runs in the background.

The groups both use common, and multiple, methods to hide their activities. Employing sandbox environments, antivirus software and gateway firewalls, they do their best to remain unobtrusive. Methods include:

• checking for the number of core processors (and quitting if only one is detected);
• attaching password-protected documents and providing a password in the email contents; and
• sending large files padded with unnecessary null bites to slide past network- and host-based AV engines that can’t scan larger files.

Tools of the Trade 

The two different operators seem to share backdoors and RATs – some of which are custom; others are publicly available. Overlapping tools include:

• CT/NewCT/NewCT2
• Mongall
• Nflog
• PoisonIvy

We observed Moafee running HTRAN proxies on their multiple Command and Control (C2) servers – all operated on CHINANET, and hosted in Guangdong Province.

Like the Moafee group, we observed DragonOK running HTRAN to proxy their C2 servers, which are also operated on CHINANET but are hosted in the Jiangsu Province.

Summary

Primarily focused on governments and military operations of countries with interests in the South China Sea, Moafee likely chooses its targets based on region’s rich natural resources. By targeting high-tech and manufacturing operations in Japan and Taiwan, DragonOK may be acquiring trade secrets for a competitive economic advantage.

While their targets and missions appear different, our researchers found enough linking evidence to demonstrate a relationship between Moafee and DragonOK, and perhaps even a third attack group. By sharing TTPs and coordinating joint attacks, these advanced threat actors are leveraging China’s supply chain economic expertise to perform extensive worldwide espionage.

Summary

FireEye Research Labs identified a new Internet Explorer (IE) zero-day exploit used in targeted attacks.  The vulnerability affects IE6 through IE11, but the attack is targeting IE9 through IE11.  This zero-day bypasses both ASLR and DEP. Microsoft has assigned CVE-2014-1776 to the vulnerability and released security advisory to track this issue.

Threat actors are actively using this exploit in an ongoing campaign which we have named “Operation Clandestine Fox.” However, for many reasons, we will not provide campaign details. But we believe this is a significant zero day as the vulnerable versions represent about a quarter of the total browser market. We recommend applying a patch once available.
According to NetMarket Share, the market share for the targeted versions of IE in 2013 were:

IE 9      13.9%
IE 10    11.04%
IE 11     1.32%

Collectively, in 2013, the vulnerable versions of IE accounted for 26.25% of the browser market.  The vulnerability, however, does appear in IE6 through IE11 though the exploit targets IE9 and higher.

The Details

The exploit leverages a previously unknown use-after-free vulnerability, and uses a well-known Flash exploitation technique to achieve arbitrary memory access and bypass Windows’ ASLR and DEP protections.

Exploitation

• Preparing the heap

The exploit page loads a Flash SWF file to manipulate the heap layout with the common technique heap feng shui. It allocates Flash vector objects to spray memory and cover address 0×18184000. Next, it allocates a vector object that contains a flash.Media.Sound() object, which it later corrupts to pivot control to its ROP chain.

• Arbitrary memory access

The SWF file calls back to Javascript in IE to trigger the IE bug and overwrite the length field of a Flash vector object in the heapspray. The SWF file loops through the heapspray to find the corrupted vector object, and uses it to again modify the length of another vector object. This other corrupted vector object is then used for subsequent memory accesses, which it then uses to bypass ASLR and DEP.

• Runtime ROP generation

With full memory control, the exploit will search for ZwProtectVirtualMemory, and a stack pivot (opcode 0×94 0xc3) from NTDLL. It also searches for SetThreadContext in kernel32, which is used to clear the debug registers. This technique, documented here, may be an attempt to bypass protections that use hardware breakpoints, such as EMET’s EAF mitigation.

With the addresses of the aforementioned APIs and gadget, the SWF file constructs a ROP chain, and prepends it to its RC4 decrypted shellcode. It then replaces the vftable of a sound object with a fake one that points to the newly created ROP payload. When the sound object attempts to call into its vftable, it instead pivots control to the attacker’s ROP chain.

• ROP and Shellcode

The ROP payload basically tries to make memory at 0×18184000 executable, and to return to 0x1818411c to execute the shellcode.

0:008> dds eax
18184100  770b5f58 ntdll!ZwProtectVirtualMemory
18184104  1818411c
18184108  ffffffff
1818410c  181840e8
18184110  181840ec
18184114  00000040
18184118  181840e4

Inside the shellcode, it saves the current stack pointer to 0×18181800 to safely return to the caller.

mov     dword ptr ds:[18181800h],ebp

Then, it restores the flash.Media.Sound vftable and repairs the corrupted vector object to avoid application crashes.

18184123 b820609f06      mov     eax,69F6020h
18184128 90              nop
18184129 90              nop
1818412a c700c0f22169    mov     dword ptr [eax],offset Flash32_11_7_700_261!AdobeCPGetAPI+0x42ac00 (6921f2c0)
18184133 b800401818      mov     eax,18184000h
18184138 90              nop
18184139 90              nop
1818413a c700fe030000    mov     dword ptr [eax],3FEh ds:0023:18184000=3ffffff0

The shellcode also recovers the ESP register to make sure the stack range is in the current thread stack base/limit.

18184140 8be5            mov     esp,ebp
18184142 83ec2c          sub     esp,2Ch
18184145 90              nop
18184146 eb2c            jmp     18184174

The shellcode calls SetThreadContext to clear the debug registers. It is possible that this is an attempt to bypass mitigations that use the debug registers.

18184174 57              push    edi
18184175 81ece0050000    sub     esp,5E0h
1818417b c7042410000100  mov     dword ptr [esp],10010h
18184182 8d7c2404        lea     edi,[esp+4]
18184186 b9dc050000      mov     ecx,5DCh
1818418b 33c0            xor     eax,eax
1818418d f3aa            rep stos byte ptr es:[edi]
1818418f 54              push    esp
18184190 6afe            push    0FFFFFFFEh
18184192 b8b308b476      mov     eax,offset kernel32!SetThreadContext (76b408b3)
18184197 ffd0            call    eax

The shellcode calls URLDownloadToCacheFileA to download the next stage of the payload, disguised as an image.

Mitigation

Using EMET may break the exploit in your environment and prevent it from successfully controlling your computer. EMET versions 4.1 and 5.0 break (and/or detect) the exploit in our tests.
Enhanced Protected Mode in IE breaks the exploit in our tests. EPM was introduced in IE10.
Additionally, the attack will not work without Adobe Flash. Disabling the Flash plugin within IE will prevent the exploit from functioning.

Threat Group History

The APT group responsible for this exploit has been the first group to have access to a select number of browser-based 0-day exploits (e.g. IE, Firefox, and Flash) in the past. They are extremely proficient at lateral movement and are difficult to track, as they typically do not reuse command and control infrastructure. They have a number of backdoors including one known as Pirpi that we previously discussed here. CVE-2010-3962, then a 0-day exploit in Internet Explorer 6, 7, and 8 dropped the Pirpi payload discussed in this previous case.

As this is still an active investigation we are not releasing further indicators about the exploit at this time.

Acknowledgement: We thank Christopher Glyer, Matt Fowler, Josh Homan, Ned Moran, Nart Villeneuve and Yichong Lin for their support, research, and analysis on these findings.

Lines of people, lines of parts. The modern production line is composed of individuals contributing to a larger process. This common manufacturing approach is efficient, effective, and profitable.

Now it appears cyber attack groups in the world’s largest manufacturing country are using a similar approach to infiltrate targeted networks and compromise data – collaborating for increased efficiency and effectiveness.

FireEye Labs have published a report – Operation Quantum Entanglement – that details two attack campaigns by different groups in separate regions of China, apparently operating in parallel.

The first group, named Moafee, appears to operate from the Guandong Province. Its targets include the military organizations and governments of countries with national interests in the South China Sea, including some within the U.S. defense industrial base. Moafee may have chosen its targets based on the rich resources of South China Sea region – the world’s second business sea-lane, according to Wikipedia – including rare earth metals, crude oil, and natural gas.

The second group, known as DragonOK, targets high-tech and manufacturing companies in Japan and Taiwan. This may indicate they’re acquiring trade secrets for a competitive economic advantage in the area. DragonOK appears to operate out of China’s Jiangsu Province.

It seems that both groups, while operating in distinctly different regions, either 1) collaborate, 2) receive the same training), 3) share a common toolkit supply chain, or 4) some combination of these scenarios, which means they are employing a ‘production line’-type approach to initiating cyber attacks to breach defenses.

Mirroring Each Other

Both campaigns use similar tools, techniques and procedures (TTPs) – including custom-built backdoors and remote-administration tools (RATs) to infiltrate their targets’ networks.

Moafee and DragonOK both use a well-known proxy tool – HUC Packet Transmit Tool (HTRAN) – to disguise their geographical locations. Both utilize password-protected documents and large file sizes to disguise their attacks. These approaches, along with other similarities in TTPs we’ll review below, seem to indicate the groups are affiliated in some way and have at least some commonality in their attack campaigns.

A third, separate group also appears to be using the same TTPs, including the same custom backdoors and RATs; however, FireEye researchers do not have enough insight to reliably report a definitive connection to the Moafee and DragonOK groups.

Hidden from Sight

Both Moafee and DragonOK favor spear-phishing emails as an attack vector, often employing a decoy to deceive the victim. The emails are well crafted and audience specific, even written in the intended victim’s native language.

Attachments are typically sent as an executable file embedded in a ZIP archive or a password-protected Microsoft Office document. We also observed both groups using decoy documents that are presented to the victim while the malware runs in the background.

The groups both use common, and multiple, methods to hide their activities. Employing sandbox environments, antivirus software and gateway firewalls, they do their best to remain unobtrusive. Methods include:

• checking for the number of core processors (and quitting if only one is detected);
• attaching password-protected documents and providing a password in the email contents; and
• sending large files padded with unnecessary null bites to slide past network- and host-based AV engines that can’t scan larger files.

Tools of the Trade 

The two different operators seem to share backdoors and RATs – some of which are custom; others are publicly available. Overlapping tools include:

• CT/NewCT/NewCT2
• Mongall
• Nflog
• PoisonIvy

We observed Moafee running HTRAN proxies on their multiple Command and Control (C2) servers – all operated on CHINANET, and hosted in Guangdong Province.

Like the Moafee group, we observed DragonOK running HTRAN to proxy their C2 servers, which are also operated on CHINANET but are hosted in the Jiangsu Province.

Summary

Primarily focused on governments and military operations of countries with interests in the South China Sea, Moafee likely chooses its targets based on region’s rich natural resources. By targeting high-tech and manufacturing operations in Japan and Taiwan, DragonOK may be acquiring trade secrets for a competitive economic advantage.

While their targets and missions appear different, our researchers found enough linking evidence to demonstrate a relationship between Moafee and DragonOK, and perhaps even a third attack group. By sharing TTPs and coordinating joint attacks, these advanced threat actors are leveraging China’s supply chain economic expertise to perform extensive worldwide espionage.

While cybercriminals continue to target the payment card and banking information of individual users, they seem increasingly aware that compromising retailers is more lucrative. Targeting retailers is not new; Albert Gonzales infamously targeted retailers nearly a decade ago. What has changed, however, is the wide availability of tools and know-how that make it possible for even relatively unskilled cybercriminals to commit large-scale attacks. The results speak for themselves – significant breaches at retailers have increased over the last few years, and the trend continues. In fact, the Verizon Data Breach Investigations Report called 2014 the “year of the retailer breach” due to the number of large-scale attacks.

Not only are breaches at retailers occurring more regularly, FireEye researchers have noticed another startling new trend: while much of this activity is not initially targeted in nature, it can easily transition to a targeted attack when the attackers realize the value of the network they have compromised. The convergence of the wide availability of malware tools specifically built for point-of-sale (POS) systems and indiscriminate botnets, combined with targeted attack activity, suggest that network defenders struggle to determine the levels of threat severity and adversary sophistication. Simply put: What may initially seem like a “simple” crimeware infection may actually be a vector through which targeted actors can purchase or rent access to their victims.

POS Malware: A History Lesson

Since 2013 we have seen a dramatic increase in the number of malware threats specifically focused on POS systems. This uptick is like any other market dynamic — there’s a lot of data residing in retailers’ networks, and threat actors are adapting and evolving to take advantage of what’s at stake. Robust underground markets and an enterprise-like cyber criminal ecosystem enable threat actors to develop and trade their wares. What follows is a summary of some of the most major POS malware families and their similarities:

• Backoff POS – The Backoff attacks were publicly disclosed in July 2014 but the campaign itself was active in October 2013. The attackers reportedly brute forced remote desktop servers and installed the Backoff malware. Backoff is capable of extracting payment card data by scraping memory, and exfiltrating data over HTTP. Backoff’s Command-and-Control (C2) servers are connected to servers used to host Zeus, SpyEye and Citadel, suggesting Backoff may be connected to a broader series of attacks.

• BrutPOS – The BrutPOS malware was documented in July 2014. This botnet scans specified ranges of IP addresses for remote desktop servers and if a POS system is found, the attackers may deploy another variant that scans the memory of running processes to extract payment card information. BrutPOS exfiltrates data over FTP.

• Soraya – The Soraya POS malware was disclosed in June 2014. It iterates through running processes and accesses memory to extract payment card data. Soraya also has form-grabbing capabilities and exfiltrates data over HTTP.

• Nemanja – The details of the Nemanja were disclosed in May 2014 and the botnet is believed to have been active throughout 2013. The attackers compromised an array of POS machines worldwide running a variety of POS software. The attackers were reportedly directly engaged in the production of fake payment cards and money laundering using mobile POS solutions.

• JackPOS – The JackPOS malware was reported in February 2014 and was reportedly originally spread using “drive-by” download attacks. The malware, which appears to be somewhat related to the Alina malware, is capable of scraping memory to acquire payment card data and exfiltrate it over HTTP. JackPOS is now widely available on underground forums and is used by a variety of actors.

• Decebal – The Decebal POS malware was first reported in January 2014. The malware enumerates running processes and extracts payment card information, which is then exfiltrated over HTTP.

• ChewBacca – The ChewBacca malware was first disclosed in December 2013. This malware enumerates running processes and accesses memory to extract information using two regular expressions that match payment card data formats. This malware uses the Tor anonymity network for data exfiltration.

• BlackPOS – The BlackPOS malware, sold on underground forums by an individual believed to be “ree4,” was first reported March 2013 and is now widely available. This malware, which has a variant also known as KAPTOXA, scrapes memory to obtain payment card data. This data is typically transferred to a local staging point and then exfiltrated using FTP. The malware is best known for its reported role in several highly publicized breaches.

• Alina – The Alina POS malware, first disclosed in February 2013, is believed to have been developed by the same actor, known as “dice,” who developed the Dexter POS malware. This malware has been reportedly distributed via Citadel botnets. The Alina POS malware iterates through running processes (except those on a blacklist) and dumps the memory, looking for payment card data before exfiltrating it over HTTP. While this malware initially was used by a select few, it was subsequently sold on underground forums.

• vSkimmer – The vSkimmer malware was first disclosed in January 2013. It is available on a variety of underground forums and is used by multiple threat actors. The malware iterates through running processes and accesses memory to extract payment card information. The data is exfiltrated over HTTP.

• Dexter – The Dexter POS malware was first disclosed in December 2012 and is believed to have been developed by an actor known as “dice,” (who may also have been involved with the development of the Alina POS malware); the actual use of the tool has been connected to an individual known as “Rome0″. The malware iterates through running processes, accesses memory looking for payment card data, and exfiltrates it over HTTP.

Most of these malware families use a similar approach of enumerating running processes and using pattern matching to extract payment card information from running processes. However, in at least one case, a BlackPOS variant was configured to only access a specific process. This not only makes it less noisy, but indicates that the attackers knew what process to target on the compromised system. This development, along with some hardcoded network paths and usernames, may indicate specific targeting by the attackers.

Indiscriminate vs. Targeted Attacks

While some malware appears to have been used exclusively by particular threat actors, some variants are now widely available. In many cases, it appears that the POS-specific malware was used as a “second stage” attack, while the initial vector remains unclear. In the case of Alina and BackOff, for example, the POS malware was connected to Citadel, Zeus and SpyEye botnets. While the details remain unclear, the attackers may be selling or trading access to particular targets.

In other cases, the attackers appear to be much more specific with their targeting. One particular threat group will engage in periods of reconnaissance for months before engaging with the target. We also observed this group using SQL injection as an attack vector, deploying POS-specific malware after moving laterally through the compromised network.

Conclusion

These developments challenge the traditional conceptions of risk when it comes to network defense. While targeted attacks (including those associated with APT activity) can be tracked and clustered over time (by understanding the tools, techniques and procedures used by the threat actors, as well as their timing, scope and targeting preferences), it is difficult to prioritize incidents that began indiscriminately and transitioned into targeted attack activity. Is a simple, indiscriminate Zeus infection a noteworthy incident? Or will it pass largely unnoticed … only to transform into a significant breach?

Acknowledgements

We would like to thank Kyle Wilhoit, Jen Weedon and Chris Nutt.

The FireEye Labs team has identified two new zero-day vulnerabilities as part of limited, targeted attacks against some major corporations. Both zero-days exploit the Windows Kernel, with Microsoft assigning CVE-2014-4148 and CVE-2014-4113 to and addressing the vulnerabilities in their October 2014 Security Bulletin.

FireEye Labs have identified 16 total zero-day attacks in the last two years – uncovering 11 in 2013 and five in 2014 so far.

Microsoft commented: “On October 14, 2014, Microsoft released MS14-058 to fully address these vulnerabilities and help protect customers. We appreciate FireEye Labs using Coordinated Vulnerability Disclosure to assist us in working toward a fix in a collaborative manner that helps keep customers safe.”

In the case of CVE-2014-4148, the attackers exploited a vulnerability in the Microsoft Windows TrueType Font (TTF) processing subsystem, using a Microsoft Office document to embed and deliver a malicious TTF to an international organization. Since the embedded TTF is processed in kernel-mode, successful exploitation granted the attackers kernel-mode access. Though the TTF is delivered in a Microsoft Office document, the vulnerability does not reside within Microsoft Office.

CVE-2014-4148 impacted both 32-bit and 64-bit Windows operating systems shown in MS14-058, though the attacks only targeted 32-bit systems. The malware contained within the exploit has specific functions adapted to the following operating system platform categories:

• Windows 8.1/Windows Server 2012 R2
• Windows 8/Windows Server 2012
• Windows 7/Windows Server 2008 R2 (Service Pack 0 and 1)
• Windows XP Service Pack 3

CVE-2014-4113 rendered Microsoft Windows 7, Vista, XP, Windows 2000, Windows Server 2003/R2, and Windows Server 2008/R2 vulnerable to a local Elevation of Privilege (EoP) attack. This means that the vulnerability cannot be used on its own to compromise a customer’s security. An attacker would first need to gain access to a remote system running any of the above operating systems before they could execute code within the context of the Windows Kernel. Investigation by FireEye Labs has revealed evidence that attackers have likely used variations of these exploits for a while. Windows 8 and Windows Server 2012 and later do not have these same vulnerabilities.

Information on the companies affected, as well as threat actors, is not available at this time. We have no evidence of these exploits being used by the same actors. Instead, we have only observed each exploit being used separately, in unrelated attacks.

About CVE-2014-4148

Mitigation

Microsoft has released security update MS14-058 that addresses CVE-2014-4148.

Since TTF exploits target the underlying operating system, the vulnerability can be exploited through multiple attack vectors, including web pages. In the past, exploit kit authors have converted a similar exploit (CVE-2011-3402) for use in browser-based attacks. More information about this scenario is available under Microsoft’s response to CVE-2011-3402: MS11-087.

Details

This TTF exploit is packaged within a Microsoft Office file. Upon opening the file, the font will exploit a vulnerability in the Windows TTF subsystem located within the win32k.sys kernel-mode driver.

The attacker’s shellcode resides within the Font Program (fpgm) section of the TTF. The font program begins with a short sequence of instructions that quickly return. The remainder of the font program section is treated as unreachable code for the purposes of the font program and is ignored when initially parsing the font.

During exploitation, the attacker’s shellcode uses Asynchronous Procedure Calls (APC) to inject the second stage from kernel-mode into the user-mode process winlogon.exe (in XP) or lsass.exe (in other OSes). From the injected process, the attacker writes and executes a third stage (executable).

The third stage decodes an embedded DLL to, and runs it from, memory. This DLL is a full-featured remote access tool that connects back to the attacker.

Plenty of evidence supports the attacker’s high level of sophistication. Beyond the fact that the attack is zero-day kernel-level exploit, the attack also showed the following:

• a usable hard-coded area of kernel memory is used like a mutex to avoid running the shellcode multiple times
• the exploit has an expiration date: if the current time is after October 31, 2014, the exploit shellcode will exit silently
• the shellcode has implementation customizations for four different types of OS platforms/service pack levels, suggesting that testing for multiple OS platforms was conducted
• the dropped malware individually decodes each string when that string is used to prevent analysis
• the dropped malware is specifically customized for the targeted environment
• the dropped remote access capability is full-featured and customized: it does not rely on generally available implementations (like Poison Ivy)
• the dropped remote access capability is a loader that decrypts the actual DLL remote access capability into memory and never writes the decrypted remote access capability to disk

About CVE-2014-4113

Mitigation

Microsoft has released security update MS14-058 that addresses this vulnerability.

Vulnerability and Exploit Details

The 32-bit exploit triggers an out-of-bounds memory access that dereferences offsets from a high memory address, and inadvertently wraps into the null page. In user-mode, memory dereferences within the null page are generally assumed to be non-exploitable. Since the null page is usually not mapped – the exception being 16-bit legacy applications emulated by ntvdm.exe–null pointer dereferences will simply crash the running process. In contrast, memory dereferences within the null page in the kernel are commonly exploited because the attacker can first map the null page from user-mode, as is the case with this exploits. The steps taken for successful 32-bit exploitation are:

1. Map the null page:
   1. ntdll!ZwAllocateVirtualMemory(…,BaseAddress=0×1, …)
2. Build a malformed win32k!tagWND structure at the null page such that it is properly validated in the kernel
3. Trigger vulnerability
4. Attacker’s callback in win32k!tagWND.lpfnWndProc executes in kernel-mode
   1. Callback overwrites EPROCESS.Token to elevate privileges
5. Spawns a child process that inherits the elevated access token

32-bit Windows 8 and later users are not affected by this exploit. The Windows 8 Null Page protection prohibits user-mode processes from mapping the null page and causes the exploits to fail.

In the 64-bit version of the exploit, dereferencing offsets from a high 32-bit memory address do not wrap, as it is well within the addressable memory range for a 64-bit user-mode process. As such, the Null Page protection implemented in Windows versions 7 (after MS13-031) and later does not apply. The steps taken by the 64-bit exploit variants are:

1. Map memory page:
   1. ntdll!ZwAllocateVirtualMemory(…)
2. Build a malformed win32k!tagWND structure at the mapped page such that it is properly validated in the kernel
3. Trigger vulnerability
4. Attacker’s callback in win32k!tagWND.lpfnWndProc executes in kernel-mode
   1. Callback overwrites EPROCESS.Token to elevate privileges
5. Spawns a child process that inherits the elevated access token

64-bit Windows 8 and later users are not affected by this exploit. Supervisor Mode Execution Prevention (SMEP) blocks the attacker’s user-mode callback from executing within kernel-mode and causes the exploits to fail.

Exploits Tool History

The exploits are implemented as a command line tool that accepts a single command line argument – a shell command to execute with SYSTEM privileges. This tool appears to be an updated version of an earlier tool. The earlier tool exploited CVE-2011-1249, and displays the following usage message to stdout when run:

Usage:system_exp.exe cmd

Windows Kernel Local Privilege Exploits

The vast majority of samples of the earlier tool have compile dates in December 2009.  Only two samples were discovered with compile dates in March 2011. Although the two samples exploit the same CVE, they carry a slightly modified usage message of:

Usage:local.exe cmd

Windows local Exploits

The most recent version of the tool, which implements CVE-2014-4113, eliminates all usage messages.

The tool appears to have gone through at least three iterations over time. The initial tool and exploits is believed to have had limited availability, and may have been employed by a handful of distinct attack groups. As the exploited vulnerability was remediated, someone with access to the tool modified it to use a newer exploit when one became available. These two newer versions likely did not achieve the widespread distribution that the original tool/exploits did and may have been retained privately, not necessarily even by the same actors.

We would like to thank Barry Vengerik, Joshua Homan, Steve Davis, Ned Moran, Corbin Souffrant, Xiaobo Chen for their assistance on this research.