1 of 8

Account Manipulation

Account Manipulation [T1098]

Information

Name: Account Manipulation
ID: T1098
Tactics: TA0003, TA0004
Sub-Technique: T1098.003, T1098.006, T1098.007, T1098.004, T1098.005, T1098.001, T1098.002

Introduction

Account Manipulation (T1098) is a technique categorized within the MITRE ATT&CK framework under the tactic of Persistence, Privilege Escalation, and Defense Evasion. Attackers leverage this technique to maintain persistent access to compromised systems, elevate their privileges, or evade detection by altering, creating, or deleting user and system accounts. Manipulating accounts allows adversaries to blend into legitimate administrative activities, making detection challenging and enabling prolonged access within targeted environments.

Deep Dive Into Technique

Account Manipulation involves attackers modifying existing user accounts or creating new accounts to maintain persistence, escalate privileges, or evade detection. Technical execution methods and mechanisms include:

Creating New Accounts:
- Attackers may create local or domain accounts, such as standard user accounts or administrative accounts, to maintain access.
- On Windows systems, adversaries may use command-line utilities such as:
  - net user <username> <password> /add
  - PowerShell cmdlets: New-LocalUser, New-ADUser
- On Linux/Unix systems:
  - Commands like useradd, adduser, and editing /etc/passwd or /etc/shadow directly.
Modifying Existing Accounts:
- Attackers may alter account permissions, privileges, or group memberships to escalate privileges or maintain access.
- Windows:
  - Commands such as net localgroup administrators <username> /add
  - PowerShell scripts to modify Active Directory group memberships or user attributes.
- Linux/Unix:
  - Commands such as usermod, editing /etc/group, or directly manipulating PAM configurations.
Deleting or Disabling Accounts:
- Attackers may disable or delete accounts to disrupt legitimate administrative activities or hide their tracks.
- Windows:
  - net user <username> /delete
  - PowerShell cmdlets: Remove-LocalUser, Remove-ADUser
- Linux/Unix:
  - Commands such as userdel or editing system files directly.
Manipulating Account Attributes:
- Attackers may alter account attributes (e.g., password expiration, login scripts, home directories) to facilitate persistence or privilege escalation.
- Windows Active Directory:
  - Using tools like Active Directory Users and Computers (ADUC), PowerShell, or direct LDAP queries.
- Linux/Unix:
  - Modifying files like /etc/passwd, /etc/shadow, and /etc/login.defs.

When this Technique is Usually Used

Account Manipulation is commonly employed during various stages and scenarios of cyberattacks:

Persistence:
- Attackers create or modify accounts to ensure persistent access even after system reboots or credential changes.
- Commonly used after initial compromise (post-exploitation).
Privilege Escalation:
- Attackers modify existing accounts or create new accounts with elevated privileges to gain administrative control.
- Often occurs immediately after initial foothold establishment or lateral movement.
Defense Evasion:
- Attackers manipulate accounts to blend into legitimate administrative activities, making detection challenging.
- Deleting or disabling accounts may also be used to disrupt defensive operations or hide attacker presence.
Credential Access:
- Attackers may alter account password policies or attributes to facilitate easier credential harvesting.
Impact Stage:
- Attackers may disable or delete legitimate accounts to disrupt organizational operations or hinder incident response.

How this Technique is Usually Detected

Detection of Account Manipulation involves monitoring and analyzing various system logs, configurations, and behaviors. Common detection methods, tools, and indicators of compromise (IoCs) include:

Windows Event Logs:
- Security logs (Event IDs):
  - 4720: User account created
  - 4722: User account enabled
  - 4725: User account disabled
  - 4726: User account deleted
  - 4732, 4733: Security-enabled local group membership changes
  - 4738: User account attributes changed
- System logs for unusual service account creations or modifications.
Linux/Unix Logs:
- /var/log/auth.log, /var/log/secure for account creation, deletion, or modifications.
- Monitoring changes to files such as /etc/passwd, /etc/shadow, /etc/group.
Active Directory Monitoring:
- Tools like Microsoft Defender for Identity, Azure AD Audit Logs, and third-party solutions (Splunk, Elastic Security, CrowdStrike Falcon, SentinelOne).
- LDAP queries and monitoring of unusual account attribute changes.
Endpoint Detection and Response (EDR) and SIEM Tools:
- Real-time monitoring for suspicious account activities.
- Alerting on unusual account creation, modification, or deletion events.
Behavioral Analytics:
- Detecting anomalous account behaviors, such as logins from unusual locations or times, sudden privilege escalations, or account creations/deletions outside normal administrative hours.
Indicators of Compromise (IoCs):
- Unexpected or unauthorized accounts appearing in user directories or Active Directory.
- Sudden privilege escalation of existing accounts.
- Disabled or deleted legitimate administrative accounts without proper authorization.
- Unusual logins or account modifications from suspicious or unknown sources.

Why it is Important to Detect This Technique

Early detection of Account Manipulation is critical due to its significant impacts on security posture, operational integrity, and organizational trust. Possible impacts and reasons for importance include:

Persistent Access:
- Undetected manipulated accounts enable attackers to retain long-term access, increasing risk of prolonged breaches and data exfiltration.
Privilege Escalation:
- Attackers gaining elevated privileges can perform further malicious actions, including lateral movement, data theft, ransomware deployment, or sabotage of critical systems.
Operational Disruption:
- Deletion or disabling of legitimate accounts disrupts business operations, leading to service outages, productivity loss, and potential financial harm.
Difficulty of Remediation:
- Manipulated accounts complicate incident response and remediation efforts, making it challenging to fully eradicate attacker presence.
Compliance and Regulatory Implications:
- Failure to detect and respond to account manipulation may lead to breaches of compliance standards (e.g., GDPR, HIPAA, PCI DSS), resulting in legal penalties and reputational damage.
Increased Risk of Insider Threats:
- Manipulated accounts may be leveraged to mimic insider behaviors, complicating attribution and response.

Examples

Real-world examples of Account Manipulation in attack scenarios include:

APT29 (Cozy Bear):
- Utilized account manipulation techniques to maintain persistent access within targeted networks by creating new domain administrator accounts and modifying existing accounts.
- Tools used: PowerShell scripts, custom malware, and legitimate administrative utilities.
- Impact: Persistent espionage activities, data theft, and prolonged breaches.
FIN7 Cybercrime Group:
- Created new Windows administrative accounts after initial compromise to maintain persistent access and evade detection.
- Tools used: PowerShell scripts, Cobalt Strike, and built-in Windows utilities (net user, net localgroup).
- Impact: Financial data theft, unauthorized access to payment card data, and significant financial losses for targeted organizations.
NotPetya Ransomware Attack:
- Manipulated Active Directory accounts to escalate privileges and propagate rapidly across networks.
- Tools used: Mimikatz, built-in Windows commands, and credential theft techniques.
- Impact: Massive global disruption, significant financial damages, and operational downtime across multiple industries.
Operation Cloud Hopper (APT10):
- Leveraged account manipulation by creating new accounts and altering existing ones within managed service providers (MSPs) to gain persistent access to customer networks.
- Tools used: Custom malware, PowerShell scripts, and legitimate administrative tools.
- Impact: Espionage, intellectual property theft, and prolonged unauthorized access.
Insider Threat Scenarios:
- Malicious insiders manipulating or creating unauthorized accounts to exfiltrate sensitive data or disrupt organizational operations.
- Tools used: Standard administrative tools, scripting languages, and direct system configuration edits.
- Impact: Data breaches, operational disruptions, reputational harm, and financial losses.

Additional Cloud Credentials

Additional Cloud Credentials [T1098.001]

Information

Name: Additional Cloud Credentials
ID: T1098.001
Tactics: TA0003, TA0004
Technique: T1098

Introduction

The MITRE ATT&CK sub-technique Additional Cloud Credentials (T1098.001) refers to adversaries obtaining and leveraging extra credentials within cloud environments beyond their initial access point. Attackers frequently utilize these credentials to maintain persistence, escalate privileges, and move laterally across cloud resources. By acquiring additional cloud credentials, adversaries can expand their control and enhance their ability to evade detection and remediation efforts.

Deep Dive Into Technique

Attackers commonly execute this sub-technique by targeting cloud platform features, configurations, or vulnerabilities to obtain additional credentials. The following mechanisms detail typical methods attackers use:

Credential Theft from Cloud Instances:
- Attackers access cloud-hosted virtual machines or containers and extract credentials stored within instance metadata services or configuration files.
- Exploitation of misconfigured instance metadata endpoints (e.g., AWS EC2 metadata endpoint at http://169.254.169.254).
Compromising Cloud Identity and Access Management (IAM) Roles and Policies:
- Attackers exploit overly permissive IAM policies or roles to gain elevated privileges or additional credentials.
- Manipulation or abuse of IAM trust relationships to assume additional roles.
Cloud Service Misconfigurations:
- Misconfigured storage buckets, databases, or other cloud services that inadvertently expose credentials or access tokens.
- Harvesting credentials from improperly secured cloud-based CI/CD pipelines or code repositories.
Phishing and Social Engineering:
- Attackers may use targeted phishing campaigns to trick users into revealing cloud credentials or authorizing OAuth applications that grant additional credentials.
Third-party Integrations and OAuth Tokens:
- Attackers abuse third-party applications or OAuth tokens with excessive permissions to access additional cloud credentials or escalate privileges.
Credential Dumping Tools and Scripts:
- Utilizing specialized tools and scripts designed to extract secrets, tokens, or credentials from cloud instances or services (e.g., Pacu, ScoutSuite, Prowler).

When this Technique is Usually Used

Attackers typically leverage additional cloud credentials during multiple stages of an attack lifecycle, including:

Initial Access and Persistence:
- After initial compromise, adversaries obtain additional credentials to maintain persistent access even if initial credentials are revoked or discovered.
Privilege Escalation:
- Attackers use additional credentials to escalate privileges, gaining administrative access or broader permissions within cloud environments.
Lateral Movement:
- Utilizing additional credentials to move laterally across cloud accounts, resources, or even between cloud providers.
Defense Evasion:
- Attackers rotate between multiple credentials to obscure activities, evade detection, and complicate incident response efforts.
Data Exfiltration and Impact:
- Attackers leverage additional credentials to access sensitive data, intellectual property, or confidential information stored in cloud environments.

How this Technique is Usually Detected

Detection of additional cloud credential usage typically involves monitoring and auditing cloud environments with various methods and tools:

Cloud Provider Logging and Monitoring:
- AWS CloudTrail, Azure Activity Logs, Google Cloud Audit Logs to track suspicious or unauthorized credential usage.
- Monitoring for unusual API calls, unexpected IAM policy changes, or suspicious role assumptions.
Cloud Security Posture Management (CSPM) Tools:
- Tools such as Prisma Cloud, CloudGuard, Aqua Security, or Wiz to detect misconfigurations and suspicious credential activity.
Behavioral Analytics and Anomaly Detection:
- Leveraging User and Entity Behavior Analytics (UEBA) tools to identify anomalous credential usage patterns or unusual access attempts.
Endpoint Detection and Response (EDR) and Cloud Workload Protection Platforms (CWPP):
- Monitoring cloud instances for credential dumping tools, scripts, or suspicious processes indicative of credential harvesting.
Specific Indicators of Compromise (IoCs):
- Unusual or unauthorized IAM role assumption events.
- Unexpected increase in API requests from unknown or unexpected sources.
- Detection of credential dumping tools (e.g., Pacu, ScoutSuite) on cloud instances.
- Identification of unauthorized OAuth application authorizations or tokens within cloud environments.

Why it is Important to Detect This Technique

Early detection of adversaries obtaining additional cloud credentials is critical for several reasons:

Preventing Privilege Escalation:
- Early detection helps mitigate attackers' ability to escalate privileges and gain administrative control over cloud resources.
Reducing Damage and Impact:
- Quickly identifying compromised credentials limits attackers' opportunities to exfiltrate sensitive data, disrupt operations, or cause financial and reputational damage.
Stopping Lateral Movement:
- Prompt detection prevents attackers from moving laterally across cloud environments, containing the attack and reducing the scope of compromise.
Preserving Trust and Compliance:
- Timely detection and response ensure compliance with regulatory standards (e.g., GDPR, HIPAA, PCI DSS) and protect organizational reputation and customer trust.
Improving Incident Response Efficiency:
- Identifying and remediating compromised credentials early reduces the complexity, time, and costs associated with incident response and recovery efforts.

Examples

Real-world examples of adversaries leveraging additional cloud credentials include:

Capital One Breach (2019):
- Attack Scenario:
  - Attacker exploited a misconfigured Web Application Firewall (WAF) to access an AWS EC2 instance.
  - Extracted AWS IAM credentials from the instance metadata service.
- Tools and Techniques:
  - Accessed AWS EC2 metadata endpoint (http://169.254.169.254) to obtain IAM role credentials.
- Impact:
  - Exfiltrated sensitive data of over 100 million customers, resulting in significant financial and reputational damage.
TeamTNT Cloud Attacks (2020-2021):
- Attack Scenario:
  - Attackers compromised cloud instances and containers to extract AWS credentials from metadata endpoints and configuration files.
- Tools and Techniques:
  - Used automated scripts and tools to scan and extract AWS credentials from compromised Docker instances and Kubernetes clusters.
- Impact:
  - Hijacked cloud resources for cryptocurrency mining, resulting in increased operational costs and resource exhaustion.
Uber Data Breach (2022):
- Attack Scenario:
  - Attacker performed social engineering against an employee, gaining initial credentials.
  - Leveraged compromised VPN and cloud credentials to access internal cloud resources.
- Tools and Techniques:
  - Social engineering, credential theft, lateral movement within cloud environments.
- Impact:
  - Exposure of sensitive internal data, significant public scrutiny, and regulatory investigations.

These examples highlight the critical importance of securing cloud environments and proactively monitoring for unauthorized credential usage to prevent severe impacts.

Additional Email Delegate Permissions

Additional Email Delegate Permissions [T1098.002]

Information

Name: Additional Email Delegate Permissions
ID: T1098.002
Tactics: TA0003, TA0004
Technique: T1098

Introduction

The sub-technique Additional Email Delegate Permissions (T1098.002) falls under the MITRE ATT&CK framework's Account Manipulation technique (T1098). Attackers leveraging this sub-technique assign additional delegate permissions to email accounts, enabling unauthorized access, persistence, and stealthy monitoring of email communications. Delegation permissions allow attackers to read, send, and manage emails on behalf of the compromised users, facilitating internal reconnaissance, lateral movement, and data exfiltration activities without raising immediate suspicion.

Deep Dive Into Technique

Attackers exploiting Additional Email Delegate Permissions typically target email systems such as Microsoft Exchange and Office 365. Email delegation permissions allow one mailbox user to grant another user or account the ability to read, send, and manage email messages on their behalf. Attackers may abuse this functionality by:

Modifying mailbox permissions using administrative credentials or compromised user accounts with sufficient privileges.
Leveraging PowerShell cmdlets, Exchange Management Shell, or Exchange Web Services (EWS) API to assign mailbox delegation rights silently.
Assigning delegate permissions such as "Full Access," "Send As," or "Send on Behalf" to an attacker-controlled account or compromised internal account.

Technical execution methods include:

PowerShell Commands:
- Add-MailboxPermission -Identity victim@example.com -User attacker@example.com -AccessRights FullAccess -InheritanceType All
- Add-RecipientPermission victim@example.com -Trustee attacker@example.com -AccessRights SendAs
Exchange Web Services (EWS) APIs:
- Attackers may interact directly with EWS endpoints to manipulate permissions programmatically and silently.
Graph API (Office 365 environments):
- Attackers may leverage Microsoft Graph API endpoints to silently adjust mailbox permissions if they have sufficient privileges.

Real-world procedures commonly involve:

Compromising administrator-level accounts or accounts with sufficient Exchange privileges.
Stealthily assigning delegate permissions to attacker-controlled accounts or compromised internal accounts for persistent email access.
Monitoring internal communications, exfiltrating sensitive data, or conducting internal phishing campaigns using delegated permissions.

When this Technique is Usually Used

Additional Email Delegate Permissions are typically employed by attackers during the following attack stages and scenarios:

Persistence:
- Attackers establish persistent access to sensitive email communications by silently assigning delegate permissions, even after initial access vectors are mitigated.
Collection and Reconnaissance:
- Attackers monitor email communications to gather intelligence, sensitive data, credentials, or internal organizational information.
Credential Access and Lateral Movement:
- Attackers leverage delegated permissions to send internal phishing emails, spread malicious content, or escalate privileges internally.
Exfiltration:
- Attackers silently forward emails or use delegated access to extract sensitive information outside the organization without raising alarms.
Internal Phishing and Social Engineering:
- Attackers use delegate permissions to impersonate legitimate users, sending emails from trusted internal accounts to deceive users.

How this Technique is Usually Detected

Detection of Additional Email Delegate Permissions involves monitoring and auditing mailbox permissions and changes closely. Methods and tools include:

Exchange Audit Logging:
- Regularly review mailbox permission changes logged by Exchange or Office 365 audit logs for suspicious or unauthorized delegate permissions.
PowerShell Logging and Monitoring:
- Monitor PowerShell command execution logs for suspicious mailbox permission cmdlets (Add-MailboxPermission, Add-RecipientPermission) executed by unusual accounts or at unusual times.
Microsoft 365 Defender and Security Center Alerts:
- Utilize built-in alerts and anomaly detection that flag unusual mailbox permission assignments or delegate permission changes.
SIEM Solutions and Log Aggregation Tools:
- Aggregate and correlate Exchange logs, PowerShell logs, and API access logs to detect suspicious permission changes.
Indicators of Compromise (IoCs):
- Sudden appearance of unknown delegate permissions on sensitive mailboxes.
- Unexpected mailbox permission modifications initiated by non-administrative or rarely-used administrative accounts.
- Unusual login or mailbox access patterns from unknown or suspicious IP addresses or devices.

Why it is Important to Detect This Technique

Detecting Additional Email Delegate Permissions early is critical due to the potential severe impacts on organizational security, privacy, and operational integrity:

Data Theft and Exfiltration:
- Attackers gain persistent, covert access to sensitive internal communications, intellectual property, financial data, and personally identifiable information (PII).
Internal Reconnaissance and Privilege Escalation:
- Attackers leverage email delegate permissions to gather intelligence, escalate privileges, and prepare for lateral movement across the network.
Business Email Compromise (BEC) and Fraud:
- Attackers impersonate legitimate internal users, conducting fraudulent transactions, unauthorized wire transfers, or business disruptions.
Reputational Damage and Regulatory Compliance:
- Unauthorized email access can lead to data breaches, regulatory fines, loss of customer trust, and significant reputational damage.
Difficulty of Detection Post-Compromise:
- Delegate permissions are subtle and may evade detection if not monitored closely, allowing attackers prolonged access and increasing the difficulty of remediation.

Early detection and response significantly reduce these risks, limiting attacker dwell time, minimizing potential damage, and ensuring rapid containment and remediation.

Examples

Real-world examples of attacks involving Additional Email Delegate Permissions include:

APT29 (Cozy Bear) and SolarWinds Incident:
- Attackers leveraged compromised administrator accounts to silently assign delegate permissions in Microsoft 365 environments, enabling persistent access to sensitive email communications. Attackers monitored internal communications for months, harvesting sensitive data and intelligence.
- Tools used included PowerShell scripts and Exchange Web Services (EWS) APIs to silently configure delegate permissions.
- Impact included prolonged espionage, sensitive data exfiltration, and significant operational disruption.
Business Email Compromise (BEC) Incidents:
- Attackers compromised executive-level accounts, silently assigned delegate permissions to attacker-controlled internal accounts, and monitored email communications for financial transactions and sensitive business information.
- Attackers used delegate permissions to impersonate executives, sending fraudulent payment instructions, resulting in significant financial losses.
- Impact included financial theft, reputational damage, and regulatory scrutiny.
Internal Phishing Campaigns:
- Attackers assigned delegate permissions to compromised internal accounts, enabling them to send phishing emails from trusted internal accounts, significantly increasing the effectiveness of social engineering attacks.
- Attackers used delegated email access to distribute malware, ransomware, or credential-stealing phishing emails internally.
- Impact included widespread credential theft, malware infections, operational disruptions, and costly remediation efforts.

These examples highlight the effectiveness, stealth, and potential severe impacts of Additional Email Delegate Permissions, underscoring the importance of proactive monitoring, detection, and response.

Additional Cloud Roles

Additional Cloud Roles [T1098.003]

Information

Name: Additional Cloud Roles
ID: T1098.003
Tactics: TA0003, TA0004
Technique: T1098

Introduction

The MITRE ATT&CK sub-technique Additional Cloud Roles (T1098.003) falls under the broader technique of Account Manipulation (T1098). This sub-technique specifically addresses scenarios where adversaries create, modify, or assume additional roles within cloud environments to maintain persistence, escalate privileges, or evade detection. Cloud roles define sets of permissions that grant access to resources and services. By manipulating roles, attackers can establish persistent access, facilitate lateral movement, and reduce their risk of detection.

Deep Dive Into Technique

Additional Cloud Roles (T1098.003) involves adversaries leveraging cloud identity and access management (IAM) systems to create or modify roles with specific permissions. These roles can then be assigned to compromised accounts or resources, enabling attackers to maintain persistence, escalate privileges, or perform lateral movement across the cloud infrastructure.

Technical execution methods include:

Creating New IAM Roles:
- Attackers may create new roles with elevated or specific permissions tailored to their objectives.
- Roles can be designed to blend in with legitimate naming conventions to evade suspicion.
Modifying Existing Roles:
- Attackers may alter existing roles by adding permissions or policies that grant additional access.
- Existing roles are often targeted due to their legitimate presence, thus minimizing detection risk.
Assuming Roles via STS (Security Token Service):
- Attackers leverage the cloud provider's STS to assume roles temporarily, obtaining temporary security credentials for privileged actions.
- Temporary credentials reduce the likelihood of detection, as they are ephemeral and may not be closely monitored.
Cross-Account Role Assumption:
- Attackers may exploit trust relationships between cloud accounts to assume roles in other accounts, broadening their access scope across organizational boundaries.

Real-world procedures attackers employ include:

Leveraging compromised cloud administrator accounts or API keys to create or modify roles.
Exploiting overly permissive IAM policies or misconfigured trust relationships.
Using automation scripts or cloud-native CLI tools (such as AWS CLI, Azure CLI, or Google Cloud SDK) to programmatically manage roles.

When this Technique is Usually Used

Attackers typically utilize Additional Cloud Roles (T1098.003) during various stages of the cyber kill chain, including:

Persistence:
- Creating roles with persistent access ensures attackers retain long-term access even if initial compromised accounts are detected or mitigated.
Privilege Escalation:
- Modifying existing roles or creating new roles with elevated privileges allows attackers to escalate their access within the cloud environment.
Lateral Movement:
- Assuming cross-account roles facilitates lateral movement between cloud accounts or environments within an organization.
Defense Evasion:
- Utilizing ephemeral role assumptions and temporary credentials makes detection and attribution more challenging.

Common attack scenarios include:

Post-compromise activities after initial cloud credential theft or phishing attacks.
Exploitation of misconfigured IAM policies or trust relationships between cloud accounts.
Advanced persistent threat (APT) actors seeking long-term and stealthy persistence in cloud environments.

How this Technique is Usually Detected

Detecting Additional Cloud Roles (T1098.003) typically involves monitoring and analyzing cloud IAM activity and logs. Effective detection methods include:

Cloud Audit Logging:
- Regular monitoring of cloud provider audit logs (AWS CloudTrail, Azure Activity Logs, Google Cloud Audit Logs) for suspicious role creation, modification, or assumption events.
Behavioral Analytics:
- Using anomaly detection tools or security information and event management (SIEM) systems to identify unusual IAM activity patterns or anomalous role assumptions.
Identity and Access Management (IAM) Policy Reviews:
- Periodic reviews of IAM policies and roles to identify unauthorized or suspicious changes, overly permissive roles, or newly created roles that do not adhere to established naming conventions or policies.
Monitoring Temporary Credential Usage:
- Tracking the frequency, source, and scope of temporary credentials generated via STS or similar services to detect anomalous or malicious role assumptions.

Specific Indicators of Compromise (IoCs) include:

Creation of roles with overly broad permissions or administrative privileges.
Sudden appearance of roles with naming conventions inconsistent with organizational standards.
Unusual or unauthorized cross-account role assumptions.
High frequency or volume of temporary credential generation events from unusual sources or times.

Why it is Important to Detect This Technique

Detecting Additional Cloud Roles (T1098.003) is crucial for maintaining the security and integrity of cloud environments. Failure to detect and respond promptly can lead to severe consequences, including:

Persistent Unauthorized Access:
- Attackers can maintain long-term stealthy access, making remediation difficult and resource-intensive.
Privilege Escalation:
- Attackers may escalate privileges, gaining administrative or sensitive access to critical cloud resources, data, or applications.
Data Exfiltration and Theft:
- Unauthorized roles may facilitate data exfiltration, intellectual property theft, or exposure of sensitive customer or organizational information.
Financial Impact:
- Attackers may leverage additional roles to provision unauthorized cloud resources, incurring significant financial costs.
Compliance and Regulatory Violations:
- Uncontrolled role creation or modification may lead to breaches of compliance requirements and regulatory standards, resulting in legal, financial, and reputational damage.

Early detection minimizes the damage, reduces remediation costs, and preserves organizational reputation and compliance posture.

Examples

Real-world examples of Additional Cloud Roles (T1098.003) include:

Capital One Data Breach (2019):
- Attackers leveraged compromised AWS credentials to assume roles and access sensitive customer data stored in AWS S3 buckets.
- The attacker created additional roles and assumed them via AWS STS, enabling data exfiltration and unauthorized access to sensitive resources.
- Impact: Exposure of personal information of over 100 million customers, significant financial penalties, and reputational damage.
TeamTNT Cloud Attacks:
- TeamTNT, a threat actor group, targets cloud environments by creating new IAM roles or modifying existing ones to maintain persistence and escalate privileges.
- The group leverages automation scripts and cloud-native CLI tools to rapidly create and assume roles, facilitating lateral movement and cryptojacking activities.
- Impact: Unauthorized resource provisioning, increased cloud costs, and compromised infrastructure stability.
Misconfigured Cross-Account Role Exploitation:
- Attackers exploit improperly configured cross-account IAM roles, assuming roles in multiple accounts within an organization.
- Once assumed, attackers escalate privileges, exfiltrate sensitive data, or launch additional attacks from compromised accounts.
- Impact: Extensive lateral movement, data breaches, and significant remediation efforts.

These examples underline the necessity of robust monitoring, detection, and response capabilities to mitigate threats associated with Additional Cloud Roles (T1098.003).

SSH Authorized Keys

SSH Authorized Keys [T1098.004]

Information

Name: SSH Authorized Keys
ID: T1098.004
Tactics: TA0003, TA0004
Technique: T1098

Introduction

SSH Authorized Keys (T1098.004) is a sub-technique within the MITRE ATT&CK framework under the broader Account Manipulation (T1098) technique. Attackers leverage this method by adding or modifying SSH authorized keys, enabling persistent, passwordless access to compromised Linux or Unix-based systems. This allows adversaries to maintain long-term persistence and evade traditional authentication mechanisms, simplifying lateral movement and further exploitation.

Deep Dive Into Technique

SSH (Secure Shell) provides secure remote login capabilities, typically authenticating users via passwords or cryptographic keys. The authorized_keys file, usually located at ~/.ssh/authorized_keys, contains public keys that grant access without requiring a password.

Attackers exploiting this sub-technique typically follow these steps:

Initial Access:
- Exploit vulnerabilities or stolen credentials to gain initial access to the target system.
- Use existing compromised accounts or escalate privileges to gain write access to the victim user's SSH configuration.
Key Generation and Placement:
- Generate a new SSH key pair (ssh-keygen) on attacker-controlled infrastructure.
- Insert the attacker's public key into the victim user's authorized_keys file, often using commands such as:
  echo "<attacker_public_key>" >> ~/.ssh/authorized_keys
- Alternatively, attackers may overwrite existing keys or modify permissions to avoid suspicion.
Persistence and Access:
- Once the public key is in place, attackers can log in remotely without providing passwords, bypassing traditional authentication logging.
- Attackers may modify file permissions (chmod 600 authorized_keys) and timestamps (touch -r) to mask their activity.
Privilege Escalation and Lateral Movement:
- Attackers may escalate privileges by compromising administrative or root accounts.
- Attackers can propagate their keys across multiple systems, enabling lateral movement.

When this Technique is Usually Used

Attackers commonly employ SSH Authorized Keys manipulation in various attack scenarios and stages, including:

Persistence:
- Maintaining long-term, stealthy access to compromised systems after initial intrusion.
- Avoiding repeated exploitation or credential reuse, reducing detection probability.
Lateral Movement:
- Propagating access across multiple compromised hosts within the network.
- Simplifying lateral movement by eliminating the need to repeatedly authenticate with passwords.
Privilege Escalation:
- Gaining root or administrative-level access by inserting keys into privileged user accounts.
- Facilitating future privilege escalation attempts and simplifying administrative access.
Data Exfiltration and Command-and-Control (C2):
- Establishing secure, encrypted channels for data exfiltration or command-and-control operations.
- Reducing detection risks by leveraging legitimate SSH traffic.

How this Technique is Usually Detected

Detecting unauthorized modifications to SSH authorized keys involves monitoring various indicators and employing multiple detection methods, including:

File Integrity Monitoring (FIM):
- Monitoring changes to critical files such as ~/.ssh/authorized_keys.
- Tools: OSSEC, Tripwire, AIDE, Auditd.
Audit Logging and Alerts:
- Enabling audit logging to track file modifications (auditd rules for authorized_keys).
- Example audit rule:
  -w /home/*/.ssh/authorized_keys -p wa -k ssh_key_modification
- Monitoring alerts for unauthorized file edits or unexpected SSH key additions.
Behavioral Analytics and Anomaly Detection:
- Identifying unusual SSH login patterns, such as logins from unfamiliar IP addresses or at unusual times.
- Using SIEM solutions (Splunk, ELK Stack, QRadar) to correlate SSH login events with authorized_keys changes.
Host-based Detection:
- Regularly scanning authorized_keys files for unfamiliar or unauthorized public keys.
- Comparing current keys against a known whitelist or baseline.
Network Traffic Monitoring:
- Monitoring network traffic for unusual SSH sessions or data exfiltration attempts.
- Identifying SSH connections to external, unknown, or suspicious IP addresses.

Indicators of Compromise (IoCs):

Unrecognized public keys in authorized_keys.
Unauthorized file permission changes on .ssh directories or authorized_keys files.
SSH logins from unknown or suspicious IP addresses.
Unusual SSH login times and frequencies.

Why it is Important to Detect This Technique

Identifying SSH Authorized Keys manipulation early is critical due to its severe potential impacts, including:

Persistent Unauthorized Access:
- Attackers gain persistent, stealthy access, making remediation challenging.
- Unauthorized access may persist even after password changes or account lockouts.
Privilege Escalation and Administrative Control:
- Attackers can escalate privileges by inserting keys into privileged accounts, significantly increasing their control over systems and networks.
Data Exfiltration and Intellectual Property Theft:
- Attackers can exfiltrate sensitive data securely and stealthily via encrypted SSH channels, causing significant financial and reputational damage.
Lateral Movement and Network Compromise:
- Attackers can propagate their access across multiple systems, increasing the scope and severity of breaches.
- Networks can become extensively compromised, complicating containment and remediation efforts.
Evasion of Traditional Security Controls:
- SSH key-based authentication bypasses traditional password-based monitoring and detection mechanisms, making unauthorized access harder to detect.

Early detection helps minimize damage, reduces remediation costs, and prevents attackers from establishing long-term footholds.

Examples

Real-world examples demonstrating the use of SSH Authorized Keys manipulation include:

APT29 (Cozy Bear):
- Russian state-sponsored group known to use SSH keys for persistent access.
- Attackers inserted their own SSH keys into compromised systems to maintain long-term access and evade detection.
- Impact: Persistent espionage, theft of sensitive government and commercial information.
Operation Windigo:
- Large-scale Linux malware campaign that compromised thousands of servers.
- Attackers inserted malicious SSH keys into authorized_keys files for persistent access and lateral movement.
- Impact: Spam distribution, credential theft, malware hosting, and extensive network compromise.
Cloud Hopper Campaign (APT10):
- Chinese state-sponsored attackers compromised managed service providers (MSPs).
- Attackers manipulated SSH authorized keys to persistently access client networks and systems.
- Impact: Intellectual property theft, sensitive data exfiltration, extensive supply-chain compromise.
Crypto-mining Campaigns:
- Attackers compromised Linux servers and cloud resources, inserting SSH keys to maintain persistent access.
- Used persistent access to deploy crypto-mining malware, causing resource exhaustion and financial losses.

These examples highlight the widespread use and significant impact of SSH Authorized Keys manipulation in real-world attacks, emphasizing the importance of robust detection and prevention measures.

Device Registration

Device Registration [T1098.005]

Information

Name: Device Registration
ID: T1098.005
Tactics: TA0003, TA0004
Technique: T1098

Introduction

Device Registration (T1098.005) is a sub-technique within the MITRE ATT&CK framework under the broader "Account Manipulation" technique (T1098). It involves adversaries registering unauthorized devices or systems within an organization's network or cloud environment, thereby gaining persistent access and evading detection. By registering malicious or compromised devices, attackers can blend in with legitimate infrastructure, making their activities appear normal and authorized. This sub-technique is commonly leveraged to establish persistence, maintain stealth, and facilitate lateral movement within targeted environments.

Deep Dive Into Technique

Adversaries exploit device registration by adding unauthorized endpoints or virtual devices into legitimate management systems, Active Directory (AD), Azure AD, or other identity and access management (IAM) systems. This registration can be performed via various methods:

Manual Registration: Attackers with sufficient privileges manually add compromised or attacker-controlled devices into the organization's directory services or endpoint management solutions.
Automated Scripted Registration: Attackers may use automated scripts or command-line tools such as PowerShell, Azure CLI, or specialized APIs to rapidly register multiple devices, thereby scaling their access.
Compromise of Device Enrollment Credentials: Attackers may obtain legitimate device enrollment credentials or tokens through credential theft, phishing, or social engineering, allowing them to register devices without raising immediate alarms.
Use of Stolen or Forged Certificates: Attackers may use compromised or forged certificates to authenticate and register malicious devices, bypassing standard device authentication checks.

Once registered, these devices may:

Appear legitimate to endpoint management platforms such as Microsoft Intune, SCCM, Jamf, or Mobile Device Management (MDM) solutions.
Gain access to sensitive resources, applications, or data within the environment.
Facilitate lateral movement and allow attackers to pivot to other systems or escalate privileges.
Remain persistent and evade standard detection mechanisms due to their authorized and legitimate appearance.

When this Technique is Usually Used

Device Registration (T1098.005) is typically employed during specific stages of a cyberattack lifecycle, including:

Persistence Stage: Attackers leverage device registration to maintain a foothold within compromised environments, ensuring continued access even after initial entry points are identified and remediated.
Privilege Escalation and Defense Evasion: By registering devices as legitimate endpoints, attackers can evade detection mechanisms, bypass network segmentation controls, and escalate privileges by blending into trusted device groups.
Lateral Movement: Once a device is registered and trusted, attackers can pivot internally, accessing resources and systems that rely on device trust relationships.
Post-Compromise Expansion: After initial access, attackers may register additional malicious devices to expand their presence within the compromised network or cloud environment.

Common scenarios include:

Cloud-based attacks targeting Azure AD or other cloud IAM solutions.
Enterprise environments relying heavily on endpoint management platforms (Intune, Jamf, SCCM).
Organizations using automated provisioning and device enrollment processes that attackers can exploit.

How this Technique is Usually Detected

Detection of unauthorized device registration requires careful monitoring, auditing, and correlation of identity-related events. Common detection methods include:

Endpoint and Device Inventory Audits: Regular audits and automated inventory checks can identify newly registered devices that do not match known device naming conventions, hardware specifications, or enrollment patterns.
Log Analysis and SIEM Monitoring: Aggregation and analysis of logs from directory services (Active Directory, Azure AD), endpoint management platforms (Intune, SCCM), and certificate authorities can reveal suspicious registration activities.
Behavioral Analytics: Machine learning and behavioral analytics tools can identify abnormal patterns, such as sudden bursts of new device registrations, unusual geographic locations, or atypical enrollment times.
Monitoring of Enrollment Tokens and Certificates: Tracking the usage of device enrollment tokens, certificates, and credentials can help detect unauthorized or unexpected registrations.
Alerts on Privileged Account Activity: Monitoring privileged accounts or service accounts that can register devices can highlight unauthorized or suspicious device registration activities.

Specific Indicators of Compromise (IoCs) include:

Unrecognized device names, hardware identifiers, or serial numbers.
Device registrations originating from unusual geographic locations or IP addresses.
Sudden spikes in device enrollment activities.
Usage of compromised or suspicious certificates or tokens.
Devices enrolled by accounts not typically associated with device registration.

Why it is Important to Detect This Technique

Detecting unauthorized device registration is critical due to its significant potential impacts on organizations, including:

Persistence and Long-Term Access: Attackers can use registered devices to maintain persistent, long-term access to sensitive data and systems, even after initial compromise points are remediated.
Privilege Escalation and Lateral Movement: Registered devices can bypass security controls, facilitating attackers' lateral movement and privilege escalation within the network.
Data Exfiltration Risk: Attackers can leverage registered devices to access, exfiltrate, or manipulate sensitive data, leading to significant data breaches and compliance violations.
Operational Disruption and Business Impact: Unauthorized device registration can disrupt legitimate device and endpoint management processes, causing operational inefficiencies or downtime.
Increased Detection Difficulty: Devices registered through legitimate channels can evade traditional detection mechanisms, highlighting the importance of proactive detection and monitoring strategies.

Early detection enables organizations to:

Rapidly identify and isolate unauthorized devices.
Minimize the scope and impact of potential breaches.
Strengthen overall security posture by improving visibility and control over device enrollment processes.

Examples

Real-world examples and scenarios involving Device Registration (T1098.005):

SolarWinds Compromise: Attackers leveraged compromised identities and credentials to register unauthorized devices within Azure AD environments. Once registered, these devices facilitated lateral movement, persistence, and data exfiltration.
- Tools and Techniques Used: Azure Active Directory PowerShell modules, compromised credentials, and automated scripting.
- Impacts: Long-term persistence, lateral movement, and sensitive data exfiltration impacting multiple high-profile organizations.
APT29 (Cozy Bear) Activities: Known to compromise cloud infrastructure and leverage device registration to maintain persistent access to targeted environments.
- Tools and Techniques Used: Credential harvesting, Azure CLI, PowerShell scripting, and forged certificates.
- Impacts: Persistent espionage activities, sensitive data theft, and significant operational disruption.
Compromised Mobile Device Management (MDM) Platforms: Attackers have registered malicious devices within enterprise MDM solutions, enabling persistent access to sensitive corporate data and applications.
- Tools and Techniques Used: Compromised enrollment tokens, phishing attacks, and unauthorized device enrollment scripts.
- Impacts: Data breaches, unauthorized access to corporate applications, and prolonged attacker presence within enterprise environments.

These examples underscore the critical importance of monitoring and securing device registration processes to mitigate this sub-technique's risks and impacts.

Additional Container Cluster Roles

Additional Container Cluster Roles [T1098.006]

Information

Name: Additional Container Cluster Roles
ID: T1098.006
Tactics: TA0003, TA0004
Technique: T1098

Introduction

The MITRE ATT&CK sub-technique Additional Container Cluster Roles (T1098.006) refers to adversaries exploiting or creating additional roles within container orchestration environments, primarily Kubernetes, to gain elevated privileges or maintain persistence. By manipulating cluster role definitions and bindings, attackers can escalate privileges, access sensitive resources, or create persistent backdoors within containerized infrastructures.

Deep Dive Into Technique

In Kubernetes and similar container orchestration platforms, roles define permissions for resources within namespaces, while cluster roles grant permissions across the entire cluster. Attackers targeting this sub-technique typically perform the following actions:

Enumeration of Existing Roles and Bindings: Adversaries initially enumerate existing cluster roles and role bindings to understand their permissions and identify potential weaknesses or overly permissive roles.
```
kubectl get clusterroles
kubectl get clusterrolebindings
```

Creation of Malicious Cluster Roles: Attackers create new cluster roles or modify existing ones to include excessive privileges, such as administrative-level access to secrets, pods, services, nodes, or the ability to execute arbitrary commands.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: malicious-clusterrole
rules:
  - apiGroups: [""]
    resources: ["pods", "secrets", "services"]
    verbs: ["get", "list", "watch", "create", "delete", "update"]

Binding Malicious Roles to Service Accounts or Users: After creating or modifying roles, adversaries bind them to compromised or attacker-controlled service accounts or user accounts, enabling persistent and stealthy access.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: malicious-binding
subjects:
  - kind: ServiceAccount
    name: compromised-account
    namespace: default
roleRef:
  kind: ClusterRole
  name: malicious-clusterrole
  apiGroup: rbac.authorization.k8s.io

Privilege Escalation and Persistence: With these additional roles and bindings, attackers can escalate privileges, access sensitive data, deploy malicious workloads, and maintain persistence within the Kubernetes cluster.
Stealth and Obfuscation Techniques: Attackers may use generic or misleading names for the created roles and bindings to blend in with legitimate administrative tasks, complicating detection efforts.

When this Technique is Usually Used

Adversaries commonly use this technique in various stages of the attack lifecycle:

Privilege Escalation: Attackers who have gained initial footholds with limited privileges may create or modify cluster roles to escalate permissions and gain administrative control.
Persistence: Attackers establish persistent access by binding malicious roles to compromised or attacker-controlled accounts, ensuring long-term access to the cluster.
Lateral Movement: Additional roles can grant attackers permissions to access resources across namespaces, facilitating lateral movement within the containerized environment.
Data Exfiltration: Attackers leverage elevated permissions to access sensitive data such as secrets, configuration files, or databases for exfiltration purposes.
Impact and Disruption: Elevated privileges allow attackers to disrupt or manipulate workloads, services, and nodes, potentially leading to denial-of-service or sabotage scenarios.

How this Technique is Usually Detected

Detection of unauthorized or malicious cluster roles and bindings involves multiple approaches:

Monitoring Kubernetes Audit Logs: Audit logs capture API requests, including creation or modification of cluster roles and bindings. Look for unusual or unexpected role creation events, especially those performed by unfamiliar or unexpected user accounts or service accounts.
Role and Binding Enumeration and Baseline Comparison: Regularly enumerate existing cluster roles and bindings and compare them against secure baselines to identify unauthorized additions or modifications.
Behavioral Anomaly Detection: Security tools and platforms designed for Kubernetes (e.g., Falco, Sysdig, Aqua Security, Prisma Cloud) can detect anomalous role creation activities and alert security teams.
Indicators of Compromise (IoCs):
- Unexpected cluster role or binding creations.
- Cluster roles granting overly broad permissions (e.g., "*" verbs on sensitive resources).
- Role bindings associating unknown or suspicious service accounts or user accounts.
- Kubernetes audit log entries showing role creation or modification from unknown IP addresses or at unusual times.
Security Information and Event Management (SIEM) Integration: Integrating Kubernetes audit logs and security events into SIEM solutions (e.g., Splunk, Elastic Stack, QRadar) enables correlation and alerting on suspicious role-related activities.

Why it is Important to Detect This Technique

Detecting unauthorized additional cluster roles is critical to maintaining the security and stability of containerized environments:

Prevent Privilege Escalation: Early detection prevents attackers from escalating privileges and gaining administrative control over Kubernetes clusters.
Limit Data Exposure and Exfiltration: Attackers with elevated permissions may access sensitive data, including secrets, credentials, and confidential information, leading to significant data breaches.
Avoid Persistent Threats: Identifying malicious roles and bindings early prevents attackers from establishing persistent backdoors, reducing long-term risk and remediation complexity.
Protect Operational Stability: Unauthorized roles could enable attackers to disrupt critical workloads, manipulate configurations, or cause denial-of-service, jeopardizing cluster stability and availability.
Compliance and Regulatory Requirements: Timely detection and response to unauthorized access and privilege escalation activities are often mandated by security standards and regulations (e.g., PCI DSS, HIPAA, GDPR).

Examples

TeamTNT Attacks on Kubernetes Clusters:
- Attack Scenario: TeamTNT, a threat actor group, compromised Kubernetes clusters by exploiting misconfigured APIs and service accounts. They created additional cluster roles granting administrative privileges to deploy crypto-mining workloads.
- Tools and Techniques: Automated scripts to enumerate roles, create malicious bindings, and deploy crypto-mining containers.
- Impact: Resource hijacking, increased cloud bills, and potential lateral movement within cloud environments.
Hildegard Malware Campaign:
- Attack Scenario: Hildegard malware targeted Kubernetes clusters by exploiting vulnerable APIs and creating malicious cluster roles to escalate privileges and deploy crypto-mining operations.
- Tools and Techniques: Leveraging Kubernetes API access to create cluster roles with broad permissions, deploying malicious containers, and hiding activities through obfuscated naming conventions.
- Impact: Unauthorized resource consumption, degraded cluster performance, and potential access to sensitive data.
Tesla Kubernetes Breach (Cryptojacking Incident):
- Attack Scenario: Attackers gained access to Tesla's Kubernetes dashboard due to misconfigured access controls. They created additional cluster roles and deployed crypto-mining containers within the cluster.
- Tools and Techniques: Exploitation of misconfigured Kubernetes dashboard, creation of additional cluster roles, deployment of cryptojacking workloads.
- Impact: Unauthorized resource usage, increased cloud costs, and reputational damage.

These examples illustrate the real-world implications of attackers exploiting Additional Container Cluster Roles (T1098.006), highlighting the necessity of vigilant monitoring, detection, and prevention measures.

Additional Local or Domain Groups

Additional Local or Domain Groups [T1098.007]

Information

Name: Additional Local or Domain Groups
ID: T1098.007
Tactics: TA0003, TA0004
Technique: T1098

Introduction

The MITRE ATT&CK sub-technique "Additional Local or Domain Groups" (T1098.007) falls under the broader technique of Account Manipulation (T1098). It refers to adversaries creating or modifying local or domain groups within a compromised environment to maintain persistence, escalate privileges, or facilitate lateral movement. Attackers leverage these groups to blend in with normal administrative activities, making detection challenging. Understanding this sub-technique is essential for defenders to recognize unauthorized alterations to group accounts and mitigate potential threats.

Deep Dive Into Technique

Attackers performing this sub-technique typically follow these technical steps:

Local Group Creation or Modification:
- Attackers may create or modify local groups on compromised endpoints to establish persistence and maintain control.
- Using built-in utilities such as net.exe, net localgroup, or PowerShell cmdlets (New-LocalGroup, Add-LocalGroupMember), attackers can silently establish new groups or add compromised accounts to existing groups.
Domain Group Creation or Modification:
- Attackers with domain admin privileges or sufficient permissions may create new domain groups or modify existing ones to facilitate lateral movement and privilege escalation across the domain.
- Common tools and techniques include Active Directory Users and Computers (ADUC), PowerShell AD cmdlets (e.g., New-ADGroup, Add-ADGroupMember), or direct LDAP queries and modifications.
Group Nesting and Privilege Escalation:
- Adversaries may nest groups strategically to inherit permissions from higher-privileged groups, thus indirectly escalating privileges without attracting immediate attention.
- Attackers could add their compromised accounts to existing privileged groups such as "Domain Admins," "Enterprise Admins," or custom administrative groups.
Persistence and Stealth:
- Creating additional groups allows attackers to maintain persistent access even if individual compromised accounts are discovered and disabled.
- Attackers often use innocuous-sounding group names or mimic legitimate administrative groups to avoid suspicion.

When this Technique is Usually Used

Attackers employ "Additional Local or Domain Groups" in various stages and scenarios, including:

Privilege Escalation:
- Attackers add compromised accounts to privileged groups or create new groups with high-level privileges to escalate their access rights.
Persistence:
- Creating or modifying groups ensures persistent access, even if initial compromised accounts are disabled or passwords changed.
Lateral Movement:
- Domain groups provide attackers the means to move laterally across multiple systems within the domain, leveraging inherited permissions and trust relationships.
Credential Access and Reconnaissance:
- Attackers may use group memberships to enumerate additional targets, gather credentials, or identify sensitive assets within Active Directory environments.
Defense Evasion:
- Attackers create or modify groups with names similar to legitimate administrative groups to blend in and evade detection by security teams.

How this Technique is Usually Detected

Detection of "Additional Local or Domain Groups" typically involves monitoring, auditing, and analyzing group membership changes and creation events:

Event Log Monitoring:
- Windows Security Event Logs, especially Event IDs:
  - 4727: A security-enabled global group was created.
  - 4731: A security-enabled local group was created.
  - 4754: A security-enabled universal group was created.
  - 4728, 4732, 4756: Members were added to security-enabled groups.
- Regular monitoring and alerting on these events can help identify suspicious group activity.
Audit Policies and SIEM Solutions:
- Implement advanced audit policies to log group creation and membership changes.
- Centralize log aggregation and correlation using SIEM solutions (e.g., Splunk, ELK, QRadar) to detect unusual patterns or anomalies.
Active Directory Monitoring Tools:
- Utilize specialized Active Directory monitoring tools (e.g., Microsoft Defender for Identity, BloodHound, PingCastle) to detect unusual group nesting or privilege escalation paths.
Endpoint Detection and Response (EDR):
- EDR solutions can detect suspicious command-line activities (e.g., net localgroup, PowerShell cmdlets) indicative of unauthorized group manipulation.
Indicators of Compromise (IoCs):
- Unrecognized or newly created administrative groups.
- Unexpected additions of standard user accounts into privileged groups.
- Suspicious PowerShell scripts or command-line arguments related to group management.

Why it is Important to Detect This Technique

Early detection of "Additional Local or Domain Groups" is critical due to the following potential impacts:

Privilege Escalation Risks:
- Attackers who successfully manipulate groups can escalate privileges, gaining administrative or system-level access, and significantly increasing their potential damage and control.
Persistence and Long-Term Compromise:
- Attackers can maintain persistent access through group memberships, even after initial compromised accounts are remediated, resulting in prolonged threats within the environment.
Lateral Movement and Wider Compromise:
- Unauthorized domain group modifications enable attackers to move laterally across multiple systems, potentially compromising critical infrastructure, sensitive data, and intellectual property.
Evasion of Detection and Defense Mechanisms:
- Attackers who blend into legitimate administrative groups or mimic standard naming conventions may evade detection and continue malicious activities unnoticed.
Compliance and Regulatory Risks:
- Unauthorized group changes may lead to compliance violations, audit failures, and regulatory penalties.

Examples

Real-world examples demonstrating the use of "Additional Local or Domain Groups" include:

APT29 (Cozy Bear):
- During the SolarWinds supply chain compromise, APT29 leveraged domain administrative privileges to create new Active Directory groups and add compromised accounts, enabling lateral movement and persistence across victim networks.
FIN6 Group:
- FIN6 attackers have been observed creating new local administrative groups on compromised point-of-sale (POS) systems, allowing persistent access and facilitating further data exfiltration activities.
Ryuk Ransomware Attacks:
- Attackers deploying Ryuk ransomware frequently manipulate domain groups, adding compromised accounts into privileged groups to spread ransomware rapidly across victim organizations.
PowerSploit Framework:
- Attackers leveraging PowerSploit scripts often use PowerShell cmdlets (New-ADGroup, Add-ADGroupMember) to create and modify domain groups silently, establishing persistent and privileged access.
TrickBot Malware:
- TrickBot operators have been known to enumerate and modify local group memberships using built-in Windows utilities (net localgroup) to escalate privileges and maintain persistence on compromised endpoints.

These examples highlight the importance of monitoring and detecting unauthorized group creation or modifications to mitigate risks associated with this sub-technique.