The Heartbleed incident is starting to settle down. At my company most of our systems are patched and secured now, which makes it a perfect time to go back and do a little post incident research.
Mandiant recently released an article about finding hijacked VPN sessions by correlating a number of log sources (including VPN logs, IPS logs, and web server logs). At my company we wanted to do the same thing, but on the cheap. Our infrastructure logs don't lend themselves well to that sort of search, so we limited ourselves to VPN logs. Here's what we did.
The scenario is that a user is logged in to your VPN appliance getting work done. An attacker uses Heartbleed on the VPN appliance to grab the session keys needed to hijack the session and proceeds to impersonate your user, gaining potentially the same level of access into your network as your user.
As the attacker performs activity their IP address and the IP address of your user should alternate in the VPN logs rapidly for at least a period of time. It is always possible that an attacker would hijack a session right at the end of the legitimate user's activity, but given the volume of packets an average machine sends per second, we decided to count this unlikely.
So that's the signature we're searching for: two IP addresses that are sending traffic for the same user alternating very quickly.
"What if a user legitimately uses two different IP addresses? Like they work at a coffee shop for a while and then oh home?" Very good point. And it's always possible (
Your VPN appliance probably logs lots of things about your user sessions. One of the most common logs we chose to filter was key renegotiation. You may want to do some manual paging through of your logs to look for anything that is obviously not malicious.
Here's the groovy script I used to do this.
If you find anything you get to kick off your incident response process, look at what that user was doing and what they have access to. Best of luck with that part!
No comments:
Post a Comment