; however, this is configurable. The beacons are HTTP/1.0 GET requests for resources in the form xxxx/xxxx.xxx, where x is a random alphanumeric ASCII character. The malware does not provide any HTTP headers with its requests.
shows an instance of the string in the registers window of OllyDbg. Note that the contents of EDX are 0x12E248, but OllyDbg correctly interprets this as a pointer to an ASCII string. The malware attempts to delete itself from the disk by combining the constructed string with program cmd.exe in a call to ShellExecuteA. Fortunately, we have the file open in OllyDbg, so Windows does not allow the file to be deleted. This behavior is consistent with what we saw during basic dynamic analysis of the sample in the labs.. Then add the -in argument in the OllyDbg arguments dialog, as shown in .When the malware is executed with the argument -in, it still tries to delete itself, which tells us that the command-line arguments are not yet valid. Let’s use OllyDbg to step through the code flow when we give the malware a parameter to see what’s happening.
shows the function setup and parameter check. at ❶ and ❷. The instruction at ❸ performs pointer . shows the relevant context menu items. shows the assembled instructions after they have been entered into the edit dialog. Since we want to write 6 bytes over a previous instruction that took only 1 byte, we uncheck the box labeled Keep size. We then enter the assembled hex values in the HEX+06 field and click OK. OllyDbg will automatically assemble and display the new instructions at the appropriate location. Next, save the changes to the executable by right-clicking the disassembly window and selecting Copy to executable ▸ All modifications. Accept all dialogs, and save the new version as Lab09-01-patched.exe.To test whether the password check function was successfully disabled, we try debugging it with the command-line parameter -in again. This time, the malware successfully passes the check at address 0x402510 and jumps to address 0x402B3F. Six instructions later, a pointer to the first command-line parameter is pushed onto the stack next to a pointer to another ASCII string, -in. shows the state of the stack at this point.
shows the state of the call stack when CreateServiceA is called and includes the ASCII string name, description, and path. At address 0x4028A1, the malware copies itself into %SYSTEMROOT%\system32\. The function at address 0x4015B0 alters the modified, accessed, and changed timestamps of the copy to match those of the system file kernel32.dll. Modifying timestamps to match another file is known as timestomping.. The strings contain the values ups, http://www.practicalmalwareanalysis.com, 80, and 60. This looks like it may be the configuration data related to a network capability of the malware.. These can be easily identified in the main function by looking for calls to __mbscmp. shows the entry in the Windows registry using Regedit after a default installation of the malware.The function at 0x401280, which executes if the -cc switch is provided, is the reverse of the configure function (0x401070), as it reads the contents of the configuration registry value and places the fields into buffers specified as function arguments. If the -cc switch is provided to the malware, the current configuration is read from the registry and formatted into a string. The malware then prints this string to the console. Here is the output of the -cc switch after a default installation of the malware:
summarizes the supported commands, showing the adjustable parameters in italics..The function that starts at 0x401D80 is a little different in that it does not return the same value at each invocation. Rather, it appears to return an ASCII string containing random characters. After debugging this function many times, a pattern will appear that involves the forward slash (/) and dot (.) characters. Perhaps the returned string corresponds to a URL-like scheme.
When the malware is analyzed in an isolated testing environment, it will repeatedly fail somewhere within the next function, which starts at address 0x401D80. Returning to the disassembly view of IDA Pro, we see that within this function, the malware constructs an HTTP/1.0 GET request and connects to a remote system. This connection is unlikely to be blocked by corporate firewalls, since it is a valid outbound HTTP request. If your malware analysis virtual machine has networking disabled, the outbound connection will never succeed, and the malware fails. However, by following the disassembly listing carefully, you will see that the malware does, in fact, attempt to connect to the domain and port recorded in the registry configuration key, and requests a randomly named resource. Further analysis of the disassembly shows that the malware searches the document returned by the server for the particular strings `'`'` (backtick, apostrophe, backtick, apostrophe, backtick) and '`'`' (apostrophe, backtick, apostrophe, backtick, apostrophe), and uses these to delineate the command-and-control protocol.
This sample is an HTTP reverse backdoor. The password abcd must be provided as the last parameter when invoking the malware for installation, configuration, and removal. It installs itself by copying itself to the %SYSTEMROOT%\WINDOWS\system32 directory and creating an autorun service. The malware can be cleanly removed by passing the command-line argument -re, or reconfigured using the -c flag.
When run after installation, the malware uses a registry key to fetch server configuration information, and makes HTTP/1.0 GET requests to the remote system. The command-and-control protocol is embedded within the response document. The malware recognizes five commands, including one that specifies the execution of arbitrary shell commands.
Назад: Lab 7-2 Solutions
Дальше: Lab 9-2 Solutions
Войти в систему
Войти с помощью соц. сетей:
-in argument in the OllyDbg arguments dialog, as shown in .When the malware is executed with the argument -in, it still tries to delete itself, which tells us that the command-line arguments are not yet valid. Let’s use OllyDbg to step through the code flow when we give the malware a parameter to see what’s happening.
To test whether the password check function was successfully disabled, we try debugging it with the command-line parameter -in again. This time, the malware successfully passes the check at address 0x402510 and jumps to address 0x402B3F. Six instructions later, a pointer to the first command-line parameter is pushed onto the stack next to a pointer to another ASCII string, -in. shows the state of the stack at this point.
CreateServiceA is called and includes the ASCII string name, description, and path. At address 0x4028A1, the malware copies itself into %SYSTEMROOT%\system32\. The function at address 0x4015B0 alters the modified, accessed, and changed timestamps of the copy to match those of the system file kernel32.dll. Modifying timestamps to match another file is known as timestomping.ups, http://www.practicalmalwareanalysis.com, 80, and 60. This looks like it may be the configuration data related to a network capability of the malware.main function by looking for calls to __mbscmp.The function at 0x401280, which executes if the -cc switch is provided, is the reverse of the configure function (0x401070), as it reads the contents of the configuration registry value and places the fields into buffers specified as function arguments. If the -cc switch is provided to the malware, the current configuration is read from the registry and formatted into a string. The malware then prints this string to the console. Here is the output of the -cc switch after a default installation of the malware:
The function that starts at 0x401D80 is a little different in that it does not return the same value at each invocation. Rather, it appears to return an ASCII string containing random characters. After debugging this function many times, a pattern will appear that involves the forward slash (/) and dot (.) characters. Perhaps the returned string corresponds to a URL-like scheme.
When the malware is analyzed in an isolated testing environment, it will repeatedly fail somewhere within the next function, which starts at address 0x401D80. Returning to the disassembly view of IDA Pro, we see that within this function, the malware constructs an HTTP/1.0 GET request and connects to a remote system. This connection is unlikely to be blocked by corporate firewalls, since it is a valid outbound HTTP request. If your malware analysis virtual machine has networking disabled, the outbound connection will never succeed, and the malware fails. However, by following the disassembly listing carefully, you will see that the malware does, in fact, attempt to connect to the domain and port recorded in the registry configuration key, and requests a randomly named resource. Further analysis of the disassembly shows that the malware searches the document returned by the server for the particular strings `'`'` (backtick, apostrophe, backtick, apostrophe, backtick) and '`'`' (apostrophe, backtick, apostrophe, backtick, apostrophe), and uses these to delineate the command-and-control protocol.
This sample is an HTTP reverse backdoor. The password abcd must be provided as the last parameter when invoking the malware for installation, configuration, and removal. It installs itself by copying itself to the %SYSTEMROOT%\WINDOWS\system32 directory and creating an autorun service. The malware can be cleanly removed by passing the command-line argument -re, or reconfigured using the -c flag.
When run after installation, the malware uses a registry key to fetch server configuration information, and makes HTTP/1.0 GET requests to the remote system. The command-and-control protocol is embedded within the response document. The malware recognizes five commands, including one that specifies the execution of arbitrary shell commands.
Войти в систему
Войти с помощью соц. сетей: