Grey bar Blue bar
Share this:

Wed, 4 Mar 2015

SensePost Training

Over those years, we've trained thousands of students in the art of offensive and defensive security through our Hacking by Numbers courses.

Our courses are taken directly from the work we do. When we compromise networks, or applications with new techniques, they're turned into modules in the appropriate course. We also don't use trainers; every course is given by one of our analysts to keep it authentic.

For our fifteenth year, we've decided it was time to retire the ‘Hacking by Numbers' name and just call it was it really always has been: SensePost Training.

We've also simplified the path to offensive security mastery with our artisanal, fair trade, hand crafted training courses:



The beginner course lies at the start of the journey. This course doesn't assume anything of the student other than desire to learn. The course will present the background information, technical skill and basic concepts to get a student going in the field of information security (we can't bring ourselves to say “cyber”).

Students will start at learning how to use the command line interface for Linux to get the best out of an offensive Linux tool-set, then delve into networking fundamentals and vulnerability discovery and finally, learn how to exploit common weaknesses within the network, application, mobile and wireless arenas.

The course will serve those wanting to understand the offensive security world as well as those looking to join it. It's a fun course with plenty of hands on exploitation and owning stuff. For more information, visit Blackhat's USA training page here.


‘A journeyman is an individual who has completed an apprenticeship and is fully educated in a trade or craft, but not yet a master' Wikipedia.

The Journeyman layer is where you learn the trade in order to become a master. This layer is where our decade and a half of experience in gaining access to everything from ships to data centers is most evident. Each of the journeyman courses are hands on, fully interactive and teach the latest approaches and techniques for exploiting everything! We've completely revamped the courses and our analysts typically add new techniques as they happen, sometimes even during the course.

The journeyman series contain several courses focused on specific areas of specialisation, from hacking networks and applications, to securing code, to signals (wireless) and advanced second order compromises (spec ops).

If you are looking to expand your skill-set then these courses are for you.


At the top of the learning tree is our brand new Master course. This course is aimed at those students who've completed one or more of the Journeyman courses, or are working senior penetration. Nmap's man page, Metasploits internals, or network pivoting should not be new concepts.

This course sets about teaching students how to hack like an APT; with strong offensive focus drawing on the techniques employed in recent industry hacks. Students will be thrown into environments they've never seen before, and forced to rely on wits, or shown how to turn the mundane into the extraordinary.

To learn more about this course being offered at Blackhat USA, head over to here.


When you love what you do, you love showing others how to do it; training is at the heart of what we do at SensePost. Using our decade of BlackHat training experience, we've put a lot of thought into creating some awesome courses for our fellow hackers. We hope to seeing you in one at BlackHat USA Las Vegas 2015.

Fri, 13 Jun 2014

Using Maltego to explore threat & vulnerability data

This blog post is about the process we went through trying to better interpret the masses of scan results that automated vulnerability scanners and centralised logging systems produce. A good example of the value in getting actionable items out of this data is the recent Target compromise. Their scanning solutions detected the threat that lead to their compromise, but no humans intervened. It's suspected that too many security alerts were being generated on a regular basis to act upon.

The goal of our experiment was to steer away from the usual data interrogation questions of "What are the top N vulnerabilities my scanner has flagged with a high threat?" towards questions like "For how many of my vulnerabilities do public exploits exist?". Near the end of this exercise we stumbled across this BSides talk "Stop Fixing All The Things". Theses researchers took a similar view-point: "As security practitioners, we care about which vulnerabilities matter". Their blog post and video are definitely worth having a look at.

At SensePost we have a Managed Vulnerability Scanning service (MVS). It incorporates numerous scanning agents (e.g. Nessus, Nmap, Netsparker and a few others), and exposes an API to interact with the results. This was our starting point to explore threat related data. We could then couple this data with remote data sources (e.g. CVE data, data).

We chose to use Maltego to explore the data as it's an incredibly powerful data exploration and visualisation tool, and writing transforms is straight forward. If you'd like to know more about Maltego here are some useful references:

What we ended up building were:

  • Transforms to explore our MVS data

  • A CVE / API engine

  • Transforms to correlate between scanner data and the created APIs

  • Maltego Machines to combine our transforms

So far our API is able to query a database populated from CVE XML files and data from (they were kind enough to give us access to their CVE inclusive data set). It's a standalone Python program that pulls down the XML files, populates a local database, and then exposes a REST API. We're working on incorporating other sources - threat feeds, other logging/scanning systems. Let us know if you have any ideas. Here's the API in action:

Parsing CVE XML data and exposing REST API
Parsing CVE XML data and exposing REST API

Querying a CVE. We see 4 public exploits are available.
Querying a CVE. We see 4 public exploits are available.

It's also worth noting that for the demonstrations that follow we've obscured our clients' names by applying a salted 'human readable hash' to their names. A side effect is that you'll notice some rather humorous entries in the images and videos that follow.

Jumping into the interesting results, these are some of the tasks that we can perform:

  • Show me all hosts that have a critical vulnerability within the last 30 days

  • Show me vulnerable hosts for which public exploit code exists

  • Show me all hosts for which a vulnerability exists that has the word 'jmx-console' in the description

  • Show me all hosts on in my DMZ that have port 443 open

  • Given a discovered vulnerability on a host, show me all other hosts with the same vulnerability

  • Show me a single diagram depicting every MVS client, weighted by the threat of all scans within the last week

  • Show me a single diagram depicting every MVS client, weighted by the availability of public exploit code

  • Given a CPE, show me all hosts that match it

Clicking the links in the above scenarios will display a screenshot of a solution. Additionally, two video demonstrations with dialog are below.

Retrieving all recent vulnerabilities for a client 'Bravo Tango', and checking one of them to see if there's public exploit code available.
Retrieving all recent vulnerabilities for a client 'Bravo Tango', and checking one of them to see if there's public exploit code available.

Exploring which clients/hosts have which ports open
Exploring which clients/hosts have which ports open

In summary, building 'clever tools' that allow you to combine human insight can be powerful. An experiences analyst with the ability to ask the right questions, and building tools that allows answers to be easily extracted, yields actionable tasks in less time. We're going to start using this approach internally to find new ways to explore the vulnerability data sets of our scanning clients and see how it goes.

In the future, we're working on incorporating other data sources (e.g. LogRhythm, Skybox). We're also upgrading our MVS API - you'll notice a lot of the Maltego queries are cumbersome and slow due to its current linear exploration approach.

The source code for the API, the somewhat PoC Maltego transforms, and the MVS (BroadView) API can be downloaded from our GitHub page, and the MVS API from here. You'll need a paid subscription to incorporate the data, but it's an initiative definitely worth supporting with a very fair pricing model. They do put significant effort in correlating CVEs. See this page for more information.

Do get in touch with us (or comment below) if you'd like to know more about the technical details, chat about the API (or expand on it), if this is a solution you'd like to deploy, or if you'd just like to say "Hi".

Wed, 12 Feb 2014


Hey all,

So following on from my talk (slides, video) I am releasing the NMAP service probes and the Poison Ivy NSE script as well as the DarkComet config extractor.

An example of finding and extracting Camellia key from live Poison Ivy C2's:
nmap -sV -Pn --versiondb=nmap-service-probes.pi --script=poison-ivy.nse <ip_address/range)
Finding Poison Ivy, DarkComet and/or Xtreme RAT C2's:
nmap -sV -Pn --versiondb=nmap-service-probes.pi <ip_range>

If you have any questions, please contact

Thu, 6 Jun 2013

A software level analysis of TrustZone OS and Trustlets in Samsung Galaxy Phone


New types of mobile applications based on Trusted Execution Environments (TEE) and most notably ARM TrustZone micro-kernels are emerging which require new types of security assessment tools and techniques. In this blog post we review an example TrustZone application on a Galaxy S3 phone and demonstrate how to capture communication between the Android application and TrustZone OS using an instrumented version of the Mobicore Android library. We also present a security issue in the Mobicore kernel driver that could allow unauthorised communication between low privileged Android processes and Mobicore enabled kernel drivers such as an IPSEC driver.

Mobicore OS :

The Samsung Galaxy S III was the first mobile phone that utilized ARM TrustZone feature to host and run a secure micro-kernel on the application processor. This kernel named Mobicore is isolated from the handset's Android operating system in the CPU design level. Mobicore is a micro-kernel developed by Giesecke & Devrient GmbH (G&D) which uses TrustZone security extension of ARM processors to create a secure program execution and data storage environment which sits next to the rich operating system (Android, Windows , iOS) of the Mobile phone or tablet. The following figure published by G&D demonstrates Mobicore's architecture :

Overview of Mobicore (courtesy of G&D)

A TrustZone enabled processor provides "Hardware level Isolation" of the above "Normal World" (NWd) and "Secure World" (SWd) , meaning that the "Secure World" OS (Mobicore) and programs running on top of it are immune against software attacks from the "Normal World" as well as wide range of hardware attacks on the chip. This forms a "trusted execution environment" (TEE) for security critical application such as digital wallets, electronic IDs, Digital Rights Management and etc. The non-critical part of those applications such as the user interface can run in the "Normal World" operating system while the critical code, private encryption keys and sensitive I/O operations such as "PIN code entry by user" are handled by the "Secure World". By doing so, the application and its sensitive data would be protected against unauthorized access even if the "Normal World" operating system was fully compromised by the attacker, as he wouldn't be able to gain access to the critical part of the application which is running in the secure world.

Mobicore API:

The security critical applications that run inside Mobicore OS are referred to as trustlets and are developed by third-parties such as banks and content providers. The trustlet software development kit includes library files to develop, test and deploy trustlets as well as Android applications that communicate with relevant trustlets via Mobicore API for Android. Trustlets need to be encrypted, digitally signed and then remotely provisioned by G&D on the target mobile phone(s). Mobicore API for Android consists of the following 3 components:

1) Mobicore client library located at /system/lib/ This is the library file used by Android OS or Dalvik applications to establish communication sessions with trustlets on the secure world

2) Mobicore Daemon located at /system/bin/mcDriverDaemon: This service proxies Mobicore commands and responses between NWd and SWd via Mobicore device driver

3) Mobicore device driver: Registers /dev/mobicore device and performs ARM Secure Monitor Calls (SMC) to switch the context from NWd to SWd

The source code for the above components can be downloaded from Google Code. I enabled the verbose debug messages in the kernel driver and recompiled a Samsung S3 kernel image for the purpose of this analysis. Please note that you need to download the relevant kernel source tree and stock ROM for your S3 phone kernel build number which can be found in "Settings->About device". After compiling the new zImage file, you would need to insert it into a custom ROM and flash your phone. To build the custom ROM I used "Android ROM Kitchen 0.217" which has the option to unpack zImage from the stock ROM, replace it with the newly compiled zImage and pack it again.

By studying the source code of the user API library and observing debug messages from the kernel driver, I figured out the following data flow between the android OS and Mobicore to establish a session and communicate with a trustlet:

1) Android application calls mcOpenDevice() API which cause the Mobicore Daemon (/system/bin/mcDriverDaemon) to open a handle to /dev/mobicore misc device.

2) It then allocates a "Worlds share memory" (WSM) buffer by calling mcMallocWsm() that cause the Mobicore kernel driver to allocate wsm buffer with the requested size and map it to the user space application process. This shared memory buffer would later be used by the android application and trustlet to exchange commands and responses.

3) The mcOpenSession() is called with the UUID of the target trustlet (10 bytes value, for instance : ffffffff000000000003 for PlayReady DRM truslet) and allocate wsm address to establish a session with the target trustlet through the allocated shared memory.

4) Android applications have the option to attach additional memory buffers (up to 6 with maximum size of 1MB each) to the established session by calling mcMap() API. In case of PlayReady DRM trustlet which is used by the Samsung VideoHub application, two additional buffers are attached: one for sending and receiving the parameters and the other for receiving trustlet's text output.

5) The application copies the command and parameter types to the WSM along with the parameter values in second allocated buffer and then calls mcNotify() API to notify the Mobicore that a pending command is waiting in the WSM to be dispatched to the target trustlet.

6) The mcWaitNotification() API is called with the timeout value which blocks until a response received from the trustlet. If the response was not an error, the application can read trustlets' returned data, output text and parameter values from WSM and the two additional mapped buffers.

7) At the end of the session the application calls mcUnMap, mcFreeWsm and mcCloseSession .

The Mobicore kernel driver is the only component in the android operating system that interacts directly with Mobicore OS by use of ARM CPU's SMC instruction and Secure Interrupts . The interrupt number registered by Mobicore kernel driver in Samsung S3 phone is 47 that could be different for other phone or tablet boards. The Mobicore OS uses the same interrupt to notify the kernel driver in android OS when it writes back data.

Analysis of a Mobicore session:

There are currently 5 trustlets pre-loaded on the European S3 phones as listed below:

shell@android:/ # ls /data/app/mcRegistry


The 07010000000000000000000000000000.tlbin is the "Content Management" trustlet which is used by G&D to install/update other trustlets on the target phones. The 00060308060501020000000000000000.tlbin and ffffffff000000000000000000000003.tlbin are DRM related truslets developed by Discretix. I chose to analyze PlayReady DRM trustlet (ffffffff000000000000000000000003.tlbin), as it was used by the Samsung videohub application which is pre-loaded on the European S3 phones.

The videohub application dose not directly communicate with PlayReady trustlet. Instead, the Android DRM manager loads several DRM plugins including which is dependent on library that makes Mobicore API calls. Both of these libraries are closed source and I had to perform dynamic analysis to monitor communication between and PlayReady trustlet. For this purpose, I could install API hooks in android DRM manager process (drmserver) and record the parameter values passed to Mobicore user library (/system/lib/ by setting LD_PRELOAD environment variable in the init.rc script and flash my phone with the new ROM. I found this approach unnecessary, as the source code for Mobicore user library was available and I could add simple instrumentation code to it which saves API calls and related world shared memory buffers to a log file. In order to compile such modified Mobicore library, you would need to the place it under the Android source code tree on a 64 bit machine (Android 4.1.1 requires 64 bit machine to compile) with 30 GB disk space. To save you from this trouble, you can download a copy of my Mobicore user library from here. You need to create the empty log file at /data/local/tmp/log and replace this instrumented library with the original file (DO NOT FORGET TO BACKUP THE ORIGINAL FILE). If you reboot the phone, the Mobicore session between Android's DRM server and PlayReady trustlet will be logged into /data/local/tmp/log. A sample of such session log is shown below:

The content and address of the shared world memory and two additional mapped buffers are recorded in the above file. The command/response format in wsm buffer is very similar to APDU communication in smart card applications and this is not a surprise, as G&D has a long history in smart card technology. The next step is to interpret the command/response data, so that we can manipulate them later and observe the trustlet behavior. The trustlet's output in text format together with inspecting the assembly code of helped me to figure out the PlayReady trustlet command and response format as follows:

client command (wsm) : 08022000b420030000000001000000002500000028023000300000000500000000000000000000000000b0720000000000000000

client parameters (mapped buffer 1): 8f248d7e3f97ee551b9d3b0504ae535e45e99593efecd6175e15f7bdfd3f5012e603d6459066cc5c602cf3c9bf0f705b

trustlet response (wsm):08022000b420030000000081000000002500000028023000300000000500000000000000000000000000b0720000000000000000

trustltlet text output (mapped buffer 2):


SRVXInvokeCommand command 1000000 hSession=320b4

SRVXInvokeCommand. command = 0x1000000 nParamTypes=0x25

SERVICE_DRM_BBX_SetKeyToOemContext - pPrdyServiceGlobalContext is 32074

SERVICE_DRM_BBX_SetKeyToOemContext cbKey=48

SERVICE_DRM_BBX_SetKeyToOemContext type=5

SERVICE_DRM_BBX_SetKeyToOemContext iExpectedSize match real size=48

SERVICE_DRM_BBX_SetKeyToOemContext preparing local buffer DxDecryptAsset start - iDatatLen=32, pszInData=0x4ddf4 pszIntegrity=0x4dde4

DxDecryptAsset calling Oem_Aes_SetKey DxDecryptAsset

calling DRM_Aes_CtrProcessData DxDecryptAsset

calling DRM_HMAC_CreateMAC iDatatLen=32 DxDecryptAsset

after calling DRM_HMAC_CreateMAC DxDecryptAsset


calling DRM_BBX_SetKeyToOemContext res=0x0


By mapping the information disclosed in the trustlet text output to the client command the following format was derived:

08022000 : virtual memory address of the text output buffer in the secure world (little endian format of 0x200208)

b4200300 : PlayReady session ID

00000001: Command ID (0x1000000)

00000000: Error code (0x0 = no error, is set by truslet after mcWaitNotification)

25000000: Parameter type (0x25)

28023000: virtual memory address of the parameters buffer in the secure world (little endian format of 0x300228)

30000000: Parameters length in bytes (0x30, encrypted key length)

05000000: encryption key type (0x5)

The trustlet receives client supplied memory addresses as input data which could be manipulated by an attacker. We'll test this attack later. The captured PlayReady session involved 18 command/response pairs that correspond to the following high level diagram of PlayReady DRM algorithm published by G&D. I couldn't find more detailed specification of the PlayReady DRM on the MSDN or other web sites. But at this stage, I was not interested in the implementation details of the PlayReady schema, as I didn't want to attack the DRM itself, but wanted to find any exploitable issue such as a buffer overflow or memory disclosure in the trustlet.

DRM Trustlet diagram (courtesy of G&D)

Security Tests:

I started by auditing the Mobicore daemon and kernel driver source code in order to find issues that can be exploited by an android application to attack other applications or result in code execution in the Android kernel space. I find one issue in the Mobicore kernel API which is designed to provide Mobicore services to other Android kernel components such as an IPSEC driver. The Mobicore driver registers Linux netLink server with id=17 which was intended to be called from the kernel space, however a Linux user space process can create a spoofed message using NETLINK sockets and send it to the Mobicore kernel driver netlink listener which as shown in the following figure did not check the PID of the calling process and as a result, any Android app could call Mobicore APIs with spoofed session IDs. The vulnerable code snippet from MobiCoreKernelApi/main.c is included below.

An attacker would need to know the "sequence number" of an already established netlink connection between a kernel component such as IPSEC and Mobicore driver in order to exploit this vulnerability. This sequence numbers were incremental starting from zero but currently there is no kernel component on the Samsung phone that uses the Mobicore API, thus this issue was not a high risk. We notified the vendor about this issue 6 months ago but haven't received any response regarding the planned fix. The following figures demonstrate exploitation of this issue from an Android unprivileged process :

Netlink message (seq=1) sent to Mobicore kernel driver from a low privileged process

Unauthorised netlink message being processed by the Mobicore kernel driver

In the next phase of my tests, I focused on fuzzing the PlayReady DRM trustlet that mentioned in the previous section by writing simple C programs which were linked with and manipulating the DWORD values such as shared buffer virtual address. The following table summarises the results:
wsm offsetDescriptionResults
0Memory address of the mapped output buffer in trustlet process (original value=0x08022000)for values<0x8022000 the fuzzer crashed

values >0x8022000 no errors

41memory address of the parameter mapped buffer in trusltet process (original value=0x28023000)0x00001000<value<0x28023000 the fuzzer crashed

value>=00001000 trustlet exits with "parameter refers to secure memory area"

value>0x28023000 no errors

49Parameter length (encryption key or certificate file length)For large numbers the trustlet exits with "malloc() failed" message

The fuzzer crash indicated that Mobicore micro-kernel writes memory addresses in the normal world beyond the shared memory buffer which was not a critical security issue, because it means that fuzzer can only attack itself and not other processes. The "parameter refers to secure memory area" message suggests that there is some sort of input validation implemented in the Mobicore OS or DRM trustlet that prevents normal world's access to mapped addresses other than shared buffers. I haven't yet run fuzzing on the parameter values itself such as manipulating PlayReady XML data elements sent from the client to the trustlet. However, there might be vulnerabilities in the PlayReady implementation that can be picked up by smarter fuzzing.


We demonstrated that intercepting and manipulating the worlds share memory (WSM) data can be used to gain better knowledge about the internal workings of Mobicore trustlets. We believe that this method can be combined with the side channel measurements to perform blackbox security assessment of the mobile TEE applications. The context switching and memory sharing between normal and secure world could be subjected to side channel attacks in specific cases and we are focusing our future research on this area.

Mon, 22 Apr 2013

Windows Domain Privilege Escalation : Implementing PSLoggedOn in Metasploit (+ a bonus history module)

There are multiple paths one could take to getting Domain Admin on a Microsoft Windows Active Directory Domain. One common method for achieving this is to start by finding a system where a privileged domain account, such as a domain admin, is logged into or has recently been logged into. Once access to this system has been gained, either stealing their security tokens (ala Incognito or pass-the-hash attacks) or querying Digest Authentication (with Mimikatz/WCE) to get their clear-text password. The problem is finding out where these user's are logged in.

I've often seen nmap and the smb-enum-sessions script ( used to retrieve all the user sessions on the network. This (not so grep'pable) output is then grep'ed to find the hosts where our target user is logged in. The process of smb-enum-sessions and subsequent analysis can be quite time consuming and clumsy. On a recent assessment, multiple tunnels in, where uploading nmap wasn't a great idea, we realised that there has to be a better way of doing this. While searching for an alternative solution we came across PsLoggedOn (SysInternals Suite) which, with a single binary, allows you search the network for locations where a user is logged in. The downside with this is that it doesn't cleanly run via psexec or other remote shells and you need graphical logon to a system on the domain, and you need to upload another binary (the PsLoggedOn executable) to the target system. Examining how PsLoggedOn worked we figured out that it was simply using the Windows NetSessionEnum API. Having a look at the API I figured that it should be possible to write a simple post exploit module for Metasploit using the railgun.

After some trial and error, we now present enum_domain_user.rb a simple Metasploit post exploit module capable of finding network sessions for a specific user. Below is a screenshot of the module in action.

To use the module,

1.) Download and copy it to:
(we'll send a pull request to metasploit-framework's github shortly).

2.) In MSF:
use post/windows/gather/enum_domain_user

3.) Set the USER and SESSION variables.

4.) Then simply run it with "exploit".

The module can also be used directly from meterpreter with:
run post/windows/gather/enum_domain_user USER=username

Warning, this doesn't seem to work with x64 meterpreter yet mostly likely due to some memory pointer stuff I haven't worked out. Hopefully this will get updated shortly, or even better, one of you smart people out there can fix my horrible Ruby.


As an added extra I've included a Metapsloit history plugin. This plugin will simply allow you to view all the commands executed since the module was loaded and then execute them "bash style".

Typing "history" will give display the last 10 commands executed. If you wish to see more commands, type history <numberof entries>

To run a command from the history list type:
history !<command number>

Below is an action shot of the history module.

To install:

1.) Download and Copy history.rb to the plugins folder: <msf install>/plugins/
2.) In msfconsole type: load history
3.) For usage info type: help history

Both modules are available for download on Github, and I'll submit a pull request to metasploit-framework shortly. Please feel free to fork and be merry. Any updates/fixes/comments are welcome.