Detecting T1587 Develop capabilities

How T1587 Develop capabilities shows up before an intrusion

T1587 Develop capabilities covers the work an adversary does to build its own tools or certificates before an intrusion starts. Under the MITRE ATT&CK tactic TA0042, ATT&CK describes Resource Development as establishing resources the adversary can use to support operations, and T1587 is the in-house build step within it. The four sub-techniques are Malware, Code Signing Certificates, Digital Certificates and Exploits. Each leaves a different trace, and one campaign may use several of them. This page maps detections to Enterprise ATT&CK version 20.0, so confirm the sub-technique IDs and tactic assignments against that version before any rule is deployed.

Most T1587 activity happens on infrastructure the victim never sees, such as the attacker's build environment and certificate workflows. Your network usually observes only the results: a sample arriving, a signed binary executing, or an exploit reaching a vulnerable service. Detection therefore depends on indirect evidence, chiefly the data components ATT&CK links to these sub-techniques: Response Content (DC0104), Malware Content and Malware Metadata. Response Content typically comes from external sources such as sandbox reports and threat intelligence feeds, so the first question for your team is whether those outputs reach your SIEM at all. Confirm which of these data components your current tooling can actually ingest before promising coverage.

Decide early what evidence you will accept as a T1587 indicator. A sandbox verdict or hash match on a sample found in a phishing attachment or software download is a strong lead for Malware. For Code Signing Certificates and Digital Certificates, a signature from a certificate issued to an unfamiliar subject, or a certificate revoked after issuance, is worth investigating, but it does not establish intent on its own. Record these expectations in your detection plan for version 20.0, assign an owner to review external intelligence, and set the review cadence yourself so that intelligence is triaged before it goes stale.

Which telemetry reveals T1587 and which open-source tool collects it

This table maps each telemetry source ATT&CK links to T1587 Develop Capabilities onto the signal a defender looks for and the open-source tool that typically collects it. Read it as a starting point: coverage depends on what your team actually ingests, and the data component mapping should be confirmed in the STIX bundle for version 20.0 before you build rules on it.

Telemetry (data component)	Signal to look for	Open-source collector
Malware Content (sample bytes)	Sample file structure, embedded strings and packing traits that repeat across samples a team has ingested	Sample sandbox fed by a file ingest pipeline, with YARA rules run on the sample store
Malware Metadata (sample attributes)	Hashes, compile timestamps, import tables and section layout that match earlier samples from the same build chain	YARA and hash lookups in a sample repository, with results forwarded to Wazuh for alerting
Response Content (captured responses)	Reused build artifacts or staging files that appear in web or file responses an adversary's infrastructure returns	Zeek file and HTTP logs, with Suricata rules for known artifact patterns
Network Traffic Content (inbound and outbound payloads)	Payload fragments or certificate and banner details that match previously analyzed development artifacts	Suricata or Zeek, forwarded into Security Onion for hunting
Endpoint file activity (where the team collects it)	Newly introduced binaries on managed hosts that match a sample already in the malware store	Velociraptor hunts and Wazuh file integrity monitoring
Coverage check (your environment)	Whether each source above is ingested at all, and for how long it is retained	Confirm with your own log and sample pipeline owners before relying on any row

Detection ideas for T1587 that a SOC can build today

T1587 Develop Capabilities is largely invisible to the victim until a capability is used, so detection depends on the outside signals adversary tooling leaves behind. The ideas below connect malware metadata, response content and network patterns, and each one needs tuning against legitimate research and build activity before it is trusted.

Correlate new binaries with threat intelligence

Compare hashes of newly observed executables and documents against commercial and open threat intelligence sample feeds. The logic is simple: a binary that is new to your estate but already known to a feed suggests a capability that was developed and shared elsewhere. Tune the match window so that only binaries first seen in the last few days generate alerts, and set a minimum feed confidence before escalation. Expect false positives from security vendors, sandbox submissions and internal red team tooling, so maintain an allowlist of hashes that your own testing produced. Ask your feed provider which malware metadata fields are included, since matches on family names alone are weak.

Flag tooling families in external content

Watch for known tooling family names, panel strings or artifact names appearing in response content from external hosts that your organization has no business reason to contact, such as code repositories, paste sites or hosting pages. Match on a short list of families relevant to your sector and require at least two independent indicators before raising an alert. Common false positives include security researchers publishing analysis, threat hunting blogs and your own staff reviewing public reports, so route matches to an analyst queue rather than paging on-call staff.

Spot shared build metadata across samples

Group binaries by shared compile-time metadata such as build paths, compiler versions, timestamps that cluster in a narrow window, and embedded project names. A cluster of unrelated-looking samples that share the same build fingerprint can indicate a single developer or toolkit behind several campaigns. Set a minimum cluster size and a maximum time span before reporting. Legitimate software build pipelines, shared open-source libraries and internal developer machines produce the same fingerprints, so exclude known build servers and signed vendor packages from scoring.

Watch for repeated loader patterns

Write Zeek or Suricata rules that flag repeated custom loader behavior in network traffic, such as the same unusual request structure, header ordering, or beacon interval reappearing across unrelated hosts. Start with a baseline of normal application traffic for your environment and set a threshold on how many distinct hosts must show the pattern within a set period. Legitimate software updaters, monitoring agents and penetration testing traffic can match these signatures, so record the source of each match and suppress known internal testing ranges during scheduled exercises.

Track newly registered infrastructure

Where a capability depends on staging infrastructure, newly registered domains and certificates that resemble the naming of observed tooling can serve as an early pointer. Review domain registration and passive DNS data for recent registrations that match your sector keywords or brand terms, and set a window of recent days for high-priority review. Expect noise from marketing teams, new product launches and legitimate domain testing, so confirm ownership with the business before escalating. Ask your data provider how long their registration history is retained.

How to validate that a T1587 detection fires

This sequence shows how a team proves that its T1587 Develop Capabilities detections fire as intended, using a scoped emulation plan in a private cyber range with benign, pre-approved sample material. It produces a validation record that ties each step to an ATT&CK technique or sub-technique, the alerts expected, the alerts observed and the tuning changes that followed.

Define the scope and approvals
The detection owner, the threat intelligence lead and the cyber range operator agree in writing which T1587 sub-techniques are in scope, which systems and telemetry sources are involved, and who can stop the exercise. Legal or compliance reviewers confirm that the sample material is benign and approved for use in the range. The output is a signed scope note that names the ATT&CK version being tested, since techniques and sub-techniques can change between releases such as v18, v19 and v20. The exercise does not start until this note exists.
Map each step to ATT&CK identifiers
Build a table that links every planned activity to its technique and sub-technique IDs in the ATT&CK version named in the scope note, for example T1587 and its sub-technique IDs. Each row also lists the ATT&CK data components the detection is expected to read, such as Response Content, Malware Metadata or Malware Content, and the detection strategy or analytic ID the team is testing. The output is a traceability matrix that an assessor can follow without asking the team questions.
Write expected alerts before the run
For each row of the matrix, the team records what it expects to see before the exercise starts: which log source produces the event, which Sigma rule or Wazuh rule should match, which severity it should carry and which analyst queue receives it. Writing expectations first prevents the team from adjusting the definition of success after the run. The output is a signed expected-alert sheet. Any row without an expected source is flagged as a data source gap to resolve before testing.
Run the benign emulation plan
The emulation operator runs the pre-approved, benign sample steps in the isolated range in the order written in the matrix, without improvising new techniques. An observer records the start and end time of each step in a neutral timeline. The operator does not publish or share the sample material outside the range. The output is a timestamped run log that matches the matrix row by row, so each alert can later be paired with the activity that caused it.
Capture alert timing and fidelity
Once the run ends, the analyst exports the alerts from the SIEM, such as Wazuh or Security Onion, and compares each one with the expected-alert sheet. For each step the team records whether an alert fired, the alert time relative to the activity timestamp, the rule name and version, and any enrichment fields that were missing. Late or duplicate alerts are noted as separate findings. The output is a results table in which every row is marked as detected, partially detected, missed or not testable.
Record data source gaps
The team checks each missed or partial result against the telemetry chain: was the collector running, did the log reach the indexer, were the required fields parsed, and did the source actually capture the relevant data component. Where the source does not exist in the environment, the gap is logged as a coverage issue rather than a rule failure. The output is a gap register with an owner and a remediation note for each item, such as enabling a feed or adding a parser.
Tune rules and retest
Rule changes are made under version control, with each change tied to a specific result in the results table. The team records the previous rule version, the new version, the reason for the change and the approver. The changed rules are then rerun against the same benign steps to confirm the expected alert now fires and that no unrelated alerts were introduced. The output is a change log and a retest result that show the detection moved from the earlier state to the new one.
Close with a validation record
The validation record combines the scope note, the traceability matrix, the expected-alert sheet, the run log, the results table, the gap register and the change log into one package stored with the detection repository. The record names the ATT&CK version tested and states which sub-techniques remain untested. Auditors and internal reviewers can use it as evidence of testing, but the record reflects the team's own testing and is not a certification. The output is a dated, signed record that is reviewed again whenever ATT&CK or the rule set changes.

Why T1587 detections depend on upstream visibility

Most of the work behind T1587 Develop capabilities happens off your network. An adversary builds or modifies malware, tooling and exploits on infrastructure you do not own, so your leverage comes from what reaches your environment after a payload lands, plus the samples and intelligence you can ingest from outside. Plan the section of your detection program around three inputs: malware samples and metadata your team or your providers can obtain, threat intelligence shared through sector groups and vendors, and the endpoint, network and email telemetry in your SIEM that shows the capability in use. If any of these three is missing, the T1587 analytics you deploy will have blind spots that no tuning will close.

The limits are real and you should state them plainly to leadership. Malware content and metadata reach you only when a sample is collected, shared or recovered, which usually happens after an intrusion has started or after a campaign has been publicized. Sub-techniques that describe development activity, such as writing custom tooling or obtaining code signing material, may leave little or no trace inside your estate. Expect delays between a sample appearing in public feeds and its arrival in your pipeline, and expect some samples to be heavily modified before they reach you. Treat detections built on these inputs as indicators that a capability is present, not proof of when it was developed.

Before you rely on this coverage, confirm the following with your own team and providers: which malware analysis or sandbox sources feed your environment, how quickly sample metadata is ingested, whether hashes and file attributes are retained long enough to match historical activity, and which threat intelligence feeds you consume and under what terms. Check that endpoint and email telemetry capture executable creation, signing events and script execution with enough fidelity to correlate with a sample. Map each source to the ATT&CK version your rules target, since detection mappings change between releases. Document the gaps you accept, because auditors and red team exercises will ask about them.

Mitigations that reduce T1587 exposure

T1587 happens largely outside the defender's network, so the mitigation the ATT&CK knowledge base maps to it is Pre-compromise (M1056). The cards below turn that mitigation into checks the team can run, and pair it with controls inside the environment that limit what an adversary gains from preparation.

Monitor external signals about your tooling

Pre-compromise asks the defender to watch for adversary preparation before any intrusion. For T1587, that means reviewing public sources for your organization's names, product references, code repositories, and internal tool signatures that appear in outside collections. Confirm who owns this review, how often it runs, and where findings are logged. Treat a new public sample that matches an internal tool as a signal to rotate affected secrets and review related detections.

Track brand and domain lookalikes

Adversaries often build capabilities around a convincing brand, so lookalike domains and spoofed application names are a practical early indicator. Use open-source feeds and certificate transparency monitoring to flag registrations that mimic your domains, and confirm the team can take a takedown or block decision within its own change process. Record which lookalikes were found, when they were first seen, and what action was taken.

Control source code and secret exposure

Internal code, certificates and build artifacts that leak to public repositories give an adversary material to shape malware and tooling. Scan repositories you own for committed secrets and proprietary code, restrict who can publish to public locations, and confirm that leaked credentials are revoked through a documented process. Ask the engineering lead which repositories are public, which are mirrored, and who approves any external release.

Limit the value of stolen tooling

Capabilities an adversary builds from your environment are less useful when they cannot be reused. Confirm that internal tools use per-environment keys, short-lived tokens and mutual authentication where the platform supports them. Check that administrative tools are not exposed to the internet and that certificates can be rotated without a full outage. Verify these settings against your own platform documentation rather than assumptions.

Keep detections current with ATT&CK

Pre-compromise activity is hard to see directly, so detection depends on the signals that follow it. Map your Response Content, Malware Metadata and Malware Content collection to the ATT&CK version you target, currently v20, and review those mappings after each release because releases can rename, deprecate or revoke techniques. Assign an owner to check the release notes and record each mapping change.

How to triage and respond when a T1587 alert fires

When a T1587 Develop capabilities alert fires, the first decision is whether the artifact is a capability an adversary is building or something your own teams or a vendor placed in your environment. Start by confirming the sample or artifact itself: record its hash, file type, size, signing status and the telemetry source that raised it, and keep the original object unmodified. Then check whether it matches a known malware family or internal tooling. Compare the hashes and strings against your own software inventory, your red team's tool registry and the sample libraries your threat intelligence provider or open-source feeds expose. If the artifact matches a known family, the triage shifts from discovery to scoping. If it matches nothing and it is not explained by internal work, treat it as an unattributed capability until proven otherwise.

Next, scope the affected hosts. In Velociraptor, build a hunt described in words as a search across all endpoints for the same hash, the same file names, the same signing certificate or the same network destinations seen in the Malware Metadata or Response Content events. In Wazuh, run a query against the indexed file integrity and endpoint telemetry for the same indicators over a window that starts before the first alert. Preserve evidence before you contain anything: collect the sample, the hunt results and the relevant logs into a case folder with timestamps, and record who touched what. Decide on containment based on whether the artifact is executing, staged for use or only sitting on a build or staging system. Isolate hosts that run it, but do not wipe systems that may hold evidence needed by your incident responders. Finally, feed findings back. Record the result in your threat intelligence platform, tune the Wazuh rule or Sigma logic that fired (for example, narrowing a hash match that caught approved internal builds), and note the ATT&CK version your mapping targets, since MITRE ATT&CK updates can change technique definitions between releases.

How to rehearse T1587 detection in a private cyber range

A private cyber range for T1587 should be isolated from production and from the public internet, with instrumented endpoints that generate the telemetry the detection strategies depend on: process activity, file creation, network connections and DNS queries. The goal is to confirm that your Security Onion or Wazuh stack ingests, parses and retains that telemetry in a form analysts can search. Sample handling belongs in a sandbox that is separate from the endpoints, so that a detonated sample never reaches the monitored network.

Isolated network segment: Confirm egress is blocked by default and that any permitted outbound path is logged and documented before the exercise starts.
Instrumented endpoints: Verify that Wazuh agents or equivalent collectors are reporting on each endpoint type in scope, and record which fields are present.
Security Onion or Wazuh stack: Check that Suricata, Zeek and host alerts reach the analyst console within the time your runbook expects.
Sample sandbox: Keep detonation on a dedicated host with snapshots, so each run starts from a known state.
Baseline capture: Record a clean snapshot of logs and configuration so you can show later what changed.

Before the first run, ask your platform team to confirm the exact log sources, retention settings and time synchronization across the range.

Practitioner questions about detecting T1587 Develop capabilities

How do I tell T1587 Develop capabilities apart from T1588 Obtain capabilities?

T1587 covers capabilities the adversary builds itself, such as malware, tools and exploits they author or compile, while T1588 covers capabilities they acquire from someone else, such as purchased tools, leaked code or public exploits. The line can blur when an adversary modifies a public tool, so the practical test is provenance: if the artifact was made in-house or customized by the actor, map it to T1587; if it was obtained as-is from a third party, map it to T1588. Keep both mappings in your rule notes so analysts know which technique a finding supports. Confirm the current sub-technique definitions in the ATT&CK 20.0 entries before you write mappings, because wording can change between releases.

Which data sources matter most for detecting T1587?

Start with the data components ATT&CK links to this technique family: Response Content, Malware Metadata and Malware Content. In practice, the most useful inputs are the outputs of your own threat intelligence pipeline, such as sample hashes, file metadata, compiler artifacts and certificate details from submitted files, plus any sandbox reports you collect. Pair these with network telemetry (Zeek or Suricata logs for TLS certificates and HTTP content) so you can connect a newly seen artifact to infrastructure already in your environment. Check each data component against the detection strategy IDs for your target ATT&CK version, since v18 replaced detections with detection strategies and analytics.

How should I handle ingestion limits when I collect malware samples and metadata?

Treat sample ingestion as a tiered problem rather than trying to index everything at full fidelity. Keep hashes, file type, size, import and signature metadata for all observed samples, store full content only for files that match a prioritized threat profile, and set retention by tier. Use Wazuh or your SIEM's index lifecycle features to move older metadata to cheaper storage, and use Velociraptor or your EDR only for on-demand collection. Document the sampling rule in the detection record so an auditor or analyst can see why a given artifact was or was not retained. Confirm the storage, licensing and retention limits of each platform in your own environment, since they vary by deployment.

How do I version detection rules against ATT&CK 20.0?

Pin every rule to the ATT&CK version it was written for, and record the technique ID, sub-technique ID, data component and detection strategy ID in the rule metadata. Sigma rules support tags that map to ATT&CK, so keep those tags in version control alongside the rule logic. When a new release arrives, diff the technique and sub-technique list against your pinned version, because MITRE can rename, deprecate or revoke techniques. ATT&CK 20.0 is the version these pages target; the release notes for each version are published on the ATT&CK updates page, and your mapping review should start there. Assign an owner to the diff review so mappings do not drift silently.

How do I measure detection coverage for T1587 without overstating it?

Measure coverage as the share of your in-scope sub-techniques for which you have a tested analytic, a documented data source and a recorded replay result, rather than as a single percentage. Build a simple matrix with one row per sub-technique and columns for data available, rule status, last validation date and gaps. Validate each row in your cyber range by replaying a benign test artifact or simulated telemetry, then record whether the alert fired and how long it took to appear. Be explicit that a row marked covered means tested under stated conditions, not that every variant of the behavior is detected. Ask your internal reviewers to sign off on the matrix before it appears in any report.

How do I avoid false positives from internal research and red team tooling?

Most false positives in this area come from the security team's own work: sandboxes, malware analysis lab hosts, internal compilers and red team builds. Start by tagging these sources with an asset class and a known-good owner, then exclude them from production alerts by asset identifier, not by broad path or username patterns that an adversary could mimic. Route activity from the analysis network to a separate index so analysts can still review it. Keep a registry of approved internal tools with hashes and build metadata, and review exclusions on the same schedule as rule reviews. Test every exclusion in the cyber range to confirm it does not hide the behavior you intend to catch.

Which ATT&CK version and data components this page targets

This page maps T1587 Develop capabilities to Enterprise ATT&CK 20.0, using the STIX 2.1 bundle that MITRE publishes for that version in the attack-stix-data repository. Any detection logic, data component reference or mitigation mapping written against this technique should name that version explicitly, because a rule written for one release may reference IDs that have since changed. Before you adopt a mapping, open the enterprise-attack 20.0 bundle and confirm that T1587 and its four sub-techniques still carry the IDs and names this page uses. Record the bundle filename and the date you checked it in your detection repository so that an auditor or a peer can reproduce the review.

The most important change to understand is the one introduced in ATT&CK v18. That release replaced the detections that used to sit in technique pages with detection strategies (DET IDs) and analytics, updated data components (DC IDs) and deprecated some data sources. If your team still maps coverage at the data source level, rebuild that mapping at the data component level for this technique. The data components referenced most often for Resource Development techniques include Response Content (DC0104), Malware Content and Malware Metadata for the capability-focused sub-techniques. Check which of these your collection pipeline can actually produce, since a data component you cannot ingest does not give you coverage, however well it is documented.

Releases can rename, deprecate or revoke techniques, and ATT&CK v19 (April 2026) and v20 (October 2026) both changed the framework after v18. Review the ATT&CK updates page at each release, and read the tactic page for Resource Development (TA0042) to confirm the technique still sits under that tactic. Assign an owner to this review, set a recurring check that matches your change control cycle, and treat any renamed or revoked sub-technique as a backlog item for your detection rules, not a silent update. Confirm all of this in your own environment and with your tooling vendor, since the mapping that matters is the one your SIEM actually runs.

How DeployOpen builds T1587 detections and range scenarios

DeployOpen works on T1587 Develop Capabilities as a defined engagement inside your own environment, not as a generic tooling rollout. We agree what is covered, build the detections and range scenarios against a named ATT&CK version, and hand over the artifacts your team needs to run them.

How we scope

Confirm which T1587 sub-techniques and telemetry sources your environment can actually observe.
Name the ATT&CK version the detection mappings will target before any build work starts.
Agree the written scope, deliverables and timeline in writing, since most engagements are fixed-scope.

How we build

Implement detection logic for malware metadata and malware content telemetry in your open-source stack.
Map detections to the response content and detection strategy references of the agreed ATT&CK version.
Build private cyber range scenarios that replay T1587 activity against your own detections and alerting.

How we hand over

Document each detection with its data source, logic in plain words, known gaps and tuning notes.
Record range test results, including which detections fired, missed or produced noisy alerts.
Provide the pre-compromise mitigation mapping and runbooks your analysts use to respond to alerts.

How we support

Offer ongoing support and continuous testing as a retainer after the fixed-scope handover.
Review detection mappings when ATT&CK releases rename, deprecate or revoke techniques you depend on.
Ask your team to confirm the support scope and response expectations in writing before signing.

T1587 Develop capabilities