© SANS Institute 2018

Create a file that brbbot.exe might understand and allow the

specimen to download it.

• Create ads.php file on REMnux in /var/www.

• Use httpd to accept HTTP connections.
• Use fakedns to redirect to REMnux.
• Reinfect the Windows VM with brbbot.exe.
• Observe the effects using Process Hacker.

FOR610 | REVERSE-ENGINEERING MALWARE 104

Let's create a file on REMnux upon which brbbot.exe might act, and then allow the specimen to
download it.

First, if your Windows REM Workstation currently has the brbbot.exe process active, terminate that
process.

Consider the "cexe" keyword we discovered in the brbconfig.tmp file, which corresponded to the "exec"
action. Such a command would typically accept a path to the executable that the attacker would want to
execute on the infected system. Therefore, we can experiment with this specimen's C2 mechanism by
creating an ads.php file with the following contents:

cexe c:\windows\notepad.exe

In this case, if our assumption about the syntax expected by brbbot.exe is correct, the attacker would
instruct the specimen to run Notepad on the infected system. To create this file on REMnux, change into
the directory where the REMnux web server expects to find its files: /var/www. Then, create the file using
the echo command as shown on this slide.

The web server should already be running in the background on your REMnux system from our earlier
experiments. If it's not running, or if you are not sure whether it's running, run the command httpd
start. Also, fakedns should already be running from our earlier experiments. If it's not running, run the
fakedns command.

On your Windows REM Workstation, launch Process Hacker 

if it isn't

already running. Then, reinfect the
virtual machine with brbbot.exe. You should observe an instance of Notepad launching on the infected
VM. Note that the specimen seems to download ads.php every 30 seconds. You could confirm this by
sniffing the network using Wireshark. Therefore, it will spawn a new notepad.exe process every half a
minute. You can observe these activities using Process Hacker.

104 © 2018 Lenny Zeltser

 © SANS Institute 2018
Send the exit command (tixe) to terminate brbbot.exe.

• You can direct the specimen to

terminate its process.
• Note that Notepad instances persist
even after the parent process exits.
• When you're done, stop the REMnux
web server (httpd stop).

FOR610 | REVERSE-ENGINEERING MALWARE 105

As another experiment, you can check how brbbot.exe handles the exit command that, according to
brbconfig.tmp, is represented by the tixe keyword.

Before doing that, remove the ads.php file. Then, create a new version of that file to contain the tixe
keyword, as shown on the bottom of this slide.

When brbbot.exe receives this command in response to its HTTP GET request, the specimen's process
exits. You can observe this using Process Hacker, as illustrated on the right side of this slide.

After you've confirmed that brbbot.exe received the exit command, turn off the web server on REMnux
by issuing the httpd stop command in the REMnux terminal window. This way, if you experiment
with brbbot.exe later, it will have a chance to run instead of immediately exiting when it downloads the
tixe command through the ads.php file.

   

© 2018 Lenny Zeltser 105

 © SANS Institute 2018
Understanding the specimen's C2 capabilities helps assess the
nature of the incident in which it was involved.

• The adversary can use brbbot.exe to execute arbitrary commands

on the infected system.
• C2 functionality is based on polling the malicious web server.
• These capabilities are useful for using brbbot.exe as a backdoor
and could be used for controlling a large botnet.
• The attacker can modify keywords that correspond to commands,
potentially invalidating our network IOCs.
• This specimen is likely early in the infection chain, and allows the
adversary to perform reconnaissance and enables further attacks.

FOR610 | REVERSE-ENGINEERING MALWARE 106

After completing the recent steps in exploring brbbot.exe's C2 capabilities, we have a reasonably solid
understanding of the specimen's capabilities, which inform our understanding of the context within which
this malicious software is likely used. These findings are based on the combination of behavioral and
code analysis steps that we've been performing throughout this section.

We've just confirmed that brbbot.exe receives commands from the adversary by downloading a file
through an outbound HTTP request. The commands enable the attacker to take several actions on the
infected system, including executing arbitrary programs on the infected system. These capabilities allow
the adversary to use brbbot.exe as a backdoor for controlling an individual host. Moreover, this C2
mechanism could be used for controlling a large number of infected hosts (let's call them a botnet)
because each of them will be able to connect to the malicious web server, download the ads.php file, and
act according to its contents.

Earlier analysis also indicated that the adversary can change the keywords that represent C2 commands
through the brbconfig.tmp file. This means that if we created IOCs (or network intrusion detection
signatures) that look for keywords such as cexe or tixe, we might fail to locate brbbot.exe's activities if the
adversary supplies the specimen with a different configuration file.

Overall, the capabilities of brbbot.exe make it a useful tool for performing malicious actions relatively
early in the infection chain. The type of data it exfiltrates is useful for performing reconnaissance because
it enables the adversary to identify the most interesting system about those that were infected and prepare
the next set of malicious tools to attempt bypassing the security measures on that endpoint. In other
words, if you spotted brbbot.exe being used in your environment, there is a reasonable chance that you've
caught the adversary relatively early in his efforts to compromise
  you.
 

106 © 2018 Lenny Zeltser

 © SANS Institute 2018
How might we intercept and analyze an encrypted HTTPS
connection, such as the one initiated by ghyte.exe?

• Let's look at another sample. EXERCISE 1.6

• Wireshark wouldn't show HTTPS payload

even if the connection completed.

FOR610 | REVERSE-ENGINEERING MALWARE 107

In the case of brbbot.exe, we were dealing with HTTP connections, which we could examine using a
network sniffer with the help of DNS and web services running on REMnux. What if we had encountered
an encrypted HTTPS connection instead? Consider the following malware sample, titled ghyte.exe. It's in
the day1 folder in your malware archive.

Before proceeding, revert your Windows REM Workstation virtual machine to its pristine state.

On REMnux, begin capturing network traffic using Wireshark. Launch fakedns. Then, infect your
Windows REM Workstation with ghyte.exe by double-clicking on its file. Wireshark should show that
the infected system is attempting to connect to a host on TCP port 443 after resolving the hostname
talonstamed.com. Most likely, the malicious program is attempting to reach this web server via HTTPS.

For another perspective on these sets of events, open Process Hacker and go to the Network tab. As you
can see in the screenshot at the bottom of the slide, this tool shows the malicious process attempting to
talk to the REMnux VM, which it thinks is talonstamed.com, on TCP port 443. The process is sending
SYN packets to initiate the connection. The REMnux VM isn't completing the connection because we
didn't launch a TCP port 443 listener there.

   

Even if REMnux was listening for such connections, Wireshark in its standard configuration wouldn't be
able to show us the connection payload, since HTTPS contents are encrypted.

© 2018 Lenny Zeltser 107

 © SANS Institute 2018
We can observe HTTPS contents from either endpoints of the
connection; INetSim can help us do this from the server side.

• INetSim can emulate many protocols, including HTTP, HTTPS,

SMTP, FTP, POP3, TFTP, IRC, and more.
• You can tweak its configuration by editing the
/etc/inetsim/inetsim.conf file on REMnux.
Ł Enable and disable emulators
Ł Adjust response options
• INetSim on REMnux saves detailed logs in /var/log/inetsim.
• It keeps files used by its emulators in /var/lib/inetsim.
• Use it in conjunction with fakedns or enable its built-in DNS
emulator by editing inetsim.conf.
FOR610 | REVERSE-ENGINEERING MALWARE 108

Because we have full control over all systems in the malware analysis lab, we could "spy" on malicious
HTTPS connections in our environments from two perspectives: We can observe the data being wrapped
into HTTPS from the Windows client before the data gets encrypted. Alternatively, we can observe the
data after its gets decrypted from the REMnux server. A convenient way to utilize the latter approach
involves INetSim, which can emulate HTTPS and many other network protocols, including SMTP, FTP,
POP3, TFTP, and IRC.

You can obtain a free copy of INetSim from http://www.inetsim.org. It is also installed on REMnux.
Following are the REMnux locations of the important files that INetSim uses:

• /etc/inetsim/inetsim.conf is the main configuration file of INetSim. It enables you to define which
services INetSim should emulate. It also enables you to define service-specific options, such as
listening ports, static DNS mappings, HTTP response parameters, SSL configuration details, and
so on.
• /var/log/inetsim contains the INetSim log files. The most useful of these files is probably
service.log, which contains details about the requests INetSim received and the responses it
provided.
• /var/lib/inetsim contains data files used by INetSim emulators, such as the files provided by the
HTTP emulator or the certificate used for SSL encryption for the HTTPS emulator.

As done earlier in the course, you can use fakedns to redirect malicious network connections to REMnux.
Alternatively, you can enable the DNS emulator built into INetSim by editing the inetsim.conf file,
removing the comment mark from the line start_service dns, and changing the dns_default_ip
value to point to the IP address of your REMnux system.
   

To avoid any conflicts, turn off any tools on REMnux that might be using the ports INetSim wants to use
or that otherwise conflict with INetSim, including the web server (httpd stop).

108 © 2018 Lenny Zeltser

 © SANS Institute 2018
Activate INetSim; then reinfect the system with ghyte.exe.

• Terminate the ghyte.exe process.

• Keep fakedns running on REMnux.
• Stop httpd on REMnux, if it's still running.
• Launch INetSim on REMnux.
• Reinfect the Windows VM with ghyte.exe.
• Look for connection details in
/var/log/inetsim/service.log.

What are the specimen's web connection properties?

FOR610 | REVERSE-ENGINEERING MALWARE 109

Is ghyte.exe indeed going to use HTTPS for the TCP port 443 connection we just observed? If so, what
will be the details of the connection to the web server? To answer these questions, we need to allow the
malicious program's connection to be established. INetSim will allow us to do this quite easily, in part
because it has a built-in HTTPS emulator.

Terminate the ghyte.exe process on your Windows REM Workstation.

Go to the REMnux virtual machine. Run the command httpd stop to stop the web server, in case it's
still active in the background.

Keep fakedns running in one terminal window. Open another terminal window and run the command
inetsim to activate INetSim.

With fakedns and INetSim running, reinfect your Windows REM Workstation with ghyte.exe.

   

© 2018 Lenny Zeltser 109

 © SANS Institute 2018
The specimen attempted to download and run another program.

• INetSim responded to the request by

serving a simple default executable.
• The specimen saved it into %Temp%
as ghyted.exe and executed it.
• Process Hacker confirms that
ghyte.exe acted as a downloader.

FOR610 | REVERSE-ENGINEERING MALWARE 110

When INetSim intercepts the specimen's network connection, you should see a popup on your Windows
REM Workstation, stating "This is the INetSim default binary" while the process named ghyted.exe runs.

This popup is the functionality of the Windows program that INetSim automatically provides in response
to a request to download an executable file from INetSim's web server. If this popup appears on the
infected system, that means ghyte.exe downloaded and executed the program, thinking that it obtained the
file from talonstamed.com.

You can see where the file ghyted.exe was saved by its presumptive parent ghyte.exe by using Process
Hacker. Right-click on ghyted.exe and select Properties; this will display the full path to the file. If you
look into the temporary folder (%Temp%), you will find the file ghyted.exe there.

Based on these observations, we can conclude that our specimen ghyte.exe appears to be looking to
download and execute the next malicious program in the infection chain.

   

110 © 2018 Lenny Zeltser

 © SANS Institute 2018
The /var/log/inetsim/service.log file shows connection details,
which offer useful IOCs and related insights.

recv: GET /images/1m6r.exe HTTP/1.1

recv: Accept: text/*, application/*
recv: User-Agent: Updates downloader
recv: Host: talonstamed.com
recv: Cache-Control: no-cache
info: Request URL: https://talonstamed.com/images/1m6r.exe
info: Sending fake file configured for extension 'exe'.
send: HTTP/1.1 200 OK
send: Server: INetSim HTTPs Server
send: Connection: Close

FOR610 | REVERSE-ENGINEERING MALWARE 111

To see the details of the connection established between ghyte.exe and INetSim's HTTPS emulator, take a
look at INetSim's log file /var/log/inetsim/service.log by issuing this command on REMnux:

more /var/log/inetsim/service.log

The log file, whose excerpt you can see on this slide, shows how ghyte.exe malware connected to what it
thought was talonstamed.com. Apparently, the specimen attempted to retrieve
https://talonstamed.com/images/1m6r.exe.

One slightly unusual aspect of the connection is the User-Agent "Updates downloader." We might use
this characteristic as an IOC to spot the presence of ghyte.exe on our organization's production networks.
The adversary might be using this common User-Agent string as a way of authenticating the downloader
to the malicious web server.

   

© 2018 Lenny Zeltser 111

 © SANS Institute 2018
Alternatively, you could've observed the connection from the
client side; Fiddler could have helped with this.

• Fiddler can intercept and display HTTP and HTTPS traffic from
the client side on Windows.
• Its powerful proxy-like debugging capabilities are also useful
when assessing web applications.
• If you don't have web services active on REMnux, you can use
Fiddler's autoresponder to generate HTTP and HTTPS responses.

FOR610 | REVERSE-ENGINEERING MALWARE 112

We used INetSim's HTTPS emulator to gain visibility into web connection contents tunneled through
HTTPS, accomplishing this by looking at the server side of the connection. An alternative to this
approach is to observe the connection from the client side. You can accomplish this by using Fiddler on
your Windows REM Workstation, which can conveniently intercept local HTTP and HTTPS traffic. For
this to work, Fiddler's HTTPS settings options (Tools > Fiddler Options…) need to be configured in the
manner shown in the bottom-left corner of this slide so that the checkboxes "Capture HTTPS
CONNECTs," "Decrypt HTTPS traffic," and "Ignore server certificate errors (unsafe)" are enabled.

Fiddler is available as a free download from https://www.telerik.com/download/fiddler. It's also installed

on your Windows REM Workstation.

Fiddler can automatically generate responses to HTTP and HTTPS requests, which is convenient in
situations in which you don't have the corresponding listeners active on REMnux. To enable this feature,
you need to go to the AutoResponder tab and enable the checkbox called "Enable rules," as shown on the
right side of this slide. You don't need to add any rules unless you want to modify the tool's automatic
responses.

   

112 © 2018 Lenny Zeltser

 © SANS Institute 2018
You can observe ghyte.exe traffic using Fiddler.

• Launch Fiddler and enable rules in AutoResponse.

• Make sure HTTPS traffic decryption is enabled.
• Infect the Windows VM with ghyte.exe.
• Review the Inspectors > Raw tab for connection details.

FOR610 | REVERSE-ENGINEERING MALWARE 113

After configuring Fiddler in a manner described on the previous slide, you can infect your Windows REM
Workstation with ghyte.exe while Fiddler is active.

The tool should intercept the specimen's HTTPS connection and display a line about the existence of this
connection on the left side of its screen. To see the properties, you need to select the HTTPS connection,
go to the Inspectors tab, and then go to the Raw tab. You'll see the same type of information that we
observed using INetSim, as shown on the left side of this slide.

If you perform this experiment, Windows will pop up an error that complains about an "Unsupported 16-
Bit Application." This happens because the response that Fiddler generates when handling the specimen's
GET request isn't a valid Windows executable file. The ghyte.exe file tries to execute what it thinks is
another malicious program; Windows is unable to do so.

   

© 2018 Lenny Zeltser 113

 © SANS Institute 2018
Be prepared to intercept malicious connections that use IPs
instead of hostnames.

• So far, we have relied on DNS to redirect and intercept malicious

connections in the lab, but what if malware uses IP addresses?
• Some malware (downloaders, backdoors, and such) uses hard-
coded IP addresses for outbound connections.
• Network worms might generate IP addresses at random when
seeking other systems to infect.
• We could try hard-coding specific IPs into our lab systems, but
this approach is too static.

FOR610 | REVERSE-ENGINEERING MALWARE 114

So far, when performing behavioral analysis, we have relied on the specimen resolving a hostname when
reaching out to the malicious server. This enabled us to easily redirect the connection using fakedns to a
lab system that we controlled. What if the sample is using an IP address instead of a hostname? There are
variants of bots, downloaders, backdoor malicious scripts, and other malware that attempt to connect to
their C2 or another type of a server using an IP address. Moreover, network worms often propagate by
generating random IP addresses when looking for potential targets. Learning how to redirect such IP-
based connections can help you deal with such scenarios.

If a specimen is connecting to a hard-coded IP address, you can configure a system on your laboratory
network to use that IP address. For instance, if malware were looking to connect 91.200.13.20, you could
configure your REMnux virtual machine to use that IP address instead of the one assigned to it by the
VMware DHCP server. One way to do this on REMnux is to use the command set-static-ip
91.200.13.20. You also need to configure your Windows laboratory system, which you will infect, to
follow a compatible IP addressing scheme. For instance, in this example, you could assign the IP address
of 91.200.13.21 to the Windows virtual machine, assuming you use the subnet mask 255.255.255.0.

However, statically assigning IP addresses in this manner is cumbersome. Moreover, this approach
doesn't handle scenarios in which malware is generating IP addresses at random or is attempting to
connect to multiple IP addresses. Let's look at one such example, and then experiment with a technique
that can assist with such scenarios.

   

114 © 2018 Lenny Zeltser

 © SANS Institute 2018
What will this juice.exe specimen do if one of its many IP-based
connections is established?

FOR610 | REVERSE-ENGINEERING MALWARE 115

Consider the malware sample titled juice.exe.

If you infected your Windows REM Workstation virtual machine with this specimen, Wireshark would
show that the infected host appears to be scanning the network by generating IP addresses at random. A
small portion of these activities is captured on this slide. Each connection attempt involves a SYN packet
directed at TCP port 3127. However, because our lab is unlikely to have a system that corresponds to
these IP addresses, even if REMnux was listening on that port, the connections cannot be established.

For another perspective on these scans, you could look at Process Hacker's Network tab. As shown on the
bottom-right portion of this slide, the juice.exe process is, indeed, reaching out to many different IP
addresses on TCP port 3127.

You might want to find out what this specimen will do after it successfully establishes at least one of
these connections. What payload will be sent across the network in that case? To find out, we need to find
a way to intercept such IP address-based connections in our lab.

   

© 2018 Lenny Zeltser 115

 © SANS Institute 2018
NAT capabilities of iptables can redirect traffic going to any IP to
the corresponding local port.

• In your lab, the Windows VM should already be configured to use

the REMnux VM as its default gateway.
• To enable iptables redirection, you'd use
iptables -t nat -A PREROUTING -i eth0 -j REDIRECT

• To disable iptables redirection, you'd use

iptables -t nat -D PREROUTING -i eth0 -j REDIRECT

• On REMnux, you can do this using commands

accept-all-ips start and accept-all-ips stop

• Start a listener on the port where you expect to receive traffic.

FOR610 | REVERSE-ENGINEERING MALWARE 116

You might already be familiar with iptables, which is a powerful Linux-based firewall software. Its
capabilities include Network Address Translation (NAT), which we can use to intercept and redirect
network connections going to all possible IP addresses. We can use iptables in this manner on REMnux,
directing it to redirect traffic to the corresponding local port on the REMnux VM. (A variation of this
technique is outlined at https://techanarchy.net/2013/10/inetsim-and-ip-addresses.)

To use iptables for such interception, your Windows virtual machine needs to be configured to point to
the REMnux virtual machine's IP as its default gateway. You've done that when setting up your lab in the
beginning of this course.

To enable iptables traffic redirection on most Linux systems, you can use this command:
iptables -t nat -A PREROUTING -i eth0 -j REDIRECT

To disable this capability, you could reboot the Linux system or enter the following command:
iptables -t nat -D PREROUTING -i eth0 -j REDIRECT

On REMnux, an easier way to accomplish this is to use the accept-all-ips command, as shown at the
bottom of the slide. This is a wrapper script around iptables. In addition to enabling IPv4 traffic
redirection, the script also instructs iptables to handle IPv6 traffic.

After enabling iptables redirection, remember to launch a listener on REMnux on the port where you
expect to receive traffic. For instance, start a web server to listen on TCP port 80 to intercept HTTP traffic
or use Netcat to listen to a less common port, such as 3127.
   

116 © 2018 Lenny Zeltser

 © SANS Institute 2018
Activate iptables and Netcat on REMnux in the following manner;
then reinfect the Windows VM with juice.exe.

FOR610 | REVERSE-ENGINEERING MALWARE 117

Now that we know iptables can help us intercept network traffic that uses IP addresses, rather than
hostnames, let's see how we can use this technique with the juice.exe sample. It's in the day1 folder of
your malware archive, though the steps outlined here for this sample are not documented as a formal
exercise.

First, we need to enable interception using the command accept-all-ips start on REMnux. Our
earlier observations showed that juice.exe attempts to connect to TCP port 3127. Because we don't know
what protocol the specimen expects to use for this connection, our best approach might be to use Netcat
(https://nmap.org/ncat). This versatile tool has many capabilities. We'll use its capability to listen on an
arbitrary port. When in this mode, Netcat will accept a connection on the port you designate, and send
whatever data it receives as a payload of that connection to STDOUT.

In our example, we launch Netcat with the parameter -l (that's lowercase L), which tells it to listen, and
with the parameter -p, which specifies the listening port number. Optionally, we could have also added
the -n parameter, which would have directed Netcat to avoid trying to resolve the connecting IP
addresses to hostnames. In this example, we've also redirected the output of Netcat to a file named out.

Once iptables redirection is active on REMnux, you can reinfect the Windows VM with juice.exe. Thanks
to iptables, Netcat will receive one of the specimen's connections and save the payload of the connection
to a file.

You can use xxd to view contents of a binary file, such as one containing connection payload, into a
readable hex dump. As you can see on this slide, xxd shows us what data that juice.exe sent to our system
over TCP port 3127. The presence of the letters "MZ" and the string
 "This program
 cannot be run in DOS
mode" suggest that this a Windows executable because this is a classic PE file pattern. The "MZ"
character sequence is part of the PE header structure that carries the MS-DOS compatible header data and
designates this file as an MS-DOS compatible program.

© 2018 Lenny Zeltser 117

 © SANS Institute 2018
Wireshark findings corroborate those we saw via Netcat.

The sequence 85 13 3c 9e a2 corresponded to another specimen's

command "upgrade," which juice.exe was using to propagate copies of itself.

FOR610 | REVERSE-ENGINEERING MALWARE 118

If Wireshark was running during the infection step discussed on the previous slide, it would confirm that
the malicious system successfully established the network connection that enabled us to capture the
payload using Netcat. In the illustration on this slide, you can see the successful completion of the TCP
handshake between the infected system in the lab (192.168.87.135) and the host it is trying to reach
(190.251.74.1). Though 190.251.74.1 isn't actually present in our lab, iptables allowed us to mimic its
existence and intercept this connection.

You could look at the connection's contents using the Follow TCP Stream feature of Wireshark. You'd
see the same payload that we observed using Netcat. Notice that the embedded executable file actually
starts a few bytes into the payload (with the characters "MZ"). Earlier in the payload, we see hexadecimal
values 85 13 3c 9e a2. Searching the web for that sequence reveals a few mentions of the worms
MyDoom and DoomJuice, which spread across the internet a while ago.

We're looking at malware samples that one might describe as "classic" nowadays, in part because it gives
us the opportunity to discuss the innovative way in which it was spreading. The file juice.exe corresponds
to the network worm named DoomJuce. Its way of spreading involved scanning for systems infected with
another worm called MyDoom and taking them over. MyDoom infected lots of servers on the internet in
its day, setting up a backdoor on TCP port 3127. DoomJuice scanned for MyDoom-infected systems and
sent them the MyDoom "upgrade" command, directing those systems to displace MyDoom with
DoomJuice. The malicious executable embedded into the connection we just observed was a copy of
DoomJuice malware that in our example exists as the file named juice.exe itself.

If you were dealing with DoomJuice at the time, or if you encountered a more recent program that was
propagating by connecting to randomly generated IP addresses,
 you'd
 be ableto make this assessment
through behavioral techniques by redirecting the connections to a laboratory system that was listening on
the targeted port, just like we've done in this example.

118 © 2018 Lenny Zeltser

 © SANS Institute 2018
Another example: Intercepting getdown.exe with iptables.

• The specimen getdown.exe attempts

EXERCISE 1.7
to connect to TCP port 80 (HTTP)
using a hard-coded IP address.
• What URL does getdown.exe use for
the HTTP request?
• Intercept the traffic using iptables
and, if time permits, Fiddler.

FOR610 | REVERSE-ENGINEERING MALWARE 119

To gain experience with iptables, take a look at the malware specimen getdown.exe, located in
day1\getdown.zip on your malware archive. Examine its network connection properties using behavioral
analysis techniques.

If you infect your Windows REM Workstation using this specimen, you should notice it attempting to
connect to 1.234.27.146 on TCP port 80. Given this port number, we can assume that the malicious
program wants to use HTTP for this network connection. (Sometimes, malware might use a well-known
port such as 80 for another protocol, so be careful to validate such assumptions.)

Confirm that the bot wants to use HTTP by allowing that connection to be established. Also, determine
the properties of the HTTP connection—namely, the URL that the specimen wants to use as part of the
HTTP request.

To answer these questions, use iptables to intercept the specimen's TCP port 80 traffic and redirect it to a
web server running on REMnux. If time permits, try using Fiddler for this, too.

   

© 2018 Lenny Zeltser 119

 © SANS Institute 2018
Use iptables to redirect the HTTP connection initiated by
getdown.exe to your web server.

• Remember to start the web server using: httpd start

• Activate iptables redirection using: accept-all-ips start

• Use Wireshark to observe the HTTP request.

• Infect your Windows VM with getdown.exe.
• When done, stop the analysis tools and examine Wireshark logs.

FOR610 | REVERSE-ENGINEERING MALWARE 120

Use iptables to redirect the specimen's outbound network connection to your lab's web server. To do this,
start the web server on REMnux (httpd start), and then activate iptables redirection (accept-all-
ips start).

After the lab environment has been set up, launch Wireshark, infect your Windows REM Workstation
with getdown.exe, and observe the HTTP connection details using Wireshark.

As a reminder, make sure that TCP/IP settings on your Windows REM Workstation are configured to use
the IP address of your REMnux VM as its default gateway. You should have done this when initially
setting up your lab.

   

120 © 2018 Lenny Zeltser

 © SANS Institute 2018
Wireshark shows HTTP connection details.

FOR610 | REVERSE-ENGINEERING MALWARE 121

Infecting the laboratory system with getdown.exe should demonstrate that it is attempting to connect to
1.234.27.146 on TCP port 80. To determine protocol level details of the resulting connection, you need to
make sure that the TCP connection gets successfully established with the help of iptables.

As you can see on this slide, the infected system (192.168.87.135) issues an HTTP GET request to the
web server it believes runs on 1.234.27.146. The GET attempts to retrieve the URL
/pcfix.exe?affid=23456732-34459 from the web server. If the web server contained the pcfix.exe file,
getdown.exe would retrieve it and—as you could determine through further analysis—execute it on the
infected system.

Note that the GET request includes a unique-looking string that seems to be an Affiliate ID (affid). The
attacker might use this ID to identify the infection campaign or the entity that is distributing the malicious
program. This could be a way to determine who should get paid for infecting the system with a copy of
pcfix.exe.

If you select one of the packets corresponding to this HTTP session and click Follow TCP Stream, the
sniffer displays the data exchanged as part of the HTTP request. As you can see on this slide, the server
responded with Not Found to the specimen's request for pcfix.exe.

When you finish, exit Wireshark, stop the web server (httpd stop) and disable iptables redirection
(accept-all-ips stop). Also, terminate the getdown.exe process on your Windows virtual machine
if it is still running.

   

© 2018 Lenny Zeltser 121

 © SANS Institute 2018
Fiddler also could have captured this information.

FOR610 | REVERSE-ENGINEERING MALWARE 122

Instead of using iptables, the REMnux web server, and Wireshark, you could have used Fiddler to
intercept the specimen's HTTP connection and examine its details. As you can see on this slide's
screenshot, Fiddler can show the full HTTP request that getdown.exe sent out.

   

122 © 2018 Lenny Zeltser

 © SANS Institute 2018
Consider the following additional tools intercepting and analyzing
network connections in your lab.

• TcpLogView: Maintains a historical log of local TCP

connections, showing which process handled which connection.
• PE Capture: Records and captures local PE files that try to run.
• ApateDNS: DNS server for redirecting hostname resolution
requests; similar to fakedns but runs on Windows.
• FakeNet-NG: Intercepts network traffic in the lab, emulating
common protocols; similar to INetSim but runs on Windows.

FOR610 | REVERSE-ENGINEERING MALWARE 123

We covered several useful tools that can assist in your behavioral interactions with malicious software.
Here are a few additional utilities you might want to include in your toolkit.

TcpLogView maintains a historical log of TCP connections that have taken place on the local host. Like
Process Hacker, it shows socket information and includes the name and ID of the process responsible for
the connection. Process Hacker's Network tab shows these details only in real time, so if the connection
occurred before you glanced there, you wouldn't see it. TcpLogView is installed on your Windows REM
Workstation and is available free from http://www.nirsoft.net/utils/tcp_log_view.html. Note that for
outbound activity, TcpLogView shows only those connections that have been established, having
completed the TCP handshake. As the result, if a specimen is performing a SYN scan of the network, this
activity won't show up in the TcpLogView log. Also, the tool won't show non-TCP (for example, UDP)
traffic.

PE Capture captures any PE file that tries to run on the system. This tool can be useful for gaining
visibility and capturing various components of the malicious program you're analyzing. You can
download this free tool from http://www.novirusthanks.org/products/pe-capture.

ApateDNS is an alternative to fakedns. It runs on the Windows host you're infecting. Therefore, it's very
convenient. However, malware might detect and interfere with it. It's available as a free download from
https://www.fireeye.com/services/freeware/apatedns.html.

FakeNet-NG offers a convenient way of intercepting and redirecting network connections, much like
INetSim. FakeNet-NG can also emulate common network protocols. This tool is available as a free
download from https://github.com/fireeye/flare-fakenet-ng.
  The bottom
 of this slide offers a glimpse at
this tool as it intercepted a local connection made by the getdown.exe specimen.

© 2018 Lenny Zeltser 123

 © SANS Institute 2018
Interacting with malware helps you understand its functionality
and is often intertwined with other analysis techniques.

• We learned how to intercept and redirect different types of

malicious network connections in the lab.
• This helps us explore and understand functionality such as the C2
mechanics or downloader details.
• It's useful to be able to emulate common protocols that malicious
programs might want to speak.
• These techniques help prove or disprove earlier behavioral and
code-level theories and bring forth additional findings.

FOR610 | REVERSE-ENGINEERING MALWARE 124

We covered several techniques for interacting with malicious programs while they run in your lab to
better understand their behavior. This often involved intercepting and redirecting network connections to
laboratory resources under our control. When necessary, we activated services that the malicious software
was attempting to reach, or emulated such services on the REMnux VM. We've seen how such
approaches can help us explore malicious functionality such as C2 mechanics and downloader details. We
employed these approaches to validate the theories we formulated during earlier behavioral and code
analysis phases, as well as to identify new attributes of malicious software.

   

124 © 2018 Lenny Zeltser

 © SANS Institute 2018
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

FOR610 | REVERSE-ENGINEERING MALWARE 125

This is the end of Section 1, Malware Analysis Fundamentals, of the FOR610 course.

   

© 2018 Lenny Zeltser 125

 © SANS Institute 2018
COURSE RESOURCES AND CONTACT INFORMATION

AUTHOR CONTACT
SANS INSTITUTE
Lenny Zeltser
11200 Rockville Pike, Suite 200
lenny@zeltser.com
N. Bethesda, MD 20852
zeltser.com/blog
301.654.SANS(7267)
Twitter: @lennyzeltser

SANS EMAIL
DFIR RESOURCES GENERAL INQUIRIES: info@sans.org
digital-forensics.sans.org REGISTRATION: registration@sans.org
Twitter: @sansforensics TUITION: tuition@sans.org
PRESS/PR: press@sans.org

FOR610 | REVERSE-ENGINEERING MALWARE 126

This page intentionally left blank.

   

126 © 2018 Lenny Zeltser