Farming Malicious Documents to Unravel Ransomware

Posted on by Jeff White

While analyzing a recent malicious Microsoft Word document, it downloaded a ransomware variant, “SAGE 2.0” (Sage Locker), which is a spin-off from CryLock. This ransomware has been slowly making the rounds lately; most notably because a number of these campaigns have been seen delivering both Sage and Cerber ransomware families from the same download locations, sometimes changing between the two periodically throughout the day.

In this blog post, I plan to analyze the distribution infrastructure for the ransomware and enumerate indicators that can be deployed for detection and prevention; however, before I get into the infrastructure, I need to briefly mention how the distribution occurs.

I stumbled across this, not because of the ransomware itself, but due to how the Microsoft Word documents download the ransomware executable. Specifically, these Microsoft Word documents are delivered via e-mail, as usually happens with these types of ransomware campaigns, and launch a PowerShell process to download the actual ransomware using an evasion technique I’ve been monitoring. The idea behind the evasion technique is to bypass pattern or string matches that prevent process launching by using the Windows command-line escape caret character injected between your regular characters to break up commands such as “powershell” and “executionpolicy” – below is an example of this.

If, for example, you tried to block “powershell”, it would fail because the carets have broken up the word, but it will have no impact on Microsoft Window’s actual processing of it. The Microsoft Word document contains an obfuscated macro that puts together this command and executes it, which subsequently downloads the ransomware file and runs it. Nothing mind bending but, despite its attempt to evade detection and prevention, it actually stands out more and has the reverse effect.

Pivoting off of this path in the URL “read.php?f=0.dat”, I was able to use Palo Alto Networks AutoFocus to quickly identify 9,107 unique Microsoft Word document since December 15th, 2016 that matched this pattern in their dynamic process activity. From there, I was able to extract all of the download locations being used by this campaign from the identified samples.

To determine if there were any underlying correlations at the registrant level, I pulled WHOIS data for all of the identified domains and, sure enough, another pattern begins to emerge.

unraveling_1

Figure 1 Connections between delivery domains.

What you see in Figure 1 are five clusters of domains: the light green represent the Name of the person who registered the domain and the dark gray represents the persons e-mail. For each “person” there are multiple domains that are tied to that identity.

With this information in hand, I used the e-mails to continue pivoting and pulled every domain these identities have registered. To my surprise, there were 574 total domains, with each one having between 125-160 except for the “dns at unit.org[.]hk” address, which has just nine.

Now, with just a quick review of some of these domains you can get a feel for the general malicious nature of them through the abundant amount of domains masquerading as other companies, whether for phishing or evasion purposes.

Using this new list of domains, I was able to go back through AutoFocus and further enumerate another 12,422 samples, all showing similar activity to the previous documents.

Below are examples of each variation of their download command and unique URL path.

“search.php”

“read.php?f=1.dat”

“read.php?f=404”

“admin.php?f=0.dat”

“admin.php?f=1.jpg”

This next one is particularly interesting as it was serving Locky instead of Sage or Cerber. The first instance of this was on December 9, six days before the Sage and Cerber campaigns described in this post began.

Another thing to note is that it uses a different PowerShell command but the actor(s) behind it still used the “read.php?f=X.dat” format during the download.

“read.php?f=3.dat”

Last, but not least, there was samples starting on August 6, 2016 which used yet another iteration to download the ransomware. This one uses BITS to transfer the file as opposed to PowerShell and drops the file with a screensaver “scr” extension instead of the previously seen executable “exe” in newer iterations.

“admin.php?f=1.exe”

After going over the files and scraped data from dynamic analysis reports, it’s clear the actor(s) behind this campaign have a pattern they like to follow. Regardless of ransomware variant, these small trails can allow us to unravel a larger infrastructure and generate more actionable data for current and, possibly, future threats.

Palo Alto Networks customers are defended by this threat in the following ways:

  • The domains used to delivery this malware and used in related attacks are blocked through Threat Prevention
  • WildFire identifies files using these techniques as malicious
  • AutoFocus users can identify related activity using the PowerShellCaretObfuscation and CerberSage_Distribution

Below is a summary of indicators that can be used for detection and prevention.

Enumerated Paths:

Direct ransomware download URLs:

Enumerated Domains:

Updated March 15, 2023, at 9:30 a.m. PT. to update CryLocker to CryLock.

Exploring the Cybercrime Underground: Part 3 – Into the RAT Nest

Posted on by simon-conant

In this third part of Unit 42’s Cybercrime Underground blog series, we’re taking a slightly different approach. In this blog we begin with data from a real attack in the wild, and use the evidence from that attack to make a connection back to underground forums and the actors who are using them.

Rather than starting from an attack we had already explored, we looked into a third-party research report linking an Adwind malware sample to a specific command and control (C2) domain and loosely associating a number of other domains.

Using Autofocus, we found an additional dozen samples on the same C2 – almost all of which were instead the LuminosityLink Remote Access Tool (RAT) – itself the subject of a recent Unit 42 report. RATs, Remote Access Tools, are sometimes defended as legitimate utilities but in fact are most typically used for illegitimate, unauthorized access, to control malware-infected systems. From there we dived into associated infrastructure, and underground forums, to see what connections we might find.

Linking Command and Control Infrastructure

We identified five further C2 domains contextually linked with the same naming scheme as the noted Adwind sample, but using different Dynamic DNS root domains. These led us further to additional IP addresses, themselves associated with other known malware C2s. Of immediate interest, not only were these C2s linked, but almost every C2 observed currently resolving to those IP addresses all appeared to be using similar dynamic DNS services.

Figure 1 shows the cluster of Dynamic DNS C2s (right) resolving to the IP addresses associated with the initial C2 investigation (left). We found several thousand files in Autofocus that connected to this infrastructure – every one of them malware.

ratnest_1

Figure 1 Dynamic DNS domains and IP clusters

The linked C2 domains include a handful of first-party and apparently-compromised domains, but are predominantly dynamic DNS. These dynamic DNS providers include abused, legitimate commercial services (e.g. NoIP, DynDNS), and what appears to be purposely-misleading and/or underground services (such as alcatelupd[.]xyz, appleupdate[.]xyz, fagdns[.]net) (Figure 2).

The malware we observed on this infrastructure was almost uniquely commodity RATs including DarkComet, DarkTrack, LuminosityLink, NJRAT, ImminentMonitor, NanoCore, Orcus, NetWireRAT, BabylonRAT, Remcos, ZyklonHTTP, SandroRAT, RevengeRAT, SpyNote, QuasarRAT, and HWorm.

ratnest_2

Figure 2 Dynamic DNS including legitimate providers and deliberately misleading base domains

Abusing legitimate dynamic DNS providers gives the actors a quick, easy, and reliable service – but with the risk of rapid takedown of their infrastructure if abuse is detected by or reported to the dynamic DNS provider. This has created a marketplace for shady home-grown dynamic DNS services which advertise on underground forums that they ignore such abuse. Figure 3 is an example of an underground forum member recommending such a service, over that of a legitimate commercial one.

picture3

Figure 3 Recommending an Underground service over a legitimate commercial one.

We observed clusters of such hosts contextually-linked across multiple domains, for example:

This not only groups activity, but suggests multiple actors are using this infrastructure. Several of those hosts were observed sharing multiple IP addresses already identified in this cluster, further linking the activity. Additionally, this expands on prior Unit 42 research into the LuminosityLink RAT, corroborating those C2s and contributing to further context on them.

Marketplace

The next question is, who is operating these dynamic DNS services, and where are they selling them. Using open source data and information from underground forums, we are able to connect some of these dots.

A Swede in his 30s, Gustaf, runs “ra4wvpn”, which offers domains, hosting, and a VPN service.

John, “Armada”, a Canadian also in his 30s and one of the persons behind the Orcus RAT (subject of another recent Unit 42 report) owns several of the C2 root domains and offers a paid DNS service advertised on underground forums.

“LaPanthere” runs fagdns. He insists that his service does not tolerate abuse (despite the context of where the service is advertised). His ISP suspended fagdns[.]com for abuse, he returned with fagdns[.]su registered elsewhere – but his reputation took a hit as he now appears somewhat gun shy:

collage_1And other underground providers face a similar fate – Punkbastard’s free service was discontinued when his domain was suspended by his provider, for abuse:

ratnest_9

Although LaPanthere advertises his service on an underground cybercrime forum, he protests that his service is legitimate – and suggests that those interested in illegal activities might want to consider the paid service of the Canadian, Armada, with a helpful flow chart:

ratnest_10

The domains of just two of these dynamic DNS providers alone are contacted by almost 3000 unique malware samples identified in our Autofocus service. As well as providers advertising their services on the underground forums, other forum members author advice and step-by-step tutorials, assisting technically unsophisticated miscreants in setting up their RAT systems. More details on this topic were covered in part two of this series. The below figures corroborate how threat actors collaborate in such forums by sharing attack methodologies and also buying and selling such services.

ratnest_11

ratnest_12

ratnest_13

ratnest_14

ratnest_15

 

screen-shot-2017-01-26-at-11-12-07-am-2-copy

Several forum actors offer complete setup services, at fairly low prices:

ratnest_18

Attribution

We observed malware using the same C2 that originated this investigation being spread in email attacks. These appeared to be high-volume and indiscriminate, including both corporate targets and free-email-service addresses. Each email was sent to 16 recipients; the recipient list throughout the campaigns incrementing alphabetically, suggesting strongly they are simply parsing a huge email address database.

We observed these emails sent from an email address at a legitimate Nigerian commercial organization – confirmed by its Nigerian IP address to be the actual originating domain, and not spoofed. The attacks leveraged content and filenames referencing that organization. This is most likely explained by either a compromised account or system, or possibly an insider. In other words, this is likely an example of true Business Email Compromise (BEC) as opposed to the less sophisticated, trickery-only Business Email Spoofing (BES).

We noted a domain using the same naming pattern as the C2 in the original report registered for a few days in 2015, before being suspended for abuse. The WHOIS was apparently false, but with some interesting links:

Registrant Name: Roger Lougheed
Registrant Street: 200 Florida Ave Tavernier, FL 33070
Registrant City: Tavernier
Registrant State/Province: Florida
Registrant Postal Code: 33070
Registrant Country: Nigeria
Registrant Phone: +1.3128699324
Registrant Email: jmcoru@yahoo.com

As well as another Nigerian reference, the registrant email address resolves to the Skype account “mikescotoru1”. This handle is found at a handful of coding/malware forums. Dropping the “1”, “mikescotoru” is found at other underground forums, including some very contextual links:

ratnest_19

Further posts suggest a rather unsophisticated user, asking very basic questions, and purchasing the pieces for his campaigns. The handle “jmcoru” is less unique, but also found on various underground hacking and website hosting forums.

Conclusion

Starting from a third party’s research report, we were able to use Autofocus and open-source intelligence to connect a real world attack to a series of actors operating malicious Dynamic DNS services and offering training and tools to help unskilled actors launch these attacks.

The original report suggested that this was “a wave of persistent attacks against a number of commercial and non-commercial organizations”, characterized the observed activity as “refined APT campaigns”, and went on to conclude that that this was part of “small-scale, targeted attacks with small infrastructure”.

Through our research, we instead understand that this specific malware was spread by an unskilled, opportunistic, financially-motivated Nigerian criminal. When we inspected email-borne attacks for samples on the original C2, the recipients more closely resembled indiscriminate, wide-scale targets.

The infrastructure further led us away from attribution of this as APT activity, instead revealing low-sophistication “service providers” on underground forums, sharing of best practices and tutorials among script kiddies, and end-to-end full-service operations providing entire RAT system setups for even the least capable aspiring cyber criminal.

Thanks to Brandon Levene and Jeff White for assistance in reviewing unknown malware seen on this infrastructure.

IOCs

As well as specific C2 host names / IPs, we also identified multiple malicious DNS providers / domains with multiple C2s.

Palo Alto Networks customers are protected from this threat in the following ways:

  1. WildFire accurately identifies all malware samples using this infrastructure as malicious.
  2. C2s and malicious Dynamic DNS provider domains identified in this investigation are flagged as malicious by Threat Prevention.
  3. AutoFocus users can view malware using known malicious Dynamic DNS providers using the “AbusedDynamicDNSProvider” tag.

You can download a copy of associated IoCs here.

Threat Brief: Second Wave of Shamoon 2 Attacks Reveal Possible New Tactic

Posted on by Unit 42

Palo Alto Networks Unit 42 threat intelligence team has just released new research that has uncovered a previously unknown second wave of Shamoon 2 attacks: Second Wave of Shamoon 2 Attacks Identified

Based on our analysis, these attacks were timed to occur on November 29, 2016, twelve days after the initial Shamoon 2 attacks that we wrote about previously.

Like the initial Shamoon 2 attacks, this second wave of Shamoon 2 attacks utilize the Disttrack wiper malware. Disttrack is optimized to destroy systems by targeting their hard drives and to spread as widely as possible throughout a network it’s infiltrated. And once again, the Disttrack malware was configured to operate without any command and control (C2) servers, essentially optimized for a one-way mission of data destruction.

But this second wave of Shamoon 2 attacks show evidence of potential new tactic. Unit 42 analysis shows that the latest sample contains credentials for virtual desktop infrastructure (VDI) solutions, such as Huawei’s FusionCloud. VDI solutions can provide protection against a destructive malware like Disttrack through the ability to load snapshots of wiped systems to recover from a wiper attack. The presence of these credentials in the sample may suggest that attackers intended to increase the impact of their attack by not only wiping systems but also carrying out destructive activities against the VDI deployment, as well as any snapshots.

In essence, a manual destructive attack against the VDI deployment and snapshots coupled with the destructive attack by the malware could destroy an organizations’ systems and primary line of backup against such an attack.

The possible targeting of VDI solutions with legitimate credentials (either stolen or default) represents an escalation in tactics not only in this specific attack but other future attacks. Security teams and administrators should be aware of and take immediate steps to evaluate this development and consider adding additional safeguards to protect credentials related to their VDI deployment.

Full technical details including associated indicators of compromise (IOCs) that can be used for more detailed analysis and protection, can be found the full report.

Palo Alto Networks customers are protected from the Disttrack payload used in this attack:

  • WildFire properly classifies Disttrack samples as malicious
  • Threat protection AV signature of Virus/Win32.WGeneric.ktoto detects the new payload.

AutoFocus customers can monitor Disttrack activity using the Disttrack tag

Campaign Evolution: EITest from October through December 2016

Posted on by Brad Duncan

EITest is a name originally coined by Malwarebytes Labs in 2014 to describe a campaign that uses exploit kits (EKs) to deliver malware. Until early January 2016, "EITest" was used as a variable name in the attacker’s malicious injected script in pages on legitimate websites compromised by this campaign. While the variable name is gone, the name for the campaign remains: we still call this campaign "EITest" and it continues to use EKs to distribute a variety of malware.

We reviewed EITest in March 2016 and October 2016. However, the EITest campaign looks noticeably different than when we last reviewed it three months ago.

The EITest campaign is focused on the Delivery, Exploitation, and Installation phases of the cyber attack lifecycle. The way the attacker executes each of these phases changes over time, and this blog examines the changes during the last quarter of 2016. Two significant changes have occurred during this time.

  • Since our last report, EITest no longer uses a gate between the compromised website and the EK landing page (possibly in response to that report).
  • Script injected by the campaign into pages on legitimate websites no longer contains any obfuscation.

Perhaps the most interesting thing about EITest is its longevity.  People have been tracking this campaign since 2014, and its longevity suggests that despite the shifting EK landscape, EKs remain a profitable venture for the criminals involved.

Chain of Events

Successful infections by the EITest campaign generally follow a set sequence of events. It currently uses at least two variations of Rig EK to deliver a variety of ransomware. The infection sequence is similar to other campaigns utilizing EKs to distribute malware. To understand how campaigns use EKs, see our previous blog on EK fundamentals. For EITest, we see the following steps:

  • Step 1: Victim host views a compromised website with malicious injected script.
  • Step 2: The injected script generates an HTTP request for an EK landing page.
  • Step 3: The EK landing page determines if the computer has any vulnerable browser-based applications.
  • Step 4: The EK sends an exploit for any vulnerable applications (for example, out-of-date versions of Internet Explorer or Flash player).
  • Step 5: If the exploit is successful, the EK sends a payload and executes it as a background process.
  • Step 6: The victim's host is infected by the malware payload.

For most of its history, EITest has used a gate between the compromised website and the EK landing page. However, the EITest campaign has stopped using a gate after we published our previous blog about it on October 3, 2016.  Since then, injected script from this campaign links directly to an EK landing page. Gates are no longer used by EITest.

eitest_1

Figure 1: Chain of events for the EITest campaign as of October 3, 2016.

EITest and Rig EK

The EITest campaign still uses Rig EK to deliver its malware. Our research shows EITest most often uses a variant of Rig EK called Empire Pack. Many in the community refer to Empire Pack as "Rig-E" to distinguish it from other variants and still emphasize its relationship to the original Rig EK.  Empire Pack uses the same URL patterns we've seen from Rig EK since late March 2015, while other variants of Rig EK like Rig-V (an improved "VIP" version or Rig) and Rig standard moved on to different URL patterns.

Of note, the variant of Rig EK that EITest uses depends on the payload it delivers. Most EITest payloads are sent using Rig-E.  However, EITest has used Rig-V to distribute ransomware like Cerber or CryptoMix (also known as CryptFile2).

Payloads sent by EITest

Since October 2016, the EITest campaign continues using Rig EK to distribute a variety of malware.

We occasionally see ransomware like Cerber or CryptoMix from the EITest campaign. More often, the campaign will distribute information stealers like Gootkit or the Chthonic banking Trojan. EITest has also delivered other types of malware like Ursnif variants and Latentbot.

Patterns of injected script

When we last examined injected script by the EITest campaign, it still used obfuscation to disguise the EK landing page URL.  By October 15th 2016, EITest stopped obfuscating URL within the injected script.  Figure 3 shows the injected script shortly before the change.  Figure 4 shows the injected script shortly after wit an unobfuscated landing page URL.

eitest_2

Figure 3: Injected EITest script in page from a compromised website on October 13th, 2016.

eitest_3

Figure 4: Injected EITest script in page from a compromised website on October 17th, 2016.

Throughout the rest of 2016, injected script from EITest hasn't changed that much, as seen in Figure 5.

eitest_4

Figure 5: Injected EITest script in page from a compromised website on December 30th, 2016.

Conclusion

EKs are still a popular method to distribute malware. Campaigns like EITest continue to use EKs to deliver a variety of malware, including information stealers and ransomware. These campaigns do not have a specific target and anyone with a Windows system that’s out of date or has out of date applications is vulnerable to infection.

As the EK model of distribution remains profitable, we expect to see malware delivered by EKs through campaigns such as EITest. Domains, IP addresses, and other indicators associated with this campaign are constantly changing. Fortunately, EKs are relatively ineffective against people using a fully-patched Windows operating system who ensure their applications are all up-to-date. Furthermore, customers of Palo Alto Networks are protected from the EITest campaign through our next-generation security platform.

 

Second Wave of Shamoon 2 Attacks Identified

Posted on by Robert Falcone

In November 2016, we observed the reemergence of destructive attacks associated with the 2012 Shamoon attack campaign. We covered this attack in detail in our blog titled Shamoon 2: Return of the Disttrack Wiper, which targeted a single organization in Saudi Arabia and was set to wipe systems on November 17, 2016. Since our previous publication, we have found  another, similar but different payload used to target a second organization in Saudi Arabia that was configured to wipe systems twelve days later on November 29, 2016. This latest attack potentially materially impacts one of the primary countermeasures employed against wiper attacks: Virtual Desktop Interface snapshots.

The payload used in this attack was very similar to the November 17, 2016 payload, but exhibited slightly different behaviors and contained hardcoded account credentials specific to the newly targeted organization. The hardcoded account credentials met Windows password complexity requirements, which suggests that the threat actors obtained the credentials through a previous, separate attack, similar to the November 17, 2016 attack.

The most notable thing about this latest sample is that it contains several usernames and passwords from official Huawei documentation related to their virtual desktop infrastructure (VDI) solutions, such as FusionCloud. VDI solutions can provide some protection against a destructive malware like Disttrack through the ability to load snapshots of wiped systems. The fact that the Shamoon attackers had these usernames and passwords may suggest that they intended on gaining access to these technologies at the targeted organization to increase the impact of their destructive attack. If true, this is a major development and organizations should consider adding additional safeguards in protecting the credentials related to their VDI deployment.

At this time, we have no details of the attack we believe preceded this Shamoon attack to obtain credentials. We also have no details on the delivery method used to deliver the new, similar, but different Disttrack payload in this attack.

The Second Shamoon 2 Attack

This second known attack associated with Shamoon 2 also used the Disttrack payload, albeit a new, similar but different one from the original Shamoon 2 attack. Specifically, it used a 64-bit variant that was configured to begin its destructive activities on November 29, 2016. Like the Disttrack sample used in the first reported Shamoon 2 attack, it including a wiper and communications module stored in resources within the executable.

Table 1 below shows that the method the Disttrack payload uses to extract and decrypt the modules from resources is the same; however, the resource names changed from “X509”, “PKCS7” and “PKCS12” to “LANG”, “MENU” and “ICO”.

Component Resource Name Offset Size Base64 key
Wiper LANG 94399-14 = 94385 563712 OWRKbTxrleYfLm…
Communications MENU 218709-14 = 218695 187904 QsCfQA6ze9CoOz…
Unknown ICO Unknown Unknown ijX7buB1FIjSn/0D…

 

Our efforts to decrypt the “ICO” resource have thus far been unsuccessful as the Disttrack payload has an associated key but does not contain code that decrypts and extracts this resource.

Propagation Inside Compromised Networks

Similar to the previous attack, the Disttrack payload in this attack spreads to other systems on the local network (/24 network specifically) by logging in using legitimate domain account credentials, copying itself to the system and creating a scheduled task that executes the copied payload. While this method is the same as discussed in our previous blog, the account credentials used in this attack were specific to the targeted organization and the file names used when copying the payload to remote systems were different.

Legitimate User Accounts

There were 16 account credentials found hardcoded within the Disttrack payload, appearing to be a mixture of individual user accounts and broader administrator accounts. All but one of the passwords met Windows complexity requirements, specifically, containing uppercase and lowercase characters, and either a number, symbol, or both. One of the general administrator accounts seen in this payload was also in the Disttrack payload in the first Shamoon 2 attack from November 17, 2016, which may not be specific to the targeted organization and instead used as an attempt to guess the login credentials. Based upon the existence of these credentials, it is highly likely the threat actors had carried out a previous attack to obtain these account credentials, as it is unlikely that these passwords were guessed or brute forced.

As noted earlier, a new development with this latest Disttrack payload is that several of the usernames and passwords are found within official documentation as administrator accounts for Huawei’s virtualized desktop infrastructure (VDI) products, such as FusionCloud. This may suggest that the targeted organization used these credentials when deploying Huawei VDI systems. Shamoon actors may have obtained these credentials from a prior attack; however, it is also possible that the actors included these default usernames and passwords as an attempt to guess the login credentials to the VDI infrastructure.

VDI solutions can provide some protection against a destructive malware like Disttrack through the ability to load snapshots of wiped systems. Also, since FusionCloud systems run a Linux operating system, which would not be susceptible to wiping by the Windows-only Disttrack malware, this could be seen as a reasonable countermeasure against attacks like Shamoon. However, if the attacker was able to log into the VDI management interfaces using the account credentials they could manually carry out destructive activities against the VDI deployment, as well as any snapshots. The targeting of VDI solutions with legitimate, stolen or default credential represents an escalation in tactics that administrators should be aware of and take immediate steps to evaluate and address.

New Disttrack Names

The filenames that the payload copies itself to within the System32 folder of the remote system differs from the previously reported attack, specifically using “ntertmgr32.exe” for 32-bit or “ntertmgr64.exe” for 64-bit systems. The scheduled task executes these files on the remote system, which results in the creation of a Disttrack service named “NtertSrv” compared to the service name “ntssrv” created by the Disttrack payload used in the November 17, 2016 attacks. This can be seen in Figure 1.

shamoon_1

Figure 1 Disttrack service created on systems during propagation

Command and Control

The communications module used in this attack is rather hobbled, as it was configured without an operational command and control (C2) server to communicate with. The lack of an operational C2 is much like the November 17, 2016 attack that had the IP address “1.1.1.1” within its configuration to use as a C2 server. Unlike the non-operational C2 of “1.1.1.1” used in the first Shamoon 2 attack, this communications module completely lacked any IP address or domain name for a C2 server within its configuration.

Also, in this sample, Disttrack did not save its communications module to the system using the filename “netinit.exe” like in the original attack, rather it chose a random name from the following list:

• caiaw00e.exe
• sbuvideo.exe
• caiaw00i.exe
• olvume.exe
• usinwb2.exe
• briaw005.exe
• fpwwlwf.exe
• epiaw003.exe
• briaw002.exe
• olvsnap.exe
• dmwaudio.exe
• briaw006.exe
• miWApRpl.exe
• caiaw00b.exe
• lxiaw003.exe

Lastly, the communications module also uses different file names than the original Shamoon 2 attack. Instead of setting a custom “kill time” in a file named “usbvideo324.pnf” within the “%WINDOWS%\inf” folder, it uses a file name of “dcT21x400i.pnf”. It also would send the C2 server the contents of a file named “vsfnp7_6.pnf” from the folder “%WINDOWS%\inf” instead of “netimm173.pnf”.

Destruction

Much like the initial attacks, the lack of an operational C2 server suggests that the threat actor’s sole intention for carrying out this Shamoon 2 attack was to destroy data and systems. Without an operational C2, the actor would be unable to issue a command to set a custom “kill time” when the Disttrack payload would begin wiping systems, which would force the payload to rely on its hardcoded “kill time”. The hardcoded date suggests that this attack was set to begin wiping systems on November 29, 2016 at 1:30 AM local Saudi Arabia time.

Unlike the previous Shamoon attacks that occurred on a holiday and over a weekend, this kill time occurred during the work week, as November 29, 2016 was a Tuesday. However, it appears this attack attempted to maximize its impact by occurring very early in the morning before the majority of the organization’s staff were on site. This aligns with the Shamoon actors conducting their attacks off-hours to increase the efficacy of the attack by increasing the timeframe of detection and response.

When Disttrack observes the system clock exceeding the “kill time”, it will save its wiper component to the system using one of the following randomly chosen filenames:

• pdwmtphw.exe
• caiaw00a.exe
• sdwprint.exe
• caiaw00d.exe
• kyiaw002.exe
• sdwscdrv.exe
• briaw00a.exe
• saiaw002.exe
• _mvscdsc.exe
• hdvmp32.exe
• _s3wcap32.exe
• hpiaw001.exe
• lxiaw004.exe
• cniaw001.exe
• lxiaw006.exe
• caiaw00f.exe
• newtvsc.exe

When executed, the wiper component will extract a kernel driver from its resource section and decrypt it with a 172-byte XOR key. The wiper saves the kernel driver (SHA256: 5a826b4fa10891cf63aae832fc645ce680a483b915c608ca26cedbb173b1b80a) to the “Windows\System32\Drivers” folder in a file named “vdsk911.sys”. The wiper then uses this file to create a kernel driver service named “vdsk911”, as seen in Figure 2.

shamoon_2

Figure 2 RawDisk kernel driver service created by Disttrack wiper

The kernel driver is the 64-bit version of the commercial RawDisk driver by EldoS Corporation, which is the exact same file as the “drdisk.sys” driver extracted from the Disttrack 64-bit payload in the ‘X509’ resource in the first reported Shamoon 2 attack. The Disttrack payload will use this kernel driver to access the master boot record (MBR), partition tables and files and folders on the system to overwrite them with the same image of the deceased Syrian boy as in the previous Shamoon 2 attack.

During our analysis, we again observed the wiper setting the system time to a random date between August 1 and August 20, 2012, as seen in Figure 3. As mentioned in our previous blog, the reason the wiper sets the system time to this random date in August 2012 is due to a temporary license key needed to use the RawDisk kernel driver. The temporary license key used in this attack is the exact same as the first attack.

shamoon_3

Figure 3 Wiper changing the system date to a random date in August 2012

Since our original blog, we’ve successfully decrypted the license key, which can be seen in Figure 4. The expiration date in the temporary license key is an 8-byte field (highlighted by the orange box) that corresponds to Microsoft’s FILETIME structure, which represents the number of 100-nanosecond intervals since January 1, 1601 (UTC). In the temporary license key used in all of the Shamoon related attacks, the expiration date was set to August 30, 2012 at 8:34:29 UTC, which is the reason the wiper sets the system time to a random day between August 1 and August 20, 2012. Also, we found that the temporary license key was registered to “binnatova@bsunanotechnology.com”. We are unsure how this email address is involved with Shamoon, as it was likely compromised back in 2012 and used by the actor to obtain the temporary license for RawDisk.

shamoon_4

Figure 4 RawDisk temporary license decrypted showing August 2012 expiration date

After the MBR, partition tables and files are overwritten, the wiper issues the command of “shutdown -r -f -t 2” to reboot the system, which is the same command as used in the first Shamoon 2 attack. Figure 5 shows the dialog box that pops up as a result of this command, which will be followed by a system reboot.

shamoon_5

Figure 5 The shutdown dialog box opened just before reboot of a Windows 7 system wiped by Disttrack

The purpose of rebooting the system remains the same, as the portions of the hard disk and filesystem needed to successfully boot the system were overwritten with a JPEG image, the system is no longer able to start up. Figure 6 shows the result of this reboot in an analysis virtual machine, as the operating system could no longer be found.

shamoon_6

Figure 6 System unable to find its operating system

The operating system fails to load as the MBR is overwritten with a JPEG image. As seen in Figure 7, sector 0 of the physical hard disk, which normally stores the master boot record now contains the beginning of a JPEG file marked by the “JFIF” magic bytes in the two orange boxes.

shamoon_7

Figure 7 Hexdump of sector 0 of the physical showing the MBR overwritten with a JPEG file

Conclusion

We analyzed a second Disttrack payload associated with Shamoon 2, which suggests that the threat actors targeted a second Saudi Arabian organization in this attack campaign. The actors used the Disttrack payload to spread to other systems on the local network using legitimate credentials. The legitimate credentials were specific to the targeted organization and were complex enough to suggest that the threat actors carried out a previous attack to obtain the credentials. Also, the actors hardcoded credentials found in Huawei’s official documentation for its VDI solutions, suggesting that the threat actors may have had access to appliances hosting the infrastructure. The Disttrack wiper was set to begin overwriting systems on November 29, 2016 at 1:30 AM, which aligns with the Shamoon actor’s tactic to maximize its impact by attacking at a time when the targeted organization would have less staff and resources available onsite.

Palo Alto Networks customers are protected from the Disttrack payload used in this attack:

  • WildFire properly classifies Disttrack samples as malicious
  • Threat protection AV signature of Virus/Win32.WGeneric.ktoto detects the new payload.
  • AutoFocus customers can monitor Disttrack activity using the Disttrack tag

Indicators of Compromise

Hashes

010d4517c81bcdc438cb36fdf612274498d08db19bba174462ecbede7d9ce6bb (64-bit Disttrack)
efd2f4c3fe4e9f2c9ac680a9c670cca378cef6b8776f2362ed278317bfb1fca8 (Communication)
113525c6bea55fa2a2c6cf406184092d743f9d099535923a12cdd9b9192009c4 (Wiper)
5a826b4fa10891cf63aae832fc645ce680a483b915c608ca26cedbb173b1b80a (vdsk911.sys)

Filenames

ntertmgr32.exe
ntertmgr64.exe
vdsk911.sys
dcT21x400i.pnf
vsfnp7_6.pnf
caiaw00e.exe
sbuvideo.exe
caiaw00i.exe
olvume.exe
usinwb2.exe
briaw005.exe
fpwwlwf.exe
epiaw003.exe
briaw002.exe
olvsnap.exe
dmwaudio.exe
briaw006.exe
miWApRpl.exe
caiaw00b.exe
lxiaw003.exe
pdwmtphw.exe
caiaw00a.exe
sdwprint.exe
caiaw00d.exe
kyiaw002.exe
sdwscdrv.exe
briaw00a.exe
saiaw002.exe
_mvscdsc.exe
hdvmp32.exe
_s3wcap32.exe
hpiaw001.exe
lxiaw004.exe
cniaw001.exe
lxiaw006.exe
caiaw00f.exe
newtvsc.exe

Service Names

NtertSrv
vdsk911

2016 Updates to Shifu Banking Trojan

Posted on by Dominik Reichel

Overview

Shifu is a Banking Trojan first discovered in 2015. Shifu is based on the Shiz source code which incorporated techniques used by Zeus. Attackers use Shifu to steal credentials for online banking websites around the world, starting in Russia but later including the UK, Italy, and others.

Palo Alto Networks Unit 42 research has found that the Shifu authors have evolved Shifu in 2016. Our research has found that Shifu has incorporated multiple new techniques to infect and evade detection on Microsoft Windows systems. Some of these include:

  • Exploitation of CVE-2016-0167 a Microsoft Windows Privilege Escalation vulnerability to gain SYSTEM level privileges. Earlier versions of Shifu exploited CVE-2015-0003 to achieve the same goal
  • Use of a Windows atom to identify if the host is already infected with Shifu in addition to the mutex used by previous versions
  • Use of “push-calc-ret” API obfuscation to hide function calls from malware analysts
  • Use of alternative Namecoin .bit domains

We have also identified new links between Shifu and other tools which suggest Shifu isn’t simply based on the Shiz Trojan, but is probably the latest evolution of Shiz.

The primary goal of this report is to introduce Shifu’s new features to other malware analysts who may encounter this Trojan in the future. The following sections give an overview of the new features, and the appendix at the end includes the technical details on the overall functionality of Shifu.

New Developments and Features in Shifu

The Shifu version discussed in this analysis is comprised of several stages of payloads and was compiled in June 2016. The following image illustrates the different files included in the initial loader which get decrypted after execution:

shifu_1

Figure 1. File structure of Shifu

The initial obfuscated loader (x86 exe) contains the encrypted second stage injector (x86 exe). It uses three layers for decryption by subsequently allocating memory via VirtualAlloc() for the next layer. The second stage injector gets decrypted into memory and the original loader process is then overwritten with it. Next, the section flags are adjusted and the IAT addresses are resolved. The final decryption layer then jumps to the entry point of the second stage injector.

The second stage injector contains two exploits for CVE-2016-0167 (x86/x64) that have a compilation time stamp dated February, 2016. At the time of compilation, patches were not yet available for this vulnerability. However, the malware’s compilation time stamp dates June 2016. This may indicate the people behind this Shifu version had access to the zero-day exploit at that time or gained access to it afterwards. The exploit uses an interesting technique which makes it possible to just copy the raw disk file into memory. To make the file executable in memory, it uses a custom PE loader shellcode appended to both versions of the exploit as an PE overlay. The shellcode takes care of all the adjustments needed to get a proper executable memory image and executes the exploit. By doing so, the file just needs to be copied into a memory buffer and execution needs to be passed to the shellcode.

We have also found multiple other variants of the exploit, standalone versions (x86/64), but also versions which are embedded in an injector like in Shifu. Additionally, we identified a version of Vawtrak which contains an earlier version of the exploit dating back to November 2015, according to the compilation time stamp. The compilation time stamp of this Vawtrak sample itself dates January 2016 and thus is effectively the first malware known to us to use this exploit.

The second stage injector contains several anti-analysis tricks similar to the previous version. It also contains two command line parameters with functionality that indicate the malware is still in development. Further, the second stage injector uses an atom to check if the system is already infected, instead of using a mutex like most of the malware today. The use of atoms is not a new technique, but still not very widespread.

The main payload is encrypted and packed inside the .tls section of the second stage injector. It first gets decrypted and then unpacked with the aPLib compression library. As persistence method, the main payload copies the initial loader to the AppData folder and creates a Jscript file inside the Startup folder which points to it. The second stage injector injects the main payload inside a x86 instance of svchost and patches its API function calls with an obfuscation technique to make static and dynamic analysis of the malware more difficult.

Compared to the previous version, the main payload contains some updates. This includes the strings to search on the victim’s system, the browser target list, and the bot commands. The main payload uses .bit top-level domains to contact its C&C server. The domain names, the user-agent string and the URL parameters are encrypted with a modified RC4 encryption algorithm. The domain names indicate that the attackers may be either located in Ukraine or have a Ukrainian background.

Unfortunately, at the time of the analysis the C&C server didn’t respond with any commands and thus further analysis of the targeted financial institutions wasn’t possible. This information would be normally downloaded into a configuration file on the victim’s disk. For some of its functionality, the main payload hooks some API functions inside the svchost.exe process into which it is injected. Further, it uses the Apache web server for the web injections. If it was successfully downloaded from the C&C server, the malware makes use of a layered service provider to hook into the Winsock API for intercepting and modifying inbound and outbound Internet traffic. It also contains the normally used methods to hook into the browsers networking functions found in many other banking Trojans.

Both the second stage injector and the main payload contain a lot of strings which are never used. This indicates the author(s) were either in a rush to build the malware or the development was done in a sloppy way.

Instead of the string “IntelPowerAgent6” seen in the last version, this sample contains the string “IntelPowerAgent32” which is never used. In addition to the atom created by the second stage injector to check if the system is already infected, the main payload also creates a mutex with a name based on the same procedure to create the name for the atom (see Appendix). However, the mutex uses a hardcoded prefix named “DAN6J0-” before the byte sequence that is also used for the atom string: “{DAN6J0-ae000000d2000000e100}”

shifu_2

Figure 2. Shifu mutex and the associated svchost process

Shifu, Shiz and Other Related Tools

The Shifu banking Trojan is mainly based on the Shiz/iBank source code, which is one of the oldest banking Trojans still in the wild today. Shiz was first discovered in 2006 and has been through several stages of development since that time. It began as a banking Trojan which only focused on Russian financial institutions. Later, it also began targeting an Italian bank which may have set the stage for a more international focus. The internal versions we have tracked over the last five years ranged from generation 2 to 4 (2011) and 5 (2013/2014). The fifth generation of Shiz was the last one we saw in the wild in 2014 (last internal version was 5.6.25) and it differs from the 4th generation in the coding style. It looks like it was developed by another coder, which could indicate the source code was sold or shared. The query string used to contact the C&C server of one of the very first versions of the fifth generation supports our theory:

botid=%s&ver=5.0.1&up=%u&os=%03u&ltime=%s%d&token=%d&cn=reborn&av=%s

We can see that the campaign name (cn) contains the string “reborn”.

Shifu was first discovered in the wild in the middle of 2015 and we believe it's the evolution of the 5th generation of Shiz with a more international focus.

We have not only tracked the Shiz banking Trojan over the last couple of years, but also found several additional malware tools allegedly from the same author(s). Collected samples indicate the author(s) have developed a whole set of financially related malware. It’s not clear if the author works as part of a group or uses the malware themselves. These tools are mainly based on the source code of the fifth generation of Shiz.

We have connected these tools together because they all contain a PDB path that has the same root folder:

Z:\coding\...

Furthermore, most of the tools are based on the Shiz source code, because the coding style and used API functions are very similar. Also, comparing the code between the tools with BinDiff shows a high degree of similarity. Moreover, those tools with network functionality contain query strings similar to the one in Shiz to contact their C&C server.

As our colleagues from FireEye described last year, the PDB path found in Shifu is as follows:

Z:\coding\project\main\payload\payload.x86.pdb

Other tools we have identified have the following PDB paths and are likely from the same author(s):

Z:\coding\cryptor\Release\crypted.pdb

Z:\coding\malware\tests\Release\cryptoshit.pdb

Z:\coding\malware\RDP\output\Release\rdp_bot.pdb

Z:\coding\malware\ScanBot\Release\bot.pdb

The malware internally named "cryptor" contains an encrypted sample of BifitAgent, the first malware known to attack the financial software from BIFIT. While it's possible that BifitAgent is developed from the same person, we haven't found any indications for that. According to the compilation time stamps, most of the samples were created in October/November 2013.

The malware with the name "rdp_bot" is a small bot which uses the RDP protocol to gain full access to a computer. It uses the same modified RC4 encryption algorithm as the Shifu version discussed in this article. This tool was probably used along the Shiz banking Trojan, because the attacker is able to do his fraudulent activities directly from the victim’s computer. By doing so, one could fool bank antifraud systems which check for the IP address, browser footprints or keyboard layouts. The tool is based on the research about RDP performed by Alisa Esage. The samples date from June to November 2013.

The tool which is named "cryptoshit" contains an encrypted sample of rdp_bot and also uses the same modified RC4 algorithm as the Shifu version described here. The samples date September/October 2013 and January 2014 according to the compilation time stamp.

The malware with the internal name "ScanBot" is a small backdoor which uses the Super Light Regular Expression library (SRLE) for scanning a victim’s computer for files via commands from its operator. The samples date June 2013 according to the time stamp.

Protection Against Shifu

Palo Alto Networks customers are protected from Shifu in the following ways:

  • Wildfire classifies Shifu files as malicious and signatures are loaded into Threat Prevention
  • AutoFocus customers can track malware using the Shifu tag
  • Command and Control domains used by Shifu are blocked through Threat Prevention

SHA256 Hashes of Samples Discussed

Initial obfuscated loader

d3f9c4037f8b4d24f2baff1e0940d2bf238032f9343d06478b5034d0981b2cd9
368b23e6d9ec7843e537e9d6547777088cf36581076599d04846287a9162652b
e7e154c65417f5594a8b4602db601ac39156b5758889f708dac7258e415d4a18
f63ec1e5752eb8b9a07104f42392eebf143617708bfdd0fe31cbf00ef12383f9

Second stage injector

003965bd25acb7e8c6e16de4f387ff9518db7bcca845502d23b6505d8d3cec01
1188c5c9f04658bef20162f3001d9b89f69c93bf5343a1f849974daf6284a650

Exploit injector

e7c1523d93154462ed9e15e84d3af01abe827aa6dd0082bc90fc8b58989e9a9a

CVE-2016-0167 exploit (x86)

5124f4fec24acb2c83f26d1e70d7c525daac6c9fb6e2262ed1c1c52c88636bad

CVE-2016-0167 exploit (x64)

f3c2d4090f6f563928e9a9ec86bf0f1c6ee49cdc110b7368db8905781a9a966e

Main payload

e9bd4375f9b0b95f385191895edf81c8eadfb3964204bbbe48f7700fc746e4dc
5ca2a9de65c998b0d0a0a01b4aa103a9410d76ab86c75d7b968984be53e279b6

Appendix - Technical details

Second Stage Injector Analysis

The second stage injector contains an exploit injector (x86 DLL) which in turn has two embedded exploits (x86/64 DLL) for CVE-2016-0167. The second stage injector also contains the encrypted and aPLib packed main payload module (x86 DLL) in its .tls section. For decryption, it uses a modified version of the RC4 encryption algorithm with a salt that is stored in the .rsrc section. Significant strings in the second stage injector's .data section were XORed with the key 0x8D and get decrypted on-the-fly. Decrypted strings:

Exploit Injector with Embedded CVE-2016-0167 Exploits

The exploit injector is used to gain SYSTEM privileges on the infected host. The injector contains the actual exploits for both x86 and x64 systems. The magic PE bytes ("MZ") at the beginning of the files are patched will null bytes to prevent them from automatic extraction.

The second stage injector checks for the current process' integrity level and the OS version. If the integrity level of the process is low and the OS version is 6.1 (Windows 7 / Windows Server 2008 R2), the second stage injector writes the exploit injector file into memory. Then, it searches for the magic value 0x99999999 in the exploit injector which marks the beginning of the PE overlay. When the address was found, 12 bytes are added and the second stage injector jumps to this address which is in fact a custom PE loader shellcode. The call to the shellcode looks as follows:

Custom PE loader shellcode

It first gets the end of the shellcode which is then used to scan the exploit injector file for the magic PE number ("MZ"). The code to get end of the shellcode looks as follows:

Next, a custom GetProcAddress() function is used together with a hashing function to find the address of VirtualAllocEx(). Then, VirtualAllocEx() is called to allocate a memory buffer of with full access rights into which the exploit injectors sections are written with the appropriate memory alignments. The necessary memory addresses are then adjusted with help of the relocation information, the API function addresses are resolved and the IAT is filled. Finally, the shellcode jumps to the DLL entry point of the freshly created exploit injector module.

Exploit injector

At first, the strings "kernel32.dll", "LoadLibrary" and "GetProcAddress" are created. Next, the image base address for kernel32.dll is searched and the addresses of LoadLibrary() and GetProcAddress() are obtained. With help of these API functions, the IAT addresses of the exploit injector get resolved and the IAT is filled. The purpose of this function is unclear, as it was already done by the second stage injector. Thereafter, a new thread gets created with API function CreateThread().

The thread first calls IsWow64Process() and according to the result either the embedded x86 or x64 version of the exploit file is written into a memory buffer. Next, the PE magic value ("MZ") is written to the beginning of the exploit file. Then, an event named "WaitEventX" is created which is later used by the exploit. Then, the main exploit loading function is called.

The exploit loading function searches for the following process names and if found also the module names for the following strings which are part of Trend Micro security software:

  • "uiSeAgnt.exe"
  • "PtSessionAgent.exe"
  • "PwmSvc.exe"
  • "coreServiceShell.exe"

If one of the processes is found, a suspended process of wuauclt.exe is created. Otherwise, a suspended process of svchost.exe is created. In both cases, the command line argument "-k netsvcs" is passed, but can be only used by svchost.exe. It should be noted that this functionality always fails if the x64 version of Trend Micro Internet Security is installed. The code (x86) calls CreateToolhelp32Snapshot() on a x64 process which results in an error (ERROR_PARTIAL_COPY). Moreover, it also fails because the code tries to access a protected Trend Micro process (ERROR_ACCESS_DENIED).

Next, it maps the x86 or x64 file of the exploit into memory with CreateFileMapping() and MapViewOfFile() and fills in the memory with the exploit bytes. Finally, the section gets mapped into the suspended process of svchost.exe or wuauclt.exe by using ZwMapViewOfSection(). It then checks the OS version if it is 5.2 (Windows Server 2003 / Windows XP 64-Bit Edition) and exits the function if so. Afterwards, two memory buffers are created and a shellcode is written to each of them. The first obfuscated shellcode calls the second shellcode, which is a stager for the mapped exploit file. Next, it calls ResumeThread() to execute the suspended process so the exploit is executed.

The second stage injector verifies that the exploit was successful by checking if the integrity level of itself is still SECURITY_MANDATORY_LOW_RID. If not, the exploit successfully elevated privileges to SECURITY_MANDATORY_SYSTEM_RID and continues with the injection of the main payload. If the exploit failed, it tries to execute itself under the SYSTEM user account with help of the Windows command line (cmd.exe) and runas.exe tool.

Atom String Building

Instead of using a mutex like most of today’s malware, the second stage injector creates an atom and checks the global atom table to see if an instance of Shifu is already running.

At first, it uses the template string "%OS%_%NUMBER_OF_PROCESSORS%" for the API ExpandEnvironmentStrings() to get the Windows version and number of processors. For example, in Windows 7 with one processor the result would be "Windows_NT_1". This string is then used to calculate four CRC32 hashes with RtlComputeCrc32() and the following initial values:

  • 0xFFFFFFFF
  • 0xEEEEEEEE
  • 0xAAAAAAAA
  • 0x77777777

The resulting CRC hashes of the string "Windows_NT_1" are as follows:

  • 0x395693AE
  • 0xB24495D2
  • 0xF39F86E1
  • 0xBAE0B5C8

Next, the last byte of each CRC hash is stored as a DWORD value on the stack:

  • 0xAE000000 (from 0x395693AE)
  • 0xD2000000 (from 0xB24495D2)
  • 0xE1000000 (from 0xF39F86E1)
  • 0xC8000000 (from 0xBAE0B5C8)

The stack with the hash byte sequence looks as follows:

AE 00 00 00 D2 00 00 00 E1 00 00 00 C8 00 00 00

The atom string is then created by converting first 8 bytes of the hash byte sequence to ASCII characters with snprintf() function. The result in this case would be:

"ae000000d2000000"

At last, it calls GlobalFindAtom() API to check if the atom is present and calls GlobalAddAtom() if not.

shifu_3

Figure 3. Shifu atom in the global atom table

Command Line Arguments

The second stage injector has two command line parameters of which only one has a functionality. They may be used for an upcoming feature or were just forgotten to be removed.

  • --crypt-test

Shows just a message box with the text "It work's!"

  • --vm-test

No functionality

Anti-Analysis Tricks

Anti Sandboxie / Avast

Shifu checks if the module snxhk.dll (Avast) or sbiedll.dll (Sandboxie) is present in its own process space by calling GetModuleHandleA() and runs an infinite Sleep() loop if a handle is returned.

All the following anti analysis tricks are only used if Shifu is executed on a 32-bit Windows machine (no Wow64 process).

Process name detection

It enumerates running process names, converts them to lowercase, calculates the CRC32 hashes of those names and compares to the following list:

  • 0x99DD4432 - ?
  • 0x1F413C1F - vmwaretray.exe
  • 0x6D3323D9 - vmusrvc.exe
  • 0x3BFFF885 - vmsrvc.exe
  • 0x64340DCE - ?
  • 0x63C54474 - vboxtray.exe
  • 0x2B05B17D - ?
  • 0xF725433E - ?
  • 0x77AE10F7 - ?
  • 0xCE7D304E - dumpcap.exe
  • 0xAF2015F2 - ollydbg.exe
  • 0x31FD677C - importrec.exe
  • 0x6E9AD238 - petools.exe
  • 0xE90ACC42 - idag.exe
  • 0x4231F0AD - sysanalyzer.exe
  • 0xD20981E0 - sniff_hit.exe
  • 0xCCEA165E - scktool.exe
  • 0xFCA978AC - proc_analyzer.exe
  • 0x46FA37FB - hookexplorer.exe
  • 0xEEBF618A - multi_pot.exe
  • 0x06AAAE60 - idaq.exe
  • 0x5BA9B1FE - procmon.exe
  • 0x3CE2BEF3 - regmon.exe
  • 0xA945E459 - procexp.exe
  • 0x877A154B - peid.exe
  • 0x33495995 - autoruns.exe
  • 0x68684B33 - autorunsc.exe
  • 0xB4364A7A - ?
  • 0x9305F80D - imul.exe
  • 0xC4AAED42 - emul.exe
  • 0x14078D5B - apispy.exe
  • 0x7E3DF4F6 - ?
  • 0xD3B48D5B - hookanaapp.exe
  • 0x332FD095 - fortitracer.exe
  • 0x2D6A6921 - ?
  • 0x2AAA273B - joeboxserver.exe
  • 0x777BE06C - joeboxcontrol.exe
  • 0x954B35E8 - ?
  • 0x870E13A2 - ?

File detection

Shifu checks if the following files or folders exist on the system and runs an infinite Sleep() loop if so:

  • c:\sample\pos.exe
  • c:\analysis\sandboxstarter.exe
  • c:\analysis
  • c:\insidetm
  • c:\windows\system32\drivers\vmmouse.sys
  • c:\windows\system32\drivers\vmhgfs.sys
  • c:\windows\system32\drivers\vboxmouse.sys
  • c:\iDEFENSE
  • c:\popupkiller.exe
  • c:\tools\execute.exe
  • c:\Perl
  • c:\Python27

Debugger detection

It checks if it’s being debugged by calling IsDebuggerPresent(). Also, it calls ZwQueryInformationSystem() with ProcessDebugPort and ProcessDebugObjectHandle to check for a debugger presence. If a debugger is detected it runs an infinite Sleep() loop.

Wireshark detection

Shifu attempts to open \\.\NPF_NdisWanIp with CreateFile() and will enter an infinite Sleep() loop if it is successful.

Self-sanity checks

It checks its own file name length if it is longer than 30 characters and runs an infinite Sleep() loop if so. Also, it checks if its own process name CRC32 hash matches one of the following:

  • 0xE84126B8 - sample.exe
  • 0x0A84E285 - ?
  • 0x3C164BED - ?
  • 0xC19DADCE - ?
  • 0xA07ACEDD - ?
  • 0xD254F323 - ?
  • 0xF3C4E556 - ?
  • 0xF8782263 - ?
  • 0xCA96016D - ?

Furthermore, it checks if one of the following modules from GFI Sandbox is present in its own process address space:

  • api_log.dll
  • dir_watch.dll
  • pstorec.dll

Unknown anti-analysis trick

Shifu uses an anti-analysis trick whose purpose is unknown to us. It retrieves the address of Process32NextW() and compares the first 5 bytes with the sequence 0x33C0C20800 which disassembles to:

This code is only present in 32-bit Windows XP and not in later Windows versions, because the Unicode version of that function probably wasn't implemented yet. If the code sequence is found meaning that Shifu was executed on 32-bit Windows XP, it runs an infinite Sleep() loop.

Windows domain name check

It checks if the computer workgroup name is either "WORKGROUP" or "HOME" with API functions NetServerGetInfo() and NetWkstaGetInfo() and runs an infinite Sleep() loop otherwise. Next, it checks for the name "ANALYSERS" and runs the infinite loop if found.

Computer and user name check

Shifu gets the computer and user name with GetComputerName() and GetUserName() to check for the following strings:

  • SANDBOX
  • FORTINET
  • VIRUS
  • MALWARE
  • MALNETVM

If one is found it runs an infinite loop.

Process termination feature

Second stage injector of Shifu enumerates all running processes, converts every name to lower case, calculates the CRC32 hash of it and compares it to the following ones:

  • 0xD2EFC6C4 - python.exe
  • 0xE185BD8C - pythonw.exe
  • 0xDE1BACD2 - perl.exe
  • 0xF2EAA55E - autoit3.exe
  • 0xB8BED542 - ?

If one matches, it first tries to terminate the process with OpenProcess() and TerminateProcess(). If that fails, it tries to close the main window handle of the process if it is flagged as HANDLE_FLAG_PROTECT_FROM_CLOSE with ZwClose(). Then, it opens the process with full access rights and unmaps it from memory with ZwUnmapViewOfSection(). At last, the main window handle of the unmapped process is closed.

Main Payload Decryption, Unpacking and Injection

To decrypt the main payload, the second stage injector retrieves a salt needed for the decryption algorithm from its .rsrc section. It uses a modified RC4 algorithm where the salt is used to XOR the array of 256 bytes byte after byte at the beginning. The encrypted array is then used to decrypt the main payload located in the .tls section. The decrypted main payload is additionally packed with the aPLib compression library.

If the initial loader runs as a medium or high integrity level process, the routine which calculates the atom string name is called again. This time, only the first 4 bytes are used to build a string, for example "ae000000". Next, the CRC32 hash of this string is calculated and used to XOR another array of 256 bytes starting from 0x0 to 0xFF. This encrypted array is then used to again encrypt the decrypted main payload. The resulting encrypted data are written to registry for persistence purposes under the key "HKCU\software\microsoft\windows" with a random CRC32 hash name, for example "f4e64d63". Also, a second value with the string "ae000000" as name is created and filled up with null bytes and the path of the initial loader, for example "C:\ProgramData\7d5d6044.exe". At last, the temporarily encrypted main payload gets decrypted again.

shifu_4

Figure 4. Encrypted main payload and initial loader path stored in the Windows registry

Next, the main payload gets unpacked into memory. Thereafter, a suspended svchost.exe process (x86) is created with the same integrity level as the parent process. The main payload gets mapped into the process and the magic PE value (MZ) patched. The svchost process gets then resumed so the main payload is executed. At last, a batch file is created and executed in the %TEMP% folder. It overwrites the original executed initial loader with a random number of bytes to cover the tracks. The random bytes are always followed by a space character and the CR LF control characters.

Main Payload Analysis

The main payload module's IAT function names were XORed with the key 0xFF to make static analysis more difficult. Significant strings in the .data section are also XORed with the key 0x8D and get decrypted on-the-fly. Decrypted strings:

API Obfuscation

The main payload uses an API obfuscation technique known as Push-Calc-Ret obfuscation. The calls to the real API functions are patched by the second stage injector after the main payload gets injected into the svchost process. Whenever a Windows API function should have been called, instead the address of a trampoline function is called which calculates the actual function address. All the trampoline function addresses are stored in an array in memory.

For example, the main payload wants to call CreateFile(), but this call is patched. Now, it calls the trampoline function which could look as follows:

First, a value is pushed to the stack. Next, the EFLAGS register is saved to the stack, because it will be altered by the following XOR instruction (OF, CF flags are cleared and the SF, ZF, and PF flags are set according to the result). Then, the previously pushed value is XORed with another value to calculate the actual API function address. At last, the EFLAGS register gets restored and the real API function address is called via the RETN instruction.

Persistence Method

The main payload copies the initial obfuscated loader file to the %ProgramData% folder with a random file retrieved with GetTickCount(). Then, it creates a JScript file named "Common.js" in the Startup folder of the current user. The file contains the following code which runs the initial loader after the system was rebooted:

Updates of the Main Payload compared to Previous Version

Reports on previous versions of Shifu have been published by FireEye and Fortinet.

In comparison to the previous version, the list of substrings to scan for in the string that gets created with the computer name, user name, install date and system drive volume serial number was expanded:

  • TREASURE
  • BUH
  • BANK
  • ACCOUNT
  • CASH
  • FINAN
  • MONEY
  • MANAGE
  • OPER
  • DIRECT
  • ROSPIL
  • CAPO
  • BOSS
  • TRADE

Updated command list:

  • active_sk
  • deactive_sk
  • deactivebc
  • get_keylog
  • get_sols
  • inject
  • kill_os
  • load
  • mitm_geterr
  • mitm_mod
  • mitm_script
  • wipe_cookies

Updated list of targeted browsers:

  • iexplore.exe
  • firefox.exe
  • chrome.exe
  • opera.exe
  • browser.exe
  • dragon.exe
  • epic.exe
  • sbrender.exe
  • vivaldi.exe
  • maxthon.exe
  • ybrowser.exe
  • microsoftedgecp.exe

The main payload will download the Apache httpd.exe server file from one of the C&C servers to store it on disk for web injection purposes. Compared to the previous version, the main payload also contains two strings which indicate some functionality for the Zend PHP Framework:

  • zend_stream_fixup
  • zend_compile_file

Function Hooking in Svchost

Like in the previous version, the malware hooks some API functions to redirect URLs, capture network traffic, the clipboard and to log keystrokes. It uses a technique known as inline function hooking where the first 5 bytes of a function get patched with a jump to the malware's hook handlers. The following functions get hooked:

  • NtDeviceIoControlFile (ntdll.dll)
  • ZwDeviceIoControlFile (ntdll.dll)
  • GetClipboardData (user32.dll)
  • GetMessageA (user32.dll)
  • GetMessageW (user32.dll)
  • TranslateMessage (user32.dll)
  • GetAddrInfoExW (ws2_32.dll)
  • gethostbyname (ws2_32.dll)
  • getaddrinfo (ws2_32.dll)

Network Functionality

The main payload of Shifu uses .bit top-level domains which is a decentralized DNS system based on the Namecoin infrastructure. The malware requests the IP addresses of the domains by subsequently contacting the following hardcoded Namecoin DNS servers:

  • 92.222.80.28
  • 78.138.97.93
  • 77.66.108.93

The C&C domain names, the user-agent string and the URL parameters are encrypted with a modified RC4 encryption algorithm. Decrypted strings:

  • klyatiemoskali.bit
  • slavaukraine.bit
  • Mozilla/5.0 (Windows; U; Windows NT 5.2 x64; en-US; rv:1.9a1) Gecko/20061007 Minefield/3.0a1
  • L9mS3THljZylEx46ymJ2eqIdsEguKC15KnyQdfx4RTcVu8gCT
  • https://www.bing.com
  • /english/imageupload.php
  • /english/userlogin.php
  • /english/userpanel.php
  • 1brz

The encrypted strings are stored in the following format inside the .data section:

<LengthOfString><EncryptedString>

The domain string “klyatiemoskali“ means roughly translated to wish something bad to Muscovites. The second domain string “slavaukraine” means translated “glory to the Ukraine”. The included RC4 key "L9mS3THljZylEx46ymJ2eqIdsEguKC15KnyQdfx4RTcVu8gCT" is used to encrypt the network traffic.

At the time of analysis, only the following Namecoin DNS server was answering with the IP address of the actual C&C server:

77.66.108.93 (ns1.dk.dns.d0wn.biz)

shifu_5

Figure 5. Namecoin DNS server information of 77.66.108.93

The following screenshot shows the captured network traffic during the dynamic analysis of Shifu:

shifu_6

Figure 6. Shifu network traffic captured with Wireshark

We can see that Shifu subsequently queries the Namecoin DNS servers with the domain name klyatiemoskali.bit to get the IP address. After one name server responds with the IP address of the C&C server, it does a TLS handshake to open an encrypted network channel. Finally, it sends some encrypted data and gets an encrypted answer. However, no further network traffic could have been observed during the time of the analysis. Both domain names, klyatiemoskali.bit and slavaukraine.bit, resolved to the IP address 103.199.16.106 at the time of analysis.

As the .bit top-level domain relies on the Namecoin cryptocurrency which is based on the Bitcoin system, every transaction can be traced back. Thus, we can use a Namecoin block explorer to look when the .bit domains were registered and which IP addresses are connected to it. For example, if we use the web service namecha.in, we can get the following information for klyatiemaskali.bit:

shifu_7

We can see the same information for slavaukraine.bit:

shifu_8

Both domains were registered on 2016-06-03 and only one IP address is assigned to them. This IP address coincides with the response of the Namecoin DNS server we have seen in the captured network traffic. Moreover, we can see the domain seems to be still active.

URL Query String for C&C Server

The main payload contains a query string template used to send information of the victim to the C&C server:

botid=%s&ver=%s.%u&up=%u&os=%u&ltime=%s%d&token=%d&cn=%s&av=%s&dmn=%s&mitm=%u

We can see that some information is dynamically retrieved (bot identifier, uptime, operating system version, local timestamp, token, anti-virus software, domain name of workstation, man in the middle interception detected), while also static values like the bot version and the campaign name are send. An example of the created query string could look as follows:

botid=26C47136!A5A4B18A!F2F924F2&ver=1.759&up=18294&os=6110&ltime=-8&token=0&cn=1brz&av=&dmn=&mitm=0

We can see that the internal Shifu version is “1.759” and the campaign name is stated “1brz”.

If we compare Shifu's query string with the one of the latest Shiz version we have tracked which dates February 2014 (internal version 5.6.25), we can see the similarity between those two malwares:

botid=%s&ver=5.6.25&up=%u&os=%03u&ltime=%s%d&token=%d&cn=sochi&av=%s

Modified RC4 Encryption Algorithm

Shifu uses a modified version of the RC4 encryption algorithm. We have reconstructed the algorithm in Python and show how the domain name "klyatiemoskali.bit" present in the main payload will be encrypted as an example:

 

DragonOK Updates Toolset and Targets Multiple Geographic Regions

Posted on by Josh Grunzweig

The DragonOK group has been actively launching attacks for years. We first discussed them in April 2015 when we witnessed them targeting a number of organizations in Japan. In recent months, Unit 42 has observed a number of attacks that we attribute to this group. Multiple new variants of the previously discussed sysget malware family have been observed in use by DragonOK. Sysget malware was delivered both directly via phishing emails, as well as in Rich Text Format (RTF) documents exploiting the CVE-2015-1641 vulnerability (patched in MS15-033) that in turn leveraged a very unique shellcode. Additionally, we have observed instances of the IsSpace and TidePool malware families being delivered via the same techniques. While Japan is still the most heavily targeted geographic region by this particular actor, we also observed instances where individuals or organizations in Taiwan, Tibet, and Russia also may have been targeted.

Infiltration

We observed two unique techniques of infiltration for this particular campaign:

  1. Phishing emails being sent with malicious executables directly attached
  2. Malicious RTF files which exploit CVE-2015-1641.

The phishing emails had the following characteristics:

Email Subjects

  • Pickup at the Juanda Airport (1-Sep)
  • ポイントプレゼントのお知らせ [Roughly Translated: Point gift announcement]
  • 20周年記念パーティー [Roughly Translated: 20th Anniversary Party]
  • 参加者の10周年記念同窓会一覧 [Roughly Translated: List of participants' 10th anniversary alumni association]
  • 子供の調査連れ [Roughly Translated: Children's investigation]
  • G20 report
  • 記念日の再会 [Roughly Translated: Anniversary reunion]
  • 最新の人事異動通知 [Roughly Translated: Recent personnel change notice]

Attachment Filenames

  • G20 report.exe
  • exe
  • List of Participants.exe
  • Registration form.exe

These emails targeted the following industries in Japan:

  • Manufacturing
  • Higher Education
  • Energy
  • Technology
  • Semiconductor

The malicious RTF files in question leverage a very specific shellcode to drop and execute the malicious payload, as well as a decoy document. Decoy documents are legitimate benign documents that are opened after the malicious payload is delivered, thus ensuring that the victim does not become suspicious because their expected document opened as expected.

Two samples were found to include the decoy document show in Figure 1.

The title of the document roughly translates to “Ministry of Communications & Departments Authorities Empty Sites and Hosted Public Works Source Clearance Photos”. The use of traditional Chinese indicators the target likely residing in either Taiwan, Hong Kong, or Macau. However, based on the Taiwanese subject matter in this document, we can safely come to the conclusion that the intended victim was of Taiwanese origin. These samples delivered an updated version of the IsSpace malware family, which was discussed previously in a watering hole attack targeting an aerospace firm. IsSpace is an evolved variant of the NFlog backdoor, which has been used by DragonOK in the past.

dragon_1

Figure 1 Taiwanese decoy document

Two other samples were identified that used a Tibet-themed decoy document. The document in question (Figure 2) appears to be an internal newsletter from the Central Tibetan Ministry, as suggested by the logo used as well as the content of the document itself.  This document indicates that the malware may have been targeted towards an individual that is interested in Tibetan affairs. These particular samples were unique in that they delivered the TidePool malware family that we reported on in May of 2016. We have not previously observed DragonOK using TidePool in attacks.

dragon_2

Figure 2 Tibetan decoy document containing internal newsletter

We also identified an additional sample using decoy targeting Taiwanese victims (Figure 3), which deployed a newer sysget sample.

dragon_3

Figure 3 Taiwanese-targeted decoy document

Other new samples associated with this group used a Russian language decoy document (Figure 4.) The decoy document in question discusses the GOST block cipher, which was created by the Russian government in the 1970’s. The combination of Russian language and Russian-specific subject matter indicates that the intended victim speaks Russian and may be interested in encryption. Like the previously discussed Tibetan decoy documents, these samples also delivered the TidePool malware family.

dragon_4

Figure 4 Russian decoy document discussing the GOST block cipher

Finally, multiple samples used a traditional Chinese language decoy document that discussed a subsidy welfare adjustment program. The use of traditional Chinese indicators the target likely residing in either Taiwan, Hong Kong, or Macau. Similar to other attacks witnessed, a variant of the sysget malware family is installed by these files.

dragon_5

Figure 5 Decoy document discussing subsidy welfare adjustment program

Malware Deployed

In looking at the various malware samples used in attempted attacks, the following four families were identified:

  • Sysget version 2
  • Sysget version 3
  • TidePool
  • IsSpace

We broke the sysget classification into multiple variants when we found that a number of changes have been made since our April 2015 report. Major distinctions between the versions of sysget include the following:

Sysget version 2

  • Removed support for persistence on Windows XP
  • Reworked the URIs used for network communication
  • Added additional layers of encryption for network communication and stored configuration files
  • Switched from RC4 to AES-128

Sysget version 3

  • Numerous anti-debug and anti-vm procedures added
  • Encrypted URIs in network communication with an initial static key

In addition, we observed a sysget version 4 that was discovered in another sample during our research. This version is not attributed to a specific attack against an organization.

Indicators of compromise related to sysget version 4 and other samples not directly attributed to specific attacks may be found in the Appendix of this blog post.  Additionally, more information about the various sysget variants may also be found in the Appendix.

The TidePool samples encountered are consistent with the samples previously discussed. I encourage readers to view our previous blog post to learn more about the intricacies of this particular malware family.

The IsSpace malware sample, however, looks to have been updated since last we wrote on it. While the available commands from the command and control (C2) server remains the same, the URI structure of the network communication has been modified. Additionally, the installation routine for this malware family has been updated to be far less complex than previous discussed versions, favoring PowerShell to set persistence and forgoing the previously used side-loading technique. A more detailed analysis of the new instances of IsSpace may be found at the end of this blog post in the Appendix.

Infrastructure

A number of unique domains were employed by the various Trojans used in these attacks. For the numerous instances of sysget we observed, the following domains were observed for their C2:

  • kr44.78host[.]com
  • gtoimage[.]com
  • gogolekr[.]com

All of the above domains have Chinese WHOIS registrant details. Additionally, the gotoimage[.]com and trend.gogolekr[.]com are both registered to the same registrant and resolve to the same netblock of 104.202.173.0/24.

The instances of TidePool identified communicated with the following C2 servers:

  • europe.wikaba[.]com
  • russiaboy.ssl443[.]org
  • cool.skywave[.]top

These domains did not have many definitive relations with the sysget C2 servers except for cool.skywave[.]top, which shared a unique registrant email with the sysget C2 server of trend.gogolekr[.]com. Additionally, the geographic region of the resolved IPs was consistent with the previous set, as they all resolved to various regions in southeast Asia. Specifically, the domains resolved to China, Korea, and Taiwan in the past six months.

The IsSpace samples resolved to the following domains:

  • www.dppline[.]org
  • www.matrens[.]top

These domains had no apparent connections to the previously discussed C2 servers, other than the fact that they resolved to Korea and Hong Kong respectively. Additionally, the registrar of ‘Jiangsu Bangning Science and technology Co. Ltd.’ was used for a large number of domains. A full graph of the relations between the various attacks is shown in Figure 6.

dragon_6

Figure 6 Relationships between attacks

Conclusion

The DragonOK group are quite active and continue updating their tools and tactics. Their toolset is being actively developed to make detection and analysis more difficult. Additionally, they appear to be using additional malware toolsets such as TidePool. While Japan is still the most-targeted region by this group, they look to be seeking out victims in other regions as well, such as Taiwan, Tibet, and Russia.

Palo Alto Network customers are protected against this threat in the following ways:

  • Malware families are tagged in AutoFocus via a variety of tags (TidePool, NFlog, Sysget)
  • The following IPS signatures detect malicious network traffic:
    • IPS signature 14365 (IsSpace.Gen Command And Control Traffic)
    • IPS signature 14588 (Suspicious.Gen Command And Control Traffic)
    • IPS signature 13574 (NfLog.Gen Command And Control Traffic)
    • IPS signature 13359 (Nflog.Gen Command And Control Traffic)
  • All samples are appropriately marked malicious in WildFire

Appendix

CVE-2015-1641 Exploit and Shellcode

This particular group uses a very specific shellcode payload when exploiting CVE-2015-1641. This CVE is memory corruption vulnerability which allows for arbitrary code execution in various versions of Microsoft Office, including 2007, 2010, and 2013.

The shellcode begins by dynamically loading a small number of API functions from kernel32. A number of hashes are included that represent function names, which have a rotate right 7 (ROR7) operation applied against them before being XORed against a key of “\x10\xAD\xBE\xEF”. The ROR7 operation is a very common technique in shellcode to obfuscate what functions are being called. The author added the XOR operation to add another layer of obfuscation.

dragon_7

Figure 7 API function hashes contained in shellcode

After the shellcode loads the necessary API functions, it proceeds to seek out a number of markers that will mark the beginning and ending of both an embedded malicious payload, as well as a decoy document.

The malicious executable is marked with a starting point of 0xBABABABABABA and an end marker of 0xBBBBBBBB. The decoy document is found immediately after the end of the malicious payload, and has an end marker of 0xBCBCBCBC. Both executables are encrypted with a 4-byte XOR key. Should the original data contain 0x00000000, it will not have the XOR applied against it.

The malicious payload is XORed against a key of 0xCAFEBEEF and the decoy document is XORed against 0xBAADF00D. The following script may be applied against the RTF document to extract both the malicious payload and the decoy:

When both files are decrypted, they are written to the following location in the %TEMP% directory:

  • ../..exe
  • ../..doc

Note the initial ‘..’, which represents the parent directory of %TEMP%. This coupled with the unusual names of ..exe and ..doc make this particular shellcode very unique, which is one way we have attributed these samples to the same group. After the samples have been written, they are executed via calls to WinExec.

Sysget v2 Analysis

One of the fundamental changes witnessed in the second iteration of sysget is removing support for Windows XP and lower. Other changes include modifications to the URIs used for network communication.

Like the original version of sysget, sysget v2 still uses a named event of ‘mcsong[]’ to ensure a single instance is running at a time. It proceeds to make attempts at copying itself to the %STARTUP%/notilv.exe path. However, it uses COM objects to perform this action that is not available in Windows XP, which prevents the malware from installing itself to this location. While the remainder of the malware operates as expected, it will not survive a restart of the system.

Sysget proceeds to make an attempt at reading the following configuration file. This filename and path has changed since the original version, and is consistent in the subsequent versions.

  • %APPDATA%/vklCen5.tmp

This configuration file holds both a unique victim identifier, as well as a key that is used to encrypt HTTP traffic. It is encrypted using the AES-128 encryption algorithm, using a static key of ‘734thfg9ih’. Using AES-128 is a change from the previous version, where RC4 was used for all encryption operations. The following Python code may be used to decrypt this file:

When executed against an example configuration file, we see the following output, which includes the two pieces of data noted previously:

The encryption of this configuration file is a new feature that was not present in the original version of sysget.

If this file is not present on the system, the malware will attempt to retrieve the necessary information via a HTTP request. The following request is made to the remote command and control server. Note that the full URI is statically set by the malware sample.

The server responds with the following data, encrypted using the same technique previously described with a static key of ‘aliado75496’. Once decrypted, we see the following example data being sent back to sysget:

gh1443717133\n1059086204\n

The first string is used as a key for all subsequent network communication. The second string is treated as a unique victim identifier. This data is encrypted using the key of ‘734thfg9ih’ and written to the %APPDATA%/vklCen5.tmp file.

After this information has been obtained, the malware proceeds to enter its command and control loop. An HTTP request such as the following is made to the remote server. Note that the ‘mid’ GET variable holds the MD5 hash of the previously obtained victim identifier. The remaining data in the URI is hardcoded.

The response is encrypted using the unique key that was obtained previously. Should the response contain ‘Fatal error’ unencrypted, no further actions are taken by the malware sample. Once decrypted, the response may have one of the following two choices, and their accompanying purpose. Alternatively, if a raw command is provided, the malware will execute it and return the results.

Command Description
goto wrong "[file_path]";\n Read a specific file and return its contents.
goto right "[filename]" "[identifier]" Write a given file. The identifier is used to retrieve the file’s contents in a subsequent HTTP request.

When the ‘goto wrong’ request is made, a HTTP POST request is made to the following URI. In the following URI, the ‘list’ parameter contains the MD5 hash of the victim’s identifier.

/index.php?type=register&pageinfo=myid32987&list=5717cb8fed2750a2ee9e830a3
0716ed4

The contents of this POST request contains the victim’s identifier, as well as the file’s contents encrypted with the unique key. The first 50 bytes are reserved for the victim identifier, as shown below:

Once decrypted, the data contains both the filename, as well as the contents of that file.

If the ‘goto right’ command is used, the malware will make a subsequent request to the following URI. The ‘cache’ variable holds the unique identifier that was provided in the ‘goto right’ command.

/index.php?type=goto&pageinfo=myid47386&cache=identifier

Once the file contents are obtained, they are written to the specified filename in the %STARTUP% folder.

When a raw command is received, the malware will upload the results to the following URI via a POST request:

/index.php?type=register

An overview of the network communications exhibited by sysget version 2 can be seen in the figure below.

dragon_8

Figure 8 Sysget version 2 command and control flow

Sysget v3 Analysis

Some of the biggest changes witnessed in version 3 of sysget includes numerous anti-debug and anti-vm detections added, as well as the encryption of the URIs used for network communication.

When the malware initially executes, it performs the following checks to ensure it is not being debugged and not running in a sandbox or virtualized environment.

Should these checks return false, the malware proceeds to enter its installation routine. The malware originally copies itself to a temp file in the %TEMP% directory with a filename prefix of ‘00’. It proceeds to append 4194304 bytes of randomly chosen data to the end of this file. The increased filesize may have been added by the author in an attempt to thwart sandboxes that impose filesize limits on what is saved and/or processed. Finally, the malware copies the original file from the tmp path to the %STARTUP%/winlogon.exe path using the same technique witnessed in version 2. Sysget then writes a batch script in the %TEMP% folder with the following contents, cleaning up the original files and spawning the newly written winlogon.exe executable:

After installation, sysget will attempt to read the same %APPDATA%/vklCen5.tmp file as witnessed in the previous variant. A number of strings within the malware, including the ‘734thfg9ih’ key used to encrypt this file, have been obfuscated via a single-byte XOR of 0x5F.

Similar to previous versions, should this vklCen5.tmp file not be present on the victim machine, it will make an external HTTP request to retrieve the necessary information. The following request is made by the malware. Readers will notice that the URI has changed from previous versions in a number of ways. This version of sysget looks to always make requests to 1.php, which is hardcoded within the malware itself. Additionally, all HTTP URIs in this version of sysget are encrypted. The initial GET request made to retrieve the victim identifier and unique key is encrypted with a key of ‘Cra%hello-12sW’. The subsequent response containing this information is then decrypted using a key of ‘aliado75496’, which is consistent with previous versions.

When the URI above is base64-decoded and subsequently decrypted, we see the following:

index.php?type=read&id=692fdc3c7b2c310fc017e4af335b8dc8&pageinfo=jp&lang=utf-8

This URI is consistent with the previous sysget variant. It would seem the authors simply have added this layer of encryption to hinder efforts to block the malware via network-based detections.

After this initial request to retrieve the victim identifier and unique key, sysget enters its command and control loop. This process is consistent with the previous version, but simply has the extra layer of encryption used for the URIs.

Sysget v4 Analysis

The fourth variant of sysget is nearly identical to the third variant. However, the main difference lies in the URIs used for network communication. In addition to the expected encryption of the URIs, this variant also mangles the base64 encoding that is performed afterwards. The following Python script may be used to de-obfuscate the base64 URI found in this variant:

Additionally, the C2 URI changes in this variant, from 1.php to 5.php

IsSpace Analysis

When initially run, IsSpace will create a unique event to ensure a single instance of the malware is running at a given time. This event name appears to be unique per the sample, as multiple samples contained unique event names. The following event names have been observed in the samples that were analyzed:

  • e6al69MS5iP
  • v485ILa3q5z

IsSpace proceeds to iterate over the running processes on the system, seeking out the following two process substrings:

  • uiSeAgnt
  • avp.exe

The uiSeAgnt string may be related to Trend Micro’s solutions, while avp.exe most likely is related to Kaspersky’s anti-malware product.

In the event uiSeAgnt is identified, the malware will enter its installation routine if not already running as ‘bfsuc.exe’ and proceeds to exit afterwards. Should avp.exe be identified, the malware enters an infinite sleep loop until a mouse click occurs. After this takes place, the malware proceeds as normal.

The malware then determines if it is running under Windows XP. In the event that it is, it will make a HTTP GET request to www.bing.com, presumably to ensure network connectivity.

dragon_9

Figure 9 IsSpace connecting to www.bing.com

If the malware is not running on Windows XP, it will attempt to obtain and decrypt any basic authentication credentials from Internet Explorer. This information is used in subsequent HTTP requests in the event a 407 (Proxy Authentication Required) or 401 (Unauthorized) response code is received during network communication.

IsSpace will then enter its installation routine, where it will first copy itself to the %LOCALAPPDATA% folder with a name of ‘bfsuc.exe’.  It then sets the proper registry key for persistence by executing the following PowerShell command:

The malware then makes an initial HTTP POST request to the configured C2 server. It will make this request to the ‘/news/Senmsip.asp’ URI. The POST data is XORed against a key of “\x35\x8E\x9D\x7A”, which is consistent with previous versions of IsSpace and NFlog. Decrypted, the POST data reads “01234567890”. The C2 server in turn will respond with the victim’s external IP address.

dragon_10

Figure 10 Initial IsSpace beacon

IsSpace then spawns two threads that will make HTTP requests to the following URIs:

  • /news/Sennw.asp?rsv_info=[MAC_ADDRESS]
  • /news/Sentire.asp?rsv_info=[MAC_ADDRESS]

The ‘Sennw.asp’ POST requests that are made contain collected victim information. They, like other information sent across the network, are encrypted using the previously mentioned 4-byte XOR key. When decrypted, we are provided with information such as the following:

The information, delimited via ‘#%#’, is as follows:

Value Description
60-F8-1D-CC-2F-CF MAC address
172.16.95.1 External IP collected previously
172.16.95.186 Internal IP address
WIN-LJLV2NKIOKP Hostname
Win7 Windows version
English(US) Language
2016-12-20 16:27:12 Timestamp
Active Malware status. May also be ‘Sleep’
xp20160628 Potential campaign identifier
IsAdmins / False User admin status

The malware is expected to return one of the following two responses to this HTTP request:

  • Active
  • Slient (Note the typo)

In the event the response of Slient is received, the malware will stop sending out HTTP requests to the ‘Sentire.asp’ URI. Conversely, if the malware is set to the ‘Sleep’ status and the ‘Active’ response is received, it will begin the ‘Sentire.asp’ requests once more.

The requests to ‘Sentire.asp’ act as the main C2 loop, requesting commands from the remote server. The commands are consistent with previously observed instances of IsSpace, however, the URIs have been modified.

Command Description Response URI
CMD Executes command Sentrl.asp
Browse List specified directory Senjb.asp
UploadFile Upload file Sensp.asp
DownLoad Download file Senwhr.asp
DelFile Delete file N/A

DragonOK Indicators

Malicious RTF Documents

020f5692b9989080b328833260e31df7aa4d58c138384262b9d7fb6d221e3673
0d389a7b7dbdfdffcc9b503d0eaf3699f94d7a3135e46c65a4fa0f79ea263b40
52985c6369571793bc547fc9443a96166e372d0960267df298221cd841b69545
785398fedd12935e0ae5ac9c1d188f4868b2dc19fb4c2a13dab0887b8b3e220d
941bcf18f7e841ea35778c971fc968317bee09f93ed314ce40815356a303a3ec
ba6f3581c5bcdbe7f23de2d8034aaf2f6dc0e67ff2cfe6e53cfb4d2007547b30
df9f33892e476458c74a571a9541aebe8f8d18b16278f594a6723f813a147552
925880cc833228999ea06bd37dd2073784ab234ea00c5c4d55f130fe43a0940b
3e4937d06ac86078f96f07117861c734a5fdb5ea307fe7e19ef6458f91c14264
16204cec5731f64be03ea766b75b8997aad14d4eb61b7248aa35fa6b1873398b
64f22de7a1e2726a2c649de133fad2c6ad089236db1006ce3d247c39ee40f578
c3b5503a0a89fd2eae9a77ff92eef69f08d68b963140b0a31721bb4960545e07
d227cf53b29bf0a286e9c4a1e84a7d70b63a3c0ea81a6483fdfabd8fbccd5206
9190b1d3383c68bd0153c926e0ff3716b714eac81f6d125254054b277e3451fe
d321c8005be96a13affeb997b881eaba3e70167a7f0aa5d68eeb4d84520cca02
d38de4250761cb877dfec40344c1642542ca41331af50fa914a9597f8cc0ee9b
5a94e5736ead7ea46dbc95f11a3ca10ae86c8ae381d813975d71feddf14fc07a
bbdc9f02e7844817def006b9bdef1698412efb6e66346454307681134046e595

IsSpace

12d88fbd4960b7caf8d1a4b96868138e67db40d8642a4c21c0279066aae2f429
1a6e3cd2394814a72cdf8db55bc3f781f7e1335b31f77bffc1336f0d11cf23d1

C2 Domains

www.dppline[.]org
www.matrens[.]top

C2 Domains

europe.wikaba[.]com
russiaboy.ssl443[.]org
cool.skywave[.]top

Sysget Version 2

82f028e147471e6f8c8d283dbfaba3f5629eda458d818e1a4ddb8c9337fc0118

C2 Domains

newtw2016.kr44.78host[.]com

Sysget Version 3

02fc713c1b2c607dff4fc6c4797b39e42ee576578f6af97295495b9b172158b9
a0b0a49da119d971fa3cf2f5647ccc9fe7e1ff989ac31dfb4543f0cb269ed105
b49cb2c51bc2cc5e48585b9b0f7dd7ff2599a086a4219708b102890ab3f4daf3
b8f9c1766ccd4557383b6643b060c15545e5f657d87d82310ed1989679dcfac4
d75433833a3a4453fe35aaf57d8699d90d9c4a933a8457f8cc37c86859f62d1e
685076708ace9fda65845e4cbb673fdd6f11488bf0f6fd5216a18d9eaaea1bbc
7fcc86ebca81deab264418f7ae5017a6f79967ccebe8bc866efa14920e4fd909
c5c3e8caffd1d416c1fd8947e60662d82638a3508dbcf95a6c9a2571263bdcef

C2 Domains

gtoimage[.]com
trend.gogolekr[.]com

Additional Indicators

Sysget Version 2

a768d63f8127a8f87ff7fa8a7e4ca1f7e7a88649fe268cf1bd306be9d8069564
2bf737f147e761586df1c421584dba350fd865cb14113eee084f9d673a61ee67
2c7c9fd09a0a783badfb42a491ccec159207ee7f65444088ba8e7c8e617ab5a5
d91439c8faa0c42162ea9a6d3c282d0e76641a31f5f2fbc58315df9c0b90059c
89d8d52c09dc09aeb41b1e9fafeacf1c038912d8c6b75ad4ef556707b15641ff
6c1d56cb16f6342e01f4ebfc063db2244aef16d0a248332348dcdb31244d32f2
9c66232061fbb08088a3b680b4d0bffbbce1ce01d0ce5f0c4d8bf17f42d45682
b138ea2e9b78568ebd9d71c1eb0e31f9cf8bc41cd5919f6522ef498ffcc8762a
8830400c6a6d956309ac9bcbcceee2d27ba8c89f9d89f4484aba7d5680791459
bda66f13202cef8cfb23f36ac0aee5c23f82930e1f38e81ba807f5c4e46128e3
e8197e711018afd25a32dc364a9155c7e2a0c98b3924dc5f67b8cd2df16406ff
e9c0838e2433a86bc2dec56378bd59627d6332ffb1aec252f5117938d00d9f74
c63685b2497e384885e4b4649428d665692e8e6981dad688e8543110174f853b
2c9c2bfea64dd95495703fcec59ad4cf74c43056b40ed96d40db9b919cfd050b
94850525ea9467ae772c657c3b8c72663eaa28b2c995b22a12b09e4cacecad6d
e8bd20e3d8491497ca2d6878b41fb7be67abb97ee272ef8b6735faa6acd67777

C2 Domains

hello.newtaiwan[.]top
bullskingdom[.]com
mail.googleusa[.]top
www.modelinfos[.]com
modelinfos[.]com
www.sanspozone[.]com

Sysget Version 3

f9a1607cdcfd83555d2b3f4f539d3dc301d307e462a999484d7adb1f1eb9edf6
7f286fbc39746aa8feeefc88006bedd83a3176d2235e381354c3ea24fe33d21c
3b554ef43d9f3e70ead605ed38b5e66c0b8c0b9fc8df16997defa8e52824a2a6
8d7406f4d5759574416b8e443dd9d9cd6e24b5e39b1f5bc679e4a1ad54d409c6
edf32cb7aad7ae6f545f7d9f11e14a8899ab0ac51b224ed36cfc0d367daf5785
db19b9062063302d938bae51fe332f49134dc2e1947d980c82e778e9d7ca0616
cde217acb6cfe20948b37b16769164c5f384452e802759eaabcfa1946ea9e18b
9bee4f8674ee067159675f66ca8d940282b55fd1f71b8bc2aa32795fd55cd17e
39539eb972de4e5fe525b3226f679c94476dfc88b2032c70e5d7b66058619075
c45145ca9af7f21fff95c52726ff82595c9845b8e9d0dbf93ffe98b7a6fa8ee9
55325e9fccbdada83279e915e5aeb60d7b117f154fa2c3a38ec686d2552b1ebc
2c7d29da1b5468b49a4aef31eee6757dc5c3627bf2fbfb8e01dec12aed34736a
16dc75cf16d582eac6cbbe67b048a31fffa2fb525a76c5794dad7d751793c410
91eee738f99174461b9a4085ea70ddafc0997790e7e5d6d07704dcbbc72dc8bf
4a702ffbf01913cc3981d9802c075160dfd1beed3ba0681153d17623f781f53f
e8bed52c58759e715d2a00bdb8a69e7e93def8d4f83d95986da21a549f4d51c5
ed5598716de2129915f427065f0a22f425f4087584e1fa176c6de6ad141889d1
adc86af1c03081482fe9ba9d8a8ae875d7217433164d54e40603e422451a2b90
f0540148768247ed001f3894cdfa52d8e40b17d38df0f97e040a49baa3f5c92e
ce38a6e4f15b9986474c5d7c8a6e8b0826330f0135e1da087aae9eab60ea667a
5c4e98922e6981cf2a801674d7e79a573ebcdc9ebc875ef929511f585b9c4781
4880b43ddc8466d910b7b49b6779970c38ce095983cad110fa924b41f249f898
76b6f0359a3380943fece13033b79dc586706b8348a270ac71b589a5fd5790a4
feab16570c11ec713cfa952457502c7edd21643129c846609cb13cdc0ae4671c
ed9ca7c06aac7525da5af3d1806b32eeb1c1d8f14cc31382ca52a14ed62f00a9
a3aa4b3b3471b0bb5b2f61cbc8a94edef4988436e0bc55e9503173c836fb57a3
29ee56ca66187ece41c1525ad27969a4b850a45815057a31acee7cc76e970909
65201380443210518621da9feb45756eac31213a21a81583cc158f8f65d50626
cccb906d06aef1e33d12b8b09c233e575482228d40ac17232acad2557da4e53b

C2 Domains

gtoimage[.]com
trend.gogolekr[.com
www.bestfiles[.]top

Sysget Version 4

2ac8bc678e5fa3e87d34aee06d2cd56ab8e0ed04cd236cc9d4c5e0fa6d303fa3
8dc539e3d37ccd522c594dc7378c32e5b9deeffb37e7a7a5e9a96b9a23df398e

C2 Domains

www.sanseitime[.]com

 

Campaign Evolution: pseudo-Darkleech in 2016

Posted on by Brad Duncan

Darkleech is long-running campaign that uses exploit kits (EKs) to deliver malware. First identified in 2012, this campaign has used different EKs to distribute various types of malware during the past few years. We reviewed the most recent iteration of this campaign in March 2016 after it had settled into a pattern of distributing ransomware. Now dubbed "pseudo-Darkleech," this campaign has undergone significant changes since the last time we examined it. Our blog post today focuses on the evolution of pseudo-Darkleech traffic since March 2016.

Chain of events

Successful infections by the pseudo-Darkleech campaign have generally followed a set sequence of events. This happens regardless of the EK used or the payload delivered. The sequence is:

  • Step 1: Victim host views a compromised website with malicious injected script.
  • Step 2: The injected script generates an HTTP request for an EK landing page.
  • Step 3: The EK landing page determines if the computer has any vulnerable browser-based applications.
  • Step 4: The EK sends an exploit for any vulnerable applications (for example, out-of-date versions of Internet Explorer or Flash player).
  • Step 5: If the exploit is successful, the EK sends a payload and executes it as a background process.
  • Step 6: The victim's host is infected by the malware payload.

In some cases, the pseudo-Darkleech campaign has used a gate between the compromised website and the EK landing page. However, we far more frequently see injected script from the compromised website lead directly to the EK landing page. To get a better idea of the relationship between EKs and campaigns, see our previous blog on EK fundamentals.

fig1

Figure 1: Chain of events for the pseudo-Darkleech campaign.

EKs used by pseudo-Darkleech

The pseudo-Darkleech campaign used Angler EK until that EK disappeared in mid-June 2016. Like many other campaigns, pseudo-Darkleech switched to Neutrino EK after Angler EK disappeared.

Pseudo-Darkleech stayed with Neutrino EK until mid-September 2016. At that point, Neutrino EK ceased operations. The pseudo-Darkleech campaign then switched to Rig EK, and it has stay with Rig since then. We still see indications of a Neutrino EK variant, but at much reduced levels compared to before.

Searching for EK activity in AutoFocus, we saw a significant drop in Neutrino and a corresponding rise in Rig activity starting in mid-September 2016.

fig2

Figure 2: Hits on Neutrino and Rig EK activity in September 2016.

Payloads sent by pseudo-Darkleech

When we last reviewed the pseudo-Darkleech campaign in March 2016, it was delivering TeslaCrypt ransomware. Since that time, pseudo-Darkleech has changed the ransomware payloads it delivers. In April 2016, this campaign switched to CryptXXX ransomware after TeslaCrypt shut down and released its master decryption key. By August 2016, pseudo-Darkleech had switched to a new variant of CryptXXX ransomware dubbed CrypMIC.

By October 2016, pseudo-Darkleech switched to distributing Cerber ransomware, and it has continued sending Cerber as of early December 2016. Below is a summary of EKs and payloads used by the pseudo-Darkleech campaign so far in 2016.

  • Jan 2016: Angler EK to deliver CryptoWall ransomware
  • Feb 2016: Angler EK to deliver TeslaCrypt ransomware
  • Apr 2016: Angler EK to deliver CryptXXX ransomware
  • Jun 2016: Neutrino EK to deliver CryptXXX ransomware
  • Aug 2016: Neutrino EK to deliver CrypMIC ransomware
  • Sep 2016: Rig EK to deliver CrypMIC ransomware
  • Oct 2016: Rig EK to deliver Cerber ransomware

Patterns of injected script

Any EK infection chain almost always starts with injected script from a particular campaign in a page from a compromised website. These pages are from legitimate websites that have been compromised and are being used by the campaign.

When we last examined injected script by the pseudo-Darkleech campaign, it was a large block of heavily-obfuscated text that averaged from 12,000 to 18,000 characters in size. It remained large and obfuscated through June 2016.

fig3

Figure 3: Start of injected pseudo-Darkleech script in page from compromised website in June 2016.

fig4

Figure 4: Middle of injected pseudo-Darkleech script in page from compromised website in June 2016.

fig5

Figure 5: End of injected pseudo-Darkleech script in page from compromised website in June 2016.

But by July 1st 2016, injected pseudo-Darkleech script stopped using obfuscation and became a straight-forward iframe. This iframe has a span value that puts it outside the viewable area of your web browser's window.

fig6

Figure 6: Example of injected pseudo-Darkleech script from July 2016.

The injected script has changed slightly since then, but it remains short and unobfuscated as of early December 2016.

fig7

Figure 7: Example of injected pseudo-Darkleech script from December 2016.

Conclusion

With the recent rise of ransomware, we continue to see different vectors used in both targeted attacks and wide-scale distribution. EKs are one of many attack vectors for ransomware. The pseudo-Darkleech campaign has been a prominent distributer of ransomware through EKs, and we predict this trend will continue into 2017.

Domains, IP addresses, and other indicators associated with this campaign are constantly changing. Customers of Palo Alto Networks are protected from the pseudo-Darkleech campaign through our next-generation security platform, including Traps, our advanced endpoint solution that prevent EKs from compromising a system. We will continue to investigate this campaign, inform the community of our results, and further enhance our threat prevention.

Review of Regional Malware Trends in EMEA: Part 1

Posted on by Alex Hinchliffe

Introduction

As we head towards the end of the year it’s common to reflect on the year almost behind us and to predict what the new year approaching will bring in terms of security challenges. This blog is part of a series that describe malware trends seen in the EMEA (Europe Middle East and Africa) region over the last six months of 2016.

Not long after joining Palo Alto Networks and the Unit 42 Threat Research team I was tasked with authoring and publishing monthly regional threat reports for internal use that focused on the EMEA region using data from our AutoFocus Threat Intelligence Service. The report contents and structure are fluid but some constants exist too, such as tips, take-aways and tools described for readers to learn and act upon to improve their security posture. We are working towards making the reports themselves public, meanwhile, this blog, and future blogs in the series, serve to publish summary information from each of the reports. This blog refers to data extracted from the June and July reports.

EMEA is the largest region on earth in terms of land mass spanning 4 continents from Greenland in the North and West, to the Cape of Good Hope in the South of Africa and as far as Iran in the East but location is pretty much where the commonality ends. The EMEA region is incredibly diverse with more countries than other regions, more languages, arguably more ethnicities and vastly contrasting GDP (Gross Domestic Product) figures as well as population sizes. Despite EMEA accounting for approximately one third of the world’s GDP, per capita, it also includes both the richest and poorest countries. All this amounts to the region being a great place to conduct business however, unfortunately, cyber criminals also believe the same and find it a lucrative market. The malware seen here is not necessarily unique to the region but like the region it is diverse!

Breaking-down the EMEA region into sub-regions is necessary to create digestible threat reports with meaningful data, however even that is not simple due to disparate cybersecurity postures and policies, maturity levels and, indeed, social and economic aspects of each country. That being said, the reports thus far cover segments of the region that are somewhat similar in terms of most of those aspects. For example, the first report covers countries in western Europe with similar GDP (Gross Domestic Product) amount. The second report covers some countries that are located in the Middle East region and are considered as emerging markets.

United Kingdom, Germany and France

These three countries top the GDP list for the EMEA region and thus the European sub-region as well with most of their wealth coming from the services sector.

Highlights:

  • Information stealing Trojans are rife in all three countries most likely due to their large service sectors with companies that store and process customer data.
  • Low-points in malware sessions were around Brexit referendum voting time.
  • Higher than usual H1N1 downloader Trojan activity

trend_1 The United Kingdom had the highest amount of malicious sessions of all three countries, as seen in our next-generation security platform and, as the three-month** trend shows, much of this traffic trend_2

was during April and May, peaking on May 27th. Most of this peak consisted of Locky ransomware campaigns but also included more than one hundred samples in over 7,000 sessions affecting Government and Higher Education.

** The regional threat reports are monthly but often it’s useful to review information and trends especially over a wider period for more context.

trend_3 Germany showed a similar peak to the trend_4

United Kingdom and also consisted mostly of Locky ransomware campaigns. However Germany saw fewer samples but over double the number of sessions. In contrast to the United Kingdom, the majority were seen in the Healthcare and High Tech industries. Locky, like many other variants of ransomware, is victim-agnostic because of the nature of the adversary’s attack and delivery method that uses weaponized documents, containing macros to drop and execute the payload, attached to emails sent out in very large, wide-spread malspam campaigns a la Dridex. The evolution of Locky ransomware since early 2016 has seen various changes not only in the payload behavior but also the distribution methods switching between various Exploit Kits (EKs) and campaigns to infect users browsing compromised websites. Locky is ubiquitous: so much so other cybercriminals have copied its traits, while using their often-recoverable malware to infect and encrypt as if it were Locky, probably to social engineer the victim into a quicker response and payment.

During the spike of Locky-related activity on May 27th just under a quarter of samples seen in the United Kingdom contained a unique feature not present in any samples seen in Germany during the same activity. AutoFocus additionally tagged those samples as having a behavior indicating the malware queried the system BIOS (Basic Input Output System) information during execution in our WildFire™ cloud sandbox. The “BiosDiscovery” tag represents a method commonly used by malware to determine whether running in a virtual machine or not, which could indicate execution in a sandbox environment.

Bolster your defenses:

Locky certainly is a formidable force with its aggressive distribution methods and sheer prevalence, which raises the probability of would be victims getting infected, however there are numerous points during the kill chain or attack lifecycle at which both an exploit delivering Locky or the Locky malware itself can be disrupted preventing its end game of encrypting your data. Interrupting network communications based on source and destination domain names, command & control traffic and unknown TCP; on the end point exploit-related behavior in various applications can be blocked and further methods include detecting DLL and thread injection routines as well as suspicious static file attributes, such as lack of digital signatures.

Malware, including Ransomware, is often distributed by attackers using email but sometimes the method of delivery can differ. Many include the malware as a raw executable file (.EXE, .SCR, .CPL or other file types) as an attachment, which is quite a primitive technique but sadly one that still results in successful infections. Less amateurish are those attackers who obscure their payloads inside other file formats, such as documents containing macros capable of unpacking and executing the executable file embedded inside or downloaded from a remote host; using JavaScript attachments (either directly attached or masquerading inside an archive ZIP attachment) leads to similar results. Some file attachments include exploits capable of exploiting vulnerable applications or systems, or contain URLs pointing to sites hosting Exploit Kits that use more advanced and automated means to deploy the same exploits, however end-point protection with exploit prevention can stop these methods.

trend_5 Based on this information it’s possible to stop many of the low-hanging fruit malware attacks on your network and end-points. Start doing something different tomorrow - Block email file attachments such as document files containing macros, ZIP files containing JavaScript code (or JavaScript full stop,) and other suspicious file types. If you can’t block exclusively, at least reduce who in the company can receive such email attachments to reduce the attack surface.

trend_6 The landscape trend_7in France was a little different over the same time period with the peak volume occurring very early on comparatively. April 7th saw over two hundred samples in more than 27,000 sessions using various applications including email-based and web-browsing, predominately affecting Government, High Tech and Service Provider sectors. Rockloader – an intermediary downloader Trojan – made up most of the malware samples, together with subsequent payloads including Kegotip and Pony Trojans capable of harvesting credentials or other data from victim systems as well as installing further payloads, such as Locky ransomware.

Brexit Disrupts Malware Volume

After 3 months of pretty consistent malware volume, different peak dates and malware campaigns it’s very interesting to note that all three countries had their troughs in the same week, if not the same day, at the at the end of June. No, not early summer holidays for these countries or their attackers, but instead, a very significant political event so-called Brexit (“British Exit”) whereby British citizens voted to leave the European Union during a referendum held on Thursday 23rd June. The decision, which came as a shock to many around the world, became known the day after. This whole event was significant and I strongly believe it was no coincidence that typical traffic patterns were affected. Perhaps attackers were waiting for the media to report the result with predictions for the future, largely revolving around economic uncertainty and Britain slipping back into recession, before launching their “post-Brexit” phishing attacks using topical news, as reported the week after.

In the month of June, PredatorPain, an information stealing Trojan capable of capturing passwords, keystrokes, screenshots and other sensitive information, was extremely prevalent in the United Kingdom. Germany had a mixture of malware each constituting significant volume including Vawtrak, another type of information stealing malware forming a botnet primarily focused on gaining unauthorized access to bank accounts through online banking websites, H1N1, and a single variant of the Andromeda downloader Trojan that alone was the most prevalent sample of the month. France also saw significant volume of the H1N1 Trojan downloader, which is capable of receiving remote commands from a command and control (C2) server in order to download and execute further malicious payloads.

Turkey, Saudi Arabia and United Arab Emirates

These three countries form part of the Middle East region and the emerging markets of the world. Turkey’s economic growth relies primarily on services, much like the European countries in the first regional threat report, however Saudi Arabia and United Arab Emirates (UAE) are extremely reliant on their oil and industrial sectors, although the UAE is diversifying into services and other sectors. The diversity of these countries, not to mention the greater Middle East region, their natural resources and foreign policies makes for a very interesting cyber attack landscape, an example of which, dubbed the OilRig campaign,  describes some targeted attacks, against various industries and countries.

It’s no surprise to learn that all three countries saw Locky campaigns throughout the month of July but also multiple attacks using the LuminosityLinkRAT (Remote Access Trojan) that has many features including an aggressive key logger that injects its code in almost every running process on the system. Once installed the attacker effectively has full control over the victim’s machine with the ability to retrieve user credentials, record web cameras and more.

trend_8trend_9 Saudi Arabia and UAE saw other common malware families not present in Turkey, such as NetWireRAT, which has shown an uptick trend_10the rise trend_11globally   often using Microsoft Excel documents attached to phishing emails that use macros to launch the malicious payload, whereas in Saudi Arabia and UAE, the emails included the executable files directly implying either different actors behind the attacks or an assumption about targets not filtering such file type attachments. Atmos malware – a polymorphic variant of Citadel (which is based on ZeuS) targeting financial and confidential user data is also trending upwards trend_12in these two countries.

Neutrino point-of-sale (PoS) malware was seen in Turkey and UAE during July. Neutrino attempts to scrape credit card information from memory on the infected system. UAE saw one variant of this malware over twenty one SMTP sessions using blank email subject lines and attachment “Payment TT copy with Invoice.exe” primarily affecting the Energy sector.

trend_13

Like the United Kingdom, the PredatorPain information stealing Trojan was present in Turkey in July, however on this occasion the malware was delivered through an exploit in a Rich Text Document (RTF) file taking advantage of a 2012 vulnerability causing a buffer overflow in the ListView / TreeView ActiveX controls present in the MSCOMCTL.OCX library. The fact this exploit was so old proves that attackers will often use such techniques as they are still successful, unfortunately.

Patching systems as a security practice is as critical now as it ever has been, if not more so, given the advancements in Exploit Kits largely automating the exploitation and delivery malware but you can prioritize by focusing on vulnerabilities being used by attackers in the wild, followed by vulnerabilities with known exploits and Proofs of Concept.

After Locky, related downloader malware and PredatorPain, the Pony Trojan was the next most prevalent malware in all three countries. Pony is a popular piece of commodity malware capable of downloading further payloads but also comes equipped with a number of plugins to stealing stored credentials for various file transfer clients, web browsers and email applications. Whilst global trends for this malware were trending down slightly during this time the volume seen in the three countries was consistent and at quite high volume, relatively speaking, with Higher Education and Finance sectors being most affected.

Conclusion

EMEA is a socially and economically diverse region with many interesting assets whether they be citizen data, financial information or natural resources and, as such, is a target for cyber criminals the world over.

It’s interesting to consider that information-stealing malware, such as PredatorPain, is prevalent in countries that have a more service-based economy that manage and process plenty of user data and personally identifiable information (PII).

Some of the other countries analyzed that are more reliant on industrial sectors and natural resources seem to have more cyber attacks using RATs providing full control to remote attackers and use of key-logging technologies to harvest data.

Currently on its fourth iteration the regional threat reports have proved useful and, based on feedback, discussions are now ongoing about releasing publicly and expanding beyond the EMEA region as well, so watch this space so you too can get a better understanding of what's going on in different countries, sub-regions and industry verticals around the world.

Cyber Hygiene

The threat landscape is vast and can be complex but you can minimize your risk of infection and enhance the overall health of your network by following some basic cyber hygiene habits:

Patch systems and applications wherever (and as soon as) possible. Alternatively, focus on other security solutions, such as exploit prevention technology to protect those systems and applications from attack or to help manage patching cycles to suit your requirements. Prioritize patching based on known exploits or in-the-wild-attacks. Segment those unpatched/unpatchable devices in the network with additional access controls based on users or application communication to minimize the risk of exploitation. Perform regular vulnerability scans of systems and review changes to spot new devices or changes in active vulnerabilities.

Change the file association for JavaScript to be opened using notepad (or something else benign) rather than the Windows Scripting Host or other shell capable of executing malcode. This can be done per PC or enterprise-wide using Group Policy.

Educate users and employees of the security risks faced by your organization and perform regular training and reminders about these and how they can help the effort. Provide a platform for users to learn about the risks and to report incidents to security-related staff. Create a culture whereby such reporting is important and valued. Monitor effectiveness of training for the purposes of gap analysis and creating dialogue between security teams and users.

Palo Alto Networks Unit 42 Vulnerability Research December 2016 Disclosures

Posted on by Unit 42

As part of Unit 42’s ongoing threat research, we can now disclose that Palo Alto Networks Unit 42 researchers have reported six vulnerabilities that have been fixed by Apple, Adobe and Microsoft.

This includes two vulnerabilities in Apple WebKit and impacts iCloud for Windows, Safari, iTunes for Windows, tvOS and iOS.

  1. CVE-2016-7639: Tongbo Luo
  2. CVE-2016-7642: Tongbo Luo

This includes three code execution vulnerabilities affecting Adobe Flash (APSB16-39).

  1. CVE-2016-7873: Tao Yan
  2. CVE-2016-7874: Tao Yan
  3. CVE-2016-7871: Tao Yan

And this includes one memory corruption vulnerability affecting Microsoft Office for the Mac (MS16-148):

  1. CVE-2016-7263: Jin Chen

For current customers with a Threat Prevention subscription, Palo Alto Networks has also released IPS signatures providing proactive protection from these vulnerabilities.

Palo Alto Networks is a regular contributor to vulnerability research in Microsoft, Adobe, Apple, Google Android and other ecosystems. By proactively identifying these vulnerabilities, developing protections for our customers, and sharing the information with the security community, we are removing weapons used by attackers to threaten users, and compromise enterprise, government, and service provider networks.

Let It Ride: The Sofacy Group’s DealersChoice Attacks Continue

Posted on by Robert Falcone

Recently, Palo Alto Networks Unit 42 reported on a new exploitation platform that we called “DealersChoice” in use by the Sofacy group (AKA APT28, Fancy Bear, STRONTIUM, Pawn Storm, Sednit).  As outlined in our original posting, the DealersChoice exploitation platform generates malicious RTF documents which in turn use embedded OLE Word documents. These embedded OLE Word documents then contain embedded Adobe Flash (.SWF) files that are designed to exploit Abode Flash vulnerabilities.

At the time of initial reporting, we found two variants:

  1. Variant A: A standalone variant that included Flash exploit code packaged with a payload.
  2. Variant B: A modular variant that loaded exploit code on-demand and appeared non-operational at the time.

Since that time, we have been able to collect additional samples of the weaponized documents that the DealersChoice exploitation platform generates. These latest, additional samples are all Variant B samples. Two of these samples were found to have operational command and control servers which allowed us to collect and analyze additional artifacts associated with the attack.

In late October 2016 Adobe issued Adobe Security Bulletin APSB16-36 to address CVE-2016-7855. In early November 2016 Microsoft issued Microsoft Security Bulletin MS16-135 to address CVE-2016-7255.

Both of these were in response to active exploitation of zero-day vulnerabilities thought by other researchers to be associated with the Sofacy group. Additional reporting as well as our own analysis indicates the exploit code for the Adobe Flash vulnerability CVE-2016-7855 was indeed delivered using DealersChoice. In-house testing also reveals customers of Palo Alto Networks Traps end-point agent are protected by the new exploit code.

Deal Me In: Finding Live C2 Servers

In our previous blog discussing DealersChoice, we identified the steps that Variant B would take once executed on a victim host, but were unable to successfully interact with the command and control (C2) server identified at the time.

We have since discovered two fully operational and active C2 servers (versiontask[.]com and postlkwarn[.]com) that followed the exact steps we outlined in the blog; loading the additional Flash exploit code into memory, following by loading the associated payload also into memory. Figure 1 details the workflow of victim to C2 communications.

dealerschoice2_1

Figure 1 Workflow of DealersChoice

The ActionScript within Variant B will interact with the C2 server, specifically to obtain a malicious SWF file and a payload. This process starts with an initial beacon to the C2 server that contains system information and the victim’s Adobe Flash Player version. Figure 2 shows the beacon sent by the ActionScript to the C2 server.

dealerschoice2_2

Figure 2 Initial beacon from DealersChoice to its C2 server

The C2 responds to the initial beacon with strings that DealersChoice’s ActionScript uses as variables in upcoming actions, such as additional HTTP requests and the decryption of the responses to those requests. Figure 3 shows the C2 server’s response to the beacon, specifically including  k1, k2, k3 and k4 values.

dealerschoice2_3

Figure 3 C2 response to beacon provides DealersChoice tokens and keys needed to decrypt data

The ActionScript then uses the k1 variable from the C2 response data as a token within the HTTP request sent back to the C2 server to obtain the malicious SWF file, as seen in Figure 4.

The C2 server will respond to this request with data that the ActionScript will decrypt using the value of the k3 variable.

The active C2 servers provided Variant B with a malicious SWF file that was the same SWF file found within Variant A samples that exploited CVE-2015-7645 (addressed in October 2016 in Adobe Security Bulletin APSA15-05).

c42a0d50eac9399914090f1edc2bda9ac1079edff4528078549c824c4d023ff9
45a4a376cb7a36f8c7851713c7541cb7e347dafb08980509069a078d3bcb1405

dealerschoice2_4

Figure 4 DealersChoice HTTP request to obtain a malicious SWF file to exploit Adobe Flash Player

After receiving the malicious SWF file, Variant B will then issue an HTTP request using the k2 variable as a token to obtain its payload, as seen in Figure 5. The C2 will respond to this request with data that Variant B will decrypt using the value in the k4 variable as a key. The resulting decrypted data contains shellcode and a payload that the shellcode decrypts and executes.

dealerschoice2_5

Figure 5 DealersChoice HTTP request to obtain shellcode and payload to execute upon successful exploitation

The active C2 servers versiontask[.]com and postlkwarn[.]com provided shellcode that decrypts and executes a payload which in both cases was a loader Trojan that extracts and decrypts an embedded DLL that it saves to the system.

5dd3066a8ee3ab5b380eb7781c85e4253683cd7e3eee1c29013a7a62cd9bef8c fa8b4f64bff799524f6059c3a4ed5d169e9e7ef730f946ac7ad8f173e8294ed8

In both cases, the DLL saved to the system is a variant of Sofacy’s tool that uses the Carberp source code.

82213713cf442716eac3f8c95da8d631aab2072ba44b17dda86873e462e10421 3ff1332a84d615a242a454e5b29f08143b1a89ac9bd7bfaa55ba0c546db10e4b

The two variants of the Seduploader tool share a common C2 domain of apptaskserver[.]com, with differing backup C2 domains of appservicegroup[.]com and joshel[.]com.

Ace in the Hole: Analyzing Victim Fingerprinting

In the process of analyzing Variant B’s active C2 server, we wanted to test our hypothesis that the C2 server would load different exploit code dependent on victim fingerprinting.  We tested this by providing different responses to the C2 server.

First, we issued requests to the C2 server from a VPN located in California, USA and the server did not respond to the requests. We then connected to another VPN located in the Middle East and issued the same requests, at which point the C2 server responded with a malicious SWF and payload. This fact suggests that the Sofacy group uses geolocation to filter out requests that originate from locations that do not coincide with the location of their target.

We then issued several requests to test the C2 and each time the server responded with different k1, k2, k3 and k4 variables, suggesting that the server randomly chooses these values for each inbound request.

To further test the C2 server logic we created requests that contained different values for the operating system and Flash player version. When we sent the HTTP requests to the C2 server with the Adobe Flash Player version set to 23.0.0.185, the most recent Flash version vulnerable to CVE-2016-7855, the server responded with a compressed SWF file (SHA256: c993c1e10299162357196de33e4953ab9ab9e9359fa1aea00d92e97e7d8c5f2c) that exploited that very vulnerability.

Finally, when we issued requests to the C2 server indicating the victim was a macOS system, the C2 server served the same malicious SWF file and Windows payload as before, suggesting that the Sofacy group is not using DealersChoice to check operating system type for its victims at this time.

In all cases the payload delivered by the C2 server is a loader Trojan (SHA256: 3bb47f37e16d09a7b9ba718d93cfe4d5ebbaecd254486d5192057c77c4a25363) that installs a variant of Seduploader (SHA256: 4cbb0e3601242732d3ea7c89b4c0fd1074fae4a6d20e5f3afc3bc153b6968d6e), which uses a C2 server of akamaisoftupdate[.]com.

Show Your Hand: Decoy Documents

Six documents were collected for this wave of DealersChoice attacks, all appearing to be Variant B, using similar lures to what we had observed in the previous wave. The six filenames we discovered were:

  • Operation_in_Mosul.rtf – an article about Turkish troops in Mosul
  • NASAMS.doc – a document that is a copy of an article regarding the purchase of a Norwegian missile defense system by the Lithuanian Ministry of National Defence
  • Programm_Details.doc – a document that is a copy of the schedule of a cyber threat intelligence conference in London, targeting a Ministry of Defense of a country in Europe
  • DGI2017.doc – a document targeted at a Ministry of Foreign Affairs of a Central Asian country regarding the agenda for the Defence Geospatial Intelligence gathering in London
  • Olympic-Agenda-2020-20-20-Recommendations.doc – a document containing details of agreements for the 2020 Olympics
  • ARM-NATO_ENGLISH_30_NOV_2016.doc – a document outlining an agreement between the Republic of Armenia and NATO

dealerschoice_figure_6

Figure 6. Collected decoy documents for current wave of attacks

Unlike the first DealersChoice attacks, these documents used stripped out or forged metadata in order to add in an additional layer of obfuscation. Two of the documents, NASAMS.doc and Programm_Details.doc shared a common, unique username pain in the Last Saved By field. Additionally, each of the weaponized documents continued to use the OfficeTestSideloading technique we had previously reported on. This was the technique we had discovered the Sofacy group began using over this past summer as a way to sideload DLL files using a performance test module built into the Microsoft Office suite as well as maintain persistence on the victim host.

Filename Author Last Saved By Subject SHA256
Operation_in_Mosul.rtf Robert Tasevski ---- Turkish troops in Mosul f5d3e827…
NASAMS.doc Антон Гладнишки pain Norwegian missile defense system 1f81609d…
Programm_Details.doc Laci Bonivart pain Conference schedule 1579c7a1…
DGI2017.doc Невена Гамизов Невена Гамизов Conference schedule c5a389fa…
Olympic-Agenda-2020-20-20-Recommendations.doc admin User Recommendations for 2020 Olympics 13718586…
ARM-NATO_ENGLISH_30_NOV_2016.doc User User NATO agreement 73ea2cce…

 

The six first-stage C2 domains for the weaponized documents were all registered by unique registrant emails. Versiontask[.]com and Uniquecorpind[.]com appear to be completely new infrastructure, not sharing any artifacts with previously observed Sofacy group campaigns.

Type Domain Date Registered Registrant Email
First stage C2 Versiontask[.]com 2016-10-24 dalchi0@europe.com
First stage C2 Uniquecorpind[.]com 2016-10-25 yasiner@myself.com
First stage C2 Securityprotectingcorp[.]com 2016-08-19 ottis.davis@openmailbox.org
First stage C2 Postlkwarn[.]com 2016-11-11 fradblec@centrum.cz
First stage C2 adobeupgradeflash[.]com 2016-11-22 nuevomensaje@centrum.cz
First stage C2 globalresearching[.]org 2016-11-18 carroz.g@mail.com

Six second stage C2 domains for the Seduploader payloads delivered by DealersChoice were identified.

Type Domain Date Registered Registrant Email
Seduploader C2 Joshel[.]com 2016-11-11 germsuz86@centrum.cz
Seduploader C2 Appservicegroup[.]com 2016-10-19 olivier_servgr@mail.com
Seduploader C2 Apptaskserver[.]com 2016-10-22 partanencomp@mail.com
Seduploader C2 Akamaisoftupdate[.]com 2016-10-26 mahuudd@centrum.cz
Seduploader C2 globaltechresearch[.]org 2016-11-21 morata_al@mail.com
Seduploader C2 researchcontinental[.]org 2016-12-02 Sinkholed

Much like the first stage C2 domains, the five non-sinkholed second stage C2 domains were registered recently and used unique registrant email addresses previously unused by the Sofacy group. However, each of these domains used nameservers commonly associated with the Sofacy group, ns*.carbon2u[.]com and ns*.ititch[.]com. The domain akamaisoftupdate[.]com revealed additional artifacts linking it back to previous Sofacy group campaigns. Based off passive DNS data, we discovered akamaisoftupdate[.]com resolving to 89.45.67.20. On the same class C subnet, we discovered 89.45.67.189, which previously had resolved to updmanager[.]net, a well reported domain in use by the Sofacy group.

The domain securityprotectingcorp[.]com was also found to have links to previous Sofacy group infrastructure. It was registered a couple of months prior, but analysis of the registrant email address revealed that it had also been used to register microsoftsecurepolicy[.]org, which using passive DNS data we found had resolved to 40.112.210.240, a sinkhole with several other Sofacy group associated domains. Several of the corresponding sinkholed domains have been used over the years for multiple purposes by the Sofacy group, as C2s for multiple tools such as Azzy or XAgent, or to host phishing sites to gather credentials from targets.

dealerschoice2_7

Figure 7 Chart of DealersChoice infrastructure

Conclusion

It appears evident at this time that the Sofacy group is actively using the DealersChoice tool, specifically the Variant B, to attack targets of interest. As evidenced by the delivery of exploit code for a recently patched  vulnerability in Flash (which was used in zero-day attacks), we can see how the malware provides flexibility in exploitation methodology and is truly a platform in itself. New infrastructure does appear to have been created for DealersChoice, but as we have seen in the past, the Sofacy group has a tendency to reuse artifacts from previous campaigns and this is no exception. Palo Alto Networks customers may learn more and are protected via:

Note that even though CVE-2016-7855 was a zero-day vulnerability, Palo Alto Networks customers would have been protected by our Traps endpoint agent as seen in Figure 8.

dealerschoice2_8

Figure 8 Palo Alto Networks Traps blocking exploitation of the CVE-2016-7855 vulnerability

Indicators of Compromise

Document Hashes:

f5d3e827c3a312d018ef4fcbfc7cb5205c9e827391bfe6eab697cc96412d938e
1f81609d9bbdc7f1d2c8846dcfc4292b3e2642301d9c59130f58e21abb0001be
1579c7a1e42f9e1857a4d1ac966a195a010e1f3d714d68c598a64d1c83aa36e4
c5a389fa702a4223aa2c2318f38d5fe6eba68c645bc0c41c3d8b6f935eab3f64
137185866649888b7b5b6554d6d5789f7b510acd7aff3070ac55e2250eb88dab
73ea2ccec2cbf22d524f55b101d324d89077e5718922c6734fef95787121ff22

DealersChoice C2s:

Versiontask[.]com
Uniquecorpind[.]com
Securityprotectingcorp[.]com
postlkwarn[.]com
adobeupgradeflash[.]com
researchcontinental[.]org

Seduploader C2s:

Appservicegroup[.]com
Apptaskserver[.]com
Akamaisoftupdate[.]com
Joshel[.]com
globaltechresearch[.]org
researchcontinental[.]org

SamSa Ransomware Attacks: A Year in Review

Posted on by Josh Grunzweig

In March of this year, Unit 42 investigated the SamSa actors that were attacking the healthcare industry with targeted ransomware. With this group being active for roughly one year, we decided to revisit this threat to determine what, if any, changes had been made to their toolset. In doing so, we discovered that it’s been a very profitable year for SamSa, with an estimated $450,000 in ransom payments from samples we have identified. This blog serves to discuss changes made by this group and the SamSa malware family since we last discussed them.

Updates to Malware Toolset

In the past 12 months, Unit 42 has collected and analyzed 60 unique samples that have been identified as belonging to the SamSa malware family. SamSa has a very small number of samples overall when compared to more common ransomware families such as Locky, Cerber, and CryptoMix. This is simply a byproduct of the targeted nature of SamSa, which targets specific organizations instead of a wide number of Internet users.

During the past 12 months, a number of changes were made by the authors to make analysis and reverse-engineering more difficult. While we classify all of these samples as “SamSa,” the attackers have used various names to identify their projects. The following chart shows the various internal .NET project names used by SamSa from December 2015 until November of 2016.

samsa_1

Figure 1 Versions of SamSa Ransomware over time

The following list of internal .NET project names were witnessed, in order:

  • samsam
  • MIKOPONI
  • RikiRafael
  • showmehowto
  • wanadoesme
  • wanadoesme2
  • gonomore
  • gotohelldr
  • WinDir

The majority of the name changes took place after April of this year. When discussing changes made internally to the code base, we witnessed the following events since we last discussed SamSa:

samsa_2

Figure 2 SamSa modifications over time

  1. A number of internal .NET name changes, starting with RikiRafael.
  2. A number of changes to the encrypted filename extensions used after encryption took place.
  3. Changes to the format of the encrypted file header.
  4. Modifications to the dropped helper HTML file that informs the victim of what has occurred.
  5. Different temporary folder names used to hold SamSa while it is running.
  6. Encryption of embedded strings using the AES-128 algorithm.
  7. Internal PDB debug strings obfuscated.
  8. Internal PDB debug strings removed altogether.

Profits

When we originally discussed SamSa, there were confirmed profits of $70,000 for the threat actors, with estimates by other researchers as high as $115,000. Unlike most ransomware, SamSa ransomware executables often contain the Bitcoin Wallet address victims are supposed to use to pay the ransom. Since March 24th 2016, we’ve witnessed 24 unique SamSa samples containing 19 unique Bitcoin (BTC) addresses. This allows us to monitor the blockchain for transfers to those wallets and identify ransom payments.  In one unusual case, we saw a version of SamSa where the BTC address was input as a second argument, preventing us from seeing what payment, if any, was received by the actors. This not only makes tracking monetary payments extremely difficult, but also is yet another example of how the SamSa actors take a very targeted approach to their victims, generating unique data for each victim they infect.

Of those 19 unique BTC addresses we observed since March 24th, 14 of these have received payments totaling roughly 394 BTC. Prior to March 24, 2016, we observed roughly 213 BTC received, giving us a total of 607 BTC received by the SamSa actors. Using today’s current BTC rate of $744.43, this allows us to estimate that the attackers have obtained roughly $450,000 since their operations began. It’s important to also note that there are likely a number of samples that exist, which we were unable to obtain, causing the actual figure to likely be much higher. A visual of the money obtained by the SamSa actors can be seen in the following figure:

samsa_3

Figure 3 SamSa BTC profits over time

As we can see, there is a large gap in between June and September of 2016. This is most likely due to the sample set used during research, as there were only a few samples obtained in recent months.

Conclusion

In the past year, the SamSa actors have showed no sign in stopping their attacks. They’ve successfully compromised a number of organizations, and continue to reap significant rewards for their efforts. In the past year alone, they’ve collected an estimated $450,000 from their scam. As the group continues to make money, it is unlikely we shall see them stop in the near future. Palo Alto Networks customers are protected from this threat via the following ways:

  1. All malware is classified as malicious in WildFire.
  2. Domains used by SamSa have been flagged as malicious in Threat Prevention.
  3. AutoFocus users can track this family using the SamSa tag.

A full list of indicators of compromise (IOCs) related to SamSa can be found here.

Shamoon 2: Return of the Disttrack Wiper

Posted on by Robert Falcone

In August 2012, an attack campaign known as Shamoon targeted a Saudi Arabian energy company to deliver a malware called Disttrack. Disttrack is a multipurpose tool that exhibits worm-like behavior by attempting to spread to other systems on a local network using stolen administrator credentials. More importantly, its claim to fame is the ability to destroy data and to render infected systems unusable. The attack four years ago resulted in 30,000 or more systems being damaged.

Last week, Unit 42 came across new Disttrack samples that appear to have been used in an updated attack campaign. The attack targeted at least one organization in Saudi Arabia, which aligns with the targeting of the initial Shamoon attacks. It appears the purpose of the new Disttrack samples were solely focused on destruction, as the samples were configured with a non-operational C2 server to report to and were set to begin wiping data exactly on 2016/11/17 20:45. In another similarity to Shamoon, this is the end of the work week in Saudi Arabia (their work week is from Sunday to Thursdays), so the malware had potentially the entire weekend to spread.  The 2012 Shamoon attacks took place on Lailat al Qadr, the holiest night of the year for Muslims; another time the attackers could be reasonably certain employees would not be at work.

Composition of Disttrack

Disttrack is comprised of three distinct parts: the dropper, communications and wiper components. The main Disttrack executable is a dropper that extracts additional tools from embedded resources and coordinates when to save and execute them. Embedded within each Disttrack sample is a component responsible for communicating with a C2 server and a separate component used to carry out the wiping functionality.

The dropper extracts the communications and wiper components from resources named "PKCS7" and "PKCS12" respectively, while the x86 sample extracts the x64 variant of Disttrack from a resource named “X509”. To extract the components, the dropper is configured to seek specific offsets within the resource, read a specified number of bytes and decrypt the contents using a specified key. The key exists in the sample as a base64 encoded string that the dropper will decode then use each byte of the resulting string to XOR the data obtained from the resource. When determining the location of the ciphertext within the resource, the dropper subtracts 14 from the offset value in the sample's configuration as an additional layer of obfuscation. Table 1 shows the resources within the Disttrack x86 sample, the component it contains and the values needed to decrypt its contents.

Component Resource Name Offset Size Base64 key
x64 Variant X509 812 -14 = 798 717312 5tGLQqku0m02...
Communications PKCS7 879 -14 = 865 159744 UPi0IzQOAyiL...
Wiper PKCS12 792 -14 = 778 282112 3Lmqr/nJgzFZ7...

Table 1 Resources containing Disttrack components

Disttrack Functionality

Disttrack is mainly focused on data destruction and attempting to damage as many systems as possible. To do so, this malware attempts to spread to other systems on network using what are likely stolen administrator credentials. This is again similar to the 2012 Shamoon attacks, where compromised but legitimate credentials obtained in advance of the attacks were also hard coded into the malware to aid in its propagation. Disttrack also has the ability to download and execute additional applications to the system, as well as remotely set the date to start wiping systems.

Local Network Spreading

The Disttrack malware spreads to other systems automatically using stolen credentials. The Disttrack we analyzed contained the internal domain names and administrator credentials associated with the targeted organization. The internal domain and credentials appear to be stolen prior to the creation of this tool, as it is not a public domain and the credentials are not weak enough to have obtained through guessing, brute force or dictionary attacks.

Disttrack uses the internal domain names and credentials to log into remote systems on the same network segment. The malware determines the local network segment associated with the target system (call to gethostname) by obtaining the IP address for the system (call to gethostbyname). It then uses the system's IP addresses to enumerate the /24 network (x.x.x.0-255) that the system is networked with, and will attempt to spread to each of these remote systems.

The dropper then attempts to open the service manager on each remote system to start the RemoteRegistry service, which it will connect to using RegConnectRegistryW. Once connected, the dropper attempts to disable UAC (User Access Control) remote restrictions by setting the following registry key to a value of "1":

SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy

After disabling UAC, the dropper connects to the remote system (using NetUseAdd) and logs in using the embedded stolen credentials. The dropper then checks to see if it has administrator privileges on the remote system by attempting to open "\system32\csrss.exe", which allows it to determine if it can write its payload to the "\system32" folder on the remote system. The dropper then has two different methods in which it can pivot to the remote system.

The first method involves the dropper writing itself to "\system32\ntssrvr32.exe" on the remote system. After writing itself to the remote system, the dropper creates a service named "ntssrv", with a display name of "Microsoft Network Realtime Inspection Service" and a description of "Helps guard against time change attempts targeting known and newly discovered vulnerabilities in network time protocols" to execute the payload.

The second, alternative method also involves the dropper copying itself to "\system32\ntssrvr32.exe" on the remote system; however, instead of creating a remote service, this method calls the NetScheduleJobAdd function within the Windows netapi32 library to create a scheduled task to run the payload. Scheduled tasks require a time in which the task will run, which the dropper determines by calling the function NetRemoteTOD to obtain the time of day from the remote system. The dropper then adds 90 seconds to the time of day value on the remote system and uses this value as the "JobTime" to run the task in three minutes, which executes the payload on the remote system. The following pseudo-code shows the scheduled task creation process:

C2 Communications

Disttrack extracts the communication component from its resource named “PKCS7”, decrypts it and saves the resulting cleartext to the file %WINDOWS%\system32\netinit.exe.

The communication module interacts with its C2 server using HTTP requests. The communications modules in both the x86 and x64 variants of Disttrack we analyzed were configured to use “1.1.1.1:8080” for its C2 server, which does not host an operational Disttrack C2 server. The lack of an operational C2 server suggests that the threat actors did not desire remote access to infected systems, rather the actors sought to render them unusable instead. If the modules were configured with an operational C2 server,  the module would generate an HTTP GET request that resembles the following:

shamoon_1

The interesting part of the request above is that the host "server", the URL "category/page.php", the parameter "shinu" and the user-agent "Mozilla/5.0 (MSIE 7.1; Windows NT 6.0)" are hardcoded into the tool. The data in "shinu" parameter is a combination of the system's tickcount, local IP address, operating system version, keyboard layout and the contents of %WINDOWS%\inf\netimm173.pnf. The C2 server can respond to this HTTP request with one of the following two commands:

Command Description
E Provides an executable to run on the system. The executable is saved to %TEMP%\Temp\filer\<tickcount>.exe
T Sets the time to start wiping the system, by writing the date to %WINDOWS%\inf\usbvideo324.pnf.

We believe the HTTP host value of "server" and the non-operational "1.1.1.1" C2 address may suggest that the communication module is created with a builder tool, which in this case the actor mistakenly or purposefully did not provide an active C2 server when building this module. While completely speculative, the word “shinu” used as a parameter could be a reference to the Arabic slang for the word “what”, as well as a reference to a village name in northwestern Iran.

Disttrack Data Destruction

The Disttrack dropper is responsible for installing the wiper component of this Trojan, however, it will only activate this component if the system time is greater than a preset date. The dropper obtains a date used to activate the wiping functionality by reading a specific file, or using a hardcoded timestamp of "2016/11/17 20:45". The file containing this timestamp is named "\inf\usbvideo324.pnf", which is not initially installed but is provided by the C2 server if it sends the communications module the "T" command. The "usbvideo324.pnf" file would have the following structure:

BYTE year;
BYTE month;
BYTE day;
BYTE hour;
BYTE year;
BYTE minute;

If the dropper determines the system date is larger than the specified date, the dropper will extract the wiper component from a resource named "PKCS12" and save it to the "system32" folder with one of the following filenames appended with a ".exe" extension:

  • caclsrv
  • certutl
  • clean
  • ctrl
  • dfrag
  • dnslookup
  • dvdquery
  • event
  • findfile
  • gpget
  • ipsecure
  • iissrv
  • msinit
  • ntfrsutil
  • ntdsutl
  • power
  • rdsadmin
  • regsys
  • sigver
  • routeman
  • rrasrv
  • sacses
  • sfmsc
  • smbinit
  • wcscript
  • ntnw
  • netx
  • fsutl
  • extract

The dropper then runs the wiper component with a command line argument of "1". The wiper component extracts a driver from its resource section and decrypts it with a 226 byte XOR key. The wiper saves the extracted driver to "C:\Windows\System32\Drivers\drdisk.sys" and installs the kernel driver by creating a service named "drdisk" with the following command line commands:

The kernel driver is a commercial product that the attackers are abusing called RawDisk by EldoS Corporation, which provides direct access to files, disks and partitions. It appears that the “drdisk.sys” driver (SHA256: 4744df6ac02ff0a3f9ad0bf47b15854bbebb73c936dd02f7c79293a2828406f6) is the exact same driver as used in the Shamoon attack in 2012. With the kernel driver installed, the wiper can begin writing to protected system locations, such as the master boot record (MBR) and partition tables of storage volumes. The wiper can be configured to overwrite files in three different ways, specified by a configuration setting of "F", "R" or "E". If configured with the "F" setting, the wiper loads a resource named AJKEOA, which extracts a JPEG image to use to overwrite files and partition tables. If the wiper is configured with the "E" setting, the wiper will encrypt the contents of the file using a random value as a key and the RC4 algorithm. If configured with the "R" setting, the wiper will overwrite files with the random values that would be used as a key in "E".

The sample we analyzed was configured with "F", meaning it would overwrite files with an image obtained from its resource section. The image extracted is a picture of a Syrian boy named Alan Kurdi, whose drowning on September 2, 2015 received international attention in regards to the ongoing Syrian refugee crisis. The previous Shamoon attack in 2012 used an image of a burning American flag, continuing the political image theme.

From a functionality standpoint, the wiper relies on EldoS' RawDisk driver to overwrite files on the system. During this activity, we noticed the wiper changing the system time to August 2012, as the temporary license key for the RawDisk driver requires the system time to not exceed the month of August, which is when the temporary license would expire. This modification to the system time was seen in the previous campaign, and the temporary license key within the wiper component is the exact same as wiper component from the 2012 attacks. The wiper itself queries the following registry keys to obtain a list of partitions to overwrite:

In addition to these partitions, the wiper attempts to overwrite files and subfolders within in the following folders:

After overwriting these files and the partition tables, the wiper issues the following command to restart the system:

The arguments and switches used in the “shutdown” command above forces all running applications to close and causes the system to reboot (‘-r’) after 2 seconds (‘-t 2’). This command does result in a dialog prompt, seen in Figure 1, that informs the user that the system is shutting down.

shamoon_2

Figure 1 Dialog prompt displayed when the Wiper component runs the 'shutdown' command

With the partition tables overwritten, the system will no longer be able to properly boot, which renders the system unusable. During analysis, our analysis system was rendered unusable, as the virtual machine was unable to find the operating system during boot up, as seen in Figure 2.

shamoon_3

Figure 2 Analysis virtual machine unable to boot after executing Disttrack Wiper

Conclusion

After a four year hiatus, threat actors likely associated with the Shamoon attack campaign have used their Disttrack malware to target at least one organization in Saudi Arabia. The current attack campaign has several TTP overlaps with the original Shamoon campaign, especially from a targeting and timing perspective. Also, Disttrack malware used in the recent attacks is very similar to the variant used in the 2012 attacks, which uses the exact same RawDisk device driver as well (down to the same, temporary license key).. The main purpose of the Disttrack malware is to overwrite files and storage partitions in an attempt to destroy data and render the system unusable. To maximize its destruction, the Disttrack tool attempts to spread to other systems on the network using stolen administrator credentials, which suggests that the threat actors had previous access to the network or carried out successful phishing attacks prior to the attack using Disttrack.

Palo Alto Networks customers are protected from Disttrack:

  • All known samples have a malicious verdict in WildFire
  • AutoFocus customers can monitor Disttrack activity via the Disttrack tag

Indicators of Compromise

Disttrack Droppers

47bb36cd2832a18b5ae951cf5a7d44fba6d8f5dca0a372392d40f51d1fe1ac34 (x64)
394a7ebad5dfc13d6c75945a61063470dc3b68f7a207613b79ef000e1990909b
(x86)

Communication Components

772ceedbc2cacf7b16ae967de310350e42aa47e5cef19f4423220d41501d86a5 (x64)
61c1c8fc8b268127751ac565ed4abd6bdab8d2d0f2ff6074291b2d54b0228842 (x86)

Wiper Components

c7fc1f9c2bed748b50a599ee2fa609eb7c9ddaeb9cd16633ba0d10cf66891d8a (x64)

128fa5815c6fee68463b18051c1a1ccdf28c599ce321691686b1efa4838a2acd (x86)

EldoS RawDisk Samples

5a826b4fa10891cf63aae832fc645ce680a483b915c608ca26cedbb173b1b80a (x64)
4744df6ac02ff0a3f9ad0bf47b15854bbebb73c936dd02f7c79293a2828406f6 (x86)

PluginPhantom: New Android Trojan Abuses “DroidPlugin” Framework

Posted on by elegance

Recently, we discovered a new Google Android Trojan named “PluginPhantom”, which steals many types of user information including: files, location data, contacts and Wi-Fi information. It also takes pictures, captures screenshots, records audios, intercepts and sends SMS messages. In addition, it can log the keyboard input by the Android accessibility service, acting as a keylogger.

PluginPhantom is a new class of Google Android Trojan: it is the first to use updating and to evade static detection. It does this by leveraging the Android plugin technology. It abuses the legitimate and popular open source framework “DroidPlugin”, which allows an app to dynamically launch any apps as plugins without installing them in the system. PluginPhantom implements each element of malicious functionality as a plugin, and utilizes a host app to control the plugins. With the new architecture, PluginPhantom achieves more flexibility to update its modules without reinstalling apps. PluginPhantom also gains the ability to evade the static detection by hiding malicious behaviors in plugins. Since the plugin development pattern is generic and the plugin SDK can be easily embedded, the plugin architecture could be a trend among Android malware in the future.

Evolution of PluginPhantom

We believe PluginPhantom is a successor to the Android Trojan “Android.Trojan.Ihide”, which was discovered by TrustLook in July of 2016, since they share the same certificate and package name. PluginPhantom not only includes and improved all malicious functionalities from “Android.Trojan.Ihide”, but also adopts a very innovative design architecture. In the new architecture, the original malware app is divided into multiple apps (plugin apps) and a single app (a host app). The host app embeds all plugin apps in resources, which implement different functional modules. After victims install the host app, it can directly load and launch plugin apps without installing plugin apps, by abusing the legitimate open source plugin framework – DroidPlugin [2].

1. Introduction of DroidPlugin:

DroidPlugin is an innovative application-level virtualization/proxy framework, which was originally developed for purposes of hot patching, reducing the released APK size, and removing the 65535 methods limitation. The popular application scenario of DroidPlugin is launching multiple instances of apps on the same device (e.g. using multi-accounts in social apps). Fundamentally, DroidPlugin is very different from the widely known dynamic code loading (e.g. loading a dex or jar file), since it can directly load and launch an app from its APK file without installation. There are five basic concepts or mechanisms in the implementation of DroidPlugin:

  • Shared UID. All plugin apps share the same UID with the host app.
  • Pre-defined stub components and permissions. The host app has pre-defined components and permissions for plugin apps.
  • Dynamic Proxy Hook. The host app has hooked API invocations of plugin apps by the dynamic proxy technique, so that the Android system thinks that all API requests and components are from the host app.
  • Resource loading. As the plugin app is not installed in the system, so the host app must take over the process of loading app resources in the plugin app process.
  • Component Lifecycle Management. When the component in the plugin process is ready to be destroyed, the corresponding stub component should also be destroyed simultaneously.

2. Plugin Design of PluginPhantom:

In the plugin design architecture, PluginPhantom has one host app (i.e. the malicious APK we captured) and nine plugin apps that are embedded in the host app as assets files.  In these nine plugins, there exists 3 core plugins (“task”, “update” and “online”) and six additional plugins (“file”, “location”, “contact”, “camera”, “radio” and “wifi”), shown in Figure 1.

phantom_1

Figure 1 Plugin Architecture of PluginPhantom

The host app, as the controller and the entry point of PluginPhantom, schedules plugin apps by launching them and sending commands. In the initialization stage, the host app loads nine APK files in asset files and installs them as plugins in the DroidPlugin framework. Then, the host app can launch and communicate with plugins the same way it would with normal Apps installed on Android.

The online plugin, connects to the command and control (C2) server to upload device information (e.g. the screen state, the battery volume and the free RAM size) and retrieve commands to execute. The online plugin firstly finishes a “ThrowOut” step to probe the remote server by sending the “UUID” (from “java.util.UUID.randomUUID()”) in a UDP socket.  If the “UUID” is sent successfully, then, the online plugin continues to utilize the WebSocket to pull the command data from the server.

The task plugin, fetches the command data through the bridge of the host app. According to different command types, the task plugin forwards commands to six additional plugins to launch different attacks. The task plugin also uploads stolen data to the remote server through the WebSocket. In addition, the task plugin launches the update plugin to download new plugin APK files and update plugins, if it receives the “update” command type. Once the update plugin finishes downloading plugins, the task plugin sends a message to the host app to reload and relaunch plugins.

3. IPC and Data Sharing in PluginPhantom:

In the DroidPlugin framework, the host app and all plugin apps share different PIDs, but same UID. Thus, the IPC between the host app and plugin apps or among plugin apps is same as the IPC mechanism in the Android system. The IPC in PluginPhantom includes the Intent and AIDL. The host app can launch all plugin apps by starting the entry service of plugin apps with an Intent. In particular, to keep plugin services alive, the host app uses the alarm manager to restart the entry service of plugin apps in an interval. In addition, AIDL is used for IPC between the host app and plugin apps.  For example, “AbsAidl” is used by the task plugin to send commands to the host app for hooking keyboard inputs. The update plugin uses “ClientAidl”, “InfoAidl” and “PluginAidl” to synchronize the updated plugin information with the host app.

Even though the Intent and AIDL can share parts of data, PluginPhantom mainly uses the Content Provider and the file system to share data between the task plugin and six additional plugins. For example, the radio plugin gets commands from the task plugin by the URI “content://***.task.cntPrv/Command”, and stores the command response and recorded audio file paths into the URI “content://***.task.cntPrv/CmdRespond” and “content://***.task.cntPrv/CmdRespondFile” respectively.  Later, the task plugin parses last two content providers, and then reads and uploads recorded audio files from the external storage path “/sdcard/AndroidMedia/.audio/record”.

Stealing Information through Plugins

1. File Plugin

The file plugin scans a specific directory and retrieves information (e.g. file name, file type, file size, create time, edit time, file path, canonical path and read state), from the files inside it. It also scans media files in the external storage and can download and delete specific files.  During the file operation, the root privilege is used by the file plugin if necessary. In existing samples, PluginPhantom is trying to use the root privilege, but does not root the device. If the attacker wanted root access on the device, they could use the C2 channel to install an APK which exploits an unpatched local root vulnerability, but we have not yet observed this occur with PluginPhantom infections.

2. Location Plugin

The location plugin obtains both fine-grained and coarse-grained location information. It converts coordinates in the Android default geographic coordinate system to coordinates in two other coordinate systems, which are used by Baidu Maps and Amap Maps, the top two navigation apps in China.  To successfully obtain the location, the plugin can enable WIFI, GPS (under Android 4.4) and mobile data (under or in Android 5.0) options.

3. Contact Plugin

The contact plugin intercepts incoming SMS and phone calls for specific numbers received from the remote server. To avoid detection, it turns off the ringtone and phone screen and deletes call logs when SMS and phone calls are coming in. The contact plugin also steals call logs, device IDs and contacts info (including deleted contacts) in both the phone contact list and the SIM card contact list. Additionally, it sends SMS messages to specific numbers, which is finished after checking the current phone bill balance.

4. Camera Plugin

The camera plugin takes pictures in the background through either the front or the back camera. It uses a surface view with 0.1*0.1 size for camera previewing, and a full screen Activity with the transparent theme and no title, so victims may be not aware of this behavior. It also takes screen shots by the command “screencap –p” if it has obtained root privileges on the device.

5. Radio Plugin

The radio plugin records the audio in the background with two trigger conditions: commands from the remote server and incoming/outgoing phone calls. To avoid detection, it doesn’t record audio if other apps are also recording.

6. WIFI Plugin

The WIFI plugin steals WIFI information (e.g. SSID, password, IP address, mac address), software information (e.g. app name, version, last update time, is system app), running process information (e.g. PID, process name, app name, app resource path, app data path, timestamp), and trace information (e.g.  browser visiting history and bookmarks).

Stealing Keyboard Inputs through Accessibility in the Host App

In the host app, a developer defined service named “AutoService” extends the “AccessibilityService” to hook all GUI events in the system (Figure 2). First it needs to trick users into enabling the accessibility permission to this app using it’s description shown in Figure 3, which pretends describes a fake “memory cleaning service.”

phantom_2

Figure 2 Accessibility Service for hooking

phantom_3

Figure 3 Lure users to enable the accessibility service

The host app uses the Android Accessibility feature to hook and operate on the specific Activity and package by referring the class name and package name, for two purposes:

1. Grant or activate if a GUI dialog asks for authorizations. If the text of a clickable button matches keywords in “this.b” (Figure 4), or the text of a checkbox matches keywords “Don’t show this again” in “this.c” (Figure 4), the app will automatically click the button or the checkbox.

2. Record the keyboard inputs for specific apps.  PluginPhantom logs user inputs, such as the text and window id, for all leaf nodes in the UI tree (Figure 5). Thus, the victims’ inputs in the EditText element can be logged. Note that password inputs cannot be logged. The text of password EditText node is always empty since the password attribute of this node is true.

phantom_4

Figure 4 Matched keywords for clicking

phantom_5

Figure 5 Log the text and window id of the UI node

Conclusion

While the Android plugin technology is very hot in the Android app development, it also gives a chance to malware developers to redesign malware in a more flexible way. Like the PluginPhantom family, malware can easily update or add modules by updating or installing plugin apps. In terms of evasion, the plugin malware can hide all malicious behaviors in plugin apps, which can be downloaded and launched to bypass static detection. Additionally, the plugin technology might be a replacement of the repackage technique in the future. The plugin malware only needs to launch the original app as one plugin, and later launch malicious modules as other plugins. Even though the PluginPhantom is the first malware using the legitimate DroidPlugin framework, we will continue to watch and report this threat as attackers may use other plugin frameworks and launch more attacks.

Customers of Palo Alto Networks are protected with our WildFire, URL filtering and IPS services. AutoFocus users can identify samples of this malware using the PluginPhantom tag.

Acknowledgments

We greatly appreciate the help from Zhi Xu, Claud Xiao, Xin Ouyang, Ryan Olson and others from Palo Alto Networks in working on the analysis of PluginPhantom family.

Sample Hashes

002e568047074093ca43153b806fb29ec60bcf1b3040487f8ec727ace1209316
1f739108dc2a6520ad736249cd8ed0dbc674e59e687337005b3fa3ab52956bb2
1fe181823dbab09aee5cc72b83822977c64ec17cdbf739f5e6edf9b2f5697d11
8255149b6d3ffaa029c6302659aec00d17418fefc5cde9572fbf23bb996d9fde
91f7d9663d259b0c57619bbdd73fb763b6567cce0c1ae05542d8f55644e12d20
92b6a68ea66c73d5d05dff7d8d290ea8ba242846b05d6d4e2e477eb662944cac
b642b9de56218696cf5fe7f47aa914bfe3fec22a754d68c03e0e8d130efbb14f
d56f9157d5b9aabd01bc0476c1a5e5e398a90c75efb9da37f0f7fcaf61b896b8
e4977499171b475e8fd450477574b36b8d1bf0af62a5782fb77c702bcf4fb408

C2 Domains and URLs

1519j010g4[.]iok[.]la
58[.]222.39.215:8088/dmrcandroid/ws/httpsData/command

Tropic Trooper Targets Taiwanese Government and Fossil Fuel Provider With Poison Ivy

Posted on by Vicky Ray

Taiwan has been a regular target of cyber espionage threat actors for a number of years. Reasons for Taiwan being targeted range from being one of the sovereign states of the disputed South China Sea region to its emerging economy and growth with Taiwan being one of the most innovative countries in the High-Tech industry in Asia.

In early August, Unit 42 identified two attacks using similar techniques. The more interesting one was a targeted attack towards the Secretary General of Taiwan's Government office – Executive Yuan. The Executive Yuan has several individual boards which are formed to enforce different executing functions of the government. The Executive Yuan Council evaluates statutory and budgetary bills and bills concerning martial law, amnesty, declaration of war, conclusion of peace and treaties, and other important affairs. Given the important functions undertaken by the Executive Yuan office, it is not a surprise that they were targeted. The second attack was against an energy sector company also located in Taiwan.

The attacks in this case are associated with a campaign called Tropic Trooper, which has been active since at least 2011 and is known for heavily targeting Taiwan. One of the attacks used their known Yahoyah malware, but the other attack deployed the widely available Poison Ivy RAT.  This confirms the actors are using Poison Ivy as part of their toolkit, something speculated in the original Trend Micro report but not confirmed by them. Further analysis uncovered a handful of ties indicating the actors may also be using the PCShare malware family, which has not been previously tied to the group.

Figure 1 shows the spear phishing email which was sent to the Secretary General of Executive Yuan. The email is spoofed so that it appears as though it was sent from a staff member at the Democratic Progressive Party (DPP).

tropictrooper_1

Figure 1. Spear-phishing email with malicious attachment.

The document attached to this e-mail exploits CVE-2012-0158, a Microsoft Office vulnerability. This process is described in the Malware Analysis section later in this report, but one interesting aspect of this malicious was the decoy document the attacker chose to deploy.

Decoy Document

As we have noted in many earlier reports, attackers commonly use decoy files to trick victims into thinking a malicious document is actually legitimate. After infecting the computer, the display a clean document to the victim that contains content that is relevant to them.

The decoy document used in this case is a spreadsheet with four tabs, respectively titled “example,” “0720,” “0721,” and “1041109 full update”. All of the text uses Traditional Chinese, in contrast to Simplified Chinese, which is the official written language of the People's Republic of China. Traditional Chinese is used in Taiwan, Hong Kong, Macau, and many overseas Chinese communities.  The overarching theme of the spreadsheet is documenting protestor activity and/or progressive reform attempts in progress across Taiwan and the tone of the spreadsheet suggests it was compiled by progressive supporters. Because we were unable to find the spreadsheet online, and there is specific persona data included related to these movements and protests, we are not including any screen shots except for the one below.

tropictrooper_2

Figure 2. The four tabs in the decoy spreadsheet.

The “example” spreadsheet tab is exactly as described – it contains the headers and suggested information within two of the remaining three tabs. The headers themselves translate, from left to right, to “responsible department,” “issue,” “developments this week,” “political situation judgment,” and “related information.”  The tab labeled 0721 only has the matching headers and no additional information.  None of the information in the spreadsheet relates to activities past 2015, and there are references made to the then upcoming January 16, 2016 elections in Taiwan. In that election the DPP won, displacing the Chinese Nationalist Party (KMT) for only the second time in history, and with Taiwan’s first female President.

The spreadsheet labeled 0720 refers to the Anti-Black Box Movement, which was a protest by Taiwanese high school students against certain proposed curriculum changes. The use of “black box” by the protestors is in reference to former Taiwanese President Ma Ying-Jeou’s government and its lack of transparency concerning government decisions. Protestors occupied Taiwan’s Ministry of Education last July. A resolution passed by Taiwan’s legislature and approved by the Executive Yuan in May of this year delayed implementing that curriculum until 2020 to allow time for the act to be amended.

The Anti-Black Box Movement is related to the Sunflower Student Movement, a coalition of both student groups and other civic organizations that protested the Cross-Strait Trade Agreement between Taiwan and the PRC, feeling it would hurt Taiwan’s economy and increase the PRC’s sway over the island.  On March 17 2014, the KMT, the ruling party at the time, tried to force a vote without a previously agreed clause by clause review with the DPP. The following evening protesters occupied the Legislative Yuan, the first time that had occurred Taiwan’s history. On March 23 of the same year, after then President Ma re-affirmed he supported the pact and would not alter or drop it, protestors occupied the Executive Yuan where over 150 were injured and 61 arrested.

The final tab contains the most information of the three and has different headers. From left to right, the headers are titled “responsible person(s),” “summary of issues and major groups,” “crisis simulation, political judgment, and recommendations,” “degree of tension,” and “participating members.”

  • Information related to the November 2015 "Autumn Struggle" protest, which is an annual protest first done in 2013.
  • Information on a Taichung City government development proposal being protested largely on environmental impact grounds, and protestor demands.
  • Army 1st Special Forces veterans attempt to receive compensation for alleged illegal extension of forced military service
  • The recently settled case where toll workers forced into unemployment by the Taiwanese government’s agreement with the Far Eastern Electronic Toll Collection Company to create a national electronic toll collection system ended up resulting in the 2013 layoffs of hundreds, who have since protested for new jobs as well as lost severance and pension.
  • Kaohsiung refinery closing and protestor demands, also largely related to environmental effects and necessary cleanup; the refinery officially closed at the end of December 2015
  • Closely watching any trade agreements between the Malaysian government and Taiwan
  • Potential environmental and current residential issues related to the development of the Aerotropolis around Taoyuan International Airport, which is intended to create a major transportation hub and industry center for Asia with infrastructure for corporate research and development, conference centers, and other facilities.
  • The Puyu Development Plan, which is part of Taiwan’s Knowledge-based Economy plan
  • Taiwan’s 12-year compulsory education plan
  • Anti-Black Box Movement demands and recent activity
  • Improving working conditions for Taiwanese firefighters
  • Pension reforms
  • The Nest Movement, which started in 2014 and is related to the older “Shell-less Snail Movement,” focused on affordable housing, neighborhood and urban development, ending forced demolition and relocation, property tax reform, and related housing issues
  • The Environmental Impact Assessment (EIA) voted on by the Environmental Protection Bureau (EPB) for the Dongshi-Fengyuan Expressway, part of the National Highway #4 Project and anti-eviction efforts
  • Kaohsiung water quality issues and related projects
  • Same sex marriage legalization
  • Protecting old trees in Kaohsiung amidst construction for a new “green” library; most of the designated “precious trees” are rare exotic species
  • Indigenous peoples in Kaohsiung land return
  • Activities against the Miramar Resort Village, including the revocation of the EIA, forcing development to halt
  • Lowering the voting age in Taiwan from 20 to 18

Malware Analysis

The documents attached to spear-phishing e-mails used in both attacks contain code that exploits CVE-2012-0158, which despite its age remains one of the most common Microsoft Word vulnerabilities being exploited by multiple threat actors. This matches with known Tactics, Techniques, and Procedures (TTPs) for Tropic Trooper, targeting both government institutions and also the energy industry in Taiwan.

The delivery document uses the XLSX extension typically used by OpenXML documents, but the file itself is actually an OLE (XLS) document. The file extension to file type discrepancy was caused by the actor using Excel's built-in encryption capability, which stores XLSX ciphertext and the information needed for decryption in an OLE document.

Filename: 進步議題工作圈議題控管表.xlsx
MD5: a89b1ce793f41f3c35396b054dbdb749
SHA1: f45e2342e40100b770d73dd06f5d9b79bfce4a72
SHA256: 2baa76c9aa3834548d82a36e150d329e3268417b3f12b8f72d209d51bbacf671
Type: CDF V2 Document, No summary info
Size: 327128 bytes

Table 1. Details of the malicious document attached to the e-mail.

The embedded shellcode enumerates open handles for a file with a size greater than 0xa6f0 (Decimal - 42736) bytes. It will then set the file pointer to 0xa6e8 (Decimal - 42728) and starts looking for the following delimiter:

GfCv\xef\xfe\xec\xce

If it finds this delimiter, the shellcode knows it is working with the correct file and continues by reading 0x600 (decimal 1536) bytes following this delimiter. The shellcode then decrypts the first 0xc0 (decimal 192) DWORDs of the data read from the file using an XOR algorithm that decrypts one DWORD of ciphertext at a time with 0x29f7c592. The resulting cleartext is a second piece of shellcode that continues carrying out further functionality.

The secondary shellcode starts by resolving the following API functions using a ROT13 hashing algorithm:

kernel32.dll!CreateFileA
kernel32.dll!ReadFile
kernel32.dll!WriteFile
kernel32.dll!SetFilePointer
kernel32.dll!CopyFileA
kernel32.dll!MoveFileExA
kernel32.dll!CreateToolhelp32Snapshot
kernel32.dll!Process32Next
kernel32.dll!CloseHandle
kernel32.dll!VirtualAlloc
kernel32.dll!WinExec
kernel32.dll!TerminateProcess
kernel32.dll!LoadLibraryA
kernel32.dll!lstrlenA
kernel32.dll!lstrcpyA
kernel32.dll!lstrcatA
kernel32.dll!GetTempPathA
kernel32.dll!WideCharToMultiByte
kernel32.dll!QueryDosDeviceA
ntdll.dll!NtQueryObject
advapi32.dll!RegOpenKeyA
advapi32.dll!RegSetValueExA
advapi32.dll!RegCloseKey

Immediately following these API functions there are three DWORDS; one used to locate the payload embedded within the exploit file, one for the size of the payload, and one for the size of decoy document. The two size values are added together to get the length of the ciphertext that the shellcode will decrypt. In the sample we analyzed, the following values were present, showing that the payload is at offset 0xabc0 and has a size of 0x45218:

DWORD offset_toPayload; (0ABC0h)
DWORD payload_Size; (1C600h)
DWORD decoy_Size; (28C18h)

The shellcode then creates a string that it uses to create a registry key to automatically run the final payload each time the system starts. It then opens the registry key 'Software\Microsoft\Windows NT\CurrentVersion\Winlogon' and sets the value to the "Shell" subkey to the previously created string. Ultimately, the following registry key is created for persistence:

HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell:
"explorer.exe,rundll32.exe "C:\Documents and Settings\Administrator\Application
Data\Identities\Identities.ocx" SSSS"

It then uses the "offset_toPayload" value as an offset that it will read 283160 (45218h) bytes from the XLS file. The shellcode then enters a decryption loop to convert the embedded payload from ciphertext to cleartext. The algorithm uses the length of the ciphertext negated as the initial encryption key, which it bit rotates right by 1 to adjust the key for each of decryption. It will use this key to decrypt four bytes of the ciphertext with the XOR operation until all the ciphertext is decrypted. During each iteration of the decryption process, the algorithm will check to make sure the four bytes of ciphertext are not equal to the key or equal to zero before decrypting the ciphertext.  The following table contains the first five rounds of the algorithm to explain the decryption process:

 Key Ciphertext  Cleartext
0  ~0x45218 = 0xFFFBADE8 >> 1 = 0x7FFDD6F4  0x7F6D8CB9  0x00905a4d = MZ\x90\x00
1  0x7FFDD6F4 >> 1 = 0x3FFEEB7A  0x3FFEEB79  0x03 = \x03\x00\x00\x00
2  0x3FFEEB7A >> 1 = 0x1FFF75BD  0x1FFF75B9  0x04 = \x04\x00\x00\x00
3  0x1FFF75BD >> 1 = 0x8FFFBADE  0x8FFF4521  0xFFFF = \xff\xff\x00\x00
4  0x8FFFBADE >> 1 = 0x47FFDD6F  0x47FFDDD7  0xB8 = \xb8\x00\x00\x00
5  0x47FFDD6F >> 1 = 0xA3FFEEB7  0x00000000  0x00000000 = \x00\x00\x00\x00
6  0xA3FFEEB7 >> 1 = 0xD1FFF75B  0xD1FFF71B  0x40 = \x40\x00\x00\x00
7  0xD1FFF75B >> 1 = 0xE8FFFBAD  0x00000000  0x00000000 = \x00\x00\x00\x00
8  0xE8FFFBAD >> 1 = 0xF47FFDD6  0x00000000  0x00000000 = \x00\x00\x00\x00
9  0xF47FFDD6 >> 1 = 0x7A3FFEEB  0x00000000  0x00000000 = \x00\x00\x00\x00
10  0x7A3FFEEB >> 1 = 0xBD1FFF75  0x00000000  0x00000000 = \x00\x00\x00\x00
11  0xBD1FFF75 >> 1 = 0xDE8FFFBA  0x00000000  0x00000000 = \x00\x00\x00\x00
12  0xDE8FFFBA >> 1 = 0x6F47FFDD  0x00000000  0x00000000 = \x00\x00\x00\x00
13  0x6F47FFDD >> 1 = 0xB7A3FFEE  0x00000000  0x00000000 = \x00\x00\x00\x00
14  0xB7A3FFEE >> 1 = 0x5BD1FFF7  0x00000000  0x00000000 = \x00\x00\x00\x00
15  0x5BD1FFF7 >> 1 = 0xADE8FFFB  0xADE8FEF3  0x108 = \x08\x01\x00\x00
16  0xADE8FFFB >> 1 = 0xD6F47FFD  0xD84E60F3  0xEBA1F0E = \x0e\x1f\xba\x0e
17  0xD6F47FFD >> 1 = 0xEB7A3FFE  0x26738BFE  0xCD09B400 = \x00\xb4\x09\xcd
18  0xEB7A3FFE >> 1 = 0x75BD1FFF  0x39BCA7DE  0x4C01B821 = \x21\xb8\x01\x4c
19  0x75BD1FFF >> 1 = 0xBADE8FFF  0xD28AAE32  0x685421CD = \xcd!Th
20  0xBADE8FFF >> 1 = 0xDD6F47FF  0xAD4F3496  0x70207369 = is p
21  0xDD6F47FF >> 1 = 0xEEB7A3FF  0x9CD0CC8D  0x72676F72 = rogr
22  0xEEB7A3FF >> 1 = 0xF75BD1FF  0x947BBC9E  0x63206D61 = am c
23  0xF75BD1FF >> 1 = 0xFBADE8FF  0x94C3869E  0x6F6E6E61 = anno
24  0xFBADE8FF >> 1 = 0xFDD6F47F  0x98B4D40B  0x65622074 = t be
25  0xFDD6F47F >> 1 = 0xFEEB7A3F  0x909E081F  0x6E757220 =  run

Table 2.  Decrypting the payload

As you can see from the table above, the algorithm decrypts what is an embedded portable executable that acts as the payload in this attack. The embedded payload is written to %APPDATA\Identities\Identities.ocx and has the following attributes:

The decoy document, described in the section above, is saved to %TEMP%\進步議題工作圈議題控管表.xlsx and has the following attributes:

The shellcode will move the decoy document to the location of the originally executed XLSX file and will create the following command:

cmd /c start excel /e  “<path to original XLSX file, now decoy
document>”

Before running the above command to open the decoy document, the shellcode enumerates the running processes on the system, specifically looking for processes created for an executable with a filename that starts with “avp.”, presumably in an attempt to find Kaspersky’s antivirus process. If the process is found, the shellcode will not open the decoy document and exits.

The shellcode does not launch the payload, rather it relies on the registry key it created for persistence to execute the payload when the user reboots the system, meaning during dynamic analysis the execution of the payload may be missed.

Delivered Payload – Poison Ivy

When the system starts up, the persistence registry key will launch the Identities.ocx payload and call its “SSSS” exported function. The “SSSS” function checks to make sure that the DLL is running within the context of a “rundll32.exe” process and then begins piecing 0x141B bytes of data together in the correct order to build the shellcode of the Poison Ivy Trojan.

We found and parsed the following configuration from the Poison Ivy shellcode:

Looking for more samples which exhibited the same file structure, encryption and obfuscation to deliver the above Poison Ivy sample yielded only two additional samples. In the other two instances the delivered payloads were respectively PCShare and Yahoyah.  PCShare has not been previously associated with Tropic Trooper, but in addition to the aforementioned overlaps, the two samples have passive DNS overlap with some known Tropic Trooper infrastructure. For those reasons, we assess with limited confidence the group is also using this malware family.

tropictrooper_3

Figure 3. The limited ties between C2 infrastructure used by Yahoyah samples (top) and PCShare malware samples (bottom).

The below table shows the details of the documents, payload delivered and the C2 servers used for communications.

SHA256 a3becf3639fa82bfbf01740ce5a8335f291fb83b544e02a6cc9f1e9c96fb3764
Filename CTC Statement.xlsx
Payload d76d7d64c941713d4faaedd5c972558c5136cd1b7de237280faaae89143e7d94
Tool PCShare
C2 belindianlab[.]itemdb[.]com
C2 IP 210.108.146[.]20
SHA256 ca10489091b71b14f2c3dc0b5201825e63a1f64c0a859ba2bd95900f45580fc4
Filename 全台餐廳更新版餐廳_.xlsx
Payload bff5f2f84efc450b10f1a66064ed3afaf740c844c15af88a927c46a0b2146498
Tool Yahoyah
C2 www[.]dpponline[.]trickip[.]org
C2 www[.]myinfo[.]ocry[.]com
C2 IP 223.27.35[.]244

 

It is interesting to see that the exploit documents we found had either low or no detections on most popular antivirus engines, showing that the threat actors behind this campaign have been having considerable success in bypassing static analysis undertaken by traditional antivirus solutions with this technique.

We further expanded our search using the AutoFocus Threat Intelligence platform on the IOCs extracted from the PIVY, PCShare and Yahoyah payloads and found 42 samples which either matched unique behaviors, the unique PIVY mutex or had common C2 infrastructure.  The hashes of all the samples found are given in the appendix section at the end of this blog.

Figure 4 below shows the compilation timestamps of the payload samples found using AutoFocus. Given some of the payloads that were used in recent attacks, which were compiled months before, it shows that the threat actor group continues to reuse the payload within their exploit documents.

tropictrooper_4

Figure 4. Payload Compilation Timelines

The below Maltego graph shows some of the shared infrastructure which have been used by Tropic Trooper. The complete list of indicators on the graph can also be found in the appendix section of this report.

 

tropictrooper_5

Figure 5 Maltego graph of Tropic Trooper infrastructure

Conclusion

The Tropic Trooper threat actor group has been known to target governments and organizations in the Asia Pacific region for at least six years. In addition to using Yahoyah malware, we were able to confirm they are also using Poison Ivy and possibly PCShare malware families.  They are also still exploiting CVE 2012-0158, as are many threat actors. Palo Alto Networks customers are protected from Tropic Trooper’s malicious activities by:

  • WildFire correctly identifies all related malware as malicious
  • The C2 infrastructure are classified as malicious in PAN-DB
  • Traps prevents exploitation of CVE-2012-0158

Autofocus customers can discover additional information on Tropic Trooper via the following AutoFocus tags:

Appendix

Samples matching unique indicators, behaviors and C2 infrastructure from the payload extracted out of the malicious documents:

SHA256 hashes
Winsloader
c098235a43d9788661490d2c7b09b1b2b3544d22ee8d9ae6cd5d16a977fd1155
e81bc530075d6d31358aea5784d977d1ac2932a13a615cd1319d01d6e39c2995
cf32fb6371cc751b852c2e2e607c813e0de71cd7bcf3892a9a23b57dfd38d6fc
07663f8bca3c2118f3f77221c35873fd8dd61d9afa30e566fe4b51bcfb000834
92da05bae1d9694a1f63b854e86b5b17ef27d5fc2551318e49e17677c7c90042
e267ecfd37f3af55e8b02b081e7c9d8c0bf633e1d5acb0228be694eae4660eee
PCShare
d76d7d64c941713d4faaedd5c972558c5136cd1b7de237280faaae89143e7d94
66d672a94f21e86655f243877ee04d7e67a515a7153891563f1aeedb2edbe579
Yahoyah
85904e7b88b5049fb99b4b8456d9f01bdbf8f6fcf0f77943aed1ce7e6f7127c2
2fce75daea5fdaafba376a86c59d5bc3e32f7fe5e735ec1e1811971910bc4009
aa812b1c0b24435b8e01100760bc4fef44032b4b0d787a8cf9aef83abd9d5dbd
9623d6f3a3952280f3e83f8dbb29942694bb682296d36c4f4d1d7414a7493db0
f0aa64c1646d91b0decbe4d4e6a7cc53bfd770c86ded9a7408034fa14d2bad83
73bba13d1c7b6794be485a5eeb7b79a62f109c27c4c698601945702303dbcd6c
25809242472a9e1f08ff83c00fae943a630867604ff95c7a57313187287384d2
72d14f0a7ecb04eb2962bc9d8491194deb856ceebf30e7ecd644620932f3d4b0
2172cc228760d6e4fa297bc485637a2b17103ae88237b30df39babe548cefaa5
fdeb384ff68b99514f329eeffb05692c4c1580ca52e43e6dcbb5d760c2a78aa4
1432a8a6ae6faa5d9f441b918ddc3edddb9c133458853ad356756835fe7b3291
a4334a33e4a87cfa52e9e24f6b4d3da0b686f71b25e5cc9a6f144485ea63108a
7f8abefcc4598c643dff1ebf570677fd5c2a4f3d08bc8ddabbfbef1eed097fb3
8e1a0d93ae644ac80048e5c3485bc6282a69d52cf26f94d2be1ce634851ac3aa
c2ad0204ff90c113f7984a9db6006c9f09631c4983098803591170be62cdfaa7
8ccaade84c9c7d5955e8aa1a0d36542beeaed5b8f619aedf82f74e8fd5a5283b
03e9c25fe979f149f6dafb0398cdf3d2223b26f24009ef0f83825b60e961d111
bee4cc2c3c393953f9247eab45767e01cd26d40037fb00bd69441e026d860a63
626f65d4d638437aaa8352fe06589165d52a91e0963c988348b00734b0a3419f
5395f709ef1ca64c57be367f9795b66b5775b6e73f57089386a85925cc0ec596
72cc8c41008310024e9339b9e45bec7815b7fa8a0c3b6a56769d22bc4ced10ed
fefd9bfb0f984590b54908c6868b39ca587a3e0d8198b795ff58f67adee4b9e9
4ee115734733dae0705e5b2cb6789a1cdb877bc53e2fdb6e18ab845c0522d43b
6b6ec318ede71baf79004fe22c46a8d7a500dc6ba6dd40b2641fe9a1c2b3dbd5
78eda231bf494c7008a4ad49e982f2470597199829d46b166a75f654e3cb8d59
21857cdd794649d72ab1bf90acfa8a57767a2a176b46cdb930025cf9242303bb
bff5f2f84efc450b10f1a66064ed3afaf740c844c15af88a927c46a0b2146498
6597c49bedf3fb1964e7f6ccbb03db9e38a5903a671209ae4d3fb4f9f4db4c95
 
Poison Ivy
6966e511a45e42a9cfa32799dd3ecf9ec1c2cf62ed491f872210334a26e8a533
84f9d3c0895fbcc3148ec77b967eb9cdf33eb90915937b91a61664d36eed7464
c4b73d2102c25e31e3b73a8547a0120e1d3706eed96392acb174ecbf1218fa37
c9d0d7e3ba9a1369b670511966f2c3b5fa3618d3b8ac99cbc3a732bd13501b99
ee3f29d2a68217825666dae6a56ae7ee96297ea7f88ae4fd78819983ae67a3ce
edfedfad21bd37b890d0e21c3c832ff9493612f9959a32d6406750b2d4a93697
 

 

C2 domains
news[.]hpc[.]tw
www[.]dpponline[.]trickip[.]org
www[.]forensic[.]zyns[.]com
www[.]bannered[.]4dq[.]com
www[.]forensic611[.]3-a[.]net
bbs[.]zzbooks[.]net
bbs[.]ccdog[.]net
wallstreet[.]1dumb[.]com
www[.]cham[.]com[.]tw
pinkker[.]zzux[.]com
www[.]amberisic611[.]4dq[.]com
www[.]metacu[.]ygto[.]com
bbs[.]zzbook[.]net
www[.]myinfo[.]ocry[.]com
www[.]gmal1[.]com
news[.]hpc[.]tw
www[.]dpponline[.]trickip[.]org
pinkker[.]zzux[.]com
wallstreet[.]1dumb[.]com
redpeach[.]youdontcare[.]com
redapple[.]justdied[.]com
stone[.]mypop3[.]org
zeus[.]jkub[.]com
sniper[.]mynumber[.]org
unclesam[.]jungleheart[.]com
arora[.]x24hr[.]com
flanando[.]fartit[.]com
www[.]dpponline[.]trickip[.]org
www[.]myinfo[.]ocry[.]com
belindianlab[.]itemdb[.]com
kr[.]dns1[.]us

 

C2 HTTP requests
hxxp://www[.]dpponline[.]trickip[.]org/images/D2015_id[.]jpg
hxxp://223[.]27[.]35[.]244/images/D2015_id[.]jpg
hxxp://www[.]myinfo[.]ocry[.]com/images/D2015_id[.]jpg
hxxp://belindianlab[.]itemdb[.]com/1613986301|C7A5398FBD8214C92F6596CC39B8866B0121E53422D6B8378E5D1F5F63844D693810BDED362511ED3630DC4F6A2B1302354C31242753DACB331EF3CF808E4E107B12F103F0C040F87DAA6CAB0676A25EBC673D9DFA078915F93361308E10BB5BA7DF1A90FEB614F1A1F12C7A135B60926A5D49FCE025F577FE0DEE937C803BE27D
hxxp://202[.]153[.]193[.]73/images/kong[.]24[.]jpg
hxxp://113[.]10[.]221[.]89/images/kong[.]24[.]jpg
hxxp://61[.]221[.]169[.]31/images/kongj[.]24[.]jpg
hxxp://www[.]forensic611[.]3-a[.]net/monitor/images/Smarp140102[.]24[.]gif
hxxp://www[.]bannered[.]4dq[.]com/monitor/images/Smarp140102[.]24[.]gif
hxxp://www[.]forensic[.]zyns[.]com/monitor/images/Smarp140102[.]24[.]gif
hxxp://113[.]10[.]221[.]89/Pictures/sbsb_0620[.]24[.]jpg
hxxp://bbs[.]ccdog[.]net/Pictures/sbsb_0620[.]24[.]jpg
hxxp://www[.]forensic611[.]3-a[.]net/monitor/images/Smartzh131225[.]24[.]gif
hxxp://www[.]bannered[.]4dq[.]com/monitor/images/Smartzh131225[.]24[.]gif
hxxp://www[.]forensic[.]zyns[.]com/monitor/images/Smartzh131225[.]24[.]gif
hxxp://bbs[.]zzbooks[.]net/Pictures/lclc_0523[.]24[.]jpg
hxxp://bbs[.]ccdog[.]net/Pictures/lclc_0523[.]24[.]jpg
hxxp://113[.]10[.]221[.]89/Pictures/lclc_0523[.]24[.]jpg
hxxp://50[.]117[.]38[.]164/Pictures/dzh_0925[.]24[.]jpg
hxxp://www[.]cham[.]com[.]tw/images/dzh_0925[.]24[.]jpg
hxxp://113[.]10[.]221[.]89/Pictures/dzh_0925[.]24[.]jpg
hxxp://bbs[.]ccdog[.]net/Pictures/jpg_140430[.]24[.]jpg
hxxp://198[.]100[.]122[.]66/Pictures/jpg_140430[.]24[.]jpg
hxxp://192[.]69[.]221[.]92/Pictures/jpg_140430[.]24[.]jpg
hxxp://www[.]bannered[.]4dq[.]com/monitor/images/SmartNav141216[.]64[.]gif
hxxp://www[.]amberisic611[.]4dq[.]com/monitor/images/SmartNav141216[.]64[.]gif
hxxp://www[.]metacu[.]ygto[.]com/monitor/images/SmartNav141216[.]64[.]gif
hxxp://www[.]metacu[.]ygto[.]com/monitor/images/SmartNav141216[.]32[.]gif
hxxp://www[.]amberisic611[.]4dq[.]com/monitor/images/SmartNav141216[.]32[.]gif
hxxp://www[.]bannered[.]4dq[.]com/monitor/images/SmartNav141216[.]32[.]gif
hxxp://bbs[.]ccdog[.]net/Pictures/20150120-hex[.]64[.]jpg
hxxp://23[.]27[.]112[.]216/Pictures/20150120-hex[.]64[.]jpg
hxxp://bbs[.]zzbook[.]net/Pictures/20150120-hex[.]64[.]jpg
hxxp://bbs[.]zzbook[.]net/Pictures/20150120-hex[.]32[.]jpg
hxxp://23[.]27[.]112[.]216/Pictures/20150120-hex[.]32[.]jpg
hxxp://bbs[.]ccdog[.]net/Pictures/20150120-hex[.]32[.]jpg
hxxp://bbs[.]ccdog[.]net/Pictures/h20141212012[.]64[.]jpg
hxxp://23[.]27[.]112[.]216/Pictures/h20141212012[.]32[.]jpg
hxxp://113[.]10[.]221[.]89/Pictures/h20141212012[.]32[.]jpg
hxxp://bbs[.]ccdog[.]net/Pictures/h20141212012[.]32[.]jpg
hxxp://113[.]10[.]221[.]89/Pictures/ooba_0823[.]24[.]jpg
hxxp://198[.]100[.]122[.]66/Pictures/ooba_0823[.]24[.]jpg
hxxp://50[.]117[.]38[.]164/Pictures/ooba_0823[.]24[.]jpg
hxxp://www[.]metacu[.]ygto[.]com/monitor/images/SmartNav0120[.]64[.]gif
hxxp://www[.]amberisic611[.]4dq[.]com/monitor/images/SmartNav0120[.]64[.]gif
hxxp://www[.]bannered[.]4dq[.]com/moitor/images/SmartNav0120[.]64[.]gif
hxxp://www[.]bannered[.]4dq[.]com/moitor/images/SmartNav0120[.]32[.]gif
hxxp://www[.]metacu[.]ygto[.]com/monitor/images/SmartNav0120[.]32[.]gif
hxxp://www[.]amberisic611[.]4dq[.]com/monitor/images/SmartNav0120[.]32[.]gif
hxxp://www[.]dpponline[.]trickip[.]org/images/D2015_id[.]jpg
hxxp://223[.]27[.]35[.]244/images/D2015_id[.]jpg
hxxp://www[.]myinfo[.]ocry[.]com/images/D2015_id[.]jpg
hxxp://49[.]254[.]211[.]75//tedws/1[.]64[.]jpg
hxxp://107[.]183[.]183[.]235/public/1[.]64[.]jpg
hxxp://49[.]254[.]211[.]75//tedws/1[.]32[.]jpg
hxxp://107[.]183[.]183[.]235/public/1[.]32[.]jpg
hxxp://flanando[.]fartit[.]com/2015/p1[.]64[.]jpg
hxxp://flanando[.]fartit[.]com/2015/p1[.]32[.]jpg
Get the latest news, invites to events, and threat alerts

Default Heading

Read the article Right Arrow