How To Detect That Hadoop/YARN DemonBot Exploit That's Going Around

There's a new bot in town that exploits Hadoop YARN's REST API in a way that enables unauthenticated remote code execution (RCE). Radware reported on October 25th that a bot called "DemonBot" (can we stop with these names yet?), has been detected exploiting this RCE capability to co-opt Hadoop clusters into massive new botnets.

A Little Background on DemonBot (Hat Tip to Radware)

Here's a quote from the Radware post about how it works:

YARN, Yet Another Resource Negotiator, is a prerequisite for Enterprise Hadoop and provides cluster resource management allowing multiple data processing engines to handle data stored in a single platform. YARN exposes a REST API which allows remote applications to submit new applications to the cluster. The exploit requires two steps:

So essentially what the DemonBot does is to submit a new application, the bot code, to the Hadoop cluster via a YARN REST API that has somehow become accidentally exposed to the public internet (which apparently happens incredibly often). The bot then does a bunch of other fairly simple steps to provide a command & control channel and some attack commands so that a threat actor on the other end of the line can control the activity of the botnet to launch a DDoS attack. According to the Radware research, DemonBot is making new exploit attempts to bring new bots into the fold at a rate of 1 million per day.

Toward Less Brittle Signatures: Correlating Behavior with IOCs to Detect and Investigate DemonBot

The Radware post provides some useful Indicators of Compromise (IOCs) for detecting DemonBot, but the unfortunate nature of static IOCs is that they're brittle, with a short shelf life. The creator of DemonBot can probably tweak or obfuscate their code or make changes in their own infrastructure to render current IOCs ineffective. Furthermore, the existing IOCs might already be ineffective in situations where network traffic is sufficiently encrypted. This is the treadmill that so many cybersecurity professionals live on. We find IOCs. Bad guys change the code. Lather. Rinse. Repeat.

Fortunately, there's a method of detecting DemonBot and other RCE exploits against the YARN REST API that is much more difficult for the threat actor to route around. It relies on the fairly safe, basic assumption that because Enterprise Hadoop handles valuable, internal data, there should be strong protections around who and what can access the data, and especially around which new applications can use YARN to tap data and resources in Hadoop.

Here's how we've implemented the ability to detect this exploit with ExtraHop Reveal(x) Network Traffic Analysis:

First, our real time stream processor automatically parses and analyzes every conversation across the network, all the way down to the payload (not just the transaction metadata), so it sees all the requests submitted to YARN to add new applications. This works even if the traffic is encrypted with TLS 1.3 or earlier versions.

Then, a custom trigger that we built (available to all ExtraHop customers) does three things whenever a request comes into the YARN REST API:

1. Checks if the request came in via an HTTP POST request to the most common URI, as matched against an easily updated list, associated with attempts to exploit the unauthenticated RCE capability by creating a new application
2. If an HTTP POST request was issued against any of the listed URIs, checks whether the POST contained any IOCs, such as shell commands that would be extremely suspicious in a request to the YARN REST API, such as cd, wget, chmod, and others that indicate lateral movement and other attacker behaviors. The list of shell commands/IOCs can be simply updated and customized
3. If IOCs are present, captures the payload and records metrics for faster investigation and detailed forensic evidence of the attack

All of this information is captured and immediately surfaced via an alert to the security analyst, and could even be used to kick off automated investigation and remediation actions via Phantom or another SOAR product.

In layman's terms: no domain from the public internet should be issuing shell commands against your Hadoop clusters. If that's happening, your security team needs to know right away. Reveal(x) surfaces the clearest signals of this extremely suspicious behavior and lets the security team know.

Beyond Botnets: Why This YARN RCE Exploit is Worse Than It Seems

Here's the thing about Remote Code Execution vulnerabilities like this one. Using them for botnets is just the beginning. Remember our earlier assumption that Enterprise Hadoop is very likely to be handling potentially sensitive, internal-only data that qualifies as a critical asset for the enterprise.

The ability to remotely execute arbitrary code without authentication in a Hadoop cluster from the public internet can very easily become a mechanism for stealing or destroying large volumes of sensitive data. The DemonBot seems to only be stealing computing and network resources for DDoS purposes, but it's extremely likely that this same RCE exploit in YARN is also being used for far more sophisticated attack purposes that have not yet been detected.

Look for that in the headlines soon.

Meanwhile, if you're an ExtraHop customer using Hadoop, especially if your Hadoop clusters are in a public cloud environment, please install this trigger and talk to your ExtraHop contacts to assure you've got the best chances of detecting this exploit if DemonBot tries to come for your resources.