Malware, Social Engineering, and Client-Side Attacks
This domain tests attacks that target people and endpoints: phishing, pretexting, malicious attachments, browser exploits, and payload delivery. The ethical boundary is strict: simulations must be authorized, bounded, and designed to collect the minimum evidence.
Core rules and concepts
- Social engineering follows a cycle: information gathering, pretext development, delivery, exploitation, and reporting. Authority, urgency, fear, and familiarity are common levers.
- Client-side vectors include macro documents, ISO/archive files, malicious links, USB drops, and browser or plugin exploits.
- Payloads should be benign or tightly controlled. Avoid real malware, persistence, or credential theft unless explicitly permitted and contained.
- Measure click rate, report rate, credential submission rate, and time to report; do not shame individual users in the report.
- Get approval for target groups, message content, sending infrastructure, and stop conditions.
Worked example
A phishing simulation is approved for 200 users. The goal is to test reporting, not harvest passwords. You use a benign landing page that records only whether the link was clicked and whether the user reported the message, with no password field. After the campaign, you provide aggregate metrics and recommend a shorter reporting path. The reasoning: the test answers the client's control question without collecting real credentials or exposing users to malware.
Traps
Do not send a simulation to the whole company when only one department is in scope. Never use real malware or real stolen credentials in a report. Avoid targeting personal accounts or contractors without authorization. Do not treat a click as proof that a user is careless; the control may be the real failure.