Security Ripcord

System Combo Timeline:

The syscombotln tool has been updated to fix several bugs and time/date issues.  I have also decided to stop being lazy and updated all of the internal modules and external scripts/tools associated with this tool to properly handle the TLN format as Harlan outlined. This includes the TLN.EnScript which is NOT included in the syscombotln tool.

New functionality includes parsing the Windows XP setupapi.log file.  I have included this functionality due to a little analysis trick pointed out to me by Jason Luttgens and Jon Gross of Mandiant.  Basically any time a Windows Help (chm) file is executed the information is logged in the user’s HTML Help (hh.dat) file.  This information can be used to specify some Initial Infection Vector information.  This information, in turn, may be augmented by driver-based information which, in Windows XP, is logged in the setupapi.log file.  I cannot provide specifics at this time, but I can tell you that you will know suspicious entries when you see them.  (If anybody has specific examples, please provide them in the comments.)  Although I have not had time to parse the hh.dat file, I have had time to parse the setupapi.log file.  The syscombotln module for this file is very basic but it should handle all files well (please let me know if you experience cases where it does not).  An added benefit of parsing this log file is that external USB storage device installation information will also be added to your timelines.  And if there are anti-forensic efforts recommending deleting this log, you know we want to review it’s information and add it to our timelines.

IronGeek Resource:

Just a quick note.  When researching the information in the last post I ran across this great resource by IronGeek.  Once again he has posted some amazing content.  Take a look at his “Forensically interesting spots in the Windows 7, Vista and XP file system and registry” resource.  You might have known about this, but it is new to me, so just in case you missed it as well.

Scripts and Tools:

I have decided to start uploading my scripts and tools when I generate an update.  To this end I have created the Scripts and Tools page which includes some Window Registry tools (including some older RegRipper plugins) and a few Enscripts.  Check this page often for updates and new scripts/tools.  Leave comments with comments, updates, requests.  To help with consistency, I have also started using Subversion to help me track development of all my projects.  Basically because I have been brow-beating (unsuccessfully) Harlan to do the same with his tools.  I have started keeping all my projects on an external USB drive (which I backup often).  To keep each project separate I use the following steps.

1. Copy folder to Projects directory.
2. Type “svnadmin create /media/<usb drive>/Dev/Projects/Repo/<project name>”
3. Type “svn import <project name> file:///media/<usb drive>/Dev/Projects/Repo/<project name> -m “Initial Import”
4. Move original project directory “mv <project name> <project name>_bk”
5. Check out repository “svn checkout file:///media/<usb drive>/Dev/Projects/Repo/<project name> <project name>”
6. Double check files are there and work with it a little while.
7. Delete _bk

This works across Linux systems and should work on Windows systems using something like tortoisesvn.  Hopefully you find that useful for your script and tool development.

I have to say that reading the Windows Incident Response blog has been very useful on several occasions.  Particularly last month while helping at a client’s site.  I had been called in to assist with detecting the Initial Infection Vector of a piece of malware that was propagating to random systems throughout a very large network.  Luckily when I got onsite I was pleased to find that the company’s security staff were squared away and knew how to user their incident response procedures and tools very effectively.  Really they just needed an extra set of hands and a little more organization to help them get over the hump.

After gathering some information from systems around the world (literally) I started doing some memory analysis  information captured from one of the infected systems.  Memory analysis quickly identified one process that had used for DLL injection.  One of the exported functions of a DLL we had already flagged as “interesting” was exporting a function called “StartLoopRunDoor.”  Although this could just be anomalous it sounds an awful like “backdoor” so we noted it.   I moved onto generating timeline information from the systems files, folders, Event logs, and registry modifications and the security administrator helping me added “door” to his keywords and ran another search on the system.  As he was reviewing the hits I heard him say, “What the hell.  Hey come look at this.”  As I Peeked over his shoulder he pointed me to a registry key that had the value “door.”  I started to say, “Yeah, no big deal” when he asked me “Can you store executable files in the registry?”  Smiling, I said, “As a matter of fact, you can.”

It turns out that just days before heading to the site Harlan had mentioned it in his post “More Links“.  Basically Harlan points us to a write-up over at Sophos Labs titled “Persistence is Futile“.  They outline one such infection very nicely and Harlan concludes his post with some interesting capabilities that we might want to take into consideration.  Had I not read Harlan’s post I might not have been surprised by the malware hidden in the registry key values, but I would not have known where to go for immediate resources to help with the situation.

So, what am I really talking about.  Well, luckily I have a few screen shots for you.  First lets start with reviewing the Registry Key in question.  Using Mitek’s Registry File Viewer we drilled down into \\Software Hive\Microsoft\SysMgr.  The are several key values as you can see.  One key value that is hidden is “addr” which contains the IP address of the infected system and one other IP address (not sure the reason).

Now, many of you will be quick to recognize “4D 5A” which corresponds with “MZ” located at the beginning of Windows-based executable and DLL files.   For a better look, here is some of the information in the “ssdt” key value.

Definitely an executable or DLL.  Turns out, that this file was getting written to disk.  Funny thing is, Symantec and Microsoft were not detecting it at the time.  (I have to say, at the time they were detecting the file in the “hide” registry key value but only on disk.) So, we gave them a call.  First we started with the company’s Symantec contact.  We explained what we were doing and then what we had found.  His first words were “You can’t do that.”  We politely informed him that we were looking right at it and it can be done.  Next we pointed him to the SophosLab post so that he could do a little research and spin up on the concept.  Next we asked if they could start working on signature for the malicious code injected into memory and the malicious files stored in the registry.  His response “No and No.”

Let me break down why quickly.  Basically Symantec does not scan memory.  Oh it will look at memory.  It detects what is running and then scans the files, executables, DLLS, etc on disk to see if they contain code that triggers one of their signatures.  But beyond that they cannot detect malicious code that has been injected into memory.  NICE!!!  Next, although the engine (he said engine, not definitions) can look at certain “hard-coded” locations in the registry, it does not actively scan the whole registry looking for malicous behavior.  NICE!!!  Whether or not he new what he was talking about the answer we got at the end of the phone call was, “Send us your files and we’ll see if we can do anything.”  Which, in the end, they did.  But the situation as it occurred was not very promising.

TIP:  You can export the file in any key value by clicking “Save data….”  Hashes of the extracted file and malware found on the system were identical.

Next we called Microsoft.  We explained the situation again to their support representative and the first words out of his mouth were “You can’t do that.”  The rest of the conversation was very similar to the Symantec call.

Of course, while we are talking to these representative we were also looking at the other keys.  Remember “door”?  Well, a quick peek at its contents started to get us a little worried.  Here is what we saw.

Notice the “db” at the beginning?  What about the “yyy” (I know, deal with it!!) and “vk” values?  Well, my friends, that is a little database right there in the registry.  The first entry is the file that is located in the “ssdt” key value.  I cannot show you the other entries in this database because they are related to client information from the registry.  Stuff like account information, group policy settings, and software that was run on the system. Just little things like that.

So, not only do you have to be worried about the registry being used as a part of a malware’s persistence mechanism, you also have to be concerned about the registry being used as a staging area for your intellectual property, credit card information, user information, etc.  All this with limited methods to detect these situations.

The next question is pretty obvious.  If my anti-virus program cannot help me, what can I do to protect myself.  Well, as I am tired, that is going to have to wait until tomorrow.  Check back as I’ll have a registry detection script modeled after Harlan’s RegScan and three RegRipper timeline plugins.

Go forth and do good things,

Don C. Weber

I have been a part of many conversations about Linux-based systems running Anti-virus.  To date my best examples for saying that it should be taken into consideration has been that it ensures that your hardening standards are consistent across the environment.  Conversations of the fact that there are Linux-based malware, rootkits, privilege escalation vulnerabilities have all met with grumbled “Whatever”s, shaking of heads, and a look like “this conversation had better move on or we are done here.”  A recent incident response, however, has provided me with a better example of how anti-virus running on any system, especially servers, can be beneficial.

Let’s set up the scenario.  A US-based company has operating system hardening standards that they adhere to for all deployments.  Servers should not be placed on the internal network until it is proven that the server has been updated and hardened appropriately.  These hardening standards including anti-virus and file integrity software on all systems regardless of operating system.  So you can imagine the surprise of one of the network administrators when she received an email from a company overseas asking them to investigate a server that was conducting a FTP brute force attack on several of their servers.  A quick investigation showed that there had been a significant amount of network communications occurring between this internal server and several external IP addresses.

Network administrators started looking at the internal system in more detail.  It turns out that several developers, in an effort to test updates to one of the companies primary web-based applications, had placed a test web-server and database on the network.  Because of some older firewall rules the IP address they gave the server permitted access to the server on port 80, 443, and 22.  Further investigation determined that these developers did not follow company policy and harden the server although they did install Symantec Anti-virus and configured it to start when the system was booted.  After some initial investigations by server administrators the server was isolated from the network and I was asked to perform a data analysis to determine what had occurred on the system.

Once the data analysis was complete the story was fairly straight-forward.  After being accessible to the Internet for approximately 24 hours the “root” account was access via an SSH brute force attack.  This despite the fact that the developers had used an 8-character password with upper and lower case letters, one number, and one special character (the administrator I talked to also stated that it did not appear to be a modified dictionary word that he could readily read).  Although the SSH brute force attack should have been very noticeable from a network standpoint, it was never flagged.  With access to the “root” account the remote users started uploading tools to the server.  Specifically, the uploaded several well-known attack scripts to run brute force and run denial of service attacks, along with programs designed to connect the server with a botnet, were uploaded to the server.  Symantec anti-virus started alerting immediately.   Although it did not detect all of the malicious files that were uploaded it definitely identified and quarantined many files while writing alerts to the system’s syslog.

As with all system compromises this scenario shows a breakdown of security protections on multiple levels.  Incident response plans are recommended, and in some cases mandatory, for this very reason.  But I find it interesting that of all of the security controls in place by this company, the one that ended up performing its task the best was the anti-virus program on a Linux-based operating system.  Although anti-virus can be considered a prevention control, it is primarily a detection control.  Had this system been configured to centrally log, or had the developers periodically reviewed the system logs, the unauthorized access would have been detected almost immediately.  As it was, the system was used to attack other systems on the Internet for about a week before somebody alerted the company to their problem.

Hopefully this provides a little better explanation of the need and usefulness of deploying anti-virus programs within a Linux, Unix, Mac, FreeBSD, etc environment.  Not only are you protecting your own assets by reducing the gap between system compromise and your staff’s response, you are also making the Interwebs a safer place.

Go forth and do good things,

Don C. Weber

A while back Harlan posted Looking for “Bad Stuff”, pt III (Malware Detection).  In this post he outlined a method of talking about malware so that it could be more easily understood during an incident response.  With the increasing complexity of malware and the variety of analysis interpretations, I think that it is important that we start thinking about a more standard way of explaining malware capabilities and characteristics.

To help with this I have taken a relatively new piece of malware and run it through the paces that Harlan describes.  I have to warn you, there are still things that are not completely understood about this malware.  But, in the end, that is the point.  Some time in the future I can just take the report I generated and update it with any new information.  Not unlike what is currently done by most AV vendors.  But  I hope that Harlan’s method helps incident responders understand these reports a little better.  I think it will also provide them with the means to speak more intelligently about malware and present the issues and reasons for recommendations in a more professional and consistent manner.

I also want you to pay attention to the different sections of the write-up.  In addition to Harlan’s basic characteristics I have included a Research Notes section.  Although some of this information is apparent from the previous sections, I have tried to tie together how specific things were discovered or explain specific actions.  Especially things that are not covered by the AV vendors.  I believe it is a good example of how information obtained by incident responders can add to the details associated with a malware outbreak within an environment.  Many times quick and focused research can discover key aspects about the actions taken by a piece of malware that are not necessarily apparent in the write-up by AV vendors.  These details could drive your response or help you focus on specifics instead of operating with generalities.

NOTE: This post is best viewed using Firefox and may not render properly in Internet Explorer since most of this post is cut and pasted from Microsoft Word. *shrug* I needed the nested bullets.

Trojan.RegSubsDat.A

INITIAL INFECTION VECTOR

• Unknown – possibly email (from AV report) – I cannot figure this out for some reason
• Possibly associated with Excel Vulnerability or vulnerabilities in other Office documents

PROPOGATION MECHANISM

• Unknown – possibly email (from AV report)

PERSISTENCE MECHANISM

• Current User Run Key for ctfmon.exe
  • [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run]
    • ctfmon.exe = “%System%\ctfmon.exe”
  • NOTE: Use of this key appears to be behavior that is consistent with non-malicious activity associated with uncorrupted versions of this program.
• The malicious files ws2_32.dll and ctfmon.exe placed in the %SYSTEM%\dllcache directory to ensure that if they are deleted or modified the system will restore them automatically. This means that the sfcfiles.dll had to be updated to include the names of both files. This also means that the services had to be disable temporarily which could mean that the LastWrite time for the following key and value was updated. Unfortunately there are many key values associated with Winlogon and therefore the LastWrite time is modified regularly.
  • [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon]
    • SFCDisable should equal 0 to indicate that WFP is enabled
  • [HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Windows File Protection]
    • SFCDisable should equal 0 to indicate that WFP is enabled

ARTIFACTS

• Creates
  • %System%\ctfmen.exe
  • %System%\noise0.dat
  • %System%\regs.dat
  • %System%\subs.dat
  • %System%\windcb.dat
  • %System%\windows.dll
  • %System%\bkav2006.exe
• Modifies
  • %System%\dllcache\ws2_32.dll
  • %System%\dllcache\ctfmon.exe
  • %System%\ws2_32.dll
  • %System%\ctfmon.exe
  • C:\boot.ini – disables DEP
    • The boot.ini is modified so that DEP is disabled. This is done by changing the /noexecute value to “alwaysoff” – see the DEP reference in the notes
• Mutexes created – these may be due to the malware or due to other processes or the subverted programs
  • oleacc-msaa-loaded
  • MSCTF.Shared.MUTEX.APG
  • 08B1CDBCH
  • mutexA
• DNS Queries and Web activity
  • v4.windowsaupdate.com
  • happytimer.free.info
• Network Traffic
  • Possibly Excel or other Office or Wordpad Documents that contain shellcode to connect to remote sites and download malware
  • Multiple IDS/IPS signatures should detect shellcode, writes to system32 directory,
• Other
  • During initial malware infection the following files have been detected. These files may be associated with a completely different malware but their occurrence precedes the activity associated with Trojan.RegSubsDat.A and should be noted.
    • % Windir %\SchedLog.Txt or %Windir%\Tasks\SchedLog.Txt
    • At1.job associated with running the program TMP.EXE
    • TMP.EXE – content or actions of executable unknown
    • del.bat – content or actions of executable unknown
    • sfcfiles.dll – modified to include the %System%\ws2_32.dll and %System%\ctfmon.exe
    • %Windir%\JavaApplet
    • %Windir%\h323log.txt

RESEARCH NOTES

From system analysis it appears that the infection starts out by a scheduled task being created on the system.  The Scheduled Task Log shows that a task titled At1.job (probably depends if there is already an At1.job) is suppose to run “TMP.EXE”.  After this is run the other files appear on the system.  I also detect the occurrence of the file “del.bat” in system restore files.  I have not been able to recover either “TMP.EXE” or “del.bat” from any infected systems.  After that the dllcache files appear, the “boot.ini” file is modified, the sfcfile.dll is modified to include the new files in the dllcache, and the Prefetch file for CTFMON.EXE is created or modified.  Later after that the bkav2006.exe file, the “.dat” files, and the JavaApplet folder appear (possibly after a reboot), see the ThreatExpert update.  All of this activity appears to be surrounded by System Restore points being created.  These restore points could be caused by system files being updated or by some other system activity.

RECOMMENDATIONS

• Apply Microsoft Patches MS09-009 and MS09-010
• Update all third party applications including Microsoft Office and Adobe PDF (added for good measure)
• Monitor DNS logs for queries pertaining to “windowsaupdate” and “happytimer”
• Block via DNS, web proxy, or web filtering “windowsaupdate.com” and “happytimer.com”
• Do not read emails or surf the web from servers or critical assets
• Update IDS/IPS solutions to detect shellcode, shellcode in Office products, system32 writes, UPX packer detection
• Use file integrity products or host-based IDS solutions to detect modifications to system files
• Update AV signatures

RESOURCES

• ThreatExpert Trojan.RegSubsDat Report – http://www.threatexpert.com/report.aspx?md5=0cafb41eca73d768091bc93f4343cbb9
• IBM X-Force: Microsoft Excel Remote Code Execution Vulnerability – https://portal.mss.iss.net/mss/xftas/alertAdvisory/details.mss?alertAdvisoryId=3311
• Trojan.Regsubdat.A – http://www.symantec.com/security_response/writeup.jsp?docid=2009-042215-2550-99&tabid=2
• W32.Regsubdat.A!inf – http://www.symantec.com/security_response/writeup.jsp?docid=2009-042222-3030-99&tabid=2
• Microsoft Security Bulletin MS09-009 – Critical – http://www.microsoft.com/technet/security/Bulletin/MS09-009.mspx
• CVE-2009-0100 – http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0100
• Microsoft Excel Malformed Object Memory Corruption Bug Lets Remote Users Execute Arbitrary Code – http://securitytracker.com/alerts/2009/Apr/1022039.html
• A detailed description of the Data Execution Prevention (DEP) feature in Windows XP Service Pack 2, Windows XP Tablet PC Edition 2005, and Windows Server 2003 – http://support.microsoft.com/kb/875352
• Registry settings for Windows File Protection – http://support.microsoft.com/kb/q222473/
• Hacking Windows File Protection – http://www.bitsum.com/aboutwfp.asp

POSSIBLY RELATED

• Microsoft Security Bulletin MS09-010 – Critical – http://www.microsoft.com/technet/security/Bulletin/MS09-010.mspx
• Microsoft WordPad Text Converter Remote Code Execution Vulnerability – http://www.securityfocus.com/bid/32718/info
• Microsoft WordPad Word 97 Text Converter Memory Corruption Error Lets Remote Users Execute Arbitrary Code – http://securitytracker.com/alerts/2008/Dec/1021376.html

For those of you still reading I’ll provide you with what is currently being provided by Symantec and Microsoft for this malware.  I am going to leave the recommendations off of the Symantec write-up to save space.  One note I would like to make is that the Symantec write up talks about injecting code into specific dlls.  This is a perfect example of information that malware analysis will discover that an analysis of system artifacts may miss.  These write-ups are still necessary and helpful.

Symantec – Trojan.Regsubdat.A

Discovered: April 22, 2009

Updated: April 23, 2009 7:45:14 PM

Type: Trojan

Infection Length: 33,280 bytes

Systems Affected: Windows 2000, Windows 95, Windows 98, Windows Me, Windows NT, Windows Server 2003, Windows Vista, Windows XP

The Trojan may arrive as an email attachment.

Once executed, the Trojan creates the following files:

• %System%\ctfmen.exe
• %System%\noise0.dat
• %System%\regs.dat
• %System%\subs.dat
• %System%\windcb.dat
• %System%\windows.dll

It then modifies the following files:

• %System%\dllcache\ws2_32.dll
• %System%\dllcache\ctfmon.exe
• %System%\ws2_32.dll
• %System%\ctfmon.exe
• C:\boot.ini

The Trojan then disables the Data Execution Prevention (DEP).

Next, the Trojan injects executable code from the non-executable .dat files into the ctfmon.exe process and any other process that loads the following file:
%System%\ws2_32.dll

Once the compromised computer has restarted, the Trojan contacts the following remote location and may download additional files:
v4.windowsaupdate.com

Microsoft – Virus:Win32/Kirpich.A

Summary
This software threat is detected by the Microsoft antivirus engine. Technical details are not currently available for this threat.

Go forth and do good things,

Don C. Weber

I was learning how to use Mandiant’s Memoryze the other day and having a bit of trouble getting to know the XML configuration files.  My real task was to get Memoryze working with memory shared from a remote system using F-Response.  To do this I was pointing Memoryze to the memory instance, instead of an image file, and then using Audit Viewer to parse the information.  Unfortunately I was not able to get it working.  This was more likely due to user error and my not initially understaning how to implement the XML configuration file properly. (More on F-Response and Memoryze later!!)

Right when I thought I had figured out how to use the XML files I got a pleasant little surprise on the Mandiant blog.  Audit Viewer has been updated to run Memoryze automatically.  Now we have a quick and easy method to set up Memoryze’s XML configuration files automatically.   Parsing memory for valuable information has just become is as easy as it can get.

Before I was able to test this new version of Audit Viewer with F-Response I got a chance to use it on a memory dump from a system infected by the Conficker malware.  Conficker has been analyzed in detail by several organizations.  I like the series of blog posts on the Symantec blog as well as the very detailed analysis by SRI International.  Using the capabilities of Memoryze, however, I was able to see some Conficker activity that was not mentioned in any of the analysis that I have reviewed so far.

I’ll start out by mentioning, as most of you know, I am not a malware analyst.  I’m just pointing out a few things that appear to be interesting.

Let’s start with quick background.  The system that I gathered the memory from was a Windows XP SP3 system that was infected by Conficker via a USB drive.  I don’t have the system any more and although I could infect another system to confirm some of this information I don’t have a stand alone system readily available to infect.  We all know now that Conficker has some builtin virtual machine detection so I didn’t attempt to replicate using a VMware image.

The system showed the usual symptoms.  The Registry pointed to a randomly named service calling a randomly name DLL in the c:\WINDOWS\system32 directory.  In this case the DLL was named taqswng.dll.  The following image shows a listing of all the files that start with “ta” in the System32 directory.   Conficker marks the file as hidden so I had to use the “dir /A H” command to get it output with the rest of the files. (Right click on any image and select “View Image” to see a larger, more readable, image.)

Since I was here I ran two other commands.  First I wanted to see that processes were currently running.  Using the Tasklist command I determined that the process with ID 1484 looked interesting.  It is calling many other services that resemble the functionality outlined in many of the Conficker write-ups.  The image below highlights what I am talking about.

Next I wanted to know what the system would display as open connections.  Conficker is suppose to start an HTTP service on a random port between 1024 and 10,000.  The next image shows that the process 1484 does have a LISTENING port on 2980.

Now, I didn’t think that I would get any new information out of reviewing the memory of this system.  I just wanted to show myself what Memoryze could offer and how I could leverage it in the future when investigating processes.  After I used Audit Viewer to parse the memory for everything (use the PDF manual that is provided as part of the download to help you use Audit Viewer and Memoryze) the first thing I did was locate process 1484 and check the files tab to see if I noticed anything.  After review I noticed the taqswng.dll file was listed.

Excellent but I have to admit.  This would have been lost in the shuffle to me.  Basically, this is good verification that I have found the proper process.  Next I checked the Port tab.  This is where it gets interesting.  From the netstat command I know that I should be looking at TCP port 2980 and UDP ports 1023 and 1034 (both UDP ports on the loopback).  But look what Audit Viewer gives me.

But where does TCP port 1033 come into the picture?  I wish I still had this system so that I could try and connect to this port.  I did a quick review of all the analysis resources I am aware of and they do not reference a second listening service.  I can tell you that we did verify that this was Conficker.B and not Conficker.C.  Of course the varient does not matter because this would be different functionality.

The next interesting part came when I reviewed the Memory Sections tab.  The information provided here points to the process accessing the “index.dat” file.  Now, I’m not sure if this is to get the proxy settings to help access the Internet.  It very well could be and I have not researched to determine if this is the case.  But why Conficker is accessing the files listed in the image below are beyond me.  As with the extra port, there is no mention of this behavior in any Conficker resource.

If anybody has an answer to these questions I would like to know.  Post your explanation in the comments or, if you would rather speak with me privately, just include a valid email address in your comment and I will contact you directly.  I would have investigated this a little more deeply but due to time and resources I thought it better to get the question out there.

Good luck if you are still dealing with Conficker.  While you are addressing it, beware Virut.

Go forth and do good things,
Don

While everybody has been busy responding to Conficker/Downadup a nasty little virus loosely known as Virut has begun to make itself known.  When I first heard about this a co-worker pointed me to a new post at the Microsoft Malware Protection Center: There’s a New Virut on the Block.  Over the next few days some of the other software vendors started posting their findings about this new mutation: Microsoft, Symantec, McAfee, TrendMicro, ThreatExpert, Sophos (they call it Scribble).

This virus is especially fun because it is very good at propagating throughout a Microsoft Windows environment very quickly.  Here are some of the most interesting features:

Virus:Win32/Virut.BM

Win32/Virut.BM disables Windows System File Protection (SFP) by injecting code into WINLOGON.EXE. The injected code patches sfc_os.dll in memory which in turn allows the virus to infect files protected by SFP.

The virus infects .EXE and .SCR files on access, hence actions such as copying or viewing files with Explorer, including on shares (with write access) will result in files being infected, and the virus spreading from machine to machine.

W32/Scribble-A

A injects a malicious iframe into files whose extensions start with HTM, PHP or ASP, with affected files detected as Troj/Fujif-Gen. At the time of writing the iframe points to a site that hosts more malware.

PE_VIRUT.BO

This file infector connects to a remote IRC server. It then joins a channel to receive and execute commands on the affected system. This routine effectively compromises system security.

I can hear what you are thinking about these capabilities.  Nothing too unusual.  Companies should be able to handle this sufficiently.  It appears that the Anti-Virus vendors are on top of the situation so prevention and clean-up should be a breeze.  Well, that is where the complications begin.  Remember that little bit about disabling Windows File Protection?  This means that Virut can and will infect critical system files.  One detail that some AV vendors leave out or bury is the fact that cleaning up after Virut is not that easy.  Microsoft helps us with a little note in their write-up.

Virus:Win32/Virut.BM

Note: The method of infection used by Win32/Virut can damage some infected files beyond repair. In these cases, in order to return a machine to its pre-infected state, it may be necessary to install a clean backup of the operating system and associated applications.

Now it starts getting interesting.  Let me give you another scenario.  Your organization is very robust and you are using roaming profiles to allow your users to log into multiple workstations.  All of a sudden your server that hosts these roaming profiles is infected.  Users start logging in because that is what they do.  Bang, workstation after workstation is infected.  The only way to stop it is to stop users from logging in or taking your roaming profile server offline.  Who’s going to make that call?  No worries, your users don’t have administrator privilieges, correct?  Of course, it does not have to be a roaming profile server.  Do you have any file sharing configured within your network? Sweetness.

Here is a great scenario for administrators.  Do you have any web-based administration tools?  What about your developers?  No admin tools, okay, do you have any internal websites?  Wow, suddenly this is adversely affecting a whole bunch of applications and not just the operating system.

So now I’ll let you decide.  Would you rather spend your time rebuilding your critical systems and user workstations or spend the time doing a little preparation?  Actually, the protections are all the same ones that every security professional has been pushing over the last five years.  There is nothing new or golden.  But lets go over a few (this is not a comprehensive list) so that I can say I pointed you in the right direction.  By the way, if you have some to add, please add a comment or two.  As usual, all of these should be evaluated to determine if they do reduce risk while not adversely impacting business operations.

Quick Techniques:

• If it is determined that a server that provides roaming profiles, login scripts, or any network share has been infected the systems should be immediately isolated from the network.  Users should not log into any systems that require roaming profiles or are connected to network shares until the server(s) that provide this functionality are clean.
• All systems should be updated to include the new virus definitions provided by the AV vendor.  If maintenance agreements are in place, the AV vendors should be contacted to determine if they have provided definitions or protections for the new strains of the Virut virus currently propagating in the wild.
• All network and host-based IDS/IPS systems and applications should be updated to include new signatures associated with detecting the activity generated by this malware.  If maintenance agreements are in place, the network and host-based IDS/IPS should be contacted to determine if they have provided definitions or protections for the new strains of the Virut virus currently propagating in the wild.
• Remote systems such as laptops should be required to update their AV software and scan the system before being permitted to connect to the network.
• Users should be required to scan all removable media (regardless of size or content) on an isolated, patched, and AV up-to-date virus scanning system before being allowed to connect to an computer (server or workstation).
• On critical resources create a local administrative level account Where possible isolate critical systems from network shares and resources.  Temporarily band network login, the use of removable media, and any unnecessary network activity such as checking email or browsing the Internet from these resources.  This may require the creation of a local (non-roaming profile) administrative level account to administer the system in case the roaming profile or server providing login scripts is compromised.
• Complete, operating system level backups of all critical assets should be created and tested to ensure that these systems can be recovered quickly and accurately.
• Monitor the list of viruses cleaned by Microsoft Malicious Software Removal Tool to determine when it provides functionality for the new strain of Virut.  Have administrators practice remotely and locally deploying using this tool.
• Monitor network traffic for bot-like activity connecting to Internet servers as outlined by AV site Virut descriptions.
• Specific administrators should be assigned to monitor for updated information from AV vendor websites.

Don’t think those are hard enough to implement threat or no threat?  Try these long term protections.

Long Term Techniques:

• Users that do not require administrator capabilities should not be given administrator rights on their systems.
• Systems that do not require access to network shares and other resources should not be configured to utilize these shares or resources.
• Network resources and user profiles should be segregated by domain restrictions provided through robust Active Directory configurations.
• All systems and servers (on which it does not pose an adverse impact to operability) should have centrally managed AV and Host-base Intrusion Detection/Prevention software installed.
• Autorun should be disabled on all systems and servers.
• All operating systems and third party applications should be routinely patched.  All unnecessary operating system functionality or third party applications should be removed from any system that does not require them to operate or provide business related functionality.
• Review and upate all maintenance agreements with AV and network/host-based IDS/IPS vendors.
• Review, update, and implementation of a policies detailing acceptable use pertaining to removable media, email usage, and Internet usage.

All of this said I would like to remind everybody that the key to incident response is the preparation phase.  If we are not thinking about how to handle these situations within our environments then we are not going to be prepared.  As I stated before, this virus is nothing special in the grand scheme of malware.  Good security should limit, quickly contain, and eradicate an infection.   Not taking the affects of a virus such as this into consideration, however, is going to mean some long evening and weekend hours for the server and workstation administrators.  It also means that funds that could have been spent on increasing protections are going to be wasted on the clean-up effort.  Hopefully this put the bug into your ear and gives you a little information and methodology to help you educate others within your organization.

As I stated before, please leave a comment if you would like to add something.  Quick stories about how Virut affected your organization may help others understand what they could be up against.

Go forth and do good things,

Don C. Weber

I just updated the Scout Sniper page with a new release of the tool.  Actually, this tool was originally called Yara-Scout Sniper but I changed the name because of the new functionality that was added.

Scout Sniper now uses two different methods to detect suspicious files on a local or remote system(s).  The original functionality using the Yara Rules to locate malware files is still present.  Because of difficulties I ran into generating Yara Rule files to alert on Conficker/Downadup, I decided to try other methods to detect similar files.  I initially started looking into generating hashes for the PE file headers and sections but after some testing and recommendations from a few friends I fell back to using fuzzy hashing.  The new feature using Fuzzy Hashing functionality from the ssdeep project determines if any files are similar to a sample file provided by the user.

The tool has also been updated to provide copying and deletion capabilities.  Hense the Scout Sniper title.  Users can now copy or delete files that generate alerts.  Of course the delete functionality should be used with caution.

As usual, please provide me with any feedback, recommendations, or requests.  I would also be very happy to know how Scout Sniper is being used and any success or failure stories.

Go forth and do good things,

Don C. Weber

I have to say one thing for the rash of Conficker/Downadup infected systems that are plaguing businesses around the world:  This malware is helping the overall security of the Internet.

Once we are past this round of malware it will definitely be harder to propagate a mass infection.  Scoff if you will, but I am serious.  I admit that this worm is building a very large network of infected systems.  But for those businesses that are addressing this malware attack they are discovering the weaknesses within their infrastructures and response techniques.  The down-times associated with locked accounts, offline servers, disrupted services due to network traffic saturation, poorly implemented / broken patch management capabilities, broken backup procedures (BTW, are your backups infected?), etc are helping the information technology staff justify their recommendations to fix these issues.  Whether the recommendations were already in place or are now forth coming is really irrelevant.  The fact is that once businesses start adding up the costs associated with the response to this malware, executives should start taking notice of the potential return on investment (gasp, Securit ROI – opps, please don’t start THAT conversation AGAIN) of their network security and management technologies.

I am certainly not saying that after this malware tumbles off into the distance that there will not be another instance of a mass infection.  What I am saying is that because of the Conficker/Downadup malware, many organizations are going to be better prepared to avoid, limit, eradicate, and return to business as usual.  This will, in-turn, reduce the number of infected systems and the speed that new malware propagates across the Internet.  I wish I could also say that this will help other non-business computers such as those owned by schools, non-profit organizations, home-users, and [add your own choice here], but that is, unfortunately, just not the case.

One thing I can recommend is that IT staff and management take advantage of this situation and make their recommendations quickly with an emphasis on prioritization.  Recent disasters have shown how short lived memories associated with purchasing and implementing protections associated with business continuity and disaster recovery can be.  Determining which technologies will give you the most bang for your buck while also increasing your infrastructure’s preparedness with an emphasis on reducing the gap between an incident and the organization’s initial response is key.  Organize the rest of your list with these issues in mind.  Hopefully, you will get the number one priority on your list.  But if your list is not prioritized you may be stuck with a box of stuff that will leave you scratching your head and wondering how it is going to help future incident responses and general business requirements.

Go forth and do good things,

Don C. Weber

After reading about Yara in the Got Your Yara? post at Windows Incident Response I decided to try to see what I could do to make Yara portable.  To this end I have started the Yara – Scout Sniper project.

For those of you who are not familiar, Yara is a new project designed to help with the identification of malware.

YARA is a tool aimed at helping malware researchers to identify and classify malware samples. With YARA you can create descriptions of malware families based on textual or binary patterns contained on samples of those families. Each description consists of a set of strings and a Boolean expression which determines the its logic.

Yara – Scout Sniper (yara-ss) allows incident responders to use Yara’s malware identification techniques to reduce the amount of time it takes to identify and react to a malware infection within their environment.  Although incident responders and other members of the community still have to write the Yara Rule files to properly identify malware related files, yara-ss gives these people the capability of locally and remotely testing systems with these rule files.

There is still a lot of work that needs to go into this project.  The current version does not copy or deleted files that create alerts, but the capability is in the works.  The information that the tool outputs could use a little work.  And, as Harlan mentioned in his post, being able to use this to analyze system memory would be nice as well (although I think this will take me a bit longer than the copy/delete option).  It is also currently limited to a Windows version although if a *nix version is necessary then I may work on it although other feature might take precedence.  But, I figured that releasing this tools to see if it is useful was more important than continuing to dwell on some of its short-comings.

So, visit the Yara – Scout Sniper project page if you would like to take it for a test ride.

Please let me know your comments, recommendations, and requests.  If you do use this successfully please let us know by leaving a comment.

Go forth and do good things,

Don C. Weber

I have taken some time to write an incident response script using only the resources provided by the Windows operating system.  You can find out the why by reading the article I wrote titled Windows Incident Response With Only System Resources or the how by reviewing the code I wrote.  UPDATE: I broke the link when I did a bug fix.  So, this link may break in the future, please refer to the complete article for the most recent version.

I hope that some of you find this useful and that this centralizes a lot of the information necessary to understand the abilities inherent to the Windows operating system.  It is nothing ground breaking.  Just a few things that can be done if you do not have or are not allowed to obtain and use the number of very useful tools that are available online or through a vendor.

Go forth and do good things,

Don C. Weber

wmi, wmic, vbscript, Security Ripcord, incident response