{"id":1134,"date":"2018-04-09T00:05:25","date_gmt":"2018-04-08T22:05:25","guid":{"rendered":"https:\/\/hitco.at\/blog\/?p=1134"},"modified":"2025-11-27T08:06:53","modified_gmt":"2025-11-27T07:06:53","slug":"howto-prevent-bypassing-applocker-using-alternate-data-streams","status":"publish","type":"post","link":"https:\/\/hitco.at\/blog\/howto-prevent-bypassing-applocker-using-alternate-data-streams\/","title":{"rendered":"How to prevent bypassing AppLocker using Alternate Data Streams"},"content":{"rendered":"

I usually write my blog-posts in german. This one is in english, because Sami Laiho<\/a> asked me to do a short write-up, to make this problem available to a broader audience.<\/p>\n

Who is affected and what’s the problem?<\/h1>\n

If you are using AppLocker<\/strong> Application-Whitelisting using Path-Rules with Exceptions<\/strong> you are probably affected. See the following example to understand, what type of problem we have to fight against.<\/p>\n

Short-Summary – Typical Situation: How to „Design“ an AppLocker Path-Rule:<\/h2>\n

Your unsigned but business-critical application is located in following directory, and writes logs to a subfolder:<\/p>\n

\n
C:\\Program Files (x86)\\DemoApplication\\<\/pre>\n
C:\\Program Files (x86)\\DemoApplication\\logs<\/pre>\n<\/blockquote>\n
As this application is not authenticode-signed, you create an AppLocker path-rule: Allow to execute everything in DemoApplication, but exclude the logs-directory (as this is user-writeable, so otherwise a user or a malicious process could put a binary there and execute it).<\/p>\n
\"AppLocker
AppLocker Exception: Logs Directory<\/figcaption><\/figure>\n
Testing the Rule<\/h2>\n
\"AppLocker:
AppLocker: Execute Binary in Logs-Directory is denied<\/figcaption><\/figure>\n
The rule works as expected. A regular user can copy a binary (like for example SysInternals Tcpview.exe, which I use for demonstration purposes in this example) into the logs-directory, but cannot execute it. AppLocker-eventlog shows, that tcpview.exe (located in the logs-directory) was prevented from running – thats correct behavior:<\/p>\n
\"AppLocker:
AppLocker: Execution Denied – Eventlog<\/figcaption><\/figure>\n
Bypassing AppLocker by using Alternate Data Streams<\/h1>\n
If you are not aware what Alternate Data Streams are, check out this blog-post<\/a>. So, what’s the trick to bypass AppLocker: We copy the contents of an executable to an Alternate Data Stream of the logs-directory. To be clear: Not to a file in the logs-directory, but to an ADS of the logs-directory itself! The copy-job is done using the „type“ command redirecting the output to an ADS. The execution of an ADS can be done by various ways<\/a>, one way would be to use wmic to create a new process, but there are other ways too.<\/p>\n
\"AppLocker<\/a>
AppLocker Bypass: Execute Alternate Data Stream<\/figcaption><\/figure>\n
Looking into eventlog reveals: Yes, that was a straight-forward AppLocker bypass. Applocker saw this execution operation but decided it is „allowed to run“:<\/p>\n
\"AppLocker
AppLocker Bypass: Execute Alternate Data Stream – Eventlog<\/figcaption><\/figure>\n
How to prevent<\/h1>\n
So – bad situation. How to prevent this? Why did AppLocker allow the execution, even if we excluded the logs-directory?<\/p>\n
In fact: We did not<\/strong> exclude the logs-directory! We excluded everything below the logs-directory! We have to add a second exclude-rule „logs:*<\/strong>“ to prevent this:<\/p>\n
\"AppLocker
AppLocker Exception: log-directory, exclude Alternate Data Streams<\/figcaption><\/figure>\n
After inserting this second exception-rule, which excludes all Alternate Data Streams of the logs-Directory from executing, the start of the „Evil-ADS-Binary“ is prevented by AppLocker:<\/p>\n
\"AppLocker:
AppLocker: Alternate Data Streams – Execution prevented<\/figcaption><\/figure>\n
Which Versions of Windows are affected?<\/h1>\n
All versions I tested so far, at least I can say: Every Windows 10 Version – including the newest v1803 Release (final Insider preview, tested on 08. April 2018) are affected.<\/p>\n
Why doesn’t Microsoft prevent this?<\/h1>\n
I don’t know. I reported this behaviour twice. I cannot see any useful or legit case, where executing an Alternate Data Stream is needed. In my opinion there should be a single checkbox „prevent all ADS from being executed“ which should be on by default – but AppLocker doesn’t handle ADS this way I would like to see.<\/p>\n
Is this behaviour a problem? Yes – I really think it is. And I’m not the one who originally „found“ this bug \/ bad behaviour. If you do a google-search<\/a>, you can find other sources explaining this problem<\/a> – not exactly in detail like I did here, but I’m quite sure this is a very well known and commonly used AppLocker-Bypass trick. I think almost nobody of the SysAdmins out there is aware of the fact, that you have to set ACLs on the writeable directories in a way you cannot add ADS, or have to configure two Exclude-Rules for every writeable path. As Microsoft seems not to change AppLocker behaviour, you should be aware of this and maybe double-check your Path-Exclusion-Rules soon!<\/p>\n
Additional Notes<\/h1>\n