Hello and welcome to the Monday, March 31st, 2025
edition of the SANS Internet Storm Center's Stormcast. My
name is Johannes Ullrich and today I'm recording from
Jacksonville, Florida. Jan on Friday looked at two different
phishing sites that at first look, look very similar, same
layout. They also use the same trick that we often see where
they're including the favorite icon from a website that
matches your email domain in order to make the entire site
look more plausible. Both of these websites are claiming to
be login screens to webmail systems, something we
definitely see over and over again. What Jan really looked
at, given that these two email or these two phishing sites
look so similar, are they actually created by the same
entity? Are they using the same phishing kit? And the
answer here appears to be no, because the back end of these
two phishing sites looks very different. One of them uses
Telegram as a command control channel or to exfiltrate the
data. The other one doesn't. It uses a more sort of generic
web hook process in order to send the data off to some
collection site. Both sites are hosted very differently.
So definitely looks different, but similar techniques. What
Jan suggests here, and he's probably right with this, he's
looked at a lot of these phishing sites, that these two
are derived from the same phishing kit. So they
originally start out as one phishing kit, but then these
phishing kits get copied, traded all the time. So
basically they split off, they evolve, and that's probably
what's happening here in this particular case. Now sticking
with phishing here for the second story, Infoblogs has an
interesting blog, a very detailed blog actually, about
what they're calling a recent Meerkat phishing kit instance.
Meerkat is what Infoblogs calls this phishing kit. A
couple of things sort of stuck out here. I mentioned earlier
that the phishing kit that Jan talked about included
basically your company logo based on your email domain. So
for sans.edu, it included our sans.edu logo. And this either
is pulled from standard sites that host logos like this, or
it's just being pulled as the favorite icon from the
website. Well, of course, for myself, and I would log into
the SANS webmail client, well, it wouldn't be a sans.edu branded
one. We are using Outlook 365. Now I'm telling you we're
using Outlook 365 because that's pretty easy to discover
if you're looking at our MX record for sans.edu. And
that's what the phishing kit here does that Infoblogs
talked about. They're looking at the MX record. If it turns
out that you're using Outlook 365, they will produce an
Outlook 365-like login screen. So this is sort of a little
bit of better customization in that sense. Another
interesting part here is that in order to DNS log up,
they're actually using DNS over HTTPS. But they're not
using sort of your browser's built-in resolver for DNS over
HTTPS. Instead, they are using JavaScript to just use fetch
requests to connect to the Cloudflare DNS over HTTPS
server to request that response. Interesting use sort
of of some client-side technology to do these
lookups. And lastly, one other thing, and there are many,
many things in the blog post that this phishing kit does,
but another thing I kind of liked was that they're
exploiting an open redirect in DoubleClick. So the link
actually is going to DoubleClick.net, and then
you're being redirected to the actual phishing site. Well,
DoubleClick.net, while I actually block them in my
network because of all the advertisement and user
tracking being done with it, it is a very common domain and
something that's often allow listed because it is so
common, because it has weird URLs sort of being passed
along as parameters. And so that's, again, something else
this phishing kit uses for evasion. And Cloudflare did
open source an interesting tool that they're calling OPK
-SSH. At least that's, I think you pronounce it. The idea of
the tool is to integrate SSH logins better with existing
identity providers that you may be using for web
applications, in particular OpenID Connect, which, of
course, is often used in single sign-on systems. The
way the tool works is that you install a little command line
tool that is OPK-SSH. You use that to log in, and the way
this works is when you run it, it'll open a web page, allow
you to log in to your identity provider, and then you're
getting back essentially the private SSH key that you're
then using to log in with SSH. Have to play with it.
Certainly looks interesting. I wonder if it's a little bit
clumsy, sort of that entire web transition. But the
problem they're really trying to solve here is, first of
all, you know, integrate SSH logins with your centralized
single sign-on identity management. There are, of
course, other solutions to do that. But the big problem with
sort of what most people use is, and that's these static
private secret keys or secret public keys that you typically
have with SSH, is that, well, they're static, and they
usually don't change. They're hard to sort of centralize,
manage. There are somewhat better solutions like PGP
-based solutions that are a bit more manageable here and
that are, I think, pretty well integrated into existing SSH
clients and servers. Either way, maybe interesting to you,
like I said, if you do want to integrate your SSH access
control into your sort of central single sign-on, and if
that's OpenID-based or has the ability to use OpenID Connect,
which they often do, then this sounds like a real interesting
idea. And it's free to download and relatively easy
to install. Well, and that's it for today. Thanks for
listening and talk to you again tomorrow. Bye.
