Create A File That Brbbot - Exe Might Understand and Allow The Specimen To Download It
Create A File That Brbbot - Exe Might Understand and Allow The Specimen To Download It
Create A File That Brbbot - Exe Might Understand and Allow The Specimen To Download It
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.
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.
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.
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.
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).
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.
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.
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.
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.
• 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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
This is the end of Section 1, Malware Analysis Fundamentals, of the FOR610 course.
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