Just by accessing a folder containing a malicious SCF file, a user will unwittingly share his computer's login credentials with an attacker via Google Chrome and the SMB protocol.
This technique is not new, but a combination of two different techniques, one taken from the Stuxnet operation, and one detailed by a security researcher at the Black Hat security conference.
This attack — pieced together by Serbian security researcher Bosko Stankovic of DefenseCode — is centered around SCF files.
SCF stands for Shell Command File and is a file format that supports a very limited set of Windows Explorer commands, such as opening a Windows Explorer window or showing the Desktop. The "Show Desktop" shortcut we all use on a daily basis is an SCF file.
Just like LNK files (shortcuts), SCF files, when stored on disk, will retrieve an icon file when the user loads the file in a Windows Explorer window.
For many years, LNK files were allowed to store the location of their icon file inside a DLL or at an URL. After the Equation Group (cough, NSA, cough) used the ability to load malicious code via LNK files in the Stuxnet attacks, Microsoft patched LNK files to load their icons only from local resources.
The same was not done for SCF files, which were not included in this patch, still being possible to load the icon of an SCF file from the Internet.
Using the knowledge from a 2015 Black Hat presentation, Stankovic created an SCF file that loads its icon image from an URL, at which's end stands an SMB server.
This means that whenever the user's computer will try to load that icon from this SMB server, the server will ask and receive the user's login credentials, the user's computer thinking it needs to authenticate.
The problem is that these SMB requests take place even if users want it or not. The Windows OS is built to load file icons whenever the user navigates to a folder, no questions asked, no user interaction needed.
When the user has navigated to a folder containing a malicious SCF file, in milliseconds, the OS will read the SCF file, make a request to the remote SMB server, and give away the user's credentials in the form of a NTLMv2, NTLMv1, or LM password hash, depending on the user's operating system version.
This is a problem because there are many open-source tools that can crack these types of password hashes, with LM being trivial, and NTLMv2 being the hardest to crack, usually taking days.
Furthermore, for Windows version 8 and after, if the user uses his Microsoft account to log into his computer, the attacker not only gets hold of a user's local PC password hash, but also the hash for other services, such as OneDrive, Outlook.com, Office 365, Office Online, Skype, Xbox Live and others.
But this wouldn't be a problem if users wouldn't have malicious SCF files on their computers. Here is where Google Chrome comes in, the most popular browser on the market today.
Stankovic explains that it's very easy to get an SCF file on users' computers. This is because, in its default configuration, Chrome will automatically download files that it deems safe without prompting the user for a download location. Google deems SCF files as safe, having no reason to prompt the user for action.
Furthermore, the attacker doesn't necessarily need to social engineer users into downloading SCF files on their computers. There are plenty of websites vulnerable to "reflected file downloads" that allows attackers to download files on users' computers. In Chrome's default configuration, which many users utilize, this file will be downloaded to the user's Downloads folder.
Users that notice the download and go to the Downloads folder to inspect this suspicious file will launch the credentials sharing attack without their knowledge, as soon as they open the directory.
As a way to mitigate these types of attacks, Stankovic advises that users configure their Chrome browser to ask where to save each file individually. Users can do this by visiting:
Settings -> Show advanced settings -> Ask where to save each file before downloading
More advanced protection measures include blocking outbound SMB requests via firewalls, so local computers can't query remote SMB servers.