Preventing Tampered Update Binaries with Digital Signatures
A security analyst detected unusual network traffic related to program updating processes. The analyst collected artifacts from compromised user workstations. The discovered artifacts were binary files with the same name as existing valid binaries but with different hashes. Which of the following solutions would most likely prevent this situation from reoccurring?
Community Insight
The question tests integrity and authenticity of software updates; the trap is picking a process or source-restriction fix when only cryptographic signature verification can prove a binary was not altered.
When update processes deliver binaries that carry a legitimate file name but a different hash, the update channel has been poisoned by tampered or replaced executables. Cryptographic signature verification on every update artifact is the control that stops such forged binaries from ever executing.
Learners often choose A (improving patching processes) or D (allowing only internal files), because the artifacts arrived through an update workflow. Better patching frequency and source filtering do nothing against an attacker who replaces a binary with an equally well-named file from an allowed source — only signature verification detects the changed content.
Community Discussion (1 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Option B is correct because the defining indicator is a binary whose name matches a valid executable but whose hash differs — the textbook signature of substitution or tampering. Digital signature verification (code signing) lets the endpoint validate both authenticity and integrity of an update package against a trusted certificate chain, rejecting anything whose digest does not match the signer's signature. This check is performed before execution and works regardless of where the file came from, so a tampered update is blocked automatically and the situation cannot recur. Malware distribution and update-hijack defense both depend on this control, and it directly addresses the root cause rather than the delivery path.Why the Other Options Are Wrong
Option A, improving patching processes, only changes how quickly fixes are applied; it does not authenticate the content of the update, so an attacker who can inject a same-named binary still succeeds. Option C, performing manual updates via USB, is impractical and actually expands the attack surface through removable media, introducing a new infection vector rather than closing this one. Option D, allowing only files from internal sources, constrains provenance but not content — an attacker who compromises an internal distribution point or workstation can serve a modified binary from an approved source, and the differing hash still goes undetected without signature checks.Community Comment Notes
As jamestkd observed, the artifacts are "binary files with the same name as existing valid binaries but with different hashes," a classic binary replacement indicator. The comment explains that digital signatures force endpoints to "verify the cryptographic authenticity and integrity of any update file before execution," which is exactly the preventive control the question asks for. That reasoning matches the independent analysis here: signature verification is the only option that authenticates the file's contents rather than its timing, location, or origin.Exam Strategy
Read the indicator, not the workflow: when a question shows matching names but differing hashes or signatures, the defect is integrity, and the fix must be cryptographic verification of content. Eliminate answers that only change timing, location, or permitted sources, since none of them prove the file was not altered.
Frequently Asked Questions
Why is improving patching processes wrong for tampered update binaries?
Faster patching changes timing, not content. An attacker can still deliver a same-named altered binary through the normal update channel, so the differing hash goes undetected.
Why does allowing only internal-source files not prevent this attack?
Source filtering trusts where a file came from, not what it contains. A compromised internal distribution point can serve a modified binary that signature verification would reject.
Related Analysis
Practice All CAS-005 Questions
Access 135 questions with complete answers and detailed explanations.
View Full CAS-005 Practice Test →