SANS Stormcast Friday, August 7th, 2026: Fast SSH Attacks; Dell BIOS Passwd Weakness; Crypto Wallet Vuln; Benchmarking LLMs for Threat Intel (@sans_edu)

If you are not able to play the podcast using the player below: Use this direct link to the audio file: https://traffic.libsyn.com/securitypodcast/10042.mp3

previous

Fast SSH Attacks; Dell BIOS Passwd Weakness; Crypto Wallet Vuln; Benchmarking LLMs for Threat Intel (@sans_edu)

00:00

iTunes

MP3 Download

RSS Feed

Google

Podbean

Amazon Echo

YouTube

Spreaker

Spotify

Discussion

Login here to join the discussion.

Podcast Transcript

 Hello and welcome to the Friday August 7th, 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 graduate certificate program in
 cybersecurity leadership. Well, to start with, we have
 today another diary created by one of our undergraduate
 interns from our bachelor's program. Daryl Jimenez did
 write about, well, another compromise via SSH. Now the
 focus here was in determining the speed of the compromise.
 And since these compromises are highly automated, well,
 the speed was pretty quick. 22 seconds from compromise to
 actually gaining persistence. Now the way persistence was
 gained in this case, it's also very typical for these SSH
 compromises is that the attacker will add a special
 key to the authorized keys file. So going forward, the
 attacker no longer needs a password in order to
 authenticate. They just use this key they added. Lesson
 learned here as so often, strong passwords is a good
 start, but then keep monitoring these authorized
 keys files. Try to centralize them somewhat, try to manage
 them in order to prevent someone from just adding
 additional keys to it. The other problem here is if
 you're just focusing on monitoring these files,
 delaying actually finding out that a file got altered and
 acting on that alert is likely too much before there's a
 further compromise off your host, given that these
 attackers again, move rather quickly. And researchers with
 Amber Wolf have identified an interesting and easily
 exploited weakness with Dell bias passwords and how they
 are stored in the SPI flash memory. So the SPI flash
 memory is used for various system settings. It's easily
 read, for example, by booting the system into an alternative
 operating system or by attaching a reader to the
 respective chip. The problem here is relatively
 straightforward. We do have 32 bytes to store the password
 and then the password itself is XOR encrypted. Now XOR of
 course is not known as the strongest encryption
 algorithm, but in many ways, well, the strength depends
 then on the key being used. If you have a random key the
 attacker can't predict, then XOR actually works reasonably
 well. Unless you implement it like Dell does, where, well,
 the last few bytes of the password, the password does
 not fit the entire 32 bytes, is just zero padded. So any
 byte in these last few bytes is then essentially just the
 key because zero XOR the key just gets you the key. And
 then the key is only 20 bytes long. So the last 12 bytes of
 this password field are again using the same key as the
 first 12 bytes of the password field. And since many biased
 passwords aren't really all that long, so they're really
 not longer than 20 bytes, well, the last 12 bytes
 usually give you then the key to decrypt the first 12 bytes.
 And if your password is only 13 bytes long, then you got it
 because the first byte is actually not encrypted and
 encryption starts at byte two or one if you're starting
 counting at zero, which apparently may have been the
 issue here. So the end result is if you have one of these
 affected Dell systems, the biased password is relatively
 easy to retrieve. And as a result, well, you should
 probably either update the bias if there is something
 available or you should use a password that's 32 bytes long.
 And that sort of would help a little bit here make this
 entire tag a little bit more harder. But they're talking
 about other weaknesses in the key derivation that actually
 makes it also possible to decrypt longer passwords.
 Well, in just about a week after we got the entire issue
 around the cold card crypto coin wallet, we now have a
 second similar problem related to JavaScript library,
 CryptJS. Apparently, there are multiple Bitcoin and other
 cryptocurrency wallets that are using CryptJS as their
 crypto library in order to create random keys. The
 problem is that for about three years, this particular
 library has shown to not actually create random
 numbers. And the second problem is that the library is
 no longer maintained. So it does not appear that this
 vulnerability will be fixed anytime soon. So if you
 created a wallet that used this library, let's say a
 little bit of tricky part because that may not be easy
 to identify what particular wallet and what software it
 used in order to create your key pair for the wallet. Well,
 you may want to create a new key and then transfer your
 cryptocurrencies from the old wallet to that new wallet. The
 company that identified this vulnerability did publish a
 little sort of FAQ about it. They did not yet release all
 the details about this particular problem, which is
 probably good. They are looking for a little bit of
 staged disclosure to identify which wallets are exactly
 affected by this. But they did publish a little form on their
 website where you can check whether or not your wallet
 address may be affected. Now, just to make it clear, only
 ever paste your public key into this form. Never, ever
 release the private key. They are saying everything happens
 in the browser. But of course, that's where you start to
 trust the author of the webpage, whether or not they
 did that correctly.
 Well, today we do have another Sans.edu graduate student to
 talk about their research project. I apologize a little
 bit for the bad audio here on my end. I didn't use the wrong
 microphone when I was recording it. But anyway,
 Ricky, could you introduce yourself, please? Well, it's
 Friday again and with me today, another Sans.edu
 student to talk about their research paper. Ricky, could
 you introduce yourself, please? Hi, my name is Ricky
 Banda and I just published my research paper, Benchmarking
 Three-Tier LLMs as Cognitive Aids for Operationalizing
 Unstructured Cyber Threat Intelligence with Sans. Can
 you tell a little bit about what the paper is about? I'm
 an incident responder with over 15 years of experience in
 the field. I have responded to a wide variety of threats from
 working with government agencies to massive
 corporations like Amazon and Google and several others. One
 thing that I have noticed throughout my tenure is that
 incident response is a very, very stressful line of work.
 And more so now with the unveiling of mythos and all
 sorts of various AI models that are more focused on
 cybersecurity. That's causing a lot of churn and burn for a
 lot of folks, myself included. And I started wondering to
 myself, well, you know, when I was doing my paper with Sans,
 what can I research or what can I look into that is
 actively affecting incident responders? And that was, you
 know, a lot of this threat intelligence and vulnerability
 data that was coming in that is very unstructured, hard to
 parse and not trivial to interpret, especially as
 you're managing a large caseload with active incidents
 ongoing or security alarms that need to be triaged or
 analyzed. So my thought process was, you know, can
 LLMs be used effectively at least upwards of maybe 80% of
 the efficacy, what human cyber threat intelligence analysts
 can do to help reduce that cognitive load on incident
 responders whenever they're dealing with? Maybe to expand
 on that a little bit, Dr. Goldberg is myself personally,
 I've been in situations where I've been managing or
 balancing five to 10 cases. And then CISO sees a new
 article in the news, you know, new exploit just occurred or
 new vulnerability was just in the field. Now I have to stop
 everything that I'm doing, analyze that paper, come up
 with a defensive mitigation plan. And that's one to 45
 minutes to three hours, depending on how much work I
 need to do that is not focused on active incidents and
 operations. So can an LLM do that for me? That's what my
 paper is about in a nutshell. So it's more than just
 extracting IOCs or such, or it goes beyond that. What are
 some of the items, knowledge nuggets or whatever you call
 them, that you would like to pull out of these reports?
 Yeah, absolutely. One of the things that I had noticed or
 what the data showed, because what I did was I evaluated
 Gemini, ChatGPT and Claude and fed it three levels of
 prompting. Zero shot, evidence -based prompting, and then
 context aware or persona. Essentially the difference
 between a year one SOC analyst who maybe has very limited
 understanding of work and they asked the LLM to analyze a
 threat intelligence article and provide me five
 recommendations. Not a whole lot of tuning, not a whole lot
 of prompting there. L2 is more give me recommendations, but
 cite the sources. L3 is more focused on you are an incident
 responder. You are a security analyst. I need you to analyze
 this article and provide five actionable recommendations. I
 then took those five recommendations per those
 three articles and then also had five human cybersecurity
 professionals also provide their recommendations to see
 if the AI tools aligned with the human recommendations at
 an 80% efficacy score. That's what I had mentioned prior.
 The interesting thing about all of it was that it wasn't
 so much the model that mattered as much as it was the
 prompt. Second was AI tools when they're hallucinating or
 whenever they're providing false information, it can look
 and sound really, really good. The AI tools would provide
 recommendations that didn't always align with my human
 research assistants. And if you are in a position where
 you may not know any better, that could actually cause
 detriments to your environment. So I guess what
 it comes down to is that these are tools that can help us in
 triage and analysis. And they are effective at an 80%
 efficacy rate, but they still must be analyzed by a human
 responder who remains in a decision-making seat in order
 to action or, yes, or take action to the intelligence
 that is analyzed or triaged. And that's sort of, I think,
 the real interesting question then. It's not so much the
 error rate, like if it's 70%, 80%, or 90%, but how easy is
 it to detect the errors? Because if it takes as much
 time to detect the error as it would have taken to read the
 paper, that's probably not the point here. Or what did you
 sort of find there? Precisely why I selected that four out
 of five cadence or that 80%, what I call a HAM score or
 human-aligned mitigation score. That is precisely why,
 right? Because I think it's okay. It can be acceptable to
 review or triage an article, especially a very complex or
 technical document. And maybe you correct one of the
 recommendations that the AI provided. That should be okay.
 Any more than that, then you're just wasting time at
 that point, from my perspective, at least, from
 having worked in the field and done the work myself. Yeah, I
 have to admit, I was playing with that, I think, last year
 to basically create scripts for the podcast where I gave a
 news article and said, hey, summarize the news article and
 give some recommendations. I like to always tell, hey, what
 do you learn from this story? What's the recommendation? And
 the recommendations weren't wrong, but they weren't really
 what I would have picked necessarily. So, like, if
 there is an incident with a device that had a default
 password, the recommendation was pick strong passwords,
 which isn't really wrong. But probably the default password
 was more the problem than that the default password wasn't a
 strong password. So those are kind of subtleties I think
 that AI sometimes overlooks. Did you find something like
 that?
 Yeah. Yeah. In our data or my data that I had evaluated, it
 was more so along the lines of my analysts would provide
 their recommendations or their baseline gold scoring that was
 broken down into code blocks. And what I mean by that is
 analyst A, B, and C for Article 1 might recommend that
 behavioral-based detections need to be written to detect
 or as an actionable recommendation to put into
 production, right? Now, if all five of the analysts all agree
 that that is a direction that should be moved forward, it
 doesn't have to be specific, as in, like, we need to create
 an IOC or we need to create a detection or snort detection
 or anything like that based off of something going on in
 the article itself. It's more so, did all five analysts
 recommend creating detections? Okay. Then that means that
 they coded to a detection block. So did the AI also make
 those types of recommendations? In some
 cases, no, they didn't. So I would have five analysts who
 might say, we think a detection needs to be written
 based off of the contents of this article. The AI might
 come in and say, I think that an IAM, a new IAM policy
 instead needs to be written or built out. And so that's how
 we come to that conclusion that the AI provided a
 recommendation that was not to the same efficacy or level
 that would be expected of tenured human analysts. And I
 think that's what we need to look for when we're looking at
 these tools and deciding whether or not we want to
 operationalize them. You don't necessarily just want to trust
 what the AI is saying. And you want to see if, is it even
 anywhere near as effective as a tenured incident or threat
 intelligence analyst or incident responder? And just
 out of curiosity, how similar were the different analysts'
 recommendations? Yeah, that's a great question.
 Surprisingly, on most of them, they all came up aligned for
 the most part. Now, if you see me look over here, I'm looking
 at the data right now. For example, on report one for the
 Light LLM supply chain attack that occurred earlier this
 year, that was one of the articles that was, you know,
 it was all over the news. It was everywhere. You know, and
 out of all of the analysts, they all, you know,
 recommended that, you know, supply chain vulnerability
 management programs, processes need to be deployed and to be
 enacted, things like that. And then that was also kind of
 continued along the line. There wasn't too much of a
 discrepancy between the analysts, which I found very
 interesting. Yeah, good. So great paper. And there will be
 a link to the paper in the show note. It can also be
 found at the sans.view cyber security page. So if anybody
 looks there directly, also lots of other interesting
 papers there. Thanks for joining me, Ricky. And for
 everybody else, talk to you again on Monday. Bye.