Have you ever heard of a so-called browser-in-a-browser attack? This is a resourceful phishing method that hackers increasingly use to try to get hold of your passwords and thus gain access to the corresponding IT systems. But what sounds quite simple at first, then requires a bit more explanation for complete understanding.
What is a browser-in-a-browser attack?
We have reported on phishing and ways to make phishing attacks work more than once by now. Phishing is and remains a major issue, especially in small and medium-sized enterprises. There, employees are quite often not sufficiently trained and therefore offer the greatest opportunities to use phishing as a gateway for possible attacks on the IT infrastructure.
But how does the browser-in-a-browser attack fit into the picture, and what exactly is meant by it anyway? A browser-in-a-browser attack, which, by the way, is often simply referred to as a BITB or BITB attack, is an attack that fakes a browser in the browser. Sounds really strange, but it’s actually quite simple and yet quite clever.
Namely, the browser-in-a-browser attack pretends that there is an additional browser window. And it does so by displaying the same on the website itself. Namely, as a kind of pop-up, which looks deceptively real and looks exactly like a browser window. But let’s take a closer look.
How the browser-in-a-browser attack works
The security researcher who publicized the possibility (more on him later) presented an example in which he relied on the OAuth login process. You do not need to create a new account to log in with it. Instead, users use an existing account, such as one from Google or Facebook. However, this can be dangerous, as the browser-in-a-browser attack shows.
After the click, a new browser window opens for the login, and it is precisely this window that can be faked. Moreover, if it is skillfully made, it hardly differs from the original. Although such OAuth logins get a corresponding token from Google and Co. in the original, the hacker does not need it in such a case.
Rather, only the form is faithfully reproduced. This even goes as far as simulating the Google URL including the security lock for HTTPS. So it seems that the login on the website is a legitimate one. In reality, however, it is a phishing attempt to grab corresponding passwords and usernames.
What this looks like exactly is shown in an article on the blog of mr.d0x, who, by the way, is an Infosec researcher and pentester. Just take a look, there is also an example in moving image. Fascinating how deceptively real the fake browser window appears.
Protection against browser-in-a-browser attacks
The most important thing, as is so often the case with phishing, is to know that such attacks exist at all, especially in these days of increasingly sophisticated attacks. If you know that such windows can be a fake, you can check them accordingly and make sure that it is not a phishing attempt and thus not a malicious attack even before logging in.
The second point is that such browser-in-a-browser attacks are possible only on websites that the hacker gains access to. So large websites should be excluded from this. However, this would be quite conceivable for smaller ones, which is why such login methods should perhaps not be trusted everywhere.
The pop-up for the login is also, unlike the real login of OAuth, not a browser window, but just a pop-up. So it doesn’t exist as a window in the system either, it just looks like one. Since it opens on the website, you usually do not notice this and can move the same. However, it cannot be moved out of the browser, as would be possible with a real browser window, but only within the website. This is a clear indication of the fake.
Therefore, in the case of the browser-in-a-browser attack, it can be seen that a phishing attack is taking place here. The problem with the browser-in-a-browser attack is that you do not suspect it and therefore do not pay attention to the window or even check it again.
Conclusion
To successfully perform a browser-in-a-browser attack, hackers need access to the website in question. Moreover, while the browser-in-a-browser attack is hard to detect, it is also not as easy to exploit as it may sound at first. Some password managers check the URL and as long as addresses are not faked, another one must be used here. The password is therefore not entered automatically. If two-factor authentication is also activated, the password is of no help to the attackers in the end. Especially with Google and Co. this is often active, which is why the accesses do not necessarily bring much. If hardware tokens are then in use, success is almost impossible.
However, you should still provide education in your company. Whenever such a login occurs, it should be checked separately. This is not difficult, and just with the knowledge in the back of your mind that it could be a fake, browser-in-a-browser attacks are usually easy to detect.
