Dissecting Malicious Network Traffic To Identify Botnet Communication

by Swasti Bhushan Deb

Botnets are well-known in the domains of information security, digital forensics and incident response for hosting illegal data, launching DDOS attacks, stealing information, spamming, bitcoin mining, spreading ransomware, launching brute force attacks, managing remote access to connected devices, and even propagating infection to other devices, among other things. Internet Relay Chat (IRC) networks are a popular medium for controlling bot networks. IRC-based bots with unpredictable degrees of sophistication and customized commands have something in common. An IRC bot, when executed in a client machine, connects to IRC server on random higher ports, logs into a definite predefined channel and listens for commands issued by the bot master.

The botnet lifecycle starts with the infection phase where a system is compromised by a customized and preconfigured piece of malware. The connection phase is when the infected system initiates contact on a predefined remote IRC TCP service port for communication. A nickname, password or key may authenticate the bot’s access to the channel. In the command & control phase, the bot receives commands from the bot master via the designated channel of communication (C2C). Finally in the multiplication phase, customized and preconfigured malware is downloaded into the infected bot for further control and to spread infection via USB devices, writable network shares and so on.

This article intends to showcase a proof of concept aimed to analyse unique communication to / from an infected host and botnet. The network capture used can be found here. The analysis was carried out using Wireshark. The analysis and observations will assist in initial investigation of the network capture to identify traffic illustrating typical bot behaviour – joining a predefined channel with a nickname or username; messages exchanged between the bot and the bot master; spreading infection, and so on.

Observations

1. A total of 60 packets were observed to be present in the pcap file. IP addresses identified:
   1. 192.168.45.130: port 1037 (service: ams) ;port 1038 (service: mtqp)
   2. 192.168.45.2: port 53 (service : DNS)
   3. 91.121.100.60: Resolved Address- irc.accesox.net ;TCP port 5540 (service : sdreport)
2. IP 192.168.45.130,port 1037 initiates a DNS query to 192.168.45.2, port 53 for name resolution of irc.accesox.net. DNS Response from 192.168.45.2 at 91.121.100.60 and 91.121.96.162.
3. Packets-3,4,& 5 detail TCP three way handshake. The handshake was initiated from 192.168.45.130,port 1038 & destined to irc.accesox.net (91.121.100.60,port 5540).
4. Packet 6: IRC “PASS” message was used to set a ‘connection password’ by the host bot- 192.168.45.130.This is used to register a connection with an IRC server- irc.accesox.net (91.121.100.60)
5. Packet 8:IRC “NICK” message used to provide user a nickname (pLagUe{) by host 192.168.45.130.
6. Packet 10:IRC “USER” message was used to specify the username by host 192.168.45.130. The original parameters alongside the message are in the format <username> <hostname> <servername> <realname>.The username was identified as “sKuZ” and real name as “TeaM UniX b0at 0.4”
7. Packet 12: IRC server-irc.accesox.net (91.121.100.60) replies back to host (192.168.45.130). The reply originates from server “sex.accesox.net”. Indicates authorization message by the server.
8. Packet 15: IRC server-irc.accesox.net pings the client (192.168.45.130) with a hostname as it could not resolve the hostname. The PING command was used to test the presence of the client bot.
9. Packet 16: The PONG response indicates a reply by the client bot to the ping message of the ICR Server.
10. Packet 18: Communication indicates replies from server “sex.accesox.net” which was created on “mar 25 2011 at 02:34:51 CET” and is running “Unreal3.2.9-rc1” (an open source IRC server). The IRC server welcomes the client bot with a series of additional replies. As per RFC 2812,the series of replies indicates successful registration by the client bot.
11. Packet 19: Indicates message from the client host to change visibility mode to a hidden user on the IRC server.
12. Packet 21 & 23: JOIN command issued by the client bot and request to start listening to the specific channel –“ verga”.
13. Packet 25: PRIVMSG used by the client to send private message to channel “verga”. The message “NueVo PuTo InfeCcIoN” in Spanish translates to “New WhOre InfeCtIOn” in English.
14. Packet 27: Details the command response from the IRC server. Indicates 56 users and 189 invisible on 9 servers. Informs the client host that the nickname isn’t registered.
15. Packet 30-43: Indicates re-registration initiated by the client bot.
16. Packet 45: Indicates command message from Bot “pLagUe” to download an executable “plaga.exe” hosted at http://www.freewebtown.com/redzone/ into the system drive of the client bot ( c:\jiji).
17. Packet 53:Details the response from the client bot to the IRC server indicating infecting virus into “autorun.inf” of (most likely attached) USB devices.

IRC Communication summary

Table 1 Packet wise description

• The interpretation of the IRC commands are based on RFC 2812.
• The host at 192.168.45.130 joined irc.accesox.net (91.121.100.60) with username “sKuZ” and joined channel “verga”.
  The pLagUe{USA}64007 bot instructs the client bot (192.168.45.130) to download an executable- “plaga.exe” hosted at http://www.freewebtown.com/redzone/, store it in the system drive (c:\jiji) and inject itself into “autorun.inf” of attached USB devices. This indicates the propagation mechanism used in this case.
• The executable “plaga.exe” hosted at http://www.freewebtown.com/redzone/ was flagged as a malware by VirusTotal. The VirusTotal graph indicates multiple malware instances hosted by subdomains of www.freewebtown.com.

From the observations cited above, it would be reasonable to conclude that the host at 192.168.45.130 made a DNS query to 192.168.45.2 for resolution of irc.accesox.net. It is assumed that the host at 192.168.45.130 could be infected with a IRC Trojan which initiated TCP connection to irc.accesox.net, logged into a predetermined IRC channel and based on the commands issued by the bot master, spread further infection by infecting the autorun.inf of the attached USB devices.

Analysis

Capture File Properties: A quick glance at the pcap file using Wireshark indicates a total of 60 packets. This can be achieved using the “Capture File Properties” window by selecting the “Capture File Properties“ option from the Statistics drop-down menu.

TCP Stream: An excerpt of the TCP stream is detailed below and indicates 19 client packets and 13 server packets. The “Follow TCP Stream” window can be used to visualize protocols in the way that the application layer sees it. This can be achieved right clicking on any TCP packet and selecting Follow =>> TCP Stream. Figure 1 describes the TCP stream and relevant information required to understand bot communication.

1-Connection password set by the host bot
2-Nickname set by the host bot
3-Username set by the host bot
4-Notice from IRC server sex.accesox.net
5-PING command from IRC server & PONG response from bot
6-IRC network info
7-Visibility mode set by client bot as hidden
8-Client bot request message to start listening on specific channel – “verga”
9-Private message from client bot on channel – “verga”
10-Additional message indicating the number of active channels, local users, online operators etc. on the IRC server
11-Request message indicating a re-registration attempt of the client bot to listen on channel “verga”
12-Message from the botnet – pLagUe to download an exe (plaga.exe) from http://www.freewebtown.com/redzone/
13-Private message from client bot indicating successful injection of the exe into autorun.inf of four USB devices

“Protocol Hierarchy Statistics”: Packets usually contain multiple protocols. The “Protocol Hierarchy Statistics” window reflects a tree of all the protocols in the capture. This serves as an initial assessment in understanding major protocols present in the capture. Applying the TCP “Data” field as a display filter lists the TCP packets containing data. The protocol hierarchy chart in Wireshark can be generating by selecting the “Protocol Hierarchy“ option from the Statistics drop-down menu.

References

IETF
Wireshark