What Is TTP in Cybersecurity?

rundll32.exe C:\Windows\System32\comsvcs.dll MiniDump 748 C:\Windows\Temp\l.dmp full

That one line answers three separate questions. Most writing about TTPs answers one of them and calls it three. The acronym gets used as a single word, as in "we track the actor's TTPs", which is fine as shorthand and useless the moment you sit down to write a rule. Tactic, technique and procedure sit at different resolutions, they change at different speeds, and they cost different amounts to detect.

We use one behaviour the whole way down: reading credentials out of LSASS process memory.

The tactic is the goal

Credential Access is TA0006 in MITRE ATT&CK. It is a bucket of 17 techniques in Enterprise v19, and the only thing all 17 share is intent. The adversary wants account names and passwords. Keylogging is in there. Brute force is in there. So is pulling hashes out of NTDS.dit.

A tactic has no telemetry. There is no field in any log that equals "wanted credentials". You cannot write a Sigma rule against TA0006, and if a vendor tells you their product covers Credential Access, they have told you nothing measurable. The tactic answers why, and its job is grouping and reporting, not detection.

The technique is the method

T1003 is OS Credential Dumping, with eight sub-techniques. T1003.001 is LSASS Memory, and that is the one we care about here.

The technique is where an invariant appears. Whatever the tooling, something has to open a handle to lsass.exe with rights sufficient to read its address space, and then walk that memory. On Windows that shows up in Sysmon Event ID 10 (ProcessAccess) with TargetImage ending in \lsass.exe and a GrantedAccess mask that includes read rights. The classic mask for a MiniDumpWriteDump caller is 0x1038, which is PROCESS_QUERY_LIMITED_INFORMATION, PROCESS_VM_OPERATION, PROCESS_VM_READ and PROCESS_VM_WRITE combined.

That invariant has held for over a decade. Techniques move at the speed of the operating system, not at the speed of tooling.

The procedure is this actor's implementation

Here is the same technique three ways. These are reconstructed command lines, not captures from an intrusion.

# Procedure A: signed Sysinternals binary, default name, on disk
procdump64.exe -accepteula -ma lsass.exe C:\Windows\Temp\l.dmp

# Procedure B: the same signed binary, renamed
dllhost.exe -accepteula -ma 748 C:\Windows\Temp\l.dmp

# Procedure C: no attacker binary at all
rundll32.exe C:\Windows\System32\comsvcs.dll MiniDump 748 C:\Windows\Temp\l.dmp full

Procedure A is the loudest. The image name is procdump64.exe, the file is signed by Microsoft, and the call stack passes through dbghelp.dll and dbgcore.dll on its way into LSASS.

Procedure B changes exactly one thing, the file name on disk. Sysmon still records OriginalFileName as procdump because that value comes out of the PE version resource, not the file system. So a rule keyed on Image|endswith: '\procdump64.exe' dies here and a rule keyed on OriginalFileName survives. That distinction is a procedure-level distinction. It has nothing to do with the technique, which is identical in both cases.

Procedure C drops the attacker binary entirely. comsvcs.dll ships with Windows and exports MiniDump at ordinal 24, so rundll32 does the dumping. The call needs SeDebugPrivilege, so in practice it runs from an already elevated or SYSTEM context. No new file lands on disk except the dump itself.

There is a procedure D that matters for what comes next. A loader that resolves nothing from the ntdll.dll export table and issues the NtOpenProcess syscall stub inline leaves a different artifact: the CallTrace field begins with UNKNOWN instead of a module name and offset, because the return addresses do not fall inside any loaded module.

What ATT&CK actually does with procedures

ATT&CK does not have a procedure layer. This gets misreported constantly, usually as a four-tier pyramid.

Procedures live in the Procedure Examples section on each technique and sub-technique page. In the STIX bundle each one is a relationship object with relationship_type: uses, pointing from an intrusion-set, malware, tool or campaign object to the attack-pattern object for the technique. There is no procedure SDO. Which means there is no procedure ID to map a rule to, and no procedure matrix to colour in. If your coverage tooling claims procedure-level ATT&CK mapping, it built that layer itself.

ATT&CK v18, released 28 October 2025, replaced the old free-text Detection field on each technique with two new object types, Detection Strategies and Analytics. v19, released 28 April 2026, carries 697 Detection Strategies and 1758 Analytics across 106 Data Components. v19 also split Defense Evasion into Stealth (TA0005) and Defense Impairment (TA0112), which is why the Sigma rule below now carries an attack.stealth tag.

Two rules, one behaviour

Here is a procedure-level rule from SigmaHQ. References trimmed for length, detection logic verbatim.

title: Process Memory Dump Via Comsvcs.DLL
id: 646ea171-dded-4578-8a4d-65e9822892e3
status: test
description: Detects a process memory dump via "comsvcs.dll" using rundll32, covering multiple different techniques (ordinal, minidump function, etc.)
author: Florian Roth (Nextron Systems), Modexp, Nasreddine Bencherchali (Nextron Systems), Swachchhanda Shrawan Poudel (Nextron Systems)
date: 2020-02-18
modified: 2025-02-23
tags:
    - attack.credential-access
    - attack.stealth
    - attack.t1036
    - attack.t1003.001
    - car.2013-05-009
logsource:
    category: process_creation
    product: windows
detection:
    selection_img:
        - Image|endswith: '\rundll32.exe'
        - OriginalFileName: 'RUNDLL32.EXE'
        - CommandLine|contains: 'rundll32'
    selection_cli_1:
        CommandLine|contains|all:
            - 'comsvcs'
            - 'full'
        CommandLine|contains:
            - '#-'
            - '#+'
            - '#24'
            - '24 '
            - 'MiniDump' # Matches MiniDump and MinidumpW
            - '#65560'
    selection_generic:
        CommandLine|contains|all:
            - '24'
            - 'comsvcs'
            - 'full'
        CommandLine|contains:
            - ' #'
            - ',#'
            - ', #'
            - '"#'
    condition: (selection_img and 1 of selection_cli_*) or selection_generic
falsepositives:
    - Unlikely
level: high

Look at how much of that rule is spent on one procedure. Three ways of writing the ordinal, the 16-bit wraparound at 65560, the named export in two spellings. It catches procedure C and nothing else. It does not catch procedure A, procedure B, Mimikatz, or anything that is not rundll32 plus comsvcs.dll. Its falsepositives: Unlikely is honest, because no legitimate administrative workflow calls MiniDump through comsvcs.dll. Level high follows from that.

Now the technique-level rule for the same behaviour.

title: Potential Credential Dumping Activity Via LSASS
id: 5ef9853e-4d0e-4a70-846f-a9ca37d876da
status: test
author: Samir Bousseaden, Michael Haag
date: 2019-04-03
modified: 2026-06-29
tags:
    - attack.credential-access
    - attack.t1003.001
    - attack.s0002
logsource:
    category: process_access
    product: windows
detection:
    selection:
        TargetImage|endswith: '\lsass.exe'
        GrantedAccess|contains:
            - '0x1038'
            - '0x1438'
            - '0x143a'
            - '0x1fffff' # Too many false positives
        CallTrace|contains:
            - 'dbgcore.dll'
            - 'dbghelp.dll'
            - 'kernel32.dll'
            - 'kernelbase.dll'
            - 'ntdll.dll'
    filter_main_system_user:
        SourceUser|contains: # Covers many language settings
            - 'AUTHORI'
            - 'AUTORI'
    filter_optional_thor:
        CallTrace|contains|all:
            - ':\Windows\Temp\asgard2-agent\'
            - '\thor\thor64.exe+'
            - '|UNKNOWN('
        GrantedAccess: '0x103800'
    filter_optional_sysmon:
        SourceImage|endswith:
            - ':\Windows\Sysmon64.exe'
            - ':\Windows\Sysmon64a.exe'
    condition: selection and not 1 of filter_main_* and not 1 of filter_optional_*
falsepositives:
    - Unknown
level: medium

This one has no procedure in it. No tool name, no command line, no file path for the attacker binary. It matches on the handle and the call stack, so procedure A, procedure B, Mimikatz and the Task Manager "Create dump file" option all land in the same selection.

Note what it costs. Level is medium and falsepositives is Unknown, which is the correct label for a rule this wide. The filter list is already carrying three exclusions, one of them for a specific EDR agent's own dumping path. That list only grows. The rule also needs Sysmon Event ID 10 with LSASS included, and plenty of deployments exclude LSASS from ProcessAccess to keep event volume down. Check that before you assume coverage.

Both rules share a blind spot, which is procedure D. If the call stack contains no frame attributable to ntdll.dll, kernel32.dll, kernelbase.dll, dbghelp.dll or dbgcore.dll, the selection never fires. That is what a separate rule, Potential Direct Syscall of NtOpenProcess, exists for. It keys on CallTrace|startswith: 'UNKNOWN' and is tagged attack.t1106 for Native API, not T1003.001, because it fires on the syscall pattern regardless of what is being opened.

The cost asymmetry

Procedure detections are cheap to write and cheap to run. The comsvcs rule is a string match on a command line, no state, no joins, and it produces close to zero false positives. It also went stale the day someone shipped a dumper that does not call rundll32. Procedure detections have short half-lives, and that is fine. Write a lot of them, expect to retire them, do not grieve.

Technique detections are expensive. They need richer telemetry, they carry filter lists that grow forever, they run at medium rather than high because the analyst has to look. In exchange, they survive the actor swapping tools. This is the trade every detection backlog is actually about, and it is why detection engineering is a portfolio problem rather than a rule-count problem.

The practical rule of thumb: never let a procedure detection be the only thing standing between you and a technique. Ship both, and know which is which. When someone hands you a report full of "TTPs", the first useful question is which level each line is written at, because that determines whether you are getting a rule that lasts a year or a rule that lasts a month.

Summary

A tactic is the goal and has no telemetry. A technique is the method and has an invariant you can query. A procedure is one actor's implementation and has an exact artifact you can string-match. ATT&CK models the first two as objects and the third as uses relationships on technique pages, so procedure IDs do not exist. Detect procedures because they are cheap, detect techniques because they last, and do not confuse the coverage you get from one with the coverage you get from the other.

Telemetry to have on before either rule is worth deploying:

Sysmon Event ID 1    process creation, with CommandLine and OriginalFileName populated
Sysmon Event ID 10   ProcessAccess, TargetImage + GrantedAccess + CallTrace + SourceUser
                     confirm lsass.exe is not excluded in your Sysmon config
Sysmon Event ID 11   file create, catches the .dmp artifact landing on disk
Security 4688        process creation with command line auditing enabled
                     no CallTrace and no GrantedAccess, so procedure level only

Rules covering both levels of this behaviour are in the catalog at /rules?q=lsass, and the wider Windows set is at /rules?domain=windows.