Who is Listening in on Your Network?

The Threat of Data Exfiltration with Packet Capture Software

With the sheer volume of network traffic and the variety of applications that travel across a typical network these days, it is not surprising how easy it is to gather high-value artifacts using packet capturing software.

The goal of an attacker that is using packet capturing software is to grab usernames, email addresses, passwords and other sensitive information traversing a network in plain/clear text for further exploitation.

Not only that, but documents, videos, pictures and other files all have the potential to be reconstructed from a packet capture file (PCAP). The PCAP is then used by the packet capturing software to collect the data traveling across the network for post-examination.

Numerous protocols exist on many networks that, by default, send data in plain text, such as FTP, SMTP and HTTP. Free packet-capturing applications, such as WireShark, WinDump and TCPDump, make capturing networks all too easy. While packet capturing is a common tool for any IT professional, in the wrong hands, it could cause some serious damage.

For instance:

  • Suppose a hacker has compromised one or more machine on your network. Undetected, he begins eavesdropping on your network for sensitive data, before or after pivoting to different areas of the network. After the hacker gains initial access, he may wish to capture data from the network before making his next move.
  • Or in the case of an insider threat, perhaps there is a disgruntled employee who wishes to obtain sensitive information and exfiltrate the data. She could use packet capturing software to exploit your company.

Of course, it’s not all bad news when it comes to packet capturing software. Incident response teams regularly use packet capturing software in order to replay sessions, test malware for outbound network connections, or tell a story as to how a compromise took place and what the attacker actually did.

There is also the possibility post-incident that, if a certificate is captured, an encrypted network communication could be replayed in order to fully understand the scale of the malicious activity.

While the potential damage incurred through packet capture is high, here are a few things to put your mind at ease:

  • First, packet capturing is typically only very dangerous on broadcast networks (i.e., networks that use hubs to interconnect devices). Luckily, today many companies use packet switched networks (i.e., switches). Therefore, what a potential attacker sees would be far less visible to him. A further attack on the switch would be required to be more effective.
  • Second, the segregation of networks using VLANS or port security tends to make it more difficult to obtain any concrete artifacts due to different boundaries on the network.

So How Can You Proactively Monitor for Packet Capturing Activity?

Fortunately, due to the enormous number of different message source types, devices and applications that the LogRhythm Security Intelligence Platform supports natively out of the box, you just need to decide which servers or workstations you wish to monitor and then simply bring in the logs from the respective endpoints.

For example, if you were to open WinDump on a Windows 7/8/2008/2012 client machine and start capturing network traffic, you would see this event ID appear in the Windows Security Event Log:

Figure 1. Windows Event Security Log Event ID

Click image to expand

On a CentOS Linux 2.6 kernel-based machine (as a Linux-based example), if you were to manually change the network card to be in promiscuous (listening) mode to receive all traffic on its interface, you could issue a “ip link set eth0 promisc on” command, which would output the following in the audit.log file:

Figure 2. CentOS Audit Log File

Assuming you are receiving the logs from the target system, the above examples translate into the following:

Figure 3. Log Information

After being parsed, the above log sample shows you that the common event is “Startup and Shutdown” with the “Vendor Message ID” (event ID in this case) being 4688. The logon session of 0x3CC97 is also of particular interest. It can be further correlated on in order to find the offending login ID using the Correlate feature. You can do this by right-clicking on the log message and then clicking Correlate from the Context menu.

Figure 4. Correlating Log Information

Similarly, for the CentOS example, you can see the following data in the log information:

Figure 5. CentOS Example Log Data

From this message, you can see that the interface ID is eth0, the audit user ID is 500, the user ID is 0, the group ID is 0, and the session ID is 1. Knowing this information should make it easier to now go ahead and contact the Linux sysadmin/team for closer inspection.

For alarming, you can either choose to use a standard alarm or use a simple log observed AI Engine alarm, such as the following:

Figure 6. AI Engine Rule

With the flexibility of the lists function, you can even pre-populate the list with any other software that you wish to be alerted on when it is launched, which may infer potential suspicious or malicious activity. With the AI Engine rule configured, you can receive instant notification when packet capturing software is running or when promiscuous mode is enabled on a Linux machine—all out of the box using LogRhythm’s built-in features.

Figure 7. Alarm Configured

Put an End to Eavesdropping on Your Network

By setting up the servers and workstations you wish to monitor and bringing in those logs, you can have visibility of any eavesdropping behavior on your network with minimal effort. You can put these processes into place and sleep well at night knowing that you’ve limited the potential of data exfiltration on your network.