What Is Tactical Threat Intelligence? From Report to Rule

cmd.exe /c "netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=9999 connectaddress=<rfc1918 internal ip> connectport=8443 protocol=tcp"

That is tactical threat intelligence. It came out of CISA advisory AA23-144A, "People's Republic of China State-Sponsored Cyber Actor Living off the Land to Evade Detection", published 24 May 2023 and covering the activity cluster Microsoft calls Volt Typhoon. One command line, a named binary, an argument set, and a resulting registry path. From that you can build a detection today.

Tactical intel is the technical detail of how an adversary operates, at a resolution you can turn into a rule. Its consumers are SOC analysts, detection engineers and threat hunters. Its time horizon is hours to weeks.

## Where it sits against operational and strategic

The three-tier model is about zoom.

Operational intel is campaign-level. Which actor is working your sector right now, what they go after first, how a typical intrusion sequences. It lands with SOC leads, IR planners and hunt teams setting priorities for the next quarter. Strategic intel is board-level: risk exposure, sector trends, where the security budget goes over the next year or two. Both have their own articles.

Tactical is the bottom tier and the only one you consume with a rule editor open. A strategic brief tells you ransomware operators increasingly abuse remote monitoring tooling. Tactical intel tells you the process name, the parent, and the flags.

## What qualifies

Tactical intel is anything specific enough that a query can express it:

- Command lines and their argument patterns, including abbreviations (`netsh i p a v` is the same command as above).
- File paths and staging directories: `C:\Windows\Temp\McAfee_Logs`, `C:\users\public\Appfile`.
- Registry keys and values: `HKLM\SYSTEM\CurrentControlSet\Services\PortProxy\v4tov4\tcp\`.
- Service names, scheduled task names, mutexes, named pipes.
- Protocol behaviour: callback ports, beacon intervals, user agent strings, JA3 hashes.
- Tooling and its configuration. AA23-144A names Earthworm and a custom Fast Reverse Proxy client with hardcoded C2 callbacks to ports 8080, 8443, 8043, 8000 and 10443, dropped under filenames including `cisco_up.exe`, `cl64.exe`, `vm3dservice.exe`, `watchdogd.exe`, `Win.exe`, `WmiPreSV.exe` and `WmiPrvSE.exe`.

That last set is worth pausing on. `WmiPrvSE.exe` is a real Windows binary. The intel value is not the name, it is the name in the wrong directory, which is a query you can write.

## What does not qualify, despite being sold as tactical

A bare IOC list is data, not intelligence. A CSV of 400 IP addresses with a column header of `malicious` tells you nothing you can act on beyond a blocklist push, and it tells your analyst nothing at all when one of them hits at 04:00. Was that IP a C2 server, a staging host, a scanner, or a compromised router used as a redirector for a different victim in the same city? Each answer produces a different response.

Intelligence starts where somebody states what behaviour the artifact evidences. `8443` is data. "The custom FRP client calls back to 8443, and the portproxy rules the actor creates forward to that same port" is intelligence, because it tells you what to look for on the host rather than at the perimeter.

## The workflow, run once end to end

Take AA23-144A from report to deployed rule.

### 1. Extract the behaviour, not the artifact

The advisory gives two portproxy command lines. The artifact is `listenport=9999`. The behaviour is a host being turned into a relay so traffic from a segment that cannot reach the internet gets to somewhere that can. That maps to T1090 Proxy, and specifically to T1090.001 Internal Proxy when the forward target is internal.

Write the behaviour down before you write anything else. Port 9999 will change. The need for a relay will not, because it is a consequence of the network layout, not a preference.

CISA's own note is the useful part: port proxies are rare in legitimate administration, because they are a firewall bypass by design.

### 2. Check whether your telemetry can see it

This step gets skipped and it is the one that silently kills rules. Netsh portproxy leaves two independent traces.

The process creation event, which needs command line capture. The advisory says so directly: set the audit policy to include `audit process creation` plus `include command line in process creation events`, which produces Security Event ID 4688 with the command line populated. Enabling the audit subcategory alone gives you the event with an empty command line field, and a command line rule against it matches nothing forever. Sysmon Event ID 1 gives you the same data with `OriginalFileName` as a bonus, which survives a rename of `netsh.exe`.

The registry entry. Each portproxy add writes under `HKLM\SYSTEM\CurrentControlSet\Services\PortProxy\v4tov4\tcp\`, which surfaces as Sysmon Event ID 13. Most stock Sysmon configs do not include that path, so confirm yours does before assuming coverage.

Two sources, and the registry one is the survivor. It persists across reboots, long after the process event has aged out of your hot index.

### 3. Take the rule that already exists

SigmaHQ ships this one. It is `proc_creation_win_netsh_port_forwarding.yml`, id `322ed9ec-fcab-4f67-9a34-e7c6aef43614`, authored 2019-01-29 and last modified 2023-09-01, which is four years before the advisory in one direction and after it in the other.

```yaml
title: New Port Forwarding Rule Added Via Netsh.EXE
id: 322ed9ec-fcab-4f67-9a34-e7c6aef43614
status: test
description: Detects the execution of netsh commands that configure a new port forwarding (PortProxy) rule
author: Florian Roth (Nextron Systems), omkar72, oscd.community, Swachchhanda Shrawan Poudel
date: 2019-01-29
modified: 2023-09-01
tags:
    - attack.lateral-movement
    - attack.command-and-control
    - attack.t1090
logsource:
    category: process_creation
    product: windows
detection:
    selection_img:
        - Image|endswith: '\netsh.exe'
        - OriginalFileName: 'netsh.exe'
    selection_cli_1:
        CommandLine|contains|all:
            - 'interface'
            - 'portproxy'
            - 'add'
            - 'v4tov4'
    selection_cli_2:
        CommandLine|contains|all:
            - 'i '
            - 'p '
            - 'a '
            - 'v '
    selection_cli_3:
        CommandLine|contains|all:
            - 'connectp'
            - 'listena'
            - 'c='
    condition: selection_img and 1 of selection_cli_*
falsepositives:
    - Legitimate administration activity
    - WSL2 network bridge PowerShell script used for WSL/Kubernetes/Docker
level: medium

What it catches: the full command from the advisory via selection_cli_1, the abbreviated form via selection_cli_2, and the partially abbreviated middle ground via selection_cli_3.

What it misses, and where it over-matches. selection_cli_2 is four single letters followed by a space, matched as substrings anywhere in the command line. Any netsh invocation whose arguments happen to contain those four sequences will match, and plenty of unrelated netsh usage does. On a host with heavy scripted network configuration this is your noise source, not the WSL2 bridge in the false positives list. It also misses portproxy created without netsh, because the underlying operation is a registry write and nothing forces you to go through the CLI.

So we pair it with a registry rule rather than replacing it.

title: PortProxy Registry Entry Created
id: 6c2e5a9f-0b48-4f3d-9c11-8a4b7e2d5f10
status: experimental
description: Detects a value written under the PortProxy v4tov4 TCP key, which is the persistent artifact of a host-based port relay regardless of whether netsh was used.
references:
    - https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-144a
    - https://attack.mitre.org/techniques/T1090/001/
author: huntrule.com
date: 2026-07-31
tags:
    - attack.command-and-control
    - attack.t1090.001
logsource:
    category: registry_set
    product: windows
detection:
    selection:
        TargetObject|contains: '\Services\PortProxy\v4tov4\tcp\'
    condition: selection
falsepositives:
    - WSL, Docker and Kubernetes tooling that publishes container ports on the host
    - Documented jump host or lab configuration
level: medium

Blind spot on this one: it depends entirely on your Sysmon config including that registry path. Check first, deploy second.

4. Validate before you call it deployed

Atomic Red Team has a test under T1090.001 that adds a portproxy entry with netsh and cleans it up afterwards. Run it, confirm both rules fire, then check the host state directly:

netsh interface portproxy show all
reg query HKLM\SYSTEM\CurrentControlSet\Services\PortProxy\v4tov4\tcp
netsh interface portproxy delete v4tov4 listenport=9999 listenaddress=0.0.0.0

A rule you have not fired once is a hypothesis. We have not tested either rule on Server 2012 R2, where netsh output formatting differs.

Shelf life

Tactical intel decays, and it decays at different rates by artifact type. IP addresses and domains go stale in days to weeks. Hashes die the moment the sample is recompiled. Command line patterns and registry paths last years, which is why a rule written in January 2019 still catches an advisory published in May 2023.

The practical consequence: if the tactical feed you pay for is mostly network indicators, you are buying the fastest-rotting layer. Treat it as enrichment for alerts you already have rather than as detection content.

Intel that does not name its data source is not actionable

The final test. A tactical report that says an actor "uses port forwarding for lateral movement" and stops has told you nothing you can implement, because it never says where the evidence lands. AA23-144A passes the test in its logging recommendations section: it names Event ID 4688, names the two audit settings required to make it useful, and states that WMI tracing and deep PowerShell logging are off by default.

When you read tactical intel, look for the sentence that names the log source. If it is absent, the report is describing behaviour rather than delivering intelligence, and the gap is yours to close.

ATT&CK techniques in AA23-144A referenced here

Summary

Tactical threat intelligence is the technical detail of adversary operation at rule-writing resolution: command lines, paths, registry keys, service names, protocol behaviour and tool configuration. Its consumers are SOC analysts and detection engineers, and its horizon is hours to weeks. A list of indicators with no stated behaviour behind them is data, not intelligence, and network indicators are the fastest-decaying kind. The workflow that makes it pay is fixed: extract the behaviour rather than the artifact, verify your telemetry actually carries it, write or adopt the rule, then fire it once to prove it works. If the report never names its data source, it is not yet actionable, whatever the vendor calls it.

Our Windows coverage is at /rules?domain=windows, and the proxy and tunnelling set is at /rules?q=portproxy. If step three of that workflow is where your team stalls, /blog/what-is-detection-engineering covers the pipeline around it.

# collect before you deploy either rule
Security 4688   process creation, requires "include command line in process creation events"
Sysmon 1        process creation, provides OriginalFileName
Sysmon 13       registry value set, requires PortProxy path in the Sysmon config

# host-side check
HKLM\SYSTEM\CurrentControlSet\Services\PortProxy\v4tov4\tcp\
netsh interface portproxy show all