If a non-root malware is trying to crack the users' password, which password files or even memory part it has to access? How can I monitor and tell if the password files get accessed by the malware?

3 Answers 3


Most distros store user login passwords in /etc/shadow, this file is owned by root and has 0600 set as permissions, that is, only root can read or write to this file.

That being said, some distros provide 'keyrings' for users/programs to use. Keyrings are essentially a secret storage database or file, for example KDE provides KWallet, and programms like Chromium use KWallet to store passwords, etc.

These keyrings are generally managed per-user, and stored with 0600 permissions aswell, so only the user that owns the keyring can actually read it. So if you are woried about non-root malware, as long as it isn't running as your user, you are pretty safe in this regard.

Unfortunately, I can't give you an exhaustive list of which files to monitor, because each distro uses their own secret management solution (like GNOME3 using Seahorse instead of KWallet). But I'd generally monitor for changes in:

~/.ssh/authorized keys # List of keys accepted during SSH logins
~/.profile             # File sourced by your login shell
~/.bash_profile        # File sourced by your login shell
~/.bashrc              # File sourced by your login shell

About monitoring, perhaps the easiest way to set it up is using the audit framework through auditctl.

For example this will monitor all access to bob's KWallet database file: (temporary rule, clears on reboot unless added to /etc/audit/audit.rules)

sudo auditctl -w /home/bob/.local/share/kwalletd/kdewallet.kwl -p rwxa

And for reviewing access:

sudo less /var/log/audit/audit.log

Here is some documentation which might help you create your own rules

  • Which files do you monitor? ~/.ssh/authorized keys, ~/.profile, ~/.bash_profile, ~/.bashrc, /home/bob/.local/share/kwalletd/kdewallet.kwl? Many said using auditctl, if I were the malware, I will stop if auditctl running.
    – nudros
    Commented Aug 13, 2020 at 11:51

If a non-root software is trying to change users, you can inspect that with the lastb command:

$ sudo lastb -a | more
user     pts/2        Mon Aug 10 08:17 - 08:17  (00:00)
root     ssh:notty    Mon Aug 10 08:17 - 08:17  (00:00)
root     ssh:notty    Mon Aug 10 08:17 - 08:17  (00:00)
root     ssh:notty    Mon Aug 10 08:16 - 08:16  (00:00)
root     ssh:notty    Mon Aug 10 08:16 - 08:16  (00:00)

In this case, I logged in as user with a failed password using su. You can see that in the log. You can also see that random IPs are constantly trying to guess my root password via ssh.

If you want to setup an inotify or systemd path to watch for file access, the file to watch is /var/log/btmp. lastb uses this file.

If you want to check for successful logins, then use last. This monitors /var/log/wtmp:

$ last -a
usera    pts/5        Fri Jul 31 03:00 - 03:17  (00:16)
usera    pts/5        Thu Jul 30 21:36 - 21:37  (00:01)
usera    pts/5        Wed Jul 29 08:54 - 08:54  (00:00)
userb    tty7         Tue Jul 21 11:29   still logged in    :0
userb    tty7         Tue Jul 21 10:59 - 11:29  (00:30)     :0
userb    tty7         Tue Jul 21 07:27 - 10:58  (03:31)     :0
reboot   system boot  Tue Jul 21 09:27   still running      5.7.0-1-amd64

On linux you can use the inotify framework and associated command line tools to watch some file access made by another process.

Here are the man pages for reference

If you want more elaborate behaviour there are binding for this framework for most of scripting language (python, lua, etc ...)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .