Bread And Butter Attacks
Butter is an attack campaign that has been known to us for several years. Unlike the dozens of short-lived, mass attacks monitored in our network of sensors (GGSN), Butter originates from a very limited number of attack sources and keeps them alive without being caught due to its low and slow operation. In July of this year, Butter released a new payload that has gone undetected by many security products and has convinced us to release this post.
Butter executes a brute force SSH attack and on every breached Linux machine leaves a backdoor user named butter, together with a Trojan registered as a service. Since we first discovered Butter, we’ve seen its payload constantly evolving and taking different shape.
In this post we will cover the attack workflow, provide a closer look at two of its common payloads, and suggest ways of remediation.
Spreading butter
Our earliest record of the Butter attack is from the middle of 2015 and since then we’ve seen thousands of attacks with the butter signature in different intensities throughout all of our sensors. In fact, a new payload detected a few months ago has triggered this post.
Butter attacks look different than other mass attacks we’ve seen in GGSN. These attacks originate from a limited set of IPs as opposed to the wide range of attacking IPs we typically see in these types of attacks. Specifically, in the past two years we’ve seen only 4 different unique IP addresses used for attacks in different stages.
These IPs are from Hong Kong and Singapore and have been associated with malicious activity since 2016, including one server hosted by Krypt, a hosting company with questionable behavior towards abuse emails.
Over the last few years we’ve seen two common payloads, 80 and samba. 80, the older and more prevalent, is a x64 variant of the well known DDoS payload XOR.DDOS with the filename 80. This is a modern RAT with DDoS functionality that runs itself persistently using cron, kills competitor malware, and installs a Linux kernel rootkit to hide its tracks.
Samba, named after one of the file names it disguises itself in, first emerged in July of this year. The core features of this malware are typical along with a RAT functionality that includes downloading files, executing shell commands, an upgrade mechanism, and the capability to join in DDoS attacks. Typical to RATs in the past few years, the malware has a built-in functionality to download and run a miner. Since it first showed up we’ve seen seven versions of this malware.
Looking into different versions in this timeline, we see it evolving. For example, the first variant was in the wild for only ten days, lacked DDoS functionality and was probably a trial run. Another version was released for only a single day and then pulled back, probably because of a bug.
How butter earns his bread
The Butter attackers break into servers by brute forcing SSH credentials. This technique, while basic, is still incredibly effective worldwide. Weak and unsecured machines still exist by the tens of thousands across all industries ranging from tiny IoT devices to large servers.
Once the attackers are in, they run the system commands uname -r and uname -m and then add the user butter with the fixed password xuelp123. The first two commands above show the attacker which payload to deliver.
As a result of these commands, a new user is added, creating a backdoor into the system.
Once this backdoor is in place, the attackers download the payload over SFTP to the victim machine. Then the attackers run the command chmod 755 on the payload file, changing the file permissions to allow execution. Before running the payload, they kill prior running copies of the malware. Lastly, they execute the payload and disconnect.
The samba Payload
We first detected the samba payload in July of this year. Unlike 80, this payload is unique to the butter attacks. As seen in some of our previous campaigns (Bondnet, Prowli), parts of the malware is written in golang and contain the core of an effective Linux Trojan.
Upon starting up, the malware wipes the following log files to hide traces of attack:
These log files contain login details at different levels of detail that may come in handy for incident response. The malware copies itself to /etc/seconfig and marks itself for startup by adding an entry to /etc/rc.local or to a cron job.
In between suspicious operations such as wiping logs and and communication with C2, samba has long sleep periods to avoid detection.
Next, the RAT initiates two additional goroutines (light weight threads): a RAT update procedure and a miner executor. Both communicate over plain HTTP with a file server controlled by the attacker.
This happens while the “main” goroutine of the malware opens a communication channel with its C&C server using hard-coded addresses (e.g. 103.233.83[.]23, x.bigoupai[.]live) over port 27. The malware begins by transmitting a message with a fixed header 0x11,0x10,0x10,0x1,0x22,0x32,0x21,0x52 and then a string containing the machine architecture (in our case, linux_amd64) prefixed with a byte specifying the length of the string.
The server replies with an encoded IP address, which is an updated file server to download malware updates and miner files.
The malware sends a machine architecture string and receives an encoded IP address
Then the malware main thread enters a block state, waiting for new commands from the C&C server. The RAT supports three different commands: system (to run a shell command), udp (to run a UDP based DDoS attack) and http (to run an HTTP DDoS attack).
The bread behind butter
The attackers behind butter are pros. They have managed to collect machines, stay active for several years and monetize their operations – and all this without being caught. By ‘laying low’ and avoid making attribution mistakes, they managed to stay stealthy with a relatively simple infrastructure.
At first, the Butter attackers deployed well-known payloads developed by other malicious actors. To grow their profit, they recently they branched out and wrote their own RAT with a cryptocurrency miner and DDoS capability.
Like many modern miners, the butter attackers mine Monero, a cryptocurrency focused on privacy and anonymity. So while we have our attackers preferred mining address, 45WHGeVZUKB4R9cWEQdSpofqz7VYR596vJ2vfRSgQWVNiywAUWFbaVWJGbYtkLiHF4Q4BJ5Y6DbRD2QRhBBZu4fk7K6Y5ez, we cannot track how much money our attackers earn.
Besides cryptocurrency mining, the Trojan puts its DDoS up for hire using two different methods. There are two DDoS attacks the malware is capable of, using HTTP and DNS. The HTTP attack method targets a domain over a specific port. The HTTP verb used is GET and the user agent is one of a few well-known browsers, such as Mac OS Safari or Chrome running on Ubuntu. The DNS DDoS attack looks like a DNS amplification attack based on the Mirai botnet flow.
A Domain Name Server (DNS) Amplification attack is a popular form of Distributed Denial of Service (DDoS), in which attackers use publicly accessible open DNS servers to flood a target system with DNS response traffic. The primary technique consists of an attacker sending a DNS name lookup request to an open DNS server with the source address spoofed to be the target’s address. When the DNS server sends the DNS record response, it is sent instead to the target. Attackers will typically submit a request for as much zone information as possible to maximize the amplification effect.
As part of Butter’s attention to detail, all the important strings such as C&C IPs, file names, and directory locations are kept encoded. This prevents easy analysis by malware analysis tools and typically requires human intervention to decode.
Samba’s encoding schema is simple but effective at hiding the strings. In each string, each character is shifted 3 positions “up” in the ASCII table and XORed with a value in a small cyclic buffer.
The code to decode all the strings is as follows:
It’s important to note that the challenges in reversing golang malware are very different from reversing C/C++ malware. It’s easy to recover a list of function names because golang compiles binaries with a large amount of metadata to support reflection. However, the control flow is heavily based on goroutines and asynchronous callbacks, making it harder to track the control flow.
We also noticed a number of weird looking half-baked parts in this malware. For example, the malware listens on a specific TCP port (37373 or 47292) but doesn’t accept connections on that socket. In addition, as part of the Trojan’s configuration, it holds configuration variables that are copied from the Mirai Server source code but are not used anywhere in the source code.
The veteran 80 Payload
Best known as XOR.DDoS, this payload has been around since 2014. The core part of the malware is comparatively simple. It connects to one of the hard coded control servers, sends server metadata – CPU, memory and network information – and receives commands.
It can receive the following commands
- Stop DDoS campaign
- Start DDoS campaign
- In this case, the server also sends a target IP, port and attack type
- Send system data – A list
- Download and execute file
- Download file and execute in place – used for upgrades
- Update configuration
The XOR.DDoS payload can perform three types of DDoS attacks:
- Send a flood of DNS packets as part of a DNS amplification attack
- Send a flood of TCP SYN packets
- Send a flood of TCP ACK packets
Detection and prevention
The butter attacks are entirely driven by brute forcing SSH credentials, meaning that any device with weak credentials is vulnerable. This can include unmaintained servers and appliances with hard-coded credentials. Defenders should focus on locking down systems and pay attention to machine credentials policies to block weak passwords.
Since breaches are often inevitable, consider segmenting and monitoring your network to minimize harm and avoid breaches from weak machines. Routinely review who and what can access the servers. Monitoring outbound connections could easily uncover compromised devices communicating with cryptocurrency mining pools.
Check for butter
Check for compromised servers by searching for a user named butter in their systems. To check if a specific user exists in a system you can run the following command on any Linux based system:
If the user exists, you will get an output giving the user’s ID, which should be 0. If the machine is clean, an error message stating id: ‘butter’: no such user will appear.
Check access logs
Access logs should also give you a good indication of whether attackers have tried to connect to different machines using the butter login credentials. These access attempts may indicate that a machine in the network was previously compromised.
Clean the samba payload
The immediate step of stopping any mining activity can easily be done by detecting CPU intensive processes, stopping them, and deleting their binaries. We also suggest blocking all cryptocurrency-mining-related domains, as there is no reason for an organizational network to connect to these domains for any purpose. In butter’s case, this is fr.minexmr.com.
Conclusion
We continuously find that the most basic attack methods that worked ten years ago still work and will probably continue to be effective in the future. Brute forcing credentials and simple persistence methods such as adding users to the system are not going away anytime soon. The signature user butter was first mentioned in a thesis from 2015 and until today continues to show up in many “top lists” of SSH honeypots.
There are enough vulnerable servers online for everyone who wants to mine cryptocurrency and use it for profit. These botnets end up costing the economy hundreds of millions of dollars a year in incident response and resource costs. Prowli, Hexmen and Bondnet are only some of the campaigns we covered that behave in a similar fashion. Attackers will continue to search for low-hanging fruit and abuse it as long as it’s profitable. These easy-to-compromise servers must be handled as part of an attempt to “clean up the internet“.
IOCs
IPs
Domains
Hashes
Monero wallet
45WHGeVZUKB4R9cWEQdSpofqz7VYR596vJ2vfRSgQWVNiywAUWFbaVWJGbYtkLiHF4Q4BJ5Y6DbRD2QRhBBZu4fk7K6Y5ez
