As we have seen so far, having some skill with Tshark and analyzing our network on a regular basis can help us greatly in identifying multiple security issues. Besides the network attacks previously seen, we can intelligently use Tshark to investigate security incidents whose origin is unknown. In this recipe we will discuss a couple of examples, data exfiltration by a malicious user and an internal network intrusion.
It's not new to use tunneling techniques to attempt to circumvent firewalls or other countermeasures that do not make use of deep packet inspection. Tools such as iodine, Hping3, Netcross, and so on, can be used to encapsulate certain type of traffic within the payload of another protocol and thus get its contents hidden. The use of these tools can be tedious for network administrators who try to control the information entering and leaving their network. Tshark can be an effective tool to detect this type of traffic if it's done wisely.
So suppose we are performing a periodic analysis of our network. We decide to start looking at the protocols used to make connections with the outside. Note that with the condition
ip.addr! = 192.168.1.0/24
we will ensure that Tshark displays packets involving communication between our LAN and any other network (in this case the outside because we do not have more subnets). This way, we are also filtering connections between hosts on our LAN.bmerino@Mordor:/$ tshark -r icmp.pcap -o column.format:'"Protocol","%p"' -R "ip.addr != 192.168.1.0/24 " | sort -u DNS HTTP ICMP SSL TCP TLSv1
According to our policies (only allowed HTTP/HTTPS, DNS, and ICMP), we can see that all protocols seem normal. Since ICMP can result from a variety of network issues we decided to run the following:
We know now that a user of our network is communicating with an external host via ICMP. What is striking about this communication is the size of those packets. To see exactly what kind of ICMP packets they are sending, we run:
bmerino@Mordor:/$ tshark -r icmp.pcap -T fields -e icmp.code -e icmp.type -R 'frame.number==41628' 0 8
The user is sending ICMP echo request (
type = 8/code = 0
) of a size well above a standard ping. To know for sure the reason for that size we do a dump of one packet to see its payload:With the dump, we verified that the user was leaking information to the outside via ICMP packets. In the example the user is sending the RSA private key of a certain user/service. We realized that all payloads started with "BOF" to indicate the beginning of the file content. Likewise the "EOF" string was being used to indicate the end. With this data we could find out that the user was using the
ICMP Exfiltration
module from Metasploit to get all kinds of files from the internal host.We could take advantage of the BOF string to list all files sent by that user (the external IP has been omitted).
bmerino@Mordor:/$ tshark -r icmp.pcap -R "icmp contains BOF && ip.src==192.168.1.42"
This would generate the following output:
41591 764.064922000 192.168.1.42 -> *.*.*.*ICMP 938 Echo (ping) request id=0x1b3d, seq=1/256, ttl=64 41593 765.065198000 192.168.1.42 -> *.*.*.*ICMP 938 Echo (ping) request id=0x1b3d, seq=3/768, ttl=64
Although most files were plaintext, one of them looked as follows:
bmerino@Mordor:/$ tshark -r icmp.pcap -R "frame.number==268" -V | grep ^0 | cut -d" " -f21 | tr -d '\nBOF' TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAA4fug4AtAnNIbgTM0hVGhpcywcm9ncmtIGNhbm5vdCiZSydW4gaW4gRE9TIG1vZGUuDQ0KJAAAAAAAAAQRQAATAEEALmrjQAAAAAAAAAAAADwELAQUAAJgAAAiAAAAAAAAAEwAAAAQAAAAs
This seems to indicate that he was sending a file encoded in base 64, possibly to deal with nonprintable characters. Leveraging the output and using a little bash we get the following:
bmerino@Mordor:/$ tshark -r icmp.pcap -R "frame.number==268" -V | grep ^0 | cut -d" " -f21 | tr -d '\n' | sed 's/^...//' | base64 -d MZ @ ! L!This program cannot be run in DOS mode. $PEL 4 bL @ 0 <! d .textp `.rdata
Effectively the output indicated part of the PE header of an executable file. Now we can dump it to a file and analyze it with our favorite debugger.
Let's see another case. The internal server (192.168.1.130/24) of a certain organization has been compromised several times. The fact that the server is not accessible from the outside led us to think that an internal user had also been compromised, and the attacker was doing "pivoting" from that machine to the server. Another option was that an infected USB had been the root of the problem. However, after checking that the firewall did not filter the traffic DMZ ---> Internal Network, we could confirm that this was the origin of the intrusion. The web server (192.168.20.1/24) in the DMZ was compromised, and from here the attacker could access the internal LAN using the Administrator account. To do this the attacker used Mimikatz to get the credentials of that machine and then ran Psexec against the internal server with the Administrator account.
We realized this when we checked the traffic from DMZ to the Internal LAN as follows (note the use of the flag SYN = 1
and ACK = 0
to show only connections initiated from the DMZ):
bmerino@Mordor:~$ tshark -r pivo.pcap -T fields -e ip.src -R "ip.src == 192.168.20.0/24 && ip.dst==192.168.1.130 && tcp.flags.syn==1 && tcp.flags.ack==0" | sort -u 192.168.20.1
According to this information the machine 192.168.20.1 (the web server) started some kind of connection with the internal server.
The following output shows an excerpt of the type of traffic generated between both machines:
bmerino@Mordor:~$ tshark -r pivo.pcap -o column.format:'"Info","%i","Protocol","%p"' -R "ip.src == 192.168.20.1 && ip.dst==192.168.1.130" | head -4
This would generate the following output:
Tree Connect AndX Request, Path: \\192.168.1.130\IPC$ SMB Redirect (Redirect for host) ICMP [TCP Retransmission] Tree Connect AndX Request, Path: \\192.168.1.130\IPC$ SMB Trans2 Request, QUERY_PATH_INFO, Query File Basic Info, Path: \PSEXESVC.EXE SMB
As shown in the output, the web server initiated a NETBIOS connection with the internal server (something totally suspicious). From there, he ran Psexec to authenticate to the server machine. You can also see the plaintext password and the user used to login the server (surely he uses Psexec with -u
option, which sends the password in clear text):
bmerino@Mordor:~$ tshark -r pivo.pcap -x "ip.src == 192.168.20.1 && ip.dst==192.168.1.130" | grep "A.D.M.l" -m 1 -A 1 | awk -F " " '{print $3}'
This would generate the following output:
A.D.M.l.o.c.1.0. 1...............
Note that there will be more complex cases that will require much deeper research. Take a look, for example, at this article at http://www.securityartwork.es/2012/11/27/covert-channels-2/?lang=en, which explains some covert-channel techniques with a few TCP and IP fields. In such cases, the joint use of debuggers, traffic analysis tools, and event correlation will be our best ally.