Indeed.


Auch!



When you work with regexes a "greedy match" means the search term is not refined meaning it'll return more than it should. The reason for that is there wasn't enough information, not enough time or not enough feedback to refine things.


They are likely false positives.
If you want to make certain you could compare those files (SHA256?) hashes with the hashes created from known good package contents on a repository.


No, "unofficial" means these are signatures not included in ClamAV or any 3rd-party ClamAV signature databases provider like Sanesecurity, MalwarePatrol, INetMsg, etc, etc.


Because RKH is a post-op tool, because the signatures are for very specific situations and because they aren't as refined as they should be, it would not make sense to have them used by default as it will only confuse users so I explicitly left that functionality out.


It is never safe until you have either verified or visually inspected files. For text-based files in/etc comparing hashes is easy to do and for binary files it's imperative. (Needless to say any files used for system startup, cron jobs, login or related to providing any access to the system are suspect and should rather come from the installation. If comparing hashes then show a match you discard the "old" file, if they don't you inspect them with say 'diff' to find the cause of the change.) /home is a different situation because we do not know the infection vector and no distribution comes with hashes for that kind of content plus you don't have any backups to compare against. I'd be cautious and visually inspect files individually before introducing them in the system.

I would selectively copy the /etc/ config files you have personally adjusted. Then examine them to ensure nothing is incorrect, making sure nothing got appended to the file (or anywhere else in it)

As for home files, copy over the ones you know you'll need. Making sure executable bits are not permitted on files would be a good idea and browsing through to make sure it doesn't look changed. As unspawn said, checksum checks would defintely be the best way to go here - but that really only works if you had them prior to this all happening.
For you to get "re-infected" you would have to run a exectuable file with script to run the install script for the malware, as root.

In the future, intrusion detection software may be of use to you. I haven't used it, but you could try tripwire
Obviously, never letting them in is better. But it could save a lot more headache next time.

Should be the other way around: compare files first and if found OK then copy.


You don't know the infection vector so that's speculation.


Running Ckrootkit, Rootkit Hunter, any file system integrity checker (personally I'd suggest Samhain: see previous posts of mine) or any other post-incident tool amounts to just that: after the fact alerting / breach confirmation. Indeed prevention is better. The OP should start by reading his Linux distributions user and security documentation.

*Do note this forum also has some security references.

Brilliant thread. I learned alot from this. Thanks to everyone for their meticulous and informative responses.

Great analysis, though sorry for the necro. I had not ever heard of a Linux desktop being compromised like this in all my 15 years using Linux. Servers compromised, yes, due to not being patched, but never a desktop!

Ok, good job on finding the exploit and managing it, but I am still not clear about the initial break in. From what I have gleamed thus far, is there a MySQL server running on this system? You may want to further secure the mysql user account in linux to prevent access to bash?

Triggering a shell script from MySQL
https://patternbuffer.wordpress.com/...pt-from-mysql/

Anatomy of an attack: Gaining Reverse Shell from SQL injection
http://resources.infosecinstitute.co...sql-injection/