You are working as an analyst reviewing suspicious network events at your organization’s Security Operations Center (SOC). Things have been quiet for a while. However, you notice several alerts occur within minutes of each other on 3 separate hosts.

We are given a Screenshot of the alerts, a snort events file , a suricata events file and the .Pcap file of the traffic.

The Affected Host: (In order found in the Pcap)

Client 1:

  Client IP address: (
  Client MAC address: Dell_e2:4b:86 (00:22:19:e2:4b:86)

Client 2:

  Client IP address: (
  Client MAC address: HewlettP_32:a9:17 (00:26:55:32:a9:17)
  Client name: Jennifer-PC

Client 3:
  Client IP address: (
  Client MAC address: AsustekC_c1:f2:48 (48:5b:39:c1:f2:48)
  Host Name: Hokaydoo-PC


If we take a closer look at the alerts screenshot we see boxed in “Red” the events for the IP of and appears to have been redirected to a Exploit Kit page but we are missing what kind from the screen shot.

Boxed in “Purple” we have the events for the IP of and it appears that that is was infected with Crypto wall or Alpha Crypt by means of the Neutrino Exploit kit.

Boxed In “Blue” we have events for the IP of and appears to have downloaded an Evil File, no further information available in the screenshot.

Since we are working with 3 different infected systems lets extract the traffic for those systems to their own Pcap file. For that we will use Tshark which is the command line version of Wireshark.

The command will look like:

tshark -2 -R ip.addr== -r [Full Path \] 2016-01-07-traffic-analysis-exercise.pcap -w [Full Path \] 192-168-122-130.pcap , and remember to use double quotes around the full paths.

Once we get the Individual files we can then search for items not having to filter out the traffic from the other two systems. Note these packets only contain those that are listed “with” the stated IP Address. So those items before it was assigned an IP should not show up.

Side Note: When looking at the timestamps in the TShark generated Pcap files the timestamps were different in the hex editor than the ones in older Wireshark. I stopped long enough on this post to write another post (and a timestamp converter) on the timestamps located Here. I also discovered that they are the same as the Pcapng format saved by the newer version of Wireshark.

Now lets split out the IP’s with the Snort and the Suricata events files also.

If we open each of the events files  using Notepad++ then we can do a search for the IP Address for each of the 3 IP addresses then use the mark tab to mark all of the Instances of the one we are looking for and then copy paste those to a new file and save it, that way we can research each IP separately with the traffic and the events.

Now that we have everything separated we can go thru each systems incident without getting confused by data from the other two.

Lets just start in order found in the original Pcap file.

Client 1:

  Client IP address: (
  Client MAC address: Dell_e2:4b:86 (00:22:19:e2:4b:86)

A quick look thru the log files tells us that files were downloaded to the computer and executed.

The last get request we see for this IP before the infection is to Yahoo mail.


After that we see multiple request GET /Counter ……….

The Suricata Events log supports this with,

Count:1 Event#3.8880 2016-01-07 22:11:26
ETPRO TROJAN Nemucod Downloading Payload

Which tell us that the user opened and infected file from a spam email message.

The first one calls out to (ma-wt.com.sa) but the response resulted in a malformed packet.

Next it called out to (dariostoka.com) where it returned a normal ok but no files downloaded when it was looking for a image file.

Next it calls out to (freshanointingministries-sc.org)

Lets take a closer look at this.


If we take a closer look at this we have a total of 9 request, it calls out to each of the three sites once, increments the counter then calls again. so I would assume that the “rnd” number has something to do with deciding on if a file gets downloaded or not. The first three did not return a file but the last 6 did. Also note the the “id” value in each are exactly the same.

Another interesting thing is if we drop the “id” in to a hex editor we see this.


It appears as though it is identifying this system as being in the US and also appears to have some sort of encoded format for transmitting information.

The  six files downloaded was supposed to be “Media Type: image/gif “ but in fact are are .exe files.


(Frame Numbers) are from the extracted individual IP Pcap files.
(7382) filename=66b32.gif Size: 260613 bytes
Host: ma-wt.com.sa
SHA-1: 4d1c87e219a417c3aa86a6cd6847a82d352a8b4e

(7662) filename=174125.gif Size: 260613 bytes SHA1 Hash:
Host: dariostoka.com
SHA-1: 4d1c87e219a417c3aa86a6cd6847a82d352a8b4e

(7958) filename=c9a63078fe7d3741.gif Size: 260619 bytes SHA1 Hash:
Host: freshanointingministries-sc.org
SHA-1: 9a843ce345c45e1ec8b96df2785336c7d2a48af5

(8079) filename=250acae.gif Size: 114688 bytes SHA1 Hash:
Host: ma-wt.com.sa
SHA-1: d5cd460e184120f154d0017b929ede46b56d49ff

(8223) filename=d50f729942631.gif Size: 114688 bytes
Host: dariostoka.com
SHA-1: d5cd460e184120f154d0017b929ede46b56d49ff

(8451) filename=2487ff63fb4e79.gif Size: 145922 bytes
Host: freshanointingministries-sc.org
SHA-1: e63932430d4028b51fa25dae13d9e0188e9a02a5

the first 3 files are the same from 3 different sites. The 3rd one has a few extra bytes changing the Hash value. The next 2 files from 2 different sites are the same but the last is the odd one (C++) from the third site.

The first 5 are VB 5/6 files the last one is C++ 6.0

Here is the Diff on the second and third files.


Without running these files I can not be sure what they do, I am not finding enough information online about them.

The first 3 have a string table of Language ‘Lithuanian” but decompiles to English. the fourth and fifth file has a Version info with Language of “Chinese Traditional” but decompiles to what appears to be German.

An interesting import to me for the last one is “ SetCommBreak” MSDN Link 

Suspends character transmission for a specified communications device and places the transmission line in a break state until the ClearCommBreak function is called.

I’m not sure yet what it would be used for in this case, or even if it was used, but the Clear command is not listed in the imports that I have  seen, suggesting that communication with a device may have been blocked.

Without running these this as far as I can go with client one.

In collusion follow up with user machine for more details on the infection , and retrain the user not to open the spam emails.


Client IP address: (
Client MAC address: HewlettP_32:a9:17 (00:26:55:32:a9:17)
Client name: Jennifer-PC

The initial alerts shown tells us we are dealing with some kind of “Evil” redirector .

The first part of the traffic tells us the user is doing a Yahoo search for “http://planetside.co. uk /” we find this in packet 1343 in my IP only file or packet 9692 in the original Pcap file. This is the start of the incident, not counting clicking on the link in the search engine.

In order to find the the full chain we need to follow the leads and work backwards to find the beginning of the chain of events .

With as many request as there are and nothing stands out lets try the event logs to see what we can find.

Here is an interesting one in the Snort Events .


Using the highlighted portion of the timestamp from the Snort log we can search in Wireshark for that hit. Once we find that point, then we can “Follow stream” for that packet and we do end up getting a “Packed” script. After unpacking the script we see this.


Looking at this scrip it appears to be a benign script for page navigation. Why they decided to pack this thing who knows.

Following up on several of the alerts in the logs turned out to be false leads and several hits were for packets of encrypted traffic.

In conclusion this appears to be several false positives making it appear that this system was infected. I have not found any actual infections thru the traffic.

I recommend checking the users system to verify.


Client 3:

Client IP address: (
Client MAC address: AsustekC_c1:f2:48 (48:5b:39:c1:f2:48)
Host Name: Hokaydoo-PC

This incident begins with a Google search and a link clicked in the search results for “www.koeppl [dot] com”

This turns out to be the landing page for a Angler EK .


The end of this section of the script looks like this.


After decoding the  “Eval” section of the script we end up with this.


Then yet another layer of encoding , I see in this picture a few of the characters are missing using an earlier version of my decoder. I still have more work to do on this to fully decode/understand this part of the script.

The result of this compromised page though is a redirect to another page to download the malware flash file.

If we set a filter of  “ http.request.full_uri contains top “ we can see most of the remainder of the infection chain.


The Suricata Events Log tells us we are dealing with a Neutrino EK and they say the check-in is crypto wall but the payment page info here says  Alpha Crypt.


The source code of the extracted payment page contains “How to buy CryptoWall decrypter”.

In conclusion this user clicked on a link in Google that that landed them on the Angler EK landing page.

Compromised site: http://www.koeppl.com

Landing page for Angler EK :  uacltr.securetopc.top GET /1993/10/14/madness/willow/dick-sort-southward-swallow.html

Associated request:  uacltr.securetopc.top GET /1987/09/28/behave/cheerful-stumble-broad.html.swf  (Called twice)  gbesbsdsb.securetopc.top GET /surprise/1430317/fellow-touch-death-curl-cast-dance-bubble-moonlight-shock (Resulted in malformed packet) gbesbsdsb.securetopc.top  GET /officer/1277929/tidings-humble-communication  (resulted in possible encrypted file download  (421888 bytes)). 3wzn5p2yiumh7akj.waytopaytosystem.com  GET /1f96s0p Payment page.

In conclusion follow up with system to verify the extent of the damage.

This puppy got hammered.

Posted in Malware, Networking, security | Tagged , | 1 Comment

Wireshark and TShark Timestamps

I am currently working on the latest Malware traffic analysis exercise located here


I used the command line to run TShark  with this command to extract just the packets with the chosen IP Address.

tshark -2 -R ip.addr== -r 2016-01-07-traffic-analysis-exercise.pcap -w 192-168-122-130.pcap

What this command does is it launches tshark , with (-2) two pass analysis , (–R ) read filter of “ip.addr==”, lower case (-r) for read input file ,input pcap file to read, lower case(-w) for write output file, output filename to write.

Note: the “–2” has to be there in the current version or it throws an error and tells you it needs to be in there, and remember to put double quotes around your file paths.

Using this method I was able to extract the the packets just for the IP Address that I wanted to a new pcap file to work on just that IP.

In a couple of previous post Here and Here I showed how we can travel back and forth in between Wireshark and a hex editor using the time stamps.

The problem came in when I tried to look for a converted timestamp from Epoch to to Hex like I have in the other post in the hex editor. I could not find the timestamp for the normal Wireshark converted timestamp but if you open the original Pcap file and the TShark extracted Pcap file in Wireshark and set the IP filter on the original file then they still line up with the date time stamps.

That tells me that it is still using a timestamp but how ?

If we take a packet in the original Pcap and find the exact bytes minus the 8 bytes for the time stamp then open them up in hex editor then we see this.


If we look at the bottom one that is the normal timestamp which converts to the Epoch time of  “ 1452204366.756980 “ and the hex is  “4E E1 8E 56 F4 8C 0B 00 “ in this time stamp the left 4 bytes is the “High Time” and the right 4 bytes is the “Low Time” or the milliseconds of the time.

This other timestamp of “C5 28 05 00 74 FC 6B AD” , and it is a timestamp, as it turns out after looking at it a bit, on this one the right 4bytes are the “High Time” and the left 4 bytes are the “Low Time” or the milliseconds portion of the time. Now this conversion works a little different than the normal type.

We first take this “C5 28 05 00 74 FC 6B AD” and swap the 4 byte sections 74 FC 6B AD C5 28 05 00 next we reverse the entire 8 bytes,  “00 05 28 C5 AD 6B FC 74” then convert to decimal “1452204366756980” , add the decimal point in the 10’th position from the left  “1452204366.756980” and presto we have the Epoch timestamp.

So now I have 2 timestamp converters.


The timestamp from the TShark one reminds me of another one that I worked with a while back but can’t quite place it right now.

One other thing I noticed while looking at the Pcap file that TShark created. In the hex editor we can see a stamp at the top of the file that tells us it was created by TShark, I don’t see that type of stamp in a file created by Wireshark.


Also remember that the Timestamps are at the beginning of each packet in a normal older Pcap file.

Now that I can use the timestamps again back to the exercise.

I hope this helps someone else.

Updated 1/10/2016 :

In my haste to complete this post and get back to the write-up the Malware traffic exercise found here I neglected to investigate the file format of the PcapNG (or Next Generation) file format. In a previous post we found that the original pcap file format found here on the Wireshark development page that the packets started with the timestamp.

That is not so with the PcapNG format. It is written in a block format and the timestamp is not the first item in the block.

Here is a screenshot of the original Pcap layout pulled from the specification page.


The explanation of the PcapNG file format can be found here with a link to the most current version of the format specification. The packets I’m looking at are from the TShark dump of a Pcap file with just traffic for 1 system. This traffic comes from the original downloaded Pcap file from the malware traffic exercise that I completed.

In the PcapNG format there are different blocks that make up the complete file. The very first block of the file will give us information about the file itself  called  “Section Header Block” and is described in section 3.1 of the specification .

One of the items it gives us is the “Byte-Order Magic:”. Magic number, whose value is the hexadecimal number 0x1A2B3C4D. This number can be used to distinguish sections that have been saved on little-endian machines from the ones saved on big-endian machines.

Which brings us to section “3.6.  Data format.” that gives us information about whether it is saved in Big Endian or Little Endian.


Data contained in each section will always be saved according to the
characteristics (little endian / big endian) of the capturing
machine. This refers to all the fields that are saved as numbers and
that span over two or more octets.

There was also a line in an earlier draft that it is possible that data is in the file under both Endianness.

Ok so we have to observe that the byte order can change depending on what machine it was captured on.

Now that that is said lets move onto our packet block. This is a screenshot from the Draft page of the layout for the “Enhanced” Packet block which is what we will be looking at.


Here we see that the length  of the block is in the second and last position of the block. So our block starts with (Depending on Endianness from what I read), looking at it in a hex editor, will either be 0x00000006 or 0x60000000 and ends on  the second length value .

I will be using three packets from the exercise Pcap file and three from the extracted IP version I made using TShark.

Here is the Wireshark view of the Original 3 packets.


And from the extracted IP.


These 3 packets are short and consecutive so make a good compact example for what I am trying to show(how the data is split up).

Here are the frame numbers,timestamps(decimal epoch and hex ), and the file offsets where they can be found if anyone wants to follow along.

Pcap File:

Packet 16355 Epoch Time: 1452204647.545424000 seconds Converted to Hex 67E28E56 90520800  Offset AF4017  (segment)
Packet 16356 Epoch Time: 1452204647.545734000 seconds Converted to Hex 67E28E56 C6530800  offset AF1CA   (segment)
Packet 16357 Epoch Time: 1452204647.546110000 seconds Converted to Hex 67E28E56 3E550800  offset AF4290  (Complete Post request)

Pcap File:
192-168-122-132192-168-122-132.pcap (Tshark / pcapng)

Packet 5436 Epoch Time: 1452204647.545424000 seconds Converted to Hex  C5280500 507A28BE  Offset 33571C  (segment) 
Packet 5437 Epoch Time: 1452204647.545734000 seconds Converted to Hex  C5280500 867B28BE  Offset 3358E0  (Segment)
Packet 5438 Epoch Time: 1452204647.546110000 seconds Converted to Hex  C5280500 FE7C28BE  offset 3359B8  (Complete Post Request)

(It looks better in notepad.)

Here is a look at the Original Pcap file opened up in Wireshark and in a hex editor with the data section highlighted. This section will contain the IP’s ,ports, request type the actual data transported Etc. .


Now lets take a closer look at just the hex.


Now lets take a look at the PcapNG in hex.


As we can see here there is allot more data packed in the new format. this one did not have options in it or that section would have been bigger.

My interest in these at the moment is to have the ability to travel back and forth from Wireshark to a hex editor checking out packets of interest or to investigate possible corrupted packets using the timestamps. Knowing the packet or block layout will be of great help.

Just 1 more thought. If we are dealing with malware in the capture is this packet really a malformed packet or was it intentional ?


I hope you  learned something from reading this as I did trying to write it.

Thank you for reading.

Posted in Networking, security, System Tools | Tagged , , | 1 Comment

A little more on Wireshark and Pcap time stamps

In my last post I talked about getting a unique list of User-Agent strings and as a bonus I discovered that you can travel back and forth from Wireshark to a hex editor and back using the time stamps.

In this post I will attempt to explain the conversion process and show a couple of problems that you may be faced with  while converting.

Lets start with the actual conversion process.

Epoch to Hex:

Epoch (Unix) time stamp. This value is in seconds since January 1, 1970 00:00:00 GMT

A normal timestamp in Wireshark will be like this

Epoch Time: 1451438186.506533000 seconds

To convert this we first split it at the decimal point. like so 1451438186   506533000

Next we take the first part, before the decimal point, 1451438186 and convert it to Hex like this 56 83 30 6A

Next we reverse the “Bytes” of 56 83 30 6A  to  6A 30 83 56 , this part contains the time for seconds, days, month and year.

Next we take the last half  506533000 we cut the length down to 6 , 506533 dropping the last 3 “0” zeros then we convert the remaining Decimal value to Hex like this  7BAA5

If we do not drop those 3 zeros then it converts to 1E311488 which is an incorrect conversion for our time precision used while capturing the packets. See this in the reference for more Information.

7.4.2. Capture file formats

The next step is to left pad this 7BAA5 with zeros to this 0007BAA5, we want it to be 4 bytes.

Next we reverse this Hex value, 00 07 BA A5 to get this A5 BA 07 00, this is the sub second part of the time stamp or Milliseconds in our case.

Finally we end up with a Hex timestamp of  6A308356 A5BA0700.

This Hex time stamp can now be used to search the Pcap file opened up in a hex editor to find the exact packet that the timestamp was pulled from in Wireshark.

Hex to Epoch:

From Hex timestamp in the hex editor we see this 6A308356 A5BA0700.

In this case the first thing we do is split this into two, 4 byte sections.

Take the first one and reverse the bytes, 6A308356 to 5683306A

Next we convert this from hex to decimal, 5683306A to 1451438186 we can use the built in calculator to do this conversion also. This is now the first part before the decimal point.

Next we take the second half  reverse those bytes  A5BA0700 to 0007BAA5.

Next we convert 0007BAA5 to decimal 506533 .

So our final timestamp would be 1451438186[add the decimal point .] 506533

“1451438186.506533” , we can now use this timestamp to search in Wireshark for the exact packet in question from the hex editor.

But say our hex timestamp was like “E1 28 3D 56 AE 6E 00 00”. The first part would convert normally but the second part AE 6E 00 00 reversed to 00006EAE

Then converted to decimal , 00006EAE to 28334 .

Do you see the problem here? I didn’t at first.

This part needs to be 6 Characters long so in order to find this in wire shark we need to pad this with a leading “0” (zero) to be correct 028334.

So our final conversion with be 1446848737.028334 instead of 1446848737.28334 , missing the leading Zero. You would most likely never find that in the current Pcap or it would be the incorrect packet if it you did find that value.

Now that we know how the actual conversion works lets go thru some examples I wrote up for a couple of people that wanted a copy of the tools in the last post.


I will use 4 pcap files downloaded from http://www.malware-traffic-analysis.net/2015/index.html

We can take any pcap file and open it up in Wireshark and get the Epoch time timestamp.

To get that we open the top part of the packet marked   “Frame” ( and a number)

Unless the capture crossed midnight (GMT) or the month or year changed during the capture it should be the same 2 bytes for the whole Pcap file.(I have not tested this theory in full yet.)

Next we convert the Epoch Time stamp to Hex using my time stamp converter


If you need a copy of this please email me at pcsxcetra [at] consolidated [dot] net. “(As with all “free” software this is as is without warranty of any kind. I don’t have a good place to really drop them or download them from.)

There are 8 bytes in the time stamp we take bytes 3,4  for “our bytes to search for”, for “That” .Pcap file.

I will give 4 Examples to help it be more clear.

2015-01-01Nuclear EK (Operation Windigo) from (Main page)

PCAP of the infection traffic: 2015-01-01-Windigo-group-Nuclear-EK-traffic.pcap This is the pcap download

Arrival Time: Dec 31, 2014 19:42:01.338041000 Central Standard Time

Epoch Time: 1420076521.338041000 seconds  Paste this value into the time stamp converter.

E9 A5 A4 54 79280500  This is the resulting conversion in hex.

Take bytes 3 and 4 from the hex timestamp for our bytes to search up for.

A4 54 These are the 2 bytes we need to search “UP” for, in “This” Pcap file.

2015-02-13Magnitude EK – (Main page)

PCAP of the infection traffic: 2015-02-13-Magnitude-EK-traffic.pcap This is the Pcap download.

Arrival Time: Feb 12, 2015 18:49:12.234666000 Central Standard Time

Epoch Time: 1423788552.234666000 seconds

08 4A DD 54 AA940300  This is the resulting conversion in hex.

Take bytes 3 and 4 from the hex timestamp for our bytes to search up for.

DD 54  These are the 2 bytes we need to search “UP” for, in “This” Pcap file.

2015-06-17Angler EK from sends CryptoWall 3.0 (Main page)

PCAP of the traffic: 2015-06-17-Angler-EK-and-CryptoWall-3.0-traffic.pcap  This is the Pcap download

Arrival Time: Jun 17, 2015 11:17:03.663940000 Central Daylight Time

Epoch Time: 1434557823.663940000 seconds

7F 9D 81 55 84210A00  This is the resulting conversion in hex.

Take bytes 3 and 4 from the hex timestamp for our bytes to search up for.

81 55  These are the 2 bytes we need to search “UP” for, in “This” Pcap file.

2015-11-23BizCN gate actor from sends CrytpWall 4.0 (Main page)

2015-11-23-BizCN-gate-actor-Nuclear-EK-sends-CryptoWall-4.0-traffic.pcap  This is the Pcap download

Arrival Time: Nov 22, 2015 18:39:53.898161000 Central Standard Time

Epoch Time: 1448239193.898161000 seconds

59 60 52 56 71B40D00  This is the resulting conversion in hex.

Take bytes 3 and 4 from the hex timestamp for our bytes to search up for.

52 56  These are the 2 bytes we need to search “UP” for, in “This” Pcap file.

Notice how as the months changes  so do the bytes to search for.

I purposely chose files that spanned the year to better demonstrate the change.

I split the first 4 bytes and highlighted the 2 bytes in red  to better see them.

More Examples:

Now lets do this is pictures to better view the process using this last pcap file.

Open this in Wireshark and we navigate to the section showing the timestamps. The first one will do.



From above select the Epoch timestamp –> copy –> Value. That Copies only the value to the clipboard.

Next we Paste to the input box of the converter and click convert.




So here is our converted timestamp “59605256 71B40D00”

Now that we have that what good does it do us? These would be the “bytes to search for” while viewing “This” .pcap file in the hex editor to find the timestamp.

From the last post we were looking at User-Agent Strings in the the pcap file using the hex editor. So just for a starting point I will use this example again.


Say we see something strange like in the red box and using the value from the blue box “0x3B8B” which is the file offset location in the pcap file opened in the hex editor, we do a “Goto” for the hex value from the blue box and land at the location where the String “User-Agent” starts at..


We select the “Goto” and enter the value for the Offset “3B8B” from the other program.



Next we search “UP” for the 2 bytes for the timestamp.(This versions list it as Backward)


Once we find the timestamp for this packet we can extract and convert it to a Epoch time stamp.


Next we search for the timestamp (1448239201.417989 ) in Wireshark.

We select Edit –> Find Packet, then the search box pops up.



Next we select the Radio button “String” , Enter our search term of the timestamp “1448239201.417989” , Select the Radio button “Packet Details” and depending on where we are currently at in the in the capture file select the Radio button “Up” or “Down” to find the packet by the timestamp. If we just start at the beginning of the capture then we can always search down.


Click find, then we see.


This post has shown us how we can navigate easily and confidently back and forth between Wireshark and a hex editor with the same .pcap file open in both using the timestamps.

Note: Open the file in the Hex editor in “Read only mode” or it may block other programs from being able to open it at the same time , it can also help to keep you from accidently overwriting the .pcap file.

You may have Notice in the example I quoted the word “UP” , that is a reminder to search “UP” because the timestamp is the start of each packet otherwise you will be finding the timestamp for the packet in Wireshark after the one you are actually looking for.

Using this method is not not just for User-Agent strings. In a matter of fact I used it in the the Sans Holliday Hack Challenge 2015 to help find and extract the commands from the command and control server that were base64 encoded. Navigating back and forth between Wireshark and the Hex editor was helpful to me to see what I was missing.

I hope everyone learned something from this as I did.

If you have any question please ask.

Thank you for reading.

Posted in Networking, security, System Tools | Tagged , , , | 1 Comment

Wireshark , Pcap files, User-Agent strings and Malware

Recently I have been going thru the malware traffic exercises created by Brad Duncan of “malware-traffic-analysis.net”.

In my last post on a exercise I started wondering about the User-Agent strings used with malware as a way to possibly narrow in on the malware. The malware in the last post put a User-Agent string in the registry in it’s configuration key. I did not run down if that user agent string was used in the traffic or not do to a lack of an easy way to get a list of unique User-Agent strings.

As with a normal web page if the malware calls out to a certain page with a specially crafted User-Agent string it will respond a certain way. If a researcher try’s to look at that same page and uses a different User-Agent string then the page could respond totally different.

Over the last couple of days I’ve been working on a program that would get a list of unique User-Agent strings from a pcap file. Of course as I was writing the program I ended up with “scope creep”, I wanted it to do more that just return a list. It will now either get a full list of all locations where it finds the term “User-Agent” or will by default return just what it determines is a unique list along with the index location in hex where it was found.

What I found surprised me. There were also errors in the frames found.

Here is what it looks like using the latest exercise pcap from malware-traffic-analysis.net.


Note: If this program is run against a pcap file that is open in a hex editor in read/write mode then it will fail to open the file for reading .

This view highlights several of the errors I encountered while making this tool. Probably a good thing I chose “this” file as my test subject, others didn’t return some of the same problems or only returned a few unique User-Agents. This one has known malware in it’s traffic.

The way my program works is it looks for the string “User-Agent” in hex bytes, then it looks for the 2 bytes that the actual string normally ends on “ 0x0D 0x0A “ then it does the math and takes the bytes in between and outputs the U-A string. As you can see in this screen shot some of it was returned in hex, that was because it could not find the end byte and when returned as a string it would not display correctly.  I also had to add a limit of 300 bytes to make sure I got the longest possible string returned without returning over 1,000 bytes in some.

If we convert the hex for the top one showing it as utf-8, here is what we see.


Using the offset of  “0x3E4B59” given in my search tool we can jump to that point in the hex editor and see what was going on there.


From this we see that there appears to be some garbage mixed in with the user agent string, which caused my program to calculate the wrong length so I just output those frames in hex for further investigation.

The next item is those that only return 2 characters, when it hit those my length was calculated as  –2 and threw an error , so what was going on there?


Well the end bytes we are looking for “ 0x0D 0x0A “  are right at the end of the string “User-Agent” and to get the first byte of the actual string I added two to the length of the search string to the two normal end bytes for the string “User-Agent”. So when I subtracted that full length from the end position of the actual User-Agent end bytes I ended up with “-2” so that tells me the User-Agent string is missing here. In order to overcome this and to find what was there if it returned “–2”, instead of returning “-2” for a length I would instead return 2 for the length of bytes to get and to be able to have the index where it is, thus only having  2 Characters.

The next one shows a User-Agent string but with the web address tacked onto it, so the end bytes I was looking for was missing where it should have been. I also had to truncate the last few characters “: */*” from those strings returned because it messed up the string builder that I used in the program and would not display anything after the first one.

So what else can we do with this information ? To be honest I’m not totally sure yet.

But,  the next question is, once you find one of these how could you find the packet that this belongs to in Wireshark?

The answer, after pouring over the file format spec was to use the timestamp.

Each packet/frame has a timestamp in it.

What is the timestamp? It is a Epoch time stamp in GMT but the normal date time is displayed in the users local time. More on this in a bit.

Lets start from the beginning. First we find a interesting UA string we want to investigate so we use the UA tool to find the offset and jump to it in a hex editor.

For this example we will use the first unique U-A string found.

UA = Index Location: 0x1F48
Microsoft NCSI  UA End

It is usually the first one seen when the computer tries to connect to the internet.

So we jump to that location and search “Up” for the 2 bytes “0x54 0x56  that will help us find the timestamp, “BF8C545617920A00”. When the year changes we will have to see what the bytes are.

Update: as December rolled around the bytes to search for  changed to 0x60 0x54.

So if we just open the pcap of interest in Wireshark , pull a epoch timestamp  and convert it to hex as done below then get the last 2 bytes of the first half (bytes 3,4 from left) of the time stamp that will give us the 2 bytes to search up for in the current pcap.


Ok so we found the timestamp, now what do we do with it? Now I build another tool to convert the timestamp from hex to decimal Epoch time. Just copy paste from the hex editor  and we get this.


Next we go to Wireshark  Edit –> Find Packet (Ctl + F) –> In the popup box set the radio buttons to “String” and “Packet Details”  and insert the decimal Epoch string into the search box. Depending on where you are in the capture file you may need to change the search direction up or down.




Here we see we did find the location specified by the timestamp.

While going thru learning about the timestamps here and in the developer readme file in with the source code , we find that the “Arrival Time” is synced with the local time of the computer running Wireshark but the “Epoch Time” is in GMT time as it should be, which is also the timestamp we converted.  There is also something else called a ‘Time Shift” that is used to shift the time to another time zone or modified time, rather than the one that Wireshark is currently running on. According to what I read, most all of the time that should be set to “0” zero or no time shift, but it should be something that you would want to pay attention to if you get the file from someone else.

Next question, can we go the other way with this? The answer is yes. We just take the Epoch time stamp from Wireshark run it thru our handy dandy time converter and get the hex bytes out to search for them in the hex editor.


So now I have a way to navigate back and forth from the hex editor to Wireshark.

So where does the malware part come in at? Well it may be possible if the User-Agent used for known traffic could help narrow it down, out of the many packets of traffic that may be malware. We can also use this information to investigate why a packet didn’t display correctly or was messed up in some way. Other than that I will have to do more research to see what else I can do with this information.

And for those that are curious, just how many times was that string found in the file.

Using another program I wrote that only counts strings it totaled 789 but using my new program that also looks for end bytes it found (after fixing another bug, duplicates).

Here we see it found 785.


Why the difference in the count ? It is because my program is searching for the hex bytes for “User-Agent” and not a string search that is case in-sensitive where it would find both the upper and lower case versions of the string.

Using a case sensitive search for the string ”user-agent” in the hex editor will land us at offset 2E1DAF which we can then look up the time stamp, convert it and find the packet in Wireshark at packet/frame number 4768. We see it is not for the actual U-A string but for.

“Access-Control-Allow-Headers: origin, content-type, accept, authorization, user-agent\r\n”

So we are not finding those with the tools but would be a quick search in the hex editor using case sensitive search with the lower case string.

I hope this information is helpful and useful to those that read it.

If anyone would like a zipped copy of my tools with the file extension mangled so it can hopefully pass thru email filters, email me at pcsxcetra [at] consolidated [dot] net .

Let me know which article the tools are from so I send the right ones.

As with any “Free tools” they are as is with out any warranty and if you find a way to break something with then its your fault.

Posted in Malware, Networking, System Tools | Tagged , | 2 Comments


Although I have went thru a few of these, this will be my first post on them.


The scenario:

During an email  spam mail filter outage an employee opened a malicious E-Mail.

Our mission:

To identify these items pertaining to the incident and to provide any other details.

Date and approximate time of the infection.
The infected computer’s IP address.
The infected computer’s MAC address.
The infected computer’s host name.
Which email the employee opened.


Infection Time: (Frame 85, DNS Query for Name: kennedy.sitoserver.com)
Arrival Time: Nov  6, 2015 16:22:38.340799000 Central Standard Time

Client IP address: (
Client MAC address: Dell_2d:90:81 (00:24:e8:2d:90:81)
Host Name: Strout-PC
Note: if we set a filter of “ bootp.option.hostname “ we can get this info from 1 frame.

Which Employee: arthur.stoyt@turkey-mania.co
Email Opened was: #4 
Dated Friday, November 06, 2015 3:05 PM
With Subject line of “You have received a new fax, document 000497762”

As we look at the traffic if we filter on “dns” then the first thing we see after the system trying to get an IP is this.


As we can see here “kennedy.sitoserver.com” with an IP of 174.121.246 is our first site to show up.

Going thru the emails we find an obfuscated java script in email 4 that was labeled “fax000497762.doc.js” and it looked like this. (if your antivirus doesn’t kill it first)


After spending way to much time de-obfuscating the script by hand  we end up with this.


It calls out to the 3 sites and if it connects then

it will down load a file to to the temp folder and attempt to run it so lets set a filter for the IP and see what all it does. “ ip.addr eq “


That’s still a little to much unneeded info so lets try a new filter

“ ip.addr eq and (http.request or http.response) “

Oh that’s better


Here we can see we narrowed down the traffic to just the get and response traffic for the suspect IP.

This appears to be downloading just gif files but if we look at the data in the display we see this.


This is a dead giveaway that it contains a programs code.

So what are these 3 files we extracted from the traffic.

The first on with a MD5 of “e2fc96114e61288fc413118327c76d93”  shows up on VirusTotal as a Trojan dropper and many other things.

This is the one I done all of my work on.

It is a VB5/6 file that makes it appear that it was from DHL by the info found it in.


The next one with a MD5 of “e2151a8411627ea2a288f2241735d0d0” shows up on VirusTotal as Trojan Generic on most of the list.

When Checked In PeStudio It does not have a Signature for this file what it was created with but the import makes it suspect as a MFC application. Original Name of pattern.exe


The third file with a MD5 of “35a09d67bee10c6aff48826717680c1c” shows up on VirusTotal as another Trojan / Info stealer.

When Checked in PeStudio this one does not have a Signature for the type either but viewing the imports I would assume that it is written in a form of C/C++.

This File Also pretends to be “VMware command line Toolbox”

I did not run the last 2 to see what all they did but the rest of this will be on the First one that was a VB5/6 file. This one appears to account for most of the traffic seen in Pcap

Here is a link to a previous Pcap on VirusTotal about it. It does contain some of the same sites detected in this search.


The VB Malware:

So what does this thing do ?

When run on a VM without the other 2 files running it will will blink and disappear not appearing to be doing anything.

I was not able to fully understand the decompiled code but after running the malware it is more clear.

The Malware creates a key in  “HKEY_CURRENT_USER\Software” I believe the name is as a result of a calculation  because I believe I’ve seen it changes every run.

Sets 2 values then then launches a process under WMI that starts MSHTA with a java script value that reads the value in the key decoding it and then launching Power shell with a environment variable to read another registry key  which then launches regsvr32.exe with the environment variable that is base 64 encoded. Launches another version with the base 64 string environment variable reads a previously created registry key .

Next it queries the Value of the RUN key and finds it is empty.

Next it sets the Value of the New Key

Next It query’s a value in the new key

Next it (regsvr32) locates the original malware file

Next the Original Malware file Deletes the original Registry key and  checks to see it is gone. Then it closes.

Next regsvr32 seem to be looking for Wireshark  and other tools.
(It does this several times)

Next it Query’s the new registry keys again  (It does this several times)

Then it Finally Creates Two Null Named Values in the registry under  The HKCU  Run key  which contain 2 separate Java Scripts.

It also attempts to delete a non existent key of.


Next it creates a new instance of regserver32.exe and reads the keys again.

Finally the First versions close then the original malware is deleted from the location where it was launched from.

This is also looking for a registry key “HKCU\Software\XK72 Ltd  folder” which appears to be another form of traffic monitor tool.

It keep this traffic pattern up over and over again in the Process Monitor Trace.

Sheww that is allot.

We can view the traffic generated live thru Process Explorer it sends a lot ‘ SYN “ packets.

The PowerShell Script

This power shell script that is base 64 decoded and then run appears to be a PowerShell, “Shell Script”, it will inject into several process and do its work. What ever that may be.

This script defiantly needs more research to see how it functions.

As mentioned above it loads 2 scripts from the HKCU  RUN key on boot to persist the infection and work it does.(I’m still not sure exactly what that is.) it will go thru the process of loading the values from it’s “Configuration” registry key launching mshta.exe,powershell, then the most likely injected regserver32.exe with what ever that “Shell Code” was.

Wow this thing is nasty.

Now lets go back and look at some of the traffic it produced.

If we look at the traffic under statistics –> Endpoints –> ipv4 then sort by packets we can see the result of just the “SYN’s sent and the multiple places they were sent to in the short time.

Here we see in Process Explorer some of the traffic in a different run. Do you notice what process it is running under ?



If we set a filter of “ ip.addr == “ whuch is for the Google public DNS server, we can see a repeating pattern with the exception of “Name: pomppondy.net” and a few others. We see that is repeats a search with a transaction ID starting with Hex 0x00000001 to 0x00000028 that is 1 to 40 decimal.

The sites that end in ddns.net are for sites thru noip.org

If we set a Filter for “ dns.flags == 0x8180 “ then we can see all  of the queries where there IP’s associated with them. If we go 1 step further and set a filter for

“ip.addr == and  dns.flags == 0x8180 “ then we can view only the queries that used the Google Public DNS. It still leaves 77 packets that returned valid IP’s.

If we set 1 more filter for “http.request.method == “POST” “ we see only 2 entries.

These 2 send some sort of encrypted or compressed data to the form page.

It has an IP of  “ “ so lets set a filter of  “ ip.addr == “ and see what it is doing.

It appears it is only sending that data and the interesting parts for me is it directly calling the IP address and didn’t look it up. So this may be the phone home call.

There is so much going on here it will make your head spin, and will require more time than would be allowed at a company to research it all.


So now after all of that how do we get rid of this thing.

If we try and open the registry with Regedit we see this

If we try and view this with Regedit we see this error(twice 1 for each value).


If we look at it with Autoruns we see this.


As you can see here both values are displayed in Autoruns as “Default” or no name.

A past try to get rid of this by deleting it with Autoruns didn’t work so well since the malware is injected into the system and most likely protecting the run key.

So the new way is to find the Configuration  key and delete it.


But first we have to kill the regsvr32 processes or the configuration key will automatically be replaced.


Once we delete this key and reboot the first scripts in the run key crashes since it can’t find that data in the configuration key to start the injection process.

I also disabled the network interface to stop it calling out.

If we see this then we know the configuration key stayed deleted.



Just click ‘NO”. and we get this. (twice, once for each script)


Next we fire up Autoruns (as Admin) again but we still can not delete the values with it.


So what do we do from here, By accident I discovered if we jump to the “RUN” key using Autoruns after the same error pops up that that we originally seen. Wow there are 2 values there now even though it says they are not set.


Note: When I tried to delete this key without jumping with Autoruns it would not allow it .

Now just delete the “RUN” key, restart the system  and then we see this.


The system put the real “Run” key back.

And to verify that it is real we turn back on the network card and run the verify command in Process explorer which verifies the file.

VMwaretools verified 

The loaded EXE  is verified, so now a little more searching should verify this nasty thing was cleaned from the VM system.

If you made it this far congratulations and thanks for keep reading.

I’m sure there is more traffic to look at but I’m wore out now.

This actually took several days to research and 1 more day to write up.

If this thing does this much to a system I would hate to see what happens if all 3 of them get launched on 1 system.

I hope others have learned from this as much as I have.

Posted in Malware | Tagged | 1 Comment

Under the hood of the ATI Ace Event Log

Or, Why is the event log maxing out the log with useless user information.

Anyone that has the Catalyst Control Center may have noticed the Ace Event Log.

Mine seems to stay full of errors and if you clear the log it will fill up again with just normal system use and not even opening the Catalyst Control Center to make any changes or to run any test. 

You can find this log by opening up the event viewer and then open the the application and services log and then you will see the Ace Event log.

Lets start with the test system specs.

Microsoft® Windows Vista™ Ultimate
Service Pack 2

AMD Phenom(tm) II X4 945 Processor
AMD64 Family 16 Model 4 Stepping 2    Revision 1026
64 bit Quad Core (Socket AM3) (125 watt)

ASUS M4A79T Deluxe Last available Bios Update(BIOS Date: 03/12/10 10:11:53 Ver: 08.00.15)

XFX HD-489X-ZSFC Radeon HD 4890 1GB 256-bit GDDR5 Pci Express 2.0 x16

Part Number: CM3X2048-1333C9 8GB (4 x 2 gig modules Paired)
Type:DDR3-SDRAM PC3-10700 (667MHz)  –  [DDR3-1333]

DirectX 11

Driver Packaging Version
Catalyst Version    13.1
Provider    Advanced Micro Devices, Inc.
2D Driver Version
2D Driver File Path    /REGISTRY/MACHINE/SYSTEM/ControlSet001/Control/CLASS/{4D36E968-E325-11CE-BFC1-08002BE10318}/0000
Direct3D Version
OpenGL Version
AMD VISION Engine Control Center Version    2012.1116.1515.27190

NOTE: On AMD CPU based systems it is now called “AMD Vision Engine Control Center” and on Intel CPU based systems it it is still called “Catalyst Control Center”


The Control Center is a module based system where the functionality is spread out among multiple modules.

Most of the modules are located in “C:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static” and its sub folders. On my system Explorer says there are 341 files and 38 folder in the directory some folders are just language specific . That’s allot of files to keep track of and update for each new release.

If we take a look using Sysinternals Process Explorer We see that it starts with Mom.exe which in turn launches CCC.exe.


We can also see in the properties that these two are written in .Net clr version 2.0.50727

Using Process Explorer or a program I made to view the loaded modules we see that Mom.exe list 54 modules including, itself, the ATI modules and the .Net and system files required. Looking at CCC.exe it has 229 and over half of those are ATI modules.


Now lets get a look at the Ace Event Log.


One of the first things you notice is there are 731 events and they all have an event ID of “0” zero. Now that’s real helpful.

Another thing you may notice is , by the time stamps that they hit in groups.

So lets dig into a few of these and see if we can see why they are logged.


This is the error returned:
_IDEMDeviceDFP2Settings_0812.GetDFP2ITCFlag failed with status 2

By the function:

In order to dig in and see what is going on here we need to decompile the the modules and follow from module to module to get all of the information.

Here we will use a program called IlSpy which you can find here http://ilspy.net/ .

You can view the code and IL, C#, or VB.Net although some functions crashed the program while trying to view as VB.Net. I ended up staying in C# most of the time.

So how do we find this thing. Lets start by breaking down the function name.


ATI.ACE. = the folder name that the file is in (C:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static) the Core-Static holds the bulk of these modules.

Next look in that folder for the file named ( CLI.Aspect.DeviceDFP.Graphics.Runtime )

Personally I copy the files I’m working with to a separate drive and folder and work with the copies.

Now we open this file with IlSpy and look for the class RT_DeviceDFP and then the function PrivateRefresh . Here is what we see.


The error shown here is not what was returned so lets dig deeper into the get method.

The get method traces down to the

// ATI.ACE.CLI.Aspect.DeviceDFP.Graphics.Runtime.RT_DeviceDFP
private void Parse(bool refreshDeviceInfo)


If we follow the get function we see:

// ATI.ACE.DEM.Graphics.IDEMDeviceDFP2Settings_0812
int GetDFP2ITCFlag(int demAdapterIndex, int displayIndex, ref bool itcFlagSupport, ref int itcFlag, ref int itcFlagDefault);

So it takes the parameters as input and somehow returns an integer value, perhaps it is adding the values or counting the ones that are not “0” zero. Without stepping thru this in a debugger it is difficult to know what the values are for the index’s.

The result was 2 in the error.

Looking at the code unless the index values are “0” zero then it will always throw this error because the other values are set to “0”, Boolean False = “0” .

This took almost a full day to sift thru the code and follow it thru multiple modules.

Next lets try an easier one (hopefully).



This one appears to be trying to subscribe to the registry key change event.

Looking thru the code on this one there are several problems with it.


First of all the path returned in the error, “HKCU;Software\wow6432node\ATI\ACE\Settings\AEM” does not exist on this system, this alone will cause it to fail every time.

For what ever reason they are using “;” instead of “\” in the output of the error message, perhaps to use a split Char later.  Also subscribe is misspelled in the error message.  (oops).

This function calls to the Windows API to open the registry key and does not appear to be checking for fails from those calls.

Those long numbers convert to the values of the default registry keys.



At this point I’m not sure where the sub key name came from so this is as far as I can go with this one.

Doing a string search it may be coming from:
C:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static\CLIStart.exe

CLIStart.exe is a 32 bit unmanaged application so may be getting messed up with registry virtualization on a 64 bit system.


Lets try one more and we will call it a day.



This is the easiest one of all the file “ CLI.AIB.TutorialInfoCentre.Tutorial.Dashboard” just plain does not exist on this system. Thus the error that it can not be loaded.

I was not able to track down what tried to launch it to start with.


In conclusion this code base is so large and complicated that it is riddled with errors and it is also possible that due to the size of the code base and the registry keys that a previous version was not completely uninstalled and merged with the new version and is causing the problems. It would take a very long time to even attempt to track down the source of all of these errors.

If you don’t need the AMD/ATI user interface for overclocking  you could always uninstall it and just use the video drivers without the Catalyst Control Center.

I may test that next, after a normal uninstall and reboot see what is left and then cleaning all of the extra files and registry keys off the system .

That’s all for now I hope I was able to pass on some information oh how to dig into these although it can be difficult solve without being able to see the values in a debugger to solve some of them. There is a good chance you can not solve these without upgrading to a new version.

This version I’m using is already listed as legacy product. and it appears that there is another newer update since I last checked.


After uninstalling the old version, MSI crash and several reboots later and clearing the log file , there were still several files in the  windows\system32 folder.

Upon installing the new version with in and hour there were already over 230 new entry’s.

Go figure.

Posted in RootAdmin | Tagged | 2 Comments


Rootkits have become the most devious method of hiding malware on a system.

They are being employed to every sector from the home user to government to private industry.The monetary and information losses along with infrastructure disruption will continue to rise unless some way is developed to stop them.

What is a Rootkit ?

According to Wikipedia.

“A rootkit is a stealthy type of software, typically malicious, designed to hide the existence of certain processes or programs from normal methods of detection and enable continued privileged access to a computer.”

How do we stop them?

To stop them we have to understand how they work.

They, depending on how sophisticated they are can install a Windows service, Windows user mode driver, or a Windows kernel mode driver. They can also Infect the boot sector of a disk(boot kit), they can also create a hidden partition or volume to hide there files or even encrypt files so they are not easily identified about what they contain. They can also create task , either normal or WMI task to start at a given time or as a result to some action.I almost forgot about alternate data streams.

The basic idea is to install the driver or service so it can “Hide” itself and the other files registry keys and processes it needs to operate.

How it does this is by intercepting calls to list files or registry setting or process info or even disk info and can therefore remove from the results a predetermined set of files or registry or process entries  effectively hiding there existence so no one knows they are there by using normal means.

How do you find them?

They can be very difficult to find, again depending on how sophisticated they are.

First off you need to understand like in network analysis what is “Normal”  for a system.

The first step would be to determine if there is a process(s) running that do not conform to “Normal”, like multiple system process that should only have 1 copy of itself running, then you could check to see if there are items set to auto start on reboot that do not conform to “Normal” or any extra task that may have been added or network traffic to places it shouldn’t be going, also there are tools to check for encrypted files on the system.

Given what we know of the capability’s of these bad boys we can not be certain a system is “Clean” just because the system looks “Normal”. It could have these “Cloaking” drivers/ services running in the background.

The next step would start to delve into the world of computer forensics, where you would take a system off line and scan it for the traits previously mentioned, registry keys that shouldn’t be there, files that used to be hidden are now there or encrypted files where none should be, partitions that were not previously showing up thru the normal methods.

All of these and more could be a sign of some form of infection.(Or DRM Software)

I have been looking into service security and other information involved with them for over a year.

After reading several reverse engineering papers on different Rootkits and other malware one thing became clear and I developed a theory(educated guess).

The theory is a simple one . The implementation of it is not.

To the best of my knowledge every service or driver “Has” to “Register” with the system before it can do was it was intended to do. Whether or not it drops a file to disk or loads its code into memory and never touches the disk.

This is where I believe the weak point is.

The “Theory” is to have a service or driver “Listen” for services and  drivers being “Registered” with the system and, either scan it or at the very least log it and possibly send a administrator alert before it has a chance to infect a system and hide itself. The location of the log file would need to be well protected to keep anyone from removing it or changing its contents and thus continue to hide itself. Although the missing file itself would be a red flag that that system would need to be investigated further.If the file was changed or edited then it might prove difficult to verify what got changed in it and  thus back to the possible need to send an alert out also.

This way there will be a trail of what and when they got “Registered” with the system and possibly make the detection and removal faster. If it was somehow incorporated in a antivirus solution it may be even better as they already have a driver on the system.

The down side is if the system is already infected anything before that point would not be logged and any future ones may get filtered out by the Virus/Rootkit. You could also make a list of drivers not to be logged in order to keep down the log size but that would need to be protect also.

So far this is still a “Theory”, I still need to create a proof of concept program and build my malware lab to test against this “Theory” looking for any holes in it.

There are at least a few ways I can think of doing this and they start from the hard way to the very difficult as there seems to be no built in way to do this.

Lets see a little demonstration on how difficult it can be just to find a driver under normal conditions without being infected (that I know of ).

Have you ever wondered how Sysinternals Process Explorer works ?

In its most basic sense it just installs a device driver and listens for system calls and events and can report them back to the user application, Process Explorer, such as  process start or process end and information about each individual process and it’s threads and can give you a stack trace also for that moment in time and much more.

The question is how do you find this process or driver that it is using?

The driver does not show up in the MMC Services or in Device manager.

When using Process Monitor to view the launch of Process Explorer the driver name does not show up if it has already been launched once, it is still loaded into memory. Upon reboot run Process Monitor then run Process Explorer and then you can see the driver dropped to disk, loaded to memory then delete the file on disk.

On a 64 bit system Process Explorer starts the 32 bit version then extracts the 64 bit version to a temp folder then starts it and then extracts the driver to the system drivers folder to be loaded to memory before being deleted from disk.

So again how do we figure out what driver it is using. The easiest way it to also use the lower pane option of Process Explorer. If on a 64 bit system select the process “procexp64”  and select the view handles option on the toolbar.

Next sort by type then scroll down to the type “File” then look for an entry that starts with “\Device\drivername”.

In this case it is easy to spot. We are looking for “Device\PROCEXP 152” used with version 15.42 at least of Process Explorer.

Ok so how else can we find out what this driver name is.

If it is a normal driver install you can look into 2 places for the physical file.

“C:\Windows\System32\drivers” or if it is a 64 bit system “C:\Windows\SysWOW64\drivers” or one of the sub directory located in those folders but it could be dropped anywhere on the system, in the program files folder, in a temp folder, anywhere it may have read/write or read/execute access.

During my investigations I have created several tools to help with getting information more easily out of the registry and a system.

When a service or driver is registered it gets registered in the system registry under the keys:
“HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services” and

The same name could possibly be loaded into both keys depending on the type of driver it is.

Lets start with what you see as the system normally shows you. The places that give information on installed services  are thru the MMC utility “Services” Which on my system shows 173 services(counting by hand). Using a program that utilizes the Service Process class also return 173 services, using WMI also returns the same number.

Then for the drivers you have Device Manager you also need to select the show hidden devices to show the Non Plug and play devices or “Legacy Devices’.

Viewing it this way in Device Manager is difficult to get a count on how many are there but what I want to relay is that using WMI Win32_SystemDriver only returns a list of 248 found on my system, but using the service process class again and selecting the type of driver instead of service it returns a list of 271 a difference of 23. I have created a new program to find the difference in what is missing. I can only assume that they are not listed thru WMI  because there is no physical file on disk for them (so far that I have found). Perhaps they are the ones that were uninstalled. I still have to track down each one and see what they do then build a database to log the information in.

Also the Process Explorer driver did not show up in either my regular tools or Device Manager to  reveal the name of the driver

Using this tool though:


Here we see that there were in fact three different versions of this driver registered with the system. All this tool does is enumerate the registry key. I have made it to be able to enumerate any control set numbers that it finds to check for any possible differences.

While writing this I had CurrentControlSet, Controlset001 and Controlset002. When I enumerated them the count was “1” different between CurrentControlSet, Controlset001 and Controlset002(diff). Viewing the list of both side by side I could not see the  difference so I saved a copy of the list for each and then rebooted into another OS partition loaded the registry key for this partition and then dumped it just in case something was hidden. Using my new List Diff tool with the first 2 list I saved before the reboot I was able to track the difference to a driver that I recently uninstalled .

Upon rebooting into this OS I then discovered there was no longer a ControlSet002 listed, instead there was a ControlSet003 and no ControlSet002 most likely because I did the uninstall and the list changed.

After a small test searching the system for files by name, the names that appears here in the list seems to be the actual name of the driver without the “LEGACY_” tacked on to the beginning.

Another tool I found while researching this, called DevManView from NirSoft, can get the same information from the registry once you enable the show non plug and play devices under the options tab.

I also tested if a Administrator could delete one of the entries. The current Security settings does not allow a “User” to change the security, take ownership or delete the key.

So in conclusion the best I can tell once a service or driver is installed on a system then it will stay on this list unless advanced methods are used to remove it or it gets uninstalled/unregistered and then system is rebooted. As long as the results of the enumeration are not filtered it should give a good history of what was loaded on the system and not uninstalled.

I am adding a link to my SkyDrive where I will have a zip files containing several tools the file name is BlogTools.zip. It will also have a readme file with the files names,description, and a how to use, most are pretty self explanatory on how to use.

Once this post gets consumed by the “RootAdmin” site I will try and add them there also.

I look forward to any comments or feedback.

Posted in RootAdmin | Tagged