IDS systems are fragile. As a penetration tester, I have flown under the radar countless times. Most IDS systems depend on known bad signatures (which are often poorly written). They look for things like large NOP sleds, malicious EXEs, IRC traffic, and SYN scans. Some systems are much better, but many aren’t.
Once an attacker has access to a system, he needs to maintain access. My favorite technique for accomplishing this is to spawn a new thread by injecting it into Iexplorer. This works well, as all Windows systems have Internet Explorer and in all but the fewest cases, it has ready Internet access. From there, it’s easy enough to use Microsoft’s API to communicate via SSL to a remote C&C webserver. In 5 years of penetration testing, I’ve never seen this detected.
How do you detect C&C from the network when the traffic is inside a SSL tunnel? There’s no good solution to this problem. However several ideas come to mind:
- Create netflows for all traffic. Measure the sent and received data. Use statistics to find anomalous traffic. In general, botnets will often send more data than typical web traffic. Compute statistics on the traffic and identify anomalies that need further research. This has been previously discussed. The buzz term is statistical traffic volume analysis. However, I haven’t seen a tool to test this approach, so I’m currently writing a simple prototype.
- Create netflows for traffic. Utilize the previous statistical metrics, but combine this with network traffic relationships. To do this, implement directed graphs. For instance, you might detect a compromised machine via the former method, but know you need to determine what machines it attacked — not just communicated with. Often, the attacking machine will initiate a probe or (blindly) initiate an attack, but in either case initiate the connection. As discussed above, I generally don’t use a traditional shell or reverse shell. I want a known good service to callback. So a second connection is often initiated from the attacked machine to the attacker. From this point, the traffic volume statistics should also apply. The attacker will datamine or pivot through the attacked machine causing unusual (for http) traffic patterns. The direct graph can be used to reduce the traffic for analysis into subsets where more precise statistics can be computed.
These methods are far from perfect. In fact, I wouldn’t even say they’re good, but then again there are few good methods I’ve heard for tackling this type of problem. The only one that comes to mind is a statistical analysis on traffic times. For instance, looking for regular call-back intervals. I find this difficult, as many implants will call back every couple of days or at best every several hours. This is a difficult challenge to program as the memory requirements to log every packet time, source ip, dest ip, and size for any length of time on a fairly large network are enormous. Additionally, the mitigation is fairly trivial — add a random delay of up to several hours.
In the next week or two, I hope to release prototype code (netent) that implements the statistical traffic analysis. Currently it’s working fairly well, but I need to tune it better, determine how to display data, and clean up the code. It currently (successfully) identifies gmail and facebook as anomalous. This makes sense as both are highly chatty Web 2.0 applications that send a lot data compared to other sites — where you typically send very little and read a good deal. Therefore, the traffic is anomalous in a manner similar to compromised hosts. The challenge going forward is reducing benign anomalous traffic while still capturing possibly malicious anomalies.