Answers for the Reverse Challenge

1. Identify and explain the purpose of the binary.

The binary is the agent half of a handler / agent system, for a distributed denial of service (DDOS) attack tool. The system when in place, looks like the diagram shown below (diagram stolen from David Dittrich).

                  +----------+           +----------+
                  | attacker |           | attacker |
                  +----------+           +----------+
                       |                      |
        . . . --+------+---------------+------+----------------+-- . . .
                |                      |                       |
                |                      |                       |
          +-----------+          +-----------+           +-----------+
          |  handler  |          |  handler  |           |  handler  |
          +-----------+          +-----------+           +-----------+
                |                      |                       |
                |                      |                       |
. . . ---+------+-----+------------+---+--------+------------+-+-- . . .
         |            |            |            |            |
         |            |            |            |            |
     +-------+    +-------+    +-------+    +-------+    +-------+
     | agent |    | agent |    | agent |    | agent |    | agent |
     +-------+    +-------+    +-------+    +-------+    +-------+

Remote systems are compromised, and an agent binary is downloaded and executed. The agent becomes a daemon and waits to be commanded. When ready to utilise the agents, the attacker will use a handler program to instruct the agent(s) on the action to be performed. This allows the attacker to launch coordinated attacks upon a victim from multiple sites (the compromised hosts) on the Internet.

The agent can perform 3 types of DOS attack, plus provides "backdoor" shell access on demand. As two of the DOS attacks are quite old, and there hasn't been much reported abuse by the third method of attack, we can assume that the agent is mainly used for its backdoor feature.

2. Identify and explain the different features of the binary. What are its capabilities?

The agent can perform the following 3 types of denial of service attack:

syn flooding
jolt2 attack
a custom DNS attack

In addition, the agent allows attackers to execute remote shell commands on the compromised host, as well as providing a remote shell on demand.

Communication between handler and agent is connectionless and unreliable. IP datagrams with a protocol field of 11 are used. Payload is encrypted.

There are 12 possible commands which the agent responds to.

Initialisation. This feature is used to tell the agent the IP address of the controlling handler. The IP address of the handler is needed when replying to a status report query, or returning the output of an executed command. There are three possibilities with this command:
- A single IP address is supplied. All response packets are sent to this IP address.
- A single IP address is supplied, and 9 others are randomly generated by the agent. Each time the agent is to send a packet to a handler, the packet is sent to each of these 10 IP addresses.
- 10 IP addresses are supplied, each time the agent is to send a packet to a handler, the packet is sent to each of these 10 IP addresses. (Actually, due to a programming error, only 9 of these IP addresses are used).
Status Report. Requests that the agent inform the handler of the current action the agent is performing (if any). The response specifies the type of action being performed, (e.g. synflood) but doesn't provide any details.
Execute shell command. Requests to execute a given shell (csh) command. The output (both stdout and stderr) of the command (up to a maximum of 9950 bytes), is returned to the handler in datagrams with a maximum of 398 bytes payload. If the command does not finish executing in 10 seconds, it is killed and nothing is returned to the handler.
Perform custom DNS flood. The agent sends many spoofed DNS queries to many thousands of different DNS servers. The source address of the DNS query is spoofed to be the victim's IP address. The result is that thousands of DNS servers start sending replies to the victim, which effectively floods the victim's network capability. The DNS queries sent are zone of authority (SOA) queries for the domains com, net, edu, org and usc.edu. (Queries for the domains de, es, gr and it are also attempted, but due to a programming error, the packets sent are malformed)
Perform Jolt 2 attack. This attack is an attack upon Windows 9x, Windows NT4.0 and Windows 2000 machines which exploits a bug to cause 100% CPU utilisation. It is caused by sending invalid fragmented packets (either ICMP or UDP) to the victim host.
Open backdoor. The command causes a server to start listening for connections to TCP port 23281. If the string "SeNiF" is entered, then the port will be bound to a shell, effectively giving the remote attacker shell access (as the agent executes as root, this will be a root shell). If an incorrect password (any other string than "SeNiF" is given, the server sends a telnet WILL ECHO command and closes the connection.
Executes the given shell (csh) command. If the command has not finished executing after 20 minutes, it is terminated.
Stops the current action. If the agent is currently performing an attack, or providing a remote shell, then that action is halted. Remote shell connections are not terminated, only the server which is listening for new connections is terminated.
Same to command 4 (Perform custom DNS flood). The only difference is slight differences in the timing of sending the spoofed packets. See Appendix A for details.
Perform a syn flood on a victim. The victim IP address and port are specified. The spoofed destination IP address can be given, or generated randomly for each packet sent.
Same as command 10 (Perform a syn flood). The only difference is slight differences in the timing of sending the spoofed packets. See Appendix A for details.
Same as command 4 (Perform custom DNS flood), with the difference being that the DNS server to query is specified by the handler.

See Appendix A for the exact parameters that can be specified for these 12 commands.

3. The binary uses a network data encoding process. Identify the encoding process and develop a decoder for it

The handlers and agents use specifically constructed packets sent using protocol 11 to communicate. Specifically, the IP packets used by this tool have the following form:

   +-------------+-----+-----+---------------------------+
   | IP Header   | dir | res |    Encoded data           |
   +-------------+-----+-----+---------------------------+

IP Header - a standard IP header with protocol 11
dir       - a direction byte: 2 for handler -> agent, 3 for agent -> handler
res       - reserved byte, unused
data      - encoded data.
Total length of the IP packet is always greater than 200.

The encoding process used is quite simple. Treat the data to encode as an array of unsigned chars. For each element of the array, add the current data plus 23 to an accumulator. The value of the accumulator modulo 256 is the encoded data for that element of the array.

Here are simple C versions of the encoding and decoding methods.

void encode(unsigned char *buf, int len)
{
    int i;
    buf[0] += 23;
    for (i = 1; i < len; i++)
        buf[i] += (buf[i - 1] + 23);
}

void decode(unsigned char *buf, int len)
{
    int i;
    for (i = len - 1; i >= 1; i--)
        buf[i] -= (buf[i - 1] + 23);
    buf[0] -= 23;
}

Here is an example illustrating the encoding of the data [25, 87, 200]

src      dst
 25  ->   48  ==  (  0 +  25 + 23) % 256
 87  ->  158  ==  ( 48 +  87 + 23) % 256
200  ->  125  ==  (158 + 200 + 23) % 256

Once the encoded data is decoded, it can be processed. There are 15 different formats this decoded data can take. The formats consist of combinations of command flags, IP addresses and port numbers. For example, the format of a command to execute a shell command is:

+-----+------+----------------------------------+----------------+
| res | 0x07 | command string (null terminated) | random padding |
+-----+------+----------------------------------+----------------+
where:
   res    is an unused byte (reserved)
   0x07   is the command byte to execute a shell command
   string is a null terminated string e.g. "rm -rf /"
   random is random junk to pad the packet

Full details of the different formats can be found in Appendix A.

A full decoder is included as decoder. It is a perl script that requires the tcpdump executable to be in the current path. Output of this script on the supplied snort.log is given at the end of this document in Appendix B.

4. Identify one method of detecting this network traffic using a method that is not just specific to this situation, but other ones as well.

This tool uses an assigned, but generally unused protocol (protocol 11), to communicate between handler and agent. This is likely to go unnoticed since many firewalls and IDS system are configured to only process ICMP, TCP and UDP (protocols 1, 6, 17). Tunnelling data in other protocols such as ICMP echo or DNS packets is a known method, however tunneling data in an uncommon protocol is not widely utilised.

Detecting tunelled data in uncommon protocols is relatively easy. Setting a firewall to log / drop packets using an unused protocol (e.g anything not ICMP, TCP, or UDP) is one way to identify network traffic tunneled in an unused protocol.

5. Identify and explain any techniques in the binary that protect it from being analyzed or reverse engineered.

The binary uses a few techniques which protect it from analysis. A few techniques are deliberate, however others (such as compiling with optimisations) just happen to have an added "bonus" of making analysis more difficult.

These two methods protect the binary against analysis, by reducing the chance of it being detected. If the program is not detected, then it is not going to be analysed.

Attempt to hide the process by changing the process name to [mingetty]. This will reduce the chance of casual discovery through the use of the ps command (unless the system uses a different getty, in which case it has the opposite effect).
Tunelling commands over protocol 11. A running agent opens raw sockets. This will not show up under a nmap scan, which is a common sys admin technique for determining which services (or backdoors) are running. The netstat command will show open raw sockets, but not in the tcp or udp section which is where many system administrator pay attention to.

The following four methods have increased the difficulty of analysis, but were most likely done for other reasons. The increased difficulty of analysis is just a "pleasant" side effect.

The binary is statically linked. This was probably not done to prevent reverse engineering, but is more likely to have been done to remove possible library conflicts to ensure a greater change of the binary executing on a machine other than the one it was compiled on. It does however result in reducing the signal : noise (interesting user code : uninteresting library code) ratio.
The binary is stripped. This was more likely done to achieve a small executable size, but it does have the added bonus of removing the symbol table from executable, which makes reverse engineering much more difficult.
The binary was compiled with optimisation. Optimised code is harder to understand than unoptimised code. Again it is doubtful that the code was compiled with optimisation to solely make reversing more difficult.
Many calls to fork(). The many calls to fork() in the program increase the difficulty of tracing the program using a tools such as strace, or gdb.

Deliberate attempts to prevent analysis.

The password "SeNiF" is stored internally as the string "TfOjG" (notice the shift by one character). This prevents the password from being visible if the strings command is run over the binary.
The data sent over the network is encoded.
The decoding function has been deliberately obfuscated. A sample decoding function was given in 4 lines in the answer to question four. The decompiled decoding function is around 30 lines and performs many unnecessary actions such as double copying the data. Even though this could just be poor coding (much of the rest of the programming exhibits this), I will give the coder the benefit of the doubt and assume that this is a deliberate action.

6. Identify two tools in the past that have demonstrated similar functionality.

From David Dittrich's analysis of the Tribe Flood Network: (http://staff.washington.edu/dittrich/misc/tfn.analysis)

   TFN is made up of client and daemon programs, which implement a
   distributed network denial of service tool capable of waging ICMP
   flood, SYN flood, UDP flood, and Smurf style attacks, as well as
   providing an "on demand" root shell bound to a TCP port.
   ...
   Communication from the TFN client to daemons is accomplished via
   ICMP_ECHOREPLY packets.  There is no TCP or UDP based communication
   between the client and daemons at all.

TFN is similar (though vastly more sophisticated), to this tool. Similarities include:

both communicate between agent / handler (daemon / client) using a connectionless protocol tunneled inside another protocol.
both are capable of waging several different DOS attacks upon a victim.
both provide an "on demand" root shell bound to a TCP port.

Trinoo (http://staff.washington.edu/dittrich/misc/trinoo.analysis) is another DDOS tool which this tool is similar to.

both tools use the attacker -> handler -> agent paradigm for DDOS tools.
both tools provided selectable denial of service attacks.
both tools use encryption. Trinoo uses blowfish, the-binary uses the method described in question 3.

Appendix A - Summary of decoded commands.

There are two classes of actions which can be performed by the agent, fast and slow. A fast action is one which will complete quickly, such as executing a command or responding to a status query. Slow actions are ones which take significant amounts of time, such as performing a particular DOS attack, or providing a remote shell. Fast actions are performed as soon as their request arrives. Only one slow action can be performed at any one time. If the agent is performing a slow action, and a request to perform a different slow action arrives, the first action is terminated immediately, before starting the second.

Notes on PDU format.

Each PDU has random padding. This padding is presumably used to make decoding the packets more difficult.
res is a reserved byte (unused).
Each field is 1 byte in length unless otherwise stated.
Integer fields of more than 1 byte are in network byte order (big endian).

Packets from Agent -> Handler

Response to status query when agent is performing a slow action.

+------+------+------+------+-----+
| 0x00 | 0x01 | 0x07 | 0x01 | act |
+------+------+------+------+-----+
act:  is the request id of the action being performed

Response to a status query when agent is not performing any slow action.

+------+------+------+------+
| 0x00 | 0x01 | 0x07 | 0x00 |
+------+------+------+------+

First packet containing the output from an executed shell command.

+------+------+------------------------+
| res  | 0x03 | null terminated string |
+------+------+------------------------+
string: a null terminated string containing output (stdout + stderr) from the
        executed csh command

Continuing packets containing the output from an executed shell command.

+------+------+------------------------+
| res  | 0x04 | null terminated string |
+------+------+------------------------+
string: a null terminated string containing output (stdout + stderr) from the
        executed csh command.

Packets from Handler -> Agent

Request that the agent return a status query to the handler.

+------+------+
| res  | 0x01 |
+------+------+

Initialisation. Sets the IP address of the handler.

+------+------+------+----------------+
| res  | 0x02 | 0x00 | 4 byte IP addr |
+------+------+------+----------------+
addr:   32 bit IP address (of the handler).

Initialisation. Sets the IP addresses of the handler. Each packet to be sent to a handler will be sent to these 10 IP addresses. This is presumably increase the difficulty of finding the true IP address of the handler. (Actually, due to a programming bug, only 9 of these IP addresses are used).

+------+------+------+------------------------+
| res  | 0x02 | 0x02 | 4 byte IP addr  * 10   |
+------+------+------+------------------------+
addr:   10 32 bit IP address

Initialisation. Sets the IP address of the handler. 9 other random IP addresses will be generated, and each packet to be sent to a handler will be sent to these 10 IP addresses.

+------+------+------+----------------+
| res  | 0x02 | 0x?? | 4 byte IP addr |
+------+------+------+----------------+
addr:   32 bit IP address

Execute the given csh command, returning output to the handler.

+------+------+------------------------+
| res  | 0x03 | null terminated string |
+------+------+------------------------+
string: a null terminated string containing the command to execute.

Perform a dns flood on the given victim.

+------+------+----------------+------+------+----------+
| res  | 0x04 | victim IP addr | port | flag | hostname |
+------+------+----------------+------+------+----------+
victim:   32 bit IP address of victim to flood
port:     16 bit source port to spoof in DNS query
flag:     if 0, then use IP address for victim, otherwise use resolved hostname
hostname: null terminated hostname of victim (only used if flag is non zero)

Notes on timing:  There is a pause of 300 microseconds between sending each
packet.  If flag is non zero, then hostname is resolved once before sending any
packets.  If the hostname resolution fails, then there is a pause of 10 minutes
before the name resolution is attempted again.

Perform a jolt2 attack on the given victim.

+------+------+-----+-----+----------------+-------------+------+----------+
| res  | 0x05 | udp | port| victim IP addr | src IP addr | flag | hostname |
+------+------+-----+-----+----------------+-------------+------+----------+
udp:      if 0 use icmp fragmented packets, otherwise use udp
port:     8 bit source port to spoof in udp attack
victim:   32 bit IP address of victim to flood
src IP:   32 bit IP address of src IP to spoof
flag:     if 0, then use IP address for victim, otherwise use resolved hostname
hostname: null terminated hostname of victim (only used if flag is non zero)

Notes on timing:  Packets are sent in twos, with a pause of 20 microseconds
between each pair.  If flag is non zero, then hostname is resolved once before
sending any packets.  If the hostname resolution fails, then there is a pause
of 10 minutes before the name resolution is attempted again.

Open a backdoor (shell bound to TCP port). Default port is 23281 and default password is "SeNiF".

+------+------+
| res  | 0x06 |
+------+------+

Execute the given csh command. Output is not sent to the handler.

+------+------+------------------------+
| res  | 0x07 | null terminated string |
+------+------+------------------------+
string: a null terminated string containing the command to execute.

Terminate any currently executing slow action.

+------+------+
| res  | 0x08 |
+------+------+

Perform a dns flood on the given victim.

+------+------+----------------+-----+------+------+----------+
| res  | 0x09 | victim IP addr | arg | port | flag | hostname |
+------+------+----------------+-----+------+------+----------+
victim:   32 bit IP address of victim to flood
arg:      used for timing.
port:     16 bit source port to spoof in DNS query
flag:     if 0, then use IP address for victim, otherwise use resolved hostname
hostname: null terminated hostname of victim (only used if flag is non zero)

Notes on timing:  Packets are sent in groups of arg.  There is a pause of 300
microseconds between sending each group.  If flag is non zero, then hostname is
resolved once before sending any packets.  If the hostname resolution fails,
then there is a pause of 10 minutes before the name resolution is attempted
again.  After sending (40000 * arg) packets, hostname resolution starts again.

Perform a syn flood attack on the given victim.

+------+------+----------------+------+-----+-------------+------+----------+
| res  | 0x0a | victim IP addr | port | src | src IP addr | flag | hostname |
+------+------+----------------+------+-----+-------------+------+----------+
victim:   32 bit IP address of victim to flood
port:     16 bit source port to send syn packets to
src:      if 0 the spoofed source address is randomly generated for each packet
src IP:   if src is non 0, then this IP address is used for the source IP
flag:     if 0, then use IP address for victim, otherwise use resolved hostname
hostname: null terminated hostname of victim (only used if flag is non zero)

Notes on timing:  There is a pause of 300 microseconds between sending each
packet.  If flag is non zero, then hostname is resolved once before sending any
packets.  If the hostname resolution fails, then there is a pause of 10 minutes
before the name resolution is attempted again.

Perform a syn flood attack on the given victim.

+-----+-----+----------------+------+-----+-------------+-----+-----+----------+
| res |0x0b | victim IP addr | port | src | src IP addr | arg |flag | hostname |
+-----+-----+----------------+------+-----+-------------+-----+-----+----------+
victim:   32 bit IP address of victim to flood
port:     16 bit source port to send syn packets to
src:      if 0 the spoofed source address is randomly generated for each packet
src IP:   if src is non 0, then this IP address is used for the source IP
arg:      used for timing.
flag:     if 0, then use IP address for victim, otherwise use resolved hostname
hostname: null terminated hostname of victim (only used if flag is non zero)

Notes on timing:  Packets are sent in groups of arg.  There is a pause of 300
microseconds between sending each group.  If flag is non zero, then hostname is
resolved once before sending any packets.  If the hostname resolution fails,
then there is a pause of 10 minutes before the name resolution is attempted
again.  After sending (40000 * arg) packets, hostname resolution starts again.

Perform a dns flood on the given victim, specifying the name server to perform the flood.

+-----+------+------------+----------------+-----+------+------+----------+
| res | 0x0c | NS IP addr | victim IP addr | arg | port | flag | hostname |
+-----+------+------------+----------------+-----+------+------+----------+
NS IP:    32 bit IP address of name server to target
victim:   32 bit IP address of victim to flood
arg:      used for timing.
port:     16 bit source port to spoof in DNS query
flag:     if 0, then use IP address for name server, otherwise use resolved hostname
hostname: null terminated hostname of name server (only used if flag is non zero)

Notes on timing:  Packets are sent in groups of arg.  There is a pause of 300
microseconds between sending each group.  If flag is non zero, then hostname is
resolved once before sending any packets.  If the hostname resolution fails,
then there is a pause of 10 minutes before the name resolution is attempted
again.  After sending (40000 * arg) packets, hostname resolution starts again.

Appendix B - Sample decoder output

Here is the output of running the decoder on the supplied snort.log file.

$ perl decoder snort.log

172.16.196.132 -> 172.16.183.2 (handler -> agent)
Initialise agent.
All replies are sent to handler at 203.173.173.35
(plus 9 other randomly generated hosts)
----------------------------------------------------------------
172.16.196.132 -> 172.16.183.2 (handler -> agent)
Initialise agent.
All replies are sent to handler at 203.173.173.35
(plus 9 other randomly generated hosts)
----------------------------------------------------------------
172.16.196.132 -> 172.16.183.2 (handler -> agent)
Initialise agent.
All replies are sent to handler at 203.173.173.35
(plus 9 other randomly generated hosts)
----------------------------------------------------------------
172.16.196.132 -> 172.16.183.2 (handler -> agent)
Execute the given command and send output to handler:
rpcinfo -p 127.0.0.1
----------------------------------------------------------------
172.16.183.2 -> 109.197.191.34 (agent -> handler)
output of command executed by agent:
   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100021    1   udp   1024  nlockmgr
    100021    3   udp   1024  nlockmgr
    100021    1   tcp   1024  nlockmgr
    100021    3   tcp   1024  nlockmgr
    100024    1   udp    924  status
    100024    1   tcp    926  status

----------------------------------------------------------------
172.16.183.2 -> 126.85.250.183 (agent -> handler)
output of command executed by agent:
   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100021    1   udp   1024  nlockmgr
    100021    3   udp   1024  nlockmgr
    100021    1   tcp   1024  nlockmgr
    100021    3   tcp   1024  nlockmgr
    100024    1   udp    924  status
    100024    1   tcp    926  status

----------------------------------------------------------------
172.16.183.2 -> 233.96.38.22 (agent -> handler)
output of command executed by agent:
   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100021    1   udp   1024  nlockmgr
    100021    3   udp   1024  nlockmgr
    100021    1   tcp   1024  nlockmgr
    100021    3   tcp   1024  nlockmgr
    100024    1   udp    924  status
    100024    1   tcp    926  status

----------------------------------------------------------------
172.16.183.2 -> 210.13.117.98 (agent -> handler)
output of command executed by agent:
   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100021    1   udp   1024  nlockmgr
    100021    3   udp   1024  nlockmgr
    100021    1   tcp   1024  nlockmgr
    100021    3   tcp   1024  nlockmgr
    100024    1   udp    924  status
    100024    1   tcp    926  status

----------------------------------------------------------------
172.16.183.2 -> 219.93.216.82 (agent -> handler)
output of command executed by agent:
   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100021    1   udp   1024  nlockmgr
    100021    3   udp   1024  nlockmgr
    100021    1   tcp   1024  nlockmgr
    100021    3   tcp   1024  nlockmgr
    100024    1   udp    924  status
    100024    1   tcp    926  status

----------------------------------------------------------------
172.16.183.2 -> 203.173.144.35 (agent -> handler)
output of command executed by agent:
   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100021    1   udp   1024  nlockmgr
    100021    3   udp   1024  nlockmgr
    100021    1   tcp   1024  nlockmgr
    100021    3   tcp   1024  nlockmgr
    100024    1   udp    924  status
    100024    1   tcp    926  status

----------------------------------------------------------------
172.16.183.2 -> 41.230.157.197 (agent -> handler)
output of command executed by agent:
   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100021    1   udp   1024  nlockmgr
    100021    3   udp   1024  nlockmgr
    100021    1   tcp   1024  nlockmgr
    100021    3   tcp   1024  nlockmgr
    100024    1   udp    924  status
    100024    1   tcp    926  status

----------------------------------------------------------------
172.16.183.2 -> 20.17.169.129 (agent -> handler)
output of command executed by agent:
   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100021    1   udp   1024  nlockmgr
    100021    3   udp   1024  nlockmgr
    100021    1   tcp   1024  nlockmgr
    100021    3   tcp   1024  nlockmgr
    100024    1   udp    924  status
    100024    1   tcp    926  status

----------------------------------------------------------------
172.16.183.2 -> 214.104.164.84 (agent -> handler)
output of command executed by agent:
   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100021    1   udp   1024  nlockmgr
    100021    3   udp   1024  nlockmgr
    100021    1   tcp   1024  nlockmgr
    100021    3   tcp   1024  nlockmgr
    100024    1   udp    924  status
    100024    1   tcp    926  status

----------------------------------------------------------------
172.16.183.2 -> 109.197.191.34 (agent -> handler)
end of output of command executed by agent
----------------------------------------------------------------
172.16.183.2 -> 126.85.250.183 (agent -> handler)
end of output of command executed by agent
----------------------------------------------------------------
172.16.183.2 -> 233.96.38.22 (agent -> handler)
end of output of command executed by agent
----------------------------------------------------------------
172.16.183.2 -> 210.13.117.98 (agent -> handler)
end of output of command executed by agent
----------------------------------------------------------------
172.16.183.2 -> 219.93.216.82 (agent -> handler)
end of output of command executed by agent
----------------------------------------------------------------
172.16.183.2 -> 203.173.144.35 (agent -> handler)
end of output of command executed by agent
----------------------------------------------------------------
172.16.183.2 -> 41.230.157.197 (agent -> handler)
end of output of command executed by agent
----------------------------------------------------------------
172.16.183.2 -> 20.17.169.129 (agent -> handler)
end of output of command executed by agent
----------------------------------------------------------------
172.16.183.2 -> 214.104.164.84 (agent -> handler)
end of output of command executed by agent
----------------------------------------------------------------