When the Browser Lies: Why Seeing Is No Longer Believing
For years, cybersecurity awareness training has given people some very sensible advice.
Check the URL.
Look for the padlock.
Make sure you're on the legitimate website.
Be suspicious of unexpected downloads.
Don't click on something that doesn't look right.
There is nothing wrong with that advice.
The problem is that attackers have been listening too.
And they're getting increasingly good at reproducing the things we've taught people to recognize as signs of legitimacy.
A recent investigation by Huntress provides an excellent example. Its Security Operations Center analyzed two attacks using a technique known as Browser-in-the-Browser, or BiTB. Victims who clicked malicious links were eventually presented with what appeared to be an Adobe webpage prompting them to update Adobe Reader.
The page looked legitimate.
The branding looked legitimate.
The browser window looked legitimate.
The address bar even displayed get.adobe.com, an actual Adobe domain.
Except none of it was what it appeared to be.
The attackers had created an entire fake browser window inside the webpage itself, complete with an address bar, URL, padlock and favicon. What appeared to be the browser's trusted interface was actually content controlled by the attacker.
And that should make anyone involved in identity and authentication uncomfortable.
Because the attacker wasn't merely impersonating Adobe.
The attacker was impersonating trust itself.
Nothing Was Wrong With the Person
This is the part I find particularly interesting.
We spend enormous amounts of money trying to determine whether the person accessing a system is legitimate.
Passwords.
MFA.
Biometrics.
Passkeys.
Device intelligence.
Risk engines.
Behavioral analytics.
All designed, in one way or another, to answer:
“Is this really the person we think it is?”
But in the Huntress incidents, the more interesting question was on the other side of the relationship:
“Is this really the destination the person thinks it is?”
The person could be exactly who they claimed to be.
Their fingerprint could match.
Their face could match.
Their device could be recognized.
Their authentication could be flawless.
And they could still be interacting with an attacker.
That distinction matters.
The Wrong Destination Can Still Reach the Right Person
According to Huntress, after victims followed the fake Adobe instructions, they unknowingly downloaded ScreenConnect installers from attacker-controlled infrastructure. The rogue remote-management software then established persistent access to the endpoints. Huntress ultimately shut down both attacks before they progressed further.
Think about the sequence from the victim's perspective.
They received something that appeared to require action.
They followed a link.
They encountered a familiar brand.
They saw what appeared to be a legitimate browser window.
They saw a legitimate-looking Adobe URL.
They were told that Adobe Reader needed updating.
They followed the instructions.
At several points, the interaction offered visual reassurance.
And those reassurances were all false.
This is why I think we need to reconsider one of the assumptions sitting underneath traditional authentication.
We ask the user to prove themselves cryptographically while often asking them to verify the destination visually.
Those aren't remotely equivalent standards of proof.
“Look More Carefully” Has a Limit
Huntress quite reasonably recommends combining user education with technical controls, including restricting who can install remote-management tools, maintaining approved RMM inventories, monitoring suspicious activity and teaching employees to verify software downloads through trusted channels.
All of those measures make sense.
But there's a larger issue here.
How much responsibility can we reasonably continue placing on the person sitting in front of the screen?
Look more carefully.
Check the URL.
Inspect the certificate.
Recognize the fake.
Notice something unusual.
Don't trust the prompt.
Verify the download.
Call IT if you're uncertain.
The problem is that the visual differences between legitimate and fraudulent interactions are becoming smaller and smaller.
And AI is likely to accelerate that trend considerably.
Attackers don't need every person to make the wrong decision.
They need one person to make one wrong decision once.
That isn't a particularly attractive security architecture.
Trust Shouldn't Depend on How Convincing Something Looks
This is the larger lesson I take from the Huntress investigation.
Trust shouldn't depend on how convincing something looks. It should depend on what can be verified.
That's a significant distinction.
A logo is evidence of appearance.
A URL displayed inside a webpage is evidence of appearance.
A familiar interface is evidence of appearance.
A convincing voice can be evidence of appearance.
A realistic face can increasingly be evidence of appearance.
None necessarily proves identity.
We've spent decades improving our ability to verify the identity of the human.
Perhaps the next challenge is improving our ability to give the human equally meaningful evidence about who or what is requesting their trust.
Authentication Has Traditionally Been One-Sided
Consider what happens during a typical authentication event.
The organization asks:
Who are you?
What do you know?
What do you possess?
Can you provide a biometric?
Is this your device?
Does your behavior look normal?
All reasonable questions.
But what does the person get in return?
Usually, some version of:
Trust us. You're in the right place.
That worked reasonably well when impersonating the destination was difficult.
It's becoming less reliable as impersonation improves.
This is why we believe authentication needs to evolve from one-way verification toward Mutual Trust.
The organization should establish confidence in the user.
But the user should also be able to establish confidence in the organization, destination or request.
Verified User ↔ Verified Destination
Trust should work both ways.
Where Full Duplex Authentication® Enters the Conversation
This asymmetry in traditional authentication is one of the reasons we developed Full Duplex Authentication® (FDA) at Identité®.
FDA was designed around a straightforward premise: authenticating the person should not require the person to blindly trust the destination asking for authentication.
Instead of treating authentication as a one-directional exchange, Full Duplex Authentication establishes a mutual verification relationship.
The organization verifies the user.
The user verifies the destination and authentication request.
That distinction is especially relevant to attacks built around destination impersonation.
Importantly, FDA isn't a replacement for endpoint protection, security awareness, application controls or the other defenses Huntress recommends. Those controls address different portions of the attack chain.
But attacks like Browser-in-the-Browser demonstrate why destination verification deserves a place in the authentication architecture itself.
Had a comparable sensitive authentication or authorization interaction been protected by an architecture requiring cryptographic mutual verification, simply reproducing a convincing browser window, logo, padlock or URL would not establish the required trust relationship.
The attacker could reproduce the appearance.
They could not reproduce the legitimate trust relationship merely by making the screen look right.
That's a much higher bar.
This Is Bigger Than Browser-in-the-Browser
BiTB is only one example.
Consider the direction digital deception is moving.
Phishing sites increasingly reproduce legitimate services.
Attackers impersonate IT support through collaboration platforms.
Deepfake video can reproduce someone's appearance.
AI-generated voices can reproduce someone's speech.
Messages can reproduce someone's writing style.
Fraudulent applications can reproduce legitimate interfaces.
Attackers can even use legitimate remote-management tools once they've convinced someone to install them.
The common thread isn't necessarily malware.
It's impersonation.
And increasingly, the attacker's objective isn't to break trust.
It's to inherit it.
If I can convince you that I am your bank, your employer, your IT department, your software provider or someone you already trust, I may not need to defeat every security control directly.
I may be able to persuade you to help me get around them.
Mutual Trust Changes the Question
Traditional security awareness asks:
“Does this look legitimate?”
Mutual Trust asks:
“Can this be verified as legitimate?”
Those questions may sound similar.
They're fundamentally different.
One relies heavily on human judgment.
The other can increasingly rely on architecture.
And that's where I believe security needs to go.
We shouldn't eliminate security awareness. People should understand threats and exercise reasonable caution.
But our long-term answer to increasingly sophisticated digital impersonation cannot simply be:
Train humans to become better fraud-detection engines.
Attackers have automation.
They have AI.
They have sophisticated social engineering.
They can reproduce interfaces with remarkable accuracy.
The architecture needs to carry more of the burden.
From Recognizing Trust to Verifying Trust
There is a broader lesson here for the identity industry.
For a long time, we've treated identity as something primarily belonging to the person requesting access.
Prove who you are.
That remains essential.
But Digital Trust requires something larger.
The person matters.
The destination matters.
The request matters.
The device matters.
The context matters.
And ultimately, the relationship between them matters.
That is why we continue to believe Verifiable Identity is the cornerstone of Digital Trust.
Not recognizable identity.
Not familiar identity.
Not convincing identity.
Verifiable Identity.
Because the gap between something that looks legitimate and something that actually is legitimate is becoming one of cybersecurity's most important battlegrounds.
Seeing Is No Longer Enough
The Browser-in-the-Browser technique isn't new. Huntress explicitly points that out.
But that's almost beside the point.
The importance of these incidents isn't that attackers invented an entirely new technique.
It's that an existing technique continues to work because it exploits something deeply human:
We trust what looks familiar.
For years, that was often good enough.
Increasingly, it isn't.
So perhaps the next evolution of authentication isn't simply another way for people to prove who they are.
Perhaps it's finally recognizing that the other side of the relationship should have to prove something too.
The organization should know it's really you.
You should know it's really the organization.
That's not more friction.
That's not another password.
That's not another burden we should place on the person.
It's a different architecture for trust.
Because in a world where almost anything can be made to look legitimate, seeing is no longer believing.
Trust must be verifiable.
Trust must be mutual.
Trust must work both ways.
Comments