Detecting Linux Credential Access Attacks with Wazuh
In this blog, we will see the process of how to detect the credential access attacks on Linux endpoints using Wazuh. Credential access attacks target various sensitive information like browser data, password managers, SSH keys, and hashed passwords. To counteract these threats, we utilize Wazuh, a comprehensive security monitoring platform. This guide will walk you through the prerequisites, configurations, and practical steps needed to detect such attacks.
Prerequisites:
To detect credential access attacks with Wazuh, you’ll need the following:
Informative section for use-case understanding
Practical Steps
Configuring the Ubuntu Endpoint
We configure the Ubuntu endpoint to detect offline credential file access and use Auditd to log CLI commands for identifying potential malicious activity.
To set this up, install Auditd and create the required audit rules as follows:
Step 1: Install, start, and enable Auditd if it is not already present on the system:
This command installs auditd, the audit daemon, and audispd-plugins, which are plugins for the audit daemon. The -y flag automatically answers ‘yes’ to prompts, ensuring a smooth installation without user intervention. Once started, auditd begins monitoring and logging system activities as per the configured rules.
apt -y install auditd audispd-plugins
systemctl start auditd
systemctl enable auditd
Step 2: Run the following command to append audit rules to the /etc/audit/rules.d/audit.rules file:
The EOF is a marker that signifies the beginning and end of the text block. Appending audit rules to the /etc/audit/rules.d/audit.rules file.
cat << EOF >> /etc/audit/rules.d/audit.rules
-a exit,always -F arch=b64 -F auid!=-1 -F euid!=0 -S execve -k audit-wazuh-c
-a exit,always -F arch=b64 -F path=/etc/shadow -F auid!=-1 -F euid!=0 -F perm=r -k shadow_access
-a exit,always -F arch=b64 -F path=/etc/passwd -F auid!=-1 -F euid!=0 -F perm=r -k passwd_access
-a exit,always -F arch=b64 -F path=/<USER_HOME_DIRECTORY>/.bash_history -F auid!=-1 -F euid!=0 -F perm=r -k history_access
-a exit,always -F arch=b64 -F dir=/<USER_HOME_DIRECTORY>/.ssh/ -F auid!=-1 -F euid!=0 -F perm=r -k ssh_access
EOF
Informative Section: Here’s a breakdown of the audit rule configuration:
-a exit,always: This rule applies to the end of a syscall and is always active.
-F auid!=-1: The rule doesn’t apply to processes where the Audit User ID is -1, which usually means the process isn’t tied to a user (like kernel threads or early boot processes).
-F arch=b64: The rule is for 64-bit syscalls. For 32-bit, use arch=b32.
-S execve: Audits the execve syscall, which logs every program execution.
-k audit-wazuh-c: Tags the audit logs with audit-wazuh-c for easier searching and analysis.
-F perm=r: The rule applies to read operations.
-F euid!=0: Targets events where the effective user ID isn’t 0 (root).
-F path: Specifies the full path to the file you want to monitor. Replace <USER_HOME_DIRECTORY> with the specific user’s home directory for tracking bash history and SSH file access.
Step 3: Reload the rules and confirm that they are in place:
“-R — Reloads the audit rules from the specified file” “-L — Lists the currently active audit rules”
sudo auditctl -R /etc/audit/rules.d/audit.rules
sudo auditctl -l
Step 4: Append the following configuration to the Wazuh agent /var/ossec/etc/ossec.conf file. This allows the Wazuh agent to read the auditd log file:
This XML snippet configures the Wazuh agent to monitor the audit log file located at /var/log/audit/audit.log. It specifies that the log format is “audit,” enabling the Wazuh agent to interpret and process audit events from this file. By including this configuration, the Wazuh agent can analyze audit logs for security monitoring and threat detection purposes.
<ossec_config>
<localfile>
<log_format>audit</log_format>
<location>/var/log/audit/audit.log</location>
</localfile>
</ossec_config>
Step 5: Restart the Wazuh agent service to apply the configurations:
sudo systemctl restart wazuh-agent
Configuring the Wazuh Server — (RHEL)
Step 1: Update the /var/ossec/etc/lists/audit-keys CDB list with the custom audit key: This command appends key-value pairs to the /var/ossec/etc/lists/audit-keys file using a heredoc. It adds four entries: passwd_access:passwd, shadow_access:shadow, history_access:history, and ssh_access:ssh. These pairs are used to label and identify specific audit events related to accessing the /etc/passwd, /etc/shadow, and ~/.bash_history files, as well as the ~/.ssh directory, facilitating easier search and analysis of audit logs in Wazuh.
cat << EOF >> /var/ossec/etc/lists/audit-keys
passwd_access:passwd
shadow_access:shadow
history_access:history
ssh_access:ssh
EOF
To check if the command is proper or not do ‘nano /var/ossec/etc/lists/audit-keys’
Recommended by LinkedIn
Step 2: Add the following rules to the /var/ossec/etc/rules/local_rules.xml file to generate alerts on the Wazuh Whenever an attacker performs any of the attacks mentioned below, these rules will get triggered and alert will be shown.
<group name=”cred_access,”>
<! — Detect access to offline password storing files →
<rule id=”100110" level=”7">
<if_sid>80700</if_sid>
<list field=”audit.key” lookup=”match_key_value” check_value=”passwd”>etc/lists/audit-keys</list>
<description>File access — The file $(audit.file.name) was accessed</description>
<group>audit_command,</group>
<mitre>
<id>T1003.008</id>
</mitre>
</rule>
<rule id=”100120" level=”10">
<if_sid>80700</if_sid>
<list field=”audit.key” lookup=”match_key_value” check_value=”shadow”>etc/lists/audit-keys</list>
<description>Possible adversary activity — $(audit.file.name) was accessed</description>
<group>audit_command,</group>
<mitre>
<id>T1003.008</id>
</mitre>
</rule>
<! — Detecting suspicious activities related to unsecured credentials →
<rule id=”100131" level=”0">
<if_sid>80700</if_sid>
<list field=”audit.key” lookup=”match_key_value” check_value=”ssh”>etc/lists/audit-keys</list>
<description>Possible adversary activity — $(audit.file.name) was accessed</description>
<group>audit_command,</group>
</rule>
<rule id=”100132" level=”0">
<if_sid>80700</if_sid>
<list field=”audit.key” lookup=”match_key_value” check_value=”history”>etc/lists/audit-keys</list>
<description>Possible adversary activity — $(audit.file.name) was accessed</description>
<group>audit_command,</group>
</rule>
<rule id=”100133" level=”0">
<if_sid>80700</if_sid>
<field name=”audit.exe” type=”pcre2">/usr/bin/*grep</field>
<field name=”audit.execve.a2">cred|password|login</field>
<description>Possible adversary activity — $(audit.file.name) was accessed</description>
<group>audit_command,</group>
</rule>
<rule id=”100130" level=”10">
<if_sid>100131, 100132, 100133</if_sid>
<description>Possible adversary activity — searching for previously used credentials in system files</description>
<group>audit_command,</group>
<mitre>
<id>T1552.001</id>
</mitre>
</rule>
</group>
Informative Section:
· Rule ID 100110 is triggered whenever there is a read access attempt on the /etc/passwd file.
· Rule ID 100120 is triggered whenever there is a read access attempt on the /etc/shadow file.
· Rule ID 100131 is triggered when a read process is run on the bash_history file.
· Rule ID 100132 is triggered when a read process is run on the files in the .ssh directory.
· Rule ID 100133 is triggered when a grep process on .ssh directories, or bash_history for certain keywords is recorded.
· Rule ID 100130 is triggered when rule IDs 100131, 100132, and 100133 are triggered. This indicates searching for credentials in .ssh directories, or inspecting bash_history for previously used credentials.
Note: Depending on the different services installed on your monitored endpoint, rule ID 100110 is susceptible to fire several alerts upon a system reboot and login of users. This is because some of these applications need to authenticate the user hence reads the /etc/passwd file.
Step 3: Restart the Wazuh manager to apply the configuration changes:
systemctl restart wazuh-manager
Configuring the Wazuh Agent
Step 1: Navigate to the ‘Endpoints’ section and choose “Deploy New Agents.” Step 2: Select the DEB amd64 option and provide the server address (the name of your Ubuntu machine) Step 3: Execute the provided command on your Ubuntu (agent) machine with root privileges. Step 4: Execute the provided command on your Ubuntu (agent) machine with root privileges.
Output:
Triggering the Attack
Step 1: Triggering the rule id 100110 using John tool. Rule ID 100110 is triggered whenever there is a read access attempt on the /etc/passwd file. We will be using john tool to perform this attack.
sudo apt install john
john /usr/share/john/password.lst
Step 2: Triggering 100120 Rule ID 100120 is triggered whenever there is a read access attempt on the /etc/shadow file. Ls -ll /etc/shadow
Step 3: Triggering 100130 using hashcat Rule ID 100130 is triggered when rule IDs 100131, 100132, and 100133 are triggered. This indicates searching for credentials in .ssh directories, or inspecting bash_history for previously used credentials.
Detection results
The screenshot below shows the alerts generated on the Wazuh dashboard when we simulate the malicious activities related to credential access attacks on the victim endpoints. From the Wazuh dashboard, Navigate to Threat hunting to view the generated alerts.
If the events are not directly visible:
1. Click + Add filter. Then filter for rule.id in the Field field.
2. Filter for is one of in the Operator field.
3. Filter for 100110, 100120, and 100130 in the Values field.
4. Click Save.
I understand this article became too long, but these steps on using Wazuh to catch credential thieves on Linux are super valuable. Give it a try hands-on — that’s the best way to learn! If you hit any snags, just shoot me a message. Happy hunting and keep those systems secure!
SysAdmin SR - DevSecOps Team at Urbetrack
3moExcellent post! 👏👏👏
That's a perfect read, Aastha!
LinkedIn 15x Top Voice l Freelancer l Graphic Design l Branding Designer | Creative Lead at @TheHackersMeetup
4moGreat job, Aastha! Your guide on detecting Linux credential access attacks using Wazuh is incredibly insightful and beneficial for the cybersecurity community. Your expertise in this area shines through, and I appreciate the value you're adding with such comprehensive content. Keep up the fantastic work!