I’ve posted about dynamic and automated analysis of the Zeus malware, but what about identifying Zeus from firewall & IDS logs?
After executing Zeus, my Sophos UTM generated a few alerts. This is something that would absolutely stick out to me during daily log analysis.
Drilling into the alert tells us threat “C2/Zaccess-A” attempted to reach out to a German server (.de) 36 times.
It looks like my Sophos FW (IPS) blocked the outbound connections from Zeus. This explains why the flashplayerinstall.exe was not successfully downloaded. I initially thought it was an OS compatibility issue, but appears the FW blocked the connection.
The next thing I want to take a look at is if the malware fired any snort alerts. We’ll login to squert (Security Onion) to see our alerts:
Then we’ll filter by the source ip of the infected host.
This outputs 3 unique alerts, all referencing the DNS requests from the Zeus malware.
If we expand the first alert to fire (bottom), we see a DNS attempt to a German IP address (.de).
The payload isn’t very descriptive and not much can be identified from the data. In order to detect this traffic it’s absolutely necessary to baseline the alerts on your network. This could easily get lost in the sea of alerts.
The second alert displays the same info as the first. The only difference is instead of “DNS traffic on DNS port Reserved Bit Set,” the alert reads “DNS port Opcode 8 through 15 set.”
This brings us to the remaining 27 alerts. Marked as “ET TROJAN ZeroAccess udp traffic detected,” it appears this alert triggers after every DNS request from Zeus. From my experience as an analyst, I’ve been successful with prioritizing ET Trojan alerts during threat hunting and alerting. We create an report in our SIEM to identify “ET Trojan” alerts.
Unfortunately, the payload data is exactly the same and provides no additional insight.
It looks like Sophos was the last line of protection in preventing the download of Zeus’ payload “flashplayerinstall.exe.” I’ll have to make an exception when executing malware in the future, but it’s nice to see defense in depth in action.
If we take a look at sguil alerts in Security Onion we see that for some reason, squert wasn’t displaying all the alerts associated with the IP
If we right click the Alert ID, we can select a number of way to carve up the traffic. I typically select transcript, but in this case, we’ll look at networkminer
Full packet capture transcript. We can see the request to download the payload via the HTTP request (blue) and a red 200 response, signifying the connection was successful.
We can also select Network Miner, which is able to carve out the file download attempted to my machine
Here’s how we’d export the file in Wireshark:
Wireshark identifies the files and will allow us to save the file for further analysis.
I could continue to go down the rabbit hole with the chrome_installer.exe file, but I think it’s a good point to cut off our analysis. In a real world example, I’d take the IOCs derived from this analysis and search for related incidents in a SIEM. Using network, OS and security control logs, our goal is to identify and scope a compromise. Based on this data the process can become cyclical. Incident Response drives analysis of related events via a SIM. If additional machines are discovered to be compromised, IR analysis begins again. IR and SOC analysis should always compliment one another. IOCs must be effectively communicated between both parties to uncover the full scale of a compromise.