Social Engineering practice questions

Buy the gift cards immediately so the CEO is not delayed.

Why wrong: Complying without verification can directly reward a scam and cause financial loss.

Forward the email to coworkers so they can watch for the same request.

Why wrong: Forwarding it broadly can spread confusion and does not confirm whether the request is legitimate.

Reply to the sender and ask for more details in the same email thread.

Why wrong: Replying within the same thread may still interact with a spoofed or compromised account and is not a safe verification method.

Reset MFA immediately because the request appears to come from the employee.

Why wrong: Acting on the email alone could help an attacker bypass authentication using a spoofed or lookalike address.

Reply to the email and ask the employee to confirm the request in writing.

Why wrong: Replying through the same suspicious channel does not provide trustworthy verification and may continue the attack.

Forward the message to everyone in IT so another technician can decide what to do.

Why wrong: Broadcasting the message increases exposure and still does not confirm whether the request is legitimate.

Read the current MFA reset code over the phone to speed up recovery.

Why wrong: Sharing one-time codes defeats MFA protections and may enable account takeover.

Enroll the new device immediately because the caller knows company names and roles.

Why wrong: Insider-sounding details are a common pretexting tactic and do not prove identity.

Pretexting

Why wrong: Pretexting involves a false story, but this option does not specifically capture the voice-call delivery method.

Smishing

Why wrong: Smishing uses text messages, not a live phone conversation with the target.

Baiting

Why wrong: Baiting typically uses a lure, such as a free item or infected media, rather than a call.

the call is routed through the company ticketing system with an approved change record

Why wrong: A documented request with an approved change record would support legitimate administrative action, not social engineering. Proper workflow and traceability reduce the likelihood of a pretext. This option describes a controlled process, which is the opposite of the suspicious behavior in the scenario.

the caller answers all security questions correctly after being prompted for them

Why wrong: Correct answers to security questions do not automatically prove fraud, and they may simply mean the caller is a legitimate user who knows the information. The suspicious part of the scenario is the pressure to skip verification. Social engineering is indicated more by process evasion than by a user being able to answer questions.

the call occurs after normal business hours on a holiday weekend

Why wrong: Unusual timing can raise suspicion, but it is not as strong as impersonation and a request to skip verification. Real support requests can occur outside normal hours. The strongest indicators are the manipulative tactics used to create urgency and bypass established identity checks.

Baiting

Why wrong: Baiting usually offers something tempting, like free media or a giveaway, to lure a victim. This message focuses on fear and account suspension rather than curiosity or reward.

Vishing

Why wrong: Vishing is voice-based social engineering conducted over a phone call or voicemail. This scenario uses email, so it does not fit voice phishing.

Pretexting

Why wrong: Pretexting centers on building a fabricated story to manipulate the target, often in a conversation. While this email includes a story, the most specific label here is phishing through email.

Phishing

Why wrong: Phishing usually uses email or web pages, while this attack is happening over the phone.

DDoS

Why wrong: A distributed denial-of-service attack floods services with traffic and is unrelated to this human conversation.

SQL injection

Why wrong: SQL injection targets web applications, not a phone conversation with a help desk impersonator.

Baiting, because the caller is offering something valuable in exchange for action

Why wrong: Baiting usually involves an enticing object or promise, such as a free download, gift, or infected USB drive, rather than a fabricated identity over the phone.

Vishing, because the attack happens by voice call

Why wrong: Vishing does describe phishing over a phone call, but the question asks for the primary technique. The defining tactic here is the fabricated story and identity.

Smishing, because the attacker is using a mobile device

Why wrong: Smishing is phishing by text message. This scenario uses a voice call, not SMS or messaging.

On-path attack

Why wrong: Incorrect. An on-path (formerly man-in-the-middle) attack involves the attacker intercepting and possibly altering communications between two parties. In this scenario, the attacker hosted a fake login page that the victims visited directly; there is no indication of intercepted traffic between the user and the legitimate service.

Brute-force attack

Why wrong: Incorrect. A brute-force attack involves systematically trying all possible password combinations until the correct one is found. The scenario describes users being tricked into revealing their passwords, not an automated guessing attempt.

Password spraying

Why wrong: Incorrect. Password spraying attempts a small number of commonly used passwords against a large number of accounts. The scenario involves a targeted attack that harvested credentials from multiple users via a fake login page, not a low-and-slow password guessing technique.

Phishing

Why wrong: Phishing is a social engineering technique carried out via email, text, or malicious websites, not over voice calls. This attack uses a phone call, so it is not phishing.

Spear phishing

Why wrong: Spear phishing is a targeted email attack directed at a specific individual or organization, often using personal details. This scenario involves a phone call, not email, so it is not spear phishing.

Pretexting

Why wrong: Pretexting involves creating a fabricated scenario (pretext) to obtain information, but it is a broader category that can be carried out via phone, email, or in person. However, when the attack is specifically conducted through a voice call, vishing is the more precise term used in cybersecurity. Pretexting is not incorrect in theory, but vishing is the standard classification for voice-based social engineering.

Spear phishing, because the email uses targeted business context and time pressure.

Why wrong: Spear phishing is plausible because the message is targeted and credible, but it does not best capture the impersonation used to drive a specific action.

Smishing, because the attacker is using a text message to reach the victim.

Why wrong: Smishing specifically uses SMS or messaging apps. This scenario is delivered by email, so the channel does not match even though the content is deceptive.

Baiting, because the attacker is offering a portal link that appears helpful to the recipient.

Why wrong: Baiting relies on an enticing lure such as free media, downloads, or physical bait. A vendor-impersonation payment request is a different social engineering pattern entirely.

Tailgating, because the attacker is trying to enter a secure area physically.

Why wrong: Tailgating involves following someone into a restricted physical space, not sending an email request for a secret code.

DDoS, because the message is designed to overwhelm the mailbox server.

Why wrong: A distributed denial-of-service attack floods a service with traffic; it does not rely on impersonation or secret-code theft.

Shoulder surfing, because the attacker is watching the screen from nearby.

Why wrong: Shoulder surfing requires physically observing information, usually over someone's shoulder, rather than sending a deceptive email.

Reply with the six-digit code so the help desk can complete the repair quickly.

Why wrong: Sharing an MFA code defeats the purpose of multi-factor authentication and gives the attacker what they need for account takeover.

Open the linked repair page from the email and sign in immediately to avoid suspension.

Why wrong: The exhibit shows suspicious sender details and social pressure, so following the link could send the user to a credential-harvesting site.

Forward the message to the manager and continue using the account until the suspension occurs.

Why wrong: Escalation to a manager is not a substitute for verification, and waiting allows the attacker more time to exploit the pretext.

Send the same annual awareness slide deck to everyone again without changing the content.

Why wrong: The exhibit shows that some groups have much higher click and much lower report rates than others. A generic repeat of the same material is unlikely to address those specific behavior gaps.

Block all external email so users cannot click suspicious messages.

Why wrong: Blocking all external email would severely disrupt business communication and does not address the core awareness and reporting problem. It is also far more restrictive than the scenario calls for.

Take no action because IT already reports suspicious messages well.

Why wrong: Good performance in one group does not eliminate risk in the others. The exhibit shows clear weaknesses in other departments that still need corrective awareness efforts.

Replace the phone-call simulation with longer monthly policy newsletters.

Why wrong: Long newsletters rarely change behavior in a targeted vishing problem. The exhibit shows a specific interaction pattern that needs practice and reinforcement, not more generic reading material.

Disable MFA so users are not asked for one-time codes.

Why wrong: Disabling MFA would remove an important protection and make account compromise easier. The right response is to teach users never to share one-time codes, not to eliminate the control that uses them.

Tell users to ignore all requests from anyone outside the company.

Why wrong: That is too broad and unrealistic for business operations. Staff still need to interact with vendors and partners, so the organization should teach verification steps rather than a blanket ignore policy.

Watering-hole attack targeting employees through a compromised website.

Why wrong: This involves a trusted website being infected, not a deceptive email impersonating an executive.

Smishing attempt delivered through a text message to a mobile phone.

Why wrong: The message is delivered by email, so it is not a text-based social engineering attempt.

Credential stuffing against the CFO's mailbox using previously leaked passwords.

Why wrong: Credential stuffing is a login attack, but the scenario describes a fraudulent message rather than an account takeover attempt.

Open the link and compare it with the supplier's branding

Why wrong: Branding can be copied easily, so visual comparison is not a reliable verification method.

Reply to the text and ask the sender to confirm the request

Why wrong: Replying keeps the conversation inside the attacker-controlled channel and does not provide trusted verification.

Forward the message to finance so they can decide whether it is legitimate

Why wrong: Escalation may be appropriate later, but it does not directly verify the request or prevent a possible compromise.

Provide the code quickly so the support call can be completed without delay.

Why wrong: Sharing one-time codes can give an attacker access to the account. Legitimate support staff should not ask the user to reveal MFA codes.

Reply to the caller by email with the code and ask them to confirm receipt.

Why wrong: Sending the code by email still exposes the authentication secret to a potentially malicious actor and creates additional risk.

Change the password immediately and then tell the caller the new password.

Why wrong: Changing the password does not make it safe to share the new secret. A real support workflow would not require the user to reveal credentials.

Tap the link and complete the MFA reset immediately

Why wrong: This is risky because the message may lead to a fake site designed to steal credentials. Acting immediately without verification can expose the account.

Forward the text to coworkers so they can watch for it too

Why wrong: Forwarding can spread the harmful link and may cause more users to click it. The message should be reported through approved channels instead.

Reply to the sender and ask for more details

Why wrong: Replying confirms the number is active and can invite more social engineering attempts. It also does not verify the request through a trusted source.