We have been quite silent in the past month as we didn’t have much free time to update our blog, so let me apologize on behalf of whole team, but being silent doesn’t really mean we haven’t worked hard on the backend to improve our technology.
During this month we have doubled the number of daily unique IPs, from ~500 daily unique IPs to around ~1.100 daily unique IPs, which is fantastic even because we’re getting more and more users with very positive feedback. Also number of hits per day went up to ~100.000 requests/day – excluding API requests.
Among the new features we are going to release during this month, we’re going to update our Splunk App which will turn into a very strong interface between Splunk and Deepviz platform, with full threat intelligence embedded into Splunk pages.
Anyway, one of the very exciting things we have silently released during the past week is closely related to our malware analysis engine and this is something we’ve been recently asked for.
If you are familiar with Deepviz Malware Analysis platform you already know we can sniff network traffic leaving our environment and simulate network activities, then using such captured packets to isolate what data is being transmitted by the malware and to identify malware families by fingerprinting packet data structure. Clearly this is possible only if the traffic is in plain-text, e.g. classic HTTP connection. That said, many samples switched their communication protocol to a more robust HTTPS, thus leaving only the domain address visible but completely hiding whole interesting data behind a strong SSL/TSL encrypted channel. This is bad as it can easily evade from network IDS/IPS controls and mix itself up with legit HTTPS traffic.
With Deepviz we had the same problem while analyzing malware, as you can see from the screenshot below, we were able to identify the destination but we couldn’t see any of the interesting data.
Our team worked hard during the past 3 weeks and the past week we have silently rolled out a major update to our engine, by implementing on-the-fly TLS/SSL network decryption, emulating a valid root CA and forging on the fly the needed public/private key pair to trigger malware into establishing connection and thus logging the hidden data. We now also show complete URL as well as used user agent, which is often a good indicator for specific malware families.
Just one more thing: no, we don’t look for TCP connections to port 443 to identify TLS/SSL connections, we deeply analyze every packet going out from our network and deep inspect for TLS/SSL handshake, then we simulate the handshake and log the transmitted data, no matter whether it’s HTTP or plain socket connection, no matter whether it’s on TCP/443 or e.g. TCP/58457. If it’s TLS/SSL, it’s for us.
Last, but not least: we have recently added static analysis of PDF/OLE files, but we’re going to roll-out dynamic analysis for them as well as full analysis of .JS files.