T1556.004: Network Device Authentication

Network Device Authentication is a high-consequence persistence and credential-access behavior: an adversary modifies a network device operating system image so a hard-coded password is accepted before normal authentication checks occur. For leaders, the risk is not just a stolen password; it is trust in routers, VPNs, or other network infrastructure being undermined at the authentication layer.

Executive priority

Prioritize this where network devices provide remote access, segmentation, or critical connectivity. The business question is whether the organization can prove that device images and authentication paths are intact, privileged access is controlled, and incident responders have a way to validate firmware or system-image integrity during an investigation. This technique is material to resilience because normal account reviews, password rotation, and even MFA may not be sufficient if the device authentication process itself has been modified.

Technical view

This sub-technique applies to Network Devices and sits under Modify Authentication Process across defense impairment, persistence, and credential access. SOC and IR teams should validate coverage for DET0272, Detect Modification of Network Device Authentication via Patched System Images, with emphasis on comparing running and stored system images against known-good baselines, reviewing privileged authentication behavior, and investigating unexpected successful local or administrative logons. Relationship context includes SYNful Knock, SLOWPULSE, and DRYHOOK as software associated with this behavior or related authentication modification activity, so threat hunts should consider network-device image integrity and authentication anomalies together rather than treating them as separate problems.

Likely telemetry

Network device authentication logs, including local, administrative, and failed-versus-successful login patterns
AAA, RADIUS, TACACS, or identity-provider records where used for network-device administration
System image, firmware, or boot image hashes and version inventory
Configuration backups and change history for network devices
Privileged account usage and administrative session logs

Detection direction

Validate whether DET0272-style detection is implemented: comparison of network device system images against trusted baselines and investigation of patched or unexpected images.
Tune for authentication outcomes that bypass expected identity flows, such as local administrative access where centralized authentication should normally apply.
Correlate image or firmware changes with approved maintenance windows and privileged account activity to reduce false positives from legitimate upgrades.
Do not rely only on password-change events or account audits; this behavior can grant access before normal credential verification is completed.
Confirm whether network-device logs are retained off-device, because a compromised device may not be a trustworthy source of evidence by itself.

Mitigation priorities

Start with privileged account management: restrict network-device administrative roles, enforce least privilege, and maintain accountability through logging and auditing.
Apply MFA for critical administrative access where supported, while recognizing that modified authentication logic may undermine normal authentication controls.
Maintain trusted baselines for network device images and configurations so responders can compare suspected devices against known-good states.
Control and review system image updates through approved change management, with independent validation after upgrades or emergency maintenance.
Ensure incident response playbooks include network-device image acquisition, integrity validation, and credential review for privileged device access.

Analyst notes and limits

MITRE provides no official detection text for this object, but the relationship to DET0272 gives a clear defensive direction: detect modified network-device authentication via patched system images. The supplied relationships to SYNful Knock, SLOWPULSE, and DRYHOOK support treating this as a network infrastructure and authentication-integrity problem, not merely an account-security issue.

This take is limited to the supplied ATT&CK fields and relationships. It does not assert current exploitation, affected vendors, customer exposure, or guaranteed detection. Local device models, logging capability, image validation methods, and administrative architecture are required to assess real coverage.

Official MITRE ATT&CK definition

Network Device Authentication

Adversaries may use Patch System Image to hard code a password in the operating system, thus bypassing of native authentication mechanisms for local accounts on network devices.

Modify System Image may include implanted code to the operating system for network devices to provide access for adversaries using a specific password. The modification includes a specific password which is implanted in the operating system image via the patch. Upon authentication attempts, the inserted code will first check to see if the user input is the password. If so, access is granted. Otherwise, the implanted code will pass the credentials on for verification of potentially valid credentials.[1]

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

ATT&CK relationship table

Related techniques

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

Filter related techniques 1 rows

Domain	ID	Name	Relationship / procedure
Enterprise	T1556	Modify Authentication Process	This object subtechnique of Modify Authentication Process.

Associated objects

Groups, software, and campaigns

S1104: SLOWPULSE

SLOWPULSE is a malware that was used by APT5 as early as 2020 including against U.S. Defense Industrial Base (DIB) companies. SLOWPULSE has several variants and can modify legitimate Pulse Secure VPN files in order to log credentials and bypass single and two-factor authentication flows.[1]

Network Devices

S0519: SYNful Knock

SYNful Knock is a stealthy modification of the operating system of network devices that can be used to maintain persistence within a victim's network and provide new capabilities to the adversary.[1][2]

Network Devices

S9013: DRYHOOK

DRYHOOK is Python script used to steal credentials. DRYHOOK was first reported in January 2025, and has previously been leveraged by People's Republic of China (PRC) state-affiliated threat actors identified as UNC5221 and SYLVANITE.[1][2][3]

LinuxNetwork Devices

Relationship explorer

All related ATT&CK context

uses · Malware S1104: SLOWPULSE Enterprise subtechnique of · Technique T1556: Modify Authentication Process Enterprise detects · Detection Strategy DET0272: Detect Modification of Network Device Authentication via Patched System Images Enterprise mitigates · Mitigation M1026: Privileged Account Management Enterprise uses · Malware S0519: SYNful Knock Enterprise mitigates · Mitigation M1032: Multi-factor Authentication Enterprise uses · Malware S9013: DRYHOOK Enterprise

Mitigations

Mitigation direction

M1026: Privileged Account Management

Privileged Account Management focuses on implementing policies, controls, and tools to securely manage privileged accounts (e.g., SYSTEM, root, or administrative accounts). This includes restricting access, limiting the scope of permissions, monitoring privileged account usage, and ensuring accountability through logging and auditing.This mitigation can be implemented through the following measures:

Account Permissions and Roles:

- Implement RBAC and least privilege principles to allocate permissions securely. - Use tools like Active Directory Group Policies to enforce access restrictions.

Credential Security:

- Deploy password vaulting tools like CyberArk, HashiCorp Vault, or KeePass for secure storage and rotation of credentials. - Enforce password policies for complexity, uniqueness, and expiration using tools like Microsoft Group Policy Objects (GPO).

Multi-Factor Authentication (MFA):

- Enforce MFA for all privileged accounts using Duo Security, Okta, or Microsoft Azure AD MFA.

Privileged Access Management (PAM):

- Use PAM solutions like CyberArk, BeyondTrust, or Thycotic to manage, monitor, and audit privileged access.

Auditing and Monitoring:

- Integrate activity monitoring into your SIEM (e.g., Splunk or QRadar) to detect and alert on anomalous privileged account usage.

Just-In-Time Access:

- Deploy JIT solutions like Azure Privileged Identity Management (PIM) or configure ephemeral roles in AWS and GCP to grant time-limited elevated permissions.

*Tools for Implementation*

Privileged Access Management (PAM):

- CyberArk, BeyondTrust, Thycotic, HashiCorp Vault.

Credential Management:

- Microsoft LAPS (Local Admin Password Solution), Password Safe, HashiCorp Vault, KeePass.

Multi-Factor Authentication:

- Duo Security, Okta, Microsoft Azure MFA, Google Authenticator.

Linux Privilege Management:

- sudo configuration, SELinux, AppArmor.

Just-In-Time Access:

- Azure Privileged Identity Management (PIM), AWS IAM Roles with session constraints, GCP Identity-Aware Proxy.

M1032: Multi-factor Authentication

Multi-Factor Authentication (MFA) enhances security by requiring users to provide at least two forms of verification to prove their identity before granting access. These factors typically include:

- *Something you know*: Passwords, PINs. - *Something you have*: Physical tokens, smartphone authenticator apps. - *Something you are*: Biometric data such as fingerprints, facial recognition, or retinal scans.

Implementing MFA across all critical systems and services ensures robust protection against account takeover and unauthorized access. This mitigation can be implemented through the following measures:

Identity and Access Management (IAM):

- Use IAM solutions like Azure Active Directory, Okta, or AWS IAM to enforce MFA policies for all user logins, especially for privileged roles. - Enable conditional access policies to enforce MFA for risky sign-ins (e.g., unfamiliar devices, geolocations). - Enable Conditional Access policies to only allow logins from trusted devices, such as those enrolled in Intune or joined via Hybrid/Entra.

Authentication Tools and Methods:

- Use authenticator applications such as Google Authenticator, Microsoft Authenticator, or Authy for time-based one-time passwords (TOTP). - Deploy hardware-based tokens like YubiKey, RSA SecurID, or smart cards for additional security. - Enforce biometric authentication for compatible devices and applications.

Secure Legacy Systems:

- Integrate MFA solutions with older systems using third-party tools like Duo Security or Thales SafeNet. - Enable RADIUS/NPS servers to facilitate MFA for VPNs, RDP, and other network logins.

Monitoring and Alerting:

- Use SIEM tools to monitor failed MFA attempts, login anomalies, or brute-force attempts against MFA systems. - Implement alerts for suspicious MFA activities, such as repeated failed codes or new device registrations.

Training and Policy Enforcement:

- Educate employees on the importance of MFA and secure authenticator usage. - Enforce policies that require MFA on all critical systems, especially for remote access, privileged accounts, and cloud applications.

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release: 19.1
Object version: 3.0
Created: Oct 19, 2020, 17:58 UTC (UTC+00:00)
Modified: May 12, 2026, 15:12 UTC (UTC+00:00)
Raw hash: 147e2fd925a90219...

Imported snapshots across ATT&CK releases (1)

Release	Bundle imported	Object version	Modified	Status	Raw hash
19.1	May 18, 2026, 07:08 UTC (UTC+00:00)	3.0	May 12, 2026, 15:12 UTC (UTC+00:00)	Current bundle	`147e2fd925a9…`

Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Open mirrored raw JSON Open MITRE-hosted copy

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

[1]
Mandiant - Synful Knock

Bill Hau, Tony Lee, Josh Homan. (2015, September 15). SYNful Knock - A Cisco router implant - Part I. Retrieved November 17, 2024.
Open source URL
[2]
mitre-attack T1556.004
Open source URL

Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use

Analyst context for executives and security teams