It is obvious that none of our signatures matched on a valid Windows system file that just had a different name – cmd.exe renamed to sethc.exe. The signature was still intact, the MD5 and SHA1 hash of the file a well known one and listed in the “trusted-md5-hashesh” database. Therefore I introduced the so called “Inverse Yara Signature Matching” that checks if certain system files contain specific strings. THOR extends the Yara functionality by certain values that may be checked including the “filename” of the scanned file. This could also be accomplished by the Yara integrated functionality of external variables.
So – I combined the file name with strings that must exist in the system file and generated a rule that checks for the existence of 4 different strings that I extracted from all “sethc.exe” versions from the different operating system versions (Windows 2003, Windows XP, Windows 7, Windows 2008 and Windows 2012).
$s1 = "stickykeys" fullword nocase
$s2 = "stickykeys" wide nocase
$s3 = "Control_RunDLL access.cpl" wide
$s4 = "SETHC.EXE" wide
$filename = "filename: sethc.exe"
condition: $filename and not 1 of ($s*)
The rule matches if the analysed “sethc.exe” does NOT contain the typical string values and therefore indicates a manipulation. This method could be extended to other system files that are typically replaced or placed in uncommon directories like an “explorer.exe” in the “C:\Windows\System32” folder or a “svchost.exe” in the “C:\Windows” folder. We have already integrated checks that compares the file extension with the actual file type but this definitely bringst the anomaly detection to a new level.
Applying the rule listed above we detected over 15 server systems with this backdoor modification in place in a distributed THOR run. In case of the “sethc.exe” we had no false positives but they are possible if new operating system versions of the “sethc.exe” are checked.
With this method you are not able to determine the exact malware or malicious modification of the analysed file but you will at least be able to detect the modification.
Thanks to Chad for the back reference to our blog. I even created more rules that match on valid Windows system files and described a way to scan a system with Windows PowerShell. You can find the second part of my article here.