Count Upon Security

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

Oct 20 2015

Course Review: SANS FOR578 Cyber Threat Intelligence

Image retrieved from lockheedmartin.com

Last week I had the opportunity to attend SANS DFIR Prague where I completed the SANS FOR578 course “Cyber Threat Intelligence” (CTI) with Robert M. Lee. Robert is one of the co-authors of the course and is brilliant instructor that really knows his stuff. Everything stands or falls with the quality of the instructor and I believe Robert did give us (students) a great learning experience with great interactions and discussions. Among other things Robert is the CEO of the security company Dragos Security and has worked in the US Air Force which allows him to talk genuinely about the “intelligence” topic.

Overall this was a five day course that immerses the student into the new and emerging field of CTI. During the five days we lived, ate and breathed being a CTI analyst. Being a CTI professional is not an easy task and it’s not in five days that you can expect to become one. However, in my opinion, if someone has the desire, as well as the ability, this course can give you the means. I’m sure this course gave me important skills and competencies about this new, emerging field. One key take away from the training is that it gives you the foundations to create a threat Intel capability into your organization and enables security personnel to develop more proactive and mature response practices against threats and move defenses higher up the kill chain.

The first day is a comprehensive introduction to the new Cyber Threat Intelligence (CTI) domain, with a wide range of topics and terminology being covered. What is threat intelligence? Why should organizations adopt it? What is the value? What is the difference between a consumer and a producer of CTI? What are the different types of CTI? In addition, background on the intelligence doctrine and its life cycle is also discussed. The afternoon was spent on the different frameworks and models that you can use to create consistent and repeatable CTI outputs. The Kill Chain, Diamond Model, Courses of Action Matrix and the Detection Maturity Model were the ones most covered.

Day two was all about enforcing the models presented in day one with special focus on the Kill Chain model. Lots of exercises supported by a network intrusion scenario where we (students) needed to perform different tasks to put in practice the theory from day one. The way the intrusion attributes, properties and artifacts are mapped to the Kill Chain, Diamond Model and Courses of Action were really useful. Because the frameworks discussed are complementary they can be combined in order to produce multi-dimensional analysis of the intrusion. I think this multi-dimensional approach to intrusions gives great insight about the adversary. Although a time consuming exercise it was great to get a feeling about what a CTI analyst might do in a organization with high security risk that need to have mature and dedicated teams to perform this type of work.

By leveraging the intelligence gained overtime during the analysis of multiple intrusions we start to get an understanding about commonalities and overlapping indicators. Mapping these commonalities and indicators to the intrusion kill chain and diamond model results in a structural way to analyze multiple intrusions. By repeating this process we could characterize intruders activity by determine the tactics, techniques and procedures on how the attackers operate i.e., perform a campaign analysis. This was day three. A meticulous work that is built over time and needs great amount of support from your organization but after execution it will produce great insight about the adversary. In terms of tools, the exercises relied heavily on Excel and the fantastic and open source Maltego.

Day four was focused on the different collection, sharing and ingestion methods of threat intelligence. The primary method of collection discussed was trough threat feeds. Other collection methods such as OSINT and threat Intel produced inside the organization or received trough circles of trust were also discussed. For sharing, a key take away is that partners with strong non disclosure agreements are very efficient. Still, in the sharing realm delivering context is crucial in order to make it actionable. Furthermore, we discussed the roles of the different ISAC and other organizations. Regarding the ingestion, the material has very good coverage on the different standards and protocols that have been developed in recent years to collect share and consume technical information in an automated way. The focus was on STIX, TAXII. We also reviewed other methods and standards such as OpenIOC and Yara rules. In regards to the tools and exercises we had the chance to play with Recorded Future and Threat Connect and and develop OpenIOC and Yara rules. SANS posture overtime has been always vendor neutral but I must say the Recorded Future demo for OSINT is well worth and the tool is really amazing!

The material on day five is more abstract. Special focus on how people – analysts – make conclusions. For example we discussed the difference between observations and interpretations and how to construct assessments. Great amount of material about cognitive biases and how it might influences the work performed by an analyst. During this day we were also exposed to the analysis of competing hypotheses (ACH) methodology by former CIA analyst Richards J Heuer, Jr. The exercises were really interesting because we had to evaluate hypotheses against the evidences we found during the intrusion analysis of the different scenarios. By the end of the day we immersed into the topic of attribution and discussion about nation state capabilities and the different cases that have been known in the industry.

Of course apart of the training, was great to attend the DFIR Summit, absorb information, play DIFR NetWars and more important meet new people, share experiences and see good old friends!

Tagged courses of action, cyber kill chain, diamond model, Incident Response, intrusion analysis, Security Intelligence, Threat Intelligence

Oct 13 2015

6 Comments

Incident Handling and Hacker Techniques, Malware Analysis

Malicious Office Document delivering Dyre

Phishing campaigns that distribute commodity malware are common and ongoing problem for end users and corporations. In this article would like give you an illustration about one email that was part of a phishing campaign that distributes a very successful banking trojan malware known as Dyre or Dyreza. This trojan is quite sophisticated. Among other things 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. Dyre has remote access functionality that allows the threat actor to connect to websites trough the victim computer.

The distribution methods observed is the past are mainly done using phishing emails that include a malicious Microsoft Office document attached. It normally includes a Microsoft Word or Excel document with macros. The image below illustrates one of these samples where the sender falsely mimics a legitimate business transaction. This well-crafted email attempts to lure the recipient into opening the malicious attachment.

Noteworthy is that the threat actors behind the malware distribution operations go to great lengths ensuring the files are not detected as malicious by the different security mechanism such as Anti-Spam, Anti-Virus and Sandboxes. Is quite normal when submitting this malicious Office documents to Virus Total to have less than 10% detection rate and being rated benign by Sandboxes.In this example as seen in the picture below, the user when opening the email attachment is presented with the information that the document is encrypted with RSA algorithm and the user needs to enable macros in order to see its content.

The document is of course not encrypted and this is a social engineering technique to trick the users to run the malicious macro. Allowing macros to run causes the malware to be extracted and executed in the victim system.

So what makes this document different than the others recently seen? The difference is in the weaponization mechanism that was used. Traditionally, these malicious Office documents have encoded and obfuscated macros. These macros when executed will connect to a site and download the malicious executable. However, in this case the document contains an obfuscated macro but the executable is embedded within the document. This reduces the steps needed for infection and might increase the infection rate.

What tools and techniques one could use to unravel what is inside the document?

For malicious document analysis, REMnux and the cheat sheet created by Lenny Zeltser are a fantastic companion. On REMnux v6 one of the new tools pre-installed is the python-oletools toolkit. This toolkit was created by Philippe Lagadec based on the work created by John William Davison on officeparser. The tool among other things can parse and extract VBA Macros from Microsoft Office documents. It supports a variety of Microsoft Office documents and it can be very handy for this type of malicious documents. We start with the usage of olemeta.py to view the document metadata. In this case we could see codepage 1252 which might indicate where the document was fabricated. Then we run oleid.py which gives us a very good overview about the capabilities inside the document. In this case we could observe that the document contain VBA macros and OLE embeded objects. These indicators definitely need a deeper look.

We start by looking at the VBA macro. The following picture illustrates the output given by olevba.py after analyzing the malicious Office document. It shows the actual macro and one could see that is obfuscated. In addition the tool gives its interpretation of the different functions used in the macro. Many of the functions used are considered suspicious.

Based on this information we can see that the document contains a obfuscated VBA macro that presumably creates RTF files (300.rtf and 301.rtf) and extracts an executable called n1.exe.

To further dig into these artifacts we will use another great tool. Oledump created by Didier Stevens. This tool allows you to analyze OLE files. As stated in the manual page: “Many file formats are in fact OLE files, like Microsoft Office files, MSI files. Even the new Microsoft Office Open XML format uses OLE files for VBA macros”. Another powerful tool created by Didier that even supports decoders and plugins such as Yara rules. One of the Yara rules is based on the work made on OfficeMalscanner by Frank Boldewin that can find shelcode, PE-files and other embedded streams inside Office documents.

To verify our suspicious we use oledump.py with a yara rule that detects the presence of PE files inside documents. The output confirms that an executable was found inside the document.

We can now extract the executable. The stream that triggered the Yara rule is the stream 11. Once again using oledump.py we can extract the binary and redirected to a file for further analysis.

With the executable extracted we can now start using static and dynamic analysis techniques to determine the malware capabilities and extract IOCs that can be used to across our logs and network to find infected systems. This will be left for another blog post.

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.

MD5 of the files used in this exercise:
Evil.doc : dd3cd493aa68f55d1df442873ad2b2e8
Evil.bin : 27079661fb498dcf18194f45a4171492

Tagged Dyre, Malicious Office Document, oledump, oletools, REMnux