Part of SOCSimulator

SOCSimulator Research

SOCSimulator Research is the detection-engineering practice behind the platform. It studies how real attacks show up in security telemetry, builds and tests the detections that catch them, and turns that work into the technique pages, examples, and scenarios analysts train on. This page explains how that work is done.

What SOCSimulator Research does

SOCSimulator Research sits between threat research and hands-on training. Its work is to understand how an attack behaves, how that behavior surfaces across SIEM, endpoint, and network data, and which signals reliably separate an intrusion from ordinary activity. That understanding is then written down as reference material: what a technique looks like in real telemetry, which queries surface it, how a representative alert reads, and where the activity sits in a wider attack. The output is not marketing copy. It is meant to be correct enough that a working analyst can act on it.

How the work is done

Every page follows the same path from research to publication. It is closer to a lab notebook than to a content calendar.

1. 1

   Investigate

   We start from how an attack actually behaves, not from whatever currently ranks for the keyword. That means reconstructing the technique from primary research: what the attacker does step by step, which artifacts the activity leaves behind, and where those artifacts appear in logs and endpoint data.

2. 2

   Verify

   A detection is only worth publishing if it holds up. We test queries against representative telemetry, confirm they separate real activity from benign noise, and put every claim through an adversarial review whose only job is to break it. Anything that reads as filler, or that cannot be substantiated, is cut before the page moves forward.

3. 3

   Translate

   The final step is turning verified detection work into something a learning analyst can use: a plain explanation, a labeled example, a query they can read line by line, and a scenario they can practice on a realistic console.

Our standards

A few rules hold across everything published under this name.

• Grounded in primary research. Every technical claim traces back to how the attack actually works, drawn from a broad body of threat intelligence and official documentation rather than from restating another page.
• Verified before it ships. Detections are tested and reviewed. A page that would only repeat what is already available does not get published. It is folded into a parent page or dropped.
• Simulated data, clearly labeled. Example alerts and logs are generated to be realistic and are never taken from a real environment. Each one carries the label 'Simulated example generated by SOCSimulator Research,' so an analyst always knows exactly what they are looking at.
• Kept current. Techniques get renumbered, log schemas change, and figures move. Pages show the date they were last reviewed when a review has been recorded, and are revised when the underlying research changes, rather than left to drift.

Authorship and review

Reference pages carry the organizational byline SOCSimulator Research rather than a single person's name, because they are maintained as a continuously updated body of work instead of one author's article. When a named specialist has reviewed a page, that review is credited to them by name. Editorial writing, such as the blog and long-form guides, carries individual bylines. We do not attach a person's name to work they did not review.

See the work

The clearest picture of this practice is the library itself. Browse the MITRE ATT&CK technique pages, the cybersecurity glossary, the investigation playbooks, or the blog.

Frequently Asked Questions

Who produces the content on SOCSimulator?

Reference pages are produced by SOCSimulator Research, the platform's detection-engineering practice. Each page is grounded in primary research, verified, and reviewed before it is published. Editorial pieces on the blog carry individual author bylines.

Are the alerts and log samples on these pages real?

They are realistic but simulated, and every one is labeled as such. We generate them so we can show a clean, safe example without exposing any real environment's data.

How do I know a page is current?

Pages show the date they were last reviewed when a review has been recorded, and they are revised when the underlying research changes. Nothing is left to quietly drift out of date.