Using Corelight to monitor and identify exploited VPNs
Network and security devices operate with vulnerabilities that can be exploited. Here's how to use Corelight to monitor and identify exploited VPNs.
One of the many interesting things we stumble across in the Black Hat NOC (Network Operations Center) is the various applications exhibiting poor security hygiene. Usually it’s something in the clear that makes us chuckle before we move on to more serious matters. Sometimes it’s something more serious that requires letting an attendee know they’re leaking sensitive information. Then, on other occasions, it’s something like a video game running on a device that is only partially encrypted. Seeing such data raises even more eyebrows when one of the games happens to be open in my own taskbar.
What stood out the most was not that there are overlooked, common applications that could leak information; but that the network streams were partially encrypted as if certain aspects of the games were accidentally neglected when it came to securing its various communications.
As a player of this game myself, I find this especially interesting. While skimming through the ‘etc_viz’ Corelight log (we’ll touch on this log further down in this blog), I noticed a bunch of ASCII strings associated with outbound TLS connections to a game developer that I recognized. Looking at the metadata, it was clear that the data was from in-game; someone else at the conference was playing this game too. What struck me first was that some of the in-game actions were unencrypted, while others were not. For example, as shown in the image below, actions that typically follow combat in the game, such as looting a creature, gave us insight into what items were available for pickup. In some cases, we could see which creature was fought and which items were dropped. Nice job in slaying the armoured zombie.

We were able to identify the username, and world that the player was on. To be honest, my first thought was to log in and go say hi, but the data showed the player was on a different variation of the game, which was a bummer.

A more serious finding was that potentially chat information inconsistently leaked. While it was fun to explore this gamer’s in-game activity, the availability of a Discord server and event planning were a bit more alarming. Is there anything sensitive about a Penguin Hide n’ Seek mini game at the Ardougne Zoo? No. But it does raise the question, what else is leaking? A lesson we often teach others is to be wary of what you put online, because you never know who else may see it. This extends into in-game chat, where we expect everything to be encrypted.
But hey, good luck at the Well of Souls, fellow gamer.
Let’s let this image speak for itself for a moment.

Similar to the previous section, we observed partial encryption here as well. Frankly there were too many nicknames (usernames?) to highlight. While the game is different, the lesson is the same: Be careful of what you put in chatrooms online. Just because we think communications are encrypted doesn’t mean everything within them actually is.
We discovered at this show yet another game partially encrypting traffic. This one mostly made us chuckle. While we didn’t see any chat information, we were pretty invested in seeing all the rewards the player earned throughout their time in the conference. Some example rewards included:
Nice work earning those rewards, but perhaps we should spend more time focusing on cybersecurity training instead.
At Corelight, we experiment quite a bit. One of the logs our Labs team created for research is the ‘etc_viz’ log, which is available to all Corelight customers as part of the Encrypted Traffic Collection. Among other things, this log helps identify unencrypted traffic in the middle of encrypted traffic streams. Where it really shines is its ability to identify ASCII strings inside encrypted payloads. As an industry, we often assume that when we see TLS, the payload is effectively useless because it shouldn’t (key word here) be readable. What we have learned through our years serving in the Black Hat NOC and working with our customers is that encrypted does not always equate to encrypted well. When we are hunting in the Black Hat NOC, we use this log to very quickly and efficiently find ASCII strings.
Here is an example of a couple of fields in the log from the tower defense game above.

What this showed us is that for this particular connection, the client-to-server (c2s) connection was probably encrypted, while the server-to-client (s2c) connection very clearly contained JSON-formatted cleartext.
While this blog was focused on fun and games, the practical application of using that log is the same for more serious hunts. Should we just blindly trust that our data is actually being encrypted to the extent that we expect? Or should we leverage the rich metadata available to us on the network to verify? The answer to that question is up to you, but personally, I will always side with a motto: trust, but verify.
Network and security devices operate with vulnerabilities that can be exploited. Here's how to use Corelight to monitor and identify exploited VPNs.
We hosted a virtual CTF tournament where hundreds of players raced to solve security challenges using Zeek data in Splunk and Elastic. Here are the...
Corelight just released our v17 software. Here are the details about how these new features can enhance your data, speed up your IR workflow, and...