What Is Operational Threat Intelligence?

AnyDesk, Fleetdeck.io, Level.io, Mimikatz, Ngrok, Pulseway, Screenconnect, Splashtop, Tactical.RMM, Tailscale, TeamViewer and Teleport.sh. That is Table 1 of CISA advisory AA23-320A, the legitimate tooling attributed to Scattered Spider. Twelve strings you can paste into a SIEM in about a minute.

The list is the least valuable part of the advisory. The valuable part is the order everything happens in, and that is what operational threat intelligence is.

Operational intelligence answers three questions. Who is likely to come at us. How do they work. What will they probably do next. Its consumers are SOC leads, hunt teams and incident response, not the board. Its horizon is weeks to months, which is roughly how long a crew keeps a working playbook before something breaks and they change it.

Tactical gives you the string, operational gives you the sequence

Tactical intelligence is the artifact. PCMonitorSrv.exe running on a finance workstation. A registration domain shaped like targetsname-helpdesk[.]com. A hash. Useful, cheap to consume, and it expires the moment the operator rotates infrastructure.

Operational intelligence is the shape of the campaign. It tells you that the RMM binary lands after a help desk password reset and an MFA re-enrolment, and before anyone goes looking for VMware vCenter. That ordering is the whole point. If you know an actor touches identity three steps before they touch hypervisors, you know which detection to build in week one and which can wait for week six.

Strategic intelligence sits above both. Sector targeting, extortion economics, budget arguments. Different audience, and not what this post is about.

Where it actually comes from

Four inputs carry most of the weight, and they are not equally reliable.

Vendor and government reporting. AA23-320A was last revised on 29 July 2025 and carries the seals of the FBI, CISA, the RCMP, ASD's ACSC, the AFP, CCCS and NCSC-UK. Joint advisories are slow and conservative, which is a feature when you are deciding where to spend engineering weeks.

ISAC and sector sharing. FS-ISAC, Health-ISAC, MS-ISAC and the Aviation ISAC are members of the National Council of ISACs, formed in 2003. The value is victim-derived detail with sector context, often weeks ahead of anything public, and usually under TLP restrictions. Check your handling rules before a shared indicator ends up in a public rule repository.

Victim notification. Law enforcement or a hosting provider tells you that you are already in it. Highest confidence input available and the worst possible timing.

Dark web and criminal forum monitoring. Be honest about this one. Leak sites are marketing, not telemetry. After the ALPHV/BlackCat disruption its blog carried 27 victim logos with no files behind them. Babuk2 claimed a run of victims in 2025 that analysts traced back to data from earlier, unrelated breaches. Treat a leak post as a claim with an unknown denominator. Its real use is watching which sectors and access brokers are being traded, not counting victims.

The products it feeds

Three artifacts come out the other side. Threat actor profiles, a documented sequence plus the tooling at each step. Campaign tracking, the same profile updated as the crew changes technique. Prioritised technique lists, a profile converted into engineering work. Only the third is a deliverable a detection engineer can act on.

Worked example: one profile into a hunt plan

Take Scattered Spider (ATT&CK group G1015, also tracked as UNC3944, Octo Tempest, Oktapus and Muddled Libra). The documented sequence, from the advisory:

1. Reconnaissance. Gather identity information (T1589), read victim-owned sites for roles and contacts (T1594), call staff to elicit detail (T1598.004).

2. Initial access. Buy employee or contractor credentials on illicit markets such as Russia Market (T1597.002), or phone the help desk while impersonating a real employee (T1656).

3. MFA bypass. Push bombing (T1621) or a SIM swap (T1451).

4. Persistence. Register their own MFA token (T1556.006), forge web credentials (T1606), create new identities (T1136), install an RMM agent (T1219). Historically they added a federated identity provider to the SSO tenant with automatic account linking (T1484.002), which let them sign in as anyone even after passwords were rotated. The advisory notes this one is not a current TTP.

5. Discovery. SharePoint (T1213.002), credentials in files (T1552.001), private keys and code-signing certificates (T1552.004), vCenter and other remote systems (T1018), AWS Systems Manager Inventory used as a cloud dashboard (T1538).

6. Lateral movement. Existing cloud services (T1021.007) and EC2 instances they create themselves (T1578.002).

7. Collection and exfiltration. Code repositories (T1213.003), cloud storage (T1530), staged into one database first (T1074). They also read mailboxes to see whether you have noticed them yet (T1114).

8. Impact. Extortion, sometimes with DragonForce ransomware.

Note step seven. An actor who reads your incident mail should change how you run comms during a response, and no tactical feed will tell you that.

Ranking the backlog

Rank each step by three things: how early it sits in the sequence, whether you already hold the log, and roughly how many events per day it produces. Early plus cheap plus quiet wins.

1. MFA factor reset or deactivation followed by a successful authentication from a new network (T1556.006). Step four, identity logs you already pay for, a handful of events per day in most tenants.

2. A burst of denied pushes followed by a success (T1621). Same log source, same day of work.

3. An RMM binary executing on a host that has never run one (T1219). Step four, needs process creation telemetry and a baseline, noisier.

4. Domain trust modification (T1484.002). Near-zero volume and near-zero false positives, but a dormant TTP, so a cheap tripwire rather than a priority.

5. Cloud instance created by an identity that has never created one (T1578.002). Step six, and it needs CloudTrail work you may not have done.

Discovery of SharePoint and file shares sits at step five and produces enormous volume. That is a monthly hunt, not a rule.

Detection 1: reset then authenticate from somewhere new

SigmaHQ already ships okta_mfa_reset_or_deactivated, which fires on the single event. It will bury you, because your help desk resets factors legitimately all day. The sequence carries the signal. Pseudo-SQL against a normalised Okta system log:

WITH resets AS (
  SELECT target_user, published AS reset_at
  FROM okta_system_log
  WHERE event_type IN ('user.mfa.factor.reset_all',
                       'user.mfa.factor.deactivate',
                       'user.account.reset_password')
    AND published > now() - interval '30 days'
),
auths AS (
  SELECT actor_user, published AS auth_at, client_ip, asn
  FROM okta_system_log
  WHERE event_type = 'user.authentication.auth_via_mfa'
    AND outcome_result = 'SUCCESS'
    AND published > now() - interval '30 days'
)
SELECT r.target_user, r.reset_at, a.auth_at, a.client_ip, a.asn
FROM resets r
JOIN auths a
  ON a.actor_user = r.target_user
 AND a.auth_at BETWEEN r.reset_at AND r.reset_at + interval '60 minutes'
WHERE a.asn NOT IN (
  SELECT DISTINCT asn FROM auths
  WHERE actor_user = r.target_user AND auth_at < r.reset_at
)
ORDER BY r.reset_at DESC;

What it catches: an account whose second factor was cleared and then immediately used from a network that account has never authenticated from. What it misses: an operator who waits out the 60 minute window, one on a residential proxy inside your usual ASN set, and every SIM swap, because a SIM swap produces no reset event at all. On Entra ID the same logic runs over the audit activity User registered security info joined to sign-in logs, where resultType 50074 marks a required MFA challenge and 500121 an MFA prompt the user did not complete. Rules for this side of the sequence live under /rules?domain=identity.

Detection 2: the RMM agent

title: Remote monitoring and management tool execution on a user endpoint
id: 4b0f9c21-7d3e-4a58-9c62-1f8ad0e5b774
status: experimental
description: >
    Detects execution of commercial remote access tooling of the kind listed in
    CISA AA23-320A. Legitimate on IT-managed hosts, suspicious on a host with no
    prior RMM history.
references:
    - https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a
    - https://lolrmm.io/
author: HuntRule
date: 2026-07-31
tags:
    - attack.command-and-control
    - attack.t1219
logsource:
    category: process_creation
    product: windows
detection:
    selection_image:
        Image|endswith:
            - '\ScreenConnect.ClientService.exe'
            - '\ScreenConnect.WindowsClient.exe'
            - '\PCMonitorSrv.exe'
            - '\TeamViewer.exe'
            - '\TeamViewer_Service.exe'
            - '\AnyDesk.exe'
            - '\ngrok.exe'
    selection_original:
        OriginalFileName:
            - 'ScreenConnect.ClientService.exe'
            - 'PCMonitorSrv.exe'
            - 'TeamViewer.exe'
            - 'AnyDesk.exe'
            - 'ngrok.exe'
    condition: 1 of selection_*
falsepositives:
    - Sanctioned help desk tooling on IT-managed endpoints
    - Contractors and MSPs running their own RMM under contract
    - Users who installed TeamViewer or AnyDesk for personal remote access
level: medium

Two honest caveats. The Image|endswith list is a static snapshot and the advisory names tools this rule does not cover, so generate the full list from the LOLRMM project rather than typing it by hand. Renaming the binary defeats the image match, which is why the OriginalFileName selection is there, and that field only exists if you collect Sysmon Event ID 1. Windows Security 4688 does not carry it.

The rule is really a per-host novelty problem dressed as a signature, so it is only worth deploying alongside a baseline of which hosts legitimately run which agent. Related catalog rules are at /rules?q=remote+access+tool.

The failure mode

Operational intel that never lands in a detection backlog is a newsletter. The tell is easy to spot. Ask when an actor profile last produced a ticket with an owner and a due date. If the honest answer is a Slack thread, the function is producing reading material.

The fix is unglamorous. Every profile ends as records in the same backlog your detection engineering work already runs through:

DET-114  T1556.006  MFA factor reset followed by auth from unseen ASN
  source:    AA23-320A rev 2025-07-29, Scattered Spider profile, step 4
  logsource: Okta system log (held, 90d retention)
  status:    query written, backtested 30d, 6 hits, all help desk
  next:      exclude help desk actor IDs, then promote to alert
  owner:     detection-eng
  due:       2026-08-14

DET-115  T1219      RMM agent new to host
  source:    AA23-320A Table 1 + LOLRMM
  logsource: Sysmon EID 1 (held on 62% of fleet, gap: ~1400 laptops)
  status:    blocked on telemetry coverage
  owner:     platform
  due:       2026-09-01

The second record is the useful one. It says out loud that the detection cannot be built yet and names the reason. A backlog that only contains work you can do is not tracking your real coverage.

Techniques referenced

ATT&CK v17 renamed T1219 from Remote Access Software to Remote Access Tools and added sub-techniques including T1219.002 for remote desktop software. The advisory tables still carry the older title.

Summary

Operational threat intelligence is the campaign shape and the sequence, aimed at hunt teams and IR on a horizon of weeks to months. Tactical intel hands you an artifact that expires on infrastructure rotation. Operational intel tells you which artifact to detect first, which is a more durable answer. Its inputs run from joint government advisories down to leak sites that will lie about their own victim counts. Judge the function on one thing: whether last quarter's actor profiles turned into dated, owned records in a detection backlog.

Logs to collect before you attempt any of the above:
  Okta system log        user.mfa.factor.reset_all, user.mfa.factor.deactivate,
                         user.account.reset_password, user.mfa.okta_verify.deny_push,
                         system.push.send_factor_verify_push,
                         user.authentication.auth_via_mfa
  Entra ID audit         "User registered security info", "Update user"
  Entra ID sign-in       resultType 50074, 500121
  Windows endpoints      Sysmon EID 1 with OriginalFileName, 30d minimum
  AWS CloudTrail         RunInstances, ssm:* inventory calls
  Reference              https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a
                         https://lolrmm.io/