Phishing Attack Using Encoded Spaces In URL To Hide Payload
I read an article on how using encoded spaces in the URL could increase the chances of deception on a phishing campaign but it was not until I received an attack similar to it myself that I was able to see more clearly how it operates. It appears that since the bad guys have noticed that most people are not that dumb anymore and actually pay more attention to what the URLs actually contain, they decided to come up with a method that would conceal the real [and complete] URL behind the scheme. Essentially, the method uses the character space [escape encoding %20] as a filler in the URL to push the rest of the contents of it out of sight so that only the initial part remains reasonably visible. The scheme assumes that once the victim lands on the target site, that is where they would pay attention, to make sure they are at theĀ āright placeā.
It started with an innocent looking email asking to accept a refund :)
The email contains a link toĀ āmake a secure online refundā and which, on the source code of the email reveals this:Ā
TheĀ āsecureā link [not secure at all since no SSL is enabled] is using a compromised website in Denmark which, when opened, jumps to another compromised site:
This is where things become interesting as Ā there is a base64 string on the next target of the jump and I can only imagine what that looks like on a browser when presented without restrictions. Here is what it looks like when intercepted:
If it is not intercepted, here is how the URL looks like:
A quick glance shows the URL looking totally normal and it appears that we have landed on a legitimate Bell.ca website. But after a second look, there is something unusual at the beginning of the URL. It reads:
data:text/html;https://....
When I saw this I was like, holy cow, this is not being executed as a URL but it is simply beingĀ displayed as a āvisual labelā to deceive the cautious observer into thinking that he/she has indeed landed on a legitimate URL - in this case monbell.bell.ca, the French language login portal. BUT if this is not being treated as a URL, what is going on here?! IfĀ I would have not intercepted the URL to see what is going on behind the scenes, I would have not noticed that there is actually spaces filling up the rest of the URL field where there appears to be more stuff! look further:
Another base64 encoded string starts after the spaces! Ā If I intercept the scheme and prevent any JS execution, Ā and simply display the URL content, I can see that there is a two-step base64 encoded string carrying out the deception. First the initial string after the second URL jump, which is HUGE:
After decoding the above first string, I start to see where this is going more clearly. The string contains a clever piece of JS code
where it first, ensures that the browser is Chrome and second, uses a variable called āspaceā to build and display the filler I was seeing displayed in the URL. Next to the spaces, there is the second base64 string which when decoded, it contains an HTML page with yet another inner JS script:
This final JS script contains the URL where the victim finally lands to. The interesting thing about this last script is that the code isĀ āPACKEDā using a known function as there is no practical way of easily concealing the purpose of JS code. By using an unpacker, we can finally see the open code at the heart of the scheme and which contains the malicious URL:
Why all this effort? most likely toĀ āflight under the radarā and avoid AV detection and controls that could block the scheme but more importantly, to cleverly fool even the best trained technology user into thinking that they are making sure they are dealing with a legitimate website. You can imagine what happens next.
