Some people on this list are treating this far too casually. 2015/01/07 1:06 "Danny" <mynixm...@gmail.com>: > > Hi guys, > > A while ago I posted a question about SFTP (I think the thread name was "SFTP > Question") about attacks I got against my server after syslog warned me about an > attempted breakin.
Too bad I've been so distracted dealing with social engineering issues. I was going to tell you at the time, if you think your box has been cracked, assume it's been cracked. Don't guess, don't swag in parts, don't tiptoe through the tulips. Don't ask on mailing lists for someone to tell you it's all right. > Consequently I installed fail2ban and did a few other things to let me sleep > better at night. Too late. You're opponents probably already have their own, separate login mechanisms in place. Those things only work against opponents who have only the front door to come in through. Unless you are talking about a physically separate firewall and a physically separate proxy, I suppose. But then you would be telling us about what the firewall logged, instead of asking about the toys left behind. > However, prior to this breakin, in early December 2014, I noticed my network > behaving strangely especially through wireless connections. I have Debian that > acts as a gateway (wlan0->br0->eth0). wlan0 is the pickup for the internal > network that gets bridged to eth0 which then goes through the router to the > internet. What I noticed was that wireless connections would break down quickly, > bind9 would fail to resolve (even on wired connections) and pages would load > slow. In general it was chaos. You should be looking for the physical path of entry. If you can afford it, set up logging monitors on the internal traffic, both wired and wireless. And insert a dedicated logging firewall to the WAN, firewalling and logging both ways. And you wanted to have done that back then. > Under the impression that it was a hardware failure, I changed the wlan0 > adapter. Still it was the same. So I bought a more expensive one, and still no > change. I changed eth0 with an expensive one and still it was the same. I bought > 2 new Netgear ADSL routers but the chaos was still there. Next time, remember what swagging hardware bought you -- just giving time to your opponents. > wlan0, br0 and eth0 just didn't want to work together no more. Eventually I > stopped all bootup scripts and processes trying to isolate the problem. And > guess what, I found the culprit. More like one of the careless culprits' leftover toys. You've been had by amateurs, but that doesn't mean that professionals have ignored you. > Here it is: > ########################################################## > -rwxr-xr-x 1 root root 648K Dec 11 17:17 /boot/dippqejwvf > ########################################################## You really want to know how that file got there, and all its differently named clones. > This file got booted up and caused all the havoc. I moved it to a secure place and > now it seems that all gremlins have gone away. The date on this file is 11 Dec > 2014, right about the time my troubles started. I think that those Chinese guys > got into my system even before syslog warned me a few days later. You can't even trust the dates, of course. > However, I have a few other weird looking files in the /boot directory. Can you > guys please have a look at them and tell me if they are normal or not. There is no reason to ask. You're just giving your opponents more time. > ######################################################### > drwxr-xr-x 3 root root 4.0K Jan 6 19:35 . > drwxr-xr-x 24 root root 4.0K Jan 3 17:23 .. > -rwxr-xr-x 1 root root 648K Jan 6 19:03 aknaykocbs > -rwxr-xr-x 1 root root 648K Jan 1 11:34 bxerzoalfk > -rw-r--r-- 1 root root 157K Dec 10 18:57 config-3.16.0-0.bpo.4-686-pae > -rw-r--r-- 1 root root 132K Dec 8 00:36 config-3.2.0-4-686-pae > -rwxr-xr-x 1 root root 648K Dec 20 08:04 cwpgfmvkrk > -rwxr-xr-x 1 root root 648K Dec 30 22:41 czhlgmsgzh > -rwxr-xr-x 1 root root 648K Dec 30 20:03 dkseypedtx > -rwxr-xr-x 1 root root 648K Jan 3 15:14 esijfkmwnd > -rwxr-xr-x 1 root root 648K Dec 27 14:49 fndswijgdk > -rwxr-xr-x 1 root root 0 Dec 20 08:14 gbwokvqoch > drwxr-xr-x 3 root root 12K Jan 3 17:23 grub > -rwxr-xr-x 1 root root 648K Jan 5 07:28 gyimenpwnt > -rwxr-xr-x 1 root root 648K Dec 31 17:49 hjmmvaxfzq > -rwxr-xr-x 1 root root 648K Dec 15 21:25 hutaslspbf > -rw-r--r-- 1 root root 14M Jan 3 17:25 initrd.img-3.16.0-0.bpo.4-686-pae > -rw-r--r-- 1 root root 11M Jan 2 22:01 initrd.img-3.2.0-4-686-pae > -rwxr-xr-x 1 root root 648K Jan 2 18:47 isrgzlchmx > -rwxr-xr-x 1 root root 648K Dec 27 14:56 izytxsbskq > -rwxr-xr-x 1 root root 648K Jan 5 18:40 kvvcqvddix > -rwxr-xr-x 1 root root 648K Jan 1 11:19 ryrfvxjggh > -rwxr-xr-x 1 root root 0 Jan 5 19:08 sgopxfsiac > -rw-r--r-- 1 root root 2.0M Dec 10 18:57 System.map-3.16.0-0.bpo.4-686-pae > -rw-r--r-- 1 root root 1.6M Dec 8 00:36 System.map-3.2.0-4-686-pae > -rwxr-xr-x 1 root root 648K Dec 30 20:40 ttqssdikcn > -rwxr-xr-x 1 root root 0 Dec 26 17:11 utxlhlmnix > -rwxr-xr-x 1 root root 0 Dec 12 07:29 vdqepbezvg > -rw-r--r-- 1 root root 2.9M Dec 10 18:56 vmlinuz-3.16.0-0.bpo.4-686-pae > -rw-r--r-- 1 root root 2.6M Dec 8 00:35 vmlinuz-3.2.0-4-686-pae > -rwxr-xr-x 1 root root 648K Dec 31 17:30 wevzubbsgn > -rwxr-xr-x 1 root root 648K Jan 1 09:46 xjeemjyuly > -rwxr-xr-x 1 root root 648K Jan 1 17:10 zfmpizunja > -rwxr-xr-x 1 root root 648K Jan 1 10:00 zkdjlvhuui > -rwxr-xr-x 1 root root 0 Dec 30 22:32 zpaqgbuxvr > ######################################################## > > What bothers me is that the "other" files are all the same size (648k) as the > suspected file I removed and they are very recent additions to the /boot > directory. > > Thank You > > Danny BTW, did you think to do a cmp /boot/dippqejwvf /boot/aknaykocbs ? Not that I expect attackers to dump multiple identical rootkits, but it might be amusing. You also might be amused by doing a hexdump -C on some of those files. But get that box off-line, first. At this point, you can't really trust anything on it, including the BIOS -- even with secure boot enabled. Kill the wireless and wired connections. power it down. If you can afford a dedicated analysis box, do a post-mortem. Don't put this box back on-line unless you can compare the BIOS to a known good BIOS first, and then only after wiping the drives and installing a new OS. Back up the data on the box to a drive mounted no-execute on a known good system. As someone else mentioned, scrub your data as you restore it to the new box by making sure it is the data it is supposed to be. And figure out how they got in, and fix that, or you're just going to be doing this all over again pretty soon. And, by the way, you probably have at least one more box on your internal network that has been owned by the attackers. -- Joel Rees
