Windows AppLocker allows administrators to control which executable files are denied or authorized to execute. AppLocker works well for executables and over time it has also been improved to control various script types, including JScript, PowerShell and VBScript. This has significantly reduced the attack surface and forced attackers, including more sophisticated groups, to find new methods of launching executable code. A number of legitimate Windows executables that are not blocked by the default AppLocker policies has been discovered and various proof of concept AppLocker bypass code became publicly available. Example of malicious scriptlet file used to drop a malicious DLL dropper for the next stage Microsoft allows developers to create COM+ objects in script code stored in an XML document, a so-called scriptlet file. To bypass AppLocker and launching script code within a scriptlet, the attacker includes the malicious code within an XML script tag placed within the registration tag of the scriptlet file and calls cmstp with appropriate parameters. For example: Here, the attackers randomize the scriptlet name and use a .txt filename extension, likely in an attempt to bypass fundamental protection mechanisms that attempt to block file types based on the filename extension. Payload dropper in an XSL file Another executable used to attempt bypass of the AppLocker feature is msxsl.exe, a Windows utility used to run XSL (eXtensible Stylesheet Language) transformations. It takes an XML and an XSL file as a parameter, but it also loads the script engine and runs the script code within the &lt;msxsl:script&gt; tag of the supplied XSL file when invoked through a call placed within the &lt;xsl:value-of&gt; tag. Invoking the JScript code of the payload dropper within an XSL file The supplied XML file seems to be randomly generated and used simply because the second parameter is required and is of no further interest for analysis