Today's article has you checking your computer for rootkits.

Nah, even with alternative DNS it was hosed. It was something at my ISP's level and it strangely came back in stages. This domain would work fine, but mine wouldn't. Google worked, but Reddit didn't. I have devices with different DNS enabled. It impacted all devices uniformly. It was a strange, strange outage.

Initially IRC and IMAP worked. I could ping and traceroute the sites that I couldn't reach, but they all got stuck when trying to load them in the browser. It was one of the strangest outages I've had. Before I could browse at all, IRC worked like a champ - and I was still getting emails. Then some of the 'net worked, but not all of it. Then all of the net worked. It must have been something strange at their end.
 


Have you tried turning it off and on again?

I did! That made one router kinda show part of the 'net, but that was probably just coincidental timing.

My ISP used to be pretty awesome. They're still okay, or I'd change them. My old ISP was bought by another company and I've had more issues since that sale happened. I'd still rate 'em well enough, but they're not as good as they used to be.
 
Glad it got resolved quickly. Sounds like an opportunity to... "blame the intern!" ;)
 
Yeah, it was pretty weird. I could ping and traceroute everything, but could only reach a limited set of sites with the browser. Nothing worked and, as mentioned, first IRC and IMAP worked just fine. Then I was able to ping stuff - including domains I couldn't actually reach with the browsers. Eventually everything loaded, but that took hours.

The behavior was universal across a litany of devices, including a 2nd isolated connection to the ISP. (I have my own connection on one line and the 'house' has a 2nd connection.)

How bizarre. It was one of the strangest outages I've ever seen.
 
i've done a little reading up on chkrootkit and have played with my PKKBUILD file which is used by makepkg to download source and create a package. That now puts version 0.55 in /usr/bin and runs from the command line, simple calling "chkrootkit".

When i looked into the source i found in addition to the chkrootkit , ELF 64-bit LSB pie executable, the following check_wtmpx chkdirs chklastlog chkproc chkutmp chkwtmp ifpromisc strings-static. I've now got my pkgbuild file to install the Brazilian Valentine edition 0.55. However when i ran chkrootkit ; the output included :

Code:
Checking `sniffer'... not tested: can't exec ./ifpromisc
Checking `w55808'... not infected
Checking `wted'... not tested: can't exec ./chkwtmp
Checking `scalper'... not infected
Checking `slapper'... not infected
Checking `z2'... not tested: can't exec ./chklastlog
Checking `chkutmp'... not tested: can't exec ./chkutmp
Checking `OSX_RSPLUG'... not tested

You can see that chkrootkit finds a problem launching for instance chkwtmp. From my Googling, the issue is that when chkrootkit runs , it expects the other executable ' s to be in the location at which "make sense" was called.

That would be in my directory "abs" , obviously not in /usr/bin which is where its put in install


Now i got an email back from the developer Nelson Murilo; he was no help with the issue but made/ or alluded to : that using anything that quotes the system path should not be trusted. I think hes saying just run it from the source directory and don't put the executables in places like /usr/bin

The other thing is that if you look at sites by say Igor Ljubuncic the best it seems they can come out with if you get a report of a rookit is to run another rootkit to confirm it. Nobody seems to be able to state- look at this , or compare that , i haven't investigated but i thought maybe systemd might at least be able to report something "new running " that did not previously. So @KGIII people will beat a path to your door /web if you can come up with a couple of golden nuggets on rootkits
 
I'm hoping to play with chkrootkit this weekend. Hoping... I'll be busy tonight and tomorrow, but Sunday is so far fairly free. That's subject to change, but I'm hopeful!
 
this is what i know so far on Rootkits and possibly food for thought ?


Rootkits are complicated and they use different approaches for insurgency . The approach is that they simply exchange existing parts of system with their own modified versions.

The idea of tripwire was that it should be installed immediately after a clean install; then theoretically differences to the system of as it was at install to the present could be compared and any differences looked at for anything suspicious. I noticed that previous opensource code over time stops being opensource with developers maybe “selling out” or deciding they wanted to earn a few pennies from it.

Looks like Tripwire has succumbed to that scenario ; its flagged out of date on the AUR and going to their web site results in seeing a web that has the hand of marketing guys written all over it and classics such as “start for free trial now”.

One alternative was Ossec but looking at https://aur.archlinux.org/packages/ossec-hids/ that's flagged out of date as well.

Aide looks like a possibility https://aur.archlinux.org/packages/aide/ which I will checkout later . Chkrootkit luckily is still going strong; I even got an email back from the developer regarding a custom pkgbuild I’m playing with.


Because rootkits are complicated there’s not actually much out there to read that makes any sense unless your a nuclear physicist with masters degree in calculus. But there iare one of two nuggets out there hopefully @KGIII will add a lot more


What signs might you see if you’ve been hacked ? A rootkit is designed not to reveal itself and even monitors usage of the hard drive so that it can block access to code it had hidden. Its much harder then to identify a rootkit on a running machine and better to run a rootkit scanner maybe from a live OS on a USB to check the laptop its booted from. Thus the OS on the laptop is not running neither is the rootkit, but sins are still there such as modified files.


In terms of running a rootkit scanner such as chkrootkit that's been installed via your OS repo you need to check that its all working since I found that chkrootkit couldn’t launch the supporting executables such as chkutmp, strings-static, chkdirs and so on. If chkrootkit could launch the other executables then that would imply that chkrootkit would use and know the “path” to them. In the email from Nelson Murilo, he stated
If the Unix environment is compromised the PATH would not reliable
.

So maybe instead of running chkrootkit as an installed package from the menu, simply run it directly from the unpacked source directory. There are some tasks to do firs tsuch as running "make sense" .


Although rootkits aim to remain hidden and work so that your Linux system seems the same, hints of intrusion can be that the login process acts differently from usual;system utilities are slower. Another might be unexplained band width usage.

Chkrootkit is one tool that can be used to check for rootkits. False positives are not uncommon, so how d you confirm. One well know writer simply suggest you use another rootkit scanner to confirm. I’m not sure on that one; first choice would have been rkhunter but as we have identified or seemed to have identified on this site; rkhunter does not seem to have been updated. I read somewhere a quote that rkhunter morphed into lynis ?

It seems that if a rootkit is detected the only option maybe a complete wipe and getting stuff you need from say home and back it. How do you know though that what you save is clean ?

[a 2 minute, 3 second read for me KG]
 
Last edited:
I've tossed this as a bookmark into my 'future articles' file. It'd be nice to take the time to do a longer piece on rootkits. They're not as well known but are capable of being the most sinister member of the malware family.
 
I'm the founder and one of the editors of LinuxSecurity.com and author of the original Linux Security HOWTO from 1993. We recently contributed an article on LinuxSecurity about the different types of Linux rootkits and how to detect and tools to remove them. I'd love to hear what you think and how it can be improved.

 
This is my summary... things are wrong
Code:
System checks summary
=====================

File properties checks...
    Files checked: 147
    Suspect files: 1

Rootkit checks...
    Rootkits checked : 478
    Possible rootkits: 3

Applications checks...
    All checks skipped

The system checks took: 2 minutes and 27 seconds

All results have been written to the log file: /var/log/rkhunter.log

One or more warnings have been found while checking the system.
Please check the log file (/var/log/rkhunter.log)

From the log file:

Code:
Checking for hidden files and directories       [ Warning ]
Warning: Hidden directory found: /etc/.java

Code:
Checking for suspicious (large) shared memory segments [ Warning ]
Warning: The following suspicious (large) shared memory segments have been found:
 
Last edited:
I'd love to hear what you think and how it can be improved.

I've skimmed it and it looks like a very, very well written article. I actually went so far as to edit my article to add a link to your site as "Recommended reading:".

My article is a bit dated and only covered one method, so linking to your article just made good sense.
 
Warning: Hidden directory found: /etc/.java

That's just complaining about there being some hidden files. They're most likely Java files and they probably belong there. That'd be a false positive.

Warning: The following suspicious (large) shared memory segments have been found:

You have something using a lot of RAM. Look at your system processes and sort by RAM usage. See anything suspicious? (Probably not...) That'd be just a warning - letting you know to investigate further.
 
I'm running Mint 20.1, and while I was able to download and run it in the Terminal, I encountered some weird glitch in the Software Manager where I could install it but it wouldn't run. I've encountered this issue very rarely in the past when installing things through SM.
 
Hmm... A Mint thing, perhaps? That might be worth starting a thread to ask as there are some Mint peculiarities from time to time. The only Mint I use on bare metal is LMDE.
 
@gossamer i was playing with chkrootkit a while back using it to experiment with a custom PKBUILD - I was figuring out what did what having jumped from Slackware to Arch.

Basically with an Arch PKGBUILD file , chkrootkit , itself (POSIX shell script, ASCII text executable
) gets located to /usr/bin . (also supporting executables but see below)

Thats after running makepkg -s of course on the PKGBUILD file and installing the .zst that results from the action of makepkg



I got my PKGBUILD working and noted on running i got :

Code:
Checking `wted'... not tested: can't exec ./chkwtmp
Checking `z2'... not tested: can't exec ./chklastlog
Checking `chkutmp'... not tested: can't exec ./chkutmp


I sent an email to one the developers and got a reply from Nelson Murilo . Who stated :

I’m not familiar with Arch Linux packing structure, but anyway, the reason is avoid to use the regular system PATH.
If the Unix environment is compromised, the PATH would not reliable.


i found that if i did run the chkrootkit executable from the unzipped directory then , chkwtmp, chklastlog and chkutmp all worked fine. i was going to continue to try to get all working from an installation , then realised it would be pointless anyway since, whats mentioned in the article and nelson is also alluding to is that chkrootkit should never be "installed" on a system but instead run from a location outside the Linux OS.





the other point in the article is that "it is a good idea to have ClamAv" - my thinking is , well it can't do any harm. I'm thinking most on this forum think ClamAv a waste of time ?


Rkhunter doesn't seem to be maintained anymore, so maybe that program can be considered "iffy"
A lot of articles I have read state; if you think you have a rootkit using chkrootkit, well confirm that by running Rkhunter ,which seems a bit amateurish to me.

probably the main issue with rootkits are, they are flipping complicated to get your head around unless your a kernel hacker (most are not)
 
Last edited:
The majority of people (according to the research I read) tend to not read anything longer than six minutes. It's also why I give a time estimate.

While it's true that people have tasks they need to complete like work, chores, child-rearing, paying bills, and home improvement projects, maybe they shouldn't waste 1-2 hours on social media whenever they get online
 
Here's my summary:

Code:
[11:06:34] System checks summary
[11:06:34] =====================
[11:06:34]
[11:06:34] File properties checks...
[11:06:34] Files checked: 147
[11:06:34] Suspect files: 1
[11:06:34]
[11:06:34] Rootkit checks...
[11:06:34] Rootkits checked : 478
[11:06:34] Possible rootkits: 6
[11:06:34]
[11:06:34] Applications checks...
[11:06:34] All checks skipped
[11:06:34]
[11:06:34] The system checks took: 8 minutes and 29 seconds
[11:06:34]
[11:06:34] Info: End date is Fri 15 Oct 2021 11:06:34 AM CDT

If I were to have any rootkits or other viruses on my system, how I would quarantine?
 
how I would quarantine?

That'd depend on how the rootkit worked. If you're afflicted with one, and warnings don't mean you are, then your best option is to backup and then do a clean installation - then being extremely careful restoring your data. I suppose you could take away its permission to write or execute, but a clean install would be your best option.
 
You'd want to verify the integrity of every executable file - or not restore them at all. You can use sites like Virus Total to scan anything executable.
 

Members online


Top