ShinyHuntersG1057 ↗
Has used valid domain accounts to gain initial access or to escalate privileges within environments.1
- Tactics
- Initial Access, Persistence, Privilege Escalation, Stealth
- Platforms
- ESXi, Linux, macOS, Windows
- Version
- 2.0
- Created
- 13 March 2020
- Last modified
- 12 May 2026
- Contributor
- Jon Sternstein, Stern Security
Adversaries may obtain and abuse credentials of a domain account as a means of gaining Initial Access, Persistence, Privilege Escalation, or Defense Evasion.[1] Domain accounts are those managed by Active Directory Domain Services where access and permissions are configured across systems and services that are part of that domain. Domain accounts can cover users, administrators, and services.[2]
ReconResource DevInitial AccessExecutionPersistencePriv EscStealthDef ImpairmentCred AccessDiscoveryLateral MoveCollectionC2ExfiltrationImpact
20
Threat groupsTop 8%
Threat groups92nd percentile · 92% of ATT&CK techniques have this many threat groups attributed or fewer.10
CampaignsTop 3%
Campaigns97th percentile · 97% of ATT&CK techniques have this many campaigns recorded or fewer.5
Tools & malware66th pct
Tools & malware66th percentile · 66% of ATT&CK techniques have this many tools implementing them or fewer.13
Detection rulesTop 19%
Detection rules81st percentile · 81% of ATT&CK techniques have this many detection rules written or fewer.Domain Accounts MITRE reference T1078.002
Top 8%of all ATT&CK techniques for number of groups
20 groups have been recorded using this technique. Newest first; each entry carries MITRE’s procedure text and a link to the group’s full record. Click a name to filter the rules below.
VOID MANTICOREG1055 ↗
Has used previously compromised Domain Administrator credentials to maintain persistent access.1
BlackByteG1043 ↗
Captured credentials for or impersonated domain administration users.12
PlayG1040 ↗
Has used valid domain accounts for access.1
AgriusG1030 ↗
Attempted to acquire valid credentials for victim environments through various means to enable follow-on lateral movement.1
APT5G1023 ↗
Has used legitimate account credentials to move laterally through compromised environments.1
All 20 groups for this technique · 6 newest in this preview
10 campaigns have been recorded using this technique. Listed newest first; dates are year-granularity and attribution is MITRE’s.
2025 Poland Wiper AttacksC0063 ↗
During the 2025 Poland Wiper Attacks, threat actors utilized privileged accounts to access the FortiGate VPN solution and subsequent subnets.1
Operation MidnightEclipseC0048 ↗
During Operation MidnightEclipse, threat actors used a compromised domain admin account to move laterally.1
Cutting EdgeC0029 ↗
During Cutting Edge, threat actors used compromised VPN accounts for lateral movement on targeted networks.1
Leviathan Australian IntrusionsC0049 ↗
Leviathan compromised domain credentials during Leviathan Australian Intrusions.1
Operation CuckooBeesC0012 ↗
During Operation CuckooBees, the threat actors used compromised domain administrator credentials as part of their lateral movement.1
SolarWinds CompromiseC0024 ↗
During the SolarWinds Compromise, APT29 used domain administrators' accounts to help facilitate lateral movement on compromised networks.1
All 10 campaigns for this technique · 6 newest in this preview
5 software entries are documented implementing this technique. MITRE files each as a tool or as malware; newest first, then by how many groups carry them.
CreepySnailS1024 ↗
Can use stolen credentials to authenticate on target networks.1
StuxnetS0603 ↗
Attempts to access network resources with a domain account’s credentials.1
RyukS0446 ↗
Can use stolen domain admin accounts to move laterally within a victim domain.1
Cobalt StrikeS0154 ↗
Can use known credentials to run commands and spawn processes as a domain user account.123
ShamoonS0140 ↗
If Shamoon cannot access shares using current privileges, it attempts access using hard coded, domain-specific credentials gathered earlier in the intrusion.12
All 5 software entries for this technique
Offense vs defense T1078.002
Is defensive coverage keeping up with adversary use? Eight counts, each ranked against all 697 ATT&CK techniques. Attack sits left, defense right, so a shape leaning left means adversaries are better documented here than defenders are equipped. Hover any spoke for its percentile and the share of techniques that have more. The timeline below shows when each side arrived.
How it got here
Range
Adversary activity (campaign spans) over cumulative rule output. Each source is plotted independently from zero, so neither line includes the other. Campaign dates are year-granularity.
Campaigns · 9Sigma rules (cumulative) · 7Splunk ESCU (cumulative) · 6
first rule: 2017 Q4 · 9 of 10 campaigns plotted (Night Dragon (dated 2009) falls before the 2014 window)Domain Accounts detection strategy DET0210
MITRE names one behaviour worth catching for this technique and breaks it into 4 analytics, one per platform. Each carries the log sources it needs and the fields you tune per environment.
Abuse of Domain Accounts
4 platforms
AN0590 · Windows
Detection of suspicious logon behavior using valid domain accounts across multiple hosts, off-hours, or simultaneous sessions from geographically distant locations.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| Process CreationDC0032 | WinEventLog:Sysmon | EventCode=1 |
| Network Connection CreationDC0082 | WinEventLog:Sysmon | EventCode=3, 22 |
| Logon Session MetadataDC0088 | WinEventLog:Security | EventCode=4624, 4625, 4768, 4769 |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| TimeWindow | Tune for detection of off-hours or abnormal logon spikes. |
| UserContext | Scope to sensitive domain accounts (e.g., Domain Admins). |
| LogonType | Distinguish between interactive, service, and network logons. |
AN0591 · Linux
Use of domain accounts via sssd or winbind for logon activity outside of typical patterns, especially on sensitive systems or with lateral movement tools.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| User Account AuthenticationDC0002 | auditd:SYSCALL | pam_authenticate, sshd |
| Logon Session MetadataDC0088 | linux:syslog | sssd / sudo logs |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| HostnameScope | Filter to high-value systems (e.g., domain-joined servers). |
| AccountDomain | Identify trusted domains versus external or misconfigured domains. |
AN0592 · macOS
Domain logins using network accounts or mobile accounts via Open Directory or Active Directory plugins, especially outside business hours or on atypical endpoints.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| User Account AuthenticationDC0002 | macos:unifiedlog | log show --predicate 'eventMessage contains "Authentication"' |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| UserLocation | Geo-IP or VPN source context for abnormal remote access. |
| LogonMethod | Control for expected services (e.g., GUI login vs. SSH). |
AN0593 · ESXi
Login to vSphere or ESXi hosts using domain accounts, especially those associated with vpxuser or unexpected group memberships.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| User Account AuthenticationDC0002 | esxi:vpxd | /var/log/vmware/vpxd.log |
| Logon Session MetadataDC0088 | esxi:hostd | /var/log/hostd.log |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| AccountType | Prioritize detection on accounts with elevated access. |
| LoginInterface | Distinguish interactive UI login from API or SSH access. |
5 analytics
Multiple users logged into a single machine at the same time, or even within the same hour, do not typically occur in networks we have observed.
D3FEND techniques
The defensive countermeasure this analytic implements, in MITRE’s D3FEND ontology.
| ID | Name |
|---|---|
| D3-ANET | Authentication Event Thresholding |
Data model references
The CAR data model objects, actions and fields the logic reads. Map these to your own schema before implementing.
| Object | Action | Field |
|---|---|---|
| user_session | login | user |
| user_session | login | hostname |
Implementations
Pseudocode is the canonical logic; the rest are CAR’s translations into vendor query languages.
users_list = search UserSession:Login users_grouped = group users_list by hostname users_grouped = from users_grouped select min(time) as earliest_time, max(time) as latest_time count(user) as user_count multiple_logins = filter users_grouped where (latest_time - earliest_time <= 1 hour and user_count > 1) output multiple_logins
Most users use only one or two machines during the normal course of business. User accounts that log in to multiple machines, especially over a short period of time, may be compromised. Remote logins among multiple machines may be an indicator of Lateral Movement.
D3FEND techniques
The defensive countermeasure this analytic implements, in MITRE’s D3FEND ontology.
| ID | Name |
|---|---|
| D3-ANET | Authentication Event Thresholding |
As described in CAR-2013-01-003, SMB provides a means of remotely managing a file system. Adversaries often use SMB to move laterally to a host. SMB is commonly used to upload files. It may be used for staging in Exfiltration or as a Lateral Movement technique. Unlike SMB Reads, SMB Write requests typically require an additional level of access, resulting in less activity. Focusing on SMB Write activity narrows the field to find techniques that actively change remote hosts, instead of passively reading files.
D3FEND techniques
The defensive countermeasure this analytic implements, in MITRE’s D3FEND ontology.
| ID | Name |
|---|---|
| D3-IPCTA | IPC Traffic Analysis |
Data model references
The CAR data model objects, actions and fields the logic reads. Map these to your own schema before implementing.
| Object | Action | Field |
|---|---|---|
| flow | message | proto_info |
| flow | message | dest_port |
Implementations
Pseudocode is the canonical logic; the rest are CAR’s translations into vendor query languages.
flow = search Flow:Message smb_write = filter flow where (dest_port == "445" and protocol == "smb.write") smb_write.file_name = smb_write.proto_info.file_name output smb_write
An adversary needs to gain access to other hosts to move throughout an environment. In many cases, this is a twofold process. First, a file is remotely written to a host via an SMB share (detected by CAR-2013-05-003). Then, a variety of Execution techniques can be used to remotely establish execution of the file or script. To detect this behavior, look for files that are written to a host over SMB and then later run directly as a process or in the command line arguments. SMB File Writes and Remote Execution may happen normally in an environment, but the combination of the two behaviors is less frequent and more likely to indicate adversarial activity.
D3FEND techniques
The defensive countermeasure this analytic implements, in MITRE’s D3FEND ontology.
| ID | Name |
|---|---|
| D3-IPCTA | IPC Traffic Analysis |
Data model references
The CAR data model objects, actions and fields the logic reads. Map these to your own schema before implementing.
| Object | Action | Field |
|---|---|---|
| process | create | image_path |
| process | create | proto_info |
| process | create | hostname |
Implementations
Pseudocode is the canonical logic; the rest are CAR’s translations into vendor query languages.
process = search Process:Create smb_write = run Analytic:CAR-2013-05-003 remote_start = join (smb_write, process) where ( smb_write.hostname == process.hostname and smb_write.file_path == process.image_path (smb_write.time < process.time) ) output remote_start
Monitoring logon and logoff events for hosts on the network is very important for situational awareness. This information can be used as an indicator of unusual activity as well as to corroborate activity seen elsewhere.
D3FEND techniques
The defensive countermeasure this analytic implements, in MITRE’s D3FEND ontology.
| ID | Name |
|---|---|
| D3-ANET | Authentication Event Thresholding |
Implementations
Pseudocode is the canonical logic; the rest are CAR’s translations into vendor query languages.
This base pseudocode looks for user logon events and filters out the top 30 account names to reduce the occurrence of noisy service accounts and the like. It is meant as a starting point for situational awareness around such events.
logon_events = search User_Session:Login filtered_logons = filter logon_events where ( user NOT IN TOP30(user)) output filtered_logons
Splunk version of the above pseudocode. NOTE - this is liable to be quite noisy and will need tweaking, especially in terms of the number of top users filtered out.
index=__your_win_event_log_index__ EventCode=4624|search NOT [search index=__your_win_event_log_index__ EventCode=4624|top 30 Account_Name|table Account_Name]
DNIF version of the above pseudocode.
_fetch * from event where $LogName=WINDOWS-NXLOG-AUDIT AND $SubSystem=AUTHENTICATION AND $Action=LOGIN group count_unique $ScopeID, $User limit 30 >>_store in_disk david_test win_top_30 stack_replace >>_fetch * from event where $LogName=WINDOWS-NXLOG-AUDIT AND $SubSystem=AUTHENTICATION AND $Action=LOGIN limit 10000 >>_checkif lookup david_test win_top_30 join $ScopeID = $ScopeID str_compare $User eq $User exclude
Integrating multi-factor authentication (MFA) as part of organizational policy can greatly reduce the risk of an adversary gaining control of valid credentials that may be used for additional tactics such as initial access, lateral movement, and collecting information. MFA can also be used to restrict access to cloud resources and APIs.
Password PoliciesM1027
Implement and enforce strong password policies for domain accounts to ensure passwords are complex, unique, and regularly rotated. This reduces the likelihood of password guessing, credential stuffing, and other attack methods that rely on weak or static credentials.
Audit domain account permission levels routinely to look for situations that could allow an adversary to gain wide access by obtaining credentials of a privileged account. Do not put user or admin domain accounts in the local administrator groups across systems unless they are tightly controlled and use of accounts is segmented, as this is often equivalent to having a local administrator account with the same password on all systems. Follow best practices for design and administration of an enterprise network to limit privileged account use across administrative tiers. Limit credential overlap across systems to prevent access if account credentials are obtained.
Regularly review and manage domain accounts to ensure that only active, necessary accounts exist. Remove or disable inactive and unnecessary accounts to reduce the risk of adversaries abusing these accounts to gain unauthorized access or move laterally within the network.
User TrainingM1017
Applications may send push notifications to verify a login as a form of multi-factor authentication (MFA). Train users to only accept valid push notifications and to report suspicious push notifications.