The phishers are looking for someone to click on link that takes them to a compromised server that hosts a replica of the login service that they are trying to get your credentials to (banking, Office365, Google, etc.) In properly configured organizations there are often tools to block the user from going to the compromised site. Most of these controls use URL checking and reputation checking of the server that the link points to.
What happens if someone can present a URL and server that passes the checks, but still shows a page that gives the attacker access to the credentials being entered? This is the concept behind the Browser-in-the-Browser attack. According to a security researcher who goes by the handle mr.d0x the concept takes advantage of the use of pop-up windows for third party authentication services via single sign on (SSO) experiences.
Using HTML/CSS the attacker can replicate the sign in page almost to perfection and if the fake page is inside of an iframe that points to an attacker controlled server you complete the set. At least the set for the actual collection of credentials, you still need to convince the target to click on the link that is supposed to take them to the site in the first place. mr.d0x says that this is also easy to accomplish using JavaScript. One way that users are taught to check for phishing attempts is by hovering over a link and checking to make sure it goes there it is supposed to. If you are trying to get to Google and instead the link takes you to bob’s surf shop, you know it might be fake. If you can slip Javascript into your phishing template, you can get around this though.
By slipping in a simple return false onclick event the button or link will still return the current and legitimate URL but will ignore the href URL and launch the malicious site the attacker wants you to see. This type of obfuscation of the intended site and page is very effective at fooling users into thinking they are clicking on the proper link. The attacker can also make their popup display the expected URL at the top to further confuse the matter. It is a slick work around to most user driven phishing prevention methods.
The attacker just needs to get the user to a page that is hosted by a server they control so that they can present the obfuscated and poisoned links. The initial pivot might not be as easy to fake as the login screens, but considering the number of incidents that involve phishing, it is not too much of a stretch to believe that will not be too much of a challenge.
