What acquire access means for your SOC and where it shows up
Threat intelligence reports often describe access to compromised networks being offered for sale, and your SOC needs to decide whether that applies to your environment. ATT&CK technique T1650, Acquire access, describes an adversary obtaining access to systems or networks as a Resource Development step, so it can support later operations. That access may be bought from a broker or handed over between actors, and it can appear before any initial access attempt against your organization. The technique sits under the Resource Development tactic (TA0042), which ATT&CK describes as establishing resources adversaries can use to support operations. Because the activity happens before the adversary touches your systems, your SOC rarely sees it directly and must work from external signals.
This page targets Enterprise ATT&CK 20.0. Before you map detections to T1650, confirm the technique definition, any sub-techniques and the data component references against that version in the enterprise-attack 20.0 STIX bundle, because ATT&CK releases can rename, deprecate or revoke techniques. Your practical exposure depends on what the intelligence describes. Reports naming your sector, your products or your remote access technologies deserve prompt triage. Ask your threat intelligence provider or internal intel team to route any listing with identifiable victim details to the SOC, and check whether your VPN gateways, identity providers or SaaS tenants appear in the material.
Decide now who owns this signal, who triages it and what evidence moves it into an incident. A workable starting point is a short intake procedure that records the source, the date, the claimed access type and the assets that could match. Pair it with a check of recent authentication logs for sign-ins from unfamiliar infrastructure against the accounts and applications named in the report. Document the decision either way, including why an unconfirmed listing was closed. That record will matter when an auditor or leadership asks how your organization handled pre-compromise intelligence.
Which data sources reveal acquired access and which open-source tool collects them
This table maps each signal that suggests an adversary has acquired access to a victim's environment to the data source that carries it and the open-source collector that can gather it. Read each row as a signal, its source, and a collector to evaluate, then confirm the data component IDs against the T1650 entry in the ATT&CK version your team targets. The main takeaway is that T1650 is mostly visible outside your perimeter, so collection must reach beyond your own logs.
| Signal | Data source | Open-source collector | Validation note |
|---|---|---|---|
| Leaked credentials or session tokens for your domains in public dumps | External exposure and leaked credential intelligence | OSINT feeds or threat intelligence platform the team already licenses, scheduled queries against Wazuh or a SIEM | Check the leak feed coverage and the DC IDs listed for T1650 in your ATT&CK version |
| Access listings or broker posts referencing your organization or its VPN appliances | External exposure and leaked credential intelligence | Threat intelligence feed with dark web or forum coverage, saved alert searches in Security Onion | Confirm which forums and marketplaces the feed actually indexes before relying on absence |
| Newly registered look-alike domains or certificates issued for your brand | Domain and certificate records | Certificate transparency monitoring, passive DNS feeds, alerts routed into Wazuh | Confirm DC0101 and DC0096 mappings for T1650 against your ATT&CK version |
| Unexpected changes in public DNS records or hosted service responses | Active DNS and response content from monitored services | Scheduled DNS and HTTP checks, file integrity monitoring on exposed configuration | Verify DC0103 and DC0104 references, then baseline normal responses first |
| Outbound connections from your network to infrastructure tied to access sales or staging | Network traffic content from perimeter sensors | Zeek logs for DNS and HTTP metadata, Suricata rules loaded through Security Onion | Confirm DC0085 applicability and test rules against captured traffic in a lab |
| Login attempts from anonymous or newly provisioned VPN or cloud accounts | Response metadata from authentication and remote access services | Wazuh decoders for VPN and identity logs, Zeek connection records for session review | Check DC0106 references and confirm the ATT&CK mitigation Pre-compromise scope with the vendor |
Detection ideas for acquired access described in words
Acquired access rarely announces itself inside the environment, so these ideas watch the edges: identity sign-ins, exposed credentials, hosting infrastructure and external service records. Each idea is a hypothesis to baseline in your own environment, and the cards note the thresholds to set and the benign activity that will trigger them first.
First-seen sign-in for a known account
Alert when a successful sign-in to an existing account comes from an address, network range or device fingerprint that the account has never used before, especially when it follows a password reset or a burst of failed attempts. Acquired accounts are often used from infrastructure the owner has never touched, so the novelty signal matters more than the location itself. Tune the look-back window per account group after a baseline period, and require a second risky signal, such as a new mailbox rule or a privilege request, before paging anyone. Expect false positives from vendor support sessions, penetration testers, traveling staff, and shared administrative accounts used from changing jump hosts. The data this depends on is identity provider sign-in logs and device records.
Exposed credential matches
Compare credential exposure feeds and breach corpora against your identity domains, and raise an alert when a matching address or username appears alongside a recent successful sign-in or an unchanged password. Treat a match as a prompt for forced reset and session revocation, not as proof of compromise. Set the matching rule to act on corporate domains and privileged accounts first, then widen it once the false positive rate is understood. Common noise comes from old breach data for accounts already rotated, from service accounts that share names with personal addresses, and from test users created during penetration tests. The data this depends on is external exposure feed records joined to the directory of accounts and the identity provider's sign-in history.
Hosting provider sign-in bursts
Watch for a sudden rise in successful sign-ins from cloud hosting and virtual private server address ranges that your users have not previously used, particularly when several accounts show the same pattern within a short window. Access sold in batches tends to be tested from the same provider blocks, so clustering matters more than any single event. Start with a threshold of several distinct accounts from one provider range in a short window, then adjust it based on your own baseline of legitimate cloud-hosted tooling. Expect false positives from managed service providers, cloud-hosted backup or SaaS integrations, and vendor support tooling that runs in hosted environments. The data this depends on is sign-in logs enriched with network ownership data, and network traffic content from your perimeter where it is retained.
Unexpected external service changes
Monitor your public-facing names for changes that suggest a service has changed hands: a new authoritative name server, a certificate issued by an unfamiliar authority, a registrar contact change, or a web response that differs sharply from the approved content. A handover of an exposed service can precede misuse of its trusted identity, so these records give defenders time to act. Set alerts on any change to registrar or name server records for owned domains, and treat certificate changes outside your change calendar as high priority. Expect false positives from planned migrations, managed DNS providers rotating name servers, and certificate renewals performed by a new vendor. The data this depends on is active DNS, passive DNS, domain registration and response metadata records for your own domains.
How to validate that the detection fires before you trust it
This sequence shows how to prove that a T1650 Acquire Access detection produces the expected telemetry and alerts before the SOC relies on it. It produces a repeatable test record tied to the ATT&CK version you target.
Agree the emulation scenario with the SOC
The detection engineer, SOC lead and cyber range operator agree in writing on the scenario, the business context and the boundaries of the exercise. Acquire Access is about an adversary obtaining access to infrastructure or accounts that it can then use, so the scenario should describe the kind of access being simulated and the systems in scope, without including commands, payloads or tooling details. The step is done when all three parties sign off on the scenario card.
Define the simulated access event and its expected telemetry
The detection engineer writes a short scenario card that names the simulated access event, the log sources that should record it, and the ATT&CK technique and version under test. Expected telemetry might include records from identity, cloud audit, or network sources, depending on how your environment handles access acquisition (illustrative). Confirm each expected source against the data components listed for T1650 in the ATT&CK version you target, so the test does not assume telemetry your collectors never receive. The step closes when every expected source has an owner and a confirmed collection path.
Define the expected alert and time window
The team writes down the alert name, its severity, the rule or analytic it comes from, and the time window in which the alert should appear after the simulated event. The SOC confirms which queue or case type the alert should land in. Agreeing the window before the run lets the team measure detection latency honestly rather than judging the result afterwards. The step is complete when the expected alert and window are recorded on the scenario card and reviewed by the SOC.
Run the emulation inside the cyber range
The range operator executes the agreed scenario in an isolated cyber range that mirrors production logging, while a neutral observer records the start and end times of each simulated action. Keep the operator's notes separate from the SOC's view so the analysts triage the alert as they would in production. The step is done when the run ends and every simulated action has a timestamp in the run log.
Record latency, fidelity and triage notes
After the run, the team compares the observer's timestamps with the time the telemetry arrived, the time the alert fired and the time an analyst opened the case. Detection latency is the gap between the simulated event and the alert. Alert fidelity records whether the alert fired on the intended behavior, and whether it also fired on unrelated activity. Analysts write triage notes on what context they needed and where they lacked it. The step is complete when each metric and note is filled in for the run.
Log gaps and assign fixes
The team lists each gap: missing telemetry, late ingestion, a rule that did not fire, or an alert that lacked enough context to triage. Each gap gets an owner, a fix type (collection, rule logic, enrichment or runbook) and a retest condition. Gaps that cannot be closed are recorded as accepted risk with the reason. The step closes when every gap has an owner and a status in the tracker.
Re-run the test after each tuning change
After any change to a rule, data source or parser, the team repeats the same scenario card and compares the new results with the baseline run. The goal is to confirm the fix works and that earlier behavior has not regressed. Use the same time window and observer method so the runs are comparable. The step is done when the new run is documented against the baseline with differences explained.
Store results against the targeted ATT&CK version
Save the scenario card, the run log, the metrics and the triage notes together, and label them with the ATT&CK version the detection targets. MITRE updates ATT&CK on a regular schedule, and releases can rename, deprecate or revoke techniques, so a result is only meaningful against the version it was tested for. Ask your detection content owner to confirm the version tag on each record, and review the mapping whenever a new ATT&CK release is adopted. The step closes when the record is filed in the detection library and linked to the rule it validates.
Preventive controls mapped to Pre-compromise (M1056)
ATT&CK maps Pre-compromise (M1056) to Resource Development techniques, including T1650 Acquire access. The controls below reduce what a broker can buy, reuse or find before an intrusion begins. Most run inside the client's own teams, while a few need a managed service or retainer to stay current.
Monitor external data sources
Watch paste sites, breach corpora, code hosting platforms and underground marketplaces for organization names, domains, executive identities and internal hostnames. Each hit should open a ticket with an owner and a time target for review. Ask any monitoring vendor which sources they cover, how often they refresh, and whether they alert on hostnames that are not yet public. Continuous collection and triage usually need a managed service or retainer, while the review workflow stays with the client.
Rotate and hunt exposed credentials
When a credential appears in an external dump, reset it, revoke active sessions and check authentication logs for use from unfamiliar sources. Prioritize service accounts, API keys and privileged users because a single leaked secret can give a broker a foothold without any phishing. Confirm that your identity provider can force resets in bulk and that secrets managers hold the keys that code repositories currently contain. The client owns rotation policy; a retainer can run recurring hunts across new leak sets.
Review third-party and vendor access
Inventory every vendor, reseller, contractor and managed service account that can reach your systems, including remote support tools and shared VPN credentials. For each one, record who approved the access, when it was last reviewed and whether multifactor authentication applies. Brokers often sell access that already exists in a supplier relationship, so an unmanaged vendor account is a common gap. The client owns this review and contract terms; a periodic external review can be scoped as a fixed engagement.
Restrict reusable access paths
Limit which systems accept inbound sessions from the internet, and require that remote access pass through a controlled gateway with logging. Remove legacy remote access methods that no current process needs, and check that administrative interfaces are not reachable from the public address space. The goal is to reduce the number of paths that a purchased credential or access listing could reuse. Firewall and gateway rules belong to the client's network team, and validation can be included in a fixed-scope penetration test.
Maintain an internet-facing asset inventory
Keep a current list of every domain, IP range, cloud account, certificate and externally reachable service, with an owner and a business purpose for each. Compare the list against what outside scanners see, and treat any unknown or abandoned service as a finding. Brokers commonly sell access to forgotten hosts, so stale systems carry much of the risk. Automated discovery can run in-house with open-source scanners, but reconciling the results and retiring assets stays with the client's operations and application owners.
Triage and response when an acquired-access alert fires
When an alert suggests that an adversary has acquired access, the first decision is whether the access is real. Confirm the signal against the source before anyone disables accounts or blocks infrastructure. For T1650 Acquire access, the access may be a valid credential, a session token, a purchased account or a VPN or remote access foothold, and each leads to a different response. Establish which account, system or service is involved, who owns it, and whether the login or session matches an expected business pattern. Then check for evidence of activity after the access: new mailbox rules, changed authentication methods, unusual API calls, new cloud resources or data reads from the affected identity. Also identify who else may hold the same access, including shared service accounts, vendor accounts, group memberships and other users who received the same credential or token through a common channel. Record the answers in the case notes as you go, because they determine the scope of containment.
Containment should match the confidence level and the blast radius. Typical options include disabling the affected account or revoking its active sessions, rotating secrets, keys and tokens that the identity could read, and blocking the source addresses, domains or infrastructure seen in the alert at the firewall, proxy or identity provider. Be deliberate about sequencing: a block that tips off an adversary can make later evidence harder to collect, so agree the order with the incident lead before executing. Preserve evidence before changing state, including identity provider sign-in logs, audit logs, endpoint and network captures within retention limits, and copies of any mailbox or configuration changed by the actor. Notify legal early so privilege and any reporting duties are considered, bring in the identity team to own account and credential changes, and brief the business owners of affected systems so they can confirm what is normal for their services. Confirm the list of recipients and their decisions in writing. Finally, treat these playbooks as untested until they have been run in the cyber range exercise described below, where gaps in ownership, access to logs and approval paths tend to surface.
Rehearsing acquired-access detection in a private cyber range
The range is a private environment built inside the client's own infrastructure, with no traffic leaving to external services. It mirrors the parts of the production estate that the detection depends on, so analysts see realistic-looking telemetry without touching live systems. Because T1650 Acquire access is an adversary activity that occurs before any compromise of the target, the range focuses on the signals the defender can actually observe: identity logs, network sensor output and external exposure records.
- Mirrored identity provider: a test tenant that reproduces the client's login flows, group structure and sign-in logging, so authentication events resemble production.
- Sample services: a small set of internal applications and an external-facing test endpoint whose exposure can be changed during the exercise.
- Network sensors: Zeek or Suricata deployed on a mirrored segment to record connections and content metadata for the test services.
- SIEM and case management: a Wazuh or Security Onion deployment that ingests the range logs, with a ticketing system that records every alert and handoff.
- Isolation controls: documented egress rules and a named owner who can cut the range off from any network it should not reach.
Confirm with the client which of these components can be deployed in their environment, which identity provider versions are supported, and what data may be copied into the range.
Injects are scripted events the exercise team releases on a schedule to test whether the detection logic fires and whether analysts respond. Each inject is described by what the defender should observe, not by how an adversary would produce it. The facilitator keeps the inject plan, timings and expected detections in a controlled document that the blue team does not see in advance.
- Leaked credential in a monitored feed: a test record appears in a simulated external feed that the team subscribes to, which should generate a triage ticket and a credential reset request.
- Login from unfamiliar hosting infrastructure: a sign-in event in the identity logs originates from an address range the client has not seen before, which should trigger risk scoring and a user verification step.
- Change in external exposure: a test endpoint becomes reachable on a new port or hostname, which should appear in the exposure review and open a change investigation.
- Unexplained inbound scanning: a burst of connection attempts against the test services, which tests whether network sensor alerts reach the correct queue.
- Mid-exercise escalation: a second inject that depends on whether the first was handled, which tests handoffs between analysts and the on-call owner.
Agree the inject list, the safety stops and the facilitator roles in writing before the rehearsal, and confirm which feeds and log sources the client can supply for the test.
A successful rehearsal is measured by observable outcomes, not by the number of alerts generated. The agreed criteria should be written before the exercise starts so the after-action discussion stays factual. The most useful output is a list of gaps with named owners and due dates, not a score.
- Timely alerts: each inject produces the expected alert within the response window the client agrees to, and the facilitator records the actual time.
- Playbook use: analysts follow the documented playbook for triage, verification and escalation, and deviations are noted with reasons.
- Containment executed: the responsible team carries out the agreed containment step, such as credential reset, blocking a test source or restoring a known exposure setting, and confirms it in the ticket.
- Accurate after-action report: the report lists what fired, what did not, what was missed and who owns each fix.
- Follow-up retest: gaps are retested after remediation so the fix is verified rather than assumed.
Check that the window, playbook and containment steps match the client's actual operating model before treating any result as a baseline.
Questions SOC leads and detection engineers ask about acquired access
How does T1650 detection differ from initial access detection in practice?
Initial access detection watches your perimeter, authentication paths and endpoints for an intrusion that has already started. T1650 happens before the adversary touches your environment, so most of the signal comes from outside your network or from your own logs showing that a stolen or sold access path is in use. In practice, the work splits into two streams: external intelligence about access offerings that could affect your organization, and internal correlation that flags a known account, session or VPN identity appearing from unexpected infrastructure. Your team can seldom see the acquisition itself, so the alert is built around the moment the access is used. Document which signals are external, and confirm the data component mappings for T1650 in the ATT&CK version you target.
Which data sources can an internal team realistically own for this detection?
Most internal teams can own the sources already inside their environment, plus a short list of external feeds they are permitted to consume. Start with identity provider sign-in logs, VPN and remote access logs, and directory events for privileged accounts, because these show when an account is used from unfamiliar sources. Add DNS and network metadata collected with open-source tools such as Zeek or Suricata to help correlate reused infrastructure. External intelligence on access brokers or exposed credentials is usually sourced through a subscription, and your team should confirm the licensing terms for each source before ingestion. Ask platform owners which logs already exist, how long they are retained, and whether they reach your SIEM in a normalized form.
How do we stop threat intelligence feeds from causing alert fatigue?
Limit feed-based alerts to indicators that match an asset, identity, domain or cloud tenant you own, and send everything else to a hunting queue. Feeds produce volume, so relevance is the first control: only indicators tied to your environment should page anyone. Second, score each indicator by source confidence and age, and expire it on a schedule so stale entries stop firing. Third, require correlation before escalation. A feed match combined with a sign-in from new infrastructure is an alert, while a feed match alone is a ticket. Track how many feed matches lead to confirmed investigations, and retire sources that never contribute. Write the rules in Sigma or your SIEM's native format so changes go through the same review as code.
How often should we re-validate the detection after an ATT&CK version change?
Re-validate whenever the ATT&CK version your detections target changes, and review the mapping at each release, not only when a rule starts failing. ATT&CK v18 replaced technique-page detections with detection strategies and analytics and made major updates to data components, so a rule written against an older mapping may no longer match its documented intent. Recent releases were v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026. Set a review step in your change process, then retest the detection in your cyber range after each review. Check the ATT&CK updates page for each release, and ask any testing partner to state in writing how version changes are handled.
What evidence will an auditor expect to see for this detection?
An auditor will usually expect a traceable chain from the control objective to the detection and its test results. Expect a mapping document that names the ATT&CK version, the technique, the mitigation Pre-compromise (M1056), and the data sources used along with their owners. Include the detection rule with version history, tuning records and sample alerts from test runs. Add cyber range exercise reports showing what was simulated, what fired, how triage proceeded and what changed afterward, plus the response runbook and evidence that analysts followed it. Auditors decide conformance. DeployOpen prepares systems, controls and evidence but does not issue audit reports or certifications. Confirm with your auditor which framework and control IDs they will test against before building the evidence pack.
Can our own team build and run this detection without outside help?
Your team can own the detection logic over time, but most organizations need outside help for the first build and the telemetry plumbing. The main cost drivers are detection engineering staff time, access to identity and network logs, legal review of any external intelligence feeds, and the number of scenarios your cyber range must replay. The initial build is one-time, while rule maintenance, version reviews and feed onboarding recur. DeployOpen plans, implements and documents open-source platforms inside your own infrastructure, runs private cyber ranges and offers retainers for ongoing testing. Engagements are fixed-scope, and scope, deliverables and timelines are agreed in writing before work starts. A quote follows from that written scope.
What should a cyber range exercise for this detection prove?
The exercise should show that the detection fires, is triaged, and leads to the documented response. For illustrative purposes, a range operator could replay synthetic sign-in events for a test identity from an address range the environment has never seen, then confirm the correlation rule raises an alert with the expected fields. Next, change one element at a time, such as the time gap between events or the presence of a matching feed entry, to find where the rule stops working. Record each result against the ATT&CK version and rule version in use. Keep the exercise safe by using test identities and isolated infrastructure, and only run it against systems your organization owns or has authorized in writing.
How DeployOpen builds acquired-access detections and range exercises
DeployOpen works on T1650 Acquire access as a fixed-scope engagement inside your own environment, starting from the ATT&CK version your team targets. We scope what telemetry you can actually see, build detections with open-source tooling, and rehearse them in a private cyber range before handing them over.
How we scope
- Confirm which ATT&CK version the detection mapping will target before any rule work begins
- Inventory which Response Content, Domain Registration and Passive DNS feeds your team can legitimately access
- Agree in writing which sub-techniques, log sources and assets fall inside the engagement
How we build
- Write detection logic in Sigma form and map it to the relevant ATT&CK detection strategies
- Connect the required log sources to Wazuh or Security Onion and document field mappings
- Tune alert thresholds against your baseline so analysts receive triage-ready signals
How we hand over
- Deliver rule documentation, data source dependencies and known blind spots in a single pack
- Run a cyber range exercise that replays acquired-access scenarios and records detection results
- Provide a response runbook covering triage, evidence preservation and escalation paths
How we support
- Offer ongoing support and continuous testing as a retainer after the fixed-scope delivery
- Review detection mappings when ATT&CK releases rename, deprecate or revoke techniques
- Ask your team to confirm retainer terms and review cadence in the written quote
