While the XOR DDoS Trojan has been active for over a year, we’ve seen a recent surge of coverage and blog posts recently. We’ve also seen the Groundhog variant emerge. This has prompted a few of our customers to ask how their Threat Stack deployment will detect this type of attack and activity as well as what new rules need to be added to detect this.
Before getting to this, let’s set the stage. The XOR DDoS Trojan is malware that targets Linux machines to create a botnet, which is then used to host DDoS attacks against various targets. While the first concern may be how to protect yourself against this DDoS attack, you are more likely to be a target of the Trojan trying to make your Linux servers part of the botnet.
Of course, there are several mitigating factors to being successfully infected such as use of identity files for SSH and the use of OpenVPN to get to jump or bastion hosts, but barring these I want to highlight the things that are built-in to every Threat Stack deployment with the “Base Rule Set” to detect the indicators of compromise for this attack and its variants. The Base Rule Set is provided with every Threat Stack deployment and is regularly updated as new attacks are discovered by Threat Stack and others.
Before I get into the details of how the Base Rule Set works in this case, it’s important keep two things in mind. The first is that all of the settings and severity levels are the defaults for the Base Rule Set and can be changed to suit your security needs. Second, this process of infection is pretty much the standard process as part of the cyber kill chain regardless of the attack vector, vulnerability, or exploit. The cyber kill chain will almost always be the same. Here’s how the “Base Rule Set” covers the detection of each of these steps in the cyber kill chain.
The above images reflect how Threat Stack identifies the chain of events and timelines associated with this attack.
The first step in the trojan infection process is for the attacker to breach SSH by brute force and dictionary attack, targeting root accounts with weak passwords. This is where the first rule will create an alert. This rule is titled “User Activity (Login Failures)”. This rule will create a “Severity 1” alert on the first failed login, unless of course your root password is the first password in the dictionary file.
When a successful login is acquired the attacker will then run a shell script via remote SSH commands to download and install the binary used for the attack. This binary is built and compiled dynamically based on kernel information of the compromised server sent back to the attacker’s server. When possible, this build process will create a rootkit binary compiling with the appropriate loadable kernel modules. If the rootkit functionality is used and the malware is installed as a kernel module then the rule “Kernel module activity detected” will be triggered created a “Severity 1” alert.
Now the trojan establishes a new connection to the command and control system (C&C), which happens over one of a few TCP ports. This is where the next few rules come in and will create several alerts. The first rule is the “Network Activity (Connects) by ran by user ”. This will create a “Severity 3” alert when a process makes an outbound network connection that we have not seen before and will show the process, user (root in this case), and the destination IP.
The downloaded trojan binary is then executed, which will then write two copies of itself into different directories, one in /boot and one in /lib/. This is where the next layer of detection and the next alert will be triggered. This is the file monitoring rules in the Base Rule Set. The file monitoring will create a “Severity 3” alert for the creation of a file in both the /boot/ and /lib/ directories recursively.
Finally, the trojan executes for its designed purpose — a DDoS. This is again picked up and a “Severity 3” alert is created by the “Network Activity (Connects)” rule I mentioned above, as the trojan process sends its flood of traffic to the target server.
As for the Groundhog variant of the XOR DDoS malware, this is is used to create a backdoor for attackers to take control over a compromised server and maintain a foothold. This malware is often discussed along with the XOR DDoS since it appears to have several pieces that are similar and is possibly created by the same group or person.
The attack is started by taking advantage of the well publicized ShellShock vulnerability. If this vulnerability exists, a shell script is executed that starts the process of infecting the vulnerable server. This script uses wget or curl to download the persistent malware payload and this is where the first two rules will create an alert. The first rule is the “Network Activity (Connects) by ran by user ”, which will create a “Severity 3” alert showing the process (wget or curl) making an outbound connection including the arguments for that process, which will be the URL with the IP and file downloaded. The second rule that will create an alert for this activity is the “User Activity (File Transfers): by with ”. This will show the same information as the previous rule, however it will be a “Severity 2” alert.
The rar file is then executed and will write itself to various directories during the decryption process. Files are written into /usr/bin/, /bin/, /lib/, /var/, and /tmp/. This will trigger the next alerts from File Integrity Rules, specifically “Monitor System” and the corresponding alert rule, “File Activity for file: ”. This is a Severity 3 alert.
Once the malware has been decrypted, it will then make an outbound connection from a random process name to the C&C server (hostname GroUndHog.MapSnode.CoM) hence the name Groundhog.
Additionally the polymorphic nature and real-time building and compiling of the malware means that traditional signature-based malware detection means the products are completely ineffective.
This C&C connection is maintained for future use and any additional malware downloaded or executed or any other activities will trigger rules in the “Base Rule Set”, but hopefully the alerts already generated by this activity will tip you off to the presence of this malware to allow you to remediate before further damage is done.
As the detail here illustrates, Threat Stack and the “Base Rule Set” are directly focused on alerting on the indicators of compromise. With one umbrella rule set to cover all your servers along with the ability to stack rule sets on top, you can create a few rule sets that are server or application stack specific. This means that typically there’s no need to have more than two rule sets applied to any server. The power of the rule sets is not in the sheer number of rules or the ability to create complex rules, but in the simplicity of the rules.