Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

A few days ago my website got hacked and a malicious file called images.pl was uploaded which creates a backdoor that allows the file's author to upload/download/do whatever they want. Later I found out it contains PHP.C99-7.

I noticed this file, created a backup of the website's content and then removed the file. The backup is on my MacBook Pro (running Mountain Lion). The same day my MBP started acting funny. I called off work as a security precaution (I'm a website developer) so I can do damage control.

I did a full ClamXav scan on the MBP (ML latest version with latest security release), but it found nothing out of the ordinary, except the php file which ClamXav identified as PHP.C99-7. The file was moved to quarantine.

I decided I should make sure the MBP doesn't have any more malware, since that was a backdoor after all. I shut it down, boot into target disk mode and then run another ClamXav scan with my 2007 Intel Mac Pro (G5) (running OS X 10.6.8). 5 hours later, no results. 5 hours 5 minutes later 17 infections found. The files were moved to quarantine on my Mac Pro.

2 days later (today) the Mac Pro starts acting funny. I get a bunch of errors about .kext files being misconfigured or something. I shut it down and press Command+Option+Shift+Power until I get blinky lights. Then press Command+Option+P+R and hold until I hear three chimes. Finally press Command+V just to be sure, but at this point I get abnormal output:

 Bug: launchctl.c :3576 (25952):17: ioctl(s6, SIOCAIFADDR_IN6, &ifra6 != -1 
 running fsck on the boot volume...
 csrusbbluetooth blah (is normal)
 Executing fsck_hfs (version diskdev_cmds-491.6~3).
 hfs: Removed 1 orphaned / unlinked files and 0 directories
 -crucial filesystem check: fixing bogus GID 80 on path: /sbin/launchd
 -(a)crucial filesystem check: adding missing mode bits 01002 on path: /tmp/
 -(b)crucial filesystem check: fixing bogus GID 80 on path: /tmp/

Repeat (a) and (b) with:

 /var/tmp/
 /var/folders
 /var/db/launchd.db
 /var/db/launchd.db/com.apple.launchd
 launchctl: Dubious permissions on file (skipping): /Library/LaunchDaemons
 launchctl: Dubious permissions on file (skipping): /System/Library/LaunchDaemons
 launchctl: Dubious permissions on file (skipping): /etc/mach_init.d

And then nothing happens, it just stays on that last line.

I have not done single user or safe mode yet, will report back when I do, but meanwhile does anyone know what any of that means and how can I fix it?

share|improve this question
    
Safe mode didn't work- stuck at the apple. – Andrew Luhring Oct 16 '12 at 17:34
    
Single-User mode works, but now I have no idea what to do... – Andrew Luhring Oct 16 '12 at 17:37
    
thanks for the edit. – Andrew Luhring Oct 16 '12 at 17:49
1  
nope. from what i remember, the next i did was run repair disk permissions. i think stuff in launchd are programs that execute at launch, so one thing you might try would be to start your (potentially infected) mac in target disk mode, and repair its disk permissions remotely ( so as to avoid running the program that executes at launch). – Andrew Luhring Jan 6 at 23:14
1  
pretty sure that at the end of the day what i ended up doing was- i made a backup of my computer, and reinstalled osx. in retrospect im pretty sure that part was unnecessary for the sake of the exploit (it was a php backdoor... if your computer is a server, thats a different story, but on just a computer that isn't a server, i'm pretty sure its harmless) ... i ended up nuking it to fix the permissions stuff and other problems that started arising when i went in over my head in single user mode. – Andrew Luhring Jan 6 at 23:22

You must log in to answer this question.

Browse other questions tagged .