hein0us – Page 2 – Pending Investigations

Malware Analysis from Virustotal: DeepLinks PDF Exploit

Last week, I went to a local security meetup for the first time. That coupled with some recent networking and building connections on Twitter has been super motivating for me. I now have a lot more things to analyze from different repositories, and seeing pros and veteran security people post regularly on Twitter motivates me to get something out. So this next sample comes from VirusTotal (they were kind enough to give me an academic account):

Malicious PDFs in General

PDFs are organized in a way that makes cross references quite visible. Streams and different types of objects are easily parsed from text and are generally quickly recognizable when you know what you’re looking for.

Good objects to look out for in malicious PDFs are OpenActions, JavaScript, Automatic Actions, Embedded Files and Embedded Flash. You can open PDFs in a text editor to see objects, but I’m a fan of Didier Steven’s PDF Tools (which come, fortunately, preinstalled on the FLARE VM I use).

Diving In

The first tool I ran was pdfid, which parses the names of known PDF objects to give an overview of a PDF’s contents:

As we can see, this file includes several JavaScript objects, an embedded file, and an OpenAction, which definitely warrant further investigation. To look at individual streams of interest, I used pdfstreamdumper, a tool from Sandsprite.

Only the bottom window is really relevant here; the top window is just gibberish that gets displayed when the PDF loads.

The object in the main window may be nonsensical, but I used a cool feature of the tool to search for all of the Javascript objects and see them at a glance (visible in the bottom window of the tool). There aren’t too many objects to look through in this case, but it’s good to think of scenarios with tons of objects and how one would efficiently search through them.

The object I’m most interested in at this point is the one with the OpenAction which also seems to contain a function, although the second object with the embedded file definitely seems relevant. So, let’s take a look:

The OpenAction object and its encapsulated function.

This OpenAction may look a little weird, but it’s barely enough obfuscation to even fool an automated system. The things to take notice of are the keys, like [‘cName’] and [‘nLaunch’], which are standard parameters you can look up. In this case, the big picture is that the variable hadapet is used to open a file called ‘downl.SettingContent-ms’ with the ‘exportDataObject’ function. nLaunch refers to the way the file is exported/opened, and cName refers to the filename.

Now, where can we find the opened file, downl.SettingContent-ms? In order to do that, we need merely go up to the 2nd object.

Object 2 doesn’t seem to contain much, but it points us in the right direction to find the file that gets launched. Object 2 is a file specification describing Object 1, which you can see from the line “/F 1 0 R/UF 1 0 R.” We can see that Object 1 is described as being the file we are looking for, downl.SettingContent-ms. So let’s focus on that object, the embedded file which is the meat of the exploit:

Here we have what appears to be an XML-formatted file which holds the downloader function of the malware. Within the DeepLink tag is the main exploit, which uses Windows Powershell to download an executable from a remote server, then creates a process using that executable. Clearly, remote code execution is enabled by this DeepLink tag, because otherwise you usually wouldn’t be able to call Powershell from inside an XML file. You can read more about the exploit method here.

Detection Rates:

Fortunately, this PDF is now well detected by antiviruses on VirusTotal and has an incredibly low community score. However, on reverse.it, there appeared to be a detection rate of only 5%, at 3/57 antiviruses flagging the file. I wanted to see what was being flagged by reverse.it’s behavioral analysis, and I did note the embedded file, plaintext IP and WMIC reference were indicators, but I didn’t see much on the DeepLink tag or use of Powershell.

IOCs:

Command & Control/URL: hxxp(:)//169.239.128.164

MD5: 6354A39C95A58B85505E6C8152443100

Strings: DeepLink, Powershell, .exe

Next Time

I’ve also been working on some Windows PE malware and will make another post for that soon. I’ll be putting a lot of time into Practical Malware Analysis, now that I’m done with technical interviews for the time being. Stay tuned and thanks for reading.

Dionaea (Honeypot) Update

After spending many hours on my old and slow iPod trying to install the nepenthes honeypot program through a terminal emulator, I realized that it was a terrible idea and moved on. I ended up installing Dionaea on my Raspberry Pi instead, using a client-server deployment method called Modern Honey Net. If you plan to follow the Raspberry Pi deployment guide, I have tips at the end.

With this method, a sensor like my Raspberry Pi reports attacks and submits payloads to a central server. I decided to just keep a VM running on my desktop to be the server. I had to troubleshoot network problems and debug conflicts between services already running on my VM and the MHN server program, but in the end it was worth it:

Here we have the first 2 attacks on my honeypot (1/min so far).

MHN’s guide is extremely helpful and seems very straightforward, but pay close attention to the deployment script for Dionaea on the Raspberry Pi. I searched for hours to figure out why my install wasn’t completing; it turns out one of the main problems is that the RPi deployment script downloads an old version of openssl that doesn’t exist in the repositories anymore. I had to go 4 updates up to find a version of the library that worked. I might need to contact the developers about that… (Update: there was another bug with one of the files being out of date so I had to reinstall the honeymap module. Details at https://github.com/threatstream/mhn/issues/619.)

In other news, I’m going through some interesting technical interviews that I’ll be taking a pit stop to prepare for. I’ll be going through microcorruption because I think I’ll have to be able to hack an embedded device. If I do write-ups for microcorruption, I’ll definitely have a spoiler alert.

0x00637961

Shorter Post: Goals for the Next 2 Weeks

So, now that the semester will be starting soon, I want to get some action items off the ground while I have (some) time. Mainly:

Get my own honeypot(s) working so I can see what is out in the wild, especially what’s attacking MITnet (the 18.X.X.X subnet). I’m planning to use nepenthes or Dionaea, low interaction honeypot tools, on an old iPod touch with the MobileTerminal emulator on it. I might use my Raspberry Pi as an HTTP server for uploads from the iPod, since it’s a bit weak/slow for constant access. If the iPod can’t handle nepenthes, I can run the honeypot on the Pi, but I would prefer to have some use for this old thing. I’ve been wanting to do this for a bit, and I’m not sure if it’s possible, but it’s worth a try.
Perform full analysis of a malware sample from current trackers. It’s time to look at some malware from the wild rather than from books and courses (although that malware was, of course, originally in the wild).

Stay tuned for the blog post follow-up for these goals!

Short Post: Weeks in Review

Hey guys,

Just wanted to do a short post to update you all on things. The past 2 weeks have been really eventful. On January 15th, I went to the MIT AI (Artificial Intelligence) Policy Conference to learn about how AI and Machine Learning are currently being used in research applications. I also got a chance to see how policymakers and the media perceive AI and its potential. The conference covered applications on everything from healthcare and privacy, to transportation, to national security. I’d like to say I was surprised by the lines of discussion, but it’s clear that technology drastically outpaces the means to legislate and legally understand implications. As one gentleman said, “if the research community doesn’t define AI [and its practical consequences], lawyers will.”

This past week I also got the opportunity to attend the Cybersecurity Insight event, hosted by MIT Sloan in collaboration with Kaspersky Labs. I was really excited to see the presentations, as they were talking about Critical Infrastructure Security, which is a big interest of mine. Unfortunately I had to work, so I missed the information-based presentation, but I got off just in time to attend their CTF! The challenges were really fun: I learned more about exiftool and image metadata, and I got to show off my knowledge of memory forensics. It just so happened that their challenge was kind of similar to the one from the last blog post :). I received an archive with a strange file (my Mac identified it as a MacOS binary, which was dubious). Since the file was a gigabyte I decided against reversing it and put it right into Volatility with the imageinfo plugin. When it turned out to be a Windows 7 memory image, I was off to the races.

The challenge was to first find the suspicious process that had been injected and look through its File handles (with the handles plugin to find the file it had written to the Desktop, which contained the first half of the flag. This half-flag was encoded in Base64, which would be key to recognizing the second half of the flag. The second challenge was to dump that malicious process from the image and do a little reversing. The executable was compiled in .NET, so decompilers were readily available, if not easy to install on my Mac. With the code decompiled, one could see that the malware iterated through the registry to find a given key. By using the hivelist plugin from Volatility, you could find several suspicious subkeys (Flag and Notflag, for example). But only one subkey appeared to be in Base64 encoded format. After combining the two halves of the flag in a Base64 decoder, the flag was revealed! That was just one of the challenges available, but definitely my favorite. It was a really fun event overall and I’m glad I went.

RingZer0 CTF Malware Analysis: Capture 2

Welcome back. I recently found the RingZer0 CTF website while looking for some malware analysis/RE challenges. CTF-style malware analysis challenges can be harder to find online; I’d definitely like to see a Vulnhub for compromised machines, where the challenge is to recreate the infection timeline, but for now I’ll settle.

Capture 2 seems like an interesting challenge because the given file is a memory image. I’ll run it over to my RemSift machine (Remnux and SIFT installed on Ubuntu) and hopefully expand my memory forensics knowledge.

I ran volatility’s `imageinfo` plugin on the image to identify the OS and version with a search of the KDBG structures.

It appears to match the profile for Windows XP Service Pack 2. This is good because if I have to pull malware from this image and analyze it, which is likely, I’m much more likely to understand Windows libraries.

Question 1: What is the CVE of the exploited vulnerability?

Well, that’s a tough question to begin with. CVEs are very specific identifiers for exploitable vulnerabilities, and there are thousands of them. If I’m lucky, I can look in the command history for the memory image using volatility’s plugin cmdscan, and maybe the attacker will have used a metasploit module with a CVE I can look up.

Except I forgot cmdscan only works for Windows 7 and above. Let’s try the consoles plugin instead.

Well unfortunately, the plugin didn’t give me a command history as it might on a Windows 7 machine. We have a process ID and we could probably get some strings out of memory, but I feel like this might be a dead end. Maybe we can work backwards from more evidence to get the CVE, so I’ll move on.

Question 2: Process Name and PID of the Exploited Process

Okay, I might know how to do this. A process that has been exploited by malware should show signs of compromise, including the loading of malicious libraries or remapping of memory addresses. One of the easiest ways to use a process to call malicious code is writing malware to a place where it can be executed in memory. The first way to look for evidence of this in memory is looking at the process maps for containers that have the permissions Read, Write, and Execute set. This information can be found in a process’s VAD, or Virtual Address Descriptor.

Many processes may have memory containers with RWX set, so searching through all the VADs in memory could be tedious. Fortunately, there is a Volatility plugin that searches for VADs with RWX set on memory containers; it’s called malfind.

A process with the VAD protection RWX; in this case, malicious.

As you can see, malfind is extremely helpful. It displays the process name, process ID number and the address in question, in case we want to dump the memory at this location for further analysis.

Fortunately, it also displays the beginning of the data at the location in hexidecimal and ASCII, and you can see the ‘MZ’ translated from the hexidecimal value 4d 5a. MZ is the file header for a Windows executable, which means the data at this location could be a malicious executable injected into svchost.exe. Plus, svchost is a commonly used process for hijacking and injection because there are usually several legitimate instances running on a given machine. I submitted this as the answer, and jackpot! Let’s move on:

Question 3: Connect back IP and port?

This question is likely asking about the network activity of the compromised machine connecting back to the attacker. More than likely, a backdoor of some kind was used; perhaps a reverse shell. Let’s run the memory image through the gauntlet of volatility’s network plugins, starting with connections and connscan:

`connections` didn’t display any results, but `connscan` pulled through. This is likely because the connections listed by `connscan` were terminated by the time the memory image was acquired.

As you can see, there were several remote network processes occurring on different ports. However, only one of them matches the Process ID of the compromised process svchost.exe, which is 1092. The infected machine is connecting back to 10.0.75.16 (looks like a computer on the same internal subnet) through port 21. Port 21 is commonly used by FTP, the File Transfer Protocol, and is another indication this may be our reverse shell to the attacker.

And we were correct. Moving on…

Question 4: What is the Victim’s User Password?

The first thing that comes to mind when thinking about extracting passwords from memory is a post-exploitation tool called Mimikatz. Used offensively, it exploits the lsass.exe process with malicious code and reads passwords from memory structures. It was recently adapted into a Volatility plugin for use on offline memory dumps, which will be helpful to us here. Let’s run it.

Running the mimikatz plugin on the memory image.

No dice on that. Well, maybe it’s am issue with my RemSift installation. I pointed the mimikatz plugin at the whole memory image, but there’s another approach where you dump the memory of the lsass process and point mimikatz at it instead. Unfortunately, I tried this and found that volatility doesn’t have support for minidumps (the format of the process memory dump). This means I’ll need to take it to a native installation of Mimikatz, on Windows.

Using Mimikatz against the minidump on my FLARE (Windows 7) VM.

No luck there either. Maybe we can try a different approach to recovering the passwords, although I can’t imagine why Mimikatz would be failing. Let’s look for password hashes in the registry hives.

I’ll use the volatility plugin hivelist to find the memory addresses of the SYSTEM and SAM hives, which hold the hashes to the passwords we want. After that, there’s a plugin called hashdump that parses the hashes. Let’s try that strategy:

Using Volatility’s `hashdump`, passing in the offsets of the SYSTEM and SAM hives.

Okay, good signs: we see the user and hash for ‘victim’, the account we need. Let’s see if the hash is crackable.

I used hashkiller.com, an automated hash decrypting website. Some of you may use CrackStation, but I’m glad I tried another site, as it didn’t work for me.

And it worked! The decrypted password was correct.

Well, I think that’s enough for now; I’ll be attempting more challenges like these in the next CTF-related blog post. Thanks for reading!

Practical Malware Analysis Chapter 3

This week I’m getting back to Practical Malware Analysis after looking into some honeypot options. But now I need to get back on the grind; I’ll come back to that later.

Chapter 3 of PMA (as I’ll refer to it) is a dynamic analysis refresher, helping aspiring analysts develop a workflow for finding those host-based and network indicators. I won’t repeat all of their write-ups, which are quite detailed, but I will outline my dynamic analysis process and explain why I picked that order. But first:

My Lab

I’m using Oracle’s VirtualBox (yeah, I know) with a host-based adapter for my analysis. Currently I’m working with a Windows XP machine as my analysis machine, and a Remnux machine for network forensics.

In order to simulate network traffic for malware I set up the Remnux box as the DNS server for the Windows box, and of course they are on the same subnet so they can communicate. PMA recommends using ApateDNS, but I prefer just going through Control Panel and making it a lasting change. Besides, it’ll just be one less program to open later on a crowded Dynamic Analysis screen.

Changing the DNS server through the Control Panel.

The final important thing one should do before analyzing any sample is to snapshot, saving the state of the virtual machine (VM). But now to the meat of the matter:

Dynamic Analysis Workflow

Start Process Explorer and Process Hacker
Start Netcat Listeners (ports 80, 443)
Start Process Monitor (Procmon)
1st Registry Snapshot (Regshot)
Inetsim, Wireshark
Run malware
Analyze Process Explorer, Process Hacker
Wait 5 minutes if it has not elapsed
2nd Regshot
End Procmon
Analyze Wireshark, Netcat, Inetsim, Procmon, Regshot
Revert snapshot

Explanation

Process Hacker and Process Explorer are very useful for runtime analysis. They don’t generate tons of logs like Procmon, so it’s fine to run them first. I start Procmon after that because its filtering capabilities can eliminate the noise of later programs. However, Regshot has fewer capabilities to deal with noise. So I prefer to do as few operations between Regshots as possible.
I start Inetsim and Wireshark right before executing the malware to avoid any noise from the Windows box attempting to look for network shares, request updates, or use NetBios.
I prefer not to end Procmon or Wireshark captures until sufficient time has passed. For example, Lab 3-2 waited a minute before executing.

Things I Learned

One tip from PMA that was especially helpful was in the capabilities of Process Explorer. During Lab 3-2, you use rundll.exe to execute the malware and eventually an svchost.exe is spawned that uses that DLL. But as many ~~geeks~~ people know, there are often many svchost processes running simultaneously. Of course, there are many ways to narrow down which process used the DLL (my first instinct was to check the properties of each and search through the handles), but few are as quick as:
- Process Explorer: Find > Find Handle or DLL

Well, that’s it for the first post! Feel free to leave me some feedback and I’ll post an update when I finish Chapter 4 (or I’ll get sidetracked with some CTF problem).