Checking a Bot for Rogue Traffic and Plaintext Connections

It’s a good idea to perform a security review of a bot before you decide to implement it in your network. One test you can perform is to see what types of connections the bot is initiating, as well as what servers the bot is connecting to. If you are a bot developer, it is also important to check and make sure that no data is being leaked over a plaintext protocol that could be read by anyone observing the network traffic.

Getting started

Wireshark is the de facto tool for analyzing network traffic. It will capture all traffic sent to or from an interface. In observing the packet captures Wireshark produces, you will be able to see if there are any plaintext protocols or traffic being generated.

To detect rogue traffic, you’ll need to install your bot and Wireshark on a computer that is not already generating a lot of noisy traffic. This usually means a bare-bones, fresh install of Windows with as many services disabled as possible. On this machine, install Wireshark and the Automation Anywhere Client.

When you have the environment up, listen to traffic on your primary interface in Wireshark, then launch the bot. When the bot has completed running, stop capturing the traffic and save the packet capture file (PCAP) for analysis.

Packet analysis

Despite your best efforts to minimize the amount of traffic you’re generating that is not related to your bot’s execution, there will likely still be lots of additional traffic to filter out before you can see the bot traffic. Luckily, there are many built-in features within Wireshark to help you filter traffic.

Look at the following packet capture. In just the short time the bot was running, more than 2200 packets were captured. That would be a lot to go through individually, so let’s see about using some filters to cut down the amount.

Starting with DNS

If you have a large amount of traffic to sift through and exclude, first look at the DNS traffic. Simply type in “DNS” into the search bar to identify the domains and associated IP addresses that traffic is being sent to. If you can prove the hosts have nothing to do with the bot’s execution and are just background windows traffic, those IP addresses can be quickly filtered out from the traffic

In the graphic, you can see the DNS resolved two IP addresses—one related to Microsoft and the other related to Google. As the bot is currently fetching results from Google, it can’t be excluded, but the Microsoft IP can be.

To do this, type “!dns && !ip.addr==52.169.83.3” in the filter bar and press enter. It’s also a good idea to preserve your filters in case you need to go back and use them later. You can exclude DNS traffic from the results. The data will not be needed anymore.

Filtering by protocol

If you scroll through the packet data, you can see lots of SQL traffic traveling over plaintext using the TDS protocol. The traffic is for the backend database supporting the Control Room instance that is running on the same machine. It’s plaintext because it is a local test server. The filter can be improved by adding “&& !tds” to the existing filter.

That successfully cut the packets down to around 900, which is slightly more manageable. So, how can you further exclude protocols? To view a frequency ranked list of protocols, navigate to “Statistics”> “Protocol Hierarchy.”

This bot appears to be heavily concentrated on TCP traffic. If you see anything peculiar, you can right-click on any of the items in the list and select “apply as filter”> “selected” to further investigate; however, you will probably lose any currently applied filters, which is why you should keep a notepad with all your filters and what they do.

In this case, after investigating all UDP traffic, you could exclude UDP and add it to your filter.

“!dns && !ip.addr==52.169.83.3 && !tds &&!udp”

This would leave 898 TCP packets.

Excluding by conversation

The next thing up for consideration for excluding traffic is to look at conversations between a source IP or port and a destination IP or port. To view all conversations, navigate to “Statistics”>“Conversations” from the top menu.

If you look at the IPv4 conversations, you can see that there are seven connections established during the time the bot ran. The easiest way to exclude any of these seven is to perform research and maybe some reverse whois/DNS lookups on those IP addresses to determine if it is bot traffic or otherwise suspicious. If it is web-based traffic, you could also try navigating to that particular IP and port directly to see what page is displayed.

By filtering out one additional IP address with the most traffic (determined to be related to Control Room and Automation Anywhere remote database), you can narrow the traffic down to 19 relevant requests related to the bot’s operation.

If you reintroduce some of the DNS traffic excluded earlier, you can see the full flow of what the bot does. Here are the steps in the packet capture:

1. Perform a DNS lookup for google.ca to obtain an IP address
2. Establish a TCP connection with the remote host
3. Establish a TLS connection with the remote host
4. Transfer encrypted data
5. Close the connection

This bot does exactly what it’s supposed to—fetch a page from the Internet. If there was other traffic not identified, be suspicious of using the bot. In addition, if all this was done over a plaintext protocol, you should be worried about information leakage.