Sysinternals Autoruns - offline analysis

This post discusses how to use Sysinternals Autoruns in the offline mode if all you have are registry hives.

1.      Create the following files structure for the system registry hives to fool Autoruns to thinking you’re giving it the Windows folder.

a.      <FOLDER>\System32\ntdll.dll [can be an empty file]

b.      <FOLDER>\System32\Config\SAM

c.      <FOLDER>\System32\Config\SYSTEM

d.      <FOLDER>\System32\Config\SOFTWARE

e.      <FOLDER>\System32\Config\SECURITY

2.      Recreate the user’s hives

a.      <FOLDER>\NTUSER.DAT

b.      [on Vista+]
<FOLDER>\AppData\Local\Microsoft\Windows\UsrClass.dat

         [pre-Vista]
<FOLDER>\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat

Now just point your Autoruns at these two folders and you’re ready to go!

It’s worth noting that while the latest version of Autoruns doesn’t seem to try to perform any tests on the files from extracted entries if it’s in the Offline mode (e.g. to tell you if the file exists), if your version does then you could use it to your advantage by running Autoruns on a fresh copy of the same operating system as the one the hives come from and turn on the option “Hide Windows Entries” and “Hide Microsoft Entries”. Naturally, doing so should reduce the amount of entries that you need to look at by ignoring the files that would occur on a legitimate system. Of course it discounts the fact that the system the hives come from might have had some of its system files replaced, which while quite unlikely to happen is perfectly plausible.

Troubleshooting: If you managed to load the hives in Autoruns the first time you tried but it complains when you try again, that’s most likely because the hives remain loaded by the system. To fix that open up the Command Prompt as administrator and type the following commands:

• reg unload HKLM\autoruns.software
• reg unload HKLM\autoruns.system
• reg unload HKLM\autoruns.user

SSH Fingerprint from a PCAP

This post will cover how to generate a SSH public key fingerprint from captured network traffic. There’s also a Python script that you can download (ssh_fingerprint_extractor.py) that will go over a binary file searching for the public key that a typical SSH server presents and generate the fingerprint of it.

What is a SSH Fingerprint?

You know when you try to connect for the first time to a SSH server with a client like Putty, it will present to you a fingerprint that looks something like this “43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8” and then it’ll ask if you’d like to accept it. Most people instruct their SSH client to remember the key, so that they’re not warned the next time they try to connect to the server. The idea is to prevent a Man-in-the-Middle (MITM) attack by verifying that the server’s public key is what we expect to get.

The Scenario

I’ve recently worked on an incident response (IR) case where the attacker was tunnelling their connections using the malware they implanted on some of the end nodes. When investigating a PCAP with tunnelled connections, I came across a SSH session. The natural thing would be to determine what host the attackers were accessing. However, based on the PCAP we couldn’t tell what the end-point system was.

Wireshark verified my suspicions that the SSH server needs to send its public key to the client before the encrypted communication can start. If we could produce the SSH fingerprint from the captured data then we can compare it to the once presented by the servers on the network and therefore pin point what systems the attackers were accessing.

The Solution

Googling to see if someone has had a similar problem yielded Didier Steven’s blog post about calculating a SSH fingerprint from a (Cisco) public key. Studying his code quickly revealed that the “mysterious” fingerprint is nothing else but MD5 of the public key, presented in a rather peculiar form, perhaps the byte separation was meant to help folks swiftly perform a visual inspection if it matches what they should expect to see.

Looking at the PCAP in Wireshark I quickly realised that the public key has a recognisable keyword “ssh-rsa”, which is preceded by a byte sequence “\x00\x00\x00\x07” and the key size before that. So all the code needs to do is look for the keyword, read the size, grab the data and calculate MD5 of it.

While testing the tool, I was surprised to learn that in fact there were two SSH public keys, referred to by Wireshark as KEX DH host key and KEX DH H signature; you’re only interested in the host key as this is what the SSH client will take as the fingerprint.

SSH Servers Scanning

Say you extracted the SSH fingerprint from the PCAP and you need to find the server it belongs to – nothing easier! As it turns out, nmap has a NSE script called ssh-hostkey that will do that for you. Example usage:

nmap [IP_range] --script ssh-hostkey --script-args ssh_hostkey=full -oX output.xml

All that's left now is to grep the XML file or write a parser. Have fun!

Chip's Backdoor and Chinese: Fake Accusation

There's been a lot of hype recently about a backdoor in a "military grade" chip, which allegedly has been planted by Chinese. There is a great article by Robert Graham, which explains (almost) exactly what mistakes have made by the paper's authors, which led them to thinking that a debugging functionality is a backdoor. I do recommend reading it just for the sake of familiarising yourself with the hardware side of information security.

Final Year and Links

I know it has been ages since I wrote the last time but finishing university kept me extremely busy. Speaking of which, I should soon publish my dissertation and then I will post a link to it.

While still on the topic of university, I have published some of the essays/reports that I wrote while studying at University of Derby. One can probably notice that with time they started improving therefore if you are going to read anything, I highly recommend you start from the latest ones. The details of each of them are available on my LinkedIn profile.

This is a list of them:

• Evading Intrusion Detection Systems (IDS) (May 2012)
• Issues of Forensic Investigations in Cloud Computing (May 2012)
• Autonomous Network Management (Dec. 2011)
• The Use of Insects at the Crime Scene (Oct. 2010)
• Computer Crime and Computer Misuse (Mar. 2010)
• Database Design, Implementation & Testing (a project, Dec. 2009)
• Forensic Science - Case Study (Dec. 2009)
• Evidence Collection at the Crime Scene (Dec. 2009)
• The Greg Schardt case - Forensic Investigation (Apr. 2009)

Cryptoscan: Fixed Windows Vista+ support

There’s been a minor update to the batch script that I’ve provided with Cryptoscan as previous version was limited to only work with versions of Windows supported by Volatility 1.3 beta. I know that to truly solve the problem I should have ported the module to Volatility 2.0 but I already tried it and I miserably failed. Anyone wants to help? ;>

The new batch script runs Cryptoscan using version 1.3 and then the other two modules (i.e. Strings and Modules) using version 2.0.

To get it working here are 3 simple steps:

1.       Extract 'Volatility-1.3_beta'.

2.       Extract 'Volatility-2.0.standalone' to the same folder as before.

3.       Extract 'Cryptoscan' to the same folder too (overwrite if asked).

You can run ‘Cryptoscan.cmd’ now and enjoy! ;)

If you have some problems getting it working then check my previous post or leave a comment.

PS. There's been a small change to the provided binaries. Instead of using GnuWin32, the batch script uses UnxUtils since they do exactly the same job and are smaller in size.

Compressed (and Encrypted) Alternate Data Streams

The technique of hiding data within NTFS Alternate Data Streams (aka ADS) has been widely documented and it isn’t something that could take a forensic investigator by surprise. Then about a month ago I came across an article with an extra-ordinary name – Stealth Alternate Data Streams and Other ADS Weirdness, which hinders certain tools from finding the ‘hidden’ streams. You can probably see where I’m going with this… today I read an article titled Detecting and Manipulating Compressed Alternate Data Streams in a Forensics Investigation, unfortunately there's no freely available copy of it, which describes another technique of hiding data.

The article explains that by compressing a file using WinRAR with an option for preserving NTFS streams turned on (Figure 1), which according to this post is the only archiver that supports this technique at the moment, we can evade some of the anti-virus scanners. I also tested it on 7-Zip and WinZip 16.0 but neither of them can handle file streams.

Figure 1. Preserving ADS.

The article, not surprisingly, uses VirusTotal to compare results of scanning the archive by different anti-virus engines. In October 2007, when the research was carried out, only four out of all the supported scanners detected the embedded malicious software. Bearing in mind that it was a few years ago, I couldn’t resist trying it out myself. I firstly created a text file with some random text and then appended a file with an EICAR-TEST file to it. Then I archived the file making sure it includes file streams, and scanned it with an anti-virus which was on my machine but it didn’t detect anything (I used F‑Secure Internet Security 2011 with today’s virus definitions).

Figure 2. The result of scanning a RAR archive with an EICAR-TEST file hidden in a file stream.

I was also curious about how would other anti-virus scanners cope so I uploaded the file to VirusTotal and the detection rate was only 37.2% (Figure 2). But it gets even better… you see, the other WinRAR’s NTFS option reads ‘save file security’. The article doesn’t cover this feature, but I decided to give it a go: I encrypted the file (with a stream) using the NTFS Encryption (aka EFS) feature and then archived it making sure that both of the WinRAR's NTFS options were selected. Guess what, the detection rate was 0% (Figure 3).

I opened the archive with WinRAR on different machine (VM with Windows XP SP3) and the file was in green indicating that it is compressed but when I unpacked it, because the user didn’t have the right encryption key, WinRAR skipped the streams. What was even more surprising, the file extracted without showing any errors what‑so‑ever. Just to clarify, the archive successfully extracts files with streams when opened by the user who created it. It indicates to me that for some weird reason WinRAR has different implementation of compressing encrypted files and their streams: it decrypts files and keeps them in "plain-text" unlike file streams which are stored encrypted.

Figure 3. The result of scanning a RAR archive with an encrypted file stream.

Let’s consider the implications of it. If a suspect had used a RAR archive to hide NTFS Encrypted files then unless the investigator tried to open the archive under the suspect’s account (e.g. using LiveView), or imported the suspect's encryption key on his investigation workstation (I’m not quite sure how and if it’s doable), then he’d have missed the streams. On the other hand, if the archive is suspiciously large compared to its content, it may be a clue to an investigator.




Update (21 Dec 2011): I decided to write a tool that would scan a hard drive for any RAR files to see if they contain any NTFS streams. Before I did it though, I tried again the above-mentioned  method with encrypted NTFS streams. As it turned out, I must have made a mistake when firstly testing this method because WinRAR has a bug which makes it skip NTFS streams of encrypted files. Thus, the 0% detection rate from VirusTotal (because the file wasn't included!).

Update (31 Jan 2012): I've contacted the team behind WinRAR about the issue and this is their response: "Sorry, WinRAR does not support encrypted streams now. It would require another approach like using ReadEncryptedFileRaw instead of BackupRead for encrypted files and it is not implemented. Maybe we'll do it in the future." So as one can infer, it is a known issue and may, or may not, be solved in the future.

File System Tunnelling

While reading through Harlan Carvey’s slides from PFIC 2011 about Introduction to Windows Forensics, I came across a term File System Tunnelling. A quick Google search directed me to Raymond Chen’s blog post titled The apocryphal history of file system tunnelling.

As I started reading, I immediately realised that I have heard about this concept before but up until then I didn’t know what it was. Without spoiling it for you, I won’t tell you exactly what it says, but I really liked the analogy of quantum mechanics and how the process of “short name saving” works.

Cutting long story short, even if you know what File System Tunnelling is but you don’t know what I’m talking about, go and give it a read!