0Dozduh$Qdo/Vlv) Xqgdphqwdov

© SANS Institute 2018
)25_5(9(56((1*,1((5,1*0$/:$5(0$/:$5($1$/<6,6722/6$1'7(&+1,48(6

0DOZDUH$QDO\VLV
)XQGDPHQWDOV

THE MOST TRUSTED SOURCE FOR INFORMATION SECURITY TRAINING, CERTIFICATION, AND RESEARCH | sans.org
&RS\ULJKW/HQQ\=HOWVHU$OOULJKWVUHVHUYHGWR/HQQ\=HOWVHUDQGRU6$16,QVWLWXWH
3/($6(5($'7+(7(506$1'&21',7,2162)7+,6&2856(:$5(/,&(16($*5((0(17
&/$ &$5()8//<%()25(86,1*$1<2)7+(&2856(:$5($662&,$7(':,7+7+(6$16
&2856(7+,6,6$/(*$/$1'(1)25&($%/(&2175$&7%(7:((1<28 7+(³86(5´ $1'
6$16,167,787()257+(&2856(:$5(<28$*5((7+$77+,6$*5((0(17,6
(1)25&($%/(/,.($1<:5,77(11(*27,$7('$*5((0(176,*1('%<<28
:LWKWKH&/$6$16,QVWLWXWHKHUHE\JUDQWV8VHUDSHUVRQDOQRQH[FOXVLYHOLFHQVHWRXVHWKH&RXUVHZDUH
VXEMHFWWRWKHWHUPVRIWKLVDJUHHPHQW&RXUVHZDUHLQFOXGHVDOOSULQWHGPDWHULDOVLQFOXGLQJFRXUVHERRNV
DQGODEZRUNERRNVDVZHOODVDQ\GLJLWDORURWKHUPHGLDYLUWXDOPDFKLQHVDQGRUGDWDVHWVGLVWULEXWHGE\
6$16,QVWLWXWHWR8VHUIRUXVHLQWKH6$16FODVVDVVRFLDWHGZLWKWKH&RXUVHZDUH8VHUDJUHHVWKDWWKH
&/$LVWKHFRPSOHWHDQGH[FOXVLYHVWDWHPHQWRIDJUHHPHQWEHWZHHQ6$16,QVWLWXWHDQG\RXDQGWKDWWKLV
&/$VXSHUVHGHVDQ\RUDORUZULWWHQSURSRVDODJUHHPHQWRURWKHUFRPPXQLFDWLRQUHODWLQJWRWKHVXEMHFW
PDWWHURIWKLV&/$
%<$&&(37,1*7+,6&2856(:$5(<28$*5((72%(%281'%<7+(7(5062)7+,6&/$%<
$&&(37,1*7+,662)7:$5(<28$*5((7+$7$1<%5($&+2)7+(7(5062)7+,6&/$0$<
&$86(,55(3$5$%/(+$50$1'6,*1,),&$17,1-85<726$16,167,787($1'7+$76$16
,167,787(0$<(1)25&(7+(6(3529,6,216%<,1-81&7,21 :,7+2877+(1(&(66,7<2)
3267,1*%21' 63(&,),&3(5)250$1&(2527+(5(48,7$%/(5(/,()
,I\RXGRQRWDJUHH\RXPD\UHWXUQWKH&RXUVHZDUHWR6$16,QVWLWXWHIRUDIXOOUHIXQGLIDSSOLFDEOH
8VHUPD\QRWFRS\UHSURGXFHUHSXEOLVKGLVWULEXWHGLVSOD\PRGLI\RUFUHDWHGHULYDWLYHZRUNVEDVHGXSRQ
DOORUDQ\SRUWLRQRIWKH&RXUVHZDUHLQDQ\PHGLXPZKHWKHUSULQWHGHOHFWURQLFRURWKHUZLVHIRUDQ\
SXUSRVHZLWKRXWWKHH[SUHVVSULRUZULWWHQFRQVHQWRI6$16,QVWLWXWH$GGLWLRQDOO\8VHUPD\QRWVHOOUHQW
OHDVHWUDGHRURWKHUZLVHWUDQVIHUWKH&RXUVHZDUHLQDQ\ZD\VKDSHRUIRUPZLWKRXWWKHH[SUHVVZULWWHQ
FRQVHQWRI6$16,QVWLWXWH
,IDQ\SURYLVLRQRIWKLV&/$LVGHFODUHGXQHQIRUFHDEOHLQDQ\MXULVGLFWLRQWKHQVXFKSURYLVLRQVKDOOEH
GHHPHGWREHVHYHUDEOHIURPWKLV&/$DQGVKDOOQRWDIIHFWWKHUHPDLQGHUWKHUHRI$QDPHQGPHQWRU
DGGHQGXPWRWKLV&/$PD\DFFRPSDQ\WKLV&RXUVHZDUH
6$16DFNQRZOHGJHVWKDWDQ\DQGDOOVRIWZDUHDQGRUWRROVJUDSKLFVLPDJHVWDEOHVFKDUWVRUJUDSKV
SUHVHQWHGLQWKLV&RXUVHZDUHDUHWKHVROHSURSHUW\RIWKHLUUHVSHFWLYHWUDGHPDUNUHJLVWHUHGFRS\ULJKW
RZQHUVLQFOXGLQJ
$LU'URS$LU3RUW$LU3RUW7LPH&DSVXOH$SSOH$SSOH5HPRWH'HVNWRS$SSOH79$SS1DS%DFNWR0\
0DF%RRW&DPS&RFRD)DFH7LPH)LOH9DXOW)LQGHU)LUH:LUH)LUH:LUHORJRL&DOL&KDWL/LIHL0DF
L0HVVDJHL3DGL3DG$LUL3DG0LQLL3KRQHL3KRWRL3RGL3RGFODVVLFL3RGVKXIIOHL3RGQDQRL3RGWRXFK
L7XQHVL7XQHVORJRL:RUN.H\FKDLQ.H\QRWH0DF0DF/RJR0DF%RRN0DF%RRN$LU0DF%RRN3UR
0DFLQWRVK0DF260DF3UR1XPEHUV26;3DJHV3DVVERRN5HWLQD6DIDUL6LUL6SDFHV6SRWOLJKW
7KHUH¶VDQDSSIRUWKDW7LPH&DSVXOH7LPH0DFKLQH7RXFK,';FRGH;VHUYH$SS6WRUHDQGL&ORXGDUH
UHJLVWHUHGWUDGHPDUNVRI$SSOH,QF
303DQG30%2.DUHUHJLVWHUHGPDUNVRI30,
62)(/.LVDUHJLVWHUHGWUDGHPDUNRI/HZHV7HFKQRORJ\&RQVXOWLQJ//&8VHGZLWKSHUPLVVLRQ

6,)7LVDUHJLVWHUHGWUDGHPDUNRI+DUELQJHUV//&8VHGZLWKSHUPLVVLRQ
*RYHUQLQJ/DZ7KLV$JUHHPHQWVKDOOEHJRYHUQHGE\WKHODZVRIWKH6WDWHRI0DU\ODQG86$
)25BB'B
FOR610.1 REVERSE-ENGINEERING MALWARE
Malware Analysis
Fundamentals
© 2002-2018 Lenny Zeltser | All Rights Reserved | Version D01_01
FOR610.1, also known as Section 1 of the FOR610 course, lays the groundwork for the course by
presenting the key tools and techniques malware analysts use to examine malicious programs. You will
learn how to save time by exploring malware in several methodical phases, which include looking at the
specimen's static properties, examining its behavior, and looking at its code-level patterns. You will also
learn how to build and use a flexible and isolated laboratory to perform this type of analysis in a
controlled manner.
FOR610.1 materials were created by Lenny Zeltser. They incorporate feedback from FOR610 course
participants. To learn about Lenny's background and other projects, visit his website at https://zeltser.com
or follow him at https://twitter.com/lennyzeltser. You can also keep up with his writing at
https://zeltser.com/blog.

© 2018 Lenny Zeltser 1

Set up your lab before proceeding with this course.
• Refer to the instructions in your Workbook, Section 0.

• Access the USB drive provided to you by SANS for this course.
• Exercise
EXERCISE 0.1:
0.1 Import and configure REMnux to prepare the Linux
virtual machine.
• Exercise
EXERCISE 0.1:
0.2 Import and configure Windows REM Workstation
to prepare the Windows virtual machine.
• Confirm that the two VMs can connect to each other via the host-
only network and take snapshots while they're in a good state.
FOR610 | REVERSE-ENGINEERING MALWARE 2
This course includes a lot of hands-on labs. To take advantage of them, you need to set up the malware
analysis laboratory on your system, so you can utilize it during the course and, hopefully, after the class
ends.
The instructions for setting up your lab are documented in your Workbook. Turn to Section 0 in the
Workbook and follow Exercises 0.1 and 0.2. To proceed with these exercises, you'll need to access the
USB drive that SANS provided to you for this course.
Exercise 0.1 asks you to import and set up the REMnux virtual machine. You use this VM to monitor the
laboratory network, to provide services that malicious software may attempt to reach, and to examine
malware using Linux-based tools. We use a Linux distribution called REMnux (https://REMnux.org) for
this purpose.
Exercise 0.2 asks you to import and set up the Windows REM Workstation, which includes many
malware analysis tools used throughout the course. This is also the virtual machine you will infect when
studying how malicious software behaves and when examining its code using Windows-based tools.
Some of the steps will involve accessing large files from the USB drive, which can take a fair bit of
waiting. Please start these operations as early as possible.

2 © 2018 Lenny Zeltser

Course Roadmap MALWARE ANALYSIS FUNDAMENTALS
• FOR610.1: Malware Analysis 1. Introduction to Malware Analysis

Fundamentals 2. Malware Analysis Lab
• FOR610.2: Reversing 3. Static Properties Analysis
Malicious Code 4. Behavioral Analysis Essentials
• FOR610.3: Malicious Web and 5. Code Analysis Essentials
Document Files
6. Interactive Behavioral Analysis
• FOR610.4: In-Depth Malware
Analysis
• FOR610.5: Examining Self-
Defending Malware
• FOR610.6: Malware Analysis
Tournament
We're in Section 1, Malware Analysis Fundamentals, of the FOR610 course. Our next module is titled
Introduction to Malware Analysis.


Introduction to
Malware Analysis
Let's spend a bit of time discussing the objectives that tend to drive malware analysts' efforts. This module
also discusses the key phases of the malware analysis process and walks you through an example of using
publicly available tools and data sources to start learning about the nature of a suspicious file.


Malware analysis is a critical component of information security.
• Malicious software is an integral component of many security

incidents and the associated investigations.
• Organizations often struggle to understand malware they
encounter during incident response.
• Knowing how to analyze malware enables you to take control of
the situation that involves it.
Malware is code that is used to perform malicious actions.
People and organizations disagree in what they consider malware. The exact definition has been the
subject of many discussions; however, the best way to proceed might be to acknowledge that differences
in people's experiences and priorities lead them to define malware differently. (For more on this topic, see
https://zeltser.com/what-is-malware.)
In the context of this course, we define malware as code that is used to perform malicious actions. This
definition implies that whether a program is malware depends not so much on its capabilities but, instead,
on how the attacker uses it. Malware is typically designed to allow the attacker to benefit at the victim's
expense. Remember that behind malware there is usually a human or organization that makes use of its
capabilities for malicious purposes.
Modern IT incidents that involve a security breach typically include malware, which might be designed to
allow the attacker to remotely control the compromised system, spread within the organization, steal
(exfiltrate) sensitive documents, spy on the victim, and so on. In such scenarios, knowing how to analyze
the malicious programs discovered in the incident response process is critical to taking control of the
situation.


Learn core malware analysis techniques so you can…
• Assess the nature of malware threats.

• Determine the scope of the incident.
• Eradicate malicious artifacts.
• Fortify system and network defenses.
• Strengthen your ability to handle malware incidents.
Is there a difference between reverse-engineering malware and malware analysis?
All too often, organizations that discover malware when performing incident response or forensic
investigations don't know how to examine it. This course is designed to address that deficiency. You will
learn how to analyze malicious software to determine its characteristics so that you can contribute such
insights to investigations. What threat does it possess? How skilled is the adversary using it? What goals
might he be pursuing? How do you contain and recover from the incident? How do you strengthen system
and network defenses based on what you learned when handling the incident? Malware analysis helps us
answer these and other critical questions.
In this course, we use the terms malware analysis and reverse-engineering malware (REM)
interchangeably. Depending on your background or industry, you might make a distinction between the
two terms. Some people consider REM to be the practice of reversing the code that comprises the
malicious program and use the term malware analysis when referring to more basic aspects of examining
the software.
In this course, we examine malware from different perspectives, though we do not go as deep into the
world of code-level reversing as a more "advanced" REM course might.


This course focuses on examining malicious software that thrives
in an enterprise setting.
• Compiled Windows executables

• Malicious document files, which might
be used as the initial infection vector
• Browser-based malware, designed to
infect victims' Windows systems
• Some specimens hide in plain sight;
“I’m afraid it’s malware.” others conceal or obfuscate themselves
• A part of a larger forensics
curriculum…
Before getting into the details of malware analysis, let's make sure you know what to expect from the
course. You are probably familiar with this based on the course description, which you reviewed prior to
signing up for this course.
The course focuses on the analysis of malicious Windows executables because this type of malware poses
a large threat to modern enterprises. Recognizing that the way in which attackers install Windows
programs often involves malicious documents and browser-based exploits, we also learn how to examine
malware designed to run on a browser and document files that could be used as the initial infection
vector.
As a reverse engineer, you typically do not have the source code for the malicious programs you'll
examine. Even browser scripts that we explore will be obfuscated. Therefore, you need to learn how to
study malware using other techniques. These involve static properties analysis, behavioral analysis, and
code-level analysis tactics that are covered in the course.
We won't get into all topics related to malware, though. After all, malware analysis exists in the larger
context of digital forensics and incident response.
(The image on this slide is based on the image by NLshop: https://www.fotolia.com/id/13374457.)


The activities of a malware analyst, at least in the context of our course, begin when the analyst is
presented with a malicious, or at least suspicious, program that needs to be examined. The person needs to
assess the nature of the specimen and collaborate with colleagues or clients that participate in other
aspects of the investigation or incident response.
SANS Institute offers courses that cover many aspects of digital forensics and incident response (DFIR),
which include examining the compromised host's file system and memory, as well as performing network
forensics and analyzing mobile devices. FOR610 is a part of this knowledge-rich curriculum.
Follow the pointers on this slide to learn about other SANS DFIR courses and to learn from DFIR faculty
members as they post articles, share tips, and conduct free webcasts.


Stages of malware analysis techniques increase in complexity.
Manual code reversing
Harder Interactive behavior analysis
Static properties analysis
Fully automated analysis
The process of analyzing malicious software involves several stages, which can be listed in the order of
increasing complexity. The pyramid on this slide, based on the diagram by Alissa Torres
(https://www.sans.org/instructors/alissa-torres), presents one such ranking.
The easiest way to begin learning about a particular malware specimen is to examine it using fully
automated tools, some of which are available as commercial products and some as free ones. These
utilities are designed to quickly assess what the specimen might do if it ran on a system. They typically
produce reports with details such as the registry keys used by the malicious program, its mutex values,
network traffic, and so on. They might not provide as much insight as a human analyst would obtain
when examining the specimen in a more manual fashion. However, they contribute to the incident
response process by rapidly handling vast amounts of malware, allowing the analyst (whose time is
relatively expensive) to focus on the specimens that truly require her attention.
Analysts might proceed with examining the malware specimen by looking at its static properties, which
are sometimes called metadata. This process entails examining the strings embedded into the file, its
overall structure, and header data, without actually running the malicious program. We look at tools and
techniques for performing these steps, which tend to be fast and offer a convenient way of becoming
acquainted with the specimen.
Automated and static analysis steps might pique the analyst's interest, justifying the person to allocate
time toward taking a closer look at the specimen. This examination might entail running the malicious
program in an isolated lab, instrumented to provide the analyst with insights about the specimen's
behavior. The next step—which tends to be most time-consuming—entails reverse-engineering the
program's code to better understand its inner-workings. As
you will see later in
the course, these analysis
stages are often intertwined. Moreover, memory forensics can sometimes assist with the stages presented
in this diagram, as we'll briefly discuss later in the course.

Malware analysts need to understand how they interact with
other information security professionals.
Input to REM staff: Output from REM staff:
• Verbal reports • What malware does

• Suspicious files • How to identify it
• File system image • Attacker's profile
• Memory image • IR recommendations
• Network logs • Reports and IOCs
• Anomaly observations • Malware trends
Malware analysts collaborate with colleagues, clients, and consultants on a regular basis. One way to
consider how we can be more effective at interacting with other information security professionals is to
understand the "inputs" they provide to us and the "outputs" we produce.
Malware analysts obtain from others suspicious artifacts that we need to investigate. These include
potentially malicious executables, documents, URLs and web pages. We also seek any additional
contextual information about the infection, which might come in the form of memory snapshots, file
system images, and network logs. Other details about the incident and the associated malware might come
to us in the form of verbal reports from the victims or IT staff as well as the associated email messages,
attachments, chat logs, and screenshots. All these details help us derive insights and identify patterns
when examining malware.
The results of our malware analysis efforts can be shared with others as informal verbal and written
observations. They can also take the form of a formal report. Sometimes, the organization seeks a few
quick tips, such as indicators of compromise (IOCs) that we might derive in less than an hour. Sometimes,
we may be asked to devote days to the analysis for an in-depth study of the specimen's characteristics. In
many cases, the organization looks to us for information about the capabilities of the malicious program,
ways of spotting it in the wild, the characterization of the attacker using the specimen, and
recommendations for how to proceed with the incident response process.
The data that malware analysts derive after examining malicious programs can help the organization
understand the threat landscape that is relevant to its particular industry or geography. Such insights can
inform the enterprise about the trajectory with which the threats are evolving and clarify the ways in
which its defenses need to be adjusted. Acting in thiscapacity,
malware
analysts
can provide threat
intelligence and other insights that would not be available otherwise.

What to include in a malware analysis report.
• Determine how detailed and formal the output of your malware

analysis needs to be.
• If you need to produce a formal report, here's one way to structure it:
Ł Summary of the analysis
Ł Identification (IOCs)
Ł Characteristics (consider MAEC Malware Capabilities)
Ł Dependencies
Ł Behavioral and code analysis findings
Ł Supporting figures
Ł Incident recommendations
• Sometimes, a quick email will suffice.
When communicating the results of your malware analysis in writing, be sure to understand how detailed
the output of your work needs to be. Don't put time into a formal report if a quick email will suffice.
When asked to produce a formal report after analyzing a malicious program, following are some of the
areas you might want to cover in the write-up:
• Summary of the analysis: Key takeaways the reader should get from the report regarding the
specimen's nature, origin, capabilities, and other relevant characteristics.
• Identification: The type of the file, its name, size, hashes (such as SHA256), malware names (if
known), and current antivirus detection capabilities.
• Characteristics: The specimen's capabilities for infecting files, self-preservation, spreading,
leaking data, interacting with the attacker, and so on. For a good reference of what characteristics
you may need to capture, and for a schema of describing such traits, take a look at the MAEC
Malware Capabilities project at https://github.com/MAECProject/schemas/wiki/Malware-
Capabilities.
• Dependencies: Files and network resources related to the specimen's functionality, such as
supported OS versions and required initialization files, custom DLLs, executables, URLs, and
scripts.
• Behavioral and code analysis findings: Overview of the analyst's behavioral, as well as static
and dynamic code analysis observations.
• Supporting figures: Logs, screenshots, string excerpts, function listings, and other exhibits that
support the investigator's analysis.
• Incident recommendations: Indicators for detecting the specimen on other systems and networks,
and possible for eradication steps.

When deciding the level of details to include in your report, consider including enough information that
would allow another similarly skilled analyst to go through your findings and arrive at similar
conclusions.

Consider the following malware analysis report templates.
The common aspects of a formal malware analysis report could be captured as a template, two of which
are shown on this slide.
The template on the left, created by Lenny Zeltser, takes the form of a "mind map." Such mind maps can
help organize your notes, links, and screenshots on a single easy-to-see canvas. You can download this
template from https://zeltser.com/malware-analysis-report.
The template on the right, created by Anuj Soni, offers another way to organize your report and takes the
form of a Microsoft Word document. To learn about this template and to download it, see
https://digital-forensics.sans.org/blog/2014/12/01/how-to-track-your-malware-analysis-findings.


Here are some of the numerous free online resources that offer
malware information or automated analysis capabilities.
• Malware data repositories: VirusTotal, #totalhash

• Multi-engine antivirus scanners: VirusTotal,
Metadefender, VirSCAN, AVCaesar
• File reputation: Malware Hash Registry, HashSets
• Automated sandboxes: Malwr, Hybrid Analysis
• Website investigation: urlQuery, vURL, Quttera
• Other threat intelligence: PassiveTotal, Censys, Open
Threat Exchange
Now, let's consider how an analyst might quickly assess the nature of a suspicious artifact to perform
automated malware analysis. This slide lists some of the freely available online tools and public
information sources useful for the tasks that form the foundation of the pyramid shown a few slides ago.
Of these options, perhaps the best-known one is VirusTotal, which can not only scan the specified file
using a multitude of antivirus engines but also provides a vast malware knowledge base for the files it
scanned earlier.
Malware analysts shouldn't rely on a single tool for their work, which is why it's great to see other free
resources that also provide information about malicious software, offer antivirus scanning capabilities,
share file reputation details, and even automatically run your specimen to report what it might do when
infecting a host.
Other sites useful for investigating malicious artifacts include threat intelligence services that aggregate
various data sources into unified reports and provide a useful interface for sifting through such
information. Moreover, several free online tools focus on helping you investigate suspicious websites by
visiting them on your behalf.
This slide isn't an all-encompassing listing of such resources, but is merely a sampling of free tools and
data sources available online. Of course, many commercial options are also available. For a more
comprehensive listing of free automated sandboxes available online, see https://zeltser.com/automated-
malware-analysis.


How might you start investigating this suspicious file by using free
online resources?
Consider the following scenario: Your antivirus tool flags a suspicious file vdaudio.dll, discovered on a
system in your organization. You look up the hash of this file on VirusTotal. The hash value enables you
to uniquely identify the file without sharing its contents directly and acts as its digital fingerprint.
An excerpt of the report for this file is shown on this slide. It resides at the following URL:
https://www.virustotal.com/en/file/1e9f21f514ee4793cfae7baa21549be0d9b432c59513d2efed860c2b150
1da39/analysis/
VirusTotal shows that many antivirus tools consider this file malicious. The names assigned to this
specimen are mostly generic, though some tools include "proxy" in its name. If you could identify the
name of the malware family to which the specimen belongs, you could get a good sense regarding its
capabilities and threat level.
VirusTotal's report includes some details about the specimen, which the service statically extracted from
the file, although its analysis of this program is far from comprehensive. Among the more interesting
details are its exports, which are captured on this slide.
We're dealing with a Dynamic-Link Library (DLL) file. A DLL is similar to traditional Windows
executables; however, to run it properly, you often need to know which function implemented inside the
DLL you need to run first. The export table, labeled by VirusTotal as "PE exports," shows the listing of
the functions that were designed to be invoked from outside the DLL. In this case, there appear to be only
three such functions. You can use this information for launching the specimen inside your lab later,
should you decide to perform behavioral analysis.


Automated analysis sandbox highlights key attributes, enabling us
to pivot around them to expand the investigation.
For additional details about this specimen, you check whether an online automated analysis sandbox
provides a report about the file's runtime behavior. For this example, we used the free site Hybrid
Analysis by Payload Security. This slide captures some excerpts of the report, which you can obtain from
the following URL: https://www.hybrid-
analysis.com/sample/1e9f21f514ee4793cfae7baa21549be0d9b432c59513d2efed860c2b1501da39.
Hybrid Analysis shows a lot of details regarding the behavior of the specimen. This tool was able to
gather such information by executing ("detonating") the sample in a monitored sandbox environment. For
instance, the report shows that the malicious program attempted to use DNS to resolve two hostnames:
cn.mnemonicarx.biz and cm.mnemonicarx.biz. Network attributes also included connections to three
other hosts via IP addresses on TCP port 53, though actually, this wasn't valid DNS traffic. The report
highlights enable us to investigate which other artifacts are associated with these hosts, and it shows the
hashes of malware samples that used the same IPs.
The report also shows that the specimen created a mutant named LXCV0IMGIXS0RTA1 during runtime.
A mutant (sometimes called mutex) serves as a flag that programs can use to serialize access to a
resource. These flags are sometimes used by malware to avoid reinfecting the host, acting as infection
markers. Malware may attempt to open a handle to a mutant with a specific name; the specimen might
exit if the mutant exists, which would indicate that the host is already infected. Therefore, knowing the
name of the specimen's mutant objects might help us spot it in our environment. Sometimes, you might be
able to see a mutant name embedded into the program as a string, which will be visible during this early
analysis stage; however, in many cases, you won't be able to discover this functionality until you perform
behavioral or code analysis.


Other data sources show additional details about the domain, the
communication protocol, and the likely malware family.
Continuing with the investigation, you check other public data sources about artifacts related to the
vdaudio.dll specimen. For instance, PassiveTotal provides historic information about the IP addresses to
which cn.mnemonicarx.biz resolved over time, network details for those IPs, and indicators that those
resources were associated with malicious activities. In the case of this sample, the site confirms that the
hostname presently resolves to the same IP that was reported by Hybrid Analysis.
Another data source, Open Threat Exchange, provides additional details about this hostname at
https://otx.alienvault.com/indicator/hostname/cn.mnemonicarx.biz. This report includes a reference to a
file associated with this hostname that you haven't seen in other reports, which takes you to the Open
Threat Exchange report for this file. It's available at
https://otx.alienvault.com/indicator/file/dceb91a3aace0c732f5732584fe7eac2635546f10df2bd0ce0330a9d
3730016d.
The report about this new file shows some familiar indicators. This specimen communicates with the
same host as your original sample. Moreover, it uses the same mutant value: LXCV0IMGIXS0RTA1. It
also states that when this specimen runs, it generates a DLL named llmedia.dll, which appears similar in
nature to our sample vbaudio.dll. The report also shows that the network traffic generated by the
specimen when communicating with 85.17.114.55 matches the signature of the "ETPRO TROJAN
Bunitu Covert Channel port 53" protocol. Your vbaudio.dll sample probably uses the same protocol when
communicating with 85.17.114.55.
This analysis suggests that the sample you're investigating belongs to the Bunitu malware family.
Looking it up in a web search engine brings you to Microsoft's report about it, which is available at
https://microsoft.com/security/portal/threat/encyclopedia/Entry.aspx?Name=Win32%2fBunitu.
According
to Microsoft, a Bunitu infection involves a dropper executable and a malicious DLL. The report states that
this malware causes the infected system to act as a "malicious proxy host. A remote malicious hacker can
then connect to the Internet or malware-related servers by using your PC as a proxy, in order to hide their
activities."

You've confirmed that the file is malicious, gathered IOCs, and
identified the nature of the infection.
• Open-source intelligence (OSINT) is information collected from

public data sources.
• OSINT investigations often involve pivoting around known
attributes to locate new ones.
• Malware often seeks to communicate with the adversary for
beaconing, command and control (C2), and exfiltration.
• Indicators of compromise (IOCs) are attributes you can use as
context-specific "signatures" to spot the adversary elsewhere.
You now have additional data for assessing the nature of the incident involving the malicious file and
deciding how to proceed with the investigation. The process that enabled you to reach this state involved
examining publicly available data sources, which included reports of previously performed automated
analysis and historical data about artifacts associated with the specimen. In other words, you gathered
open-source intelligence (OSINT).
The approach to locating and analyzing OSINT involved looking for associations between known
attributes of the malicious program with new characteristics. This technique is sometimes called pivoting.
For instance, pivoting around one of the hostnames that the specimen resolved (cn.mnemonicarx.biz) led
you to another malware specimen that also used it, which in turn led you to a signature that identified both
samples' network traffic characteristics and family name.
Malware analysts are often tasked with investigating the nature of the network traffic coming to or from
the specimen, such as the non-DNS traffic sent out by the vdaudio.dll specimen over TCP port 53. Such
communications can take several forms, including:
• Beaconing: Sending brief periodic messages to the adversary with basic information about the
state of the malicious program and its infected host.
• Command and control (abbreviated as C2 or C&C): Obtaining instructions from the adversary
regarding actions that the specimen needs to perform, such as upgrade itself or scan a host.
• Exfiltration: Sending stolen data, such as keystroke logs, to the adversary.
When examining malware, analysts often seek to define indicators of compromise (IOCs), which are
infection characteristics that could be used as context-specific
"signatures"
to detect the presence of the
adversary using this malware throughout your enterprise. IOCs can be defined as network-level
characteristics, such as network traffic envelope and content details. They can also be defined as host-
level characteristics, such as filenames, process names, hash values, registry keys, and mutant names.
Your analysis of vdaudio.dll identified several such IOCs.

Automated tools are useful and OSINT resources are useful, but
we cannot rely on their applicability or availability at all times.
• It might be a bad idea to upload a sensitive file to a third party.

Ł The file might have sensitive data embedded into it.
Ł In a targeted attack, attackers might learn they were discovered if they spot their
specimen's analysis report.
Ł Your organization's policy might prohibit such sharing and distribution without an
explicit contract with the third party.
• If in doubt, it's best to search the sites for file hashes or other
IOCs without actually uploading your artifacts.
• Fully automated tools don't offer the level of control and insight
you can get in your own lab (if you know what you're doing).
It's convenient and useful to use online tools for analyzing various aspects of malicious files. However,
consider whether uploading a given specimen to a third-party service is appropriate for your particular
situation. The file might have sensitive data in it; releasing it might violate laws, regulations, or other
commitments. For this and other reasons, your organization's policy or contractual obligations might not
allow you to share sensitive files, including suspicious documents and executables, with a third party.
Be especially careful with the artifacts discovered as part of a targeted attack. By uploading the file to a
service such as VirusTotal, you might reveal to the attacker that his presence has been discovered within
the targeted organization. The attacker might determine this by periodically querying the VirusTotal
website for the hash of the executable specific to the target, expecting that as long as the attack is
undiscovered, the query should produce no match.
If you're not sure whether uploading a suspicious file to a third-party website is a good idea, consider
keeping the file's contents private. Instead, you might merely search the site using the file's hash or other
IOCs related to the incident you are investigating.
Examining public data sources for data related to your specimen and using online tools—if the situation
allows for this—are a valuable part of the malware analysis process. However, you cannot rely on such
third-party resources and fully automated tools as your sole approach for understanding the nature of
malicious software. In many cases, the analyst needs to dig deeper than full automation allows. To
accomplish this task, you need to start with a lab that you fully control. The lab will require the right tools
and, of course, you will need to know how and when to use them.


Course Roadmap MALWARE ANALYSIS FUNDAMENTALS
• FOR610.1: Malware Analysis 1. Introduction to Malware Analysis

Fundamentals 2. Malware Analysis Lab
• FOR610.2: Reversing 3. Static Properties Analysis
Malicious Code 4. Behavioral Analysis Essentials
• FOR610.3: Malicious Web and 5. Code Analysis Essentials
Document Files
6. Interactive Behavioral Analysis
• FOR610.4: In-Depth Malware
Analysis
• FOR610.5: Examining Self-
Defending Malware
• FOR610.6: Malware Analysis
Tournament
We're in Section 1, Malware Analysis Fundamentals, of the FOR610 course. Our next module is titled
Malware Analysis Lab.


Malware Analysis Lab
Before we can analyze malicious software, we need to ensure that we have a laboratory environment that
can accommodate key malware analysis phases. This entails isolating the lab from other networks,
installing the appropriate tools, and confirming that the overall configuration of the laboratory
environment can accommodate your analysis objectives.
Let's see what this entails.


To examine malware safely and effectively, we need a lab.
• Use external information and tools when you can, but in many
cases, you have to keep the investigation under tight control.
• Isolate the lab from other networks.
Ł Mitigate the risk of inadvertently infecting production systems outside the lab.
Ł Don't accidentally attack others on the internet.
Ł Keep tight control over all aspects of the lab for reliable and repeatable analysis.
• Install and configure malware analysis tools.
As we discussed, a variety of information sources on the internet can provide details relevant to the
specimen you need to analyze. However, you cannot count on them being available, and you need to
know how to examine the malicious program even if no one has taken the time to perform the analysis
earlier or made the findings available to you.
You could employ free and commercial tools outside of your environment that shed details on various
aspects of the malicious program. However, in some cases, you may be dealing with a sensitive incident
that—due to its nature or the overall policy of your organization—precludes you from sending the sample
outside of your environment.
All this is to say that you need to have tools of your own to analyze malicious programs so that you can
go beyond the details what third-party tools or information sources can offer. You need a lab.
The lab should be isolated from other networks. Such isolation mitigates the risk of malware escaping
from your lab to infect production systems. It also helps prevent situations in which the analyst might
inadvertently infect the wrong system. Isolating the lab also makes it less likely that the malware you
examine accidentally attacks other people or organizations.
Finally, isolating the lab gives you the degree of control over its configuration that's needed to examine
malware in a reliable and repeatable manner. If the lab were connected to other networks, you would have
a harder time controlling what IT resources are available to the specimen and how it interacts with its
environment.
Your lab should have the tools you know and trust toexamine
malware
using behavioral and code
analysis techniques. You get to know many such tools throughout the course, perhaps to enhance the
toolkit you already have or to give you the opportunity to experiment with new tools and approaches.

The malware analysis lab could be composed of physical or
virtualized components.
Windows 7 Windows 10
172.16.198.128 172.16.198.131
Linux Windows 8.1

172.16.198.129 172.16.198.130
Laboratory Network - 172.16.198.0/24
The malware analysis lab should incorporate several systems networked together.
It helps to have multiple operating systems available to explore how malware might operate under
different conditions. For this purpose, consider including both older operating systems (for example,
Windows 7) and more modern ones (for example, Windows 10).
You might also benefit from having a Linux host in the lab, even if you don't examine Linux-based
malware. Many tools that can help examine Windows-centric malware run on Linux. A Linux host is also
useful for running or emulating the various network services that malware might want to access when it
runs.
The diagram on this slide shows an example of such a lab. The network addressing scheme and specific
systems present in your lab might differ from what you see on this sample drawing. Such a lab could be
implemented using physically distinct components or using virtualization.


Virtualization software provides convenience and flexibility.
• Virtualization software allows multiple virtualized systems to run

on a single physical host.
Ł These systems are sometimes called "guests."
Ł They're also called "virtual machines" or "VMs."
• You need to install an OS into each VM like you'd install it onto a
traditional host.
• VMs can interact with each other or, if you let them, with the
physical network.
Many analysts appreciate the convenience and flexibility that virtualization software offers for building a
lab. Such tools enable multiple virtual systems, sometimes called guests or virtual machines (VMs) to run
on a single physical host. The virtualization tool emulates (or "virtualizes") the hardware for each VM.
You still need to install the operating system and applications into the VMs, much like you would install
them onto a traditional physical host.
Virtualization software emulates (or "virtualizes") the network within the host, allowing the VMs to
interact with each other as if they were plugged into the physical network. You have a lot of control over
the virtualized network's configuration, so you can define how the virtualized network is structured and
how and whether it can communicate with the physical network.


We'll use VMware, but there are other virtualization options.
VirtualBox and Hyper-V are among

feasible alternatives.
Virtualization software includes such products as VMware Workstation, Microsoft Hyper-V, and Oracle
VirtualBox. This course uses VMware Workstation or Fusion products. We're sticking with VMware
mostly because of that tool's maturity and to have a uniform environment in the class for ease of
troubleshooting.


Pay attention to your lab isolation measures.
• Malware could escape from a virtual machine by exploiting a

hypervisor vulnerability or a misconfigured feature.
• Perhaps more likely, you might accidentally infect the wrong
system when examining the specimen.
• Malware analysis involves some element of risk, but you should
take measures to minimize it to an acceptable level.
• Precaution tasks:
Ł Keep up with security patches.
Ł Don't use lab systems for other purposes.
Ł Disconnect the lab from other networks.
Ł Disable risky capabilities, such as folder sharing.
We already touched on the need to isolate your lab, but it's worth emphasizing this point again due to its
importance, especially if you virtualize the lab. Malicious software might look for bugs or configuration
weaknesses to escape from one VM to another or onto your physical host. Perhaps more likely, you might
accidentally infect the wrong system when experimenting with malware.
There are steps you can take to minimize the risk associated with malware analysis to an acceptable level.
Avoid connecting the lab's network to other networks. If using virtualization, don't use the lab's physical
host for other purposes. Keep up to date with security patches for your virtualization software, the
operating system of your physical host, and the tools you use for examining malware.
To further minimize the attack surface of the laboratory environment, disable risky capabilities related to
your virtualization software. For instance, consider disabling folder sharing that VMware supports, to
make it less likely that malware can exploit such a feature to break out of the VM. To further reduce the
risk, consider avoiding the installation of VMware Tools altogether.


Malware might try to determine whether it is being analyzed.
• Malware might include "self-defending" capabilities:

Ł Detect virtualization, monitoring, analysis tools
Ł Detect or confuse code analysis tools such as debuggers and disassemblers
• If a malicious process detects that it's being analyzed, it might:
Ł Terminate itself
Ł Put itself to sleep
Ł Interfere with analysis tools
Ł Exhibit different characteristics
• Such approaches help malware evade detection and complicate
the analysis process.
Because we're talking about virtualization, it's worth mentioning that some malware might include
evasive "self-defending" capabilities to detect whether it's being analyzed. This capability might entail
recognizing the use of virtualization and spotting other malware analysis utilities that are part of your
toolkit. Such approaches make it harder for automated tools to spot the specimen. They also make it
harder for malware analysts to examine its functionality.
If malware believes it's being analyzed, it may try to terminate the offending tools, refuse to run, or
behave differently from how it would a non-laboratory system.


There are ways to deal with malware that detects analysis tools.
• You could use a physical, not a virtual system.

• You might tweak the virtual machine's settings by editing its .vmx
file to fool some VM-detection approaches.
• You could modify the code that attempts to "defend" the
malicious program.
• We cover specific examples and countermeasures for such
situations later in the course.
There are several ways to deal with malware that detects the presence of our analysis tools. For instance,
you can use a dedicated physical system for performing your analysis instead of using a virtualization
tool.
Another practical option is to edit the malicious executable so that the code that looks for the analyst's
tools never has a chance to run. This powerful technique can remove debugger and virtualization-
detecting functionality from the specimen. Editing compiled executables is known as patching; we cover
this topic in another section of the course.
You have another option for some VMware-aware code. Tom Liston and Ed Skoudis documented several
settings you can add to the .vmx file of the virtual machine to make it more difficult for malicious code to
detect the presence of VMware. However, these options aren't practical to use on a regular basis, in part
because they drastically slow down the performance of the VM. Tom and Ed outlined these options and
various techniques for detecting malware in the following paper:
http://handlers.sans.org/tliston/ThwartingVMDetection_Liston_Skoudis.pdf.


Consider how to save and restore the state of your system.
• You need the ability to revert to a

clean state after your analysis.
• Also, take periodic snapshots during
the investigation to go back and
forth.
• Maintaining different states of a
pristine lab system is also useful.
• Virtualization software makes this
convenient via snapshots.
When preparing your lab, consider how you can save and restore the state of your system before you
infect it. After all, you wouldn't want to install the operating system and your tools from scratch at the end
of your experiment. Virtualization software provides a convenient mechanism for doing this. Such
software enables you to take an almost instantaneous snapshot of the virtual machine, and it gives you the
ability to revert to that snapshot almost as quickly.
You'll probably want to take a snapshot of your VM while it's still clean. In addition, you might take
snapshots periodically as you progress through the analysis process, in case you'd like to repeat some of
your steps without having to start from the beginning. Conveniently, VMware Workstation and Fusion
enable analysts to take multiple snapshots of the VM.
Snapshots also help maintain different noninfected versions of the VM. For instance, you might
periodically apply security patches to your laboratory systems. Snapshots of the various patch levels
enable you to experiment with malware in different environments, which is especially useful for
examining malicious programs that exploit known vulnerabilities.
We will certainly make use of snapshots in this course while working on hands-on exercises.


0Dozduh$Qdo/Vlv) Xqgdphqwdov

Uploaded by

Copyright:

Available Formats

You might also like

0Dozduh$Qdo/Vlv) Xqgdphqwdov

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

0Dozduh$Qdo/Vlv) Xqgdphqwdov

Uploaded by

Copyright:

Available Formats

© SANS Institute 2018

© 2002-2018 Lenny Zeltser | All Rights Reserved | Version D01_01

© 2018 Lenny Zeltser 1

• Refer to the instructions in your Workbook, Section 0.

FOR610 | REVERSE-ENGINEERING MALWARE 2

2 © 2018 Lenny Zeltser

• FOR610.1: Malware Analysis 1. Introduction to Malware Analysis

FOR610 | REVERSE-ENGINEERING MALWARE 3

© 2018 Lenny Zeltser 3

FOR610 | REVERSE-ENGINEERING MALWARE 4

4 © 2018 Lenny Zeltser

• Malicious software is an integral component of many security

Malware is code that is used to perform malicious actions.

FOR610 | REVERSE-ENGINEERING MALWARE 5

© 2018 Lenny Zeltser 5

• Assess the nature of malware threats.

Is there a difference between reverse-engineering malware and malware analysis?

FOR610 | REVERSE-ENGINEERING MALWARE 6

6 © 2018 Lenny Zeltser

• Compiled Windows executables

FOR610 | REVERSE-ENGINEERING MALWARE 7

(The image on this slide is based on the image by NLshop: https://www.fotolia.com/id/13374457.)

© 2018 Lenny Zeltser 7

FOR610 | REVERSE-ENGINEERING MALWARE 8

8 © 2018 Lenny Zeltser

Manual code reversing

Harder Interactive behavior analysis

Static properties analysis

Fully automated analysis

FOR610 | REVERSE-ENGINEERING MALWARE 9

© 2018 Lenny Zeltser 9

Input to REM staff: Output from REM staff:

• Verbal reports • What malware does

FOR610 | REVERSE-ENGINEERING MALWARE 10

10 © 2018 Lenny Zeltser

• Determine how detailed and formal the output of your malware

FOR610 | REVERSE-ENGINEERING MALWARE 11

© 2018 Lenny Zeltser 11

FOR610 | REVERSE-ENGINEERING MALWARE 12

12 © 2018 Lenny Zeltser

• Malware data repositories: VirusTotal, #totalhash

FOR610 | REVERSE-ENGINEERING MALWARE 13

© 2018 Lenny Zeltser 13

FOR610 | REVERSE-ENGINEERING MALWARE 14

14 © 2018 Lenny Zeltser

FOR610 | REVERSE-ENGINEERING MALWARE 15

© 2018 Lenny Zeltser 15

FOR610 | REVERSE-ENGINEERING MALWARE 16

16 © 2018 Lenny Zeltser

• Open-source intelligence (OSINT) is information collected from

FOR610 | REVERSE-ENGINEERING MALWARE 17

© 2018 Lenny Zeltser 17

• It might be a bad idea to upload a sensitive file to a third party.

FOR610 | REVERSE-ENGINEERING MALWARE 18

18 © 2018 Lenny Zeltser

• FOR610.1: Malware Analysis 1. Introduction to Malware Analysis

FOR610 | REVERSE-ENGINEERING MALWARE 19