I encountered a spambot, hitting a port somewhere in the 32xxx range, which had the following modus operandi:

• It installed its own rogue /etc/cupsd
• When logged on as root and watching it, the system could and would replace this file every few minutes.
• Another file of identical size was in /etc/logrotate.d ... a binary copy of the rogue.

Which "bot" is this, and where is it documented?

The rogue file is interesting in part because it contains the word "spam" quite liberally inside its carefully-designed content. Obviously a zombie engine. Not easy to see how long it's been there especially if they were monkeying with logrotate.

Grrr... If your hosting company "helpfully" installs Plesk on your machine, beat them severely with a wet noodle. (Coated in battery acid.)

Hi,

Tried to look at the iotop right after the rogue install? This should be interesting...

Hey! Thanks for this thread! I'll follow this one with more than the usual interest...

And, a wet noodle does'nt hurt! You should consider the classic: the board with a nail

Thor

No, this was a virtual server from 1&1 Internet. Not only did they pre-install software that was chock full o' bugs, but it also had many "gratuitous" features (including Plesk itself) which I tried to lock down but obviously missed.

Incidentally, the modus operandi was always the same: it installed or reinstalled a rogue /etc/cupsd file, then spawned the listener, and a few seconds later it was dumping spam somewhere. A very freshly installed and updated ClamAV didn't know anything about it. Unfortunately for me, the rogue software was executing as root.

I also noticed that sshd_config permitted GSSAPI authentication although I don't know why. I haven't quite figured out the attack vector it was using, except for noticing the binary file (of exact size and content) in /etc/logrotate.d.

The maddening thing about these "gratuitous installs," of course, is that you really don't know all of what they are doing; all of what has been installed. I am accustomed to installing Linux more-or-less from scratch on a machine that I can actually touch. But when it's a virtual box in Kansas City, that's a little hard to do.

That means a user, what does the password file say? Is there a 0.0 user in there other that the root?

In /etc/passwd there is no one else with a UID of zero.

In /etc/shadow this field does not apply.

Anywhere else to look? Command to use? (System is ancient, centos-5.)

But I wouldn't have put it past these guys to, say, have monkeyed-around with PAM.

Edit: We also know that no successful login attempts are recorded through last although lastb (failed attempts) is as full as ever. So, whatever it is that "refreshes" these files a few minutes after they're removed, that thing is persistent. We also know that it is not constantly active. And, as I said earlier, we know that ClamAV doesn't seem to see anything wrong. (Not even the obviously rogue /etc/cupsd or the obviously bogus file previously mentioned ... which tells you how useful that kind of software actually is ...)

Is that a webserver? Consider that one (you've seen it on this forum, I'm sure) infected PHP file could spawn a Perl file with the proper rights at any time without the maker even being needed. Nifty but nasty. As soon as the page is called up (by an innocent surfer) the whole ball starts rolling again...

Just thinking out loud...but, still thinking.

Thor

Suggestion: Use auditctl to watch what is opening the file (or directory) and writing to it.

Example:
From there, you should be able to go further. NOTE: this requires you have kernel auditing turned on, and the auditing package.

I simply shot the horse. (Poor dobbin... she was such a nice nag.)

Bam!!! Straite in the kisser! Oh well, may she enjoy LinuxHeaven...where all good Kernels go