Using frameworks in detection and threat hunting

From framework to practice

Knowing ATT&CK IDs does not stop attacks. What helps is using the framework to answer practical questions: Which techniques matter most for us? Which of them can we detect today? Where are the gaps? Did our new rule really work?

Detection engineering

Detection engineering is the work of designing, testing and maintaining detection rules. A typical cycle:

1. Choose a technique to cover, based on threat intelligence (for example T1059.001 PowerShell, used by groups targeting your sector).
2. Check data: do we collect the logs needed (Sysmon process creation, PowerShell script block logging)?
3. Write the rule, and tag it with the ATT&CK technique.
4. Test it safely, ideally by simulating the behaviour in a lab or approved test.
5. Tune false positives, document the response steps, and deploy.
6. Review regularly: is it still firing correctly?

Sigma: rules you can share

Sigma is an open, generic format for detection rules written in YAML. A Sigma rule can be converted into the query language of many SIEMs (Splunk SPL, Sentinel KQL, Elastic and others). Here is a rule for the Office-spawns-PowerShell pattern:

title: Office Application Spawning PowerShell
status: experimental
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    ParentImage|endswith:
      - '\winword.exe'
      - '\excel.exe'
    Image|endswith: '\powershell.exe'
  condition: selection
level: high
tags:
  - attack.execution
  - attack.t1059.001

Measuring coverage

Coverage means: of the techniques we care about, how many do we have a working detection for? Teams often show this as a heat map on the ATT&CK matrix (MITRE's free ATT&CK Navigator tool can draw one). Coverage is a guide, not a score to game: one weak rule does not mean a technique is truly covered.

priority = {"T1566.001", "T1059.001", "T1053.005", "T1003", "T1021.001", "T1486", "T1490"}
rules = {"Office spawns PowerShell": "T1059.001", "Shadow copy deletion": "T1490", "New scheduled task": "T1053.005"}
covered = priority & set(rules.values())
print(f"{len(covered)}/{len(priority)} covered:", sorted(covered))
print("Gaps:", sorted(priority - covered))

Threat hunting

Threat hunting is proactively searching for attackers that existing rules have missed, instead of waiting for alerts. A good hunt starts with a hypothesis based on intelligence and ATT&CK, for example: "If an attacker used valid accounts with RDP for lateral movement (T1078, T1021.001), we will see logon type 10 events between workstations, which our staff never do." The hunter queries the SIEM, investigates anything odd, and turns useful queries into new detection rules.

Purple teaming

In a purple-team exercise, attackers (red team) and defenders (blue team) work together. With written approval and a clear scope, the red team safely performs a technique in the company's own environment, and the blue team checks whether the logs and alerts appear. Gaps are fixed on the spot. Open-source test libraries exist for this, but they must only be run in approved test environments.

Common mistakes

• Colouring the ATT&CK matrix green without testing that rules fire.
• Writing rules for data you do not collect.
• Hunting with no hypothesis, just browsing logs.
• Running attack simulations on production systems without approval.