Unit Scenarios
Scenario 1A: Phishing Email Analysis
The Email
A message arrives claiming to be from "The Google Drive Team," saying a student requested access to copy a document and that the teacher needs to click a link to authorize it, warning that if they don't, the student won't be able to finish their assignment, and tossing in a line about how "research shows" faster teacher responses lead to more on-time submissions.
Phishing Indicators
Suspicious sender address: the domain uses zeros instead of the letter "o" (like
g00gle.com instead of google.com), a classic typosquatting trick that mimics a real company's domain.Urgency tactics: "Urgent" right in the subject line, plus a threat that the student won't finish their assignment, which pushes the teacher to act fast without thinking it through.
Vague details: no student name, no document name, just a generic message that could apply to literally anyone.
Authority appeal: claims to be the "Google Drive Team" to borrow trust from a service people already rely on.
Fear of consequences: implies the teacher is the one blocking the student's progress, playing on their sense of responsibility.
Manipulative statistics: throwing in a fake "research shows" line to seem more legitimate and nudge a quicker response.
Psychological Manipulation Elements
Urgency forces quick action and blocks careful thinking. Authority borrows trust by impersonating Google. Responsibility plays on the teacher not wanting to hurt the student's grade. Social pressure implies that a good teacher would respond quickly.
Potential Consequences of Clicking
Clicking could lead to credential theft through a fake Google login page that captures the username and password, which then hands the attacker access to the teacher's actual Google account, including student grades, personal info, emails, and stored documents with sensitive school data. It could also install malware, be used to launch further phishing attacks against students, colleagues, or parents, or expose student data that's protected under FERPA.
Scenario 1B: Unauthorized Login Detection
The Login Log
A student plays an online game where players create and manage virtual teams. One day they notice that some of their earlier choices were changed without their knowledge. The account activity section lists every time the account was accessed. The student normally logs in on weekends and in the evenings, when they're not in school. Here's part of that list:
Entry Date/Time Device IP Address 1 Saturday April 18 10:43 208.104.29.211 2 Sunday April 19 20:51 208.104.29.211 3 Tuesday April 21 18:34 208.104.29.211 4 Wednesday April 22 11:13 142.54.195.17 5 Saturday April 25 13:21 208.104.29.211 6 Sunday April 26 21:18 208.104.29.211 7 Monday April 27 10:07 142.54.195.17 8 Wednesday April 29 19:12 208.104.29.211
What the log tracks: an entry number, the date and time of each login, and the IP address of the device that logged in.
Suspicious Patterns
Normal pattern: six of the eight logins (entries 1, 2, 3, 5, 6, and 8) come from the same IP address,
208.104.29.211, on weekends or weekday evenings (18:34 is 6:34 PM and 19:12 is 7:12 PM). That matches when the student actually plays, so those are almost certainly the student.Unusual times: entries 4 (Wednesday at 11:13 AM) and 7 (Monday at 10:07 AM) happen on weekday mornings, when the student is in school.
Unknown device: entries 4 and 7 also come from a different IP address,
142.54.195.17, that never shows up anywhere else in the log. Two logins at odd times from an unfamiliar device are the suspicious entries.What Happened
Someone else logged in to the student's account twice, on Wednesday April 22 and Monday April 27, and changed the student's choices. Both logins show signs of a password attack: they happened at unusual times and came from an unknown device. Both logins also worked, so the adversary had the password. They might have guessed a weak one built from personal details, used one stolen in a data breach of another site where the student reused it, or tricked the student into giving it up through phishing.
What to Do
Right away: change the password to one that's long, random, and unique, and sign out of all other devices if the game has that option. If the same password was used on any other site, change it there too.
For the long term: turn on multifactor authentication (MFA) so a password alone isn't enough to get in, use a password manager or a long passphrase so every account has its own strong password, and check the account activity log now and then for logins you don't recognize.
Scenario 1C: Evil Twin Attack
What Happened
At a neighborhood coffee shop, a friend joins a network called "Guest Wi-Fi." It sends them to a captive portal (the sign-in page some Wi-Fi networks show before letting you online) that offers to let them sign in with their account for a popular online platform. They enter that username and password and get online. Later, their streaming music stops, they've been logged out, and their password no longer works. Then they notice a sign on the wall: "Login to our free Wi-Fi network: Sunshine Coffee Wi-Fi." The shop's real network was "Sunshine Coffee Wi-Fi." "Guest Wi-Fi" was a fake network set up by an attacker to trick customers.
How the Attack Played Out
The attacker set up their own wireless access point with a generic name that sounds official, "Guest Wi-Fi," so customers would assume it belonged to the shop. When the friend joined, the attacker's network showed a fake captive portal. Typing their platform username and password into it handed both straight to the attacker. The attacker didn't need to read any encrypted traffic, since the friend gave the password to the attacker's own page. The attacker then used those credentials to log in to other services linked to the same platform login, including the music service, and changed the password, locking the friend out. This kind of attack usually only takes low-skilled tools that are pretty easy to set up.
How to Prevent This
Always confirm the exact network name before joining. Here the sign listed "Sunshine Coffee Wi-Fi," so checking posted signs or asking staff would have shown that "Guest Wi-Fi" wasn't the shop's network. Be careful with any Wi-Fi sign-in page that asks for your login to another platform, since a fake portal is an easy way to collect passwords. Turning on multifactor authentication (MFA) for the platform account could have stopped the attacker from using the stolen password. And using cellular data instead of unknown Wi-Fi is safer for anything sensitive. A VPN helps once you're online, but it can't protect a password you type into the attacker's own sign-in page.
What Else Might Be at Risk
Every service linked to that same platform login is at risk, not just the music app: email, social media, school or work accounts, shopping sites with saved payment info, and cloud storage could all be opened with the one stolen password. That's the trade-off of using one platform to log in to many services. It's convenient (one password to remember and quick sign-ups), but if that one login is stolen, the attacker can get into everything linked to it. Strong MFA on the platform account lowers that risk.
Compromised email could expose personal conversations, let someone reset passwords on other accounts, and hand over a contact list for more phishing. Banking access could mean someone viewing balances, moving money, or grabbing credit card info. A hijacked social media account could be used to impersonate the victim, post harmful content, spread malware to friends, or read private messages. And compromised school or work accounts could expose grades, assignments, or confidential organizational data.
Scenario 1D: AI Voice Cloning Scam
What Happened
Someone gets a frantic call from a relative asking about money and trouble, claiming to have been arrested and needing bail. In reality, that person was never arrested, never called, and never left home. When told this, the relative insists, "it sounded exactly like you."
How the Attack Was Built
About two weeks earlier, the attacker sent a fake friend request mimicking a real classmate's name, and the victim accepted without checking. That gave the attacker access to social media content. From there, they downloaded video posts and pulled voice samples, and some AI tools need only a few seconds of clear audio to work with (more audio makes a more convincing clone). Those samples went into an AI voice cloning tool, which built a synthetic voice model that could say anything in that person's voice. The attacker then researched the victim's relatives through social media, called one of them using the cloned voice, invented an emergency about being arrested, created urgency around needing bail money right away, and asked for a wire transfer since those are hard to trace or reverse.
How Voice Cloning Works
The AI analyzes pitch, tone, speaking pace, rhythm, accent, and even emotional inflections from just a short clip of audio, then generates a synthetic version of that voice. These tools are publicly available, some built for legitimate use, some not.
Warning Signs
An unusual request for money by wire transfer, high pressure urgency to send it immediately, a story that doesn't line up (like an arrest with no prior contact from any actual authorities), a call instead of a more typical communication method, and a payment method like wire transfer or crypto that's hard to reverse.
How to Protect Against This
If you want to limit your own exposure, review your social media privacy settings, restrict who can see videos with your voice in them, and think twice before posting voice or video content publicly. Be cautious about accepting friend requests from people you don't actually know, and watch for fake profiles with recent creation dates or very few posts.
If you're worried about being targeted through a relative, set up a verification protocol ahead of time, like a secret code word that only your family knows to use during a real emergency, and always call the person back on their known number before sending any money. Verify through an independent channel, like calling them directly or checking with other family members, or contacting authorities directly to confirm any claimed arrest. Recognize urgency as a manipulation tactic, since a real emergency usually still allows time to verify. And question anything odd, like why a wire transfer instead of paying bail directly, or why they called you instead of a parent.
Bigger Picture
Voice and video can no longer be trusted on their own for identity verification. We need new ways to verify people beyond just recognizing their voice. Public social media content gives attackers raw material to build these deepfakes, which makes awareness and education about this threat really important.
Scenario 1E: AI-Assisted Security Review
The Situation
A company is building a customer-facing web app where customers place orders online, the app automatically checks a warehouse inventory database, shows real-time availability, and updates the database when something is purchased. Before launch, an AI tool reviews the code for security issues.
What the AI Found
The AI flagged that user input fields were being copied directly into database requests, a classic SQL injection vulnerability. That means an attacker could learn what's in the warehouse inventory, modify the database (deleting records, changing prices, faking orders), pull sensitive customer data, or otherwise mess with the database's integrity. The AI's recommendation was to validate and sanitize user input before it ever touches a database query.
How the Workflow Should Go
Code gets written, then AI reviews it for security issues, then a human developer reviews the AI's findings, then it goes to a testing environment, and only then to production.
The human review step matters a lot here: developers need to evaluate whether the AI's suggestions actually make sense, confirm the fixes don't break anything, make sure the fix follows real best practices, and adapt it to fit the specific app. Then it needs to be tested in a staging environment to catch anything before it goes live.
Why AI Code Review Helps
It's fast, scanning thousands of lines almost instantly compared to hours or days for a human. It's consistent and doesn't get tired or miss things from fatigue. It checks against huge databases of known vulnerabilities, runs any time of day, and cuts down the need for expensive manual audits.
Where AI Code Review Falls Short
It can flag legitimate code as a false positive. It doesn't understand business logic or why the code was written a certain way. It's limited to patterns it already knows, so it can miss genuinely new kinds of vulnerabilities. It suggests fixes without understanding what the developer actually intended, it's only as good as what it was trained on, and it can't replace human judgment about what level of risk an organization is willing to accept.
Why Human Review Still Matters
Developers understand what the code is actually supposed to do, they can tell real vulnerabilities apart from AI false alarms, they know whether a suggestion fits the actual framework and architecture, they can catch a fix that solves one problem but creates another, they keep the code readable and maintainable, and they're the ones who actually verify everything works as intended.
For example, if the AI recommends just removing user input from database queries entirely, a developer would recognize that this breaks search functionality, and instead implement parameterized queries that safely handle user input without allowing injection.
Where This Shows Up in Everyday Life
The same "AI helps, human verifies" pattern applies everywhere. Grammarly or ChatGPT can catch spelling and grammar issues in an essay, but you still need to check that the suggestions are accurate and appropriate. GitHub Copilot or similar tools can suggest code fixes or optimizations, but you still need to verify the logic and security. AI calculators can check math and show steps, but you need to actually understand the process rather than just copying the answer. AI can summarize research and find sources quickly, but you still need to verify the facts, check original sources, and avoid plagiarizing. The key idea across all of these: AI assists, it doesn't replace critical thinking and verification.
Unit 1 Summary
Scenario 1A covered spotting phishing through sender analysis, urgency, and thinking through potential impact. Scenario 1B covered reading a login log to spot unauthorized logins at unusual times from an unknown IP address. Scenario 1C covered fake Wi-Fi networks and fake captive portals that steal credentials. Scenario 1D covered AI voice cloning scams and why verification protocols matter. Scenario 1E covered balancing AI-assisted security review with essential human oversight.
The common threads running through all of these: attacks exploit human psychology like urgency, authority, and fear, detection relies on spotting patterns and anomalies, defense comes down to verification, strong authentication, and awareness, AI shows up as both a threat (cloning voices, automating attacks) and a defense (reviewing code), and critical thinking is essential whenever you're evaluating something suspicious or checking AI output.