Networking APIs

Malware commonly relies on network functions to do its dirty work, and there are many Windows API functions for network communication. The task of creating network signatures is complicated, and it is the exclusive focus of Chapter 14. Our goal here is to show you how to recognize and understand common network functions, so you can identify what a malicious program is doing when these functions are used.

Berkeley Compatible Sockets

Of the Windows network options, malware most commonly uses Berkeley compatible sockets, functionality that is almost identical on Windows and UNIX systems.

Berkeley compatible sockets’ network functionality in Windows is implemented in the Winsock libraries, primarily in ws2_32.dll. Of these, the socket, connect, bind, listen, accept, send, and recv functions are the most common, and these are described in Table 7-2.

Table 7-2. Berkeley Compatible Sockets Networking Functions

Function

Description

socket

Creates a socket

bind

Attaches a socket to a particular port, prior to the accept call

listen

Indicates that a socket will be listening for incoming connections

accept

Opens a connection to a remote socket and accepts the connection

connect

Opens a connection to a remote socket; the remote socket must be waiting for the connection

recv

Receives data from the remote socket

send

Sends data to the remote socket

Note

The WSAStartup function must be called before any other networking functions in order to allocate resources for the networking libraries. When looking for the start of network connections while debugging code, it is useful to set a breakpoint on WSAStartup, because the start of networking should follow shortly.

The Server and Client Sides of Networking

There are always two sides to a networking program: the server side, which maintains an open socket waiting for incoming connections, and the client side, which connects to a waiting socket. Malware can be either one of these.

In the case of client-side applications that connect to a remote socket, you will see the socket call followed by the connect call, followed by send and recv as necessary. For a service application that listens for incoming connections, the socket, bind, listen, and accept functions are called in that order, followed by send and recv, as necessary. This pattern is common to both malicious and nonmalicious programs.

Example 7-3 shows an example of a server socket program.

Note

This example leaves out all error handling and parameter setup. A realistic example would be littered with calls to WSAGetLastError and other error-handling functions.

Example 7-3. A simplified program with a server socket

00401041  push    ecx             ; lpWSAData
00401042  push    202h            ; wVersionRequested
00401047  mov     word ptr [esp+250h+name.sa_data], ax
0040104C  call    ds:WSAStartup
00401052  push    0               ; protocol
00401054  push    1               ; type
00401056  push    2               ; af
00401058  call    ds:socket
0040105E  push    10h             ; namelen
00401060  lea     edx, [esp+24Ch+name]
00401064  mov     ebx, eax
00401066  push    edx             ; name
00401067  push    ebx             ; s
00401068  call    ds:bind
0040106E  mov     esi, ds:listen
00401074  push    5               ; backlog
00401076  push    ebx             ; s
00401077  call    esi ; listen
00401079  lea     eax, [esp+248h+addrlen]
0040107D  push    eax             ; addrlen
0040107E  lea     ecx, [esp+24Ch+hostshort]
00401082  push    ecx             ; addr
00401083  push    ebx             ; s
00401084  call    ds:accept

First, WSAStartup initializes the Win32 sockets system, and then a socket is created with socket. The bind function attaches the socket to a port, the listen call sets up the socket to listen, and the accept call hangs, waiting for a connection from a remote socket.

The WinINet API

In addition to the Winsock API, there is a higher-level API called the WinINet API. The WinINet API functions are stored in Wininet.dll. If a program imports functions from this DLL, it’s using higher-level networking APIs.

The WinINet API implements protocols, such as HTTP and FTP, at the application layer. You can gain an understanding of what malware is doing based on the connections that it opens.

  • InternetOpen is used to initialize a connection to the Internet.

  • InternetOpenUrl is used to connect to a URL (which can be an HTTP page or an FTP resource).

  • InternetReadFile works much like the ReadFile function, allowing the program to read the data from a file downloaded from the Internet.

Malware can use the WinINet API to connect to a remote server and get further instructions for execution.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.141.37.10