YARA Part lll

This is a follow up to the previous posts about YARA.

If you haven’t read part I or part II, a good way to mentally model what YARA can do is the following

• What regex is for text, YARA is for files

• What Suricata is for network traffic, YARA is for files (malware)

• What Sigma is for logs, etc.

It really is a versatile tool, which you can do much more than scan for malware with. (You can actually leverage any of the above mentioned tools along with YARA)

You can use YARA for any of the following

• detecting a specific sample of malware

• detecting a specific class of malware

• scanning email attachments

• testing for certain strings in memory

• utilities that need to verify file formats

When it comes to doing any meaningful amount of testing or running YARA at scale, having a good dataset is in order.

As mentioned previously, some ideas for building a malware corpus

• VirusTotal

• AnyRun

• Vx-Underground

This last option has some large datasets if you go to the Yearly Archives

Building “Goodware” AKA Clean samples

• Microsoft, or Ubuntu ISO’s

• Blank files

These are just some ideas to form your datasets.

Deep Dive on a Rule

This is a rule looking to match on malware that masquerades itself to look as a legitimate Windows system binary.

In this case, the rule is looking to match on a specific sample of Ferocious Kitten APT.
https://attack.mitre.org/groups/G0137/

Sample rule for Ferocious Kitten sample

In the strings section, you can see it’s looking for these 2 bitsadmin commands in the contents of the file. It’s also looking for the file to be unsigned.

The conditions section is checking for unsigned files that match on any of the defined strings from the strings section.

Now, there could be signed malware of course, but this is a fairly simple example rule.

Let’s take a look at a more refined rule looking to detect similar behavior, rather than matching on a specific sample.

A more robust rule

This one is has a bit content to it, but in a nutshell is looking to do the following

• defining strings for legitimately Microsoft signed files

• a regex pattern to match on a given file path

• a PE header check

• printing to stdout file name

• excluding the previously defined strings for Microsoft signed files

Is this rule perfect? No, but it will catch many instances of malware masquerading itself.

A good way to limit your rule to a specific filetype, is with the header.
Take this condition for example as shown above

condition:
    uint16(0) == 0x5a4d

This is checking for the PE MZ header in Windows files.

Or this one, checking for the ELF header in Linux.

condition:
    uint32(0) == 0x464C457F

For more on this, see this resource

https://www.optiv.com/insights/source-zero/blog/selective-yara-scanning-whats-your-type

This accomplishes two things: you narrow the scope of your rule for higher fidelity, and your rule doesn’t alert on itself. Say you’re testing across a large dataset, you don’t want to be matching a string on filetypes that you are not even looking for.

What I Read This Week

• The role of Legal in Cybersecurity continues to increase

• Golssue - Tool Behind Recent Github Phishing Campaign

• Snowflake hackers identified for 2023 AT&T breach

  • The actual indictment if you’re curious

---

Conclusion

This was part of the Tools Series, where we go over various security tools for the job.

In this post, we continued on the capabilities of YARA and dove into the details behind a rule and what it would detect on.

See you in the next one.

---