Identifying Tools by /etc/shadow Permission Denied Errors
A security administrator is performing an audit on a stand-alone UNIX server, and the following message is immediately displayed: (Error 13): /etc/shadow: Permission denied. Which of the following best describes the type of tool that is being used?
Community Votes
56% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
The question tests recognition of tool behavior by analyzing OS-level error messages, with the common trap being the assumption that audits only use benign monitoring tools like FIM.
This question tests the ability to identify security tools based on specific error messages during an audit. The correct answer is D because password crackers attempt to read /etc/shadow, triggering permission errors if privileges are insufficient.
Many learners chose B (File integrity monitor) assuming the context of an 'audit' implies a non-destructive scanning tool, ignoring that the error indicates an unauthorized access attempt typical of cracking tools.
Community Discussion (20 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
The key to this question lies in the specific file and error message:/etc/shadow and Permission denied. In UNIX/Linux systems, /etc/shadow stores user password hashes and is strictly protected (readable only by root). A password cracker's primary function is to retrieve these hashes for offline cracking. If a password cracker is run without root privileges, it will immediately fail with a permission denied error when attempting to open this file. This behavior directly matches the scenario described.Why the Other Options Are Wrong
Option A (Pass-the-hash monitor) involves replaying captured hashes, not reading local shadow files. Option C (Forensic analysis) is a broad discipline; while forensic tools might read shadow files, they typically operate with elevated privileges or handle evidence files rather than generating live OS permission errors in this manner. Option B (File integrity monitor) checks for changes to files but does not typically attempt to read the contents of restricted files like/etc/shadow in a way that generates this specific error during a standard audit configuration; FIMs usually rely on kernel hooks or privileged agents.Community Comment Notes
The community was split, with many voting for D. As Cyberity noted, "Password crackers often attempt to access this file to obtain hashed passwords for cracking." However, some users like AndyK2 argued for B, stating, "I'd go with FIM - since it makes more sense" in the context of an audit. Others like Eracle questioned why a cracker would generate such an error, suggesting it operates on copies, but in a live server audit scenario, direct access attempts trigger these OS-level blocks.Exam Strategy
When analyzing security scenarios involving error messages, focus on the resource being accessed. Accessing sensitive credential stores like /etc/shadow or SAM is a strong indicator of password-related attacks or tools, even if the tool fails due to permissions.
Frequently Asked Questions
Why isn't this a File Integrity Monitor?
FIMs check for changes to file contents or permissions but don't typically try to read the raw content of highly restricted files like /etc/shadow in a way that triggers immediate permission denied errors during setup.
Does a password cracker always fail on /etc/shadow?
No, if run as root it succeeds. The error indicates the specific tool instance lacked privileges, which is common in unprivileged audit or attack scenarios.
Related Analysis
Practice All SY0-701 Questions
Access 100 questions with complete answers and detailed explanations.
View Full SY0-701 Practice Test →