Reversing Malware Command and Control: From Sockets to COM

On a Windows host there is more than one way for a program to communicate across the internet.  When reverse engineering a piece of malware it is of critical importance to understand what API is being used and how it works so that you may gain an understanding of the data sent and received as well as command structure and internal protocol if applicable.  The choice of networking API also effects how you craft your indicators (more on this later). I break Windows Malware Command and Control communications into four API categories: Sockets, WinInet, URLMon and COM. The primary focus of this article is COM, since it is the rarest, least understood and most difficult to reverse engineer.
Sockets
The first group, sockets, is the most widely known as it is the same basic networking API found on Unix. It provides a somewhat raw session level access to a TCP or UDP session.  It is provided primarily by the DLL ws2_32.dll, though it has a storied history.  Any application using the socket API must manually craft any higher level protocol such as HTTP.  A socket object is created with a call to the function socket().  It is during this call where the protocol is specified, TCP or UDP.  For a TCP client like most malware backdoors, the function connect() must be called, which (continue reading...)