Introducing "threat injector" for Azure Sentinel

Here's my brand new tool for pen testers and ethical hackers in Azure I wish to introduce as part 3 on my series on improving detection in Azure Sentinel.

As a recap:

• Part 1 demonstrates the current limitations of Azure Kusto for detecting statistical anomalies in Azure Activity logs;
• Part 2 proposes a new detection model derived from features I think are missing in time-series decomposition.

So we have this new model, and we wish to test it. How should we proceed?

Lessons learnt from biology

If you remember, the core of the model explained in part 2 is based on Markov chains, i.e. transitions between sequences. An anomaly is nothing more than an unexpected transition popping up in a chain.

To verify that anomalies are properly caught in our model, we can inject trackers into an existing valid chain. A tracker is not a random sequence, it's a sample of real-life activity taken from actual Azure logs. It can be:

• actual malicious activity or
• legit admin activity placed out of context. For example, we may pick the session of an administrator troubleshooting the configuration of a VNet peering and inject it into the session of a CD/CI automaton deploying assets into the VNet peers as part of its routine, white noise activity.

Possibilities are countless, we must choose the ones which make sense for us.

Trackers injection works exactly the same way as genes edition where enzymes are able to add or remove targeted amino acids to a DNA string. Genes edition has been soaring since 2012 when it was discovered that a system called CRISPR-Cas9 could be genetically programmed to perform editions with ease and precision. It works so well that Emmanuelle Charpentier and Jennifer Doudna, the inventors of CRISPR-Cas9 programming, received the Nobel Prize in 2020.

The name of my tool is a dedication to this powerful technique.

Porting CRISPR-Cas9 to the threat intel world

We have two ways to inject our trackers: we may either work at the raw logs level and intersperse logs into an existing logs chain, or work directly at transitions level and inject sequences into the probability matrix of the Markov state machine.

Both are equally easy to implement and give the same results, of course. But for auditability and troubleshooting, I find it much more satisfactory to work at raw logs level.

How to make proper trackers for our raw logs, then? For ease of handling, we need to find a good way of watermarking the samples we wish to turn into trackers. Let's see how timestamps work in Azure.

Watermarks, "jiffies" and causality

In Azure, time measures are rounded into ticks, 100 nanoseconds each. Azure Activity logs are no exception.

On close quarters, we notice that the TimeGenerated type is rounded to the millisecond, so if we base our time-series on TimeGenerated we can leverage what I call the jiffy, a 4 digits gap between the magnitude of milliseconds (10E-3) and ticks (10E-7) to squeeze-in a watermark that is unique for each tracker. This way we have up to 10^4=10000 watermarks at our disposal to uniquely identify overlapping trackers without collision.

Resorting to milliseconds rather than ticks for ordering events in an edited time-series may occasionally break local causality, but honestly do you believe that for any couple of events separated by less than a millisecond, causation should be ever taken for granted?

Now that we can "track our trackers" thanks to watermarks, we can easily add or remove as many of them into a given sequence.

But for that we have a last problem to solve... how to manipulate Azure logs?

Growing Azure Sentinel in vitro

In vivo (picture on the right), Sentinel relies on a dedicated Log Analytics workspace to build up Azure security events; you enable a connector to Azure Activity logs and the workspace starts to be fed in batches.

To edit logs, we need to severe that umbilical cord and replace it with a data source fully under our control. Here is the recipe to go soilless (in vitro):

1. Pull Azure Activity Logs with the Log Analytics API (red bullet 1 in the picture below);
2. In a CRISPR-Cas9 compute instance, add trackers to your local copy of logs;
3. Upload the modified logs to Azure Files;
4. Design a Sentinel Analytics Rule using your Azure Files as external data (red bullet 2);
5. Wait for the rule to fire ;
6. Investigate alerts;
7. Rinse and repeat.

The in vitro set-up will look like this:

As you can see, the CRISPR-Cas9 compute instance acts as a customer-controlled ETL sitting between Log Analytics and Sentinel.

Conclusion

We have designed a technique for simulating threats and performing threat intel at will on time-based logs in a native soilless Azure Sentinel.

Beyond Azure, it can be used for benchmarking OSINT tools, performing purple-team simulations, training devSecOps... All this in an auditable and explainable way.

My personal use case is testing, improving and gaining confidence in the Markov detection model explained in part 2. In part 4, I will run through a small case study to give you a better grasp of it.

I hope you find this series useful!