When a criminal buys access to your network, the purchase happens on a forum you do not control, and the first event you can log is the buyer logging in. MITRE ATT&CK T1650 Acquire Access covers adversaries purchasing or otherwise obtaining an existing foothold in a target system or network, usually from initial access brokers. ATT&CK v20 places it in Resource Development (TA0042) on the PRE platform, so there is nothing to detect on your own hosts at the moment of sale. This guide treats T1650 as an exposure reduction problem: what makes your access sellable, which non-human credentials end up in listings, what to watch outside your perimeter, and exactly what to do when a listing points at you. It is for threat intelligence analysts, SOC leads and identity teams. The broker market itself is explained in the Initial Access Brokers Guide; this page is the technique and response view.
Key takeaways
- ATT&CK says prevention is out of reach. The only mapped mitigation is M1056 Pre-compromise, and the detection strategy DET0884 says most of this happens outside the target's visibility, so defenders work the stages either side of the sale.
- What is sold is usually a valid login. ATT&CK notes that acquired footholds often rely on T1078 Valid Accounts, web shells (T1505.003) or external remote services (T1133). Removing those is how you reduce what can be sold.
- Machine credentials are stock too. Cloud access keys, VPN and service account passwords, API tokens and live session cookies survive in infostealer logs and breach dumps and often outlive the person who leaked them.
- Unmonitored, privileged systems sell for more. Microsoft reports that access to systems without antivirus or EDR, or with Domain Administrator credentials, commands higher prices. Coverage gaps are a commercial signal to buyers.
- A credible listing is an incident. Rotate, revoke and hunt as if the buyer is already inside, because the time between sale and use can be very short.
What T1650 covers
ATT&CK v20 describes T1650 as buying or otherwise acquiring existing access through online services and broker networks, and notes that adversary groups sometimes share compromised systems in partnerships. Footholds take many forms, including planted backdoors such as web shells, established access through external remote services, and a "load" that installs further malware for paying customers. Buyers save the effort of breaking in and focus on later stages. ATT&CK also notes that buying access to IT contractors, software developers or telecoms providers can lead to further victims via T1199 Trusted Relationship, T1111 Multi-Factor Authentication Interception or T1195 Supply Chain Compromise.
| Related technique | How it differs from T1650 |
|---|---|
| T1589.001 Credentials (Reconnaissance) | Gathering credentials about the victim; T1650 is acquiring a working foothold |
| T1597.002 Purchase Technical Data | Buying information about the target, not access to it; ATT&CK notes the two are often used together |
| T1078 Valid Accounts | The initial access step when the purchased foothold is a working account; this is where detection becomes possible |
| T1133 External Remote Services | Use of VPN, RDP, VDI or similar services, a common form of sold access |
| T1505.003 Web Shell | A planted backdoor on a web server, sold as ready-made access |
For the wider stage, see the ATT&CK Resource Development Tactic Guide.
How adversaries use it
ATT&CK procedure: Medusa Group
ATT&CK v20 records one procedure example: Medusa Group (G1051) purchasing user credentials and other sensitive data from initial access brokers. The joint FBI, CISA and MS-ISAC advisory AA25-071A, first published on 12 March 2025, adds that Medusa developers recruit brokers on cybercriminal forums and marketplaces, offering payments between US$100 and US$1 million, with an option to work exclusively for Medusa. The same advisory lists phishing and exploitation of unpatched software, including ScreenConnect CVE-2024-1709 and Fortinet EMS CVE-2023-48788, as initial access vectors. Its mitigations focus on the things brokers sell: MFA on webmail, VPNs and accounts that reach critical systems, strong passwords for service and administrator accounts, and filtering so unknown origins cannot reach internal remote services. See the Medusa Ransomware Threat Actor Profile.
What raises the price
Microsoft's analysis of ransomware as a service describes brokers selling "loads" from malware and botnets, mass-compromised Remote Desktop systems with weak passwords, and legacy systems without antivirus or EDR, with buyers choosing access by the number of systems they can reach and the profit potential. CrowdStrike's research on access broker listings found that listings describe the victim's sector and country, that higher revenue and elevated privileges raise the asking price, and that some access is auctioned. The practical point for defenders: privilege, monitoring gaps and company size are the three things a listing advertises, and the first two are under your control.
Case: credentials that stayed valid for years
In the Snowflake customer breach of 2024, Mandiant attributed access to credentials taken mainly by infostealer malware on systems Snowflake did not own, some first stolen as early as November 2020 and still valid years later because they were never rotated, on accounts without MFA. Stolen data was later offered for sale on criminal forums. Whether or not money changed hands for the credentials, the lesson for T1650 is the same: a leaked credential that is never rotated and is not protected by a second factor is sellable access for as long as it works.
What gets sold: NHI and remote access stock
The table lists the access types most relevant to this technique, where the exposure is visible to you and how to make each one worthless to a buyer. The control column is NHI Mgmt Group guidance based on the sources above.
| Access type | How it leaks | Where you can see the exposure | Make it unsellable |
|---|---|---|---|
| VPN, RDP or VDI accounts | Phishing, infostealers, password reuse | Dark web and infostealer log monitoring; VPN logs for new devices and countries | Phishing-resistant MFA on every remote path, including service and break-glass accounts |
| Cloud access keys (for example AWS AKIA keys) | Committed to code, left in files, CI logs, developer laptops | Secret scanning on repositories and public code; provider leak notifications | Replace with federated, short-lived credentials; deactivate unused keys |
| Service account passwords | Scripts, config files, shared vaults, infostealer logs from admin workstations | Credential exposure feeds matched against service account names | Managed or group managed service accounts, vaulting, interactive logon denied |
| API tokens and personal access tokens | Browser storage, CLI config files, repositories | Token scanning; SaaS audit logs for token use from new sources | Short expiry, scoped permissions, IP or device restrictions where supported |
| Session cookies and refresh tokens | Infostealer malware | Infostealer log monitoring for your domains | Short sessions, token binding where available, revocation on risk |
| Web shells and implants | Exploited edge devices and web applications | EDR and web server file integrity monitoring | Patch internet-facing systems quickly; reduce the edge |
For the identity side see the AWS Access Keys Security Guide and the Infostealer Logs and Session Token Abuse Guide.
Exposure reduction and external monitoring
Because DET0884 points defenders at the stages around the sale, the useful work splits into reducing what can be sold and watching for evidence that it was.
- Close monitoring gaps: Microsoft advises regular network scans and device discovery so that every server and workstation has antivirus or EDR, with tamper protection on. An unmanaged host is both easier to sell and harder for you to see.
- Remove standing privilege: Keep privileged accounts off member servers and workstations and randomise local administrator passwords, as Microsoft recommends, so a stolen local foothold does not carry domain-wide rights.
- Shrink remote access: Block unused remote management tools, require VPN or jump hosts for internal remote services and filter unknown origins, as both Microsoft and the Medusa advisory recommend.
- Watch credential markets: Subscribe to dark web, broker forum and infostealer log monitoring for your domains, IP ranges, product names and key prefixes. See the Dark Web Monitoring Guide.
- Watch the first login: The buyer's first action is T1078 or T1133. Alert on remote access from new devices, new hosting providers and impossible travel, and on cloud keys used from networks they have never used.
- Use partners: Share listings with your national CERT or law enforcement contact, and with suppliers named in the listing.
Responding when a listing names you
Listings rarely name the victim outright. Expect a description such as sector, country, revenue band, access type and privilege. Assess first, then act as if it is true.
- Assess credibility (first hour): Match the description to your estate: revenue, sector, number of hosts, named products (VPN vendor, Citrix, cloud provider). Note the seller's history if your intelligence provider has it. Preserve screenshots and the listing text with timestamps.
- Identify candidate access paths: List every external remote service, every privileged account and every non-human credential that matches the advertised access type and privilege level.
- Rotate and revoke: Reset passwords and enforce MFA on the matching accounts; deactivate exposed cloud access keys and use the provider's session revocation for roles (in AWS, revoking active role sessions invalidates temporary credentials issued before that time); in Microsoft Entra, disable the account where appropriate and revoke sign-in sessions. Remember that existing access tokens remain valid until they expire, about an hour by default in Entra, unless the app supports Continuous Access Evaluation.
- Hunt for the foothold and its backups: Look for web shells, new remote management tools, new local or cloud accounts, new access keys, new OAuth grants and new MFA methods registered in the weeks before the listing. Brokers often set up spare access.
- Review logs for the buyer: For each rotated credential, review its use over the past 90 days for new sources. In AWS, a key ID starting
AKIAis a long-term IAM user or root key andASIAis a temporary STS credential, which tells you whether to chase a key or the role that issued it. - Escalate and notify: If you find use of the access, move to your ransomware or intrusion playbook and assess breach notification duties. Report the listing to law enforcement.
- Close the class, not just the item: If the access was a password-only VPN account, fix MFA for all remote access, not one account.
For credential-specific steps see the Cloud Access Key Leak Playbook and the Session Token Theft Response Playbook.
How to test readiness
- Tabletop: Give the team a mock listing ("US healthcare, US$500M revenue, Citrix access, domain user") and time how long it takes to list matching access paths.
- Canary credentials: Plant decoy service account credentials and cloud keys with no rights in places that leak (old repositories, file shares) and alert on any use.
- Coverage audit: Compare the asset inventory against EDR enrolment each month; every unenrolled host is a potential listing.
- Revocation drill: Revoke a test identity's keys and sessions and confirm access stops across VPN, cloud console and SaaS.
Measuring it
- Share of remote access paths requiring phishing-resistant MFA, including non-human and break-glass accounts.
- Share of hosts with EDR enrolled and reporting.
- Number of long-lived cloud keys and static service account passwords, trending down.
- Median time from a credential exposure alert to rotation.
- Time from listing receipt to completed rotation of matching access paths.
Common failure patterns
- Filing the listing as intelligence: Treating a credible advert as background reading instead of an incident.
- Rotating the human, not the machine: Resetting user passwords while service account passwords and API keys in the same scope stay unchanged.
- Revoking passwords but not sessions: A stolen cookie or refresh token keeps working after a password reset unless sessions are revoked.
- Missing the backup access: Removing the advertised foothold but not the extra account or web shell the broker added.
- MFA exceptions: Leaving service, vendor or legacy VPN accounts on password only, which is exactly the access brokers test and sell.
Framework mapping
| Framework | Mapping |
|---|---|
| MITRE ATT&CK v20 | T1650 (TA0042 Resource Development); mitigation M1056; detection DET0884 / AN2016; related T1078, T1133, T1505.003, T1199, T1589.001, T1597.002 |
| NIST SP 800-53 Rev. 5 | PM-16 Threat Awareness Program, RA-3 Risk Assessment, IA-2 Identification and Authentication, AC-2 Account Management, SI-4 System Monitoring |
| NIST CSF 2.0 | ID.RA-03 internal and external threats identified; PR.AA-05 access permissions managed; DE.AE-02 adverse events analysed |
| ISO/IEC 27001:2022 Annex A | 5.7 Threat intelligence, 5.17 Authentication information, 8.5 Secure authentication |
Practitioner checklist
- Monitor broker forums, markets and infostealer logs for your domains, IP ranges and key prefixes.
- Require phishing-resistant MFA on every remote access path with no service account exceptions.
- Replace long-lived cloud keys and static service account passwords.
- Enrol every host in EDR and audit coverage monthly.
- Keep a written runbook for "access listed for sale" with owners and time targets.
- Revoke sessions and tokens, not only passwords, when credentials are exposed.
- Hunt for backup access after any confirmed listing.
- Plant canary credentials where leaks happen.
Standards and references
- MITRE ATT&CK: Acquire Access (T1650)
- CISA, FBI and MS-ISAC: #StopRansomware: Medusa Ransomware (AA25-071A)
- Microsoft Security: Ransomware as a service, understanding the cybercrime gig economy
- CrowdStrike: Access brokers, who are the targets and what are they worth
- AWS: Remediating potentially compromised AWS credentials
- Microsoft Learn: Revoke user access in Microsoft Entra ID
Related NHI Mgmt Group resources: MITRE ATT&CK T1078 Valid Accounts Guide · T1133 External Remote Services Defensive Guide · Ransomware-as-a-Service Business Model Guide · Top 10 Ransomware Initial Access Vectors