Accessed vulnerable Cisco switch devices using accounts with administrator privileges.1
- Tactics
- Initial Access, Persistence, Privilege Escalation, Stealth
- Platforms
- Containers, ESXi, Linux, macOS, Network Devices, Windows
- Version
- 2.0
- Created
- 13 March 2020
- Last modified
- 12 May 2026
Adversaries may obtain and abuse credentials of a local account as a means of gaining Initial Access, Persistence, Privilege Escalation, or Defense Evasion. Local accounts are those configured by an organization for use by users, remote support, services, or for administration on a single system or service.
Local Accounts MITRE reference T1078.003
12 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.
Compromised cPanel accounts in victim environments.1
Has used valid local accounts to gain initial access.1
Has used the NT AUTHORITY\SYSTEM account to create files on Exchange servers.1
Has used a tool called GREASE to add a Windows admin account in order to allow them continued access via RDP.1
Has used known administrator account credentials to execute the backdoor directly.1
All 12 groups for this technique · 6 newest in this preview
4 campaigns have been recorded using this technique. Listed newest first; dates are year-granularity and attribution is MITRE’s.
During the Anthropic AI-orchestrated Campaign, the adversary used Claude Code to test credentials harvested against discovered devices.1
Leviathan used captured local account information, such as service accounts, for actions during Leviathan Australian Intrusions.1
During the SolarWinds Compromise, APT29 used compromised local accounts to access victims' networks.1
During Operation Wocao, threat actors used local account credentials found during the intrusion for lateral movement and privilege escalation.1
All 4 campaigns for this technique
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.
Can use a compromised local account for lateral movement.1
Can use valid credentials with PsExec or wmic to spread itself to remote systems.12
Can brute force a local admin password, then use it to facilitate lateral movement.1
Creates valid local users to provide access to the system.1
Can use known credentials to run commands and spawn processes as a local user account.12
All 5 software entries for this technique
Offense vs defense T1078.003
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
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.
Local Accounts detection strategy DET0407
MITRE names one behaviour worth catching for this technique and breaks it into 3 analytics, one per platform. Each carries the log sources it needs and the fields you tune per environment.
Detection of Local Account Abuse for Initial Access and Persistence
AN1137 · Windows
Detects anomalous usage of local accounts to log into a system, especially accounts not typically used interactively or outside business hours.
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 |
|---|---|---|
| Logon Session CreationDC0067 | WinEventLog:Security | EventCode=4624, 4648 |
| Logon Session MetadataDC0088 | WinEventLog:Security | EventCode=4672 |
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 normal business hours to reduce false positives from legitimate after-hours work. |
| UserContext | Define list of legitimate local users for interactive access. |
AN1138 · Linux
Detects interactive or service logins from local accounts outside expected operational context or at anomalous times.
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 | linux:auth | sshd login |
| Logon Session MetadataDC0088 | auditd:USER_LOGIN | USER_LOGIN |
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 | Define operational hours or expected login times per host. |
| HostRole | Differentiate expected behavior for server vs. workstation. |
AN1139 · macOS
Detects abnormal or rare logins via local accounts through system or remote mechanisms such as SSH.
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 |
|---|---|---|
| Logon Session MetadataDC0088 | macos:unifiedlog | loginwindow or sshd |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| UserContext | Restrict expected local users by device owner or role. |
| TimeWindow | Set appropriate bounds based on endpoint usage patterns. |
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
Enable multi-factor authentication (MFA) for local accounts to add an extra layer of protection against credential theft and misuse. MFA can be implemented using methods like mobile-based authenticators or hardware tokens, even in environments that do not rely on domain controllers or cloud services. This additional security measure can help reduce the risk of adversaries gaining unauthorized access to local systems and resources.
Ensure that local administrator accounts have complex, unique passwords across all systems on the network.
Audit local accounts permission levels routinely to look for situations that could allow an adversary to gain wide access by obtaining credentials of a privileged account. Limit the usage of local administrator accounts to be used for day-to-day operations that may expose them to potential adversaries. For example, audit the use of service accounts in Kubernetes, and avoid automatically granting them access to the Kubernetes API if this is not required. Implementing LAPS may also help prevent reuse of local administrator credentials across a domain.
Enforce user account management practices for local accounts to limit access and remove inactive or unused accounts. By doing so, you reduce the attack surface available to adversaries and prevent unauthorized access to local systems.
Tests from Atomic Red Team (MIT licence) · technique definition