Trick 1: "If a URL contains the name of a legitimate company (like 'microsoft'), it must be a Microsoft URL." True or False?
FALSE — a URL is validated by its domain, not by what text it contains anywhere in it.
The domain of a URL is the registerable portion: in https://[domain]/path, it is the label immediately before the first slash after the protocol. In https://login.microsoft.verify-account.co/signin, the domain is verify-account.co — not microsoft.com. "login.microsoft" is a subdomain of verify-account.co, which the owner of verify-account.co controls completely.
Attackers deliberately include the target company's name as a subdomain to fool users who read URLs casually: login.microsoft.verify-account.co, secure.paypal.account-update.net, account.bankofamerica.security-alert.com. These all contain real brand names — none belong to the real organizations.
The only trustworthy part of a URL is the registered domain — the part that ends in a TLD (.com, .co, .net, .org) and the label immediately before it. For microsoft.com, the registered domain is microsoft.com. Everything else — subdomains, paths, query parameters — can contain any text the attacker wants.
Exam tip: when a URL question presents a long URL with a brand name somewhere in it, find the actual domain first, then evaluate. Ignore everything else until you've located the domain.
The domain of a URL is the registerable portion: in https://[domain]/path, it is the label immediately before the first slash after the protocol. In https://login.microsoft.verify-account.co/signin, the domain is verify-account.co — not microsoft.com. "login.microsoft" is a subdomain of verify-account.co, which the owner of verify-account.co controls completely.
Attackers deliberately include the target company's name as a subdomain to fool users who read URLs casually: login.microsoft.verify-account.co, secure.paypal.account-update.net, account.bankofamerica.security-alert.com. These all contain real brand names — none belong to the real organizations.
The only trustworthy part of a URL is the registered domain — the part that ends in a TLD (.com, .co, .net, .org) and the label immediately before it. For microsoft.com, the registered domain is microsoft.com. Everything else — subdomains, paths, query parameters — can contain any text the attacker wants.
Exam tip: when a URL question presents a long URL with a brand name somewhere in it, find the actual domain first, then evaluate. Ignore everything else until you've located the domain.
Trick 2: "HTTPS means a website is safe to enter credentials." True or False?
FALSE — HTTPS means the connection is encrypted, not that the site is legitimate.
HTTPS certificates are free (Let's Encrypt issues them at no cost, fully automated) and can be obtained by anyone for any domain they control — including attackers who register phishing domains. Getting an HTTPS certificate for phishing-login-microsoft.com takes about 90 seconds and costs nothing.
The padlock icon means: your connection to this server is encrypted in transit. Your credentials will be securely transmitted — to the attacker. The encryption protects the data from being intercepted by a third party; it says absolutely nothing about whether the server receiving the data is legitimate.
A phishing site with HTTPS will have a valid certificate for its (fake) domain. The padlock is green. The connection is encrypted. Your credentials arrive safely at the attacker's server.
What HTTPS and the padlock DO NOT tell you: whether the domain is the legitimate one. That is the user's responsibility to verify by checking the actual domain in the address bar.
Exam tip: any answer that equates "HTTPS" or "the padlock" with "safe" or "legitimate" is wrong. HTTPS only means encrypted transit.
HTTPS certificates are free (Let's Encrypt issues them at no cost, fully automated) and can be obtained by anyone for any domain they control — including attackers who register phishing domains. Getting an HTTPS certificate for phishing-login-microsoft.com takes about 90 seconds and costs nothing.
The padlock icon means: your connection to this server is encrypted in transit. Your credentials will be securely transmitted — to the attacker. The encryption protects the data from being intercepted by a third party; it says absolutely nothing about whether the server receiving the data is legitimate.
A phishing site with HTTPS will have a valid certificate for its (fake) domain. The padlock is green. The connection is encrypted. Your credentials arrive safely at the attacker's server.
What HTTPS and the padlock DO NOT tell you: whether the domain is the legitimate one. That is the user's responsibility to verify by checking the actual domain in the address bar.
Exam tip: any answer that equates "HTTPS" or "the padlock" with "safe" or "legitimate" is wrong. HTTPS only means encrypted transit.
Trick 3: "Implementing SPF and DKIM is sufficient to prevent email spoofing of your domain." True or False?
FALSE — without DMARC, SPF and DKIM are authentication without enforcement.
SPF and DKIM perform their checks when an email arrives. If an email claiming to be from yourcompany.com fails SPF (sent from an unauthorized server) or fails DKIM (signature invalid or absent), those failures are recorded. But what happens next? Without a DMARC record, each receiving mail server makes its own decision — and the default behavior in most implementations is to deliver the email anyway, perhaps with a slightly lower reputation score.
DMARC is the policy layer. It says: "When you see an email from my domain that fails SPF or DKIM, here is what to do: none / quarantine / reject." Without DMARC at quarantine or reject, all authentication checks are informational only — they identify spoofed emails but don't stop them.
The complete protection sequence requires all three: SPF (defines authorized senders) + DKIM (cryptographically validates emails) + DMARC(reject) (enforces the policy — blocked emails don't reach inboxes).
Exam tip: whenever a question presents SPF + DKIM without DMARC, the correct answer is that spoofed emails are still being delivered. DMARC is what converts authentication failure from "logged" to "blocked."
SPF and DKIM perform their checks when an email arrives. If an email claiming to be from yourcompany.com fails SPF (sent from an unauthorized server) or fails DKIM (signature invalid or absent), those failures are recorded. But what happens next? Without a DMARC record, each receiving mail server makes its own decision — and the default behavior in most implementations is to deliver the email anyway, perhaps with a slightly lower reputation score.
DMARC is the policy layer. It says: "When you see an email from my domain that fails SPF or DKIM, here is what to do: none / quarantine / reject." Without DMARC at quarantine or reject, all authentication checks are informational only — they identify spoofed emails but don't stop them.
The complete protection sequence requires all three: SPF (defines authorized senders) + DKIM (cryptographically validates emails) + DMARC(reject) (enforces the policy — blocked emails don't reach inboxes).
Exam tip: whenever a question presents SPF + DKIM without DMARC, the correct answer is that spoofed emails are still being delivered. DMARC is what converts authentication failure from "logged" to "blocked."
Trick 4: "Phishing-resistant MFA and regular MFA (like SMS OTP or TOTP apps) provide equivalent protection against phishing." True or False?
FALSE — regular MFA can be relayed in real time; phishing-resistant MFA cannot.
Regular MFA (SMS OTP, TOTP apps like Google Authenticator or Microsoft Authenticator) generates time-based codes that are valid for 30–60 seconds. In an AiTM (Adversary-in-The-Middle) attack, the attacker's phishing site proxies the real service in real time. The victim enters their password AND their TOTP code — both are immediately forwarded by the attacker's proxy to the real service, logging in before the code expires. The attacker captures the resulting session token, which remains valid far longer than the TOTP code.
SMS codes have additional weaknesses: SIM swapping (attacker ports your phone number to their SIM), SS7 protocol vulnerabilities, and smishing attacks that request codes directly.
Phishing-resistant MFA (FIDO2/WebAuthn hardware security keys such as YubiKey, passkeys) works fundamentally differently: the authentication is cryptographically bound to the origin of the authentication challenge. During login, the real site issues a challenge that includes its domain. The hardware key signs that challenge — and the response only validates for that exact domain. A phishing site cannot impersonate the challenge because it cannot forge the origin. Even if the attacker has a real-time proxy, the challenge from their site does not match microsoft.com, and the hardware key simply won't respond to it.
Phishing-resistant MFA credentials are mathematically impossible to harvest on a phishing site, regardless of attacker sophistication.
Regular MFA (SMS OTP, TOTP apps like Google Authenticator or Microsoft Authenticator) generates time-based codes that are valid for 30–60 seconds. In an AiTM (Adversary-in-The-Middle) attack, the attacker's phishing site proxies the real service in real time. The victim enters their password AND their TOTP code — both are immediately forwarded by the attacker's proxy to the real service, logging in before the code expires. The attacker captures the resulting session token, which remains valid far longer than the TOTP code.
SMS codes have additional weaknesses: SIM swapping (attacker ports your phone number to their SIM), SS7 protocol vulnerabilities, and smishing attacks that request codes directly.
Phishing-resistant MFA (FIDO2/WebAuthn hardware security keys such as YubiKey, passkeys) works fundamentally differently: the authentication is cryptographically bound to the origin of the authentication challenge. During login, the real site issues a challenge that includes its domain. The hardware key signs that challenge — and the response only validates for that exact domain. A phishing site cannot impersonate the challenge because it cannot forge the origin. Even if the attacker has a real-time proxy, the challenge from their site does not match microsoft.com, and the hardware key simply won't respond to it.
Phishing-resistant MFA credentials are mathematically impossible to harvest on a phishing site, regardless of attacker sophistication.
Trick 5: "A spear phishing email sent from a compromised legitimate email account can be detected by checking the sender's email domain." True or False?
FALSE — if the attacker has compromised a legitimate account, all technical email authentication checks pass.
A phishing email sent from a compromised legitimate account (account@realcompany.com) has the following properties: it comes from the real domain (SPF check passes — the sending server is authorized), it is signed with the real domain's DKIM key (DKIM check passes — the signature is valid), DMARC check passes (both SPF and DKIM passed). The display name is the real person's name. The email address is the real email address. There is no cousin domain to detect.
This is why process controls are essential alongside technical controls. The technical email authentication stack is designed to prevent impersonation from outside — it cannot detect an insider or a compromised legitimate account.
The only defenses that work here: (1) Behavioral analysis — does this email request something unusual for this sender? Wire transfers, credential requests, and urgent confidential requests from otherwise-normal contacts should trigger manual verification. (2) Process controls — policies requiring independent verification of sensitive requests regardless of who they appear to come from. Call the person at their known number. Verify through a different channel than the one the request arrived on.
The email being technically authentic only proves the sending account is real — it says nothing about whether the human in control of that account is who they claim to be or whether the request is legitimate.
A phishing email sent from a compromised legitimate account (account@realcompany.com) has the following properties: it comes from the real domain (SPF check passes — the sending server is authorized), it is signed with the real domain's DKIM key (DKIM check passes — the signature is valid), DMARC check passes (both SPF and DKIM passed). The display name is the real person's name. The email address is the real email address. There is no cousin domain to detect.
This is why process controls are essential alongside technical controls. The technical email authentication stack is designed to prevent impersonation from outside — it cannot detect an insider or a compromised legitimate account.
The only defenses that work here: (1) Behavioral analysis — does this email request something unusual for this sender? Wire transfers, credential requests, and urgent confidential requests from otherwise-normal contacts should trigger manual verification. (2) Process controls — policies requiring independent verification of sensitive requests regardless of who they appear to come from. Call the person at their known number. Verify through a different channel than the one the request arrived on.
The email being technically authentic only proves the sending account is real — it says nothing about whether the human in control of that account is who they claim to be or whether the request is legitimate.
Performance Task: An employee at a financial services firm clicks a phishing link and enters their Microsoft 365 credentials on a credential-harvesting site. They report it to the security team 2 hours later. Design the immediate incident response procedure.
Model Answer:
Immediate actions — within 15 minutes of report:
1. Force sign-out of all active sessions for the compromised account from all devices. In Microsoft 365 admin center: Revoke all sessions for the account. This terminates any active attacker session immediately — if the attacker is currently logged in, this kicks them out. Do this first, before anything else.
2. Reset the account password to a new, unique, complex password. Do NOT communicate the new password to the employee via email — if the attacker still has email access (in the 15 minutes before the session revocation propagates), they could intercept it. Communicate the new password via phone or in person.
3. If MFA was not enabled, enable it NOW before restoring any access. If TOTP-based MFA was enabled, check the audit log — the attacker may have used the credentials before the code expired, or may have added a new MFA method (authenticator app) to maintain access after a password reset. Check for newly added MFA devices.
First hour — investigation:
4. Review the account's complete audit log for the 2-hour window: what emails were sent from this account (BEC attempts, data exfiltration)? What files were accessed or downloaded? What OAuth applications were authorized? What inbox rules were created?
5. Specifically check for email forwarding rules — this is the most common attacker persistence mechanism. An attacker who has 2 hours of access will frequently add a rule that silently forwards all incoming email to an external address. This rule persists after a password reset unless explicitly removed. Find it and delete it.
6. Check for newly authorized OAuth applications — these can maintain persistent access even after a password reset if not revoked.
7. Review login history: from what IP addresses, what geographic locations, what devices? Confirm compromise and document for the incident report.
Within 24 hours:
8. Full review of what data the attacker could have accessed with this account's permission level. If the employee had access to sensitive client data, assume it was exfiltrated and assess notification obligations.
9. Check if any emails were sent impersonating the compromised employee — identify recipients and notify them that those emails may be fraudulent.
10. Determine if a broader campaign is in progress — search email logs for other employees who received the same phishing email. If others received it and have not yet reported clicking, proactively reach out.
11. Investigate the phishing site: what domain was used, who registered it, is it still active (submit for takedown), what other organizations might it be targeting?
12. Mandatory MFA enrollment for the affected employee as a condition of restored access. Consider upgrading to phishing-resistant MFA (hardware key) for this account given the demonstrated risk.
13. Document the complete incident timeline for regulatory reporting if required — two hours of unauthorized access to a financial services account with client data access may trigger notification obligations.
Immediate actions — within 15 minutes of report:
1. Force sign-out of all active sessions for the compromised account from all devices. In Microsoft 365 admin center: Revoke all sessions for the account. This terminates any active attacker session immediately — if the attacker is currently logged in, this kicks them out. Do this first, before anything else.
2. Reset the account password to a new, unique, complex password. Do NOT communicate the new password to the employee via email — if the attacker still has email access (in the 15 minutes before the session revocation propagates), they could intercept it. Communicate the new password via phone or in person.
3. If MFA was not enabled, enable it NOW before restoring any access. If TOTP-based MFA was enabled, check the audit log — the attacker may have used the credentials before the code expired, or may have added a new MFA method (authenticator app) to maintain access after a password reset. Check for newly added MFA devices.
First hour — investigation:
4. Review the account's complete audit log for the 2-hour window: what emails were sent from this account (BEC attempts, data exfiltration)? What files were accessed or downloaded? What OAuth applications were authorized? What inbox rules were created?
5. Specifically check for email forwarding rules — this is the most common attacker persistence mechanism. An attacker who has 2 hours of access will frequently add a rule that silently forwards all incoming email to an external address. This rule persists after a password reset unless explicitly removed. Find it and delete it.
6. Check for newly authorized OAuth applications — these can maintain persistent access even after a password reset if not revoked.
7. Review login history: from what IP addresses, what geographic locations, what devices? Confirm compromise and document for the incident report.
Within 24 hours:
8. Full review of what data the attacker could have accessed with this account's permission level. If the employee had access to sensitive client data, assume it was exfiltrated and assess notification obligations.
9. Check if any emails were sent impersonating the compromised employee — identify recipients and notify them that those emails may be fraudulent.
10. Determine if a broader campaign is in progress — search email logs for other employees who received the same phishing email. If others received it and have not yet reported clicking, proactively reach out.
11. Investigate the phishing site: what domain was used, who registered it, is it still active (submit for takedown), what other organizations might it be targeting?
12. Mandatory MFA enrollment for the affected employee as a condition of restored access. Consider upgrading to phishing-resistant MFA (hardware key) for this account given the demonstrated risk.
13. Document the complete incident timeline for regulatory reporting if required — two hours of unauthorized access to a financial services account with client data access may trigger notification obligations.