I absolutely adore the Server Message Block (SMB) protocol. Sure, it's ugly and bewilderingly complex. But, what I love is the raw power SMB provides for manipulating Windows environments during a penetration test. Via SMB, you can remotely access file shares, the registry, services, domain authentication, and much more! What's not to like? Well, the ugliness and complexity, but we can overlook those with a few good tools, right?
One of the best tools for thoroughly plundering a Windows target via SMB is the Linux rpcclient command, part of the Samba suite. The rpcclient program was originally designed for troubleshooting and debugging Windows and Linux Samba daemon configurations, but we can leverage its capabilities in a penetration test (or even a vulnerability assessment or audit) to gather some awesome info.
Chris Gates, at the Carnal0wnage blog, posted a few excellent articles (including this one here and another one here) about using rpcclient to interrogate target Windows machines across NULL SMB sessions. A NULL SMB session has a blank user name and a blank password. However, most modern Windows systems by default prohibit enumerating detailed user information across a NULL SMB session (controlled by the HKLM\System\CurrentControlSet\Control\Lsa\RestrictAnonymous, RestrictAnonymousSAM, and EveryoneIncludesAnonymous registry keys).
Some pen testers I've met think that because NULL sessions are increasingly extinct, stuff like rpcclient isn't useful. But, hey? as long as you have just one user name and its associated password (local or domain) for the target environment, you can make AUTHENTICATED SMB sessions (non-NULL). Even if your user and password are NOT in the admin group or domain admin group, you can still get a HUGE amount of information via an authenticated, non-admin SMB session to a target machine in the environment, plundering all kinds of stuff, including user names, group memberships, Security Identifiers (SIDs), and even last logon events. I'd like to show you how, as well as how a defender can squelch incoming SMB sessions in real-time on a Windows box.
First, you'll need to get a user name and password. In a crystal box penetration test or an internal audit, you may be given one by target system personnel as part of your planning activities. If not, try to ask for one, explaining that you want to see if this limited user can break out of their constraints and take over the target environment, modeling what would happen if an insider tries to attack, or an outsider exploits an employee's account.
If those arguments still don't get you a non-admin user name and password, you could try to do some brute force guessing, using a tool like Metasploit's auxiliary/scanner/smb/smb_login module, which can be configured to do guessing of passwords from a list.
Once you have a user name and password and open SMB access of a target Windows client or server over TCP port 445, you can use rpcclient to open an authenticated SMB session to a target machine by running the following command on your Linux system (rpcclient is built into many Linux distros by default):
$ rpcclient —U <username> <winipaddr>
If you had used a NULL Session, you would have entered a username of "". But, instead, use a real user name (which doesn't have to be in the admin group). When prompted for the password, enter it, and you'll see the funky rpcclient prompt (I say it is funky, because of it's $> notation):
rpcclient $>
Now, you have a whole freaking candy store of yummy SMB commands at your fingertips. Just type "help" to see all of the over 100 commands. Yeouch. Nice.
(I have seen, on rare occasions, rpcclient refuse to connect unless it has the name of the target Windows machine inside of /etc/hosts. If it doesn't work, simply append into /etc/hosts a line that has the IP address of the target Windows machine and the hostname of that machine.)
I'd like to show you some of the most useful commands within rpcclient. First off, let's get the version of the target Windows machine:
rpcclient $> srvinfo 10.10.76.1 Wk Sv NT PtB platform_id : 500 os version : 6.2 server type : 0x11003
You can look up the different server version types here. As we can see, we've got an OS version of 6.2, so it's a Windows 8 or Windows Server 2012 machine. In this case, it just so happens to be Windows 8.
Now, let's slurp up some users. Start by typing "enum" at the prompt and hitting <tab><tab>:
rpcclient $> enum enumalsgroups enumdomains enumdrivers enumkey enumprivs enumdata enumdomgroups enumforms enumports enumtrust enumdataex enumdomusers enumjobs enumprinter
Nice! On most Linuxes, we have tab auto-complete of commands, which extends into rpcclient commands. And, yes, this little rpcclient shell can clear the screen with a CTRL-L. To enumerate users, run the following command:
rpcclient $> enumdomusers user:[Administrator] rid:[0x1f4] user:[Fred] rid:[0x3e9] user:[Guest] rid:[0x1f5] user:[HomeGroupUser$] rid:[0x3eb] user:[lab] rid:[0x3ec] user:[stuff] rid:[0x3f1] user:[test] rid:[0x3f5]
Here, we can see the user names as well as their RID (the suffix of their SID) in hexadecimal form.
Now, let's look at groups. For this, we'll first enumerate domain groups (with "enumalsgroups domain") and then builtin groups (with "enumalsgroups builtin"). The union of these two sets are the groups that this target knows about. By the way, the "als" between enum and groups in this command refers to "aliases". Windows treats some group names as aliases.
rpcclient $> enumalsgroups domain group:[HomeUsers] rid:[0x3ea] group:[WinRMRemoteWMIUsers__] rid:[0x3e8] rpcclient $> enumalsgroups builtin group:[Administrators] rid:[0x220] group:[Backup Operators] rid:[0x227] group:[Cryptographic Operators] rid:[0x239] group:[Event Log Readers] rid:[0x23d] group:[Guests] rid:[0x222] group:[Hyper-V Administrators] rid:[0x242] group:[IIS_IUSRS] rid:[0x238] group:[Power Users] rid:[0x223] group:[Remote Desktop Users] rid:[0x22b] group:[Remote Management Users] rid:[0x244] group:[Users] rid:[0x221]
Again, we see the group name and the RID for each group.
To determine a full SID, you could run the "lookupnames" command. Here, I'll do it for the administrator account and then the administrators group:
rpcclient $> lookupnames administrators administrators S-1-5-32-544 (Local Group: 4) rpcclient $> lookupnames administrator administrator S-1-5-21-728759338-17244630-2184799192-500 (User: 1)
There is likewise a lookupsids command that converts a SID to a username.
Now, wanna see something really cool? We can use the queryuser command to get all kinds of details about an individual user based solely on the user's RID in decimal form (rpcclient annoyingly switches between hex RIDs and decimal RIDs in its output and between different commands). Remember how the original admin user on a Windows machine has a RID of 500, no matter the current user's name? Well, watch this:
rpcclient $> queryuser 500 User Name : Administrator Full Name : Home Drive : Dir Drive : Profile Path: Logon Script: Description : Built-in account for administering the computer/domain Workstations: Comment : Remote Dial : Logon Time : Thu, 26 Jul 2012 03:22:17 EDT Logoff Time : Wed, 31 Dec 1969 19:00:00 EST Kickoff Time : Wed, 31 Dec 1969 19:00:00 EST Password last set Time : Thu, 26 Jul 2012 03:27:04 EDT Password can change Time : Wed, 31 Dec 1969 19:00:00 EST Password must change Time: never unknown_2[0..31]... user_rid : 0x1f4 group_rid: 0x201 acb_info : 0x00000211 fields_present: 0x00ffffff logon_divs: 168 bad_password_count: 0x00000000 logon_count: 0x00000001 padding1[0..7]... logon_hrs[0..21]...
Note here that the output shows the last logon time for the user, as well as the Password last set Time. That kind of stuff is immensely valuable for auditors and penetration testers alike. And, the best part here is that you can get all of this information without an admin user name and password. With simply a non-admin account and SMB access, rpcclient can plunder all of this and much more from a target Windows machine. Note that the Dec 1969 dates are references to fields that are not set by Windows.
I'd like to encourage you to explore rpcclient further, checking out the multitude of additional commands and applying them in clever ways in your own penetration testing, vulnerability assessment, and audit work. If you come up with something cool, please let us know in the comments below.
Oh, and as a final note, if you are ever on a Windows machine and suspect that someone has established a nasty SMB session to you, you can get a list of all inbound SMB sessions into your machine by running the following command on Windows:
C:\> net session Computer User name Client Type Opens Idle time ------------------------------------------------------- \10.10.75.2 TEST Unix 6 00:02:53 The command completed successfully.
Check out that Client Type: Unix. Nice. Our attacker is using Samba tools.
You can squash that SMB session coming into your Windows by running:
C:\> net session \[LinuxIPaddr] /del
You'll be prompted to verify you really want tear this session down. Hit y and it'll go away. Or, if you use a /y in the original command, it won't even prompt you before killing the session.
Now that I've killed that session, let's see what happens with good old Mr. rpcclient when I try to run an srvinfo again over on my Linux box:
rpcclient $> srvinfo write_data: write failure. Error = Connection reset by peer write_socket: Error writing 158 bytes to socket 3: ERRNO = Connection reset by peer Error writing 158 bytes to client. -1 (Connection reset by peer) rpc_api_pipe: Remote machine 10.10.76.1 pipe \srvsvc fnum 0x4001 returned critical error. Error was Write error: Connection reset by peer result was DOS code 0x0000003b rpcclient $>
Bah! Windows killed the SMB session, shutting rpcclient out.
Of course, the attacker can jump back in with rpcclient again. The defender can block that by configuring the built-in Windows firewall to block TCP port 445, but that would block any legit user's inbound SMB session. If you'd like to have a little more fun as a defender, you can play whack-a-mole with SMB sessions, using a Windows FOR loop to kill SMB sessions from your attacker every 1 second. That's sure to make the attacker scratch his head in annoyance:
C:\> FOR /L %i in (1,0,2) do @net session \[LinuxIPaddr] /del /y & ping -n 2 127.0.0.1>nul
Here, I'm running a FOR /L loop, which is a counter. It starts counting at 1, counts in steps of 0, up to 2. Thus, it'll keep running forever if we want it to. I declare a %i iterator variable that I don't ever use, but the syntax requires me to declare it. At each iteration of the loop, I drop the SMB session and then ping localhost twice, which introduces a 1-second delay. The first ping happens nearly instantly, the second one happens one second later. Our attacker will make a session, it'll last for a second, and then get blown up.
If you like this kind of topic, I'd encourage you to take a SANS Penetration Testing course, such as our SANS SEC504 course on Hacker Attacks, Exploits, and Incident Handling or our SANS SEC560 course on Network Penetration Testing and Ethical Hacking. You can take the courses anytime, online, OnDemand.
Thank you-
-Ed Skoudis
SANS Pen Test Curriculum Lead
Founder, Counter Hack
Director, SANS NetWars & CyberCity Projects
