When Service Accounts Go Rogue: Analyzing a Compromised 'mail' User

This is the last part of our blog series Linux DF/IR User activity. 

You can read the previous blog post from here:

First Part

Second Part

Service accounts, like the 'mail' user, are typically the unsung heroes of Linux systems, silently performing background tasks. That's why it's alarming when they're used for interactive logins. In a recent investigation, we discovered an attacker successfully logged in as the 'mail' user, a clear deviation from normal behavior. This suggests a critical security lapse, and we're here to break down the potential causes and how to prevent them.

Why is a 'mail' user login suspicious? Service accounts are designed for specific tasks, not human interaction. They should lack interactive shells and password authentication. So, what went wrong?

Potential Scenarios:

1. Service Account Misconfiguration: A Recipe for Disaster

• Interactive Shell Enabled:
  • Instead of a restricted shell like /usr/sbin/nologin or /bin/false, the 'mail' user might have been granted an interactive shell like /bin/bash.
  • How to check: grep mail /etc/passwd
  • If you see /bin/bash or a similar shell, that's your smoking gun.
• Password Authentication Enabled:
  • Service accounts shouldn't have passwords.
  • How to check: grep mail /etc/shadow
  • If the second field isn't ! or *, a password exists, and that’s a problem.

2. Weak or Default Password: An Attacker's Dream

• A simple password means easy access.
• Evidence: "Accepted password for mail from 192.168.210.131" in the logs speaks volumes.

3. SSH Access Misconfiguration: Open Doors

• Check /etc/ssh/sshd_config for:
  • AllowUsers or AllowGroups that include 'mail'.
  • PermitEmptyPasswords or PasswordAuthentication set to 'yes'.
• These settings can grant unintended SSH access.

4. Privilege Escalation via Sudo: The Ultimate Goal

• Sudo privileges for service accounts? A major red flag.
• Evidence: "mail : TTY=pts/1 ; USER=root ; COMMAND=/bin/su -" in the logs shows the attacker's next move.

5. Exploitation of a Vulnerability: Hidden Pathways

• An RCE vulnerability in the mail service could grant shell access as 'mail'.
• Always keep your services patched.

6. Compromised SSH Keys: Silent Entry

• How to check: cat /home/mail/.ssh/authorized_keys
• Compromised keys bypass password checks.

Fortifying Your Defenses: Prevention is Key

1. Disable Interactive Login: usermod -s /usr/sbin/nologin mail
2. Disable Password Authentication: passwd -l mail
3. Restrict SSH Access: Use AllowUsers in /etc/ssh/sshd_config and disable password authentication.
4. Review Sudo Privileges: Use visudo to remove unnecessary entries.
5. Monitor and Harden: Regular log reviews and patching are vital.
6. Strong Passwords and MFA: If passwords are a must, enforce strength and use MFA.

 
Immediate Actions:

1. Investigate: Dig into the 'mail' account's configurations and logs.
2. Block: Add the attacker's IP to your deny list.
3. Audit: Hunt for further signs of compromise.

Service account security is often overlooked, but it's a critical piece of your defense. By understanding these vulnerabilities, you can proactively protect your systems.