Using IOK rules to hunt for phishing sites across multiple threat intelligence sources

IOK ("Indicator of Kit") is a small, open source language designed for detecting and classifying phishing sites. It's based on Sigma, but adapted for analysis of websites, rather than security logs.

A simple IOK rule looks like this:

title: login-title
description: Page has the same title as Brand's login page
level: likely_malicious

detection:
  loginTitle:
    title: "Login | Brand"
    
  realDomain:
    hostname|subdomain: brand.com
    
  condition: loginTitle and not realDomain

Further examples are available on our IOK rule recipes page.

These IOK rules are run against every website submitted by Phish Report users, but are also proactively run against a number of threat intelligence sources.

How does a single IOK rule search across multiple threat intelligence sources?

A major reason we based IOK on the Sigma language, is that it can be easily converted to other, more-concrete query languages. The Sigma project has official support for over 50 different query languages, and there are multiple alternative implementations too (including our own: sigma-go).

This support for other query languages lets us take the same IOK rule and run it against many different datasources looking for matches.

Rule relevancy

It may not be possible to run a specific IOK rule across all datasources. For example, if a rule contains conditions based on the contents of a website, it doesn't make sense to run this rule against a datasource which just contains hostnames.

To solve this, Phish Report defines a range of support levels:

• URLs-only (for example passive DNS logs or website referrer logs)
• Static scans (just the returned HTML contents)
• Dynamic scrapes (full evaluation of a website in a virtual browser)

and only evaluates rules against datasources that can support them.

Handling unsupported features

Not all datasources can be queried against every field available in an IOK rule. For example, although IOK lets you match on the contents of the website HTML, it's rare for full-text search of webpage content to be offered by a threat intelligence source.

In these case, IOK rules can be evaluated in three stages:

1. Simplification to a supported subset. Unsupported conditions are removed to leave a rule which is supported by the datasource.
2. The datasource is queried using this simplified rule
3. The results are filtered using the full, unsimplified rule

This process guarantees precision (all results returned are truly match the original rule), but has variable recall (some valid matches may not be found in this process).

For example, urlscan.io doesn't support searching on the content of JavaScript files, so we cannot directly run this rule:

title: onlinecheck-wikipedia
description: |
  This site loads the Wikipedia logo as test of network connectivity.
  This technique is used by a specific threat actor in their phishing kits.

detection:
  logo:
    requests|endswith: "/portal/wikipedia.org/assets/img/Wikipedia-logo-v2@1.5x.png"

  noInternetJS:
    js|contains: "document.querySelector('.no-internet-wrap')"
  noInternetCSS:
    css|contains: ".no-internet-wrap{height:100vh;background-color:#fdfcfc"

  condition: logo and 1 of noInternet*

Instead, Phish Report:

1. Simplifies the rule to:

   detection:
     logo:
       requests|endswith: "/portal/wikipedia.org/assets/img/Wikipedia-logo-v2@1.5x.png"
   
   condition: logo 
   

   (as this is the only condition supported by urlscan.io's search API)

2. Converts this simplified rule to an urlscan.io query: filename:/.*\/portal\/wikipedia\.org\/assets\/img\/Wikipedia-logo-v2@1\.5x\.png/. Because loading the Wikipedia logo is not inherently malicious, this may return benign results

3. Filters the results to only those that also match the noInternetJS or noInternetCSS conditions

Benefits of writing your detections with IOK

Open core

There's no vendor lock-in with IOK rules. The underlying rule engine is open source and anyone can build on top of it.

If you write IOK rules with Phish Report, you can take these with you when you leave and either:

• Run them yourself
• Convert them into your new vendor's rule format

Write once, run everywhere

When we add additional datasources to Phish Report, you don't have to re-write any of your rules. We do the work of converting your rules to the new query format, and you get the additional coverage automatically.