Deanonymizing Windows users and capturing Microsoft and VPN accounts
Long ago, when computers were single core and worked perfectly with 256MB RAM and Windows networks were common, Microsoft guys though of a Single Sign-on mechanism when you enter you password only once on boot and get access to all internal resources without logging in again. It works pretty straightforward: when user tries to access any resource with NTLM authentication (most common authentication method for Windows networks) OS sends domain name, user name and password hash to accessed host. Login/password prompt would appear only if authentication wasn’t successful. As time goes by, it was clear that Single Sign-on implementation wasn’t the best from the security point of view, so Microsoft successfully fixed some issues, some other issues were half-fixed, and another ones are not fixed at all and could be exploited up to this day.
The problem of transmitting account credentials to the SMB server over the internet is one of the not fixed ones. SMB is a widely used protocol used to access network shared files and folders, printers and and so on. This problem is remembered almost every year, the last huge mention was at Blackhat US 2015, seems like Microsoft isn’t going to fix it and it still can be exploited on a Windows 10 with latest updates.
How does it work?
As soon as you open a link to SMB resource using standard browser (Internet Explorer, Edge) or any application which use standard Windows API or Internet Explorer as a HTML renderer (Outlook, Explorer), SMB server instantly captures your account credentials before you see login/password dialog. All the attacker need is to add a link or hidden picture from SMB resource on a webpage or inside an email and — boom!— your account is already in attacker’s hands. For some time it wasn’t considered very bad as the attacker would only get your PC user name, which is usually set to something default, and password, which is not set most of the time. You can hardly use that data to make harm.
The situation drastically changes when we speak about corporate computers with domain accounts. It’s easy to guess what company is this computer from based on domain name, and then, if you can brute force password from hash, you can try to authenticate to internal company resources like email or VPN.
It’s not always needed to brute force the password though. If you know any host with NTLM authentication beforehand, you can proxify the whole authentication process in a real time as soon as the client is connected to your SMB server. If you’re lucky and got in the same network segment as the administrator, you’ll be able to become a domain administrator!
Windows 8 and Microsoft Account
Modern Windows versions are tighly integrated to the internet and almost force you not to create local account but a Microsoft account. Without MS account you won’t be able to access application store, OneDrive and Cortana, and other software would always remind you how it would be great to live with file, settings and email sync if you register one.
All serious researches of this issue have been done in pre-Windows 8 and Microsoft Account era and even in already mentioned Blackhat presentation MS Account was only slightly mentioned. It was found out that Windows 8, 8.1 and 10 would transmit not your local account data but Microsoft Account credentials, which is a lot more fun! So to say, the old security issue which was considered harmful only for business now can be easily used on a home users.
Fresh details
As I was testing this issue, I saw that 3 of older Windows 10 installations work perfectly fine with simplified SMB servers (Responder, Impacket) but the latest installation won’t while still working with fully loaded Samba. Several days later it became clear that for some reason NetBIOS name and Workstation name should be equal to make newer installation work. But if you’re connected using built-in VPN connection protocols (IPsec, PPTP, L2TP) with MSCHAPv2 authentication then Windows would transmit not your account credentials but VPN username and password hash! I supposed that the whole MSCHAPv2 stack is built the same way, but unfortunately this trickdoesn’t work with Wi-Fi WPA-Enterprise (PEAP/MSCHAPv2).
How to use
All right. We learned that anyone who try to open any file or directory from a remote SMB server would automatically transmit account credentials or VPN username/password hash. What should we do with this knowledge?
The most straightforward what can we do it just to set up publicly available SMB server and want for someone. You’ll definitely won’t wait long since the whole routable IPv4 range is constantly being scanned for profit. Scanners are often run on Windows and we’ll be able to know who exactly scans us. For a reason MS accounts on scanners are rare, and it’s unlikely to get access somewhere with local account data. Boring. For hash capturing I would recommend Responder, I’ve added some patches to capture multiple credentials if there are any (set CaptureMultipleCredentials = On in configuration file).
Exploitation for deanonymization is more interesting. The credentials would leak from any PC right after accessing webpage in case of Internet Explorer or viewing email in Outlook. Almost any email web interface filters file:// scheme (it’s a synonym of \\ scheme) but not Yandex — one of the biggest mail provider in Russia. This type of attack is more scary as it gives the attacker not just IP-Username connection but IP-Username-Email connection.
Google Chrome also supports file:// scheme but only if it’s copy-pasted or typed directly in the address bar. The same is true for Firefox, except \\ scheme should be used. As Chrome and Firefox are much more popular then IE, we’ll need some social engineering.
It’s possible to steal accounts for our needs. Some VPN providers use one account for management and VPN connection itself. You can determine VPN account based on client’s IP address. If you got Microsoft Account credentials and brute forced the hash, then you’ll be able to access OneDrive files, Outlook email, Skype account if it was registered with Live account and all the other things.
Of course all the older attacks like SMB Relay are still work.
How to protect outselves?
Don’t think you’re completely safe if you’re not using Internet Explorer and not opening file:// links. It could be just an unsafe application which you run by mistake. The application have no rights to access your credentials directly but it can use standard functions like URLDownloadToFile() to send request to a remote server, and your account is compromised.
The proper way to fix this issue is to create a and apply a .reg file with the following data:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0]
"RestrictReceivingNTLMTraffic"=dword:00000002
"RestrictSendingNTLMTraffic"=dword:00000002Another way is to block all SMB traffic to the internet using Windows firewall. Just black all traffic to TCP port 137, 139 and 445 except to the destination IP ranges:
- 192.168.0.0/16
- 169.254.0.0/16
- 172.16.0.0/12
- 10.0.0.0/8
- fd00::/8
- fe80::/10
Some ISP already block it for you.
The end
I’ve added NTLM hash leak check to ＷＩＴＣＨ？. Try to open it with Internet Explorer or Edge and if your credentials is leaking ＷＩＴＣＨ？ would capture and try to brute force your password using a small dictionary. Try to connect to the VPN beforehand to increase your chances :)
Some VPN providers have been told about this issue and most of them has fixed it by blocking access to SMB ports or by blocking it locally in their client software.
It was a disappointing reveal for me to know that the most popular brute force software can’t properly crack NTLMv2 hashes. Hashcat (the -legacy one) skipped some, John The Ripper with OpenCL does the same, even when the password is 100% in the dictionary. Strange. oclHashCat, Hashcat 3.0 and non-OpenCL implementation in John seems to be working fine. You can only guess how many hashes weren’t brute forced because of these bugs.
