November | 2015 | Count Upon Security

Nov 30 2015

Dridex Black Friday

Last October different law enforcement agencies orchestrated a takedown of the Dridex Botnet. However, the threat actors behind Dridex spam runs seem stronger than ever. The resurrection of Dridex after the announced take down has been ferocious. During the last Black Friday in our spam traps we observed at least four different phishing campaigns delivering Dridex. Each campaign was carefully crafted in order to lure the users to open the malicious documents. The creativity of the threat actors is captivating. The below picture illustrates one of these emails that is supposedly sent from the well-known rent-a-car company AVIS. The email contains a Microsoft Office document attached that contains malicious macros on it.

Another one was an email supposedly sent from Bruce Sharpe from the Industrial Pump Supplier Aline Pumps in Australia. According to the social network zoominfo Bruce Sharpe exists and is an account manager in the company. The subject was Tax Invoice and once again the email contained a Microsoft Office document attached with malicious macros.Other one was an email sent from Ivan Jarman from SportSafe UK. The company is a global provider of sports equipment. This time the subject was Invoice and the email contained a Microsoft Office document attached with malicious macros. The last one was an email from the company Integrated Petroleum Services. According to the website one key location is Equatorial Guinea and the emails supposedly come from there. The subject this time was Transfer and the email contained a Microsoft Office document attached with malicious macros. As bonus the footer will mention the email has been scanned by the Antivirus AVAST. All documents use the same technique. Attract the user to enable macros in order to view the document contents.

Across all the campaigns the technique is the same. All the Microsoft Office documents contain embedded macros that download a malicious executable from one of many hard coded URLs. These hard coded URLs are normally collateral victims of the operation. The encoding and obfuscation techniques used in the macros are constantly changing in order to bypass security controls.

Normally these URLs are hosted under legitimate sites that have been compromised to host the malicious file. When the macro is executed it will fetch a second stage payload from the compromised server. This payload is then saved to C:\Users\%%username\AppData\Local\Temp and then executed.

After the machine gets infected Dridex will start beaconing out to the C2 addresses. Dridex uses HTTP to encapsulate the traffic and encrypts the payload. Below an example how the first HTTP POST request made by the infected machine looks like in the network. A POST to the root folder full of gibberish.

From this moment onward the malware is capable of stealing all kinds of credentials from the victim’s computer. It can also redirect victim’s traffic to sites controlled by the threat actors using man-in-the-browser functionality. This allows interception and manipulation of traffic that is supposed to be delivered to legitimate sites. Dridex has remote access functionality that allows the threat actor to connect to websites trough the victim computer.

Phishing campaigns that distribute commodity malware are common and ongoing problem for end users and corporations.E-mail continues to be the weapon of choice for mass delivering malware. The tools and techniques used by attackers continue to evolve and bypass all the security controls in place. From a defense perspective, the US-CERT put together excellent tips for detecting and preventing this type of malware and to avoid scams and phishing attempts applicable to home users and corporations.

Tagged Banking Trojan, botnet, Dridex, Phishing Campaigns

Nov 25 2015

1 Comment

Digital Forensics and Incident Response

Digital Forensics – SuperTimeline & Event Logs – Part II

Following part I where we wrote about tools to parse and read Windows Event Logs we will start analyzing our Super Timeline. First we start by filtering out the Super Timeline in Excel and look at WinEVTX artifacts and their meaning. To be able to find interesting events we need to have a good understanding about the different Event ID’s. This will be the main focus of this article.

In this exercise the system had Remote Desktop Administration service enable and after some event it was generating a huge amount of traffic on TCP port 3389 which might indicate that was compromise somehow. That being written we will start by looking at the Event IDs that indicate that someone logged in into the system. Security Event Logs and Terminal Service Logs can aid our quest. The following files and ID’s would be of interest:

Microsoft-Windows-TerminalServices-LocalSessionManager
Event ID 21 : Shell start notification received
Event ID 23 : Session logoff succeeded
Event ID 24 : Session has been disconnected

Microsoft-Windows-TerminalServices-RemoteConnectionManager
Event ID 1149 : User authentication succeeded

Microsoft-Windows-Security-Auditing Computer
Event ID 4624 : An account was successfully logged on.
Event ID 4625 : An account failed to log on

The image below shows some of this events in our Super Timeline. Clearly, someone logged on into our system!

When looking into the different Event ID’s is important to review its contents. For example, in the ID 4624 there is a huge amount of information about the logon event. Information such as the User Name, Domain, Logon ID and Logon Type, Authentication Package, Source Network Address will give you more context when looking for malicious activities. One important field in the Event ID 4624 is the Logon Type. This is a code that states how the logon was performed. In this case the Logon Type is 10 which means the long was performed via Remote Desktop. The table below lists the different logon types and a brief description. This information is available on Microsoft Technet and MSDN.

Note: From a Incident Response perspective, in Active Directory environments where the logging is centralized the logon types can be very useful when you are filtering out Event ID’s. In addition if you combine this filtering with the different Authentication Packages and the NTLM or Kerberos Error Codes you start finding interesting things in your domain.

For this exercise we know that we had Audit Process Tracking enable because of the PolAdtEv settings. Most often this audit setting is not enable due to the large amount of logs that it generates. However from a security point of view it can be very useful. One of the Event IDs recorded with Audit Process Tracking is the Event ID 4688 that keeps record of every process that starts in the system. Apart of the path, process that was executed, associated account and others it contains information about Token Elevation Type. This can be useful to determine if the user has been prompted for elevation of privileges using the UAC prompt. The majority of events recorded with this ID are background process as part of normal windows activity. However, a good indication of when someone logged into the system is the well known sequence of processes (smss.exe, csrss.exe, winlogon.exe, logonui.exe). This piece of evidence corroborates the other Event ID’s about someone logging in into the system

Another set of relevant Event ID’s from a security perspective its the Service Operation ones. Actions performed by malicious actors often include interaction with services in order to compromise the system or achieve persistence. For example, the usage of Metasploit PsExec module is a good example of a tool that interacts with services and leaves traces on the Event Logs under Service Control Manager category. To look at service operations events the System Event log is the one we want to look at. Some of the interesting Event ID’s are:

7030 – The service is marked as an interactive service. However, the system is configured to not allow interactive services. This service may not function properly.
7035 – The %1 service was successfully sent a %2 control.
7036 – The %1 service entered the %2 state.
7040 – The start type of the %1 service was changed from %2 to %3.
7023 – The %1 service terminated with the following error: %2
7045 – New Service was installed

The Event 7045 is a new event ID introduced in Windows 7 and 2008 R2. When a new service is installed in the system this event gets recorded. Please note that a malicious actor can also create services by editing the registry directly and this will not create an event 7045.

Of course in large environments you might have a broken application or mis-configured services but normally the services do not fail. If a service fails, then it might be interesting to look at it. This might indicate that an attacker or a piece of malware is targeting the service.

The image below shows some of this events in our Super Timeline moments after someone logged on into our system. A system service changed to interactive and was then “svchosted” by the user Administrator. Following that it crashed and then it entered into stop state.

Before we continue lets review the concept behind “svchosted” services. On Microsoft Operating Systems more and more services are turned off by default in order to reduce the attack surface. However, the Windows services continue to be a preferential choice of malware in order to achieve persistence. Microsoft has the concept of shared services in order to reduce resource consumption. This concept is materialized in the form of a service called svchost.exe. This service provides a hosting framework to launch multiple services using only one process. By using this technique multiple services are combined in service groups as long as they have the same privilege requirements. This what we called “svchosted” services. The list of groups can been seen in the Registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost.

When services are “svchosted” they are loaded trough a DLL. This can been seen on Windows Taskmanager in the Services tab or using the command line and typing tasklist /svc. When services are installed on Windows they are recorded under the registry HKLM\SYSTEM\CurrentControlSet\Services key. For each service that is listed there are two relevant subkeys from a security perspective. One is the ImagePath and another one is the ServiceDLL. Both keys are often abused by malware to load and achieve persistence. The ImagePath for a service that is “svchosted” is always %SystemRoot%\system32\svchost.exe. If the path or binary is something else than is worth investigate. The ServiceDLL value is under the Parameter Key and it points to the DLL that is going to be loaded by the service. This key needs to point to a benign DLL.

By looking at the different Event Log ID’s across our timeline we could find suspicious activities that are worth to further investigation. In this case we have someone who logged in as Administrator via Remote Desktop and we have a Service that was installed and crashed. Which artifacts should we look next? Based on the time that these events occurred we will look into other artifacts in our Super Timeline around this time frame. A closer look at the service that crashed and other artifacts that have a temporal proximity with our findings will be the topics of the upcoming posts.

That’s it. We reviewed some of the events that were generated by the system in regards to Account Logon events and Service Operations. These were relevant for this exercise. However, other events could be important depending on what you are investigating. Because Windows Operating Systems have an enormous amount of different event logs and looking at them might sound a daunting task we need supporting material. Good references that can help us understanding different Event ID’s and support our investigations while looking at Super Timelines or doing investigations are listed below.

A list of all security audit events for Microsoft operating systems can be retrieved from the following links:
Windows Server 2003
Windows Vista and Server 2008
Windows 7 and Server 2008 R2

The paper “Spotting the Adversary with Windows Event Log Monitoring” published by NSA. Furthermore, the “Threats and Countermeasures Guide: Security Settings in Windows 7 and Windows Server 2008 R2” and the old but still relevant “The Security Monitoring and Attack Detection Planning Guide” paper from Microsoft also provide comprehensive material. Other good resource is the Windows Logon Forensics paper from Sunil Gupta and the Windows Logging Cheat Sheet created by Malware Archaeology.

References:

Russinovich, M. E., Solomon, D. A., & Ionescu, A. (2012). Windows internals: Part 1
Russinovich, M. E., Solomon, D. A., & Ionescu, A. (2012). Windows internals: Part 2
Luttgens, J., Pepe, M., Mandia, K. (2014) Incident Response & Computer Forensics, 3rd Edition

Tagged Account Usage, Digital Forensics, Event Logs, intrusion analysis, scvhost.exe, Service Host Services, ServiceDLL, WinEVTX. Super Timeline

Nov 23 2015

3 Comments

Digital Forensics and Incident Response

Digital Forensics – SuperTimeline & Event Logs – Part I

In these series of articles about performing file system forensics on a Windows system we covered the evidence acquisition in the first article. The second article was about processing the evidence and creating a timeline of the NTFS metadata. The one below will be split in two parts and will cover the analysis of a Super Timeline and the different artifacts. The main focus will be on parsing and analyzing Windows Event Logs.

In this article we will not cover the creation of the super timeline because has been covered already in this article using Plaso engine. We will move on directly to the analysis and artifacts.

For contextualization Plaso is a Python-based rewrite of the Perl-based log2timeline initially created by Kristinn Gudjonsson and enhanced by others. The creation of a super timeline is an easy process and it applies to different Microsoft Windows operating systems. However, the interpretation is hard. The Plaso engine is able to parse different type of artifacts such as Windows Event Logs, Windows Registry, Windows Prefetch files and many others. During the analysis it helps to be meticulous, patience and it facilitates if you have comprehensive file systems, operating system artifacts and registry knowledge.

One thing that facilitates the analysis of a Super Timeline is to have some kind of lead about when the event did happen. Then you start to reduce the time frame of Super Timeline and narrowing it down. Essentially we will be looking for artifacts of interest that have a temporal proximity with the event. The goal is to be able to recreate what happen based on the different artifacts.

A good starting point is looking at the different Windows Event Logs that were recorded in the Super Timeline. But before we dig into our Super Timeline and the WinETX artifacts let’s review some concepts about the Windows Event Logs.

The Windows Event Logs are a good source of information when looking for potential attacks or misuse of the system. The Windows Event Logs include all the records that are a result of the enforced auditing policy i.e., the amount of information is dependent on the Audit Policy settings. For example on a standalone Windows 7 default installation the Audit Policies state that there is no auditing. This can been seen in the local group policy settings as you could see in the below image.

However, there is some auditing enable and you could verify it using the command line auditpol.exe tool. The below picture shows the auditpol.exe output in the same Windows installation from where the group policy stated that there was no auditing enable. This inconsistency is describe by Microsoft here.

From Windows Vista onwards the Windows Event Logs are stored in the %SystemRoot%\System32\Winevt\Logs folder and contain a .EVTX extension. This new format called Windows XML Event Log (EVTX) format super seeds the EVT format used in Windows XP. Apart of Event Logs from Vista onward there are Application and Service logs that record events about a particular component or application rather then system. On a Windows 7/2008 System many event log files can be found depending on the roles performed by the system. In here you can even find application event logs. For example if the system has Symantec Endpoint you will have a “Symantec Endpoint Protection Client.evtx” file. The different categories are described here. Nonetheless, there are three important files. The description was taken from Microsoft Technet website.

Application.evtx – “The Application log contains events logged by applications or programs. For example, a database program might record a file error in the application log. Program developers decide which events to log.”

System.evtx – “The Security log contains events such as valid and invalid logon attempts, as well as events related to resource use, such as creating, opening, or deleting files or other objects. Administrators can specify what events are recorded in the security log. For example, if you have enabled logon auditing, attempts to log on to the system are recorded in the security log.”

Security.evtx – “The System log contains events logged by Windows system components. For example, the failure of a driver or other system component to load during startup is recorded in the system log. The event types logged by system components are predetermined by Windows.”

To be able to parse and read these files there are good open source tools available. The work pioneered by Andreas Schuster in 2007 and afterwards by Joachim Metz on Libevtx were key to develop this capability.

One tool is the Plaso engine but that we already covered in another post. Another is the Python-evtx created by Willi Ballenthin. This tool written in Python has the ability to read the EVTX format. The tool is available on Github and contains different modules. One is the evtxdump.py that allows us to dump the contests of the Event Log files. The following picture shows the installation and a simple usage of this tool in the SIFT workstation.

Other than using open source tools you can also use Windows Event Log Parser from TZworks. Or you can use the native Microsoft tools. For example using the Windows GUI and use Event Viewer or you could use Windows CLI and use wevtutil.exe. Another option is the versatile Microsoft Log Parser.

The below pictures illustrates an example where we map a network drive to point to our evidence that is mounted on the SIFT workstation. Then we use wevutil.exe to query the Event Logs. First example with no filter and second example with a XML filter that was created using the Windows Event Viewer.

Please note that in this exercise the Security.evtx contains logon events because the system is not part of a Active Directory Domain. If that was the case the logon events will be recorded on the Domain Controllers.

Now, that we briefly covered the Windows Event Logs let’s review Audit Policy Settings. This is important because will allow us to to know what to expect on the Event Logs. The Audit Policy Settings control which events will be recorded on the Event Logs.

To be able to read the Audit Policy settings we need to read a special Registry key. At the time of this writing I could not find an open source tool that allowed us to retrieve these settings from a forensic image. The Audit Policy settings are stored in the registry under the HKEY_LOCAL_MACHINE\Security\Policy\PolAdtEv key. RegRipper is able to parse and output the contents of this key on Windows XP but seems to have issues on Windows 7 as you could on the below image. Nonetheless, it can retrieve the contents of the key. By having the contents of the registry key we can use the paper created by Teru Yamazaki that describes the structure of this key on newer Microsoft operating systems. With the information we can understand which audit settings are defined. The below image illustrates a manual mapping between the different events and the possible settings.

Teru Yamazaki also has an online tool on his website that allows you to parse this information automatically. You can get the audit policy from the SECURITY registry file using RegRipper and paste the contents into his tool. The output will be in Japanese but you can use Google Translator. In this exercise as seen by the Audit Policy settings we have Success and Failure turned on for all the event types.

Now that we know which kind of auditing settings we can expect and we reviewed some of the tools we could use to read the Event Logs we can start analyzing our Super Timeline and WinEVTX artifacts. This will be done on part II.

Tagged Audit Policy, auditpol.exe, Digital Forenics, log2timeline, PolAdtEv, Python-evtx, super timeline, Windows Event Logs, WinEVTX

Nov 10 2015

1 Comment

Digital Forensics and Incident Response

Digital Forensics – NTFS Metadata Timeline Creation

[This is my second post on a series of articles that I would like to cover different tools and techniques to perform file system forensics of a Windows system. The first article was about acquiring a disk image in Expert Witness Format and then mount it using the SIFT workstation. The below one will be about processing the disk image and creating a timeline from the NTFS metadata. LR]

After evidence acquisition, you normally start your forensics analysis and investigation by doing a timeline analysis. This is a crucial step and very useful because it includes information on when files were modified, accessed, changed and created in a human readable format, known as MAC time evidence. This activity helps finding the particular time an event took place and in which order. Different techniques and tools exist to create timelines. In recent years an approach known as super timeline is very popular due to ability to bring together different sources of data. However, in this article we will focus on creating a timeline from a single source. The Master File Table file.

Before we move to the hand-on exercise let’s review some concepts behind the Master File Table. The Master File Table is a special system file that resides on the root of every NTFS partition. This file contains a wealth of forensic evidence. The file is named $MFT and is not accessible via user mode API’s but can been seen when you have raw access to the disk e.g, forensic image. This special file contains entries for every file and directory including itself. As written by Brian Carrier the MFT is the heart of NTFS. Each entry of the $MFT contains a series of attributes about a file, directory and indicates where it resides on the physical disk and if is active or inactive. The active/inactive attribute is the flag that tracks deleted files. If a file gets deleted, its MFT record becomes inactive and is ready for reuse. The size of these entries are usually 1Kb. Because each record doesn’t fill 1Kb each entry contains an attribute stating if contains resident data or not. Due to file system optimization, NTFS might store files directly on MFT records. A good example of this are Internet cookie files. Microsoft reserves the first 16 MFT entries for special metadata files. These entries point to a special file that begins with $. The $Bitmap and $LogFile are examples of such files. A list of the first MFT entries are shown in the below picture. As well, it shows how to read the MFT record of a disk image on SIFT workstation using istat. The 0 at the end of the command is the record number you want to read for this partition that starts at offset 206848. The record 0 is the $MFT file itself.

Each record contains a set of attributes. Some of the most important attributes in a MFT entry are the $STANDART_INFORMATION, $FILENAME and $DATA. The first two are rather important because among other things they contain the file time stamps. Each MFT entry for a given file or directory will contain 8 time stamps. 4 in the $STANDARD_INFORMATION and another 4 in the $FILENAME. These time stamps are known as MACE.

M – Modified : When the contents of a file were last changed.
A – Accessed : When the contents of a file were accessed/read.
C – Created : When the file was created.
E – Entry Modified : When the MFT record associated with the file changed.

For our exercise, this small introduction will suffice. Please see the references for great books on NTFS.

Now that we have reviewed some initial concepts on MFT let’s move to our hands-on exercise. For this exercise we will need the SIFT workstation with our evidence mounted – this was done on previous article. Then we need a Windows machine where we will access the mounted evidence on the SIFT workstation using a network drive. Finally, we will need the Mft2Csv tool from Joakim Schicht on the Windows machine to read, parse and produce the MFT timeline.

To start we share the mounted evidence on our SIFT workstation. In this case its /mnt/windows1 and was mounted on previous article. To perform this we edit the smb.conf and we add the lines as shown in the below figure. Then we restart the SMB deamon.

Next, from your windows machine, which needs to be in the same network segment as your SIFT workstation. you can view the shares by using the net view command. Then using the net use command you can map a drive letter. With this step on our Windows machine we will have access to our mounted evidence over the Z: drive. Next step is to run Mft2Csv tool. Mft2Csv is a powerful and granular tool developed by Joakim Schicht. For those who are not familiar with Joakim Schicht, he is a brilliant engineer who has enormously contributed to the Forensics community with many powerful tools.The tool has the ability to read $MFT from a variety of sources, including live system acquisition. It runs on Windows and has GUI and CLI capabilities and needs admin rights. The tool can be downloaded from here. As we speak the last version is v2.0.0.33. In this case, we will launch it from our Windows machine. The command line parameters define from where you are reading the $MFT file and the Time zone. The output by default will be saved in a CSV format but could be saved in a log2timeline or bodyfile. If you are familiar with the log2timeline format than you could use /OutputFormat:l2t. Below picture illustrate this step. The command executed is Mft2Csv.exe /MftFile:Z:\$MFT /TimeZone:0.00 /OutputFormat:l2t
When the command is finished you can open the timeline in Excel or copy it to SIFT workstation and use grep, awk and sed to review the entries. Another approach to create a timeline of the MFT metadata is using an old version of log2timeline which is still available on the SIFT workstation. This old version has a MFT parser. You can use log2timeline directly on the mounted evidence. First we capture the Time Zone information from the mounted evidence using Registry Ripper – which we will cover on another post. Then we run log2timeline with -f MFT suffix to read and parse the $MFT file. The -z defines the time zone and the -m is a marker that will show prepended to the output of the filenames.

Or if you don’t have the evidence mounted you can export the $MFT using icat from TheSleuthKit.

Below picture illustrates the output of both tools using the l2t format. In this case the cache.txt is an executable file part of a system that has been compromised with w32.morto worm.

That’s it! In this article we reviewed some introductory concepts about the Master File Table and we used Mft2Csv and Log2timeline to read, parse and create a timeline of it. The techniques and tools are not new. However, they are relevant and used in today’s digital forensic analysis. Next step, review more NTFS metadata.

References:

https://github.com/jschicht/Mft2Csv/wiki/Mft2Csv
Windows Internals, Sixth Edition, Part 2 By: Mark E. Russinovich, David A. Solomon, and Alex Ionescu
File System Forensic Analysis By: Brian Carrier
SANS 508 – Advanced Computer Forensics and Incident Response

Tagged $MFT, log2timeline, Metadata Timeline, MFT Timeline, Mft2Csv, NTFS Metadata, NTFS Timeline, Sift Workstation

Nov 09 2015

Digital Forensics – Evidence Acquisition and EWF Mounting

[This is my first post on a series of articles that I would like to cover different tools and techniques to perform file system forensics of a Windows system. First article is about acquiring a disk image in Expert Witness Format and then mounting it using the SIFT workstation. LR]

Let’s look at an hands-on scenario to create a forensic image from a compromised system. To acquire the disk we will boot the system from a CD/USB using Helix and then run ewfacquire. Ewfacquire is a tool that allows us to acquire media and stored it in Expert Witness Format. Essentially, it can acquire media in an equivalent format that commercial tools like EnCase and FTK imager do. EWF format is very popular due to the market penetration of Guidance Software and their Encase Suite. The EWF format also know as Encase evidence files (E01) are a representation of the acquired physical or logical drive. Plus they support metadata, the evidence hash value, compression and file splitting. These features are very convenient.

Ewfacquire is simple and flexible tool that is part of the LibEWF package that contains many other great forensic tools written by Joachim Metz. It is launched using the command line and is preinstalled in Linux distributions like Helix and SIFT Workstation. In this case we will run use Helix. Helix product went commercial but you can still download the free 2009R3 version.

Frist step is boot the compromised system with a CD/USB using Helix. Then we will plug the pristine media where we will store the evidence and mount it. Following that we launch ewfaquire. On a previous post I wrote about the first two steps.

In this exercise we will concentrate on ewfaquire. We can see the source and destination devices by running fdisk -lu. Then we know which drive will be the source and the destination. In this case the source drive is /dev/sda. We then start the acquiring process by launching the ewfacquire tool with source drive as option and a set of questions will be raised. Below picture ilustrate this steps. The values are self explanatory. In this case we are aquiring a physical disk using the best compression method in EWF format. After entering the default values which are good enough for the majority of the case were are asked to review the settings and then proceed. The process will take some time depending on factors like disk size and compression method. When finish the evidence hash value is presented. All this information is stored in the metadata and can be reviewed afterwards with ewfinfo.

After the acquire process is finish we will have a bunch of .E## files in our target media. Next step is to move them to our SIFT workstation and process the image.

This will take three steps. First we mount the EWF files using mount_ewf.py, then we get the partition layout using mmls and finally we run the mount command. Mount_ewf.py is a script written in Python by David Loveall and available in SIFT workstation that allows us to read the evidence in EWF format and prepare it in a way that can be mounted. Then we use mmls from thesleuthkit written by Brian Carrier to display the partition layout of the physical disk we acquire. With mmls we find the starting sector for each one of the NTFS partitions and we use that value in the mount command. Finally, we use the mount command for each partition we want to mount.

In the mount command we have different flags. The loop suffix allows us to mount disk images. The ro is to ensure we mount the evidence in read only. The show_sys_files is important if we want to see the NTFS metadata. Then the stream_interface=windows is used in order to be able to read data streams such ADS. Finally, the offset is calculated by multiplying the starting sector with the amount of units we have per sector (a.ka. bytes per cluster). The following image illustrate these steps.

After mounting the different partitions into /mnt/windows folder we can see their contents. Because we mount it with the show_sys_files option. we can see the different NTFS metadata files that start with $.

That’s it! The techniques and tools are not new. However, the tools are open source and the techniques are relevant and used in today’s digital forensic analysis. Next step, produce a forensic timeline!

Tagged dead-box analysis, ewfacquire, ewinfo, Helix, mount E01 images, Sift Workstation

Nov 07 2015

1 Comment

Incident Handling and Hacker Techniques

CryptoWall Strikes Back!

A new variant of Cryptowall ransomware has been observed in recent phishing campaigns by the security community. The image below illustrates one of these emails where the sender falsely states that your domain name is going to be suspended due to abuse policy. This email attempt to lure the recipient into clicking into the link.

The link points to a compromised web server using a scheme like http://www.site.com/abuse.php?domain.com

When clicking on the link the HTTP answer uses a Content-Disposition field. Using this technique the answer to the PHP request will be a file. Download of content like executables is does not need this field but in this way the malware authors attempt to camouflage the file in the GET request.

When executed, CryptoWall uses several memory management techniques to inject into benign processes. It starts by making a copy of itself and then invoking a new explorer.exe process which by its turn will invoke a new svchost.exe. These two new processes (see below figure) are valid process initiated using the legitimate system binary but have been injected with malicious code using hollowing technique. Svchost.exe in this case is invoked “-k netsvcs” but the process parent is not services.exe which should always be the case.

Before the encryption starts, it will execute three commands that will make recovery of files even more difficult. It starts by deleting all Volume Shadow Copies that exists on the system by running the following command:

vssadmin.exe Delete Shadows /All /Quiet

Then runs the following commands in order to disable the Windows Error Recovery during startup:

bcdedit /set {default} recoveryenabled No
bcdedit /set {default} bootstatuspolicy ignoreallfailures

To achieve persistence, a copy of the malware is placed into a directory named with a random hexadecimal number under c:\. The Hidden attribute is set to the folder. Inside will store the malicious executable using a an equal filename e.g., c:\826a933e\826a933e.exe. It addition another copy of the malware is placed into the directory %APPDATA%\Roaming. Then it creates a Run key under HKLM or HKCU registry hive (depending on the admin rights) that points to this executable. This will make sure the executable is launched either during boot or during user login.

CryptoWall then starts its communications and will determine the victim public IP address and its geo-location using sites like curlmyip.com, myexternalip.com and ip-addr.es. Following that will try to reach out one of the many C&C addresses that are hard-coded into the binary.

The following picture illustrates the messages that are sent over HTTP on TCP port 80.

After the encryption process is finished the user is presented with the ransom messages. For each folder that CryptoWall processes it will leave its ransom note on the following files HELP_YOUR_FILES.HTML, HELP_YOUR_FILES.PNG, HELP_YOUR_FILES.TXT. One example is below.

If the user follows the ransom note instructions he will be redirected to the decryption service and is prompted to pay in Bitcoins. The decryption service will allow to decrypt one file for free.

What can you do? The most effective defense against these type of threats is to have proper backups. This type of malware has the capability to encrypt any attached storage such as USB drives or network drives – make sure you do your backups and keep that external drive disconnected. You back up your data once a day, right? at least weekly? maybe monthly? For enterprises the tools and processes used to backup and restore information in a timely manner need to be in place. Please note that Windows has a feature called Volume Shadow Copy that allows you to restore files to their previous state however the newer variants of this malware delete shadow copies and disable the service prior to encrypting the files.

Other things can be done, like educating users to not open attachments or links in emails from unknown senders and be suspicious about unexpected attachments and links from known senders. Also make sure to keep your software updated. Other techniques might include hardening your system using Microsoft AppLocker to introduce software whiltelisting.

MD5 of the malware used in this article:
3548959f1100a0d818f91b6502a7fdd3 ab-cp.com_copy_of_complaints.pdf.scr

At this stage the majority of the web filtering vendors have categorized the C&C addresses as malicious. This will prevent an infected computer from becoming encrypted if you prevent your users to surf to malicious websites. For example the malicious binary used in this exercise had 58 C&C hard-coded.

Tagged CryptoWall

Count Upon Security

Increase security awareness. Promote, reinforce and learn security skills.

Monthly Archives: November 2015

Dridex Black Friday

Digital Forensics – SuperTimeline & Event Logs – Part II

Digital Forensics – SuperTimeline & Event Logs – Part I

Digital Forensics – NTFS Metadata Timeline Creation

Digital Forensics – Evidence Acquisition and EWF Mounting

CryptoWall Strikes Back!