Enumerating Users from DC

I have a windows 2003 domain controller that has port 135 - 139 open on the internet. Not my choice, and unfortunatly we cannot close those ports off. We are working through a project to close them off, but we cannot just flip the switch as of this moment.

My main problem is that somehow people are enumerating Valid Domain User accounts from this DC. I have ensured that RestrictAnonomous is set to 2, however when I hit it with Cain I am able to enumerate AD Groups, but not enumerate AD Users by either the SID Scanner or any other way.

Yet still somehow people are getting the users because I keep getting people trying to run password crackers against my DC with valid accounts. Doesn't cause much of a problem except a HUGE headache for locked accounts. I have an alert stup to email me whenever the event logs start to fill with these so I can just block the ip on my firewall.. However when they do this overnight and I walk into 9900 attempts(emails) the phones have already started ringing with lots and lots and lots of locked accounts.

Any ideas would be great. Thanks.

Nessus will do this a number of ways. There are literally hundreds of tools out there that will enumerate AD accounts. Bots do this and so on. The sysinternals site alone has about a dozen tools that will enumerate AD.

Restrict Anonymous is not (as you have learned) foolproof. Hell, you can write something in seconds that will return AD accounts.

AD was not designed to operate on the internet. It also wasn't designed to hide information from queries. It's a directory service which means that it is designed to gladly hand over information when asked.

Whoever made the decision to make RPC and NetBIOS services available to the internet should be fired on the spot. The risk you're exposing your organization to is very high.

--TH13

I definatly understand what your saying and the person who did this(the three people) have left the company already. However, I have hit my server with many nessus scans inside the firewall and outside the firewall and still havn't been able to get a valid list of users.

Does anyone here have a program I can run so I can prove to management that this "close off the ports project" needs to be given higher priority than it has been. I think right now it is a internal office politics issue on why the project is going as slow as it is.

Quote:

---

However, I have hit my server with many nessus scans inside the firewall and outside the firewall and still havn't been able to get a valid list of users.

---

You're doing something wrong.

Try this tool. It's called DumpSec.
http://www.somarsoft.com/cgi-bin/download.pl?DumpAcl

or this
http://www.joeware.net/win/free/tools/lg.htm

Also, your biggest problem here is the RPC port being available (135). There are *tons* of tools that can send queries to the service and get back vital system info. For example, jump on any linux box and use the rpcclient tool with the --command=enumdomusers switch and presto. You have a list of users.

--TH13

I tried using dumpAcl and i still got nothing.

Try the joeware tool.
http://www.joeware.net/win/free/tools/lg.htm

Use the -lu switch.

Also, you need to do this from outside of your network, i.e. from the internet side. Are you doing this?

I guess my question is...why are these open on the internet any way....for some remote app\access??

I think you have to determine why and what is using this...

See if you can customize the app\access to use a different port???

I think if you forward the powers that be the 9000 emails each day....they may get the hint...although... that may overwhelm you mail server resources and wouldnt be a good thing :confused:

MLF

If LG fails, try NBSpyder.
http://www.antiserver.it/Win%20NT/Se...d/NBSpyder.exe

Seriously though, you can simply google "enumerating domain users tools download" and you can DL tons of tools.

Now, the magic question. Have you setup any logging to see where and when these queries are hitting the DC? It may lend some help in figuring out exactly what's happening. Use the native netmon tool that comes with Win32 or Ethereal. Write a filter for the open ports and then simply wait for your fish to bite. My guess is that you are not being targeted directly off the bat, rather, you're getting gleened with automated tools first and then perhaps the attacker becomes so excited that he found someone stupid enough to expose these ports to the internet that he has no fear grinding the hell out of your accounts because the simple fact that these ports are accessable via the internet is a sign that incompetent people are running the box.

--TH13

*EDIT*
I just tried DumpSec and it works fine. Are you selecting the computer under "Report" then selecting "Dump Users"?

I did this in my lab which I quickly set up to mimic your described situation and it did exacty what I expected. It dumped all the accounts.

LG also worked, along with Nessus and NBSpyder.

I used dumpsec and under report selected Sepcify Computer... I tried ip and hostname which I got the following error: Error in processing, NetServerGetInfo status-x00000035

I than goto Dump Users and I only get rc=53 NETUserModalsGet and rc=53 NetUserEnum

Try all of the tools I specified. I had success with all of them.

Nessus would be the best one of all but I have no idea where your scanner is, what version you have, what plugins you're using, etc., etc.

Your other option is to give someone permission to hit your server from the outside and hand you the results. Many folks here have the ability to do this for you. All you have to do is ask in writing and assume all responsibility of failures of any kind.

--Th13

I've got the latest of nessus on a SUSE 9 box. I just ran the update plugins command. I installed via the shell script provided.

It gives me alot of output regarding computers near me and such. However it will not give me any information regarding AD Groups or AD Users. I have enabled all plugins even dangerious ones.

I use the nessus windows client to connect to the server and run the scan and such. I tried the other tools you mentioned and I couldn't get any of them to work.

I would glady give out the IP to the box, but it limits what I can control happening to a box that is in production and being used. I have had another collegue of mine scan the box from his office(completly different company) and we compared the Nessus output. We got exactly the same output with no user accounts and no groups. He is more linux savey so he compiled the install and did it himself without the shell script.

What is the source of the grinding attacks? This will tell you for sure that the attacks are coming from the inside or out. I'm assuming that they are coming from outside. Again, I am able to enumerate an AD controller via RPC calls using the information you've provided.

Anyone else want to attempt this for this poor guy? I can't because of certain Govt. regulations (as most of you are aware).
--TH13

The attacks are definatly coming from the outside. According to the event log ip addresses and who they are registered to.

I can run those programs and enumerate users fine from the inside.. however once inside the network, nothing really touches the firewall unless it goes back out again and tries to come in. However when I try from outside is when I cannot enumerate users, but i can enumerate groups.

Quote:

---

Originally posted here by jbclarkman
I have a windows 2003 domain controller that has port 135 - 139 open on the internet. Not my choice, and unfortunatly we cannot close those ports off. We are working through a project to close them off, but we cannot just flip the switch as of this moment.

---

why he cannot close these open ports as he has privileges to do so, just curious.

Quote:

---

However when I try from outside is when I cannot enumerate users, but i can enumerate groups.

---

If you can enumerate groups, you can enumerate users. No higher priviledges are needed for one or the other. Either it works or it doesn't. Again, the attackers can be using any number of tools to harvest the accounts. My guess still sits with queries via RPC.

The real and *only* solution here is to block those ports from the internet. Until then, you're going to be driven insane over this as more and more kiddies find your host via sweeps.

Again, try an RPC tool such as rpcclient on linus or even this little guy from Bindview:
http://www.bindview.com/Services/raz...1.0-readme.cfm

Walksam is what you'll be interested in.

One last silly question. Is the box fully patched?

--TH13

I believe that Win2k3 by default does not allow anonymous enumeration of AD below the root. Thus these attempts to enumerate users from the public network are probably failing.

walkman externally with a null ipc share did it. It also explains why the first three accounts always keep showing up (They are the first three RID's). At least now I have proof to tell management it really is this easy to get all of our groups and users and such.

Only option is to turn off port 139. However i would like to get 135 - 139 off as well. At least we are getting somewhere.

Thanks for all of your help. You guys rock.

Quote:

---

walkman externally with a null ipc share did it. It also explains why the first three accounts always keep showing up (They are the first three RID's). At least now I have proof to tell management it really is this easy to get all of our groups and users and such.

---

Told ya! ;)

Seriously though, glad to help. Also, you *MUST* cut off the RPC port too. Get ALL of those ports closed. Only bad things can come of leaving them open.

Tiger, null pipes werk on all Win32 hosts including Win2k3 and early builds of vista seem to have this annoyance too.

jbclarkman, let us know what management's response is when you present the evidence.

--TH13

Definatly will do my best to get 135 and the others shut off. THe main reason they were left open was so that users can have access to MS Outlook and such from home. I know bad idea, have them VPN and such. But I didn't create the network... I only inheirted it.

So the main problem withs shutting off 135 is we need to touch all the PC's communicate to the users... blah blah blah.. the ususal stuff... However I don't believe that 139 effects this so I should be able to get a seperate plan setup to just shut 139 off and provide some type better security

Just as a side note... I found out why we didn't have this problem before was because we were using W2k which allows you to set Restrict Anonomous to 2(deny null connections). However when we upgraded to W2k3, it does not allow you to have a value of 2 in the registry. If you put a value of 2, it treats it as a value of 1. Therefore stuff is still open.

Oh dear..... Oh dear, dear me....

Quote:

---

THe main reason they were left open was so that users can have access to MS Outlook and such from home.

---

Google Microsoft Outlook Web Access. It's secure, encrypted, authenticated, requires only one port open, (SSL/443), requires only a web browser from any computer in the world and it's free!!!!

That is my first thought too.. However we have some very PITA people who would loose too much functionality not having full outlook app since not all of our Exchange servers are 2k3 yet. However with exchange 2003 you can almost virtually do everything that the client can minus offline folder use.

My plan in the future once all servers are exchange 2k3 is to Proxy RPC over Port 80 for outlook communication. That seems like a nifty feature of Outlook 2k3/Exchange 2k3

Why not use OWA for external hosts and a real VPN for drive mapping to those external host? Wouldn't this be a hell of a lot more secure?

--Th13