Getting Hacked NOW

So i'm doing my daily admin stuff and I run into about 200 or more log entries all from the same workstation trying just about every account in AD. However all I have is the following

Event Type: Failure Audit
Event Source: Security
Event Category: Account Logon
Event ID: 681
Date: 10/28/2005
Time: 11:32:11 AM
User: NT AUTHORITY\SYSTEM
Computer: NET1
Description:
The logon to account: Accounting
by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
from workstation: GALKENSON
failed. The error code was: 3221226036

I need to find the IP and preferably who the hell is doing this. any ideas would be great

Windows 2000, Active Directory.

HELP

do a nslookup on the workstation name.

if that doesn't work then find your WINS server (assuming you have WINS enabled) and do the lookup manually that way.

Either way you will find the IP address of the offending workstation. Then go visit them and find out what is going on. That box /could/ have been compromised from outside and is a hopping point to the rest of your network.

You could also look at the arp table, the IP information stays around(a short period) even after the connections have dropped. Try "arp -a" it will give you a list of IP's that have connected, your "attacker" may be one of them.

Hi,

The error messages are account lockout responses. I am surprised that the user hasn't complained.

I don't know your naming conventions but do you have a G. Alkenson working there?

I would be inclined to pull the box and scan it in safe mode for malware......................sounds like some sort of bot or backdoor to me? I would definitely take it offline until I had resolved the issue.

:)

we don't have wins enabled, however I located an IP in one of the logs when he tried to hit a local computer account. IP is 82.52.2.153.

I did a winfo 82.52.2.153 -n and got some info, such as user accounts logged in Lucios and other accounts on the machine(Admin, Marcios) as well as what OS - Win2000. However my computer than decided to blue screen and when I returned the null share hole in his computer was fixed, but luckily not before I pulled all the ip addresses that it was connected to

they all had the 82.52 but the last 2 octets changed

2.16
123.53
150.238
127.138
40.159
134.187
156.137
72.124
185.150

I'm in the process of NMAPing and using Nessus to figure out some more info. So far I'm trying to contact the Service provider of that IP range. I believe its isolated to either Italy or Amsterdam.

Quote:

---

Originally posted here by nihil
Hi,

The error messages are account lockout responses. I am surprised that the user hasn't complained.

I don't know your naming conventions but do you have a G. Alkenson working there?

I would be inclined to pull the box and scan it in safe mode for malware......................sounds like some sort of bot or backdoor to me? I would definitely take it offline until I had resolved the issue.

:)

---

yeah he's probably about to have all the users in the AD give him a call because their accounts are locked out. He said it looks to be progressively scanning all user accounts in the AD... so I'm betting someone installed something like Retina on that box and misconfigured it, or there is malware on that box doing something bad, or perhaps the box has been compromised and is being used to scan the network looking for weak passwords (and once again someone misconfigured the utility to do it).

These are just guesses though. I would find the IP address first, then yank it from the network to isolate it. Then sit at the desk and see who calls up complaining :)


actaully I would go visit the box in question after yanking it, but you never know if it is an authorized scan from a different group.

hrm, just saw your response. So you are saying these scans are originating from outside of your network to your internal network?

What kind of firewall are you guys running? Just drop connections from that IP address and be done with it. But then you are going to have to scan your entire network to make sure they didn't get in to anything in there.

just this one box on the inside has an external ip for customer connection purposes.

We used to get this all the time. We ended up using IPSec to block all but the necessary ports to prevent the AD lockout issue. Essentially, that is what this attack is, to lock out your AD accounts. The result is that accounts get locked out and then in about 30 minutes or whatever your settings are, they come back. Problem is, admin and service accounts get nailed, too.

You can block this on the perimeter, to an extent, but the IPSec solution is the best and most effective.

IPSec is a VPN standard, not really a firewall standard or a way to block ports.

It sounds like you have some serious openings that shouldn't be open. Do you have 137-139 open to the internet?

yes 135-139 is open for local outlook taffic for customers(not my recommendation but the company won't change that)

Quote:

---

Originally posted here by zENGER
IPSec is a VPN standard, not really a firewall standard or a way to block ports.

It sounds like you have some serious openings that shouldn't be open. Do you have 137-139 open to the internet?

---

Not everyone gets to play in a whitepaper sandbox. IPSec is a very good tool when you have to be creative. Would I have rather used a different solution? Absolutely! But, it worked.

;)

What IPSec will do for you is, while you don't necessarily close the port 135-139, you limit the connections in and out of the box to specific IP ranges on those ports. Outside attacks can no longer exploit that particular AD vulnerability.

anyone know of a way using windows 2003 to deny this guy from trying again.

If you have 135-139 open to the internet, then you're going to have some major issues.

What I would suggest is to use a VPN solution for your remote customers instead of allowing that traffic straight into the network.

Quote:

---

Originally posted here by jbclarkman
anyone know of a way using windows 2003 to deny this guy from trying again.

---

If you have your Win2k3 AD up, then use your Group Policy tool to set up an IPSec policy. First, the default should be deny all. Then open only those ports you need to specific IP ranges. Make sure you have a list of the apps (AV, SMTP and such) on your network that need ports open for specific traffic. You can tailor the IPSec policy to special case OUs for those situations where you have exceptions to the general rules.

This won't be quick, and will require some planning and testing.

Hope that helps. ;)

wait until the hacker connects again and is inside the machine - then pull its net connection trapping him inside!!!



Thanks bash...../coat

Quote:

---

Originally posted here by jbclarkman
yes 135-139 is open for local outlook taffic for customers(not my recommendation but the company won't change that)

---

Sorry for wagging my finger, and I'm not even sure what your job is at the company, but maybe you should explain to "the company" why having ports 135-139 open on the network is probably a bad idea. Even if you have to have them open, couldn't you at least filter traffic by IP ranges?

@valhallen - LMFAO! "Quick! Catch him with the ether-net!"

@ miracle - If his is an AD/Microsoft shop (which he has basically said), then dopping traffic on those ports inside the network is pretty much a deal breaker for most of the "useability". Not gonna happen.

jbclarkman I won't lecture, and as said we don't know your role/position at the company in question, but its basically professional suicide to allow ANYTHING inside your network in the fasion you've described. You really need to utilize some sort of VPN or Web application service or solution to give your business partners the access they require, without opening yourself to the world.

You *DO* have some solutions at your disposal, if you are a Microsoft shop. Hell, my understanding is the VPN services built into XP/2003 are pretty decent for small scale office use. Don't quote me, but it's cheaper than dropping $12,000 on a Nokia w/ Check Point FW-1 device, or a NetScreen, or something similar. Probably not the best solution, but better than what you've described so far.

To Zencoder:

I suppose I should have clarified that ports 135-139 should not be wide open to being accessed by the OUTSIDE network. Clearly, in a MS/AD network, those ports are necessary internally.

Quote:

---

just this one box on the inside has an external ip for customer connection purposes.

---

The above quote is from the OP. I still don't understand what "customer connection purposes" means, but several others have already suggested tunneling the traffic, which I would also suggest. If that isn't an option, you could still set up IP ranges that are allowed to connect.



To jbclarkman:

Clearly you are in over your head on this one. Find someone that can help you clean up the mess before it gets any uglier.