True Suckit infection NOT false positive in chkrootkit
I was looking at a machine recently with a Suckit infection. I'd dd if=/dev/zero of=/dev/sda or whatever, both the hard drive on laptop and an external hard drive and formatted as fat32 then as a linux partition. The external drive was simply an extended linux partition.
A fresh install would report no chkrootkit using Kali. However on reboot from hard drive it reported /sbin/init INFECTED AND also a sniffer on my wireless LAN card. If I created a blank test.mem test.ark file they would be hidden by rootkit. Win7 install would report everything as an executable file. A clean Windows Backup with no internet access had them as non-executables. This morning however I booted from LM15 DVD AND with the external hard drive attached and everything was fine. Executable files were returned to non-executable files on Win7 partition. That is the ones that normally on a clean install aren't executable. Others have reported not being able to remove Suckit after doing what I did ie zeroing drives, clean install. I thought it may live in memory and took the battery out of laptop as well as the power cord overnight, but it was still there when booting from hard drive without battery. What has happened? Could the rootkit lurk in drivers such as my wireless LAN card? Booting Win 7 only install on hard drive and an external extended partition linux hard drive using LM15 seems to have removed it. I doubt my ZoneAlarm virus checker did this. Perhaps we have TWO rootkits, one for Windows and one for linux? Just posting in case it helps anyone and if it does could you post back here so others know if this works or not. Also what operating systems you are using on hard drive maybe. |
Quote:
Theoretically it could be possible that it survived in the BIOS, if it was configured to do so -- unlikely, as it would need to be configured to your specific brand and model of BIOS. Same for firmware chips on devices. Entirely possible to survive there, as that's EEPROM, but it would have to be custom-written for the target. Unless your machine had a very worthwhile prize I don't see that as being likely. EDIT: Also, after a second wipe it was gone -- if it was in EEPROM it would be persistent no matter how many times you wiped it. So possibly the MBR. That's why after running a disk through /dev/zero or /dev/urandom (preferred) I'd go through it and wipe the boot record information using fdisk or gparted or even dban (forgoing the actual zero or garbage data overwrite) since that will also erase the boot record info. |
on a clean install, you may like to install rootkit hunter and see what it reports?
Altho I am sure you are right, and I know I am often wrong, sometimes what we think is true can in hindsight turn out to be false? BTW I am not a security expert. |
Quote:
- Service-based attacks and web stack exploitation replaced LKMs along time ago: SuckIT usage is way, way rare. - Chkrootkit was last updated in 2009: run current tools or run the specific check manually. - Do not mistake Microsoft Windows as a yardstick for anything: use a Live CD or DVD to inspect a system. - Verify the integrity of the system against contents from a known trusted repo (or at least compare the /sbin/init hash). - Most importantly: no proof of evidence was shown. Again. Run a Live CD or DVD, mount the "victim" file system and run the specific Chkrootkit v0.49 check manually and on the /sbin/init of the "victim" file system. First set the MOUNT_POINT variable to where you mounted the "victim" file system and include a trailing slash: Code:
strings -an4 ${MOUNT_POINT}sbin/init | egrep "HOME" Code:
strings -an4 ${MOUNT_POINT}sbin/init | egrep -ie "(fuck|backdoor|bin/rcpc|bin/login)" |
Quote:
As far as your report of a sniffer goes, if memory serves this alert is generated if a card is placed in promiscuous mode, which is done for valid reasons when using certain applications, like TCP dump, wireshark, or snort. |
Quote:
Quote:
|
I did another clean install after zeroing hard drive, and then the external hard drive before rebooting. Then formatted them as fat32, then just for fun ntfs, then reloaded win7 from dvds. Loaded lm15 behind windows. all well rebooted a few times for win7 updates. Now crappy CQ62 won't POST. caps lock flashes, black screen. Disconnected power cable and removed battery, held power button down etc
Now need to go somewhere and scream! |
@unSpawn: oops, I missed that line, sorry.
@mazinoz, your last post was quite informative and suggests that you have a hardware problem. Oftentimes, intermittent hardware issues can mask themselves as malware that tends to survive wipe and re-install processes. I would check the memory, power supply, and HDD + controller, in that order. |
'It seems I had BOTH! Compaq laptop works if I wrap it in bathmat and overheat it. Caps lock flashes every 4sec and won't boot otherwise. Seems to be the lack of thermal paste problem they are being sued for in a class action. Loctite screws are @!x'!.
Since posting I've found out using www.grc.com Optus in Oz no longer do reverse DNS. I suspect this makes it harder for hacker to brute force my computer. But I really don't know. From memory, I think I was using a boot cd and mounted Win 7 and files were no longer all green, indicating a Suckit infection. A fresh install on a zeroed fat32 formatted drive displayed pagefil.sys as white. Also sbin/inite dated 26 Mar. Almost as soon as I went on internet using linux I would be hacked. Files became +x, init date changed to 27 Mar, and chkrootkit on Kali cd reported sniffer on wlan0 as well as Suckit infection. test.mem and test.ark were hidden. When Suckit was gone I still got the chkroot INFECTION warning ONLY. I'll try to read and answer other posts asap, hopefully on something other than a 7 inch tablet! |
Quote:
Until you do it makes no sense at all to speculate about any "infections". |
David
I routinely use gparted to format partitions these days, a bit easier than fdisk or parted. This did not remove it. I thought overwriting whole disk would have been sufficient to remove it, although it takes longer than dban. I don't havea floppy drive, so went for 'scorched earth' solution. |
aus9
I did this, but from memory nothing significant was found with rkhunter. |
Still on tablet, thinking & reading your reply Unspawn, Found this interesting article
http://www.symantec.com/connect/arti...raphy-part-one in case anyone is interested. |
suckit may be old, but script kiddies have a toolbox...
Recent posts at slashdot and threatpost mention the continued use of mbr trojans. I did not see and mbr re-writes here(?) and it's quite possible there (the mbr) is the hiding place. In case you don't know, you use dd. Code:
in order to set to zero the 512 first bytes: |
Quote:
|
All times are GMT -5. The time now is 10:36 AM. |