Converting a memory image from raw to padded

Convert a Linux memory image from a raw (where the System RAM ranges have been concatenated together) to a padded image, provided the early boot messages were present in the kernel ring buffer at the time of imaging. Includes Python code to convert an image automatically.

Update 2016-06-29: The code on Github has been updated to include functionailty to scan through the memory image searching the BIOS-e820 messages in the Kernel ring buffer (basically a regular expression or two) in order to convert the image completely automatically.

There are several methods of acquiring a memory image from a Linux system – one of the most traditional being to image the current physical memory into a single file – In this case any non-system areas would need to be padded with zeros in order to maintain the representation of physical memory. Another method involves examining the /proc/iomem file (Linux will print the current map of the systems memory in this file) to identify which memory ranges are marked as System RAM, and copying / concatenating those ranges into one file. This results in a smaller file, but lacks the representation of physical memory.

The problem we have and the reason this article and Python code has come to be is because I have a memory image (for a challenge, actually – more on that in a later article, perhaps) which has been obtained using LiME, but with LiME set to output in a raw format which simply concatenates the System RAM ranges together. Many memory forensics tools and frameworks, such as Volatility, or crash with the volatile patch cannot work with this kind of raw memory image . The tools have no way of knowing what goes where.

Continue reading

Tagged , , ,

Recovering BitLocker Keys on Windows 8.1 and 10

A brief touch on how the changes to BitLocker after Windows 7 affect master key recovery and where to look when recovering keys.

This article is not intended to be an in-depth look at the inner workings of BitLocker, but is instead focussed on retrieval of the Full Volume Encryption Key (FVEK) from memory.

Key recovery on Windows 7 is a fairly simple exercise (see references at the end of this article for further reading). When dealing with a Windows 7 memory image we can simply search for the FVEc pool tag as an indicator of exactly where the FVEK lies in memory. From there, we can proceed to extract the key.

Starting with Windows 8, however, it seems that the cryptographic operations for BitLocker have been outsourced to Microsoft’s CNG (Cryptography Next Generation) Module, which is the long-term replacement for CryptoAPI, rather than being performed internally within the fvevol driver.

What this means for us is that searching for the FVEc pool tag on Windows 8 and above will no longer yield anything useful.

AESKeyFind still works, of course, though depending on your memory image you may need to tweak your threshold settings.

Continue reading

Tagged , , ,

Extracting FileVault 2 Keys with Volatility

SUMMARY: This is a volatility plugin which can recover FileVault 2 Volume Master Keys from memory, based on a certain pattern. It has been briefly tested on OS X 10.9 – 10.11. Plugin on GitHub here.

This is a Volatility Framework plugin which is capable of recovering the Volume Master Keys for volumes protected with Apple’s FileVault 2 Full Volume Encryption (FVE) solution.

Update 2016-02-15: Just to confirm, this is not some scary vulnerability nor is it anything new – It is simply the way any Full Volume Encryption system works and most (E.G. Microsoft’s BitLocker, or the now-defunct Truecrypt and its forks) can have the same issue. For performance reasons it is generally necessary to keep the keys in memory, otherwise you end up with the additional overhead of having to constantly retrieve the key. This plugin simply makes it easier and adds that functionality to Volatility.

FileVault 2 has been included with OS X since version 10.6 and uses 128-bit XTS-AES Encryption to encrypt the entire volume (As opposed to the first version of FileVault which only encrypted a users home directory). As with any current FVE solution, FileVault 2 keeps the encryption keys in memory whilst operating.

The traditional method of locating encryption keys (for us mere mortals anyway) is to run aeskeyfind to attempt to locate the AES Key Schedules, which then may be used to unlock the drive. Finding the key this way provides a starting point for developing a Volatility plugin by providing a working key which may be used to hunt down the key in the memory image.


aeskeyfind in action.

In this screenshot aeskeyfind has found the VMK (Note that it finds other potential AES keys as well, but I’ve omitted them for brevity). In our case here the VMK is 4d8266b26268909ca823581557b8bdb5

Running a yarascan for the key shows  that the key is available at three different locations of kernel memory, and one of those locations contains the entire scheduled key.

Results of a yarascan for the AES key.

Results of a yarascan for the AES key (Click for bigger).

With this information I started looking for a reliable method to locate the keys (perhaps searching for a particular symbol, or some kind of reference) but didn’t really have much luck. So, instead, I started looking for a pattern in memory locations or patterns in the data surrounding the keys that could be used to locate the keys in other memory images.

Comparing the memory of two separate OS X 10.11 VM’s shows some similarities in the memory images which may give us something to work with. The most apparent similarity is the repetition of the VMK at offset +0x430 from the initial key schedule location. This turns out to be useful knowledge when searching for the keys.

So what we know so far is:

  • The VMK exists at 3 locations in kernel memory.
  • The second location appears to be the key schedule, including the key at the start of the schedule.
  • One of the locations is always located at the schedule location +0x430
  • The keys are located at a different offset after each boot (Which appears unrelated to ASLR – This is important, since if it was related we could find the ASLR shift value).
  • The second + third locations are located in the same process memory submap, which is marked read-only.
  • The second location (The location with the key schedule) is aligned with the start of a particular page.

Therefore, if we assume that:

  • The key is located within the process memory of kernel_task.
  • The key schedule is always aligned with the start of its page.
  • The memory submap has read-only permissions (“r–“).
  • Another copy of the key may be found at key +0x430

Then we can apply this general logic to find the key on any memory image:

  1. Get process maps of kernel_task
  2. Iterate through each start_address
  3. Compare value of start_address with (start_address + 0x430)
  4. If the value matches; then we have a key.

And that’s all there is to this plugin! It simply outputs the VMK and the address at which it was found. In the case of the below screenshot, the memory image is from a VM which has its system volume encrypted, as well as a small 1GB encrypted volume for testing, so both VMK’s are recovered (Though identifying which key matches which volume is left up to you):


We can verify that the VMK is correctly extracted by attaching the disk to a Linux VM and using libfvde – an open-source implementation of FileVault 2 – to unlock the volume using the key:

VM with FileVault enabled, plus a test folder to ensure we are successful.

VM with FileVault enabled, plus a test folder to ensure we are successful.


The volume unlocked using libfvde and the VMK!

The volume unlocked using libfvde and the VMK, with the test folder for confirmation.

(Note that there is some pre-work required to obtain the EncryptedRoot.plist.wipekey, but this is fully documented in the libfvde documentation).

As with everything though there are, of course, pros and cons – For example, the pros are that it’s simple, fast and (from my testing) somewhat reliable – But the downside is that really it’s not a very sexy method of finding the VMK.

I have tested this using OS X 10.8, 10.9 and 10.11 Virtual Machines encrypted with FileVault 2, and the code is available at this GitHub repository:

As usual, any feedback is much appreciated (Especially if you have a better method of locating the VMK). Feel free to contact me with feedback.

Note: I have not yet tested this on 32-bit OS X, but aim to do that in the next few days. Update: It would seem I need to eat my own words as newer versions of OS X are 64-bit only.

Tagged , , , , ,

Glitch in the matrix…

I have heard via email that some content has been missing / some links broken.

This should all be fixed now, but let me know if you still find broken links.

Extracting BitLocker keys with Volatility (PoC)

Update 2016-03-13: There is more detail, including a link to a plugin for Volatility in the more recent article Recovering BitLocker Keys on Windows 8.1 and 10 .

This article is mainly to document a proof-of-concept Volatility plugin to extract the Full Volume Encryption Key (FVEK) from a memory dump of a Bitlocker-enabled Windows machine. The tools already exist to do this and potentially assist in gaining access to an encrypted machine, provided you have Windows running (Example scenario may be an encrypted laptop with TPM-only Bitlocker protection for which you do not have credentials).

But firstly, a few notes…

Continue reading

Automated Malware Analysis: mail server -> Cuckoo, V2.0

Quite some time ago I slapped together a couple of scripts to submit quarantined attachments from my mail server to Cuckoo (Article here).

I have finally found time to re-write this to use a Postfix content filter: extracting any attachments from an email processed by Postfix, then submitting to Cuckoo (on a different box) via Cuckoo’s REST API.

A couple of methods for achieving the same goal come to mind:

  1. Run as a Postfix after-queue filter: processing mail, submitting to Cuckoo then returning to the queue (Or forwarding to something else, such as Amavis). I initially started out with this in mind and wrote something which almost works as a simple content filter, though at the moment it doesn’t play nicely with virtual aliases.
  2. Copy all incoming mail to another mailbox and process from there. You could either poll the mailbox via IMAP and process mail (Which could be done locally on the Cuckoo box), or have Postfix pipe it through a script, thus never actually delivering the mail to a mailbox. I chose the latter option.

For now, since it is more or less a blind submission to Cuckoo without expecting any feedback, the BCC -> Pipe method makes much more sense as we don’t mess with the flow of mail (less to go wrong) and the implementation is more efficient.

However, the benefit of a content-filter design would become apparent if you want the system to make automated mail delivery decisions based on intelligence received from Cuckoo. This would be interesting to persue, but you would first need to determine how to quantify a Cuckoo report into actionable data… Of course, the delivery delay introduced may be another challenge (Though I would say no more of a delay than servers who implement Greylisting). Perhaps you could compromise and:

  • Strip the attachment and deliver the mail, then provide a link or additional email once processing is complete (Not a very elegant solution).
  • Tag each email processed by Cuckoo, then index the tag for retroactive removal from mailboxes after processing has completed and a threat detected.
  • You should probably not be delivering dangerous attachments anyway..

Note: There are a few issues you would need to consider before implementing something like this on anything other than your personal mail server (as I have done here) – If there is any expectation of privacy for your users then that will need to be addressed (Though I would consider this less invasive then most anti-spam scanners). In addition, consider any data security implications of having certain attachment types transferred to and stored on your Cuckoo machine.

Anyway, I digress. What I have now is a system which pipes a copy of incoming mail through a Python script which decodes applicable attachments and submits them to Cuckoo for analysis via the REST API.



The Python script itself is, in typical Python fashion, astonishingly simple. It takes a complete email message from STDIN and first checks if it is a multipart message (Ignoring if it is not):

if not msg.is_multipart():
 #Not multipart? Then we don't care, pass it back
 logging.debug("Ignoring non-multipart message from %s." % (msg['from']))
 return True

If the email is a multipart message, then we iterate over all the parts of the message and infer the content type from the headers. The content-type is then checked against a predefined list (MIME types such as octet-stream, msword, zip, etc). I’ve also included a secondary magic number check after the attachment is decoded as in testing it was found that you can end up submitting a bunch of stuff defined as an octet-stream which you don’t really want to submit (PGP Keys, for example).

for part in msg.walk():
 # TODO: Other mime types? pdf? doc?
 logging.debug("Processing mail part of type %s" % (part.get_content_type()))
 if part.get_content_type().strip() in mtypes:
   attachment = part.get_payload(decode=True)
   mtype = magic.from_buffer(attachment, mime=True)
   # Secondary check using magic
   # Sometimes we get octet-streams which we do not want to analyse
   if mtype not in mtypes:

Once a relevant attachment is identified the attachment is decoded into a temporary file object and included in a POST request to the REST interface running on the Cuckoo box. After submission is complete the copy of the mail is simply discarded, as delivery to the original mailbox continues in parallel and the original mail flow is left undisturbed.



In order to actually get a copy of the mail to our script we make use of Postfix’s recipient BCC maps and per-user transport tables. I’m running iRedMail, which makes things somewhat specific to an LDAP-based iRedMail setup, but the concept remains the same.

We configure Postfix with a recipient_bcc_map to BCC all incoming mail with a recipient domain to the user The email isn’t actually delivered and stored in the mailbox but the user must exist, otherwise Postfix will bounce the mail.

Before the transport tables can be configured a new pipe transport needs to be defined in Postfix’s

cuckoolyse        unix  -       n       n       -       -       pipe
  flags= user=cuckoolyse argv=/home/cuckoolyse/

It is then possible to use the now-defined transport cuckoolyse for a certain user which can be done using Postfix’s transport_maps option (As I mentioned I am using iRedMail so my BCC mapping and transport tables are contained in LDAP). Once configured correctly mail will be BCC’d to the cuckoolyse address, but mail destined for that address will be delivered via the cuckoolyse service.


Of course, the Cuckoo API server needs to be running on the Cuckoo box. It’s simple to get running, so have a look at the Cuckoo documentation for more information. Keep in mind you may wish to consider encrypting the transport of submissions.

I’ve added the code for both the version I am using here as well as the original “simple content filter” to Github here:

Feel free to use and modify as you see fit, but if you find this helpful shoot me an email as I would be very interested to hear about other implementations. Also, if you would like more information about the Postfix side of things please get in touch and I will be more than happy to explain further.

Update: I added a check to determine if the sample had already been analysed by Cuckoo. Otherwise, I end up with this…


Feedback is welcome. Contact me here.

Tagged , , , ,

Maybe I should stick to software…

A story about bricking some hardware, then encasing said brick in a large concrete slab.

People generally only publish their successes and with fairly good reason –  For the publicity, reputation and possibly to impress prospective employers. Conversely, for the opposite reasons no-one wants to broadcast to the world “Actually… I failed miserably at something.”

I believe it’s good to talk about our failures as well as our successes, if for nothing else but reflecting on what went wrong in order to learn from it (Or in this case… Hopefully have someone point out what I did wrong). So, when I completely bricked my brand new IP Camera I thought about quietly sweeping it under the rug and pretending it never existed, but instead decided that perhaps I could turn it into a somewhat light-hearted story.

Our story begins with the purchase of an IP Camera. The area we live in seems to be experiencing an increase in general ‘sketchiness’ (The electronic sign claiming that police are targeting this area due to an increase in crime doesn’t help…), so a camera at the side entrance to the house might be useful as well as potentially being fun to play with.

Lets call this a "Generic IP Camera"

Lets call this a “Generic IP Camera”

Whilst poking and prodding the camera before setting it up, it became apparent that the internal software contains a very, very simple vulnerability which allows the extraction of arbitrary files from the underlying Linux system – Including the application configuration file which stores, in plaintext:

  • The username and password to the camera’s web interface.
  • Username and password of email accounts configured for alerting.
  • Access which allows me to recover the root password of the camera and gain access via telnet.


Note: I have reported the above vulnerability to the vendor and will not be exposing any technical or identifying details until I am satisfied that either it has been fixed, or the vendor has no intention of fixing it. The rest of the article may not be considered to apply to this camera in particular.

After a lot of thinking, I started investigating methods of compromising an IP camera in order to circumvent any firewalls and gain access to the local network behind it. After obtaining the root password to the telnet interface getting shell access, I had poked around enough for my satisfaction and had a thought: What if I could push my own evil firmware to it?

Continue reading

Tagged , , , ,

CryptoWall spreading via HT Flash 0-day

Well that didn’t take long.

UPDATE 1: Chromes Sandboxing may be a useful defence.

UPDATE 2: Adobe have released a patch:

ACTION REQUIRED: Update your Flash player now! Disable Flash unless required, uninstall Flash completely or set Flash as click-to-play in all browsers. A decent guide for click-to-play can be found here: How to Enable Click-to-Play Plugins in Every Web Browser

The Flash zero-day exploit found in the Hacking Team leak has been weaponised and included in the Angler, Nuclear and Neutrino Exploit Kits, according to various reports.

Feedback from the Trend Micro™ Smart Protection Network™ has allowed us to learn that the Angler Exploit Kit and Nuclear Exploit Pack have been updated to include the recent Hacking Team Flash zero-day. In addition, Kafeine said, Neutrino Exploit Kit also has included this zero-day.

Source: Hacking Team Flash Zero-Day Integrated Into Exploit Kits

CryptoWall 3.0 has been identified as one of the payloads being distributed using the Zero-day.

This means you can be infected simply by browsing to a malicious or compromised website.

MalwareBytes have a report: PSA: Flash Zero-Day Now Active in The Wild

Kafeine’s post is here:  CVE-2015-5119 (HackingTeam 0d – Flash up to and Exploit Kits

Personally, I think you should uninstall Flash and never look back.

I will update once Adobe release a patch or more information is at hand.


CryptoWall 3.0 + Fareit / Pony Combo

In this article I’m taking a look at the recent malware double-whammy of CryptoWall 3.0 and Fareit (or Pony, depending on classification). This is a rather potent combination which will encrypt all your data on your PC, as well as steal information such as passwords and BitCoin wallets.

Note: At this point I am unaware of any way to decrypt files which have been encrypted. Given the use of a public/private keypair, I find it unlikely that there will be a way to decrypt your data (unless the C2 infrastructure can be seized). If you have been infected, it would be a good time to test your offline backup strategy.

I’ve split the article into three parts (Click the link to jump to each one):

Continue reading

Tagged , , , ,

New Look

I’ve changed the theme on the site, I feel this one is clearer and easier to read.

Feedback is appreciated, of course.