Enumerating Users from DC

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!!!!