. and compare them with the raw beacon packet at the beginning of the analysis. Do you notice the repeated User-Agent: User-Agent: in the beacon packet? Although it looks correct in the strings output, the malware author made a mistake and forgot that the InternetOpenA call includes the header title. This oversight will allow for an effective signature.Let’s first identify the beacon content, and then we will investigate how the malware processes a response. We see that the networking function at 0x004011F3 takes two parameters, only one of which is used before the InternetOpenUrlA call. This parameter is the URL that defines the beacon destination. The parent function is WinMain, which contains the primary loop with a Sleep call. Tracing the URL parameter backward within WinMain, we see that it is set in the function at 0x00401457, which contains a CreateFile call. This function (0x00401457) references a couple of strings, including C:\\autobat.exe and http://www.practicalmalwareanalysis.com/start.htm. The static URL (ending in start.htm) appears to be on a branch that represents a failure to open a file, suggesting that it is the fallback beaconing URL if the file does not exist.
Examining the CreateFile function, which uses the reference to C:\\autobat.exe, it appears as if the ReadFile command takes a buffer as an argument that is eventually passed all the way back to the InternetOpenUrlA function. Thus, we can conclude that autobat.exe is a configuration file that stores the URL in plaintext.
Having identified all of the source components of the beacon, navigate back to the original call to identify what can happen after some content is received. Following the InternetReadFile call at 0x004012C7, we see another call to strstr, with one of the parameters being <no. This strstr function sits within two loops, with the outer call containing the InternetReadFile call to obtain more data, and the inner call containing the strstr function and a call to another function (0x00401000), which is called when we find the <no string, and which we can presume is an additional test of whether we have found the correct content. This hypothesis is confirmed when we examine the internal function.
shows a test of the input buffer using a chain of small connected blocks. The attacker has tried to disguise the string he is looking for by breaking the comparison into many small tests to eliminate the telltale comparison string. Additionally, notice that the required string (<noscript>) is mixed up in order to avoid producing an obvious pattern. The first three comparisons in are the n in position 0, the i in position 5, and the o in position 1.
Two large comparison blocks follow the single-byte comparisons. The first contains a search for the / character, as well as a string comparison (strstr) of two strings, both of which are passed in as arguments. With some .
The 'd' function calls both URLDownloadToCacheFileA and CreateProcessA, and looks very much like the code from . The URL is provided by the output of the shared function in (0x00401147), which we can now assume is some sort of decoding function. The 'r' function also uses the encoding function, and it takes the output and uses it in the function at 0x00401372, which references CreateFile, WriteFile, and the same C:\\autobat.exe configuration file referenced earlier. From this evidence, we can infer that the intent of the 'r' function is to redirect the malware to a different beacon site by overwriting the configuration file.
.). Since the attacker made a mistake by including an extra User-Agent:, the obvious signature to target is the specific User-Agent string with the additional User-Agent header:.), so we will target these two commands together:alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"PM14.3.3 Download or Redirect Command"; content:"/08202016370000"; pcre:"/\/[dr][^\/]*\/ 08202016370000/"; sid:20001433; rev:1;)
This signature uses the string 08202016370000, which we previously identified as the encoded representation of http://. The PCRE rule option includes this string and forward slashes, and the d and r that indicate the download and redirect commands. The \/ is an escaped forward slash, the [dr] represents either the character d or r, the [^\/]* matches zero or more characters that are not a forward slash, and the \/ is another escaped slash.
The quit command by itself only has one known character, which is insufficient to target by itself. Thus, the last command we need to target is sleep, which can be detected with the following signature:
alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"PM14.3.4 Sleep Command"; content:"96'"; pcre:"/\/s[^\/]{0,15}\/[0-9]{2,20}96'/"; sid:20001434; rev:1;)Since there is no fixed content expression target to provide sufficient processing performance, we will use one element from outside the command string itself (the 96') to achieve an efficient signature. The PCRE identifies the forward slash followed by an s, then between 0 and 15 characters that are not a forward slash ('[^\/]{0,15}), a forward slash, and then between 2 and 20 digits plus a trailing 96'.
Note that the upper and lower bounds on the number of characters that will match the regular expression are not being driven by what the malware will accept. Rather, they are determined by a trade-off between what is reasonably expected from an attacker and the costs associated with an unbounded regular expression. So while the malware may indeed be able to accept a sleep value of more than 20 digits, it is doubtful that the attacker would send such a value, since that translates to more than 3 trillion years. The 15 characters for the term starting with an s assumes that the attacker would continue to choose a single word starting with s, though this value can certainly be increased if a more foolproof signature is needed.
Назад: Lab 14-2 Solutions
Дальше: Lab 15-1 Solutions
Войти в систему
Войти с помощью соц. сетей:
User-Agent: User-Agent: in the beacon packet? Although it looks correct in the strings output, the malware author made a mistake and forgot that the InternetOpenA call includes the header title. This oversight will allow for an effective signature.Let’s first identify the beacon content, and then we will investigate how the malware processes a response. We see that the networking function at 0x004011F3 takes two parameters, only one of which is used before the InternetOpenUrlA call. This parameter is the URL that defines the beacon destination. The parent function is WinMain, which contains the primary loop with a Sleep call. Tracing the URL parameter backward within WinMain, we see that it is set in the function at 0x00401457, which contains a CreateFile call. This function (0x00401457) references a couple of strings, including C:\\autobat.exe and http://www.practicalmalwareanalysis.com/start.htm. The static URL (ending in start.htm) appears to be on a branch that represents a failure to open a file, suggesting that it is the fallback beaconing URL if the file does not exist.
Examining the CreateFile function, which uses the reference to C:\\autobat.exe, it appears as if the ReadFile command takes a buffer as an argument that is eventually passed all the way back to the InternetOpenUrlA function. Thus, we can conclude that autobat.exe is a configuration file that stores the URL in plaintext.
Having identified all of the source components of the beacon, navigate back to the original call to identify what can happen after some content is received. Following the InternetReadFile call at 0x004012C7, we see another call to strstr, with one of the parameters being <no. This strstr function sits within two loops, with the outer call containing the InternetReadFile call to obtain more data, and the inner call containing the strstr function and a call to another function (0x00401000), which is called when we find the <no string, and which we can presume is an additional test of whether we have found the correct content. This hypothesis is confirmed when we examine the internal function.
shows a test of the input buffer using a chain of small connected blocks. The attacker has tried to disguise the string he is looking for by breaking the comparison into many small tests to eliminate the telltale comparison string. Additionally, notice that the required string (<noscript>) is mixed up in order to avoid producing an obvious pattern. The first three comparisons in are the n in position 0, the i in position 5, and the o in position 1.
Two large comparison blocks follow the single-byte comparisons. The first contains a search for the / character, as well as a string comparison (strstr) of two strings, both of which are passed in as arguments. With some .
The 'd' function calls both URLDownloadToCacheFileA and CreateProcessA, and looks very much like the code from . The URL is provided by the output of the shared function in (0x00401147), which we can now assume is some sort of decoding function. The 'r' function also uses the encoding function, and it takes the output and uses it in the function at 0x00401372, which references CreateFile, WriteFile, and the same C:\\autobat.exe configuration file referenced earlier. From this evidence, we can infer that the intent of the 'r' function is to redirect the malware to a different beacon site by overwriting the configuration file.
User-Agent:, the obvious signature to target is the specific User-Agent string with the additional User-Agent header:.alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"PM14.3.3 Download or Redirect Command"; content:"/08202016370000"; pcre:"/\/[dr][^\/]*\/ 08202016370000/"; sid:20001433; rev:1;)
This signature uses the string 08202016370000, which we previously identified as the encoded representation of http://. The PCRE rule option includes this string and forward slashes, and the d and r that indicate the download and redirect commands. The \/ is an escaped forward slash, the [dr] represents either the character d or r, the [^\/]* matches zero or more characters that are not a forward slash, and the \/ is another escaped slash.
The quit command by itself only has one known character, which is insufficient to target by itself. Thus, the last command we need to target is sleep, which can be detected with the following signature:
alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"PM14.3.4 Sleep Command"; content:"96'"; pcre:"/\/s[^\/]{0,15}\/[0-9]{2,20}96'/"; sid:20001434; rev:1;)Since there is no fixed content expression target to provide sufficient processing performance, we will use one element from outside the command string itself (the 96') to achieve an efficient signature. The PCRE identifies the forward slash followed by an s, then between 0 and 15 characters that are not a forward slash ('[^\/]{0,15}), a forward slash, and then between 2 and 20 digits plus a trailing 96'.
Note that the upper and lower bounds on the number of characters that will match the regular expression are not being driven by what the malware will accept. Rather, they are determined by a trade-off between what is reasonably expected from an attacker and the costs associated with an unbounded regular expression. So while the malware may indeed be able to accept a sleep value of more than 20 digits, it is doubtful that the attacker would send such a value, since that translates to more than 3 trillion years. The 15 characters for the term starting with an s assumes that the attacker would continue to choose a single word starting with s, though this value can certainly be increased if a more foolproof signature is needed.
Войти в систему
Войти с помощью соц. сетей: