Short Tutorial: How to Create a YARA Rule for a Compromised Certificate

Working in incident response or malware analysis, you may have come across compromised and sometimes revoked certificates used to sign malware of different types. Often threat groups use stolen certificates to sign their malware.

I’d like to show you an easy way to create a YARA rule for such a certificate. We will look at a sample that has been marked as malware by many Antivirus engines on Virustotal and the “Details” tab shows a revoked certificate. That’s a good indicator for a compromised certificate that has been and sometimes is still used by threat groups to sign their binaries.

Sample: ee5340b2391fa7f8d6e22b32dcd48f8bfc1951c35491a1e2b4bb4ab2fcbd5cd4

Let’s look at the details. I recommend creating a YARA that uses the “pe” module of YARA and integrate the Serial Number and the Issuer of the certificate to create an unambiguous rule.

rule MAL_Compromised_Cert_Nov18_1 {
      description = "Detects a compromised certificate of CORP 8 LIMITED - identified in November 2018"
      date = "2018-11-01"
      hash = "ee5340b2391fa7f8d6e22b32dcd48f8bfc1951c35491a1e2b4bb4ab2fcbd5cd4"
      uint16(0) == 0x5a4d and
      for any i in (0 .. pe.number_of_signatures) : (
         pe.signatures[i].issuer contains "COMODO RSA Code Signing CA" and
         pe.signatures[i].serial == "4c:75:75:69:2c:2d:06:51:03:1a:77:ab:49:22:4c:cc"

As you can see, you need to copy two strings from Virustotals web page:

Copy the CA name and use it for the “.issue” condition as well as the serial number, which you use for the “.serial” condition. Make sure that you changed the casing to lower-case as YARA does not expect and understand uppercase characters in the serial field.

Virustotal Intelligence users can use the following hunting rule to detect new uploaded malicious samples with revoked certificates:

rule Compromised_Certificate {
    // New files, detected by more than 30 engines and revoked certificate
   new_file and positives > 30 and tags contains "revoked-cert"

YARA Rule Creation Crackme

I’ve collected some interesting samples for an internal YARA rule creation training session with our interns. With this blog post, I’ll also share 3 new premium feed YARA rules by pushing them to the Open Source signature-base repo.

What are the the preliminary conditions for the rule creation?

  • We don’t want to to spend more than 20 minutes for a single rule.
  • We use string extraction, hex editors and yarGen
  • We also use public resources like Google (yes),


  • You need a Virusbay account to download the samples

So, get ready. We process the following 3 cases.

Turla Agent-BTZ

  • Great for yarGen string extraction
  • Especially check for variations of strings (in PE header) that are highly specific
  • Use google to check strings


PLEAD Downloader

  • yarGen will not produce good results in this case
  • Try to compare the samples in order to find specific strings that appear in all of them

Sample 1

Sample 2

Sample 3

Sample 4

TYPEFRAME (Hidden Cobra)

  • Authors missed some specific strings



Don’t check the solution before you’ve created your own rules.

Agent.BTZ YARA rule



Remember, there is no single correct solution to this task. Your rules may be better than mine. If that’s the case, please share them with me 😄.

Write YARA Rules to Detect Embedded EXE Files in OLE Objects

This is the first blog post published on our new website. If you followed my blog on you should consider subscribing to the RSS feed of this blog or the “Nextron Systems Newsletter”.

This is one of the YARA related blog posts showcasing a special use case. Last year I noticed that I wrote many rules for hex encoded strings found in OLE objects embedded in MS Office documents and RTF files.

I did most of the encoding and decoding work on the command line or with the help of CyberChef, an online tool provided by GCHQ. I also thought about a new YARA keyword that would allow us to write rules without encoding the strings.

Today, rules contain strings in a hex encoded form. I usually add the decoded string as a comment.

$s1 = "68007400740070003a002f002f00" /* http:// */

Rules with the new keyword would look like this:

$s1 = "http://" wide hex

Neat, isn’t it? I already forwarded that feature request to Wesley Shields (@wxs) but it seems to be no low hanging fruit. I’ll keep you informed about this feature via Twitter.

A tweet by Kevin Beaumont reminded me of the work that I’ve done and while looking at the tool by Rich Warren. I thought that I should create a illustrative example of a more generic YARA rule that explains why the “hex” keyword would be very useful.

The tool creates weaponized RTF files with hex encoded payloads.

I derived some strings for a new rule from the decoded object.

/* Hex encoded strings */
/* This program cannot be run in DOS mode */
$a1 = "546869732070726f6772616d2063616e6e6f742062652072756e20696e20444f53206d6f6465" ascii
/* C:fakepath */
$a2 = "433a5c66616b65706174685c" ascii

To further improve the rule I went to my goodware directory and ran the following command to generate a list of the most frequent PE file headers in a hex encoded form.

neo$ find ./ -type f -name "*.exe" -exec xxd -ps -l 14 {} ; | sort | uniq -c | sort -k 1 | tail -10
4 4d5a87000300000020000000ffff
4 4d5aae010300000020000000ffff
4 4d5abf000300000020000000ffff
4 4d5add000300000020000000ffff
4 4d5aeb000300000020000000ffff
6 213c73796d6c696e6b3e2f757372
8 4d5a72010200000020001700ffff
88 4d5a40000100000006000000ffff
116 4d5a50000200000004000f00ffff
5852 4d5a90000300000004000000ffff

Then I used these hex encoded strings in a YARA rule that looks for these strings in the OLE objects of an RTF file.

rule MAL_RTF_Embedded_OLE_PE {
      description = "Detects a suspicious string often used in PE files in a hex encoded object stream"
      author = "Florian Roth"
      reference = ""
      date = "2018-01-22"
      /* Hex encoded strings */
      /* This program cannot be run in DOS mode */
      $a1 = "546869732070726f6772616d2063616e6e6f742062652072756e20696e20444f53206d6f6465" ascii
      /* KERNEL32.dll */
      $a2 = "4b45524e454c33322e646c6c" ascii
      /* C:fakepath */
      $a3 = "433a5c66616b65706174685c" ascii
      /* DOS Magic Header */
      $m3 = "4d5a40000100000006000000ffff"
      $m2 = "4d5a50000200000004000f00ffff"
      $m1 = "4d5a90000300000004000000ffff"
      uint32be(0) == 0x7B5C7274 /* RTF */
      and 1 of them

The first analysis of the coverage looks pretty good. I see only clear matches in munin‘s output.

The few questionable matches look fishy enough to release my rule.

If you have further ideas to improve the rule, ping me via Twitter.