Journey Into Incident Response

Jesse Kornblum’s paper “Exploiting the Rootkit Paradox with Windows Memory Analysis” explains the predicament Rootkits find themselves in. The predicament is:

        1. They want to remain hidden.

        2. They need to run.

Jesse’s paper goes into detail about this paradox so I won’t. The main point is Rootkits want to remain hidden on a system but they need to run on an operating system. If an operating system can find the Rootkit then so can an examiner. The paradox applies to all kinds of malware from data stealers to remote access Trojans to droppers.

I’ve been thinking about the Rootkit Paradox and there is another aspect to it that is important for examiners to understand. The second predicament is:

        1. They need to run.

        2. They want to remain hidden

In this case the “they” in the need to run is a piece of malware while the “they” in the want to remain hidden are Rootkits. Basically, a program needs to run in order to hide a Rootkit on a system. The program could be the Rootkit itself or a different piece of malware such as a dropper or installer. When a program runs on the system it creates artifacts showing it executed. An examiner could then look at those artifacts along with changes made to the file system (files/folders creations and modifications) to determine where the Rootkit or its components are hiding. Again this predicament applies to all kinds of malware.

The Rootkit Paradox is alive and well, and can be leveraged to find malware hiding on a system.

This is an open letter to a person I will never get to meet. We will never exchange greetings nor will I ever know their name or identity. I had to settle for an open letter since I’m unable to give them a proper thank you. Please don’t misunderstand my attempt at thanking them since I’m truly sincere. This is not an attempt at humor nor is it an attempt to condescend them. This is my thank you; thanking them for infecting my system so many years ago.


To Whom It May Concern,

As the holidays are approaching it’s a time of reflection. I’ve been reflecting on my “Journey into Incident Response.” There have been numerous people who helped me along the way; people who influenced me and helped make me into the Digital Forensic and Incident Response (DFIR) practitioner I am today. Reflecting on all these people I can’t help but think how you impacted my journey. You may not even be aware of the impact you had on me, but your actions are what opened my eyes to a whole new world and made me take the first step of my journey.

At the time I was in a position doing two different responsibilities. I was performing vulnerability assessments against organizations, testing networks to find vulnerabilities. At other times I was performing digital forensic examinations to determine if someone was committing fraud. I saw my two responsibilities as separate; as duties that didn’t blend together. My perspective changed when I saw your handy work appear on my computer, which was a rogue security program holding my computer hostage. That one single event is what started me on my journey; my journey of leveraging my offensive security background to improve my DFIR knowledge and skills when investigating security incidents.

I never attempted malware forensics before this, but I wanted to know if I could figure out how you were able to install your malware on my box. I successfully traced your malware to a PDF targeting an Adobe Reader vulnerability that was delivered through a malicious advertisement served up by Yahoo’s website. Some may say it was luck, but I beg to differ. I knew that in order to get a remote code execution, an exploit had to be used. The answer was clear as day once I found the PDF that was created on the system around the same time as the malware.

I know I was not even a blip on the radar screen; maybe just an IP address showing a successful install. You opened my eyes to a whole new area; an area where the offensive side of security meets the investigative side. Where knowing how to attack systems is as beneficial as knowing what artifacts are created by those attacks. How this combination of skills and knowledge can be used to obtain intelligence to help better secure organizations and people. I know I would have come to this conclusion eventually, but your actions helped me see it sooner rather than later.

My passion for information security, my motivation to learn, and my drive to share my knowledge with others took care of the rest. Little did you know you were awakening a sleeping giant. I don’t consider myself a giant but it’s the only words that come to mind when looking at the aftermath of the infection. I dedicated myself to learning and researching how to investigate security incidents. Eventually it evolved into me using my knowledge and skills to help others investigate security incidents. I started my blog as one avenue to share what I have learned. I try to help my colleagues become better DFIR investigators through presentations and sharing my thoughts. I use my skills to help home users become better equipped to secure their computers through education about what holes to close after I remove malware from their systems. I help organizations by providing them with intelligence to improve their security by analyzing the systems impacted by attacks. I am developing a graduate course to help strengthen the ranks of DFIR practitioners capable of investigating malware incidents. I’m even considering authoring a book to reach a larger audience about malware forensics. I truly wanted to show the chain of events to illustrate why it’s as if a sleeping giant was disturbed.

I bet you have never heard a user you infected say thank. I will be the first; the first to say thank you for infecting my system so many years ago. Thank you for opening my eyes to a whole new world, sooner rather than later. Thank you for showing me the first step I needed to take to become your adversary.

Almost every “CSI” episode begins the same way. An attack took someone’s life, first responders secured the crime scene, and then the main characters show up to start processing a well preserved scene. The technological equivalent of this is the following: an attack compromises a system, first responders image the system’s memory before immediately powering the system down, and then a forensicator shows up to process the scene. This is an ideal situation but life is not always ideal. Actions taken by users and first responders do not always leave a well preserved scene. Anti-virus scans are ran, files are deleted, temporary folders are emptied, programs are installed/removed, system restore points/volume shadow copies are deleted, or the system is left running resulting in data being altered. Only after all these actions is the forensicator consulted and asked to figure out how the compromise occurred. Needless to say conducting the analysis is more difficult and time consuming but it is not impossible. There still may be artifacts left on the system providing clues to what happened.

In order to demonstrate this, I setup a simulation where I purposely infected a Windows XP system and then I mimicked actions someone would take to remove the infection. Afterwards I examined the system to see what artifacts I could find. I wanted to simulate a real life scenario so I performed the following common troubleshooting techniques administrators do when trying to “clean” a system and get it back into working order as quickly as possible.

        • McAfee antivirus scans were conducted and any detections were cleaned
        • All temporary folders’ contents were deleted
        • All prefetch files were deleted
        • All recycle bins were emptied
        • All system restore points were deleted
        • Avast! was installed and a scan was conducted

The actions may be common troubleshooting techniques but I picked them for a different reason. All of those actions potentially destroy vital information that could help determine how an infection occurred. Antivirus software deleting malware not only removes the suspicious files from the system but it also destroys their filesystem metadata. This metadata can narrow down the timeframe to when the infection occurred. Deleting the files in the Windows\Prefetch folder makes it harder to determine what programs executed on the system. Deleting files in the Windows temporary, user profiles’ temporary, and Internet browser folders removes any secondary artifacts –such as exploit artifacts – that can provide additional information about an event. Emptying the recycle bin ensures the files are actually deleted from the system. Windows System Restore Points are an interesting artifact because they contain backup copies of registry hives and Windows system files. Deleting the System Restore Points destroys the historical information they contain. Lastly, installing and running additional anti-virus software makes more changes to the system and potentially alters or deletes information beneficial to an analysis.

Potential Artifacts

The common troubleshooting techniques destroyed some of the information I look for when faced with a malware infected system. Despite those actions there is still data left on a system providing clues about how the infection occurred. Based on the actions taken, four potential areas containing information are:

        1. Host Based Logs
        2. NTFS Artifact
        3. Registry Artifacts
        4. System Timeline

Host Based Logs

Antivirus software typically records installation and other system activities in text logs. The location of these text log files is specific to each antivirus product. One method used to identify the installed antivirus products is the Uninstall Registry key in the Software hive[1]. Afterwards, Google searches on the products can show the where the folders containing logs are located. I reviewed the Uninstall Registry key on the infected system using RegRipper and found the following:

Sun Apr 8 04:49:07 2012 (EDT)
      avast! Free Antivirus v.7.0.1426.0

Sat Apr 7 10:52:52 2012 (EDT)
      McAfee VirusScan Enterprise v.8.6.0

The above information showed there were two installed antivirus products; they were McAfee antivirus and Avast!. The Google searches I performed showed me where both products store their logs on a Windows XP system. In addition to these logs, antivirus products activity may also be recorded in the Windows events logs. I examined both the antivirus and Windows events logs looking for any information about the infection.

The McAfee logs are located in the DesktopProtection folder located under “Documents and Settings\All Users\Application Data\McAfee\”[2]. Two specific logs of interest were the OnAccessScanLog and OnDemandScanLog. The OnAccessScanLog log records information regarding McAfee continuously monitoring a system. The second log – OnDemandScanLog – records information regarding scans conducted against a system. The OnAccessScanLog did not contain any entries for the malware. However, the OnDemandScanLog contained entries outlining what had been deleted, cleaned, or quarantined by McAfee. Below were some entries found:

• 4/8/2012 4:06:46 PM (EDT) Deleted corey C:\SYSTEM VOLUME INFORMATION\_RESTORE{3F806DB1-464B-46B0-B724-4376EC868222}\RP6\A0003833.EXE BackDoor-AMQ(Trojan)

• 4/8/2012 4:06:46 PM (EDT) Deleted corey C:\SYSTEM VOLUME INFORMATION\_RESTORE{3F806DB1-464B-46B0-B724-4376EC868222}\RP6\A0003834.COM BackDoor-AMQ(Trojan)

• 4/8/2012 4:06:49 PM (EDT) Deleted corey C:\WINDOWS\SVCHOST.EXE BackDoor-AMQ(Trojan)

• 4/8/2012 4:06:50 PM (EDT) Deleted corey C:\WINDOWS\MSAGENT\MSQGIX.COM BackDoor-AMQ(Trojan)

• 4/8/2012 4:06:50 PM (EDT) Deleted corey C:\WINDOWS\SYSTEM32\MSMHXY.COM BackDoor-AMQ(Trojan)

The Windows Application Event log - AppEvent.Evt – collaborated the information in the OnDemandScanLog log. There were numerous Event IDs 258 showing McAfee deleted numerous files detected as BackDoor-AMQ (Trojan) on 4/8/2012 4:06:50 PM (EDT). The OnDemandScanLog and Windows Application Event logs revealed that the “corey” user account conducted a McAfee On-demand scan around 4/8/12 4:06 PM (EDT). The scan deleted the files svchost.exe, msqgix.com, and msmhxy.com from different locations in the Windows folder while files with the same extensions were deleted from a System Restore Point. The last piece of information indicated that McAfee detected the files as the BackDoor-AMQ Trojan. I searched McAfee’s website for additional information about BackDoor-AMQ[3] but it wasn’t useful without having access to the actual malware or their hashes.

I proceeded to examine the Avast! logs located in the Log folder under “Documents and Settings\All Users\Application Data\AVAST Software\Avast”. I was looking at the names of the files in the folder when I noticed one named Setup.log. The Setup.log shows the information related to installation of Avast! and the log’s first entry stated “Started: 08.04.2012, 16:46:02”. Later on in the Setup.log I found an entry showing Avast! antivirus was installed at 4/08/12 4:49:06 PM (EDT). I wanted to correlate the information with the Windows event log. The System Event log - SysEvent.Evt – Event ID 7035 showed at 4/08/12 4:48 PM (EDT) the Windows installer started. The first entries for the Avast! in the System Event log occurred one minute later (4:49 PM (EDT)) when numerous Avast! services were started (Event IDs 7035). Something I found interesting was that the Avast! services were started under the context of the local administrator user account.

I continued looking at the other Avast! text log files in the folder and noticed that the logs starting with asw were the ones containing the results of any scans conducted against the system. The Avast! logs did not contain any entries related to files being deleted, cleaned, or quarantined on the test system.

The examination of the host based logs provided some indicators about what occurred on the system. There were numerous suspicious files (svchost.exe, msqgix.com, and msmhxy.com) located within the Windows folder. These files were detected as BackDoor-AMQ Trojans followed by being deleted when the “corey” user account conducted a McAfee antivirus scan. I knew my best bet at finding artifacts showing how the system was infected was to identify when those files first appeared or executed on the system. I turned my attention to the NTFS artifacts to see what information was available.

NTFS Artifact

When antivirus products delete or quarantine files the filesystem may still maintain metadata about those files. One piece of information that can be pulled from this metadata is timestamps; this can be valuable to the analyst, as it helps identify the timeframe of when the system first became infected. One NTFS artifact[4] that may shed light about an infection after a system is cleaned is INDX files.

INDX files contain records for each file within a directory. Each record contains information about the file including: filename, file size, and timestamps[5]. The records in INDX files may remain after files are deleted from a system[6]. This behavior makes INDX files an excellent artifact to provide information about files deleted from the system in attempts to remove malware. An analyst can use Willi Ballenthin’s INDXParse python script to parse these artifacts. On the test system the McAfee antivirus logs indicated the following files were deleted:

        • A0003833.EXE and A0003834.COM from RP6 (System Restore Point)
        • SVCHOST.EXE from the C:\Windows folder
        • MSMHXY.COM from the C:\Windows\System32 folder
        • MSQGIX.COM from the C:\Windows\MSAGENT folder

I was interested to see if either the Windows, System32, or Msagent folders’ INDX files contained any timestamps for the svchost.exe, msmhxy.com, and msqgix.com files. I examined the Windows and System32 folders’ INDX files but it didn’t provide any information about the timestamps I was looking for. However, the Msagent folder’s INDX file contained timestamps for the msqgix.com file.

        • Filename: msqgix.com (slack at 0x5c0)
        • Modified Time: 2012-04-08 4:06:50.390625 PM (EDT)
        • Accessed Time: 2012-04-08 4:06:50.328125 PM (EDT)
        • Changed Time: 2012-04-08 4:06:50.390625 PM (EDT)
        • Created Time: 2004-08-04 12:00:00

Correlating the above timestamps to the information I learned from examining the host based logs shows the timestamps are around the time when McAfee deleted the file. I also checked the Prefetch folder’s INDX file hoping to find information about program execution but it did not provide any useful information about the attack. This time around the INDX files did not provide any new information about how the attack occurred but it is an NTFS artifact to keep in mind with respect to files that may have been deleted.

I still needed to identify the timeframe of when the infection occurred since I didn’t get the information from the host based logs and INDX files. I know when malware executes it may change system configuration settings in the Registry which is where I looked next.

Registry Artifacts

When an administrator takes actions to remove malware from a system not only are important files deleted but many times, those files’ metadata is lost as well. Not having access to the metadata makes it tougher to identify the timeframe of when the system was initially infected. However, if the malware makes changes to the Registry then the Last Write times associated with modified registry keys modify can help fill in some of these gaps. Different methods can be used to locate the information stored in the Registry, from checking common keys used by malware to performing keyword searches. The McAfee log file provided names of three files of interest that were used in a keyword search. The following list provides the results of these searches.

1. C:\Windows\SVCHOST.EXE Search Hit 1
     a. Last Write Time: 2012/04/08 3:06:31 PM (EDT)
     b. Key: HKLM\System\ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\AuthorizedApplications\List
     c. Data: C:\Windows\svchost.exe


2. C:\Windows\System32\MSMHXY.COM Search Hit 1
     a. Last Write Time: 2012/04/08 3:06:33 PM (EDT)
     b. Key: HKLM\Software\Microsoft\Active Setup\Installed Components\{42CE4021-DE03-E3CC-EA32-40BB12E6015D}
     c. Name: Stubpath
     d. Data: C:\Windows\System32\MSMHXY.COM


3. C:\Windows\MSAGENT\MSQGIX.COM Search Hit 1
     a. Last Write Time: 2012/04/08 3:06:33 PM (EDT)
     b. Key: HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
     c. Name: COM Service
     d. Data: C:\Windows\MSAGENT\MSQGIX.COM


4. C:\Windows\MSAGENT\MSQGIX.COM Search Hit 2
     a. Last Write Time: 2012/04/08 3:06:33 PM (EDT)
     b. Key: HCU\ntuser-corey\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
     c. Name: COM Service
     d. Data: C:\Windows\MSAGENT\MSQGIX.COM

I found the Registry keyword searches enlighten because it showed the changes the malware made when it executed. The earliest timestamp - 2012/04/08 3:06:31 PM (EDT) – is when the firewall configuration was changed to make the svchost.exe file an authorized application. The search hits also identified how the malware remains persistent; the msqgix.com file was added to the Run key in the Software and "corey" user account hives. In the past, I’ve seen when malware infects a system it adds a persistence mechanisms to both the logged on user account NTUSER.DAT and to either the System or Software hives. It appears the malware did this by adding entries to two different Run keys. I thought the “corey” user account was not only involved with running the McAfee antivirus scan but might have been logged on when the infection occurred. Lastly, all the Registry keys Last Write times were 04/08/2012 3:06 PM (EDT) and this provided me with the first indicator to when the infection may have occurred.

I wanted to see if any programs were run by the “corey” user account around the 3:06 PM (EDT). I ran RegRipper with the userassist plug-in against the “corey” user account’s NTUSER.DAT hive which showed the following activity (I adjusted the time from Coordinated Universal Time to Eastern Daylight Time).

Sun Apr 8 3:06:21 2012 PM (EDT)
     UEME_RUNPATH:\\XP-SP3-SHARES\Main_Share\Software\npp.6.0.0.Installer.exe (1)

The Userassist registry key[7] showed that the “corey” user account ran a program called “npp.6.0.0.Installer.exe” at 4/08/12 3:06:21 PM (EDT) from the “Main_Share” network share. 10 seconds later the svchost.exe file was added to the firewalls authorized applications list which was immediately followed by persistence mechanisms being set for the msqgix.com file. I identified the timeframe of interest as 4/08/12 3:06 PM (EDT). Next I needed to see what other activity was occurring on the system so I decided to create a timeline.

System Timeline

System timelines can provide a good deal of context about data found on a system. Timelines can reveal what other activity was occurring on the system around the time when an event (i.e. malware infection) occurred on the system. This other activity can help answer questions with respect to “how did the compromise happen?” This type of question can still be answered even if someone took actions to clean the system and in the process destroyed the best artifacts available. The registry artifacts provided indications that the “corey” user account might have been responsible for the malware infection. As a result, I wanted my timeline to include the Last Write times of every Registry key in the “corey” user account NTUSER.DAT hive to help see what the account was doing and what changes the malware made to the hive. The only other timeline information I wanted initially was the filesystem metadata since it shows activity on the system. My timeline consisting of just filesystem metadata and the “corey” NTUSER.DAT Registry hive metadata showed the following activity occurring around 4/08/2012 3:06 PM (EDT). The table below illustrates some entries from the timeline.


The timeline revealed a great deal of information about the activity on the system around the time the Registry was modified to include references to the malware. Specifically, the “corey” user account accessed a network share named Main_Share on the XP-SP3-Shares computer followed by executing a program named “npp.6.0.0.Installer.exe”.

How the Compromise Occurred

The information I obtained from the host based logs, Windows Registry, and a system timeline was enough to determine how the how the infection occurred.

The “corey” user account launched a program named "npp.6.0.0.Installer.exe" from the Main_Share on the computer XP-SP3-Shares. Within 15 seconds there were multiple indicators in the Registry showing when malware first executed on the system. Those indicators involved three files names (svchost.exe, msqgix.com, and msmhxy.com) that were eventually detected by McAfee antivirus as BackDoor-AMQ (Trojan) prior to being deleted.

The information I obtained from the artifacts left on the system confirmed how I purposely infected the system. I Trojanized a Notepad ++ installer[8] which drops malware when executed[9].

Summary

There are some instances when the “CSI” main characters show up to a crime scene that appears to be spotless. There is no victim, blood spatter, knocked over furniture, or anything else to indicate a crime took place. What happened was someone cleaned the crime scene before the characters arrived. When faced with a clean crime scene they do not throw their hands up in the air and say the cleaning prevents them from investigating what happened. Instead they search the scene looking for clues the cleaning might have missed. Areas get sprayed with Fluorescein and then a UV light reveals where blood existed, cracks in objects are checked for blood, or the drains in showers are checked for any evidence. Digital forensics is no different; when a “cleaned” system is encountered then the examination needs to find any information in the artifacts left on a system.

Sometimes there might not be the original malware samples, their metadata, Prefetch files, temporary files, or historical information. It is still incumbent upon us to find any remaining artifacts whether they are host based log files, NTFS artifacts, registry artifacts, or timelines. There are even additional remaining artifacts I didn’t discuss such as ones showing program execution and file access. The Registry contains more information about program execution including the MUICache[10] and the Shim Cache[11] Registry keys. There are artifacts showing what folders and files were accessed by a user account including: Shellbags Registry keys[12], Windows LNK files[13], or Internet Explorer browser history.

The common troubleshooting techniques administrators do when trying to "clean" a system and get it back in working order makes it more challenging for us to perform our analysis. What artifacts the administrators destroy will be different from system to system. However, it’s up to us to find what articles remain and how they can be pieced together to explain what happened.

References

1. The full path to the registry key is HKLM\Software\ Microsoft\Windows\CurrentVersion\Uninstall

2. McAfee outlines the log file locations in their knowledge base https://kc.mcafee.com/corporate/index?page=content&id=KB51377

3. McAfee write-up for BackDoor-AMQ http://vil.nai.com/vil/content/v_100037.htm

4. Refer to Brian Carrier’s File System Forensic Analysis book for additional information about NTFS and the artifacts available

5. Willi Ballenthin INDXParse script webpage discussing the INDX artifact http://www.williballenthin.com/forensics/indx/index.html

6. Chad Tilbury wrote an excellent article discussing this behavior http://computer-forensics.sans.org/blog/2011/09/20/ntfs-i30-index-attributes-evidence-of-deleted-and-overwritten-files

7. For additional information about the Userassist Registry key see http://forensicartifacts.com/2010/07/userassist/

8. Virustotal scan showed 32/42 antivirus detected as malicious https://www.virustotal.com/file/84824963c0989568674f329e8dd92eb735f27609ef27e6352347288f62bf1d16/analysis/1334516889/

9. The Malwr dynamic analysis http://malwr.com/analysis/0916af77efc95add28e0abdd17b8a64c/

10. Harlan Carvey’s blog post about the MUICache http://windowsir.blogspot.com/2005/12/mystery-of-muicachesolved.html

11. Whitepaper about the forensic significance of the Shim Cache https://blog.mandiant.com/archives/2459

12. Chad Tilbury article about Windows 7 Shellbags http://computer-forensics.sans.org/blog/2011/07/05/shellbags

13. Article "Evidentiary Value of Link Files" http://www.forensicfocus.com/link-file-evidentiary-value



Article Edited By:

Harlan Carvey
Don C. Weber

It was a little over two years ago when I started Journey Into Incident Response (aka jIIr). In these two years I learned a lot about blogging on technical topics so I wanted to share some tips and advice for those considering taking the plunge into the blogosphere. The following are some things to consider from planning your blog to setting it up to maintaining it:

      -  Why
      -  Motivation
      -  Post Frequency
      -  Content
      -  Publishing Method
      -  Blog Template
      -  Blog Configuration
      -  Blog Post Tips
      -  Advertising
      -  Gauging Interest
      -  Motivation

Why

My first question to any would be blogger is why. Why do you want to put yourself through the agony of sacrificing your personal time and resources so you can share your experiences and research. There are other avenues to take; write an article and submit it to a site offering free content (such as DFI News or Forensic Focus). Write a post for a blog that publishes guest posts (such as SANs Forensic blog or Girl, Unallocated). I’m not trying to talk anyone out of blogging since it has been a rewarding experience. On the contrary, I’m just trying to get my point across that blogging is a lot of work and in the end you are doing it for free. When I decided to start blogging I told my wife “it will be easy”. Sure I had a new born to go along with my two other sons, was pursing my Masters degree, and still had a full time security job but I seriously thought putting together a few posts a month would be a cake walk. My perspective changed pretty quick after I wrote my first few posts.

If you have any hesitation about not wanting to put in the work then consider the other options available. If you made up your mind and blogging is the route you want to take then the remaining tips may be helpful.

Motivation

People who start blogging have a reason why they are doing it. For some it’s to give back to the community, for others it’s for name recognition, for some it’s a platform they control to share their research, and for the rest it’s any number of reasons. Before you even start setting up a blog make sure you know what your true motivation is. There will be times when you have writers block or you just don’t feel like writing anything so whatever your reason is for blogging needs to be enough to motivate you to put the keyboard to word processor. Your motivation needs to come from within since most of the time others can’t do this for you.

Frequency

This was something that helped me so I wanted to pass this nugget along. Before you even start worrying about content, site design, or any other details take some time to consider how often you want to update your blog. If you look at other DFIR blogs you will notice a range in how often they are updated. From multiple updates in a week to monthly updates to yearly postings. As an author, I found it helpful to set myself a monthly goal of how many posts I wanted to put together. It helped to not only plan better on how to reach my monthly goal but it helped get me into the habit of writing regularly. As a blog reader, I tend to check the sites with a more regular update schedule more so I assume others readers do the same. If a blog gets updated at random times then it tends to fall off my radar until I see it in my RSS feeds. Whatever goal you set for yourself it’s not something that needs to be publicized. It’s a personal goal for yourself and only for you to know. I’m only mentioning my goal since I’m giving this advice. I always wanted to write three substantial posts per month so at the end of the year I would have 36 decent write-ups.

Content

I also found it helpful to at least pick a theme for the blog. There are times when I’m not sure what to write about so having a theme gives me something to fall back on. As you might have noticed my theme is in the title: Journey Into Incident Response. I wanted to blog about the different things I learn and experience as I work on improving my skills and knowledge to investigate security incidents. If you do decide to pick a theme it doesn’t mean you are locked into it. Write about whatever you want whether if it’s about a book, tool, article, or anything else you are working on in the moment. The theme is just a crutch for when you start to run out of ideas which brings me to my next point. Make sure you have a blog idea hopper. Keep a list of different ideas for future posts and always add to it when you think of something new. Some ideas may never go beyond the hopper while others may turn into great articles. One of the reasons why I don’t struggle with ideas for posts is because I constantly have between 5 to 10 ideas in my hopper. If I need something to write about then I just look over my hopper and pick the one that interests me the most. Case in point, the idea for this post has been in my hopper for months.

Publishing Method

At this point you know why you want to blog, what your motivation is, how often you will update it, and you have a general idea about what content you want. The biggest decision you will now make is how you want to host your blog. The two most frequent publishing applications I see DFIR bloggers use are Word Press and Blogger. If you aren’t sure about what publishing application to use then reach out to the blog authors you read. I bet the authors are more than willing to let you know why they choose what they did and how they feel about their decision. As for me I went with Blogger for two simple reasons. First was because most of the blogs I followed at the time used the service and second was because I didn’t want to have to worry about maintaining software updates. All I want to do is blog and Blogger enabled me to do that.

Blog Template

The second biggest decision will be what template to use for your blog. The template is how your blog looks and what people will stare at when reading your posts. Your publishing application may have a few templates available that meet your needs. If the built-in templates aren’t what you are looking for then there are free templates available online. What sites should you use to get a free template? Great question and it’s still one I can’t really answer today. The last thing I wanted was to get a free template with an embedded malicious link that would attack any visitor of my blog. So I took a closer look at a few DFIR blogs I followed to see where they got their templates. I went to each blog and viewed the site’s source code to find the template’s author website. The screenshot is from my blog’s current template but it’s also the website I saw in a ton of other DFIR blogs.

Blog Configuration

Remember growing up when people said first impressions matter? I think the statement is true even for blogging. When I was in the process of configuring my blog one setting I loved was the ability to restrict access to my blog. I pretty much prevented anyone from seeing the blog while I tried out different templates, options, and layouts. In Blogger I even used the setting preventing the site getting indexed by Google. I only removed the permissions, thus allowing anyone to see the blog, when I had everything set up the way I wanted. Configuring your blog is a matter of preference so my only advice is to don’t unveil it until it’s set up the way you want it.

Blog Post Tips

ITAuditSecurity has some great posts about blogging tips. As it relates to putting a post together one tip I wanted to echo was in his post Blogging: Choose Great Titles and Intro Sentences. His reasoning is not only do they grab the attention of readers but they also help in having better search engine results. I completely agree with his points and I wanted to build on it with another point. Picking good titles and intro sentences helps to let the reader know exactly what the post will be about. If the point of the post can’t be conveyed in a title or one sentence then make sure it is conveyed in the first paragraph. If the content of the post isn’t clear upfront then some readers will stop reading before they reach the part of the post where you make your point. In all of my posts I try very hard to make sure that the reader knows exactly what I’ll be talking about by the time they finish reading the first paragraph.

Advertising

I remember thinking very clearly when I was getting ready to launch the blog “how do you advertise it to others”. I thought there was some secret so I reached out to Harlan for advice. At the time I was just a name from the Win4n6 group who Harlan helped once before but I figured who else would be better to ask them someone who has been blogging for years. Harlan’s response to my question about the secret to advertising was:

“Add your blog to your email signature, and tell others about it. Pass it around. I, and others, constantly link to blogs and posts that are interesting and informative. There's no real secret”

Here I was thinking there was some secret; some involved advertising process only known to bloggers but in the end advertising has actually been the easy part. Two years later I can honestly say Harlan’s advice was spot on.

Gauging Interest

Don’t get me wrong about my next comment. I truly appreciate all the feedback I have gotten over the last two years. The conversations in person, comments offline, and comments posted to jIIr. When you start blogging treat any feedback you get like gold. Feedback is the best way to get an idea about your blog’s content so cherish it when someone gives it to you. The reason is because the majority of blog readers don’t provide feedback. They don’t leave comments, send emails, or contact you using other means. Thinking about it I fall in the same boat. I follow over 300 blogs and my comment to read ratio is pretty low. For the first year blogging it felt as if I was talking to myself. I would keep posting different content but I didn’t get a lot of feedback. I wasn’t sure what content went over well and which ones as Harlan says “went over like a fart”. In these situations Google Analytics will be your friend. Google Analytics keeps stats about your site such as pageviews for each post and referrals to your blog. For the times when I don’t get feedback I can get a rough idea about the content people like by looking at the page views. However, some of my posts where I got great feedback were the same ones with low pageviews. Leverage Google Analytics as a tool to guage interest on your site but remember it is not fool-proof.

Motivation

As I mentioned before blogging has been one of the most rewarding things I have done. It has required a lot of sacrifice but it has made me into a better DFIR practitioner. There are times when I felt as if I wasn’t adding value; times when I was flying high because my research and posts has helped others. Regardless of what happens when you blog, the most important advice I can give is to stay true to what motivated you to blog in the first place. If you are working towards accomplishing what you set out to do then the rest doesn’t matter. Enjoy the ride and remember to say thanks to those who give shout outs about your blog or provide feedback.

There is a tendency to focus on what is different when we are faced with newer operating systems. What are the security changes and how does that impact security testing against it? What are the new artifacts and what new information do they provide? The focus is mostly on the changes as it relates to us looking at the operating system. However, there are other changes that may impact us even more and the way we do our jobs. These changes occur when we use these newer operating systems on the workstations we use for analysis and the changes impact how our tools operate. The User Account Control feature in the newer operating systems is one such change impacting how we use our tools.

User Account Control (UAC) was first introduced with Windows Vista and the feature carried over to Windows 7. By default, UAC is turned on in both operating systems. “The primary goal of User Account Control is to reduce the exposure and attack surface of the Windows 7 operating system by requiring that all users run in standard user mode, and by limiting administrator-level access to authorized processes.” This means even if a user account is in the administrators group every application the account runs will only have standard user privileges instead of the all powerful administrative privileges. In essence, we are not administrators when UAC is turned on.


It’s fairly easy to see the impact UAC has on a user account with administrative privileges. With UAC turned on, open a command prompt and type the command “whoami.exe /priv” to see the privileges of the logged on user account (if your system has UnxUtils configured in your path then make sure to run Windows\System32\whoami.exe).

C:\> whoami.exe /priv


As shown above the user account only has five privileges and none of them are the elevated privileges typically associated with administrator accounts. The two ways to get around UAC is to either turn it off or to use the “Run As” feature when starting an application. Continuing to see the impact of UAC, with the same user account re-run the command “whoami.exe/ priv” with either UAC completely turned off or with a command prompt opened with the “Run As” feature. Notice the difference in the privileges the user account has as shown below.

C:\> whoami.exe /priv

UAC Impact on Digital Forensic and Incident Response Tools

UAC will impact any application that requires administrative privileges to function properly. I first encountered the impact UAC has on applications is when I was working on a script to examine volume shadow copies. My script needed elevated privileges to work and without it the script would just fail. Why the sudden interest in UAC now? Last week a new DFIR program was released and the tool requires elevated privileges to run properly. A few people encountered an error when running the program on both Windows Vista and Windows 7. The program in question is Harlan’s Forensic Scanner and the error some people saw when clicking the Init button is below.


The error is a direct result of UAC being enabled on the workstations running the Forensic Scanner. To get around UAC and thus the error, all one has to do is use the “Run As” feature when launching the Forensic Scanner (or in my case by disabling UAC completely). Again, the UAC error is not unique to the Forensic Scanner; it’s any program that requires administrative privileges. With that said let’s take a closer look at what is really occurring with the scanner and UAC.

I monitored the Forensic Scanner as it executed with ProcessMonitor using an administrative user account with UAC turned on. The screenshot below shows the first permission issue encountered due to the restricted privileges imposed by UAC.


The event shows access is being denied when the scanner tries to open the M:\Windows\system32\config\software hive in my mounted forensic image. Now let’s take a look at the same event with UAC turned off (or with the scanner being executed with the “Run As” feature).


The event shows the result is now a success instead of the denied access previously encountered. The end result is the software registry hive was opened. Now the error some people are encountering makes a little more sense: “No filename specified at PERL2EXE_STORAGE/WinSetup.pm line 136”. The Forensic Scanner is unable to open the registry hives because the user account being used has standard privileges since UAC removed the administrative privileges.

When we upgrade our workstations to newer operating systems it may impact the way our tools work. The User Account Control feature introduced with Windows Vista and carried over to Windows 7 is just one example. When the User Account Control feature is turned on any tools needing administrative privileges will no longer function properly.

It looks like Santa put his developers to work so they could deliver an early Christmas for those wanting DFIR goodies. Day after day this week there was either a new tool being released or an updated version of an existing tool. In this Linkz edition there isn’t much commentary about the tools because I’m still working my way through testing them all to better understand: what the tool is, how the tool functions, and if the tool can benefit my DFIR process. Without further ado here are the Linkz of the DFIR goodies dropped in the past week.

Big shout out to Glen (twitter handle @hiddenillusion) for his steady stream of tweets from the 2012 Open Source Digital Forensics Conference saying what the new tool releases were.


RegRipper Plugins

The RegRipper project released a new archive containing a bunch of plugins. The plugins extract a wealth of information including: program execution artifacts (appcompatcache, direct, prefetch, and tracing), user account file access artifacts (shellbags), and a slew of plugins to create timeline data (appcompatcache_tln, applets_tln, networklist_tln, and userassist_tln). For the full detail about what was updated check out Wiki History page and to get the new archive go to the download section on the RegRipperPlugins Google code site.

ForensicScanner

While on the topic about a tool authored by Harlan, I might as well talk about his latest creation. Harlan released a new tool named Forensic Scanner followed by a detailed post explaining what the tool is. To get a better understanding about how to use the scanner there’s documentation on the Wiki page for ScannerUsage (there's also a user guide included in the zip file). What I find really cool about this tool is how it will speed up examinations. All one has to do is point the Forensic Scanner at a mounted image and then it extracts all information fairly quick. It reduces the time needed for extracting information so an analysis can start sooner; thus reducing the overall examination time. The tool is hosted on the download section of the ForensicScanner Google code site.

Volatility

Up next is another tool that is plugin based but this time around I’m pretty speechless. All I can say is the project has released a ton of information to accompany its latest version. Leading up to the release the project released a new plugin every day for a month and each plugin was accompanied with a blog post. Jamie Levy did an outstanding job summarizing all the blog posts: Week 1 of the Month of Volatility Plugins posted, Week 2 of the Month of Volatility Plugins posted, and Week 3 of the Month of Volatility Plugins posted. To grab the latest Volatility version go to the Google code site download section and to see what is new check out the Volatility 2.2 release notes.

Log2timeline

Another great tool has been updated but this time it’s a tool for performing timeline analysis. Log2timeline 0.65 was released a few weeks ago; I know this post is discussing tools released in the last week but I can’t do a toolz post and completely ignore L2T. One cool update is the addition of a new input module to parse utmp file which is an artifact on Linux that keeps track of user logins and logouts on the system. To grab Log2timeline 0.65 go to the Google code site download section and to see all the updates check out the Changelog.

L2T_Review

There are different ways to review the Log2timeline output data depending on the output’s format. Typically, people use the csv output and in this case a few different options were available. The csv file could be Grepped, viewed in a text editor, or examined with a spreadsheet program such as Microsoft Excel (refer to jIIr post Reviewing Timelines with Excel) or OpenOffice Calc (refer to jIIr post Reviewing Timelines with Calc). Now there’s another option and it’s a pretty good option at that. David Nides has been working on his L2T_review tool for reviewing log2timeline csv timelines. He posted about it a few times including here, here, and here. Typically, I don’t mention tools still in beta but I wanted to make an exception for this one. I finally got around to testing L2T_review this week and I definitely liked what I saw.

Sleuth Kit and Autopsy

The 2012 Open Source Digital Forensics Conference did occur this week so it shouldn’t be a surprise to see a new version of the Sleuth Kit released. I haven’t had the time to test out Sleuth Kit 4.0 nor have I been able to look into what the new updates are. Sleuthkit 4.0 can be downloaded from the Sleuth Kit website and the History page can be referenced to see what the updates are. The Autopsy Forensic Browser is a graphical interface to The Sleuth Kit and a new Windows beta version was released last month. I quickly tested out the functionality and I’m truly impressed. I’ve been looking for a decent free forensic browser besides FTK Imager to run on Windows and now I can say my search is over. Autopsy is that forensic browser and it can be downloaded from the Autopsy download page.

HexDive

I’ve mentioned the HexDive program on my blog a few times and the latest is when I was analyzing a keylogger. HexDive has been updated so it provides more context and testing out this new functionality is on my weekend to-do list.

ProcDOT

Speaking about malware analysis. I picked up on this next tool from a Lenny Zeltser tweet. ProDOT is “tool processes Sysinternals Process Monitor (Procmon) logfiles and PCAP-logs (Windump, Tcpdump) to generate a graph via the GraphViz suite”. This tool seems really cool by being able to correlate the ProcMon logfile with a packet capture to show how the activity looks. Yup, when I’m running HexDrive against a malware sample the follow up test will be to launch the malware and then see how the dynamic information looks with ProcDOT.

GRR Rapid Response

I first learned about GRR when I attended the SAN Digital Forensic and Incident Response summit last June. GRR Rapid Response is an incident response framework that can be used when responding to incidents. At the top of my to-do list when I have a decent amount of free time will be set up GRR in a lab environment to get a better understanding how the framework can benefit the IR process. The GRR homepage provides some overview information, the Wiki page provides a wealth of information, and the GRR Rapid Response - OSFC 2012.pdf slide deck contains information as well. GRR itself can be found on the download page.

Lightgrep is open source!

LightGrep is a tool to help perform fast searches. I have yet to try this software out but an interesting development is the core Lightgrep engine is now open source. This will be one to keep an eye on to see how it develops.

bulk_extractor

Rounding out this edition of Linkz for Toolz is a new version for the program bulk_extractor. Bulk_extractor scans a disk image, a file, or a directory of files and extracts useful information without parsing the file system or file system structures. Again, this is another tool on my to-do list to learn more about since my free time has been spent on improving my own processes using the tools already in my toolkit.

Malware forensics can answer numerous questions. Is there malware on the system, where is it, how long has it been there, and how did it get there in the first place. Despite all the questions malware forensics can solve there are some that it can’t. What is the malware’s purpose, what is its functionality, and is it capable of stealing data. To answer these questions requires malware analysis. Practical Malware Analysis defines malware analysis as “the art of dissecting malware to understand how it works, how to identify it, and how to defeat or eliminate it”. I’ve been working on improving my malware analysis skills while at the same time thinking about the different ways organizations can benefit from the information gained by analyzing malware. One such benefit is empowering the help desk to combat malware. Everyday help desks are trying to find malware on computers using antivirus products lacking signatures to detect it. Analyzing malware can provide enough information to build a custom antivirus signature to provide the help desk with a capability to find it until the commercial antivirus signatures catch up. In this post I’m going through the process; from analyzing malware to creating a custom antivirus signature to using the signature in the portable apps ClamAV version.

The work presented in this post was originally put together for my hands on lab for a Tr3Secure meet-up. Also, the sample used was obtained from Contagio’s post APT Activity Monitor / Keylogger.

Disclaimer:

I’m not a malware analyst. I’m an information security and digital forensic practitioner who is working on improving my malware analysis skills. As such for anyone looking to be more knowledgeable on the subject then I highly recommend the books Practical Malware Analysis and the Malware Analyst's Cookbook.

Static Analysis

Static Analysis is when the malware is examined without actually running it. There are different static analysis steps to extract information; the two I’m discussing are: reviewing strings and reviewing the import table.

Reviewing Strings

Strings in malware can provide clues about the program and I find them helpful since it makes me more aware about malware’s potential functionality. However, conclusions cannot be drawn by solely looking at the strings. I usually first run HexDive on a sample to filter the strings typically associated with malware followed by running Strings to make sure I see everything.

Below is the Hexdrive command running against AdobeInfo.exe and a snippet from its output.

C:\> Hdive.exe C:\Samples\AdobeInfo.exe

CreateFileA
SetFileAttributesA
CreateDirectoryA
GetCurrentDirectoryA
GetWindowTextA
GetForegroundWindow
GetAsyncKeyState
GetStartupInfoA
[Up]
[Num Lock]
[Down]
[Right]
[UP]
[Left]
[PageDown]
[End]
[Del]
[PageUp]
[Home]
[Insert]
[Scroll Lock]
[Print Screen]
[WIN]
[CTRL]
[TAB]
[F12]
[F11]

There were numerous Windows API function names in the strings and looking the functions up in Practical Malware Analysis’s Appendix A (commonly encountered Windows functions) provides some clues. The following are three function names and why they may be relevant:

     - CreateFileA: creates new or opens existing file

     - GetForegroundWindow: returns a handle to a window currently in the foreground of the desktop. Function is commonly used by keyloggers to determine what window the user is entering keystrokes in

     - GetAsyncKeyState: used to determine whether a particular key is being pressed. Function is sometimes used to implement a keylogger

The other interesting strings were the characters associated with a keyboard such as [Down] and [Del]. The combination of the API names and keyword characters indicate the malware could have some keylogging functionality.

Below is the Strings command running against AdobeInfo.exe and a snippet from its output.

C:\>Strings.exe C:\Samples\AdobeInfo.exe

---- %04d%02d%02d %02d:%02d:%02d ----------------
\UpdaterInfo.dat
\mssvr
The Active Windows Title: %s

In addition to the strings extracted with HexDrive, Strings revealed some other text that didn’t become clear until later in the examination.

Reviewing the Import Table

“Imports are functions used by one program that are actually stored in a different program, such as code libraries that contain functionality common to many programs”. Looking at functions imported by a program provides better information about a malware’s functionality than solely relying on its strings. I used CFF Explorer to review the import table as shown in the screen shot below.


The import table showed three DLLs which were kernel32.dll, user32.dll, and msvcrt.dll. The DLLs’ functions imported matched the Windows API function names I found earlier in the strings. The functions provide the sample with the ability to: create and open files and directories, copies text from a window’s title bar, returns a handle to an active window, returns handle to a loaded module, and monitor for when a key is pressed. All of which strengthens the indication that the sample is in fact a keylogger.

Dynamic Analysis

The opposite of static analysis is dynamic analysis which is examining the malware as it runs on a system. There are different dynamic analysis steps and tools to use but I’m only going to discuss one; monitoring program execution with Capture-Bat. Below is the output from the Capture-Bat log after AdobeInfo.exe executed on the system (the entries related to my monitoring tools were removed).

"2/8/2012 15:03:27.653","process","created","C:\WINDOWS\explorer.exe","C:\Samples\AdobeInfo.exe"

"2/8/2012 15:03:40.403","file","Write","C:\Samples\AdobeInfo.exe","C:\Samples\mssvr\UpdaterInfo.dat"

"2/8/2012 15:03:40.481","file","Write","C:\Samples\AdobeInfo.exe","C:\Samples\mssvr\UpdaterInfo.dat"

"2/8/2012 15:03:40.497","file","Write","C:\Samples\AdobeInfo.exe","C:\Samples\mssvr\UpdaterInfo.dat"

"2/8/2012 15:04:33.419","file","Write","C:\Samples\AdobeInfo.exe","C:\Samples\mssvr\UpdaterInfo.dat"

"2/8/2012 15:04:33.419","file","Write","C:\Samples\AdobeInfo.exe","C:\Samples\mssvr\UpdaterInfo.dat"

Capture-Bat revealed when AdobeInfo.exe runs it creates a folder named mssvr in the same folder where the executable is located as well as creates a file named UpdaterInfo.dat inside the folder. Remember the suspicious strings before? Now the strings \UpdaterInfo.dat and \mssvr make a lot more sense. Looking at the UpdaterInfo.dat file closer showed it was a text file containing the captured data as can be seen in the partial output below.


---- 20120802 15:07:38 ----------------
15:07:40 The Active Windows Title: Process Explorer - Sysinternals: www.sysinternals.com [XP-SP2\Administrator]
15:07:33 The Active Windows Title: C:\WINDOWS\system32\cmd.exe
15:07:39 The Active Windows Title: Process Explorer - Sysinternals: www.sysinternals.com [XP-SP2\Administrator]
c[CTRL]y
15:07:41 The Active Windows Title: Process Monitor - Sysinternals: www.sysinternals.com
15:07:44 The Active Windows Title: Process Monitor
15:07:38 The Active Windows Title: Process Monitor
15:07:38 The Active Windows Title: API Monitor v2 (Alpha-r12) 32-bit (Administrator)
15:07:44 The Active Windows Title: Process Monitor
15:07:45 The Active Windows Title: API Monitor v2 (Alpha-r12) 32-bit (Administrator)
15:07:35 The Active Windows Title: ApateDNS


Everything in the analysis so far has identified the AdobeInfo.exe program as a keylogger that stores its captured data in a log file named UpdaterInfo.dat. All that was left was to confirm the functionality. I used Windows to create a password protected zip file then I unzipped it. A quick look at the UpdaterInfo.dat log file afterwards confirmed the functionality (note: Windows made me enter the password twice).


16:07:30 The Active Windows Title: Program Manager
16:07:38 The Active Windows Title: Add to Archive
[CTRL]
16:07:58 The Active Windows Title: Program Manager
supersecretsupersecret
16:07:58 The Active Windows Title: Compressing
16:07:59 The Active Windows Title: Program Manager
16:07:21 The Active Windows Title: Extraction Wizard
16:07:30 The Active Windows Title: Password needed
16:07:37 The Active Windows Title: Extraction Wizard
supersecret
16:07:40 The Active Windows Title: Program Manager
16:07:42 The Active Windows Title: Windows Explorer

Creating Custom AntiVirus Signature

I’m not going into detail about how to create custom signatures for ClamAV but I will point to the great references I found on the subject. The Malware Analyst’s Cookbook talks about how to leverage ClamAV for malware analysis in the recipes: Recipe 3-1 (examining existing ClamAV signatures), Recipe 3-2 (creating a custom ClamAV database), and Recipe 3-3 (converting ClamAV signatures to Yara). Another resource is Alexander Hanel’s post An Intro to Creating Anti-Virus Signatures. The ClamAV website also has information on the subject as well including the slide deck in PDF format for the webcast Writing CalmAV Signatures.

I spent some time creating different signatures: from a custom hash database to extended signature format to a logical signature. To keep the post shorter I’m only going to cover how I created a logical signature. A ClamAV logical signature is based on hex strings found inside a file and logical operators can be used to combine the hex strings in different ways. The format for the signature is below:

SignatureName;TargetDescriptionBlock;LogicalExpression;Sig0;Sig1;Sig2;

The SignatureName is self explanatory, the TargetDescriptionBlock is the type of file the signature applies to (0 means any file), LogicalExpression is how the signatures are combined using logical operators, and the Sig# are the actual hex strings. The completed signature is placed into a file with an ldb extension.

Reviewing the strings in AdobeInfo.exe provided some good candidates to create a signature for; specially \UpdaterInfo.dat, \mssvr, and [CTRL]. I used portable apps ClamAV’s sigtool to determine the hex of those strings. I ran the following command for each string:

C:\>echo \UpdaterInfo.dat | App\clamwin\bin\sigtool --hex-dump

The end result provided me with the hex for each string.

\UpdaterInfo.dat
5c55706461746572496e666f2e646174

\mssvr
5c6d73737672

[CTRL]
5b4354524c5d

I then combined the strings into a logical signature as shown next.

AdobeInfo.exe;Target:0;0&1&2;5c55706461746572496e666f2e646174;5c6d73737672;5b4354524c5d

Finally, I ran the custom signature against the AdobeInfo.exe file and was successfully able to identify it. The command to run a custom scan from the command-line in portable ClamAV is:

App\clamwin\bin\clamscan -d adobe.ldb C:\Samples\

Empowering the Help Desk

I’m done right? I was able to analyzing the malware to determine its functionality, create a custom antivirus signature to detect it, and found a way to run the custom signature using the portable apps ClamAv version. I wouldn’t be too quick to say my job is done though. Let’s be honest, going to any help desk and telling the staff from now on you have to use the command-line may not have the greatest chances of success. You need to provide options; one option most help desk staff will want is an antivirus program with a GUI that’s similar to their commercial antivirus programs. ClamAV has a pretty nice graphical user interface that can be configured to use custom signatures so we could leverage it.

The article How to create custom signatures for Immunet 3.0, powered by ClamAV explains how to write custom signatures and configure the Windows ClamAV version (Immunet) to use them. This is nice but Immunet has to be installed on a computer. A cool option would be to be able to run scans from a removable drive so when the help desk respond to a system all they need to do is to plug in their thumb drive. This is where the portable apps ClamAV version comes into play since it can run scans from a thumb drive. I couldn’t find any documentation about how to use custom signatures in the portable version but after a little testing I figured it out. All that has to be done is to copy the custom signature to the same folder where ClamAV stores it signature files main.cvd and daily.cdv. This location is ClamWinPortable\Data\db folder. I copied my adobe.ldb custom signature to the Data\db folder and was able to locate the malware sample I disguised as Notepad ++.