Hello and welcome to the Friday, January 16th, 2026
edition of the SANS Internet Storm Center's Stormcast. My
name is Johannes Ullrich, recording today from
Jacksonville, Florida. And this episode is brought to you
by the SANS.edu Undergraduate Certificate Program in Applied
Cybersecurity. Today's diary comes from Matthew Presnell,
one of our undergraduate interns. And Matthew is
writing about, well, the most common, actually, observation
from his honeypot. And that's, well, crypto coin miners. Now,
crypto coin miners or crypto jacking, of course, is very,
very common. But there's one part to it, and that's
something here that Matthew is mentioning that's sadly often
overlooked, even though it is very, very common. And that
the crypto coin miner is hardly the only thing that's
happening when your system gets infected. So the crypto
coin miner is probably the easiest to detect problem. And
that's, you know, what usually people are paying attention
to, that all of a sudden their system is slow. They see
there's this process running. So what do they do? They kill
the process and move on. But that's not really sufficient
here. Because as Matthew points out, pretty much every
time there's a crypto coin miner, there's also a backdoor
being installed. In this case, that's probably the most
common combination with the crypto coin miner. And as H
keys being added to the authorized keys file. And with
that, the attacker now has access to your system, even
after you change the weak password that was originally
used to break into the system. So always pay attention. If
you find a crypto coin miner on the system, it really just
means that you had a real vulnerable system. Crypto coin
miners usually don't use sort of very sophisticated
exploits. They go for low hanging fruit. They go for weak
default passwords. They go for very basic, commonly exploited
web application vulnerabilities. There is a
great chance that the crypto coin miner itself did more
than just installed a crypto coin miner. But the other
problem of this, that while the same weak vulnerability
may have been exploited by more stealthy attackers that
didn't install a crypto coin miner, that just exfiltrated
the... And researchers at the Catholic University of Leuven
in Belgium did come up with an interesting new attack against
Bluetooth. Now, this attack affects devices that are
enabled to participate in Google's fast pair mode. Fast
pair allows you to quickly pair devices. We know it's
always a little bit of problem for users to sort of set up
that initial connection between like a phone and a
headset or whatever you're pairing. And sometimes in the
past, at least you had to enter like codes, which of
course is difficult on devices like headphones that don't
really have a display or a keyboard or anything like
that. So what fast pair does is where the phone basically
sends out a fast pair request and the device is then
responding and that initiates the pairing process. The
problem here is that the specification for fast pair
says that devices should only respond to these fast pair
requests if they are actually in pairing mode. And if you
have ever done it, often you have to press a certain button
a certain amount of time to turn them into pairing mode,
which apparently to some devices is a little bit too
much to ask for. So they will respond to these requests and
allow pairing regardless of whether they're in pairing
mode or not. What this means is that any device that
supports fast pair in this flawed implementation is then
hijackable by a Bluetooth device in the Bluetooth
distance. So within sort of 10 ish meters. This flaw is sadly
very widespread. There are multiple name brand and large
manufacturers affected. The website of this group,
whisperpair.eu, does contain a lookup table where you can
find affected devices. I did a quick look and like the Sony
Beats device are affected. Apple branded headsets don't
appear to be affected because they probably don't support
fast pair. But the sort of Apple version of that
protocol. So they are not affected here. It doesn't
really matter if you disable fast pair on your phone
because the phone isn't a problem here. The problem is
the device like the headset. The only fix is an eventual
firmware update for the device which of course with stuff
like headsets and such can be always quite tricky to apply.
If they haven't set up sort of an automatic update mechanism.
And Barone's lab did discover an interesting way to
exfiltrate data from Microsoft Copilot sessions. They're
calling it a reprompt attack. And the attack is actually in
principle rather straightforward. When you're
linking to Microsoft Copilot as part of the URL you're able
to specify a parameter queue. And that parameter is
essentially being then prefilled and pre-executed as
a prompt. So that way you can create links that link
directly to a particular prompt. The problem here is if
a user clicks on a link like this and then adds their own
prompt. Well, what happens to their prompt is affected by
the prompt that was supplied supposedly by an attacker.
Microsoft has implemented a couple of safeguards to
prevent malicious things happening here. But as so
often with these AI tools. Well, a little bit sort of
social engineering where you're trying to trick the AI
into doing things badly. Well, it still work here. So similar
techniques as you're used to from prompt injection and
such. One example here is where you just ask the copilot
to access every URL twice. It'll actually block the first
attempt and then not the second one. So there are
workarounds basically for the safeguards as it's fixed right
now. And I predict we'll have a little bit whack the mole
happening here where Microsoft is implementing more
safeguards. And researchers will continue to come up with
ways to bypass them. Well, be careful when you're clicking
on links. Stupid advice, I know. But probably the best
you can do in this case. Well, and that's it for today.
Thanks for liking. Thanks for subscribing. And as always,
thanks for great comments in your favorite podcast
platform. And on Monday, there will actually be a holiday
here. So the next podcast will be on Tuesday. Thanks and talk
to you again on Tuesday. I'll see you again on Tuesday. I'll
see you again on
Tuesday. Thank you.
