Dumping DarkComet config out of memory using volatility

Ian over at TekDefense has a great post up on using volatility to analyze a computer that has been compromised with the DarkComet RAT. While reading through his post I noticed a section where he was using strings to find the config of the DarkComet RAT. Since the config was all in plain text I figured I could find it using volatility and volshell and maybe even write a plugin to dump the config.

I used the memory sample that Ian has linked to from the post listed above to use for my initial testing. I fired up the VM that I had from the volatility training I took in Reston, VA in 2013 and did the following:

First I need to figure out what OS the memory image was taken under, imageinfo to the rescue:

ImageInfo from volatility

ImageInfo from volatility

In Ian’s post he provided a yara rule that looks for the mutex in darkcomet. First lets run yarascan with that rule and see what we get:

DarkComet YaraScan

HDarkComet YaraScan

Hmm looks like Process runddl32.exe Pid 1524 might be the culprit. Juts for giggles lets do a quick handles and look for any mutants that contain DC_MUTEX in them.

DarkComet Mutant

DarkComet Mutant

The pid matches. Now lets open up volshell, set the current context to Pid 1524


and then print out the bytes as a canonical hexdump from the address where we had the yara hit.

db(0x0142a539, length=512)

DarkComet VolShell1

DarkComet VolShell1

Oohh look we see the mutex and a lot of the same config options as referenced in Ian’s post, it looks like the entire config is stored in plain text in memory.

In Ian’s post there is also the string #BEGIN DARKCOMET DATA —  I wonder if that can be found using volshell as well. Lets print the bytes again but this time lets move back 21 bytes from the address where we have the yara hit for the darkcomet mutex.

db(0x012a539 – 0x21, length=512)

DarkComet VolShell2

DarkComet VolShell2

Yup sure enough its there. Now I begin to think this is a great case for a volatility plugin to dump the config. Brian Baskin has a great post about how easy it is to create a volatility plugin that I used to help guide me through this process. Below is what I came up with:

DarkComet Volatility Plugin

DarkComet Volatility Plugin

In my testing I decided to look for the #BEGIN DARKCOMET and #EOF DARKCOMET instead of the mutex. The reason being I have seen a few dark comet instances with DCMIN_MUTEX as the mutex. Take a look at this search query over at totalhash to find some samples that have the DCMIN_Mutex.

Also, in my config due to the way I decided to try and dump the config I have had to build in a dumper that will dump 400 bytes after the start address. If anyone has any suggestions or improvements to the code I would be more than happy to incorporate them 🙂 Below is the output of the config dumper using the memory image provided by Ian.

DarkComet Config Dump Output

DarkComet Config Dump Output

Thankfully, DarkComet stores the config in plain text and made this plugin quite easy to write. If you haven’t tried out volatility you really should it is amazing what you can do with it.

I have put the plugin up on github so feel free to grab it and test it. Let me know what you think and as always happy hunting!


Using IIS logs for fun and malware profit!

On an intrusion I was investigating last year, I was given access to IIS logs of a public facing web server that was comrpomised via sql injection and that sql injection was used as a pivot point for the intruder (more on this in another post)

I wanted to start reviewing the IIS logs so the first thing I did because the logs had a lot of encoded traffic was to run the logs through this simple python script to unqote all the logs to make it a little easier to investigate:

#!/usr/bin/env python
import urllib
log = open("/home/investigate/case111/weblogs//iislogs.txt","rb")
log_unquoted = open("/home/investigate/case111/weblogs/iislogs_unquoted.txt","wb")
for line in log:

While manually  reviewing the unquoted logs I saw a entry that contained the following:
exec master.dbo.xp_cmdshell ‘echo gg=^”4D5A … ^”_>> C:\dir\fg.vbs’;exec …

First you might see a xp_cmdshell – yup this host was vulnerable to sql injection and xp_cmdshell was enabled (yes, I know its bad but hey I was the responder don’t shoot the messenger)
You might notice that 4D5A is the hex header for the magic number of DOS Executables. To me this looked like the attacker was uploading a exe through the webserver. I wondered if we would be able to extract through the logs what the attacker uploaded.

I decided to grep for any line in the file that contained fg.vbs and write it to a text file
cat iislogs_unquoted.txt| grep “fg.vbs” > fg.vbs.txt
I then used awk to show me the 11th field of the logs which had the hex data for the exe they were attempting to upload.

cat fg.vbs.txt | awk ‘{print $11}’ > fg.txt

I then used a global search and replace in vi  to remove the following characters ^” from the begining and ^”_ from the end.
This gave me a text file full of hex, I then copied the hex and pasted it into a hex editor and saved the results as fg.exe.

I then copied fg.exe over to a vm I use for testing suspicious files. I then ran the following fg.exe /?

fg.exe usage

fg.exe usage

Looks like a password dumper lets run it with out any switches:

Results of fg.exe

Results of fg.exe

After seeing this was successful I looked for any other entries in the logs that looked like the attackers where uploaded an executable. I was able to also recover a 32 bit and 64 bit version of windows credential editor.

Being able to carve these files out of IIS logs was very helpful and eye opening and allowed us to confirm what the attacker was able to run.  Who would have known that IIS logs could be used to carve malware and not be used generally for web site usage statistics.

As always happy hunting!

More ZeroAccess!

I previously posted about using Redline and OpenIOC to detect a system infected with ZeroAcces. I recently as reading through the postings on the Emerging Threats Signatures list and saw there was recently two signatures added for ZeroAcces.

2015474 – ET TROJAN ZeroAccess udp traffic detected

2015482 – ET TROJAN ZeroAccess Outbound udp traffic detected

I wondered  if these signatures would work with what the variant  I previously posted about. I decided to give it a shot and deployed the great tool SecurityOnion by Doug Burks to implement full packet capture on my esxi server. I created a new vswitch with no attached physical adapters, deployed a vm running pfSense for a firewall connected to the new vswitch and the default vswitch to gain internet access. A  Windows XP system and security onion for monitoring. This is what my ESXi layout looks like:

ESXi vswitch0ESXI Layout

Following the easy installation for security onion I was up and running in a few minutes with just a few clicks. I then decided it was time to run the malware I used in my previous post. With in a few milliseconds I had hits in the sqgil console that looked interesting.

Sguil Hits

I started to review the alerts and started with the first hit “ET Policy IP Geo Location Request” I had sguil provide me a transcript of the session and here is what was provided. Note, I have removed all the location based data in the response hence the blank fields.

GeoIP Transcript

I then looked into the “ET TROJAN ZeroAccess udp traffic detected” hit and reviewed the packet data in sguil note the highlight portion in the data section is what caused the IDS rule to fire.

ET TROJAN ZeroAccess udp traffic detected

I then went and looked at the ET TROJAN ZeroAccess Outbound  udp traffic detected, again the highlighted portion in the data field is what caused the IDS rule to fire. With in a few seconds the count for this rule was increasing and the destination ip’s were all different and continues to increase so the rule is quite noisy.

ET TROJAN ZeroAccess Outbound udp traffic detected

At this point the recent ZeroAccess signatures from Emerging Threats hit, they show a DNS query associated with the malware when first run, and the attempted communications outbound to the ZeroAccess P2P network. At this point you could say based on network evidence the system was compromised. However, you could take it a step further and use the IOC previously discussed and check the suspect system to see if there any other hits to confirm the compromise at the host level.

I decided to let the malware run a little longer and saw some other interesting hits. Obviously, the malware is involved in some click fraud.

Other interesting hits

I never used the system after running the malware I just watched and it sure looks like it was busy. Here is all the alerts it generated in sguil after running for about an hour. Note the number in the CNT column for the ET Trojan ZeroAccess Outbound UDP detected and you will see why I mentioned it was noisy.

1 hour of alerts

You could dig more into the traffic and find the click fraud traffic but that is beyond the scope of this post 🙂

As always happy hunting!

IOC: ZeroAccess

The other night I happened across a tweet from Ken Pryor @KDProyr saying he was looking at a system that was infected and he thinks it was using P2P based on firewall logs. Well based on some things  I had seen recently at work I thought it might be a variant of  ZeroAccess.  I quickly fired off a couple of tweets to Ken asking if it was happening over a particular UDP port and from there where I thought the malware might be. Ken quickly confirmed that the malware was indeed where I said it would be. Yah! I was excited because I had provided help to someone else in the DFIR community even if it was just a small amount of help.  I then  noticed Ken mentioned he was using Mandiant’s Redline for analysis and I thought  why not try and write an Indicator of Compromise (IOC) and see if it hits. I luckily had a recent copy of a ZeroAccess variant for me to play with to create the IOC.

Mandiant’s Ryan Kazanciyan has a great blog post about using Redline and OpenIOC to build effective indicators and I used that as a starting point for creating this IOC.

I quickly loaded up a vm and did a registry snap shot and ran the malware and waited a few minutes took another registry snapshot and rebooted to see if the malware persisted. Sure enough it did so I went and ran a Redline Audit to get an idea of what was going on and to help create my IOC.

Redline quickly showed two process that based on their Malware Risk Index (MRI) score are process I should look at and a few others that I might want to take a look at as well.


Well the first one was the actual Redline agent that I ran to create the audit after a quick review I determined it wasn’t something I should look into further. I then moved on to the second process svchosts.exe

I quickly reviewed the Malware Risk Index report for svchost.exe and noticed under the Named Sections section  a few negative factors. A few that were injected into that process and two that were not signed and they looked to be in a rather odd location.

MRI Report Negative Factors svchost.exe

I attempted to copy the n file from the image above to my local workstation for further analysis and my AV quickly told me that I was looking at a variant of Sirefef which is another name for ZeroAccess

AV Alert on malicious dll

I then moved on to looking at the file handles that svchost.exe had opened and saw a few entries all from the same c:\windows\installer directory.

svchosts.exe file handles

Nothing else stuck out to me so I moved on and took a look at what ports svchost.exe had opened and one UDP port in particular stuck out as well

svchost.exe ports listing

So far I have a pretty good list of indicators but I wanted to take a look at the Explorer.EXE process as well just to see if anything there was interesting as well and sure enough in the Named Sections there was another hit that stuck out.

Explorer.EXE Named Sections

I then decided to take a look at the detailed sections  for that hit and I looked at the Exports and saw an exported function of ?GetWindows which I thought might be a good indicator. At this point my quick analysis was done and I thought I would take a look at the registry snapshot and see if any registry keys being added or changed stuck out. I decided to search for the string  235c1d10-b0b5-289f-6f20-91dd1f9a6306 since that was unique across the processes and I came across this entry in the snapshot:

HKLM\SOFTWARE\Classes\CLSID\{F3130CDB-AA52-4C3A-AB32-85FFC23AF9C1}\InprocServer32\: “\\.\globalroot\systemroot\Installer\{235c1d10-b0b5-289f-6f20-91dd1f9a6306}\n.”

That registry key change also matched the key specified in this Sophos blog post so I took that as another indicator to use and started building the IOC.

My inital IOC looked like this I have two extra UDP ports in my IOC based on previous cases at work that had been infected with ZeroAccess:

Initial IOC

I saved the IOC and told Redline to Create a new IOC report and a few seconds later I had hits on the Files, Ports, Process and Registry indicators I used

Original File IOC Hits

Notice something on the file hits? All of the files have a created date of 2008-04-14 12:00:00Z I know that is something that can be modified by the malware author but I thought it was unique enough I should redo the indicator to include that date for file created time.

I took a look at the file hits and I also saw the files with the name n have a PE Type of DLL so I thought I should add that as an indicator as well.  Now lets look at the other hits


IOC Port Hit


 Processes IOC Hit

Explorer.EXE Hit:

Explorer.EXE IOC Hit

svchost.exe Hit:

svchost.exe IOC Hit


Registry IOC Hit

So we know the IOC works but based on my analysis I wanted to add the File Created Date and PE Type to the IOC. Now my IOC looks like this:

New IOC with more indicators

I ran the new IOC through Redline again and this time I got more hits but only in the files section:

New IOC File Hits

As you can see we found a few extra directories that were not there previously. At this point I think I have a pretty good indicator. I sent Ken a DM on twitter and asked if he would like to run my IOC through his Redline Audit to see if it worked on his infection. A little while later he sent me the report and sure enough he had hits across all the indicators, files,ports,process,registry.Yah! Glad to know it wasn’t just working on my instance of the malware,  I then had another case at work based on network traffic that appeared to be infected. We grabbed a quick Redline audit of that system and used the IOC and sure enough we had hits there to so I think I have enough confidence in it to release it to the public. I will be posting the IOC to Mandiant’s OpenIOC Forum and to forensicsartifacts.com shortly and will update this post with links to the IOC once they have been published.

I hope others find this useful. If you have any feedback or suggestions for modifying the IOC please let me know.

As always happy hunting!

Hunting: Recent news and your proxy logs

If you have been reading any of the blog posts or the twitter verse the past few months you might have seen reference to some Adobe Flash and Microsoft 0-days being used and maybe wondering if you have been a victim. Using nuggets of open source  intelligence like info from these posts by ShadowServer and  Sophos you just might have enough  data to search your proxy logs and see if you have experienced any of these attacks. You do have your web traffic going through a proxy don’t you? If you don’t you should start doing it and start collecting the logs. The logs are a treasure trove of information if you want to go hunting.

So let’s go on a hunt.

For this hunt like previous onces I will be using ArcSight Logger because that is what I have access to. I will also be leveraging websense for the proxy logs as well.

Indicators from the ShadowServer and Sophos blogs:


Logger Query:

deviceVendor = “Websense” AND  ( ( ( requestUrlFileName CONTAINS “deploy.html” )  OR  ( requestUrlFileName CONTAINS “deployJava.js” )  OR  ( requestUrlFileName CONTAINS “movie.swf” )  OR  ( requestUrlFileName CONTAINS “BrightBalls.swf” )  OR  ( requestUrlQuery CONTAINS “Elderwood=” )  OR  ( requestUrlQuery CONTAINS “apple=” ) ) )

Now this isn’t the most efficient query because of the CONTAINS operators but there is a trade off when doing searches like this and you just have to be prepared for it. There could also be some false positives as well espically around faq.htm so be prepared to use a  little excel foo. Or you can leave the faq.htm off I will leave that up to you. I did a quick hunt and went back 2 weeks and got the following hits:

Notice the swf file is different but the query was for Elderwood.  If I had just put  BrightBalls.swf?Elderwood as a search parameter I would have missed it. Good thing the bad guys used the same query string.  So do some experimenting you might find slicing and dicing on key terms will get you more data and more places to keep hunting.

Now for me this showed a sign I needed to do more digging and going for some packets to review if you have them and perhaps another search this time adding Geoffrey.swf as a search parameter to see if there is anything additional there.

As always happy hunting!

Using CIF to create content for ArcSight – Part 2

In my previous post Using CIF to create content for ArcSight – Part 1 I quickly went over how to populate an active list with data from CIF. Now we are going to take it a step further and start monitoring for hits on that active list and generate some other content for ArcSight.  This post is quite long so the TL:DR version

Create active list for monitoring, create rule to populate the active list when a domain query matches a domain you are monitoring, create active channel/data monitor to watch for events.


This is a very basic active list/correlation rule example you can do much more but this should be a decent starting point.

Also please note for this example I am using ISC Bind DNS logs so the query field gets mapped to the DeviceCustomString4 field in ArcSight

First let’s create another active list :

In the Navigation Panel go to Active Lists and right click your personal folder and select New Active List

New Active List

Next in the Inspect/Edit Panel modify the Active List to meet your needs but in this example it will have the name “Suspicious Traffic”, it will expire entries in 3 days if an entry is not updated, 10,000 entries will  be allowed. These are all changeable fields after the active list is created.

Now set the fields the Active List will use (These can not be changed after the list has been created). I have entered:
Attacker Address (Key Field), Target Address, Target Port, Domain, Category Outcome, Description, Source

Now let’s create a filter so that we can match the events we are looking for:

New Filter

I gave the filter the name “Discover Malicious Domain Lookup” and started with creating the following conditions

Filter Conditions before Active List

I then add an InActiveList Condition

Add In Active List Condition

Then I added a condition that checks if Device Custom String 4 (The BIND DNS Query field) matches the Domain Name filed in the Malicious Domains Active List

Matches Malicious Domain

The filter should look something like this:

Full Filter

Click apply to create the filter and move on to creating the Correlation Rule:

For this example we will be firing on every hit which can be noisy. You might want to tune for your environment and capabilities but this should be a good starting point.

Start by creating your rule

New Rule

Give it a name then click on the conditions tab. Right click and select matches filter:

Matches Filter Condition

Select the filter we created above:

Selecting your filter

Next we will build some local variable that will help with populating the Suspicious Traffic Watchlist we created. Click the Local Variables Tab.

Click the + button and add a new Local Variable select List from the Categories Window on the Left and the GetActiveListValue in the functions window.

Setting the GetActiveListVaule Function

Give the variable a name I chose getDomainWatchList and map Domain Name to Device Custom String4. Click Ok and create another local variable

Setting the getDomainWatchList Local Variable

Next we create a variable using the String Categories and the Concatenate function:

String Category Concat funftion

The variable name is getWatchlistSource and it’s settings are below.  The first string argument source is from the getDomainWatchList variable we just created above. The second string argument is blank for this rule variable because we are only matching on this one source.

Get WatchList Source

Next create one more variable using the Concatenate function caused getWatchListDescription. The first string argument source is from the getDomainWatchList variable we just created above. This two has a blank string argument for the Concatenate function.

Get Watch List Description Variable

Now that all of our variables are set we need to make sure they are aggregated so they get populated when a rule hits. Click on the aggregation tab and under the Aggregate  only  if these fields are identical and click the Add button. Select the variables getWatchListDescription and getWatchListSource we just created. Click ok and let’s get to working on the actions for the rule.

Aggregation Fields to add

First we need to set a few fields that we will use to populate the event created when the rule fires. Deactivate the On First Event Action and enable the On Every Event Action then right click and Select Add -> Set Event Field .  Let’s use Flex String 1 and Flex String 2 for that purpose and use the variables we created above and click OK.

Set Flex String Event Fileds

We are almost done I promise 🙂
Now we need to add any systems that match the rule to the  Suspicious Traffic Active List we created at the beginning of this post. Right Click the On Every Event Action then right click and Select  Add -> Active List -> Add to Active List below are the mappings for the fields in the Active List.

Add to Active List Action

Now click ok and then go back to the aggregation tab and add the following fields so that your fields match the ones below:

Aggregation Fields

Now we are ready to apply all the conditions for the rule and deploy it as a real time rule. Once it is deployed as a rule you can try and generate some test hits by doing lookups of domains in the active list against the server creating the DNS logs. Just make sure you know the address of your system :). To monitor for events create an Active Channel where the filter is Name = Discover Malicious Domains or whatever name you gave the rule above. If everything works you should soon see events in your active channel.

Active Channel Test Hit

You can then look at the entries for your Suspicious Traffic Active List and you should see entries in there that match the results in the active channel.

Active List Entries

Now you can start to have some fun and create dashboard with data monitors around these type of events below is a screen shot of a sample dashboard. The top half is of an event graph and the bottom is the top bucketized count of malicious domains queried.

Sample Data Monitors

Now the rest of the content creation is up to you but hopefully this gets your juices flowing and you come up with some other great use cases for CIF related data. As always happy hunting!

Using CIF to create content for ArcSight – Part 1

If you use ArcSight hopefully by now you have come across the great ArcOSI Project for generating content for use within ArcSight. I have used it in the past and liked it but I found myself having to look for more context around the alerts it generated. I recently came across the Collective Intelligence Framework (CIF) and really like how many intel sources it aggregates like ArcOSI does and how it stores the data from the intel source and I think this too can be a great source of content for ArcSight. I have previously blogged about integrating CIF and ArcSight, but that was just using CIF as a tool for looking up data with in ArcSight not using CIF to create content to be used by ArcSight.

EDIT: 6/10/2012 if you haven’t seen @kylemaxwell ‘s Post Introduction to the Collective Intelligence Framework I highly recommend check it out!


I think the content CIF can provide could be great for ActiveLists and Correlation rules on those active lists. I came up with a few possible scenarios on how this content could be used:

  • Malicious Domain Queries – DNS Logs
  • Malicious Domain Web Traffic – Proxy Logs
  • Malicious IP Traffic – Firewall/Proxy Logs
  • Scanner Traffic – SSH/Firewall Logs

For the Scanner Traffic maybe instead of reporting on the noise of someone knocking on your door, you report on any traffic that was accepted (meaning authentication happened) but that is up to you.

I have been working on a python script that assumes you are using the CIF Perl client to generate feed data in csv format, then the script will parse the csv files and send them like ArcOSI does to ArcSight via  CEF over syslog. I have posted the script and a quick tutorial on it over at the Google Code Project cif-csv-parse-to-cef.

A quick example for this post will be to generate the domain/malware feed using the medium severity and confidence level of 85, send it to ArcSight and have it add the feed data to an Active List. Part 2 of this post will cover writing a correlation rule to monitor the Active List for actionable data.

Let’s start by first creating the Active List and the Correlation Rule to populate the Active List:

In the Navigation Panel go to Active Lists and right click your personal folder and select New Active List

New Active List

Next in the Inspect/Edit Panel modify the Active List to meet your needs but in this example it will have the name “Malicious Domains”, it will not expire, 100,000 entries allowed (these settings can be changed later) Now set the fields the Active List will use. I have entered:
Domain, Source, Confidence, Description

Active List Edit Panel

Click Apply and all that is left is to create the correlation rule to populate the Active List.

New Rule

Next add a name for your rule

Rule Name

Then click on the Conditions field and create the following filter.

Rule Conditions

Next click on the Actions tab and make sure you De-Activate the Trigger for On First Event| Action. Then activate the On Every Event Trigger

Deactivate Trigger

After activating the On Every Event Trigger right click and select Add -> Active List -> Add to Active List

Select the active list you previously created in this case. Malicious Domains

Select Active ListAfter selecting the Active List you will have to map ArcSight event Fields to the corresponding Active list fields.

Active List Action

Once you click Ok, you will most likely get a pop up message similar to this that asks if you want to add all the ArcSight Fields you mapped in the previous step to the aggregation tab. Click yes, if you don’t then your active list will be blank after the rule fires.

Aggregation Question

Now deploy the rule as a real time rule. Your account will need privileges to do that, If you don’t have them ask your ArcSight Admin to deploy the rule for you.

Now the rule and active list have been created let’s generate content for the rule to populate the active list with.

Let’s start by generating the csv:

$ cif -q domain/malware -s medium -c 85 -p csv > dom_malware.csv

Now run the cifcsv.py script

$./cifcsv.py -f dom_malware.csv -s -p 514 -t Domain

You will see output on the screen similar to this

<29>CEF:0|CIF|CIF 0.1|100|1|CIF Malicious Domain|1|shost=7daily-homebusiness7.net cs1=www.spamhaus.org/sbl/sbl.lasso?query=sbl112756 cs1Label=Source cs2=85 cs2Label=ConfidenceLevel cs3=malware cs3Label=Description

Now if you have an Active Channel up and running with a filter for Device Vendor = CIF and  Name = CIF Malicious Domain you should see something similar to this.

CIF Active Channel

Now if you right click your active list and show entries you should also see that your Active List is being populated with data.

Populated Active List

This concludes Part 1 – Part 2 will cover writing a correlation rule to monitor the Active List for actionable data.

Happy Hunting!