Shortcuts for Understanding Malicious Scripts

You are being exposed to malicious scripts in one form or another every day, whether it be in email, malicious documents, or malicious websites. Many malicious scripts at first glance appear to be impossible to understand. However, with a few tips and some simple utility scripts, you can deobfuscate them in just a few minutes.

Capture3SANS Instructor Evan Dygert conducted a webcast on October 3rd, 2018. This webcast teaches you how to cut through the obfuscation techniques the script authors use and not spend a lot of time doing it. Evan also demonstrates how to quickly deobfuscate a variety of malicious scripts.

The samples of the scripts he provided during the webcast can be downloaded here: Please note the password for the folder is: “infected”



Capture4We hope that the techniques presented in this webcast help you to begin deobfuscating potentially malicious JavaScript.  This topic is explored in depth in the SANS FOR610: Reverse-Engineering Malware: Malware Analysis Tools and Techniques course.  This class offers an excellent opportunity to understand the unique and insightful perspective that malware analysis can bring to your investigations.




New CheatSheets you might be interested in:

Tips for Reverse-Engineering Malicious Code – This cheat sheet outlines tips for reversing malicious Windows executables via static and dynamic code analysis with the help of a debugger and a disassembler. Download Here

REMnux Usage Tips for Malware Analysis on Linux – This cheat sheet outlines the tools and commands for analyzing malicious software on the REMnux Linux distribution Download Here

Cheat Sheet for Analyzing Malicious Documents – This cheat sheet presents tips for analyzing and reverse-engineering malware. It outlines the steps for performing behavioral and code-level analysis of malicious software. Download Here

Malware Analysis and Reverse-Engineering Cheat Sheet – This cheat sheet outlines tips and tools for analyzing malicious documents, such as Microsoft Office, RTF and Adobe Acrobat (PDF) files Download Here


For opportunities to take the FOR610 course, consider upcoming runs and modalities: 

US & International live training : Live events offered throughout the US, EMEA & APAC regions.

 DFIR Summits :  Two days of industry expert talks plus DFIR training events

Simulcast :   Live events from anywhere in the world.

OnDemand  : Learn at your own pace, anytime, anywhere.








DFIR Resources: Digital Forensic Blog | Twitter | Facebook | Google+ | Community Listservice | DFIR Newsletter

Top 11 Reasons Why You Should NOT Miss the SANS DFIR Summit and Training this Year

The SANS DFIR Summit and Training 2018 is turning 11! The 2018 event marks 11 years since SANS started what is today the digital forensics and incident response event of the year, attended by forensicators time after time. Join us and enjoy the latest in-depth presentations from influential DFIR experts and the opportunity to take an array of hands-on SANS DFIR courses. You can also earn CPE credits and get the opportunity to win coveted DFIR course coins!

summit video pic

To commemorate the 11th annual DFIR Summit and Training 2018, here are 11 reasons why you should NOT miss the Summit this year:

1.     Save money! There are two ways to save on your DFIR Summit & Training registration (offers cannot be combined):

·       Register for a DFIR course by May 7 and get 50% off a Summit seat (discount automatically applied at registration), or

·       Pay by April 19 and save $400 on any 4-day or 6-day course, or up to $200 off of the Summit. Enter code “EarlyBird18” when registering.

2.     Check out our jam-packed DFIR Summit agenda!

·       The two-day Summit will kick off with a keynote presentation by Kim Zetter, an award-winning journalist who has provided the industry with the most in-depth and important investigative reporting on information security topics. Her research on such topical issues as Stuxnet and election security has brought critical technical issues to the public in a way that clearly shows why we must continue to push the security industry forward.

·       The Summit agenda will also include a presentation about the Shadow Brokers, the group that allegedly leaked National Security Agency cyber tools, leading to some of the most significant cybersecurity incidents of 2017. Jake Williams and Matt Suiche, who were among those targeted by the Shadow Brokers, will cover the history of the group and the implications of its actions.

·       All DFIR Summit speakers are industry experts who practice digital forensics, incident response, and threat hunting in their daily jobs. The Summit Advisory Board handpicked these professionals to provide you with highly technical presentations that will give you a brand-new perspective of how the industry is evolving to fight against even the toughest of adversaries. But don’t take our word for it, have a sneak peek, check out some of the past DFIR Summit talks.


Immerse yourself in six days of the best in SANS DFIR training. Here are the courses you can choose from:

·       FOR500 – Advanced Windows Forensics

·       FOR585 – Advanced Smartphone Forensics

·       FOR610 – Reverse-Engineering Malware

·       FOR508 – Digital Forensics, Incident Response & Threat Hunting

·       FOR572 – Advanced Network Forensics: Threat Hunting, Analysis, and Incident Response

·       FOR578 – Cyber Threat Intelligence

·       FOR526 – Memory Forensics In-Depth

·       FOR518 – Mac and iOS Forensic Analysis and Incident Response

·       MGT517 – Managing Security Operations: Detection, Response, and Intelligence

3.    All courses will be taught by SANS’s best DFIR instructors. Stay tuned for more information on the courses we’re offering at the conference in a future article post.

4.     Rub elbows and network with DFIR pros at evening events, including networking gatherings and receptions. On the first night of the Summit, we’re going to gather at one of Austin’s newest entertainment venues, SPiN, a ping pong restaurant and bar featuring 14 ping pong tables, lounges, great food, and drinks. Give your overloaded brain a break after class and join us at our SANS Community Night, Monday, June 9 at Speakeasy. We will have plenty of snacks and drinks to give you the opportunity to network with fellow students.

5.     Staying to take a DFIR course after the two-day Summit? Attend SANS@Night talks guaranteed to enrich your DFIR training experience with us. Want to know about threat detection on the cheap and other topics? As for cheap (and in this case, that doesn’t mean weak), there are actions you can take now to make threat detection more effective without breaking the bank. Attend this SANS@Night talk on Sunday evening to learn some baselines you should be measuring against and how to gain visibility into high-value actionable events that occur on your systems and networks.

6.     Celebrate this year’s Ken Johnson Scholarship Recipient, who will be announced at the Summit. This scholarship was created by the SANS Institute and KPMG LLP in honor of Ken Johnson, who passed away in 2016. Early in Ken’s digital forensics career, he submitted to a Call for Presentations and was accepted to present his findings at the 2012 SANS DFIR Summit. His networking at the Summit led to his job with KPMG.

7.     Prove you’ve mastered the DFIR arts by playing in the DFIR NetWars – Coin Slayer Tournament. Created by popular demand, this tournament will give you the chance to leave Austin with a motherlode of DFIR coinage! To win the new course coins, you must answer all questions correctly from all four levels of one or more of the six DFIR Domains: Windows Forensics & Incident Response, Smartphone Analysis, Mac Forensics, Memory Forensics, Advanced Network Forensics, and Malware Analysis. Take your pick or win them all!


8.     Enjoy updated DFIR NetWars levels with new challenges. See them first at the Summit! But not to worry, you will have the opportunity to train before the tournament. You’ll have access to a lot of updated posters that can serve as cheat sheets to help you conquer the new challenges, as well as the famous SIFT WorkStation that will arm you with the most powerful DFIR open-source tools available. You could also choose to do an hour of crash training on how to use some of our Summit sponsors’ tools prior to the tournament. That should help give you an edge, right? That new DFIR NetWars coin is as good as won!

9. The Forensic 4:cast Awards winners will be announced at the Summit. Help us text2985celebrate the achievements of digital forensic investigators around the world deemed worthy of the award by their peers. There is still time to cast your vote. (You may only submit one set of votes; any additional voting will be discounted). Voting will close at the end of the day on May 25, 2018.

10.  Come see the latest in tools offered by DFIR solution providers. Summit sponsors and exhibitors will showcase everything from managed services covering advanced threat detection, proactive threat hunting, and accredited incident response to tools that deliver rapid threat detection at scale, and reports that provide insights for identifying potential threats before they cause damage.

11.  Last but not least, who doesn’t want to go to Austin?!? When you think Austin, you think BBQ, right? This city isn’t just BBQ, Austin has amazing food everywhere and there’s no place like it when it comes to having a great time. The nightlife and music include the famous 6th Street – which, by the way, is just walking distance from the Summit venue. There are many other landmarks such as Red River, the Warehouse District, Downtown, and the Market District. You will find entertainment of all kinds no matter what you’re up for. Nothing wrong with some well-deserved play after days full of DFIR training, lectures, and networking!

As you can see, this is an event you do not want to miss! The SANS DFIR Summit and Training 2018 will be held at the Hilton Austin. The event features two days of in-depth digital forensics and incident response talks, nine SANS DFIR courses, two nights of DFIR NetWars, evening events, and SANS@Night talks.

The Summit will be held on June 7-8, and the training courses run from June 9-14.

We hope to see you there!

4 Cheat Sheets for Malware Analysis

What tools can assess a suspicious RTF file? How to deobfuscate a JavaScript attachment? Where to set breakpoints for unpacking a malicious executable? What utilities can intercept a C2 traffic in the lab? How do the various reverse-engineering methods fit together?

So much to remember! I created 4 cheat sheets to make it easier to recall answers to these and many other malware analysis questions.

Some of these cheat sheets have been around for a while; I recently updated them to reflect the latest tools and techniques. The one listed first is brand new:

I placed a 1-page limit on each of these cheat sheets to force myself to be selective and succinct. As the result, their contents are quite condensed. You’re welcome to print PDF versions of each file or modify Microsoft Word versions for your own needs.

Many of the tools and techniques captured in these cheat sheets are covered in the FOR610: Reverse-Engineering Malware course I’ve co-authored at SANS.

For additional references from SANS faculty members, see the Community: Cheat Sheets page on the SANS Digital Forensics and Incident Response site.

— Lenny Zeltser

Lenny Zeltser is a senior instructor at SANS Institute and a VP of Products at Minerva. He is active on Twitter.



Call for Presentations Now Open!


dfirsummit 2017Submit your proposal here:
Deadline: January 16th at 5pm CT


The 10th Annual Digital Forensics and Incident Response Summit Call for Presentations is open through 5 pm EST on Monday, January 16, 2017. If you are interested in presenting or participating on a panel, we’d be delighted to consider your practitioner-based case studies with communicable lessons.

The DFIR Summit offers speakers the opportunity for exposure and recognition as industry leaders. If you have something substantive, challenging, and original to offer, you are encouraged to submit a proposal.

Check out some of the DFIR Summit 2016 talks:


We are looking for Digital Forensics and Incident Response Presentations that focus on:

  • DFIR and Media Exploitation case studies hat solve a unique problem
  • New Forensic or analysis tools and techniques
  • Discussions of new artifacts related to smartphones, Windows, and Mac platforms
  • Focusing on improving the status quo of the DFIR industry by sharing novel approaches
  • Challenges to existing assumptions and methodologies that might change the industry
  • New, fast forensic techniques that can extract and analyze data rapidly
  • Focus on Enterprise or scalable forensics that can analyze hundreds of systems instead of one at a time


DFIR Summit 2016 – Call for Papers Now Open


The 9th annual Digital Forensics and Incident Response Summit will once again be held in the live musical capital of the world, Austin, Texas.

The Summit brings together DFIR practitioners who share their experiences, case studies and stories from the field. Summit attendees will explore real-world applications of technologies and solutions from all aspects of the fields of digital forensics and incident response.

Call for Presentations- Now Open
More information 

The 9th Annual Digital Forensics and Incident Response Summit Call for Presentations is now open. If you are interested in presenting or participating on a panel, we’d be delighted to consider your practitioner-based case studies with communicable lessons.

The DFIR Summit offers speakers the opportunity for exposure and recognition as industry leaders. If you have something substantive, challenging, and original to offer, you are encouraged to submit a proposal.

Deadline to submit is December 18th, 2015.

Summit Dates: June 23 & 24, 2016
Post-Summit Training Course Dates: June 25-30, 2016

Submit now 

Hindering Exploitation by Analysing Process Launches

Malware can do some nasty things to your system, but it needs to get on there first. Thankfully, users have become more suspicious of files named FunnyJokes.doc.exe and so malware authors have had to become more innovative, using a mix of social engineering and the constant stream of 0-day browser exploits to land evil code on your box.

Popular infection methods include leveraging exploit kits to run arbitrary code in the context of your browser and ‘infecting’ documents files, such as Microsoft Word documents, which still, 20 years since the first macro virus, allow you to automate the downloading and execution of files. Recently I have been pondering the similarities between various attack types and how they present themselves on the end users machine. It strikes me that, more often than not, the endgame is launching a process by the targeted program.

This begs the question:

Is there ever a legitimate reason for Internet Explorer or Microsoft Word to launch a child process?

Of course there are exceptions, I’m not talking here about Internet Explorer launching a low integrity version of itself every time it runs, but something infrequently seen and significantly less trusted.

Common attack surface: macros

Let’s start by looking at Microsoft Word macros, which are used by several current malware strains. If you interrogate the macro code you are likely to come across a call to the Shell() API, which is one method by which you can execute a process. It looks something like this:

Result = Shell(“C:\windows\system32\calc.exe”, vbNormalFocus)

No prizes for guessing what program is going to be launched here, but what is interesting is that the calculator launches as a child process of winword.exe (Microsoft Word), which can be seen in the ProcessHacker snippet show here:


Taking a look at a real world example, this neat analysis shows how again, based on the fact that this is dropped using a macro, we can see some strange child processes appearing from winword.exe – interesting!

Further attack surfaces: web browsers

How about Internet Explorer? Well, the desired outcome of any high-stakes exploit writing competition tends to look something like the picture below. Again, we can see the launched program is a child of the attack surface – in this case, iexplore.exe.


Again, in the real word, exploit kit authors leverage vulnerabilities in the browser and cause malware to spawn from iexplore.exe (see the image right at the bottom).

It appears a pattern is emerging!!

What can we do about it?

So here are my thoughts – if we watch for processes being spawned from these common attack surfaces we may be able to detect anomalous activity. I decided to experiment by writing a python script which does the following…

  • Utilise WMI to detect new processes being launched
  • For each new process launched, identify the name of its parent
  • If the name matches that of a common attack surface (browser, word processor etc)…
  • …alert the user and terminate the process!

My code looks like this (and is available here):


When I tested it and made Internet Explorer launch calc.exe the result I got looked like this:


and boom! it’s gone…

Running a python script in your environment may not be a viable solution, but if you have a flexible endpoint monitoring solution it may be worth considering implementing a rule to monitor for unexpected spawn!

Follow me on Twitter: @CyberKramer

Detecting Shellcode Hidden in Malicious Files

A challenge both reverse engineers and automated sandboxes have in common is identifying whether a particular file is malicious or not. This is especially true if the malicious aspects are obfuscated and only triggered under very specific circumstances.

There are a number of techniques available to try and identify embedded shellcode, for example searching for patterns (NOP sleds, GetEIP etc), however as attackers update their methods to overcome our protections it becomes more difficult to find the code without having the exact version of the vulnerable software targeted, and allowing the exploit to successfully execute.

In this post, I will discuss a new technique I have been experimenting with, which approaches this issue from a different perspective, forcing the execution of the exploit code, no matter what software you have installed. It is based on two core principles:

  1. If you try and execute something that isn’t code (e.g. a text string), the program will likely crash as the machine code interpretation of this data is unlikely to make much sense.
  2. If you begin executing code from the start (i.e. wherever the instruction pointer would have been set during the exploitation phase), it will run to completion – no matter how obfuscated the instructions are.

So here’s my theory: If we attempt to “execute” the contents of a malicious file (such as a pdf), byte by byte, catching the exceptions as the program continually crashes and then increasing the instruction pointer by one each time, we will eventually come across any malicious code contained therein which will be triggered, run to completion, and provide indicators of its malicious nature through behavioural analysis.

The experiment

In order to test this concept, I wrote a program which does the following:

  • Maps the requested file to memory (i.e. make a full copy of it in memory).
  • Set the instruction pointer to the first byte, and allow it to run.
  • It will probably crash! (The instructions won’t make sense!!)
  • Catch the error, and use the error handler to increase the instruction pointer by one.
  • Try again, and again, and again…
  • If the file contains shellcode, you should eventually hit it, and it will run – hurrah!
Demonstrating the concept
Step 1 – Generating malicious document and starting metasploit reverse handler

We begin by generating a malicious pdf document containing the reverse_tcp metasploit payload, and starting the handler to await incoming connections. The attacker is now waiting for the victim to open the file with a vulnerable pdf reader, at which point it will connect back to the attackers machine.


Step 2 – Dealing with the malicious pdf

Now, let us imagine we are conducting an analysis on this document (either manually, or using an automated sandbox) – the issue we are going to have in this case, is that we are unlikely to have the vulnerable version of the software installed, the exploit won’t work, and we will be none the wiser that it exists! This isn’t to say that the intended victim doesn’t have the vulnerable version installed.

Let us try running the PDF through our proof-of-concept shellcode hunter…


Step 3 – Bingo – shellcode has been located and triggered

As we can see below, the shellcode in the document has been triggered and established a connection back to the metasploit listener! If we were conducting a behavioural analysis, we would be able to identify the suspicious activity and take appropriate action.


Video demo

Check out the video demo if you’d like to see this in action live:


Code sample

If you’re interested in testing the concept, or integrating it into your software (anyone fancy writing a cuckoo module?) – The code I used was pretty simple, and looked like this:


It could definitely be a lot more advanced than the proof of concept I wrote for this demo, for example, if the shellcode started with a JMP $-2 instruction it would trap this code by causing an infinite loop. This could be potentially overcome using multi-threading to continue the search after the first code block has been found.

You may have to play with your compiler settings to get this to work. I set Visual Studio to compile with the ‘Debug’ configuration and switched off some of the protections. If you need some help getting it working, send me a tweet.

I will be presenting this and a few other concepts during a session at SANS London in a couple of weeks, if you’re attending the conference – it would be great to have you along!

Let me know what you think!

Follow me on Twitter: @CyberKramer

Mastering Malware Analysis Skills – The Power of a Capture-the-Flag Tournament

Here at SANS, we’ve worked hard to deliver a Reverse Engineering Malware course packed with technical knowledge, hands-on exercises, and our insights from years of experience. Just as attackers and their tools continue to evolve, so has this course to arm participants with relevant skills they can apply immediately. As both an instructor and a practitioner, I believe the most significant addition to this course is a Capture-the-Flag Tournament. I’d like to share why I think this new content is an amazing opportunity for students to develop their malware analysis skills.

In my experience, building malware analysis skills requires several parallel efforts:

(1) Digest key concepts: With a basic foundation in computer systems, learn how to perform behavioral and code analysis to evaluate a suspect file, dissect its key functionality, assess its impact on a system, and discover potential indicators of compromise.

(2) Develop a process: Draft an approach to apply your knowledge and then iteratively improve it as you gain experience. As part of this activity, it’s critical to document your efforts so you can reflect upon your analysis and eventually share your observations (I previously discussed one approach to tracking your analysis).

(3) Drill: Analyze malware. Don’t just buy a book about it, don’t simply read an article about it – actually experiment with real-world malicious software samples in a properly-isolated laboratory environment.

While all three activities are important for becoming a proficient analyst, the last is, by far, the most critical for internalizing malware analysis skills. This is why we’ve dedicated an entire day of the SANS Malware Analysis course to a capture-the-flag tournament built on the powerful NetWars platform. During this final day of class, students work through a series of challenges that involve a diverse set of real-world malware samples. This game provides participants a fantastic opportunity to apply their training from the first five days of the course, where they learn how to perform behavioral analysis, interpret assembly instructions, deobfuscate binaries and scripts, extract malicious code from documents, and mine memory dumps for malware artifacts.

Participants of the FOR610 Malware Analysis Tournament

Analyzing malicious code can be a difficult task, and understanding sophisticated malware may require days, weeks, months or more to investigate. That’s why we’ve carefully chosen malware samples for the tournament and crafted targeted questions to emphasize the tools and strategies discussed earlier in the course.

Participants of the FOR610 malware analysis tournament presented as part of a live course at a conference have roughly six hours to test their skills against a variety of malware and collect as many points as possible. Getting a top score naturally gets you a bump in prestige, but it also puts you in the running for the coveted SANS Lethal Forensicator Coin. So far, hundreds of people have accepted the challenge of Day 6, and we’ve received terrific feedback. We encourage students to take a lunch break during the tournament to feed their body and minds; however, we find that many survive on adrenaline alone.

If you’d like to take part in this truly unique learning experience, join me at an upcoming FOR610 course.

And if this final day leaves you yearning for more malicious software to munch on, there are numerous resources you can access to download malware for your educational entertainment.

-Anuj Soni

Anuj Soni teaches FOR610: Reverse-Engineering Malware for the SANS Institute. He is also a Senior Incident Responder at Booz Allen Hamilton, where he focuses on hunting threats and double-clicking malware all day long. You can find him on twitter at @asoni.

How to Track Your Malware Analysis Findings


The field of incident response, forensics, and malware analysis is full of thrilling hunts and exciting investigations where you have an opportunity to aggressively pursue the activities of adversaries. While technical acumen certainly supports these efforts, a truly successful execution requires both a well-crafted process and detailed documentation of the journey through that process. Meticulous documentation allows you to easily retrace your analysis flow (particularly important if the work supports any litigation), and it facilitates information sharing so others can benefit from your analysis approach and results. More importantly, if a malware analysis effort continues for any substantial period of time, tracking what you’ve done and what is yet to be done is difficult without comprehensive notes. Generating documentation is clearly one of the less glamorous parts of malware analysis, but it’s absolutely necessary to be an effective analyst.


Documentation approaches I’ve heard of include using a word processing program, a wiki, a mind map, a dirty napkin, and hope (that you’ll just remember). Each of these styles has pros and cons – some are too structured, some are not structured enough.  Just like the analysis process itself, the documentation cannot be too rigid and must allow for some creative freedom; otherwise, it will simply go unused. The goal, of course, is not to find a perfect format, but to use one consistently that allows you to track the investigation process and results. My personal rule is if you don’t document it, it didn’t happen.

An Example

Here  is a Word document template I created to record analysis details when performing manual malware analysis of Windows executable files. I’ve found that a structured Word document provides me the organization I need to quickly note by observations and screenshots without restricting my analysis approach. Not only does the template include the key components of malware analysis, but it also refers to specific tools that can be helpful in gathering certain data. Please note that the document is intended to be a guide, and it should not be used as a comprehensive process document.

The template is divided into several sections:

  • Background: This is where you can record basic contextual information such as the date the file was discovered, why it was brought to the analyst’s attention (e.g., IDS alert) its location on the network, and timestamp data.
  • Static Analysis: As you learn everything you can about a sample without executing it, log your observations here. In addition to file characteristics, you can also document any open source research you perform using information such as the file hash or string references.
  • Behavioral Analysis: Record any file system, network, or memory artifacts in this section. Be sure to consider and document dependencies that impact behavior; for example, malware may require that a particular browser be launched to perform its activity. Samples may also depend upon escalated privileges or only trigger upon reboots. It’s important to perform iterative testing to discover such dependencies.
  • Code Analysis: When it’s necessary to disassemble code and debug its execution, detail your flow and observations here. The level of effort required to perform useful code analysis can vary greatly between samples. Incorporating clues from static and behavioral analysis and focusing on key functionality can help accelerate this process.
  • Analysis Summary: As you perform deep technical analysis to prove or disprove your theories about a sample, it’s helpful to document key analysis findings in a separate section to highlight findings and summarize your work. This section is particularly helpful when management asks for an impromptu update.

 You’re welcome to use the template and tailor it to your own analysis process and other file types. I’d be grateful for any feedback or revised templates.

Final Thoughts

Developing a documentation medium you’re comfortable with is an iterative process, so if it’s unclear what fits your style, try one approach and customize it as necessary. If it’s not working, move on and try something new. Developing a habit of reflection (i.e. What worked? What didn’t work?) will not only help you create better documentation, but it will also improve your analysis methodology.

If you would like to learn more about dissecting malware, I encourage you to join me at an  upcoming FOR610 course.

-Anuj Soni

Anuj Soni teaches  FOR610 Reverse-Engineering Malware  for the SANS Institute. He is also a Senior Incident Responder at Booz Allen Hamilton, where he focuses on hunting threats and double-clicking malware all day long. You can find him on twitter at @asoni.

TorrentLocker Unlocked

Guest submission by Taneli Kaivola, Patrik Nisén and Antti Nuopponen of NIXU

TorrentLocker is a new breed of ransomware that has been spreading lately. Like CryptoLocker and CryptoWall it encrypts files on a victim’s machine and then demands ransom. The victim has to pay to get the decryption software that can decrypt the files.

On a recent incident response case we came across a malware program that had all the known characteristics of TorrentLocker. We started to analyze the malware to see if there was a way to get the files decrypted without paying the ransom. It is well known that some ransomwares like CryptoLocker do implement proper encryption and that it is not possible to recover the encrypted files, but on the other hand, there are also several examples of malware that fail to do solid encryption. For example, security researcher Fakebit ( discovered a CryptoLocker variant that claimed to use 2048-bit RSA but was instead using Tiny Encryption Algorithm (TEA). It seems that malware authors are trying to benefit from CryptoLocker’s reputation and make people pay the ransom even if their malware is not actually implementing strong encryption.

Analysis of TorrentLocker done by iSight partners suggested that TorrentLocker uses Rijendael algorithm to encrypt files that it can locate. Rijendael is a symmetric encryption algorithm that is best known for its use in advanced encryption standard (AES). As the algorithm is a symmetric one, the same key is used both to encrypt and decrypt data. Because the malware program needs to have the key in the infected machine at some point of time to be able to encrypt the files, recovering the key from the infected machine could be possible, at least in theory.

At this point it is unclear whether the variant of TorrentLocker we analyzed is the same one that iSight analyzed, but it did contain all the characteristics that iSight partners reported. During our investigation we got help from Trend Micro ( who provided the initial analysis of TorrentLocker to us. They were able to locate the actual encryption routine from the malware program, and surprisingly it was not Rijendael or AES. According to them, it encrypted files by combining a keystream to the file with exclusive or (XOR) operation. This is the final step used in many stream ciphers. Our further analysis of the malware revealed that it did contain AES code, as well as SHA256 and SHA512 hash algorithms. Exact details on how the encryption is done still remain unknown, but it strongly appears that the encryption is done with a stream cipher that is built using AES and hash functions. The fact that the keystream consists of 16 byte blocks also supports the assumption that AES is used to produce the keystream.

Stream ciphers can be strong, but there are some fundamental issues that must be avoided in order to keep the encryption cryptographically secure. One of the most important things is not to use the keystream more than once.

In our analysis, we had samples of both encrypted and plaintext versions of the same files. As the encryption was done by combining the keystream with the plaintext file using the XOR operation, we were able to recover the keystream used to encrypt those files by simply applying XOR between the encrypted file and the plaintext file. We tested this with several samples of the affected files we had and realized that the malware program uses the same keystream to encrypt all the files within the same infection. This was a cryptographic mistake on the malware author’s part, as you should never use the keystream more than once.

Further analysis of the encrypted files also revealed that the malware program added 264 bytes of extra data to the end of each encrypted file, and that it only encrypts the first 2MB of the file, leaving the rest intact. If the size of the original file is less then 2MB and if the size is not multiple of 16 bytes, the malware program leaves a few bytes from the end of the file unencrypted (file size modulo 16 to be exact). Only encrypting 2MB from the beginning of the file has probably been a conscious decision of the malware author as it makes it faster to render more files unusable. At the same time it also makes recovering files much easier.

In practice this means that if you have both the original and the encrypted version of a single file that is over 2MB in size the entire keystream can be recovered, which makes it possible to recover all your files encrypted by TorrentLocker.

The exact purpose of the extra 264 bytes that the malware program adds at the end of each file is still unknown, but it seems to be unique for each infection. As it is unique, it allowed us to write a software program that automatically recognizes which keystream has been used to encrypt the files. If the keystream is known then the program can automatically decrypt all the files.

For more information regarding TorrentLocker decryption, please contact the team at NIXU.

Taneli Kaivola, Patrik Nisén and Antti Nuopponen, Nixu Oy