People still use Word macros!?!

Posted in Uncategorized on October 22, 2014 by christopherltaylor

I got an interesting email today.




The headers:

Received: from ( by ( with Microsoft SMTP Server id
14.2.347.0; Wed, 22 Oct 2014 09:02:52 -0400
Received: by with SMTP id cm18so2352642qab.6
for <>; Wed, 22 Oct 2014 06:02:51 -0700 (PDT)
X-Gm-Message-State: ALoCoQmf9GbcGqvsr0EmNIh1kGul9vAE9+L+H3zfk+CntPSkas8OLcrLeM9ISXmYIS16W57cL4L/f3pUKDnO10Mmi5n9T9cnDERwdGJaTC2EeaIDxh6tMsRjT3Dn47O9O/05tSlXz5UayMWhvD9Scvhx7fCjrrFSy0WYOv7nsHpSYcCzPY/mADE=
X-Received: by with SMTP id c50mr52767444qgc.77.1413982971840;
Wed, 22 Oct 2014 06:02:51 -0700 (PDT)
X-Received: by with SMTP id c50mr52767433qgc.77.1413982971744;
Wed, 22 Oct 2014 06:02:51 -0700 (PDT)
Return-Path: <>
Received: from
([])       by with ESMTP id
64si27702535qgy.68.2014.       for
<>;       Wed, 22 Oct 2014 06:02:51 -0700 (PDT)
Received-SPF: Fail ( domain of does not designate as
permitted sender);
Received-SPF: fail ( domain of does not designate as permitted sender) client-ip=;
spf=hardfail ( domain of does not designate as permitted sender);
dmarc=fail (p=NONE dis=NONE)
From: Customer service <>
To: <>
Subject: Reference:UE301325TE
Date: Wed, 22 Oct 2014 18:31:54 +0530
Message-ID: <>
X-Priority: 3
X-Gm-Spam: 1
X-Gm-Phishy: 1
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-SenderIdResult: Fail
X-MS-Exchange-Organization-SCL: 0
X-MS-Exchange-Organization-PCL: 2
X-MS-Exchange-Organization-Antispam-Report: DV:3.3.14101.477;SID:SenderIDStatus Fail;OrigIP:


Let’s start with the basic observations:

  1. From address does match the sending server, both being from “”
  2. “Customer service <>” – doesn’t seem like a legit email address for a customer service rep
  3. “Date: Wed, 22 Oct 2014 18:31:54 +0530” – note the +5:30 is the India time zone.
  4. “X-Gm-Spam: 1” and “X-Gm-Phishy: 1” tells me that the Gmail spam filters (formerly known as Postini) think this is spam and possibly a phishing attempt, but they let it through anyway. Thanks Gmail.
  5. “” is a static IP address of a broadband service, probably in or at least near Mumbai, India. Static addresses usually go to business customers, so this probably belongs to a small company. According to, Airtel runs a cellular network, fixed line broadband to homes, and provides TV service – so, basically, India’s version of Verizon.



It wasn’t the email or the headers that got my attention, though. It was the attachment. It’s been a while since I’ve seen an attempt to use a Word Document to spread malware. Very late-90’s of them.


The first stop was
It was scanned before, but only about 10 minutes before. 0/52 hits at the time I uploaded this.


Stepping over to the “Additional Information” tab, we see some interesting lines.

  1. “File type: Office Open XML Document” but this was a .doc not a .docx.
  2. “File names:” – has been uploaded several times under different names. All the names follow the same two letters, seven numbers, two letters ([A-Z]{2}[0-9]{7}[A-Z]{2}\.doc) format. Indicates programmatically created names and no imagination.
  3. “Company: SPecialiST RePack” – created with a pirated copy of Word. A google of those two words lead me to this Russian pirate website: http:// www . 5peciali5t . tk
  4. “Creator: MMM” – the user name supplied by installed this pirated copy of Word
  5. “MIMEType: application/” – macro enabled. Yup, saw that coming.
  6. “CreateDate: 2014:10:18 09:14:00Z” – this shows when Word created the new document. This is when the “new” button is pressed, which usually occurs before typing and pressing the save button.
  7. “ModifyDate: 2014:10:22 12:53:00Z” – this shows when Word last hit the save button. That is about 2 days worth of work on the part of this attacker, though it could be longer if the macro was cut-n-pasted from elsewhere. What is interesting here is how quickly this went from saved to sent (1pm to 3pm).


On to the file itself. Since it is really a docx and since those are really zipped XML, our first step is unzipping it.

  1. doc/docProps/core.xml – basic metadata, where we got company, author, and dates above
  2. doc/word/document.xml – the actual document. It just says “You didn’t enable macros.” And then has a picture to show you how. How convenient.
  3. doc/word/media/image1.gif – the embedded image


  1. doc/word/vbaData.xml – the part of the word doc that says how to handle the macro. The interesting part here is that there are actually four embedded macros:
    1. ThisDocument.Auto_Open
    2. ThisDocument.h
    3. ThisDocument.Workbook_Open
    4. ThisDocument.AutoOpen

This shows that the code was written to work in either Word or Excel, as AutoOpen is the only one that has meaning in Word, whereas Auto_Open is the command that would work in Excel. Workbook_Open is also Excel specific and slightly redundant, the difference between it and Auto_Open is slight and has to do with when each event is fired.

  1. doc/word/vbaProject.bin – this is the actual macro. I don’t really want to spend a lot of time doing code analysis here, but I will show you some interesting strings pulled from the file. The rest of the file was uploaded to pastebin here
    1. $url = ‘http:// / gr / 4.exe';
    2. $file = ‘crsss2.exe';
    3. $someFilePath = $ScriptDir + ‘crsss2.exe';
    4. $vbsFilePath = $ScriptDir + ‘ntuserskk.vbs';
    5. $batFilePath = $ScriptDir + ‘ntusersss.bat';
    6. $psFilePath = $ScriptDir + ‘ntusersc.ps1′;
    7. exe /c crsss2.exe;

So, basically, the code downloads “crsss2.exe” then tries to execute it via either a VisualBasic script, batch file, or powershell script. The IP “” belongs to a Great Lakes Dermatology in New York.



I have gone this far, I might as well. So, I downloaded the “4.exe” and sent that up to VirusTotal. I wasn’t the first. It’s getting downloaded as 4.exe then renamed to crsss2.exe by the macro, yet crsss2.exe isn’t one of the alternate names that have been submitted to VirusTotal.


I also did a search over at to see what the Cuckoo Sandbox thought of this file. As I suspected, it had already been analyzed there as well.


The “File Detail” tab at VirusTotal contained some fields that I thought might be interesting, but were coming back garbled. They get their data from a great tool that I love called ExifTool. So, I ran that locally and it turns out the garbled text was garbled because it was in Cyrillic.

Time Stamp                     : 2014:10:22 16:47:03-04:00
Language Code                   : Russian
Company Name                   : Корпорация MSoft
File Description               : Утилита запроса сервера терминалов
File Version                   : 5.3.5600.0 (xpclient.010817-1148)
Internal Name                   : qappsrv
Legal Copyright                : © Корпорация MSoft. Все права защищены.
Original Filename               : aaw2.exe
Product Name                   : Операционная система MS® Windows®
Product Version                 : 5.3.5600.0


The “File Description” basically says this is a terminal server utility.

The “Internal Name” “qappsrv” actually matches a legit file from Microsoft that is a “Query Remote Desktop Session Host Server Utility”, though this is obviously not THAT legit file.


Cuckoo Sandbox reports that it does the following:

  1. Drops a file named 2.tmp that is a dll.
  2. Creates a persistence mechanism in HKCU\…\Run
  3. Executes the renamed 2.tmp with rundll.exe
  4. Attempts to connect to http:// / IArej7rcO / @HPZ8A5aPU_W /



Though the hash is different and the detection rate is different, the file appears to share a lot of internal information with this file:



I think that’s enough fun for one day. Back to work.


Posted in Uncategorized with tags on June 17, 2013 by christopherltaylor

I’m not sure how I missed it when it came out in 2009, but Peter Norris has put together an absolutely fantastic write up on the internal structures of the Registry. Deep internal knowledge like this is vital when you are finding parts of old registry files in unallocated space, the page file, or memory. For anyone else who has seen this paper, it is hosted here:

RAW Images

Posted in Uncategorized on August 7, 2012 by christopherltaylor

Many digital cameras will compress their images into JPEG files, making them much easier to deal with for the average consumer. But, occasionally, you run across those that take their image capturing seriously who will set their cameras to save the files in “RAW Mode”. What that means depends on the model of camera. IrfanView is my preferred tool for viewing most images I run across in cases, and it usually does a great job of supporting even these RAW image formats. But, sometimes you want to get a second opinion…

Microsoft publishes a CODEC Pack that will enable its built-in viewers to also properly display most of the RAW image formats. It is available for download here:

Blog neglect

Posted in Uncategorized on March 21, 2012 by christopherltaylor

I’m guilty. I’ve been neglecting this blog. I have a really nice write-up as the next good post, and I got distracted by something shiny and haven’t finished it yet. That is coming soon. I’ve also been working on a couple of projects that y’all will find interesting. To properly host those projects, I’ve moved my personal site to a new hosting service and completely redesigned it in the process. Part of that redesign, for the purpose of consolidation, involved installing wordpress there. So, this is your warning order – this site will move off wordpress to my domain as soon as my lazy ass finishes the site. Once that is done, I’m sure I’ll get distracted by something else shiny.

Update 1: The new site is live. I’m not done, but let’s be realistic – I never will be.
Future posts will be at

Update 2: The new site is dead. My hosing provider had this rule, in fine print at the bottom of page 15 of the user agreement, that I had to log into cpanel every month or they would delete the site and domain registration due to “inactivity”. So, I’m back to using this blog instead of the one my now nonexistent site. If my boss ever lets me out from under the rock he has buried me under, I will do some more write ups.

NTFS Fix-Ups

Posted in Uncategorized with tags on September 20, 2011 by christopherltaylor

I was asked what this Fix-up thing was that I mentioned in my last post.

Fix-ups are used by NTFS to keep track of sectors that are part of specific data structures within the file system. This is done for a variety of reasons: detecting corruption from a failed disk sector, from a failed write, or from the moons of Jupiter not being properly aligned. By tagging all of the sectors that make up a specific structure, NTFS can check to ensure that the sector it just read was read correctly and does indeed belong to the structure it is trying to read. This is accomplished by a coordinated effort from two objects: the Update Sequence Number (USN) and the Update Sequence Array (USA).

The Update Sequence Number (USN) is a uint16 (two byte unsigned integer) that is stored in the header of the structure and in the last two bytes of every sector consumed by the structure. When this number is written into those sector ending positions, it overwrites existing bytes that used to be part of information that we probably cared about, such as file names, date/time stamps, etc. We need a way to store and recover that overwritten data, which brings us to the USA.

The Update Sequence Array (USA) is a series of uint16 (two-byte unsigned integer) entries that contain the last two bytes of each sector consumed by the structure. Any time we read a sector that is part of that structure, we must account for the USN. First we check to see if the last two bytes are the same as the USN from the structure’s header, to see if we read the sector correctly and to ensure the sector that we read is part of the structure we meant to read. Once we are happy with that, we throw it away. Next we need to step through the USA to the entry that corresponds to the sector we are reading, and substitute those two bytes for the last two of the sector we just read.

The types of data structures that we typically find USN and USA for are:
– $MFT FILE Records
– INDX Records for directories and other indexes
– $LogFiles RCRD Records
– $LogFile RSTR Records

This can be especially problematic when searching a drive in a forensics-like “look for this file name anywhere on the system” type keyword search. If there is a fix-up in the middle of the file name, the keyword search won’t find it. Most point-n-click forensics tools (EnCase, FTK, etc) will correct the data when displaying in the pretty tables that are part of the tool, but still can’t account for the USN when it is time to do a keyword search. Also, anyone doing manual parsing of file system, for those that have to deal with damaged media or a corrupt file system, needs to understand this concept.

1) MFT Records are 1024-bytes long. So, each record consumes two sectors. In the FILE Record header, there will be a two-byte USN and a four-byte USA. The USN will be found repeated at the end of each sector, so offset 510-511 and 1022-1023. Depending on what attributes make up the FILE record, there could be important information at offsets 510-511 that could be overwritten.

2) INDX Records that make up directories are 4096-bytes long. If there are more entries than can fit in that amount of space, then a second INDX record, for another 4096-bytes, is used. Each INDX Record will have a two-byte USN and an eight-byte USA. Only the allocated part of the INDX will be written to. So, say we have a directory that contains a lot of files, then all but a few get deleted. The actual size of the INDX will shrink, but it will still be allocated in 4K chunks. There will be records in the slack space towards the bottom of that 4K chunk that will reference files that may or may not still exist. The sectors consumed by that slack space will have a different USN saved at their tails.

$I30 INDX Parsing

Posted in Uncategorized with tags , , , , on September 20, 2011 by christopherltaylor

I needed to walk a directory index for another script I was working on. I figured, as long as I was there trying to prototype that, I would just dump out the entire Index.

I already have a couple of scripts that do this. One of the major things I noticed when I started working on this that I hadn’t realized before was that there were a couple of serious problems with those other scripts. Most notably, they weren’t applying the fixups from the Update Sequence Array, which caused random corruption in file names and dates. Forensics is not a field where you want errors in dates, so I thought this a big deal.

Like the MFT parser below, this dumps to the console. Blue check the folder of interest and run. It will operate successfully against multiple checked folders, but the output is kinda long and hard to keep straight, so I don’t recommend it.

Download here

MFT Parsing

Posted in Uncategorized with tags , , , on August 16, 2011 by christopherltaylor

So, I was having lunch with my good friend Mike. Great guy. If you get a chance, take Mike to lunch. Anyway, we were discussing how EnCase doesn’t really give the user easy access to the MFT and there is some information in there that doesn’t get parsed by EnCase that could be useful to an examiner. So, on a bet, I built an EnScript to parse out the MFT record for all selected (blue checked) files. Mike had to pay for lunch and you get an EnScript.

Currently it just dumps info to the console. Next version will output to a series of sweeping bookmarks.

Download here


Get every new post delivered to your Inbox.