Apache "stealth" process? What is it?

Portal Home > Knowledgebase > Articles Database > Apache "stealth" process? What is it?

Posted by fog, 07-11-2005, 02:38 PM
Can someone tell me what just happened? Background: I run a Linux desktop, but it's also facing the net (port 8080) as a webserver. (For services, it's providing ssh, http, samba, amphetadesk, and webmin. I'm NAT'ed, though, so only port 8080 is actually facing the public.) All of a sudden I couldn't get anywhere online, so I started investigating. While looking at network stats, I happened to notice one of my CPUs was spiked at full usage. top revealed a process known as "stealth" -- owned by user apache -- at 100% CPU usage. Anyone know what this is? Or where it came from? Unless they were really good (somehow breaching the router, getting into the LAN, and attacking me from there), the only port anyone could see was 8080, running Apache, so, assuming this was some exploit, that's how they got in. I'm going to poke through the logs to see if I can find anything. But has anyone seen this before that can offer some help?
Posted by fog, 07-11-2005, 02:42 PM
dehimifier is my hostname) The blue.aol.com is my AIM connection; I signed off right before running it, which apparently put them in CLOSE_WAIT. I'm not sure what's going on with the ircd port. I don't really use IRC. I ran this the first time, note the IRC connection to another host:
Posted by fog, 07-11-2005, 02:47 PM
Methinks someone's gotten in. I stopped Apache, but port 80 and 8080 (and 443) are still open. Playing with netstat options some more: Note that I've got a new connection to Undernet, established. Also note that apache owns it. How do I stop an Apache process that isn't running? Edit: some more fun:
Posted by fog, 07-11-2005, 02:56 PM
Looks like they were working out of /tmp. Some interesting entries: shell.pl Also: In there is the "stealth" process I saw, as well as the "sendmail" that showed up on a ps. Now to come off the net and ensure they can't do any more
Posted by fog, 07-11-2005, 03:17 PM
Okay, my apologies for the barrage of posts. I was sort of freaking out. As it's a desktop box, I have the luxury of just being able to pull it off the network and take my time. (I'm now on a laptop.) What I'm really interested in now is how they got in. I'd have expected it to be over ssh or something, but they really shouldn't have been able to. (Unless first getting into something else on the LAN here.) That "stealth" program is clearly no good: There's also a binary called sendmail, and the bin/bsh that they were running. "Reading" the binary of bin/bsh shows the string "You Have B4CKD0r3d this B0x....", along with references to things like memcpy, stdout, wapipid, strcopy, libc.so.6. (And tons of gibberish, since I'm looking at a binary file in vi.) Do you think (I can't find any information) that this is what was listening on port 80 / 8080 / 443? (I'd opened a telnet session to 80, but no matter what I typed, it didn't do anything.) Can anyone offer me help in tracking exactly how they got in? Last edited by fog; 07-11-2005 at 03:31 PM.
Posted by fog, 07-11-2005, 03:29 PM
Heh, think I found it. (Might I mention I'm suddenly glad I went with mod_log_sql? It's wonderful when you have to go searching.) Someone found me off of search.yahoo.com with a search phrase of "Please enter your cacti user name and password" It looks like older versions (<=0.8.6d) of cacti are vulnerable to remote command execution. Guess who's running 0.8.5a?
Posted by The_Overl, 07-11-2005, 03:51 PM
Geez, you needed a lot of help from here eh? Kiddin, good work though. Next time you want to check out strings in a binary file there is the "strings" command (may or may not be installed) that can be easier than just looking though it with an editor. Typically if you see a box with a lot of junk in /tmp and not-so-carefully hidden processes, you can be almost sure its a vulnerability in a php or cgi script somewhere.
Posted by dreamcarrior, 05-04-2011, 11:09 AM
This is May 4, 2011 and I have the same problem. I found your thread today with the same process running owning nearly 100% CPU. The only difference is that the owner of that process is guest instead of apache. I have Fedora 14, and all packages are up-to-date.

Add to Favourites Print this Article