Yes, I realize the title is a contradiction, but we’ll get to that. Let’s talk about phishing.
Back in the mid-2000s, phishing attacks for us were easier than actual hacking. Most phishing attacks don’t require a working knowledge of how computers work, how data packets are exchanged, or knowledge of vulnerabilities. That is because phishing is a component of the social engineer’s toolkit.
We found a tutorial with step-by-step instructions, complete with the phishing script. Then we would copy and paste the phishing script with the custom HTTP POST request that sent the captured credentials to a dump file on a third-party server into the source code of any login page we downloaded.
One of the stealthy ways we exposed users to the malicious attack vector was to hack a legitimate website and insert a URL redirect into a link, and tell it to open a new tab on the user’s browser whenever they interact with it. However, the best way to obtain hits was merely to send unsolicited emails. So, obtaining email lists was a pretty big deal at the time.
However, another method extant within the era was the ability to craft a malicious link and send it to the victim in an instant messenger. Back then, the attacker could post a link in disguise that said, https://facebook[.]com but actually be something like click2beanidiot[.]com. It was a kind of sleight of hand.
One time, I targeted a wireless access point by setting up a captive portal at a job I worked at, which had a public computer hub. I harvested reams of the information entered by users who fell for my trap.
However, I eventually quit the operation. I ended it when I accidentally met one of my victims after I had thoroughly hacked her website. It’s different when you meet your victims in person, and see the effects of your actions painted on their faces.
Nowadays, phishing is so easy, any money-hungry criminal (I can’t even use the term script kiddie here) can download a program from the GitHub repository, and install and launch a phishing attack with a premade URL to insert in their spam.
But what is traditionally thought of as child's play, doesn’t always stay that way.
New Browser-Based Undetectable Phishing Attack
There’s a new browser-in-the-browser (BitB) phishing exploit that allows bad actors to imitate a browser window that can appear within the victim’s browser. This allows the attacker to spoof an authentic domain in order to lure the unsuspecting into entering their credentials.
This new method abuses third-party single sign-on (SSO) options that are embedded in websites. For example, “Sign in with Google” is one of a handful of SSO options users commonly encounter when authenticating. Facebook, Apple, and Microsoft are also notable.
During the SSO process, users will normally encounter a pop-up window prompting them to complete the authentication process. But the BitB attack is designed to reproduce the process using a combination of HTML and CSS code to create an otherwise fake browser window. The fake browser window then harvests the entered credentials and transmits them off-site to a third-party server.
Under normal circumstances, all the built-in security checks within the browser are designed to detect phishing attempts, such as whether a URL is authentic, has up-to-date security certificates, whether a website is using HTTPS or whether any sort of homograph in the domain, etc.
For example, traditional phishing URLs will either appear similar to the authentic URL or they don’t. However, It’s ideal that the URL closely resembles the authentic URL as possible as a kind of trick of the eye.
But when this new attack vector comes into play, the user may attempt to drag the SSO prompt from the current window being used, but it vanishes beyond the edge of the browser window. This happens because it isn’t an authentic browser pop-up a user typically encounters.
Essentially, it exists as a combination of the window design with an iFrame that’s directed at a malicious server that is hosting the phishing page. This is a problem because it’s not identifiable as fraudulent. Due to JavaScript, the pop-up can appear in a link or button click, on the page loading, and so on.
The Right Conditions for the Attack
As a side note, the use of iFrames goes back quite a bit. We used to use iFrames traditionally to bypass proxy settings on public internet hubs. Basically, it existed as a single page of HTML that wouldn’t normally be flagged by a proxy server.
And within that webpage was another page, complete with an address bar that allowed the user to enjoy unfiltered web searches since the only detectable aspect was the initial webpage and not the iFrame within it.
But I digress. In this instance, the web pages the user visits are, in fact, legitimate, even complete with HTTPS. Nevertheless, when users attempt to remove the pop-up window from their session, it disappears beyond the edge of the window.
This presents the right conditions to escalate the attack surface for launching social engineering attacks. Regardless, the user still needs to be redirected to the actual phishing site in order to capture credentials. This element hasn’t changed.
The important thing to note is thus, because some people I know never learn from the first phishing attack they fall prey to. If you want to avoid finding yourselves in the cross-hairs of cybercriminals, throw your computer away.
An article by
Jesse McGraw
Edited by
Anne Caminer
Comments