Category Archives: Incident Handling and Hacker Techniques

Digital Forensics – ShimCache Artifacts

shimcacheFollowing our last article about the Prefetch artifacts we will now move into the Windows Registry. When conducting incident response and digital forensics on Windows operating systems one of the sources of evidence that is normally part of every investigation is the Windows Registry.  The Windows Registry is an important component of the OS and applications functionality, maintains many aspects of its configuration and plays a key role on its performance. As written by Jerry Honeycutt on his books the Windows Registry is the heart and soul of modern Windows operating systems. The Windows Registry is a topic for a book on its own, either from a systems or a forensics perspective. One great example is the book “Windows Registry Forensics 2nd Edition“ from Harlan Carvey.

In any case, from a forensics perspective, the Windows registry is a treasure trove of valuable artifacts. Among these artifacts you might be looking at System and Configuration Registry Keys, Common Auto-Run Registry Keys, User Hive Registry keys or the Application Compatibility Cache a.k.a. ShimCache.

In this article we will look into the Application Compatibility Cache a.k.a. ShimCache. When performing Live Response or dead box forensics on Windows operating systems one of the many artifacts that might be of interest when determining which files have been executed and were accessed is the ShimCache. In our last article we mentioned the Prefetch where you could get evidence about a specific file being executed on the system. However, on Windows Servers operating systems, the Prefetch is disabled by default. This means the ShimCache is a great alternative and also a valuable source of evidence.

Let’s start with some background about the ShimCache. Microsoft introduced the ShimCache in Windows 95 and it remains today a mechanism to ensure backward compatibility of older binaries into new versions of Microsoft operating systems. When new Microsoft operating systems are released some old and legacy application might break. To fix this Microsoft has the ShimCache which acts as a proxy layer between the old application and the new operating system. A good overview about what is the ShimCache is available on the Microsoft Blog on an article written by Tim Newton “Demystifying Shims – or – Using the App Compat Toolkit to make your old stuff work with your new stuff“.

The interesting part is that from a forensics perspective the ShimCache is valuable because the cache tracks metadata for binary that was executed and stores it in the ShimCache.  Nevertheless, it wasn’t until 2012 when Andrew Davis wrote ” Leveraging the Application Compatibility Cache in Forensic Investigations” and released the ShimCache Parser tool that the value of this evidence source came widely known. This was a novel paper because Andrew made available a tool that could extract from the registry information about the ShimCache that is valuable for an investigation.  The paper outlines the internals of the ShimCache and where the data resides on the different Windows operating systems.

On Windows XP this data structure is stored under the registry key HKLM\CurrentControlSet\Control\Session Manager\AppCompatibility\AppCompatCache. On recent Windows the ShimCache data is stored under the registry key  HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache

In the ShimCache we can obtain information about all executed binaries that have been executed in the system since it was rebooted and it tracks its size and the last modified date. In addition the ShimCache tracks executables that have not been executed but were browsed for example through explorer.exe. This makes a valuable source of evidence for example to track executables that were on the system but weren’t executed – consider an attacker that used a directory on a system to move around his toolkit.

On Windows XP the ShimCache maints up to 96 entries but on Windows 7 and earlier the ShimCache can maintain up to 1024 entries. Using the ShimCache Parser we can parse and view its contents. We only need to point to the SYSTEM registry hive file on our mounted evidence as illustrated below.

shimcache-parser

Nonetheless, the ShimCache as one drawback. The information is retained in memory and is only written to the registry when the system is shutdown. This impacts the ability of getting this source of evidence when conducting live response. To address this limitation Fred House, Claudiu Teodorescu, Andrew Davis wrote a Volatility plugin to read the ShimCache from memory. The plugin supports Windows XP SP2 through Windows 2012 R2 on both 32 and 64 bit architectures. This plugin won the volatility plugin contest of 2015. A write-up about it is available here and here. The plugin can be downloaded from the Volatility Community plugins page.  The picture below illustrates the usage of Volatility with the ShimCacheMem plugin against the memory of the analyzed system.

shimcache-volatility

By looking at the ShimCache either directly from memory or by querying the registry after system shutdown we can – in this case – confirm the evidence found in the Prefetch artifacts. On a Windows Server system because by default the Prefetch is disabled the ShimCache becomes a more valuable artifact.

Given the availability of this artifact across all Windows operating systems, the information obtained from the ShimCache can be valuable to an investigation. In this case, the ShimCache supported the findings of Prefetch on regedit.exe and rundll32.exe being executed on the system.

There are more artifacts associated with this feature. In 2013, Corey Harrell wrote on his blog his findings about the Windows 7 RecentFileCache.bcf file. Essentially, this file is maintained in %SYSTEMROOT%\AppCompat\Programs\ directory and keeps metadata (PATH and filename) about executable that are new in the system since the last time the service Application Experience was run. Yogesh Khatri, continued to research Corey findings and found that on Windows 8 this file has been replaced with a registry HIVE called amcache.hve which contains more metadata. From this file you can retrieve for every executable that run on the system the PATH, last modification time & created,  SHA1 and PE properties. Meanwhile, Yogesh noted that on Windows 7 you could also have the amcache.hve if you have installed KB2952664. To read the amcache HIVE you could use RegRipper or Willi Ballenthin stand-alone script.

The ShimCache has not only been used from a defensive perspective. From a offensive perspective, the ShimCache has been used several times by attacker. One of the best resources I’ve come across about the ShimCache is the website “sdb.tools” created by Sean Pierce dedicated to Application Compatibility database research and where he maintains his research and lists different tools, papers and talks.

That’s it, we went over a brief explanation on what is ShimCache, its artifacts, where to find it in memory and in the registry and which tools to use to obtain information from it. Next, we will go back to our SuperTimeline and continue our investigation.

 

References:
Luttgens, J., Pepe, M., Mandia, K. (2014) Incident Response & Computer Forensics, 3rd Edition
SANS 508 – Advanced Computer Forensics and Incident Response

Tagged , , , , ,

Digital Forensics – Prefetch Artifacts

prefetchIt has been a while since my last post on digital forensics about an investigation on a Windows host. But it’s never too late to start where we left. In this post we will continue our investigation and look into other digital artifacts of interest. To summarize what we have in this series of posts:

Following the last post, based on the different Event Log ID’s across our super timeline we found evidence that someone used Remote Desktop to login into the system as Administrator. Moments after, the Administrator made a modification to a “svchosted” system service, changing it to interactive and running it. There is also evidence that this service crashed.  Based on the time when all these events occurred we will look into other artifacts in our Super Timeline around the same timeframe.

The leads that were obtained from Windows Event Log’s will facilitate the analysis of our Super Timeline going forward. This allow us to reduce the time frame and narrowing it down. Essentially we will be looking for artifacts of interest that have a temporal proximity with the event of the administrator logging in.  The goal is to investigate further understand what has happened and what actions did the attacker did on our system.

That being written, which artifacts should we look next? We will start with Prefetch.

Let’s start with a brief explanation about Windows Prefetch. To improve customer experience, Microsoft introduced a memory management technology called Prefetch. This functionality was introduced into Windows XP and Windows 2003 Server. This mechanism analyses the applications that are most frequently used and preloads them in advance in order speed the operating system booting and application launching. On Windows Vista, Microsoft enhanced the algorithm and introduced SuperFetch which is an improved version of Prefetch.

The Prefetch files are stored in %SYSTEMROOT%\Prefetch directory and have a .pf extension. The Prefetch settings that are enforced can be retrieved from the Windows registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters. You can read this setting easily with the brilliant tool created by Harlan Carvey called RegRipper and use the Prefetch plugin.

prefetch-rip

On Windows XP and 7, there are a maximum of 128 .pf files. On Windows 8 this value can reach a maximum of 1024 .pf files. The file names are stored using the convention <executable filename>-<Prefetch hash>.pf.  Worth to mention that this mechanism is disabled by default on Server operating systems. In addition there have been cases where SSD drives have this mechanism disabled.

The internal format of windows Prefetch files have been documented extensively by Joachim Metz here. This documentation is part of libscca which is a library to access the Windows Prefetch File (SCCA) created by Joachim and can be used parse and read the Prefetch files from different operating systems. Matt Bromiley created a ready available script based on this library to read Windows 10 Prefetch files.

So,  other than the Prefetch internals what is the forensic value of the Prefetch artifacts’? The answer is that the Prefetch files keep track of programs that have been executed in the system even if the original file is no longer present. In addition Prefetch files can tell you when the program was executed, how many times and from which path.

Now that we have a basic understanding about Prefetch we will go back to our Super timeline analysis. Plaso supports Windows Prefetch events which we can be corroborated with FILE events and the Windows Event Logs. From the previous blog post analysis we were able to see evidence of when the Administrator logged into the system. And we know that when a user logs into the system, the initial Session Manager (smss.exe) creates a new instance of itself to configure the new session. The new Smss.exe process starts a Windows subsystem process (csrss.exe) and Winlogon process (winlogon.exe) for the new session. This sequence of Windows Events ID 4688 – you need audit process tracking enabled to view this one – can be corroborated with the WinPrefetch and FILE artifacts based on the temporal proximity. The picture below illustrates these events that were retrieved from the Super Timeline moments after the logon events.

prefetch-supertimeline

When combining the Events Logs, Windows Prefetch and File artifacts we start to bring together the different pieces of the puzzle and a start to form a picture of what happened. After looking at the result of the consolidated artifacts of interest in a single view and remove the noise we can conclude that:  On the 9th of October, around 22:42:22 the user account Administrator was used to login into the system. The login was performed from a system with the IP 189.62.10.9 (Brazil). Then based on the Prefetch artifact we have evidence that the user Administration executed the application rundll32.exe following by regedit.exe. Next, the Windows system service FastUserSwitchingCompatibility service  was changed and started. Finally a file cache.txt was created in the system. All this events are supported by evidence retrieved from our Super Timeline and can be shown in the following picture.

prefetch-supertimeline2

Now, with the consolidated view of the different artifacts we continue pursuing the investigation and looking further into those prefetch files. To determine when was the first and the most recent time the binary was executed you can use istat from The Sleuth Kit to read the NTFS metadata entry for the file to get the timestamps.

prefetch-metadata

In addition, to the execution times, we still need to read the content of the Prefetch files itself. These are useful because in addition to the last execution and how many times they were run, it includes the full path and files loaded by the application in the first 10 seconds of its execution. An exception to this is the NTOSBOOT-B00DFAAD.pf which exists on all systems and keeps tracks of the files accessed during the first 120 seconds of the boot process. The full path and files are valuable because they might show evidence of files being loaded from different paths or invoking unknown binaries.

To read the contents of the Prefetch files you could run strings with little endian encoding  (strings -e l) as a quick and dirty method to view its contents. A more robust method would be o use Joachim Metz libssca and create a Python script to read it.

For a readily available Python tool you could use Python script written by the researcher who uses as handler PoorBillionaire which is available here.

prefetch-contents

If you are a windows user then you could compile and use Eric Zimmerman’s Windows Prefetch parser which supports all known versions from Windows XP to Windows 10. In conjunction with the library Eric also released PECmd which is version 0.6 as the time of this writing.  Another method is to use the Windows freeware tool from NIRSOFT called WinPrefetchView. With the /folder suffix you can point to the Prefetch folder of your mounted evidence and see its contents

prefetch-winprefetch

In this case when looking at the Prefetch files from the regedit.exe we found evidence that regedit.exe invoked a DLL called clb.dll from a location that is not supposed to.  This give us another lead to pursue our investigation goals.

That’s it! In this article we reviewed some introductory concepts about the Windows Prefetch files, it’s forensic value and gave good references about tools to parse it. Next step, continue the investigation and review more artifacts’.

 

References:
Luttgens, J., Pepe, M., Mandia, K. (2014) Incident Response & Computer Forensics, 3rd Edition
Carvey, H. (2014) Windows Forensic Analysis Toolkit, 4th Edition
SANS 508 – Advanced Computer Forensics and Incident Response

Tagged , , , ,

Neutrino Exploit Kit

[First of all Happy New Year to all the readers!
In this summary I would like to briefly describe one component that is part of many parts which form the Internet malware industrial complex. The Exploit Kits (EK’s) which impact users and corporations of all sizes on a daily basis. The
 article below was possible due to the insights and knowledge received from @Kafeine. ~LR]

The EK’s are powerful and modular weapons that deliver malware in an automated fashion to the endpoint by taking advantage of client side vulnerabilities.

Exploit Kits are not new and have been around at least for the past 10 years or so. Nonetheless, they have evolved and are now more sophisticated than ever. The malware authors behind them enforce sophisticated capabilities that evade detection, thwart analysis and deliver reliable exploits. Basically, by introducing malicious code in a web server an attacker can turn a legitimate web server into a mechanism to deliver malicious code by taking advantaged of client-side vulnerabilities against unpatched browsers and applications. This attack vector is known as watering hole or strategic web compromise when it targets a trustworthy web site. In recent years the Exploit Kits have evolved and became very sophisticated weapons and profitable business for the ones involved. The malware authors continue to develop sophisticated capabilities to prevent detection, analysis and deploy exploits for new vulnerabilities in a very reliable manner.

In the last days I had the chance to look at one recent campaign of drive by download that leverages the Neutrino Exploit Kit to infect systems with CryptoWall. The diagram below illustrates the different components of the Neutrino Exploit Kit and how they work together.

neutrinoframework

 

  • User browses to the compromised web server.
  • Web server contacts the backend infrastructure in order perform various check and to generate malicious java script code. These checks include things like verification of victim IP address and its Geo-location. Furthermore within the malicious JavaScript code there are new domain names and URLs that are generated dynamically by the backend.
  • The browser processes and decodes the malicious JS. In the observed infection the malicious JavaScript checks the browser version and if it matches the desired version, it stores a cookie and processes a HTML iframe tag.
  • The iframe tag triggers the browser to perform a request to another URL which is the Neutrino Exploit Kit landing page.
  • The landing page is hosted in a randomly generated host using DGA which needs to be resolved via DNS. The authoritative domain to answer these domains are owned by the threat actor. The answers received by the DNS server have a time to live (TTL) of a few seconds. The domains are registered on freely available country code top level domains (ccTLD).
  • The victim then lands in the exploit kit landing page which by its turn delivers a small HTML page with an object tag defined in its body. This object tag directs the browser to load Adobe Flash Player and then use it to play the SWF file specified in the URL. In case the victim does not have Adobe Flash player installed, the browser is instructed to download it.
  • The browser as instructed by the object tag, downloads the malicious Flash file.
  • The obfuscated and encrypted SWF file is played by the Flash Player and exploits are triggered based on available vulnerabilities. The Flash file contains exploits for CVE-2013-2551, CVE-2014-6332, CVE-2015-2419 affecting Internet Explorer and CVE-2014-0569, CVE-2015-7645 affecting Adobe Flash.
  • If the exploitation is successful, shellcode is executed and the malware is downloaded and launched. In this case we observed that the malware delivered has been CryptoWall.

The threat actors behind Neutrino are finding vulnerable websites in order to host their malicious JS  content globally in a repeatable and automated fashion. Furthermore, In the last few days Neutrino has been abusing the registration of free domains registered inside the country code top level domains (ccTLD) such as  .top, .pw, .xyz, .ml, .space and others. The different landing pages have been pointing to a server hosted in Germany and in another cases in Netherlands. In another blog post I will go into more details about it.

 

References:
https://www.trustwave.com/Resources/SpiderLabs-Blog/Neutrino-Exploit-Kit-%E2%80%93-One-Flash-File-to-Rule-Them-All/
http://research.zscaler.com/2015/08/neutrino-campaign-leveraging-wordpress.html
http://www.cert.gov.uk/wp-content/uploads/2015/12/Demystifying-the-exploit kit.pdf
http://www.malware-traffic-analysis.net/2015/09/17/index.html
http://malwageddon.blogspot.ch/2015/03/data-obfuscation-now-you-see-me-now-you.html
http://malware.dontneedcoffee.com/2014/11/neutrino-come-back.html

Tagged , , , , , ,

Malware Analysis – Dridex & Process Hollowing

[In this article we are going to do an analysis of one of the techniques used by the malware authors to hide its malicious intent when executed on Windows operating systems. The technique is not new but is very common across different malware families and is known as process hollowing. We will use OllyDbg to aid our analysis. ~LR]

Lately the threat actors behind Dridex malware have been very active. Across all the recent Dridex phishing 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 normally point to websites owned by legitimate people. The site is compromised in order to store the malicious file and also to hide any attribution related to the threat actors. The encoding and obfuscation techniques used in the macros are constantly changing in order to bypass security controls. The malicious executable also uses encoding, obfuscation and encryption techniques in order to evade antivirus signatures and even sandboxes. This makes AV detection hard. The variants change daily in order to evade the different security products.

When doing malware static analysis of recent samples, it normally does not produce any meaningful results. For example, running the strings command and displaying ASCII and UNICODE strings does not disclose much information about the binary real functionality. This means we might want to run the strings command after the malware has been unpacked. This will produce much more interesting results such as name of functions that interact with network, registry, I/O, etc.

In this case we will look at the following sample:

remnux@remnux:~$ file rudakop.ex_
 rudakop.ex_: PE32 executable for MS Windows (GUI) Intel 80386 32-bit
remnux@remnux:~$ md5sum rudakop.ex_
 6e5654da58c03df6808466f0197207ed  rudakop.ex_

The environment used to do this exercise is the one described in the dynamic malware analysis with RemnuxV5 article. The Virtual Machine that will be used runs Windows XP.  First we just run the malware and we can observe it creates a child process with the same name. This can be seen by running the sample and observing Process Explorer from Sysinternals or Process Hacker from Wen Jia Liu. The below picture illustrate this behavior.

dridex-processcreation

This behavior suggests that the malware creates a child process where it extracts an unpacked version of itself.

In this case we will try to unpack this malware sample in order to get more visibility into its functionality.  Bottom line, when the packed executable runs it will extract itself into memory and then runs the unpacked code. Before we step into the tools and techniques lets brief review the concept around process hollowing.

processhollowing

This technique, which is similar to the code injection technique, consists in starting a new instance of a legitimate process with the API CreateProcess() with the flag CREATE_SUSPENDED passed as argument. This will execute all the necessary steps in order to create the process and all its structure but will not execute the code.

The suspended state will permit the process address spaced of the legitimate process to be manipulated. More specifically the image base address and its contents.

The manipulations starts by carving out and clearing the virtual address region where the image base of the legitimate process resides. This is achieved using the API NtUnmapViewOfSection().

Then the contents of the malicious code and its image base will be allocated using VirtualAlloc(). During this step the protection attributes for the memory region will be marked as  writable and executable. And then the new image is copied over to the carved region using WriteProcessMemory()

Then the main thread, which is still in suspended state, is changed in order to point to the entry point of the new image base using the SetThreadContext() API.

Finally, the ResumeThread() is invoked and the malicious code starts executing.

This technique has been discussed at lengths and is very popular among malware authors. If you want to even go deeper in this concept you can read John Leitch article. Variants of this process exist but the concept is the same. Create a new legitimate process in suspended state, carve its contents, copy the malicious code into the new process and resume execution.

Now lets practice! In order to debug these steps we will use OllyDbg on a virtual machine running Windows XP.

OllyDbg is a powerful, mature and extremely popular debugger for x86 architecture. This amazing tool was created by Olesh Yuschuk. For this exercise we will use version 1.1. The goal is to extract the payload that is used during the process hollowing technique.

When loading this sample into OllyDbg we are presented with two messages. First an error stating “Bad or unknown format of 32bit executable”. OllyDbg can load the executable but it cannot find the entry point (OEP) which suggest the PE headers have been manipulated. Following that the message “compressed code?” is presented. This warning message is normally displayed when the executable is compressed or encrypted. This is a strong indicator that we are dealing with a packed executable. Here we click “No”.

codealert

When the sample is loaded we start by creating a breakpoint in CreateProcessW. This is a key step in the process hollowing technique. We do this by clicking in the disassembler window (top left) and then Ctrl+G. Then we write the function name we want to find. When clicking ok this will take us to the memory address of the function. Here we press F2 and a break point is set. The breakpoints can been seen and removed using the menu View – Breakpoints (Alt+B).

dridex-ollydbg-brkpoint

Then we start debugging our program by running it. We do this by pressing F9 or menu Debug – Run. Once the break point is reached we can see the moment before CreateProcessW function is invoked and the different arguments that will be loaded into the stack (bottom right).  One of the parameters is the CreationFlags where we can see the process is created in suspended mode.

dridex-createprocessw

For the sake of brevity we wont perform the breakpoint steps for the other function calls. But the methodology is to set breakpoints across the important function calls. Before we start debugging the program we can set a break point for the different function calls that were mentioned and review how this technique works. In this case we will move into the end of the process hollowing technique were we hit a breakpoint in WriteProcessMemory() . Once the breakpoint is reached we can see the moment before WriteProcessMemory() function is called and the different arguments. In the stack view (bottom right) we can see that one of the parameters is the Buffer. The data stored is this buffer is of particular interest to us because it contains the contents of the malicious code that is going to be written to the legitimate process. In this case might give us the unpacked binary.

dridex-writeprocessmem

Following this step the code is resumed and executed. During the debugging process if we have Process Hacker running in parallel we can see the new process being created. We can also edit its properties and view the memory regions being used and its suspended thread. Finally when the code is resumed we can see the parent process being terminated.

That’s it for today. In the next post we will carve this buffer out and perform further analysis on this sample in order to understand its intent and capabilities.

The threat actors behind malware have many incentives to protect their code. The world of packing , unpacking, debugging and anti-debugging is fascinating. The competition between malware authors and malware analysts is a fierce fight. The malware authors write armored malware in order to evade AV and Sandboxing detection. In addition they go great lengths ensuring the analysis will be difficult. For further reference you may want to look into the following books: Malware Analyst’s Cookbook and DVD: Tools and Techniques for Fighting Malicious Code, the Practical Malware Analysis and Malware Forensics: Investigating and Analyzing Malicious Code . More formal training is available from SANS with GREM course authored by Lenny Zeltser. Free resources are the Dr. FU’s Security blog on Malware analysis tutorials. The Binary Auditing site which contains free IDA Pro training material.  Finally, the malware analysis track  in the Open Security Training site is awesome. It contains several training videos and material for free!

 

References:

SANS FOR610: Reverse-Engineering Malware: Malware Analysis Tools and Techniques
Malware Analyst’s Cookbook and DVD: Tools and Techniques for Fighting Malicious Code
http://www.autosectools.com/Process-Hollowing.pdf John Leitch
https://www.trustwave.com/Resources/SpiderLabs-Blog/Analyzing-Malware-Hollow-Processes/
http://journeyintoir.blogspot.ch/2015/02/process-hollowing-meets-cuckoo-sandbox.html

Tagged , , , , ,

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.

cryptowall3

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.

cryptowall

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.

cryptowallprocess

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.

cryptowallreg

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.

cryptowallcomms

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.

cryptowall1

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.

cryptowall4

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

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.

email-dyre

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.

email-dyre2

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.

email-oletools

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.

 

email-olevba1

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.

email-oledump1

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.

email-oledump2

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 , , , ,

John the Ripper Cheat Sheet

I created a quick reference guide for John the Ripper. Useful for those starting in order to get familiar with the command line. Download it here: JtR-cheat-sheet.
Print it, laminate it and start practicing your password audit and cracking skills. Can also aid existing users when playing Hashrunner, CMIYC or other contests.

jtr-cheatsheetimg

Tagged , , ,