Negative space and filling gaps in YARA


Using negative space and inverse matching is a lesser-seen but excellent technique to type and classify files. Here the point is not to look for what is there, but to look for what isn’t there — when it should be. Besides an excellent presentation technique it’s also a method borrowed from threat intelligence (TI). One of the tenets of structured TI is that all intelligence has a class that defines a structure. For example, events have a beginning, end, and midpoint to go along with the elements that represent the event. Previously we talked about a phishing event. It had a start, beginning, and midpoint; as well as the elements of the phishing: an email, targets, consequences, etc. The point of saying structure exists is to outline that some elements must be present. Finding evidence of C2 activity in your network traffic means not only have you found the C2 (receiver), but likewise that a sender and a message also exists. By extension, you can infer a timeline and history exists that could contain additional traffic. Additionally the sender, likely malware, implanted the system at some-point previously and that too will have its elements to investigate and define. Structure, therefore, is important to not only know, but also have handy as your investigation grows more complex and detailed. It helps maintain consistency and deliver due diligence.

DNS Constellation

Back to negative space and inverse matching. For YARA, negative space really shines when you have definitives. The sticky-keys exploits were a well-known and often-used attack against endpoint systems. Gaining access and replacing one of the well-intentioned, but ultimately vulnerable helping tools on the Windows OS was part of the standard playbook of many adversaries. They used it because it worked and, once in play, became a good disguise against detection. It’s a perfect storm situation for YARA. Those binaries are standard and pretty-fixed and building a detection for them is straightforward. Looking for when that binary exists, but doesn’t match what should be there is the inverse match.

Florian Roth from BSK Consulting previously spoke on this topic in detail and posted good YARA rules for sticky-keys exploits. One of the newer techniques since his rules release was an update to the PE module that allows for matching against a PE’s version information. Misspellings and changes to CompanyName, OriginalFileName and other version information are a rich source to look for changes. Condition lines for sethc.exe might look like:

[minti_blockquote]Rule sethc_anomaly {

condition: (NOT pe.version_info[“CompanyName”] contains “Microsoft”) OR (NOT pe.version_info(“InternalName”] contains “sethc”) OR (NOT pe.version_info(“OriginalFileName”] contains “sethc”) }[/minti_blockquote]

You could also check to make sure the digital certificate is valid (see below), signed correctly and many other approaches.

[minti_blockquote]rule valid_timeframe {
for any i in ( – 1):
pe.signatures[i].not_before == 1409184000 and
pe.signatures[i].not_after == 1440806399) }


About the author

Monty St John

Monty is a security professional with more than two decades of experience in threat intelligence, digital forensics, malware analytics, quality services, software engineering, development, IT/informatics, project management and training. He is an ISO 17025 laboratory auditor and assessor, reviewing and auditing 40+ laboratories. Monty is also a game designer and publisher who has authored more than 24 products and 35 editorial works.