Social Engineering and Human-Factor Attacks Questions
The human dimension of offense and defense. Covers social engineering techniques and pretexting, phishing campaigns and their detection and response, human factors in security, and building organizational resistance to manipulation-based attacks. Focuses on attacks that target people rather than systems, and the operational response to them.
Design a practical phishing triage playbook for the SOC for a mid-size enterprise (500–2000 employees). The playbook should include decision points for 'user clicked link', 'user submitted credentials', and 'attachment executed', and list the responsible roles and SLAs for each step.
Sample Answer
Overview
A concise SOC triage playbook for phishing incidents (500–2000 employees) with decision branches for: user clicked link, user submitted credentials, attachment executed. Goals: contain fast, preserve evidence, restore service, and reduce phishing click-to-compromise time.
Roles & SLAs (summary)
- Tier 1 Analyst (T1) — initial triage, enrich alerts. SLA: 15 min initial response.
- Tier 2 Analyst (T2)/Threat Hunter — deep analysis, pivoting. SLA: 60 min containment decision.
- Endpoint Team / EDR Engineer — containment/remediation on endpoints. SLA: 2 hours for containment actions.
- Email Admin / M365 Security — block sender/URL, remove messages. SLA: 30–60 min for blocking/removal.
- IR Lead / SOC Manager — coordinate incident, escalate to Legal/HR. SLA: 1 hour to assign incident severity.
- Legal / HR / PAM Team — for credential compromise and data exposure. SLA: 4 hours to provide guidance.
1) User clicked link (no credentials submitted)
- T1: Confirm alert, capture email headers, URL, user, device, and session logs. (15 min)
- Decision: Is URL known-malicious or redirects to credential page?
- If benign / false positive → T1 close with user education (SLA 24 hrs).
- If suspicious/malicious → T1 escalate to T2 (60 min).
- T2: Analyze URL in sandbox, check web gateway/Proxy logs, look for drive-by download. If redirect to exploit → Endpoint Team isolate device and perform EDR scan (2 hrs).
- Email Admin: Block URL, sender, and remove similar emails org-wide (30–60 min).
- Outcome: Remediate, reset user sessions, user awareness notification.
2) User submitted credentials
- T1: Immediate validate submission evidence (phish URL/form), collect headers and auth logs; force session revocation and MFA prompt. (15 min)
- Decision: Are credentials single-factor or include corporate SSO?
- If SSO/Privileged → IR Lead escalate to Legal/PAM and T2 immediately (within 30–60 min).
- T2/PAM: Rotate compromised credentials, revoke tokens, force password reset & MFA re-enrollment, perform lateral movement hunt. (2–4 hrs)
- Email Admin: Block source, remove messages. Endpoint Team: scan endpoints for persistence. Legal/HR: advise on disclosure if data access occurred.
- Outcome: Confirm no unauthorized access, close with user training and log review.
3) Attachment executed
- T1: Capture file hash, isolate host via EDR, preserve memory/image snapshots. (15 min)
- Decision: Does static/dynamic analysis show malware or ransomware indicators?
- If benign → restore host; if malicious → T2/Threat Hunter full IR (contain, eradicate). (60 min decision)
- Endpoint Team: Quarantine device, perform forensic triage, rebuild if needed (2–8 hrs depending on severity).
- T2: Hunt for indicators across network and endpoints, identify IOCs, update detection rules.
- IR Lead: Notify stakeholders, consider user communications and legal if data exfiltration.
- Outcome: Eradicate, restore from clean image, post-incident review and signature deployment.
Evidence & Documentation
- At every step: ticketing system entry, timeline, artifacts (headers, pcap, EDR logs, sandbox reports), decision rationale, and remediation steps.
Post-Incident
- SLA: Post-mortem within 72 hours; training & phishing simulation within 2 weeks for affected groups; update IOC blocks and detection rules within 24 hours after validation.
This playbook balances speed and thoroughness for a mid-size enterprise, assigning clear roles and time-bound actions to minimize damage and recurrence.
List and explain at least eight common indicators in a suspicious email message that an analyst should check during initial assessment (e.g., sender address anomalies, deceptive links, unexpected attachments, urgency language). For each indicator, briefly say why it is useful and one false-positive example to watch out for.
Sample Answer
Overview
Below are 10 common indicators to check during initial email triage. For each: what to look for, why it matters, and one realistic false-positive to watch.
- Sender address anomalies
- What: Domain mismatches, subtle typos, display name ≠ envelope from.
- Why: Attackers spoof domains or use lookalike domains to impersonate.
- False positive: Legit vendor using a marketing subdomain (news@service-marketing.example.com).
- Deceptive links (hover/URL mismatch)
- What: Link text differs from actual href, use of IPs or punycode.
- Why: Redirects to credential harvesters or malware hosts.
- False positive: URL shortener used by legitimate newsletter.
- Unexpected attachments
- What: Executables, macros-enabled documents, archive with nested files.
- Why: Attachments are primary malware delivery vectors.
- False positive: Legit HR sends .xlsm payroll with macros.
- Urgency or pressure language
- What: “Immediate action”, “Final warning”, threats of account closure.
- Why: Social engineering to bypass scrutiny.
- False positive: Real security alert from monitored vendor that truly requires prompt action.
- Generic greetings / lack of personalization
- What: “Dear customer” vs. using known user details.
- Why: Mass phishing campaigns often don’t target specifics.
- False positive: System-generated billing notices for services without account names.
- Poor grammar and spelling
- What: Awkward sentences, odd punctuation, translated text.
- Why: Many phishing kits are low-quality or machine-translated.
- False positive: Legitimate email localized by automated system with imperfect copy.
- Unusual sending time or volume anomalies
- What: Message sent at odd hours or many similar messages hitting org.
- Why: Bot campaigns or compromised accounts used off-hours.
- False positive: Global team in different time zone or scheduled batch notifications.
- Reply-to or return-path discrepancies
- What: Reply-to differs from from-address or uses third-party domain.
- Why: Responses routed to attacker-controlled inbox.
- False positive: Customer support outsourced via ticketing system with different reply-to.
- SPF/DKIM/DMARC failures
- What: Authentication fails or alignment issues.
- Why: Strong technical signal of spoofing or misconfiguration.
- False positive: Legit sender misconfigured email infrastructure.
- Contextual mismatch (unexpected topic/recipient)
- What: Email about invoices/HR but recipient never deals with those.
- Why: Spear-phishing tries to exploit unfamiliar targets.
- False positive: Cross-functional request legitimately sent to multiple teams.
Use these indicators collectively — one alone rarely proves malicious. Document findings, capture headers and URLs, and escalate when multiple signals align.
Design a machine-learning feature set (high-level, not code) to classify incoming emails as likely-phishing or benign for pre-filtering. Include feature categories (header, lexical, URL/domain, sender reputation, behavioral) and three specific example features for each category. Discuss how you would handle model drift and label quality.
Sample Answer
Overview (role frame)
As an Information Security Analyst I’d design a feature set that complements existing gateway rules and SIEM signals to pre-filter likely-phishing emails before deeper inspection.
Header features
- SPF pass/fail/softfail (numeric encoding) — mismatches vs. From alignments
- DKIM signature validity + domain alignment flag
- Reply-To vs From domain mismatch count (binary/ratio)
Lexical features
- Phishing keyword density (urgent/verify/password) normalized by token count
- Presence of obfuscated text (unicode homoglyphs, excessive punctuation) score
- HTML/plain-text ratio and invisible text segments count
URL / domain features
- Count of distinct URLs and number of URL redirects in message
- Domain age and WHOIS privacy flag for embedded domains
- URL tokenization: suspicious TLDs, uncommon subdomain depth, IP-as-host flag
Sender reputation
- Historical spam/phish rate for sender IP and envelope-from domain
- Past engagement metric (internal user replies/forwards) — low-engagement raises risk
- Presence on blocklists / threat-intel feeds (binary + recency score)
Behavioral features
- Time-of-day anomaly vs sender’s historical send window
- Similarity to previously labeled phishing templates (tf-idf cosine)
- Sudden spike in volume from sender or domain within rolling window
Handling model drift
- Continuous monitoring: track key metric drift (precision/recall), feature distribution drift (KS tests), and PSI for numerical features
- Use rolling-window retraining (e.g., weekly) plus concept-drift detectors to trigger interim retrains
- Maintain a validation set stratified by time; deploy canary models and perform A/B before full rollout
Improving label quality
- Multi-source labeling: combine gateway quarantine labels, user-report signals, and analyst-confirmed incidents with confidence weights
- Active learning: surface high-uncertainty examples for analyst review to correct labels and reduce blind spots
- Noise-robust training: label smoothing, loss functions tolerant to noisy labels, and periodic human audits of auto-labeled data
This design balances static indicators and behavioral context, integrates with threat intel/SIEM, and includes operational controls for drift and label fidelity.
Describe briefly how SPF, DKIM, and DMARC work together to reduce email spoofing. For each mechanism, explain (a) what it validates, (b) the basic deployment considerations, and (c) one limitation attackers can exploit.
Sample Answer
Overview
As an InfoSec Analyst I explain these controls as complementary layers: SPF verifies sending source, DKIM verifies message integrity/authority, and DMARC ties them to the From: domain and defines policy + reporting.
SPF
- (a) Validates: the sending mail server IP is authorized by the domain owner (envelope MAIL FROM / return-path).
- (b) Deployment: publish DNS TXT record listing authorized IPs/ranges; keep records under 10 DNS lookups; update when MTA providers change.
- (c) Limitation: fails to protect against header spoofing (attacker can spoof From: while using a third-party relay) and breaks with forwarded mail unless SRS used.
DKIM
- (a) Validates: cryptographic signature over selected headers/body proving domain’s signing key authorized the content.
- (b) Deployment: generate key pair, publish public key in DNS, enable signing on outgoing mail gateways, choose headers to sign, rotate keys regularly.
- (c) Limitation: signature breaks if intermediaries modify signed headers or body (e.g., mailing lists), and weak/short keys can be attacked.
DMARC
- (a) Validates: enforces alignment between From: domain and SPF or DKIM results and declares policy (none/quarantine/reject); provides aggregate/forensic reports.
- (b) Deployment: publish DNS TXT with policy and reporting addresses; start with p=none and analyze reports, then move to quarantine/reject; ensure SPF/DKIM coverage before enforcement.
- (c) Limitation: relies on correct reporting and alignment; attackers can use lookalike domains (typosquats) that pass SPF/DKIM/DMARC for their own domains.
By combining all three, you reduce spoofing risk: SPF/DKIM provide technical checks and DMARC enforces domain-level policy and visibility—practical defense requires monitoring reports, key management, and handling forwarding/third-party senders.
A user reports they clicked a phishing link and entered credentials, but the attacker then performed lateral movement into cloud storage. Describe a full recovery plan: revoking credentials and tokens, rebuilding or sanitizing compromised systems, restoring data integrity, and validating that no backdoors remain. Include verification steps and timelines.
Sample Answer
Situation summary (one line)
User phished and gave creds; attacker used them to move laterally into cloud storage. Recovery must contain access, eradicate footholds, restore data trust, and validate no persistence remains.
Immediate containment (0–4 hours)
- Disable compromised user account and force global sign-out (invalidate active sessions).
- Revoke all refresh and access tokens, OAuth consents, and SSO sessions for that identity.
- Rotate any exposed long-lived secrets (API keys, service-account keys, client secrets) tied to the user or resources accessed.
- Isolate affected endpoints and any VMs/containers with suspicious activity; place in network quarantine.
Short-term remediation (4–72 hours)
- Perform live forensics on quarantined hosts (memory, disk images) using EDR — capture artifacts before rebuild.
- Identify all accessed cloud resources via CloudTrail/AzureActivity/GCP Audit Logs and object access logs.
- Revoke and rotate IAM credentials for service principals and any delegated role sessions that could be abused.
- Restore compromised cloud storage objects from immutable snapshots/backups where available; mark suspect objects read-only.
- Rebuild compromised endpoints from known-good images; do not "clean" in-place unless forensic validated.
Eradication & hardening (3–14 days)
- Hunt for persistence: check scheduled tasks, startup scripts, container images, IAM policies, cross-account roles, and unusual trust relationships.
- Conduct full credential rotation for high-risk accounts and enforce MFA / conditional access policies.
- Apply least-privilege adjustments and implement access reviews on buckets/containers; remove public or broad ACLs.
- Push EDR/agent updates and run full AV/anti-malware scans on rebuilds.
Data integrity and restoration
- Validate backups: compare object hashes (e.g., SHA256) between backups and restored copies.
- If backups are compromised, restore from prior immutable snapshots; maintain chain-of-custody for potential legal action.
- Recompute checksums and run sampling integrity checks against manifests; log results.
Verification & validation (ongoing; measurable)
- SIEM correlation: confirm no anomalous logins or anomalous admin API calls for a rolling 30-day window post-incident.
- EDR: verify no active detections and no surviving suspicious processes or scheduled tasks.
- Cloud audit logs: verify no use of rotated keys after rotation time; confirm token revocations were effective.
- Penetration test / red-team (7–30 days): targeted test attempting lateral movement into storage and privilege escalation.
- Business owner sign-off after verified integrity checks and successful retest.
Timeline summary
- 0–4h: account disable, token revocation, isolate systems.
- 4–72h: forensics, credential rotation, restore critical data from backups.
- 3–14d: rebuild systems, hunt for persistence, enforce MFA/conditional access.
- 7–30d: verification testing, audits, red-team, finalize remediation and lessons learned.
Communications & documentation
- Notify stakeholders and affected users; coordinate with legal/HR/PR as needed.
- Document timeline, IOC list, actions taken, and evidence for post-incident review.
Metrics to close incident
- Zero unresolved high-severity IOCs after forensic and EDR validation.
- No anomalous cloud access for 30 days post-remediation.
- Successful red-team attempt rate = 0 for tested vectors; restored data hash audit 100% match.
This plan prioritizes containment, trustworthy backups, credential sanitation, and measurable validation to ensure the attacker has no remaining access or backdoors.
Unlock Full Question Bank
Get access to all 38 Social Engineering and Human-Factor Attacks interview questions and detailed answers.
Sign in to ContinueJoin thousands of developers preparing for their dream job.