-   Linux - Security (
-   -   Removing trojans from hidden trailing sectors of hard drive. (

mazinoz 08-07-2009 07:47 PM

Removing trojans from hidden trailing sectors of hard drive.
I have recently posted re a SucKit infection and later quoted an article on linuxquestions by Awesome Machine 'How to do everything with dd"

I have tried the free version of Helix but am still a bit mystified about the program Awesome Machine refers to on the Helix CD.

" To see the end of the disk you have to know the total number of sectors for the disk, and the disk has to be set up with Maximum Addressable Sector equal to Maximum Native Address. The helix CD has a utility to set this correctly. In the dd command your seek value will be one less than MNA of the disk."

This is the part I don't understand. Anyone know what program he is referring to and what Helix CD it is on? I think I have the total sectors worked out but I appear to have an exact amount of cylinders for my hard drive with none left over. 80Gb Maxtor drive 15061 cylinders(?
from memory) and 16 heads 63 sectors.

I would like to know more details of the content of this sector before trying out the command to wipe it. I would like to preserve Windows registration data there (for resale purposes) but remove the trojan.

Though I have been using linux for years I still feel a bit like a newbie.

I have tried some firms in Brisbane but only one seems to have any idea about linux security issues, and they are a bit uncertain about tackling this problem. Most of the time I'm just told to install Windows. Doubt that that would stop this trojan that either is SucKit or loads SucKit.
I think it is multipurpose as it appears to summon computers to attack the firewall by portscanning DCOM and Samba ports mainly. There is also a human being(?) constantly turning off my firewall and disabling PrintScrn. PrintScrn works fine when I am not on the internet. Now he/she also has hacked files in /etc/ppp/peers I use to connect to the internet, so once connected I am automatically disconnected,and changed firewall setup to allow them access to my machine. They altered the firewall to ok access for one of the IP addresses that are portscanning as mentioned above. I am not using the machine at present as I would like to preserve it.

Noticed when using Fedora live CD, that there is no /dev/kmem for SucKit to alter. Still in Lenny Debian though.

Any help appreciated.

Unspawn if you read this I have zipped log files and will forward them to you if you are still interested as well as PrntScrn shots. (Pulled plug on modem and was then able to save them). Currently typing from library PC, not sure if I can upload these.

Quakeboy02 08-07-2009 08:40 PM

Can I ask you a dumb question here?: You are describing a trojan (or whatever) that you believe to be persistent in that it magically comes back after reinstalls. Is it possible that you are using the same root/user passwords each time you reinstall, or that you reinstall every time from the same CD (or one from the same site), which is compromised? Just something to think about whilst waiting for the guys who understand this stuff.

unSpawn 08-08-2009 06:43 AM

Referring to earlier threads this "problem" of yours has been allowed to exist for way too long. Because you have not posted the required concrete evidence in threads 0 and 1 and because you allow your focus to wander from the concrete to the wildly exotic and highly improbable, but with all due respect, I have to request you 0) only collect and post "evidence" of this "infection" and upload your logs to a free host and post the URI here (or email it to me) and 1) stop posting your hunches, assumptions and misperceptions.

If the next post you make does not contain the requested evidence (or questions about retrieving or posting any) then you have a problem of a different order and of a magnitude bigger than a mere perceived breach of security.

mazinoz 08-14-2009 01:28 AM

Dear Quakeboy

Earlier on in the posts I referred to, I stated I had used a .iso download which is automatically checksummed when you go to burn the DVD in k3b and rezeroed the drive dd if=zero of=/dev/hda reformatted, reinstaled using a Linux Magazine free DVD. Same result as with either the Linux Magazine DVD, or the one I downloaded. I change the passwords for everything root, user and epp (encrypted password) each time. If you read the artice I refer to you would find what I believe is the explanation for the problem I am having.

Dear Unspawn

Other unrelated issues have prevented me from replying sooner, (paying bills, Dr visits etc, car registration etc). If you could let me know what free host or email address you are referring to / prefer I will try to upload as much as I can. (btw, dd image for an encrypted drive is an 80G drive image, bit difficult to upload!) No disrespect intended.

If anyone can help with the trailing sectors problem and knows the utility referred to please help!

Thanks and best wishes

unSpawn 08-14-2009 05:56 AM


Originally Posted by mazinoz (Post 3642839)
If you could let me know what free host or email address you are referring to / prefer I will try to upload as much as I can. (btw, dd image for an encrypted drive is an 80G drive image, bit difficult to upload!)

Using your favourite searchengine with a term like "free file upload" will yield at least ten addresses. With all due respect but I don't want to look at a complete disk unless there's no other way. I'd rather see the contents of that part of the disk you find contains (traces of) malicious activity and the log of the tool that tells you it (possibly) is malicious activity.


Originally Posted by mazinoz (Post 3642839)
If anyone can help with the trailing sectors problem and knows the utility referred to please help!

Please don't. Let's focus on determining things first.

mazinoz 08-14-2009 08:39 PM

Dear Unspawn

Have tried to upload log files to you via Megafile File Upload. Any help is appreciated. There are some screen shots as well that I will try to upload. I only have an hour a day access and no access till Tuesday AEST.

Best wishes


unSpawn 08-15-2009 01:36 AM


Originally Posted by mazinoz (Post 3643851)
Have tried to upload log files to you via Megafile File Upload. Any help is appreciated.

Did you succeed? Did it fail? What would you like help with?


Originally Posted by mazinoz (Post 3643851)
There are some screen shots as well that I will try to upload.

You could attach them here unless you don't want to.


Originally Posted by mazinoz (Post 3643851)
I only have an hour a day access and no access till Tuesday AEST.

OK. Good luck.

mazinoz 08-17-2009 08:32 PM

Dear Unspawn

I received a confirmatory email that files were uploaded to your email

Will now attempt to upload screen shots from same site as previously. Some have dates either in the file or in filename. They are from a reload done just before 27th July 2009. The screenshots are a bit haphazard, done when I noticed something odd. Just to provide additional information that may help. There is a similarity also in the firewall blocked events shots, from two different servers.

I forgot to mention my written records (paper,handwriting) say 27 July is the day I first accessed the internet after zeroing hard drive, reformat, reinstall. The hacking follows a repetitive pattern, as though following a script each time.

Back to attempting to upgrade my security measures.

We have been having an interesting time here in Australia as regards internet security.
In the last two weeks or less, Multibet a large internet betting company was put out of business by the Russian mafia. A ransom demand was made and Telstra (semi-government body with largest market share)assured them that they would nuke the threat without any problem. However Alice Springs, South Australia and Sydney networks were affected to such an extent that Telstra pulled the plug on Multibet connection. Also Pay Pal was forced down and Optus email servers were also downed. I was at one stage only getting 6Kb/s, on a wireless broadband connection. Poor signal strength where I live has also been blamed, and I suspect digital radio and new digital TV stations, some of which I can't get a signal for
recently going on line at this time also complicates the picture. People have told me they are having trouble reaching me on my mobile as well. So the problem is not just someone hacking me personally, but bigger internet network problems as well.


unSpawn 08-18-2009 01:50 AM


Originally Posted by mazinoz (Post 3647313)
I received a confirmatory email that files were uploaded to your email unspawn at linuxquestions dot org.

Awesome. Except that is the email address as vBB exposes it, I use unspawn at hushmail dot com as my main email address. Best contact me by email before sending me stuff because I prefer retrieving items from a dropoff myself (I thought I'd conveyed that in my first reply), besides no email from you has arrived at aforementioned address.

mazinoz 08-18-2009 06:40 PM

Dear Unspawn

Have sent the screenshots to you as SucKit_Evidence.tar.gz at above email address.

Will send the log files tomorrow as I don't have them on me right now.


unSpawn 08-19-2009 11:52 AM

DoSsing my inbox is not appreciated (and that is an understatement). You should not send me email like you did unless discussed beforehand.

mazinoz 08-20-2009 07:21 PM

Dear Unspawn

I apologise for what happened, and in no way intended to cause you harm. I was unable to post yesterday as believe it or not the public library network and internet were down. I honestly don't know what I sent you that caused damage. As far as I know they were screenshots and log files. Please advise what to do now. Will soon be cut off.



unSpawn 08-20-2009 08:58 PM

It's not what you sent me but how much. Anyway, I've responded to your email so my secondary email address is in the details. I'm not going to post it here.

mazinoz 08-24-2009 06:20 PM

Dear Unspawn

Just sent anything I thought might be useful. Apparently I've gone from too little to too much!

Thank you for your assistance. Off now to check emails.


unSpawn 08-25-2009 07:55 AM

0. Introduction

I have received a tarball comprising of printscreens, system logfiles, and tool logfiles. Both printscreens and logfiles contain output of single-purpose tools like 'skdet' and 'unhide' and from running tools like 'chkrootkit' and 'rkhunter'. All files have the same timestamp, manually created files are not uniformly named and rarely does the filename include a timestamp.

1. Firewall logfile examination.

1.1 The Firestarter display of events, for example "iseek_servers/6August09-2.png" shows 2 times port TCP/445. Next to deliberate scanning of hosts one can also view these types of probes as collateral from badly configured hosts in busy networks. To see the explanation of for instance port TCP/445 usage see "". To see the amount of targetting done use "".

1.2 The Firestarter logs, for example "iseek_servers/firestarter-events2.txt" show one hit of TCP/22. Because the "Out:" value isn't used, only "In: ppp0", we know this is incoming traffic. As you know it is best to shield traffic to port TCP/22 by filtering through the firewall, plus usage of /etc/ssh/sshd_config "PermitRootLogin no" plus AllowUsers and AllowGroups directives, plus using a method described in "". To see WHOIS details and to determine if a remote IP address is a known scanner use "".

1.3 In the case of iseek_servers/firestarter-events3.txt, in the second line (In: ppp0 Out: Port:62509 Source: the Service is marked "Unknown". This means that there is no mapping in /etc/services (try: 'getent services 22' to notice the difference). This is seen a lot by ports in the ephemeral range (int >=1000 or int >=10000, depending on how busy a host is).
Conclusion: good: there is no evidence of "cracker" traffic to be seen from the firewall logs.

2. System and application logfile examination

2.1 Files "Logs etc/27July2009-skdet-results" and "Logs etc/28July2008.log" showing output of running 'skdet'.
Conclusion: good: the output does not show the skdet "invisible" marker or evidence of running "sk" binary.

2.2 File "Logs etc/annie.tar.gz" has mbox(-like) contents showing automated emailed reports by Anacron ("cron.daily"), (..) and rkhunter alerts. The rkhunter email of 2009/Jul/28 shows an inode change of "/usr/sbin/unhide-linux26" and output from the "deleted files" test for /usr/sbin/anacron, /usr/lib/libgconf2-4/gconfd-2 and /bin/run-parts. The complete rkhunter log for 2009/Jul/28 can be read back from "Logs etc/log.tar/log/rkhunter.log" (append mode). The rkhunter.log for 2009/Jul/28 does show the system does not use prelinking, therefore the inode change of "/usr/sbin/unhide-linux26" must be explained by other means. Since the properties do not show changes in other files it is advisable to corellate with logs from a (previously configured and run) filesystem integrity checker (Samhain, Aide even tripwire) or using the verification method this distributions package manager offers (if any), and preferably run booted from a Live CD to prohibit tainting results. The output from the "deleted files" test for /usr/sbin/anacron, /usr/lib/libgconf2-4/gconfd-2 and /bin/run-parts are consistent with TEMPDIR value usage (default: "/tmp") and the naming scheme for applications (being of format "/tmp/gconfd-USERNAME/lock/HASHVALUE"). Because temporary files are meant to be transient, investigation of the filetype, modify, access and creation timestamps, ownership, access rights and its contents should happen on encountering them and before the same machine is rebooted.

2.3 The "Anacron job 'cron.daily' on mustang" email message of 2009/Jul/28 shows that "/etc/cron.daily/chkrootkit" was run, listing suspicious files and directories: /usr/lib/jvm/.java-gcj.jinfo, /usr/lib/iceweasel/.autoreg, /usr/lib/xulrunner-1.9/.autoreg and /lib/init/rw/.ramfs. Filenames starting with a dot are still marked as suspect because of the way running 'ls' displays them (use 'ls -al'). Enumerating installed package contents and verifying package contents will show if these files are false positives. If not listed as part of a package, inspection of these files (filetype, modify, access and creation timestamps, ownership, access rights and contents) can help determine their use. The "Anacron job 'cron.daily' on mustang" of 2009/Jul/28 also shows that tripwire was installed but not properly configured.

2.4 The "Anacron job 'cron.daily' on mustang" email message of 2009/Jul/30 shows that "/etc/cron.daily/chkrootkit" was run, listing the same suspicious files and directories as noted before, and one chkproc warning "Possible LKM Trojan installed". Because processes can be transient and do not survive a reboot, investigation of the process ('readlink -f /proc/PID/executable', its modify, access and creation timestamps, ownership, access rights, commandline arguments, opened files and used ports, its location and contents) should happen on encountering them, before the process has expired and before the machine is rebooted.

2.5 Parsing the "Logs etc/rkhunter.log", "Logs etc/rkhunter.log.tar.gz/rkhunter.log" and "Logs etc/rkhunter.txt" (with 'egrep -vie "(not found|none found| OK | skipped | request| info: | Checking for|performing )" "$1" | grep -v "^.*\]$"') shows "suspscan" was not configured and "hidden" warnings for /dev/.udev and /dev/.initramfs: see earlier examination notes with respect to determining false positives at 2.2.

2.6 Parsing the "Logs etc/rkhunter.log", "Logs etc/rkhunter.log.tar.gz/rkhunter.log" and "Logs etc/rkhunter.txt" (with 'egrep -e "(|/sbin/init)"') shows only in "Logs etc/rkhunter.txt" changed inode and modification time warnings for /sbin/init. on 2009/Jul/20 (RKH version 1.3.2) where this was not reported earlier on 2009/Jul/18 using RKH version 1.3.4. Parsing "Logs etc/rkhunter.txt" (with 'egrep -e "(inode|modif)" rkhunter.txt | awk '{print $NF}'|sort -u') shows changed inode remains constant: 10137 -> 237469 and this goes for modification time as well: 1218550140 -> 1247915052. See notes at 2.2 with respect to verifying the state of the /sbin/init file.

2.7 Parsing system and daemon logs manually and using 'logwatch' show various errors but only related to USB and applications.
Conclusion: incomplete: the logged output does not show evidence of "cracker" activity, however since corellation evidence is not available I will not mark this as "good". Also note the used RKH version (1.3.2), misconfigurations and repetition of above events in email is evidence email was not read or was not understood to be cause for proper maintenance.

3. Printscreen examination

The directory "Print Screen shots" contains printscreens of several types of situations encountered, namely:
3.1 directories being added to the root directory,
3.2 'skdet -c' output showing open ports: see notes at 2.2,
3.3 evidence of a /home/root directory,
3.4 'unhide brute' output showing hidden process Ids: see notes at 2.2,
3.5 chkrootkit output showing warning for "//home/root" (as in ENODIR): possible misconfiguration,
3.6 Rootkit Hunter output showing "language keyword not found" error, /sbin/init warning, hidden files and directory warning,
3.7 (k)ppp(d) warnings assortis,
3.8 file extension warnings (".png.png"),
3.9 zero-size files in the /home/USERNAME/.thumbnails/fail/gnome-thumbnail-factory/ directory.

3.6 Rootkit Hunter output showing "language keyword not found" error, /sbin/init warning, hidden files and directory warning.
The "language keyword not found" warning means that possibly two versions of Rootkit Hunter were installed and resources got mixed. In no way do the rkhunter.{log,txt} logfiles suggest changes in /sbin/init other than noted at 2.6.
Conclusion: incomplete.

4. The printscreens in the "Threes_Servers" directory will not be examined as the explanation for the logfiles and printscreens in the "iseek_servers/" directory is sufficient.

5. Remarks

Because of the changes in Linux 2.6 and because most of the time a perpetrator does have a goal that can be met without the need for installing one, breaches of security involving installation of rootkits are relatively rare these days. Because GNU/Linux is all about performance, protecting assets and providing services in a continuous, stable and secure way and because the rootkit threat remains any gut feeling, hint, or any shred of evidence of a rootkitted machine should lead to immediate attention, prioritized handling and definitive resolution. Not only to protect data and users, not only to protect other Internet users but also to protect the image of Linux.

Testing for rootkit evidence must be done by booting the system from a safe environment that ensures trusted binaries are used in examination of /sbin/init, allows searching the filesystem to find collateral (sk, initlog, initsk12), to ensure any hiding is bypassed, to prohibit tainting evidence by mounting disks readonly and to prohibit any malicious user activity or network traffic to pass. For this I recommend using the HELIX or KNOPPIX (or any other forensic-friendly) Live CD.

* Note that anyone who, confronted with a question about rootkits or being presented possible evidence, takes user, process, directory or filenames at face value without (pointing to) proper investigation (often accompanied by saying "don't worry") has no place in the LQ Linux Security forum or, for that matter, on LQ.
A result is binary: either there is a threat or there is not. Anything else is just dust and air.

The presented logs do not contain any evidence of a SuckIT rootkit infection. If the chkrootkit and Rootkit Hunter scans were done from a Live CD then the chance rootkit-related files still exist is minimal but not impossible if alternative file locations are used or an alternative method of loading SuckIT would be used. To complete the filesystem investigation it is recommended to run filesystem verification, as explained earlier, from a Live CD as well.

To the OP: since this limited examination respresents a significant portion of my time I would appreciate it if you read the above carefully and report back results or questions as soon as possible to facilitate a final conclusion.

All times are GMT -5. The time now is 02:47 AM.