Sensitive System File Read

How the attack works

An attacker with some level of code execution or tool access on a system directs an AI agent, script, or process to open one of these sensitive files. /etc/passwd and /etc/shadow reveal user accounts and password hashes; /etc/sudoers shows who can run privileged commands; the auth log and authorized_keys reveal login history and trusted SSH keys. This information is then used to plan credential theft or privilege escalation, rather than being the escalation itself.

Netzilo detection

Why it matters

An organisation risks having its account structure, privilege paths, and SSH trust relationships mapped out by an attacker, which feeds directly into follow-on credential theft or privilege escalation — even though this step alone does not grant new access.

What you can do

• →Restrict which accounts and processes can read /etc/shadow, /etc/sudoers, and root's authorized_keys — most services do not need this.
• →Review AI agent and automation tool permissions so they cannot read these files unless explicitly required for their job.
• →Baseline expected readers of these files (e.g. Ansible, Puppet, Chef, provisioning scripts) so unexpected reads stand out.
• →Alert on and investigate any read of these files by an AI agent or process outside known administration or configuration-management workflows.

Known benign look-alikes

• System administration and user-provisioning scripts run deliberately
• Configuration-management agents (Ansible, Puppet, Chef) reading account state
• Container image builds appending a service account to /etc/passwd
• Compliance tooling auditing sudoers or authorized_keys on a schedule

References

• https://attack.mitre.org/techniques/T1087/
• https://attack.mitre.org/techniques/T1552/

Related threats