Hello, welcome to the Tuesday, September 22nd, 2020 edition of the Sandsand and Storm Center's Stormcast. My name is Johannes Ulrich, and today I'm recording from Jacksonville, Florida.

Jan today looked at an interesting fishing attempt that we actually received at our handler email address.

It attempts to overlay a login dialogue to a legitimate page by using iFrames.

And while it sort of almost worked, it was a little bit broken and probably sent to us by mistake.

One mistake was that first of all it didn't fill in a variable that's required.

Now the variable domain, maybe they just misspelled it and it should actually be domain,

but if that's filled in correctly, then the user's email address is essentially sort of

pre-filled as a username and just as for the password.

The other part that didn't really quite work right in this particular attempt is the entire

screen layout.

Seem to be more targeted at mobile device or devices with smaller screens.

This may also be some limited quality control on the attacker's side, then well,

and it's probably no different from real developers.

And I ran to these issues myself where it's really hard to sort of test all the different

browsers and screen resolutions that users use to visit your site.

So, yep, it doesn't always look the way you expect it to look.

Part of this attack is also limited by the X-frame options header,

of course, more recently replaced with content security policy, which also limits what can

be displayed inside NIFRame and can make at least the execution of some of these attacks more difficult.

And Adam Chester with TrustedSec wrote an interesting blog post about how to inject

a code on Mac OS via third-party frameworks.

MacOS made it more and more difficult to execute untrusted code.

...