jetlib.sec » Tags » rpcclient

Post [5] Honorable Mention: Null Sessions

Null sessions are old school. they  used to be useful for pretty much every host in a domain.  Unfortunately, I very rarely run into an environment where all workstations let you connect anonymously AND get data.

Where they can come in useful is

• Against mis-configured servers
• Against domain controllers to pull info

Low? actually a medium...


More than once I've had a PT where a master_browser was exposed to the Internet.  We were able to connect to the server using rpcclient and enumerate users.  After that we had a full list of the users in the domain to conduct external brute forcing attacks with.

If you like pretty pictures, it kinda looks like this, there are command line utilities as well...

Cain uses null sessions by default to try to pull information.  On modern systems this will fail.


But domain controllers/master_browsers do allow this, so if you find yourself in the position to be able to speak with one you can a list of users for the domain




You can then take that list of users and do brute force attacks against various services.  I rarely don't find at least one username/username in an environment.

Tags:  nbsp null domain cain null-sessions brute-force rpcclient Pentesting  

Got asked to help remotely locate local admins on boxes on a network.

rpcclient $> enumalsgroups
Usage: enumalsgroups builtin|domain [access mask]

rpcclient $> enumalsgroups builtin
group:[Administrators] rid:[0x220]
group:[Backup Operators] rid:[0x227]
group:[Guests] rid:[0x222]
group:[Network Configuration Operators] rid:[0x22c]
group:[Power Users] rid:[0x223]
group:[Remote Desktop Users] rid:[0x22b]
group:[Replicator] rid:[0x228]
group:[Users] rid:[0x221]

Now you would think that doing a querygroup would give you the right output, but actually you get a:

rpcclient $> querygroup 0x220
result was NT_STATUS_NO_SUCH_GROUP

Honestly I have no idea why this doesn't work, it *should*. If anyone knows why it doesn't I know more than one person who would like to know.

Anyway it takes one more step but you can do it this way:

rpcclient $> queryaliasmem
Usage: queryaliasmem builtin|domain rid [access mask]

rpcclient $> queryaliasmem builtin 0x220
sid:[S-1-5-21-1214440339-1383384898-839522115-500]
sid:[S-1-5-21-1214440339-1383384898-839522115-1003]
sid:[S-1-5-21-2392188729-2485841371-4291725810-512]

Then you can look up who those SIDs belong to

rpcclient $> lookupsids
Usage: lookupsids [sid1 [sid2 [...]]]

rpcclient $> lookupsids S-1-5-21-1214440339- 1383384898-839522115-500
S-1-5-21-1214440339-1383384898-839522115-500 PC\Administrator (1)

rpcclient $> lookupsids
S-1-5-21-1214440339-1383384898-839522115-1003
S-1-5-21-1214440339-1383384898-839522115-1003 PC\user (1)

rpcclient $> lookupsids
S-1-5-21-2392188729-2485841371-4291725810-512 rpc_api_pipe: Remote machine 192.168.242.128 pipe \lsarpc fnum 0x4001 returned critical error. Error was Call timed out: server did not respond after 10000 milliseconds result was NT_STATUS_IO_TIMEOUT

Not sure about the 512 (its a MS built-in account I think) but the 1003 was the user I added to the local admins group.

Tags:  rpcclient group sid admins-group pc-administrator group-power Pentesting