Linux is less targeted by malicious attackers statistically than Windows. However it is still vitally important that we monitor these systems for security threats.

This blog post will show you some ways to use a SIEM to monitor for malicious Linux behaviour. A lot of these rules will use auditd – the access monitoring and accounting subsystem of Linux. Learn more about this here – https://security.blogoverflow.com/2013/01/a-brief-introduction-to-auditd/

If you have any issues implementing any of the below rules, contact me at https://blueteamblog.com/contact-me and I will try to help.

POTENTIALLY MALICIOUS SSHD ERRORS

Lets start off with looking at looking at SSH / SHHD error messages that can indicate exploit attempts occuring.

• Log Source = Linux
• Service = sshd
• Query matches = ” ‘unexpected internal error‘, ‘unknown or unsupported key type‘, ‘invalid certificate signing key‘, ‘invalid elliptic curve value‘,’incorrect signature‘, ‘error in libcrypto‘, ‘unexpected bytes remain after decoding‘, ‘fatal: buffer_get_string: bad string‘, ‘Local: crc32 compensation attack‘, ‘bad client public DH value‘, ‘Corrupted MAC on input‘ ”
• Make the above more efficient by parsing out and indexing the field where this value appears within the sshd log.

POTENTIALLY MALICIOUS VSFTPD ERRORS

Next up, potentially malicious errors within VSFTPD, that can indicate exploit attempts occurring.

• Log Source = Linux
• Service = vsftpd
• Query matches any of = ” ‘Connection refused: too many sessions for this address.’, ‘Connection refused: tcp_wrappers denial.’, ‘Bad HTTP verb.’, ‘port and pasv both active’, ‘pasv and port both active’, ‘Transfer done (but failed to open directory).’, ‘Could not set file modification time.’, ‘bug: pid active in ptrace_sandbox_free’, ‘PTRACE_SETOPTIONS failure’, ‘weird status:’, “couldn’t handle sandbox event”, ‘syscall * out of bounds’, ‘syscall not permitted:’, ‘syscall validate failed:’, ‘Input line too long.’, ‘poor buffer accounting in str_netfd_alloc’, ‘vsf_sysutil_read_loop’ “

OVERWRITING FILES WITH DEV 0 OR NULL

After performing attacks, many threat actors will attempt to hide their behaviour. They may also delete files to cause various issues.

• Log Source = Linux
• Service = auditd
• Type of auditd = EXECVE
• Query matches = ‘dd’ THEN Query matches = ‘if=/dev/null’ OR ‘if=/dev/zero’

BUFFER OVERFLOW ATTEMPTS

Attackers may attempt buffer overflow attempts during attacks. This rule looks for 4 common signs of this.

• Log Source = Unix
• Query matches any of = ” ‘attempt to execute code on stack by’, ‘FTP LOGIN FROM .* 0bin0sh’, ‘rpc.statd[\d+]: gethostbyname error for’, ‘AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA’ “

REMOVE IMMUTABLE FILE ATTRIBUTE

Atttackers may also try and edit immutable files within a Linux system. Immutable files are created so they cannot be deleted however this can be modified. The following rule looks for this happening.

• Log Source = Linux
• Service = auditd
• Type of auditd = EXECVE
• Query matches ‘chattr’ THEN ‘-i’

FILE OR FOLDER PERMISSIONS CHANGE

File or folder permissions being changed could indicate an attacker trying to access files or folders within a network.

• Log Source = Linux
• Service = auditd
• Type of auditd = EXECVE
• Query matches any of “chmod or chown”
• This query will require whitelists to be added for legitimate users who are allowed to change these permissions legitimately.

SYSTEMD SERVICE RELOADED OR STARTED

This rule is looking at the start or reload of a service. Attackers may use services maliciously within a network.

• Log Source = Linux
• Service = auditd
• Type of auditd = EXECVE
• Query matches = “systemctl” THEN query matches “daemon-reload OR start”
• Whitelists will need to be added for legitimate services

CLEARING COMMAND HISTORY

After attackers have finished an attack on a Linux system they will try and clear the command history. We can look at the commands used to do this.

• Log Source = Linux
• Query matches any of = “rm *bash_history, echo “” > *bash_history, cat /dev/null > *bash_history, ln -sf /dev/null *bash_history, truncate -s0 *bash_history, export HISTFILESIZE=0, history -c, history -w, shred *bash_history”

DETECT INFORMATION GATHERING

This next rule is looking at shell commands which are used for information gathering within a Linux system.

• Log Source = Linux
• Over 6 of the following commands within a 30 minute period
• Whitelists may be require for admins who regularly perform troubleshooting.
• Shell command equals any of the following list :

    - 'wget * - http* | perl'
    - 'wget * - http* | sh'
    - 'wget * - http* | bash'
    - 'python -m SimpleHTTPServer'
    - '-m http.server'  # Python 3
    - 'import pty; pty.spawn*'
    - 'socat exec:*'
    - 'socat -O /tmp/*'
    - 'socat tcp-connect*'
    - '*echo binary >>*'
    - '*wget *; chmod +x*'
    - '*wget *; chmod 777 *'
    - '*cd /tmp || cd /var/run || cd /mnt*'
    - '*stop;service iptables stop;*'
    - '*stop;SuSEfirewall2 stop;*'
    - 'chmod 777 2020*'
    - '*>>/etc/rc.local'
    - '*base64 -d /tmp/*'
    - '* | base64 -d *'
    - '*/chmod u+s *'
    - '*chmod +s /tmp/*'
    - '*chmod u+s /tmp/*'
    - '* /tmp/haxhax*'
    - '* /tmp/ns_sploit*'
    - 'nc -l -p *'
    - 'cp /bin/ksh *'
    - 'cp /bin/sh *'
    - '* /tmp/*.b64 *'
    - '*/tmp/ysocereal.jar*'
    - '*/tmp/x *'
    - '*; chmod +x /tmp/*'
    - '*;chmod +x /tmp/*'

FAILED LOGINS ON A SINGLE SOURCE WITH MANY USERS

Next we are going to look for failed logins on a single source from many users. This could indicate an attacker attempting to log in with various accounts and brute forcing.

• Log Source = Linux
• Service = Auth
• Pam Message = Authentication Failure
• Over 3 different accounts failing to log into the same source within 24 hours
• Exclusions will need to be added for Terminal Servers, Jump Servers and Work Stations commonly used by various users.
• You may need to raise the threshold depending on your environment.

Thanks for reading this article and I hope you learned something today. If you have any Linux rules I didn’t mention, comment below. If you are having issues making the rules I mentioned above, contact me and I will try to help. Thanks again for the continued support.