- Joined
- Feb 17, 2005
Symantec Noticed a slew of trojan horses, netcat, gethash.exe, ipcscan-gui.exe uploaded to one of our customers servers. This happened around 5:00 am or so on multiple days. I found the ******** ip address, but it is out of an isp in italy.
I doubt we will be able to do anything prosecution wise, but here is what I have found:
He has an epson printer (it tried to install the driver after he rdp'ed in)
He were able to retreive the hashes out of active directory, I have to assume that as Symantec was unable to clean gethash.exe after it had been copied, so again I assume that was because it was running.
He created two accounts, and made them domain admins.
He installed the "HTTP SSH" service, which has been removed.
I ran rootkit revealer, we changed passwords, removed all trojans etc.
My problem now is that while I was looking over the server logs this morning, the only slew of failed auths happened at 5:22 - 5:23 am (a few dozen) from process store.exe trying to auth as the admin account.
Store.exe (the Exchange Info Store) is running as local system, as it should be. I can think of no good reason, and am perhaps being paranoid, but I must ask anyone who might know.
Is it reasonable to assume that store.exe could be compromised? I base this on a few more things:
This guy usually connects around 5-6 am est, which is about 10:00 am in Rome Italy (his source ip)
There were a few dozen attempts right at 5:22 am, all failures to auth as the admin account, they came from the process id of store.exe.
This is an sbs server running exchange sp2, with all *known updates applied. I don't like running exchange on a dc, but it isn't my call. We should change the name of the admin account too, but that also isn't my call.
I am not worried about him guessing the password, lm hashes have been disabled, and the password is a good one.
Any ideas on hardening this box, and could store be compromised? I don't see any good reason for that process to try to auth as anything but local system.
I doubt we will be able to do anything prosecution wise, but here is what I have found:
He has an epson printer (it tried to install the driver after he rdp'ed in)
He were able to retreive the hashes out of active directory, I have to assume that as Symantec was unable to clean gethash.exe after it had been copied, so again I assume that was because it was running.
He created two accounts, and made them domain admins.
He installed the "HTTP SSH" service, which has been removed.
I ran rootkit revealer, we changed passwords, removed all trojans etc.
My problem now is that while I was looking over the server logs this morning, the only slew of failed auths happened at 5:22 - 5:23 am (a few dozen) from process store.exe trying to auth as the admin account.
Store.exe (the Exchange Info Store) is running as local system, as it should be. I can think of no good reason, and am perhaps being paranoid, but I must ask anyone who might know.
Is it reasonable to assume that store.exe could be compromised? I base this on a few more things:
This guy usually connects around 5-6 am est, which is about 10:00 am in Rome Italy (his source ip)
There were a few dozen attempts right at 5:22 am, all failures to auth as the admin account, they came from the process id of store.exe.
This is an sbs server running exchange sp2, with all *known updates applied. I don't like running exchange on a dc, but it isn't my call. We should change the name of the admin account too, but that also isn't my call.
I am not worried about him guessing the password, lm hashes have been disabled, and the password is a good one.
Any ideas on hardening this box, and could store be compromised? I don't see any good reason for that process to try to auth as anything but local system.