T1562
Impair Defenses
Description from ATT&CK
Adversaries may maliciously modify components of a victim environment in order to hinder or disable defensive mechanisms. This not only involves impairing preventative defenses, such as firewalls and anti-virus, but also detection capabilities that defenders can use to audit activity and identify malicious behavior. This may also span both native defenses as well as supplemental capabilities installed by users and administrators.
Adversaries may also impair routine operations that contribute to defensive hygiene, such as blocking users from logging out, preventing a system from shutting down, or disabling or modifying the update process. Adversaries could also target event aggregation and analysis mechanisms, or otherwise disrupt these procedures by altering other system components. These restrictions can further enable malicious operations as well as the continued propagation of incidents.(Citation: Google Cloud Mandiant UNC3886 2024)(Citation: Emotet shutdown)
Atomic Tests
Atomic Test #1 - Windows Disable LSA Protection
The following Atomic adds a registry entry to disable LSA Protection.
The LSA controls and manages user rights information, password hashes and other important bits of information in memory. Attacker tools, such as mimikatz, rely on accessing this content to scrape password hashes or clear-text passwords. Enabling LSA Protection configures Windows to control the information stored in memory in a more secure fashion - specifically, to prevent non-protected processes from accessing that data. Upon successful execution, the registry will be modified and RunAsPPL will be set to 0, disabling Lsass protection. https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection#how-to-disable-lsa-protection https://blog.netwrix.com/2022/01/11/understanding-lsa-protection/ https://thedfirreport.com/2022/03/21/phosphorus-automates-initial-access-using-proxyshell/
Supported Platforms: windows
auto_generated_guid: 40075d5f-3a70-4c66-9125-f72bee87247d
Inputs:
None
Attack Commands: Run with command_prompt! Elevation Required (e.g. root or admin)
1
reg add HKLM\SYSTEM\CurrentControlSet\Control\LSA /v RunAsPPL /t REG_DWORD /d 0 /f
Cleanup Commands:
1
reg delete HKLM\SYSTEM\CurrentControlSet\Control\LSA /v RunAsPPL /f >nul 2>&1
Atomic Test #2 - Disable journal logging via systemctl utility
The atomic test disables the journal logging using built-in systemctl utility
Supported Platforms: linux
auto_generated_guid: c3a377f9-1203-4454-aa35-9d391d34768f
Inputs:
None
Attack Commands: Run with sh! Elevation Required (e.g. root or admin)
1
sudo systemctl stop systemd-journald #disables journal logging
Cleanup Commands:
1
2
sudo systemctl start systemd-journald #starts journal service
sudo systemctl enable systemd-journald #starts journal service automatically at boot time
Atomic Test #3 - Disable journal logging via sed utility
The atomic test disables the journal logging by searching and replacing the "Storage" parameter to "none" within the journald.conf file, thus any new journal entries will only be temporarily available in memory and not written to disk
Supported Platforms: linux
auto_generated_guid: 12e5551c-8d5c-408e-b3e4-63f53b03379f
Inputs:
None
Attack Commands: Run with sh! Elevation Required (e.g. root or admin)
1
sudo sed -i 's/Storage=auto/Storage=none/' /etc/systemd/journald.conf
Cleanup Commands:
1
2
sudo sed -i 's/Storage=none/Storage=auto/' /etc/systemd/journald.conf #re-enables storage of journal data
sudo systemctl restart systemd-journald #restart the journal service