Detect Vulnerability Broker Targeting: CTI-Flagged Marketplace Listings for In-Inventory Products Correlated With Follow-On Probing in Elastic Security
Obtain Capabilities: Vulnerabilities covers an adversary acquiring information about a weakness — rather than discovering it themselves (Vulnerability Discovery) or building a working exploit outright (Obtain Capabilities: Exploits) — by searching open CVE/vendor bulletins or, at the higher-confidence end, paying for access to closed vulnerability databases and dark-web exploit-broker forums. That acquisition happens entirely on adversary-controlled infrastructure, so it is invisible to any log the victim organization owns; the only lever a defender has is a CTI subscription that itself monitors those same closed marketplaces and forums for listings mentioning the organization's specific vendor/product stack. This detection ingests such a feed into a custom table, cross-references every listing against the organization's own CMDB-derived asset inventory so only products actually deployed in the environment survive (a listing for a product you don't run is noise, not a lead), and then looks for a second, victim-side corroborating signal: a perimeter WAF/IDS/IPS hit tagged with the same CVE arriving within days of the broker listing. A listing alone is a leading indicator that your stack has become a target for vulnerability acquisition and should drive proactive patch prioritization before a CVE ID or public PoC even exists; a listing followed by a matching probe is materially higher confidence that the acquired vulnerability information has already been turned into reconnaissance or exploitation against you specifically, rather than a broad opportunistic scan.
MITRE ATT&CK
- Tactic
- Resource Development
Elastic Detection Query
sequence by vendor.name, product.name, vulnerability.id with maxspan=7d
[ any where event.dataset == "vuln_broker_intel.listing" and
listing.type in ("sale", "auction", "request", "discussion") ]
[ any where event.dataset == "waf.alert" and network.direction == "inbound" ]Elastic EQL sequence correlating a custom-ingested vulnerability broker/marketplace listing event (event.dataset vuln_broker_intel.listing, populated by a CTI vendor feed) with a subsequent inbound WAF/IDS alert (event.dataset waf.alert) sharing the same vendor.name/product.name/vulnerability.id within 7 days. The asset-inventory restriction is applied upstream by only ingesting vuln_broker_intel.listing events for vendor/product pairs already present in the CMDB export, since EQL sequences do not support an inline reference-set join.
Data Sources
Required Tables
False Positives & Tuning
- Broker listing ingestion not pre-filtered to in-inventory vendor/product pairs, surfacing matches for products the organization does not run
- WAF signature reuse across related CVEs producing a coincidental vulnerability.id match
Other platforms for THREAT-Capability-VulnBrokerTargetedAcquisition
Testing Methodology
Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Simulate a Vulnerability Broker Listing for an In-Inventory Product
Expected signal: A VulnBrokerIntel_CL row for VendorName_s=AtomicVendor, ProductName_s=AtomicGateway, ListingType_s=sale, and a matching AssetInventory_CL row for the same vendor/product.
- Test 2Simulate a Corroborating Perimeter Probe for the Same CVE
Expected signal: A CommonSecurityLog row for DeviceCustomString1=CVE-0000-00000 from SourceIP=198.51.100.23 against DestinationHostName=atomic-gateway-01.
- Test 3Combined Chain: Broker Listing Followed by Corroborating Probe Within the 7-Day Window
Expected signal: A VulnBrokerIntel_CL listing, a matching AssetInventory_CL row, and a CommonSecurityLog probe, all referencing VendorName_s=AtomicVendor, ProductName_s=AtomicGateway, CVE_s=CVE-0000-00000 within the same 7-day window.
Response Playbook
Triage
- Pull the raw broker/marketplace listing text (title, forum, price/ask, timestamp) from the CTI vendor's evidence bundle and confirm the referenced vendor/product genuinely matches something in your environment version-for-version, not just a name collision.
- Check whether a CVE ID is attached to the listing; if not, treat it as pre-disclosure/private vulnerability information and prioritize by product criticality and exposure rather than CVSS, since none may exist yet.
- Query internal patch/vulnerability management data for the affected product's current patch level and internet-facing exposure to gauge real risk before the vulnerability is even public.
- If ProbeConfirmed=true, pull the corroborating WAF/IDS/IPS log entries — source IP, request payload, target host — to determine whether an actual exploitation attempt, not just a scan, has already occurred.
- Check the CTI vendor's confidence score and, where possible, cross-reference the same listing against a second independent CTI source; single-source broker chatter has a materially higher false-positive rate than a confirmed transaction.
- Determine whether the flagged vendor/product combination has appeared in prior broker-mention alerts, which would indicate sustained adversary interest in your stack rather than a one-off mention.
Containment
- If a specific unpatched product/version is identified, apply available compensating controls immediately — a WAF virtual-patch rule, network segmentation, or disabling the vulnerable feature/service — without waiting for an official vendor patch.
- If ProbeConfirmed=true, block or rate-limit the corroborating source IP(s) at the perimeter and open an incident for the targeted host(s) as if exploitation may have already succeeded.
- Where the affected product is internet-facing and no compensating control is available, consider temporarily restricting access to trusted source ranges until a patch or virtual patch is in place.
Evidence Collection
- Preserve the full CTI vendor evidence package for the listing — screenshots, forum post ID/URL, seller handle, and timestamp — since broker forum posts are frequently edited or taken down within days.
- Collect WAF/IPS/firewall logs for the affected host(s) covering the full lookback window, not just the flagged event, to establish whether earlier reconnaissance preceded the broker listing.
- Export the CMDB/asset inventory snapshot used for the match so the exact scope of affected deployments at alert time is preserved for the incident record.
Escalation Criteria
- !ProbeConfirmed=true — external activity referencing the same CVE has already been observed against your organization's own infrastructure.
- !The affected product is internet-facing, unpatched, and present in significant volume across the asset inventory.
- !The CTI vendor's confidence score is high and/or a second independent CTI source corroborates the same listing.
- !The same vendor/product combination has triggered multiple prior broker-mention alerts, indicating sustained rather than opportunistic adversary interest.
Investigation Guide
Related Techniques
Forensic Artifacts
- >
CTI vendor evidence bundle: forum post ID/URL, seller handle, listing price/timestamp, and any screenshots. - >
Perimeter WAF/IDS/IPS logs carrying the corroborating CVE signature hit. - >
Internal vulnerability management / patch management records for the affected product. - >
CMDB/asset inventory export showing the scope of the affected product's deployment at alert time.
Tuning Guidance
This detection is only as good as the CTI subscription behind VulnBrokerIntel_CL — it requires a vendor that actively monitors closed vulnerability databases and dark-web exploit marketplaces and tags listings with a normalized vendor/product taxonomy; without that ingestion pipeline the table simply stays empty and this detection never fires. Keep AssetInventory_CL synchronized with the actual CMDB on at least a weekly cadence, since a stale export either hides a real match (product added since the last export) or manufactures one (decommissioned product still listed). Push back on the CTI vendor for a well-calibrated ConfidenceScore_d — early-stage feeds without confidence scoring will surface a high volume of low-value forum chatter and should be run at a stricter ListingType_s filter (sale/auction only, excluding discussion) until the feed matures. Treat ProbeConfirmed=true results as the highest priority regardless of ConfidenceScore_d, since a real perimeter hit against the same CVE outweighs marketplace-listing uncertainty; ProbeConfirmed=false results are proactive patch-priority leads and should feed the vulnerability management backlog rather than paging on-call.
Hunting Queries
Surfaces vendor/product pairs with three or more independent broker mentions over 90 days that have not yet produced a corroborating perimeter probe — sustained marketplace interest in a specific product is itself a patch-priority signal even before any exploitation attempt is observed.
// Hunt: vendor/product pairs with repeated, sustained broker mentions but no probe corroboration yet — proactive
// patch-priority candidates before any network activity is observed
VulnBrokerIntel_CL
| where TimeGenerated > ago(90d)
| summarize MentionCount = count(), FirstMention = min(TimeGenerated), LastMention = max(TimeGenerated),
Forums = make_set(ForumName_s) by VendorName_s, ProductName_s
| where MentionCount >= 3
| order by MentionCount descindex=vuln_broker_intel sourcetype="vuln_broker_intel" earliest=-90d
| stats count as mention_count, min(_time) as first_mention, max(_time) as last_mention, values(forum_name) as forums by vendor_name, product_name
| where mention_count >= 3
| sort - mention_countFinds CVE signature hits at the perimeter that never appeared in the broker/marketplace feed at all, indicating either an opportunistic actor who did not need to acquire the vulnerability from a broker, or a blind spot in the CTI subscription's marketplace coverage that should be raised with the vendor.
// Hunt: CVE signature hits with no corresponding broker-feed mention — a coverage-gap check for the CTI
// subscription itself, since a probe with no acquisition-side signal means the feed missed the acquisition
let SeenCVEs = VulnBrokerIntel_CL
| where TimeGenerated > ago(90d)
| distinct CVE_s;
CommonSecurityLog
| where TimeGenerated > ago(30d)
| where isnotempty(DeviceCustomString1)
| where DeviceCustomString1 !in (SeenCVEs)
| summarize Hits = count(), SourceIPs = make_set(SourceIP) by CVE_s = DeviceCustomString1, DestinationHostName
| order by Hits descindex=waf sourcetype="cef" earliest=-30d
| where isnotnull(device_custom_string1)
| search NOT [ search index=vuln_broker_intel sourcetype="vuln_broker_intel" earliest=-90d | fields cve | rename cve as device_custom_string1 | dedup device_custom_string1 ]
| stats count as hits, values(source_ip) as source_ips by device_custom_string1, dest_host
| sort - hitsAtomic Red Team Tests
Inserts a synthetic row into VulnBrokerIntel_CL representing a marketplace listing for a test vendor/product, and a matching row into AssetInventory_CL so the listing survives the inventory join, simulating a CTI feed flagging that the organization's own stack has become a vulnerability-acquisition target.
Command
# POST synthetic events to the ingestion API for VulnBrokerIntel_CL and AssetInventory_CL:
curl -s -o /dev/null -X POST "$INGESTION_ENDPOINT/VulnBrokerIntel_CL" -H 'Content-Type: application/json' -d '{"VendorName_s":"AtomicVendor","ProductName_s":"AtomicGateway","CVE_s":"CVE-0000-00000","ForumName_s":"atomic-test-forum","ListingType_s":"sale","ConfidenceScore_d":85,"TimeGenerated":"'"$(date -u +%Y-%m-%dT%H:%M:%SZ)"'"}'
curl -s -o /dev/null -X POST "$INGESTION_ENDPOINT/AssetInventory_CL" -H 'Content-Type: application/json' -d '{"VendorName_s":"AtomicVendor","ProductName_s":"AtomicGateway","TimeGenerated":"'"$(date -u +%Y-%m-%dT%H:%M:%SZ)"'"}'Cleanup
Delete or expire the injected test rows from VulnBrokerIntel_CL and AssetInventory_CL per your table's retention/purge process.Expected Telemetry
A VulnBrokerIntel_CL row for VendorName_s=AtomicVendor, ProductName_s=AtomicGateway, ListingType_s=sale, and a matching AssetInventory_CL row for the same vendor/product.
Expected Detection
The KQL/SPL inventory join surfaces the listing with ProbeConfirmed=false, since no corroborating perimeter probe has been injected yet.
Inserts a synthetic CommonSecurityLog-style CEF event carrying the same test CVE in DeviceCustomString1, simulating a WAF/IDS signature hit that corroborates the broker listing from the prior test.
Command
# POST a synthetic CEF event to CommonSecurityLog for the same test CVE:
curl -s -o /dev/null -X POST "$INGESTION_ENDPOINT/CommonSecurityLog" -H 'Content-Type: application/json' -d '{"DeviceCustomString1":"CVE-0000-00000","SourceIP":"198.51.100.23","DestinationHostName":"atomic-gateway-01","TimeGenerated":"'"$(date -u +%Y-%m-%dT%H:%M:%SZ)"'"}'Cleanup
Delete or expire the injected test row from CommonSecurityLog per your table's retention/purge process.Expected Telemetry
A CommonSecurityLog row for DeviceCustomString1=CVE-0000-00000 from SourceIP=198.51.100.23 against DestinationHostName=atomic-gateway-01.
Expected Detection
In isolation this row alone is not actionable; combined with the prior test it flips ProbeConfirmed to true for CVE-0000-00000.
Runs both prior atomic tests in sequence for the same test vendor/product/CVE within a few minutes of each other, reproducing the full acquisition-then-targeting chain that this detection's probe-correlation logic is designed to surface at highest confidence.
Command
# Run the two prior atomic tests in sequence (broker listing + inventory match, then perimeter probe) for the
# same VendorName_s/ProductName_s/CVE_s value within a few minutes of each other.Cleanup
Delete or expire all three injected test rows from VulnBrokerIntel_CL, AssetInventory_CL, and CommonSecurityLog.Expected Telemetry
A VulnBrokerIntel_CL listing, a matching AssetInventory_CL row, and a CommonSecurityLog probe, all referencing VendorName_s=AtomicVendor, ProductName_s=AtomicGateway, CVE_s=CVE-0000-00000 within the same 7-day window.
Expected Detection
The KQL/SPL correlation groups all three by vendor/product/CVE and sets ProbeConfirmed=true — the highest-confidence output tier, indicating the acquired vulnerability information has already been operationalized against this organization.