Since 2003 a large part of my workday has been devoted solely to hacking systems. Over this time I've collected a number of penetration testing tips and plan to write a number of posts to share them. This time I will talk briefly about the annoying NT_STATUS_INVALID_WORKSTATION error that a co-worker noticed during a penetration test. I have seen it occur when you have a valid credential but your access is not allowed--very frustrating for a penetration tester.
Let's say you are doing an internal penetration test and you collect password hashes while spoofing ARP, NetBIOS, LLMNR, ICMP redirect or whatever. You obtained the plain-text password via dictionary attack, brute-forcing, downgrading protocols or forcing clear-text authentication. Then you tried to connect to the target system and received the infamous "NT_STATUS_INVALID_WORKSTATION" error.
root@WS:~/SpiderLabs# smbclient -L -W DCSPL -U RSmith //10.10.5.15
Password: **********
Connection to \\10.10.5.15\C$ failed -
NT_STATUS_INVALID_WORKSTATION
At this point the authentication was valid (correct username / password), but failed to establish a connection to this host because of NT_STATUS_INVALID_WORKSTATION.
This occurs due to a computer restriction set on the Active Directory User Account Object.
As you see above, there is a restriction on the names that are allowed to log with this credential. My experience shows that the most common allowed workstation name is the one from where you collected the credential. For example, if you obtained the credential during a spoofing attack just check the source of the authentication, obtain the NetBIOS name and try use it.
To obtain the NetBIOS name you could use Nmap as seen below:
root@WS:~/SpiderLabs# nmap -sC -sV 10.10.5.15 -p 445
Stats: 0:00:06 elapsed; 0 hosts completed (1 up), 1 undergoing Service Scan
Service scan Timing: About 0.00% done
Nmap scan report for SRVTEST02.spl.com (10.10.5.15)
Host is up (0.00066s latency).
PORT STATE SERVICE VERSION
445/tcp open microsoft-ds?
MAC Address: 00:21:5A:86:B3:C4 (Hewlett-Packard Company)
Host script results:
|_nbstat: NetBIOS name:
Dragon, NetBIOS user: <unknown>, NetBIOS MAC: 00:21:5A:86:B3:C4 (Hewlett-Packard Company)
Nmap done: 1 IP address (1 host up) scanned in 11.73 seconds
Now, let's try connecting again using the NetBIOS name "Dragon."
root@WS:~/SpiderLabs# smbclient -L
-n Dragon -W DCSPL -U RSmith //10.10.5.15
Password: **********
Domain=[DCSPL] OS=[Windows 7 Enterprise 7601 Service Pack 1] Server=[Windows 7 Enterprise 6.1]
Sharename Type Comment
--------- ---- -------
ADMIN$ Disk Remote Admin
C$ Disk Default share
D$ Disk Default share
IPC$ IPC Remote IPC
root@WS:~/SpiderLabs#
At this point, you can access any share or anything you want. Sometimes the NetBIOS name that you obtain from the source connection is not on the list, in that case there are other options such as Exchange CAS, etc. However, what I do in general is port-scan all systems on the internal network for port 445 and extract the NetBIOS name of each computer found. With that information I build a simple script that attempts to connect replacing the NetBIOS name passed to smbclient tool with the names obtained during the port-scanning phase. It has proven to be fast and effective.
If you are interested in more hacking tricks, check other posts:
http://blog.spiderlabs.com/2013/06/wendels-small-hacking-tricks-microsoft-sql-server-edition.html
http://blog.spiderlabs.com/2013/12/wendels-small-hacking-tricks-a-not-so-common-and-neat-oracle-for-windows-hack.html
http://blog.spiderlabs.com/2013/09/wendels-small-hacking-tricks-killing-processes-from-the-microsoft-windows-command-line-interface.html
Stay tuned for more Wendel's Small Hacking Tricks.
