30 Years of Phishing — and We're Still Clicking

Phishing is older than most security frameworks designed to stop it. What began in AOL chat rooms in the mid-1990s has matured into an industrial-scale threat, bypassing multi-factor authentication (MFA), harvesting session tokens, and operating inside trusted environments. Despite three decades of investment in email security, user training, and authentication controls, phishing remains the leading initial access vector [1].

The reason is quite straightforward: phishing exploits trust, not technology. That principle has not changed since the first attackers impersonated AOL support staff to collect passwords. What has changed is the sophistication of how that trust is weaponised.

The birth of industrialised phishing

Early phishing was handmade and opportunistic. Attackers posed as AOL service representatives in chat rooms, sending instant messages that asked users to “verify” their account by replying with their password. It worked often enough to attract imitators, but low sophistication and automation made phishing impractical at scale.

That changed in 1995 with a piece of software called AOHell, a toolkit built by a teenage programmer known as “Da Chronic.” AOHell bundled several attack capabilities into a single Windows application: it could automatically generate fake AOL accounts, mass-mail phishing messages to chat room participants, and steal stored credentials. For the first time, someone with no programming ability could run phishing campaigns at volume. AOL eventually sued and shut down distribution, but the damage was conceptual and ideological: AOHell demonstrated that social engineering could be industrialised. Copycat tools followed, and the approach migrated from AOL to email, where it found a far larger attack surface.

Phishing kits and the race against email security

As online banking, e-commerce, and SaaS platforms emerged through the early 2000s, spammers followed the money. Attackers built convincing replicas of bank login pages and registered lookalike domains — paypa1.com, ebay-security.com — to harvest credentials at scale. Phishing kits emerged: pre-packaged archives containing cloned website templates, credential-logging scripts, and deployment instructions. An attacker could stand up a fictitious banking portal in minutes without writing a single line of code. These kits circulated freely on underground forums and lowered the barrier to entry with each generation.

The defender response came in waves. Email providers introduced spam filters and blacklists. The Anti-Phishing Working Group (APWG), founded in 2003, began coordinating takedowns of phishing domains. Browsers added phishing warnings based on URL reputation lists. Financial institutions rolled out one-time passwords and SMS verification codes.

Each countermeasure forced an adaptation. When static spam filters learned to catch bulk phishing emails, attackers moved to spear phishing, smaller and targeted campaigns crafted with personal details scraped from multiple open sources or breaches. When domain blacklists became effective, attackers began compromising legitimate websites to host phishing pages, or abused cloud services like Azure Blob Storage and Google Sites that could not easily be blocked without collateral damage. When URL reputation checks flagged known bad domains, attackers adopted URL shorteners, open redirects on trusted sites, and QR codes that bypassed link inspection entirely [3, 4].

Sender authentication — and its limits

The sender authentication protocols SPF, DKIM, and DMARC addressed email spoofing directly by allowing domain owners to declare which servers were authorised to send on their behalf. Adoption grew steadily through the 2010s, and spoofing of protected domains became harder. But attackers did not need to spoof.

To successfully deliver phishing messages, attackers could resort to compromised email accounts, legitimate cloud platforms, and newly registered domains instead of spoofing. The messages still came from a real server, passed authentication checks, and landed in the inbox.

MFA bypass and session hijacking

On the authentication front, Multi Factor Authentication (MFA) was introduced as a major defensive layer. By requiring a code from an authenticator app, a hardware key, or a mobile notification, MFA aimed to make stolen passwords insufficient for account takeover. For several years, it raised the cost of credential-based attacks significantly.

Attackers responded with phishing-as-a-service (PhaaS) platforms that automated MFA bypass. They automatically spin up phishing sites that sit between the victim and the real login page, relaying credentials and MFA codes in real time while capturing the resulting session token [5, 6]. This technique, coined adversary-in-the-middle (AiTM) phishing, does not defeat MFA in a cryptographic sense. It simply completes the authentication flow on the attacker’s behalf and steals what comes out: a valid session cookie. OAuth consent phishing achieves a similar outcome through a different path, tricking users into granting persistent application-level access [2].

The infostealer economy

AiTM and OAuth abuse require the attacker to run a campaign, to craft a lure, stand up infrastructure, and wait for someone to click. But what if the session tokens are already available for purchase?

That is the reality created by commodity infostealers. Malware families like Raccoon, RedLine, and Lumma run silently on infected machines, harvesting browser cookies, saved passwords, and active session tokens. The stolen data is exfiltrated to centralised command-and-control infrastructure and listed on dedicated marketplaces, sometimes within minutes of capture [1, 6]! A buyer selects a target organisation, pays a few dollars, and receives a valid session that grants immediate access. No phishing email required. No fake login page. No interaction with the victim at all.

The pattern across three decades is consistent: for each defensive layer, attackers found a way around it. Spam filters pushed attackers toward targeted campaigns. Domain controls pushed them toward compromised infrastructure. MFA pushed them toward session hijacking.

The post-login blind spot

Every countermeasure operates on the same side of the boundary: before the click, before the login, before the session is established. These controls reduce the volume of successful attacks, but they cannot eliminate them. The 30-year pattern shows that attackers consistently find ways past that boundary.

The problem lies in what happens after a successful click.

Once an attacker holds a valid session, security systems generally treat the activity as legitimate. The operating assumption breaks down in the face of stolen tokens and hijacked sessions [7, 8]. Some signals, such as impossible travel or anomalous access patterns, may eventually trigger alerts.

Behavioural analytics are inherently probabilistic: they model what “normal” looks like and flag deviations, which means they generate false positives, require extensive tuning, and often detect compromise only after the attacker has already moved laterally, escalated privileges, or exfiltrated data [9, 10].

There is no continuous verification layer between initial authentication and resource access. That gap is where attackers operate. The question is not how to build a better wall. It is how to detect an attacker who is already inside.

Turning deception against the attacker

Cyber deception approaches this problem from a fundamentally different angle. Rather than trying to distinguish attacker behaviour from legitimate behaviour (a task that grows harder as attackers learn to mimic normal patterns) deception places something in the environment that has no legitimate reason to be touched. Fake credentials, fake accounts, fake documents, fake infrastructure. These decoys serve no operational purpose. No user needs them. No system depends on them. They exist for one reason: any interaction with them is proof of unauthorised activity [11, 12].

This inverts the detection model. Instead of asking “does this session look suspicious?”, a question with inherently fuzzy answers, deception asks “did someone touch the tripwire?”. The answer is a binary true-or-false statement. There is no threshold to tune, no baseline to maintain, and no false-positive noise to filter.

Consider what this means for the specific post-login threats described earlier. An attacker who has phished a valid session token will explore the environment: enumerate accounts, browse file shares, and search for credentials to move laterally. Deception places traps precisely along those paths:

• Honey accounts seeded in Active Directory or cloud identity providers look like high-value targets such as administrative accounts or service accounts with broad permissions. Any authentication attempt against them is an immediate compromise indicator, because no legitimate process ever uses them [12].
• Honeytokens fictitious API keys, database credentials, or internal documents are placed where an attacker conducting reconnaissance would naturally find them: in configuration files, shared drives, code repositories. When these tokens are used, the defender knows not only that a breach has occurred, but where the attacker is looking and what they are after [13, 14].
• Decoy infrastructure fictitious file servers, internal applications, or data repositories beg for lateral movement. An attacker pivoting through a compromised environment has no way to distinguish real infrastructure from decoys without interacting with them, and that interaction is the alert [11].

None of these controls affect legitimate users. They impose no friction, require no training, and generate no noise during normal operations. They activate only when someone does something that no authorised user or system would ever do.

Fighting deception with deception

Phishing succeeds through deception: presenting something false as something trusted. The same principle, inverted, can expose attackers operating inside environments they should not have reached.

Prevention remains essential. Email security, authentication controls, and user training reduce the attack surface. But they are not sufficient. Post-login environments where stolen sessions are used, where lateral movement occurs, and where data is accessed require their own detection layer.

Cyber Deception provides that layer. It does not replace existing controls; it closes the gap between successful initial access and eventual detection. Honeytokens, decoy accounts, and identity traps shift the detection model from pattern matching to proof of misuse.

After 30 years, phishing has evolved in method but not in principle. Defence can do the same by turning the attacker’s own technique against them and exploiting the one thing the attacker cannot pivot from: their motives.

Follow our blog for updates on this line of research.