Credential access attacks are cyber attacks that aim to obtain users’ login credentials. These credentials can include usernames, passwords, security tokens, or other authentication information. They remain one of the critical security threats for organizations. It enables adversaries to gain unauthorized access to systems, facilitating lateral movement and privilege escalation within the targeted environment. This stealthy approach makes it easier for attackers to achieve their objectives while evading detection.

To effectively detect and respond to credential access attacks on Linux systems, organizations should implement a robust security monitoring system to check for abnormal behaviors. In this blog post, we demonstrate how to detect the following credential attack techniques:

  • Offline password cracking
  • Unsecured credential access

Infrastructure

We use the following infrastructure to demonstrate the detection of credential access attacks with Wazuh.

  • A pre-built, ready-to-use Wazuh OVA 4.8.0. Follow this guide to download the virtual machine (VM). This VM hosts the Wazuh central components (Wazuh server, Wazuh indexer, and Wazuh dashboard).
  • A Linux victim endpoint running Ubuntu 22.04  with Wazuh agent 4.8.0 installed and enrolled to the Wazuh server. To install the Wazuh agent, refer to the Wazuh agent installation guide for Linux. 

Credential access attack techniques

The possible targets for adversaries on Linux endpoints include but are not limited to:

  • Browsers
  • Password managers
  • Hash dump (which also requires offline cracking)
  • SSH keys

1. Offline password cracking

Offline password cracking is a technique used by security professionals and attackers to recover passwords from hashed or encrypted files without actively interacting with the target system.

This method focuses on acquiring password hashes stored on system files, such as etc/passwd and etc/shadow. Attackers will then attempt to crack them using brute-force or dictionary attacks on a separate endpoint. 

Detection for this technique focuses on monitoring read access to the etc/shadow and etc/passwd files, which are only readable by the root user by default.

2. Unsecured credential access

Adversaries often seek out unsecured credentials to facilitate lateral movement within a network. They may exploit poorly unsecured credentials stored in plaintext, weakly encrypted, unhashed, and in easily accessible locations. They might look into the bash_history file to uncover previously used credentials and search the ~/.ssh directory for private SSH keys.

Detection efforts should focus on identifying attempts to perform read actions on these files, as they can indicate malicious intent.

Detection with Wazuh

In this section, we configure the monitored endpoints to spot potential malicious activities run by non-root users and use Wazuh detection rules to trigger alerts.

Note: You need root user privileges to execute the commands below.

Configuring the Ubuntu endpoint

Here we configure the Ubuntu endpoint to detect offline credential file access. Additionally, we log commands run from the Command Line Interface (CLI) to uncover potential malicious commands using Auditd.

Perform the following actions to install Auditd and create the necessary audit rules:

1. Install, start, and enable Auditd if it is not already present on the system:

# apt -y install auditd audispd-plugins
# systemctl start auditd
# systemctl enable auditd

2. Run the following command to append 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

Where:

  • –a exit,always specifies an audit rule applied to the exit point of a syscall. The always keyword ensures that the rule is always active.
  • The -F auid!=-1 filter ensures that the rule does not apply to actions where the Audit User ID is -1. An auid of -1 usually indicates that the process is not associated with a user, often seen with kernel threads or during early boot stages.
  • The -F arch=b64 filter specifies that the rule applies to 64-bit architecture syscalls. For 32-bit architectures the filter will be arch=b32.
  • -S execve specifies the syscall to be audited. execve is a syscall used to execute programs. Therefore, this rule will log every program execution that meets the specified filters.
  • -k audit-wazuh-c specifies a key for the audit record. The -k option allows you to tag the audit logs generated by this rule with a specific identifier, making searching for and analyzing related logs easier.
  • -F perm=r specifies that the rule applies to read operations.
  • -F euid!=0 instructs that we are matching events where the effective user ID (euid) is not equal to 0. The EUID 0 typically corresponds to the root user in Unix-like operating systems.
  • -F path specifies the full path to the file to be monitored. Make sure to replace <USER_HOME_DIRECTORY> with the user’s home directory for whom you want to monitor the bash history and SSH file access.

Warning: The audit rule -a always,exit -F arch=b64 -S execve -F auid!=-1 -F euid!=0 -F key=audit-wazuh-c logs every command run on the monitored endpoint. This has the effect of triggering the default Wazuh auditd rule ID 80792.

3. Reload the rules and confirm that they are in place:

# sudo auditctl -R /etc/audit/rules.d/audit.rules
No rules
enabled 1
failure 1
pid 2652
rate_limit 0
backlog_limit 8192
lost 0
backlog 3
backlog_wait_time 60000
backlog_wait_time_actual 0
enabled 1
failure 1
pid 2652
rate_limit 0
backlog_limit 8192
lost 0
backlog 7
backlog_wait_time 60000
backlog_wait_time_actual 0
enabled 1
failure 1
pid 2652
rate_limit 0
backlog_limit 8192
lost 0
backlog 2
backlog_wait_time 60000
backlog_wait_time_actual 0
# sudo auditctl -l
-a always,exit -F arch=b64 -S execve -F auid!=-1 -F euid!=0 -F key=audit-wazuh-c
-a always,exit -F arch=b64 -S all -F path=/etc/shadow -F auid!=-1 -F euid!=0 -F perm=r -F key=shadow_access
-a always,exit -F arch=b64 -S all -F path=/etc/passwd -F auid!=-1 -F euid!=0 -F perm=r -F key=passwd_access
-a always,exit -F arch=b64 -S all -F path=/root/.bash_history -F auid!=-1 -F euid!=0 -F perm=r -F key=history_access
-a always,exit -F arch=b64 -S all -F dir=/root/.ssh/ -F auid!=-1 -F euid!=0 -F perm=r -F key=ssh_access

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:

<ossec_config>  
  <localfile>
    <log_format>audit</log_format>
    <location>/var/log/audit/audit.log</location>
  </localfile>
</ossec_config>

5. Restart the Wazuh agent service to apply the configurations:

# sudo systemctl restart wazuh-agent

Configuring the Wazuh server

1. Update the /var/ossec/etc/lists/audit-keys CDB list with the custom audit key:

# cat << EOF >> /var/ossec/etc/lists/audit-keys
passwd_access:passwd
shadow_access:shadow
history_access:history
ssh_access:ssh
EOF

2. Add the following rules to the /var/ossec/etc/rules/local_rules.xml file to generate alerts on the Wazuh dashboard whenever an attacker performs any of the attacks mentioned above:

<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>

Where:

  • 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.

3. Restart the Wazuh manager to apply the configuration changes:

# systemctl restart wazuh-manager

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.

Credential Access Attacks security events

Conclusion

In this blog post, we have shown how Wazuh helps identify credential access threats on Linux endpoints. As cybercriminals become more advanced, protecting against credential compromise is increasingly important to ensure the security and integrity of information assets.

Using Wazuh, you can detect potential threats relating to credential theft, hence taking a step ahead in safeguarding your organization’s credentials and maintaining the security of your digital environment.

References