Cythereal MAGIC generated Yara rules for VPNFilter also catch other botnet families
Malware authors share and reuse tried and tested code. Such sharing of code can be exploited, as we demonstrate here with the VPN Filter malware.
We used Cythereal MAGIC to generate Yara rules for VPN Filter malware. These rules, when applied on a large malware collection, flagged VPN Filter variants, as expected. In addition, the rules also triggered on variants of PNScan, Mirai (Gafgyt), Filecoder, and Tsunami, while producing ZERO false positives.
This is important and exciting as it provides evidences that sharing of code between malware can be weaponized. That is, you can use code from one malware family to catch not-yet-seen variants of not just the same family, but also of other malware families.
Related reading: Weaponizing Malware Code Sharing with Cythereal MAGIC
Early in May Cisco Talos reported finding a new Linux botnet, that they named VPN Filter. The Talos report described that the VPN Filter attack to consists of three stages. The report published hashes of 12 malware binaries for three architectures: ARM, MIPS, and x86. Of these eight files were for Stage 2 of the attack, two for ARM, three for MIPS, and two for x86. The remaining four files were Stage 1 and Stage 3 of for MIPS and x86. There was no file reported for Stages 1 and 3 of ARM.
We uploaded the 12 malware binaries into Cythereal MAGIC. MAGIC returned clusters of malware containing the VPN Filter malware, generating Yara rules for each cluster. MAGIC’s Yara rules are based on the code shared between malware in a cluster.
Here are our findings:
1. MAGIC re-discovered clusters identified by Talos
MAGIC correctly rediscovered the groups of Stage 2 binaries reported by Talos, the only stage with multiple binaries in Talos reports. It automatically found that the two ARM binaries, three MIPS binaries, and three x86 binaries had shared code. The other four files remained singletons, as they were in the Talos report.
The following table provides the number of distinct shared procedures between binaries in each cluster.
|Architecture||Talos count||Num of Distinct Procedures||Distribution type||# Shared Procedures||% Procedures Shared|
|ARM||2||472||In both files||465||98.51%|
|In 1 file||7||1.49%|
|MIPS||3||780||In all 3 files||567||72.69%|
|In 2 files||100||12.82%|
|In 1 file||113||14.49%|
|X86||3||791||In all 3 files||628||79.40%|
|In 2 files||62||7.83%|
|In 1 file||101||12.76%|
MAGIC groups two or more “semantically similar” procedures as a single distinct procedure. MAGIC found that the three Stage 2 MIPS files of the malware collection identified by Talos have 780 distinct procedures between them. Of these 567 (72.67%) are in all three of the files, 100 (12.82%) are in two of the three files, and only 113 are in only one of the three files. The two Stage 2 MIPS malware have 472 distinct procedures, of which 465 (98.51%) are in both the files. Similarly, the three Stage 2 x86 files have 791 procedures, with 628 (79.40%) in all three files, 62 (7.83%) in two files, and 101 (12.76%) in only one of the files.
Well, Talos had already found this grouping. So what’s new?
The new part here is automation. We threw the 12 VPN Filter binaries into MAGIC’s collection of around 1 million malware. Each was uploaded individually, without any information about their known association. MAGIC came back with clusters that matched those published byTalos. Which means instead of reverse engineering each malware manually and using Bindiff to find shared code, MAGIC do this entire work automatically.
For a full list of shared procedures, see: Bindiff of x86 stage2 malware
2. MAGIC generated Yara rules found variants of other malware families
So, how do the MAGIC generated Yara rules perform in the field. To answer this question we shared our VPN Filter Yara rules with three companies: a very large security company based in US, a European AV company, and a European AV testing company.
The three companies independently scanned their benign and malware collection with our rules, and reported the following:
1) Each reported that the rules did NOT trigger any False Positives.
2) Each reported that the rules caught all the VPN Filter variants.
3) Each reported that the rules detected not just VPN Filter malware, but other malware variants, as well.
That all the companies reported that the rules did not generate any False Positive is significant because the companies serve different market segments and are likely to have very different set of benign files.
We further investigated the malware variants caught by our rules on Virustotal. Turns out that the malware caught by our rules span several known router malware, including PNScan, Mirai, Filecoder, and Tsunami.
This is the power of leveraging the shared code between malware families: The shared code can be used to detect not just known malware, but also unknown ones (since, MAGIC didn’t know of the malware variants that the three companies found).
Want more details?
The table at the end of this note presents hashes of the malware found using our Yara rules.
Visit https://bitbucket.org/cythereal/threat-intelligence for our analysis and Yara rules.
The bitbucket repository provides a lot of details that will whet the appetite of a reverser. It gives the actual RVAs of the matching procedures across a large number of malware and, when available, the names of the functions.
Want to Access MAGIC?
Please contact email@example.com
Hashes of malware detected by our rules
The following table gives hashes of malware detected by our Yara rules (as reported by one of the companies). Since our Yara rules are based on code, this list indicates malware that shares code with VPNFilter.
|ARM Stage 2|
|X86 Stage 1|
|X86 Stage 2|
|X86 Stage 3|