Despite their inherently deceiving activities…ransomware groups must convince their victims of their trustworthiness. This trust encompasses not just the promise not to release the stolen data but also the assurance that payment will result in the decryption of the affected systems. This makes branding and reputation-building activities not peripheral but central to ransomware’s operational success. 

This has largely been the case since ransomware really became professionalized in 2018-2019 (though, you could argue that the professionalization started in 2016 with the Hollywood Presbyterian attack). Ransomware groups are filled with scummy bastards, absolute trash human beings who deserve the worst possible fates — sorry, I lost my train of thought for a second — but they are money grubbing capitalist scummy bastards so they will ensure their software works and your data won’t be leaked (though, it most-assuredly will NOT BE deleted) in order to get paid.

But, it appears the ransomware trust paradox may be breaking down. According to multiple reports (and my own observation), despite the number of ransomware attacks generally being up in 2024 and 2025, the percentage of victims who pay a ransom and the size of those ransom payments has decreased. Now, ransomware analysis is never an exact science and other organizations have reported an increase in ransom payments.

Why is it that after all this time victims are starting to wise up to the fact that you can’t trust ransomware groups? I think there are few reasons:

1. The rise of the lone wolf ransomware actor. We are seeing more single ransomware actors who are not part of a group, therefore have not built up that reputation needed for trust.

2. If your data is encrypted, it is increasingly likely the ransomware group-supplied decryptor will not work.

3. Law Enforcement actions are having an impact. I think this has a lot to do with numbers 1 & 2. Big RaaS groups are becoming rarer as they make easy targets for law enforcement. This certainly drives many ransomware affiliates to strike out on their own, creating the conditions for the lone wolf actors and lone wold actors don’t have the resources to tweak and improve their decryptors, leading to number 2. Evidence of a lot of this can be found with the relative success we are seeing with “closed” RaaS groups like Akira and Qilin.

4. The switch to the “data exfitration only” model may be driving some of this as well. In 2025, depending on your view, most ransomware attacks don’t involve encryption only data exfiltration. This is certainly easier for the ransomware groups and can be just as devastating for some victims, but only some. Many organizations view don’t feel the same urgency, or no urgency at all, to pay a ransom after a data leak, simply because there is so much leaked data available, their data is likely to be lost in the see of leaks. This is a very cynical, but accurate, view.

As with any “ransomware trend” things can change on a dime. Ransomware groups are always finding new ways to be scummy bastards and make money. So, I am not saying the ransomware trust paradox is completely dead, but it does seem to be on life support right now.

What do you think?

They are. How about healthcare providers? Those attacks also increased significantly in the first quarter of 2025.

By almost every estimate that I’ve seen, ransomware attacks are up across the board in the first quarter of 2025.

NO. ONE. CARES.

I mean, you do; you’re reading this. But, for the most part no one cares and I am trying to figure out why that is. I’ve talked about ransomware fatigue in the Board Room before, but this is different. Even reporters who normally write about ransomware aren’t writing about incidents with the frequency they used to. I’ve even had several reporters tell me that CL0P has complained no one is covering their Cleo exploit and subsequent data leaks.

I think the problem is one of the attention economy [PDF]. There is a A LOT happening now, and there is a lot of bad happening now. It’s hard to draw people’s limited attention to ransomware when there is so much new badness every day.

To some extent ransomware as always thrived by being able to manipulate the attention economy, but this is especially true since 2019 and the advent of data leak sites. By dripping data leaks slowly and, often salaciously, ransomware groups have been able to command the attention of reporters and researchers. But, it’s hard to compete with a random dude dropping Oracle credentials or the Chinese government infiltrating most major US telecoms or, well, everything.

Ransomware groups have been masterful at controlling the attention economy, but their power to do so is fading. Unless there is a new equivalent to Colonial Pipeline or United Healthcare ransomware attacks will continue to get less attention and that may have an unintended consequence.

You see, despite ransomware attacks being up this quarter, all signs point to the number and amount of ransomware payments being down. The same is true for last year, more publicly reported ransomware attacks but less money being paid to ransomware groups. If attacks continue to get less attention there may be even less incentive for victims to pay, especially as encryption falls out of favor for many ransomware groups.

Could the end of ransomware really be as simple as ignoring the threat actors? One can only hope.

Anyway, my point is that there have been a lot of headlines about the “resurgence of LockBit” in May after law enforcement action and I am here to remind the whole world: LockBitSupp is a Lying Bastard™ and Please Stop Listening to Him.

Is LockBit ransomware cooked? I can’t say, they have been down a number of times but always seem to come back, but May does not appear to be an example of that comeback.

Valéry Rieß-Marchive at LeMagIT has already taken a thorough look at the data and come to same conclusion. At least 68 of the “record number of victims” are simply old victims being re-posted. It also looks like some of the “new” victims aren’t real either.

Don’t get me wrong, even if LockBit posted 100 victims in May, that would be bad, but it is very different that 176 and it would be out of line compared to what we’ve seen in recent months with just 40 victims in March and April and even less than that to this point in June. I think of May as more of a “last gasp” from a slowly dying ransomware group — that’s not just wishful thinking on my part. LockBitSupp has become a pariah in the underground community and lost the trust of so many ransomware affiliates and partners that it will be hard for him to get back to where he once was.

Of bigger concern right now is the fact that so many of the newly formed ransomware groups are making use of the leaked LockBit code, so we are seeing a big increase in ransomware attacks using leaked LockBit code, but not related to the original LockBit.

Since the beginning of June, there have been three seemingly related domains registered:

• June 15th - ransomware-recovery-method-916663[.]zone

• June 13th - ransomware-recovery-method-75138236[.]today

• June 5th - ransomware-recovery-method-377612[.]world

The [.]world and [.]zone domain names were registered through enom, while the [.]today domain was registered through GoDaddy. None of the domains have subdomains, as far as I can tell, and all are currently parked.

None of them register as being malicious on any of the usual sites.

But, this feels shady. And so much of what we do in intelligence analyst starts with your Spidey Sense tingling. Of course, as any good analyst will tell you, sometimes your Spidey Sense is wrong and it just sends you down a path that leads to nowhere.

For now, I am going to keep my eyes out for these domains, and any new domains that match the pattern, to see if anything changes. If anything does change I will update you all.

Looking at collected data, states with a large rural population suffer an outsized number of ransomware attacks based on population. But, even when they don’t, attacks on large healthcare providers disproportionately impact rural areas where they may not have enough resources to survive service disruptions caused by ransomware attacks to large providers.

The linked report from the Foundation for the Defense of Democracies is worth reading in full and there are a lot of excellent ideas in the report.

There are two recommendations from the report that I want to focus on:

1. Create a Rural Hospital Cybersecurity Workforce Development Strategy

2. Develop Regional Contingency Plans for Healthcare Providers

We talk a lot about solving the rural healthcare provider ransomware problem by throwing money at it. But, money will not solve the problem without the right personnel in place to manage the technology. But, I also wonder how some of these hospitals that are struggling to make ends meet would feel about hundreds of thousands of dollars being allocated to cybersecurity when they are struggling to find the budget to cover basic healthcare needs for their patients (I’ve had similar conversations with small towns who have some of the same concerns).

I wonder if an MS-ISAC model might make more sense, where there is more centralized monitoring and alerting that covers many hospitals at once. The hospitals would need assistance to get logging set up and running, but it would allow for more effective use of people and resources while improving security overall.

The 2nd point, regional contingency plans, are also critical. Some rural hospitals are 50 miles or more away from the next closest hospital. This makes it harder to make regional contingency plans, but it still needs to be done, ideally in person. Not only do rural hospitals have to plan for what happens when they, or one of their “neighboring” hospitals, are hit with a ransomware attack, but what are you going to do if a national provider is hit and staff have challenges filling prescriptions, making appointments or treating patients. Ideally, tabletop exercises like these can be led by HHS or the Health-ISAC, organizations that have experience with everything that can go wrong during one of these attacks.

We need more focus on protecting rural healthcare, not just from cyberattacks but from everything impact these organizations. But my focus is on cybersecurity, so I am going to focus on how we can make that better.

Yours Truly Dollar #4 Kickstarter is Live!

The Kickstarter for our last Yours Truly, Johnny Dollar comic book is live and we could really use your support! In this issue (surprisingly relevant) Johnny has to deal with the fallout of a ransomware attack agains the UK Healthcare system. We’ve hit our funding goal, but I would love it if we could get to 100 backers and show the world that there are more ways to tell cybersecurity stories than through PDF and PowerPoint.

Thank you all for your support!

On the surface, this seems like good news. In all of 2023 there were 256 publicly reported attacks on state and local governments, so extrapolating first quarter numbers we should end the year at 216, a drop from 2023.

My concern is with the way the attacks have been accelerating in 2024. Take a look at Figure 1. We’ve seen a steep incline in the number of attacks, and we are seeing that incline earlier than in previous years. While January started off relatively slow with 13 attacks, we saw 19 in February and 22 so far in March (there is often a delay in reporting, so we’ll likely see March’s numbers trending up.

In particular, February and March’s numbers are worrying because they represent the highest and second highest numbers, respectively, recorded in those months (see Figure 2).

This likely indicates that we are in a rough year for ransomware attacks on State / Local / Tribal governments, combined with the added threats from an election year could mean an all out assault on local governments worldwide.

And, as Figure 3 demonstrates, it isn’t just one group. The 54+ attacks have been carried out by 20+ different groups. So, there is a lot of attention being paid to local governments by many ransomware groups.

CISA and other government agencies are working to help shore up defenses of local and tribal governments, but it may not be enough.

This is unequivocally good news. The LockBit ransomware group has been around since 2019 and is responsible for thousands of ransomware victims. Operating as an largely open Ransomware-as-a-Service, they had more affiliates than any other group (at least as far as I know) and their level of destruction was unprecedented among RaaS groups.

According to law enforcement, there is a second shoe that is going to drop tomorrow, so tune in for more details.

It is very unlikely that the core of the LockBit group, which is based in Russia, will be arrested but this disruption will have a significant impact on the ransomware ecosystem and we should enjoy that disruption before we get quickly back to building our defenses.

We are in the middle of our crowdfunding campaign for Yours Truly, Johnny Dollar #3 and we could use your support to get us over the top!

In this issue Johnny must head to Billings, Montana to deal with the aftermath of a ransomware attack on a school system. Johnny has to fight off angry parents who, understandably, don’t want to see their kids sensitive data publishing online.

In addition to the usual great artwork from our team, we also have a few special rewards for higher backers including an homage to Captain America #1. Four separate prints where Johnny punches a ransomware actor - something I know you all would love to hang on your wall.

Once again, if you can help us get over the finish line, I’d really appreciate it!

People ask me all the time for the “one thing” they can do to prevent ransomware attacks. The truth is, despite some vendors’ claims, there is no “one thing,” it takes a comprehensive security program to effectively protect against initial access brokers and ransomware operators.

Then the conversation turns to, “where should I start?”

And that is where my “ransomware triangle” comes into play. If the best ransomware defense is to keep the ransomware actor from ever getting in the network, then your defense should focus on the ways that most ransomware groups gain access (either directly or through IABs).

Most research agrees that the three most common ways that IABs breach organizations are (in no particular order):

1. Phishing

2. Credential Leaks / Stuffing

3. Exploitation

So, focusing on knowing what you have, and where you have it (including your data) along with keeping those systems patched in a timely and properly prioritized manner while knowing your when employee credentials have potentially been compromised or employee accounts are accessing systems they probably shouldn’t will allow organizations to stop most ransomware attacks.

That was a mouthful of a sentence because, let’s face it, if the three things outlined above were easy everyone would be doing it and we wouldn’t have a ransomware epidemic on our hands.

That being said, I do think it is important to spell out what needs to be done for organizations to protect themselves and all of these are realistic goals that almost every organization can accomplish without requiring a huge security budget.

I am still working through the practical side of this, but I would love your thoughts on this and, in particular, if there is anything I am missing.

Yours Truly, Johnny Dollar #3

We are getting ready to launch the Kickstarter for the 3rd Issue of Yours Truly, Johnny Dollar. In this issue Johnny travels to Billings, Montana to tackle a ransomware attack against a school system.

First day support for Kickstarter campaigns is so important so I would really appreciate it if you would consider backing us on the first day. You can set a reminder to be notified of the launch by going to our pre-launch page.

Thank you for your continued support!

According to data scraped from data leak sites, there were ~4399 (sites go up an down, scrapers break, etc, so this number is always an estimate). In all of 2022 there were 2581 victims posted to data leak sites. That is a 70% increase between 2022 to 2023.

The problem is, almost all reporting on ransomware attacks relies on data from ransomware actors. Some companies, like Coveware, will publish regular reports based on numbers from cases they’ve worked and most incident response companies can provide trending data based on what they’ve seen, but they can’t share too much information because of client NDAs and other agreements.

Even governments which require reporting from specific sectors generally don’t share that information publicly (with some exceptions) even through it would be incredibly useful for researchers and the general public.

At the upper bounds of ransomware attacks, this situation could be changing with the new SEC breach disclosure rules. But, most ransomware attacks are not against publicly traded companies in the United States (we think). And, of course, we have to be careful that breach disclosure rules cannot easily be weaponized by the cybercriminals.

Why is it a bad idea to trust cybercriminals for breach reporting? The obvious answer is that ransomware groups are liars. But, specifically, researcher Valéry Rieß-Marchive has documented numerous cases of ransomware groups double-posting victims or just making up victims in an effort to “pad their numbers.”

We consistently see underreporting of victims from ransomware groups. Some of that comes from the estimated 25-30% of victims who pay the ransom, but there are a host of reasons that a victim may not appear on data leak site. One of the most common, possibly more common than the victim paying the ransom, is that the affiliate just grabbed useless or no data from victim during the exfiltration stage. Ransomware groups are often loathe to post data that they deem invaluable or impactful and data exfiltrations fail for a variety of reasons.

That’s why when ransomware groups are taken down, we often find that as many as 80% victims never made it to the extortion site (for example, the Hive takedown).

So, what can we do? The easiest solution is for governments that require reporting to start making that data more available. Of course, doing so will require more streamlined reporting, something the government (in the US) is actively working on, but is definitely not there yet. We also have to find ways for organizations to more easily share data so that we all understand what the situation looks like, again without running afoul of NDA or other confidentially agreements.

Unfortunately, until then, we are stuck with the same problem: Relying on criminals to provide us with numbers that we know are incomplete and inaccurate.

But, I think this article highlights something that is a growing pattern: The move away from Russia as a locus of control for ransomware groups.

Don’t get me wrong, for years, there have been ransomware affiliates from around the world. We’ve seen affiliates arrested in Romania, South Korea, India, Canada and the United States. But, much of the core leadership of typical cybercriminal ransomware groups resided in Russia or Ukraine (Iran, North Korea and China were more nation state or hybrid models).

But, that is starting to change. The big ransomware groups are still, largely, based in Russia. But, now that ransomware code is largely available and, with the increased initial access broker activity, so are victims we are seeing smaller ransomware groups pop up with leadership based in other parts of the world.

One of the challenges in tracking these groups (aside from attribution is hard) is that they tend to be smaller and not as well organized as the more established Russian threat actors, so getting a handle on how big this problem really is is going to be a challenge in 2024. But, as long as ransomware remains profitable, we can expect to see more cybercriminal ransomware groups wholly operating from places outside of Russia. Which means we can look forward to even more attacks.

Welcome to 2024, it will look a lot like 2023, but worse.

CISA released an excellent report on Scattered Spider [PDF] this week and Scattered Spider has been top of mind, rightfully so, for many security teams. Scattered Spider are believed to be younger threat actors, most likely based in Western countries (some have suggested London and New York - but I am not sure there is evidence for that). The fact that they are native, or near native, English speakers has allowed them to pull off attack-types that other groups struggle with, especially social engineering attacks.

What is interesting to me about Scattered Spider is that while they are generally lumped in with ransomware groups, they are more chaos agents than they are ransomware actors and that is an important distinction. Their primary focus seems to be causing trouble, and making money is secondary.

They definitely have made money, but in cases where I have been involved, they definitely seem more interested in disrupting operations and generating headlines, the money is almost secondary. Even when they’ve deployed the ALPHV/Black Cat ransomware they have only done it sporadically and not in a typically disruptive manner.

Microsoft has also reported that they will often send mocking or threatening messages to security teams or other employees of victim networks threatening to get them fired or shoot up their house.

There has been lots of really good advice about how organizations can protect themselves against the Scattered Spider attacks. I won’t try to repeat everything here, instead I encourage you to read the CISA report. I also encourage you to check out the excellent reports from Mandiant and Microsoft.

But, know that Scattered Spider is constantly evolving their techniques. So, while the reports above offer excellent advice, in a few months there may be new techniques that need to be addressed. This is one of the problem that many security teams face: New’ish attack vectors often evolve faster than security teams can keep up.

The one hope with a group like Scattered Spider is that, because they are likely located in a western country law enforcement will be able to arrest them soon. Not as soon as we would all like, but soon.

(4) POSTING ON HHS PUBLIC WEBSITE.—The Secretary shall make available to the public on the Internet website of the Department of Health and Human Services a list that identifies each covered entity involved in a breach described in subsection (a) in which the unsecured protected health information of more than 500 individuals is acquired or disclosed.

Basically, any time there is a breach involving the Protected Health Information (PHI) it has to be reported to the US Department of Health and Human Services (HHS) and the HHS Secretary has to report it on the Breach Portal.

One of the nice things about the HHS Breach Portal is that it is publicly searchable and you can filter by “Hacking/IT Incident.” Unfortunately, the portal doesn’t get more granular than that, so we don’t know how many of these “Hacking/IT Incidents” were ransomware attacks, though we can often reverse engineer the entries to see if we can find reporting since part 2 of that same section states:

(2) MEDIA NOTICE.—Notice shall be provided to prominent media outlets serving a State or jurisdiction, following the discovery of a breach described in subsection (a), if the unsecured protected health information of more than 500 residents of such State or jurisdiction is, or is reasonably believed to have been, accessed, acquired, or disclosed during such breach.

Healthcare organizations impacted by breaches have 60 days to report the incident to HHS and then HHS takes some time to post it to the portal, so there is often a serious delay. Even as I write this, mid-October there are likely breaches from the first half of 2023 that have not made it to the portal.

Still, the data can be illuminating:

The numbers rise pretty dramatically from 2020 to 2021 and leveled off a bit in 2022. As of right now, they’ve dipped a bit in 2023, but given delays in reporting they will likely shoot up (for example, running the same search for January 1st through October 15th of 2023 list 413 “Hacking/IT Incidents”). In fact, since there were only 64 publicly reported ransomware attacks through June 30th of 2022, I expect the number will increase significantly.

My point in writing about this is that I think, for all its flaws, the HHS reporting portal is a good model for what government cyber incident/ransomware reporting should look like (the Maine portal is another excellent example). Making reported data like this publicly searchable helps keep consumers informed, but also helps researchers better understand the scope of the problem. I definitely think there are changes that need to be made to the HHS portal, but it is a good start and the changes only need to be incremental from there.

Because if we can't protect the Earth, you can be damned well sure we'll avenge it.

— Tony Stark, Avengers

In an ideal world all cyberattacks would be stopped at the point of attempted intrusion and all the safeguards discussed in Part 2 of this series (and other places) would prevent ransomware groups from ever using PowerShell in the network. Unfortunately, in security none of us get to live in an ideal world.

This means we are often chasing alerts after IABs or ransomware groups have managed to gain access. In this case, the goal is to limit the damage they can cause, find them in the network and stop them before they can steal data, encrypt files, jump to other networks and more.

Given the pervasiveness of PowerShell in ransomware attacks, hunting for signs of PowerShell can provide those breadcrumbs to root out malicious actors and stop them before they cause damage to your organization. But, how do you do that?

As with most things in security, it starts with building a baseline. If you understand what PowerShel traffic within your organization is supposed to look like, then it is easier to spot the anomalies and stop them (unless, as has happened more than a few times, there are already threat actors in your network while you are building the baseline).

Most organizations build their baseline by collecting and analyzing PowerShell logs, but it also helps to talk to the teams that are using PowerShell to find out why and how they use it. I’ve been in many networks where building the baseline uncovers PowerShell scripts that were running for years that no one knows who initiated them or why. These discussions can also lead to more efficient and secure uses of PowerShell internally and they absolutely improve communication so teams know to inform the security team when they run a new script or change existing scripts.

Once you have built your baseline, you want to find a way to understand how adversaries are using PowerShell. Understanding their behavior helps build detections.

So, for example this excellent report from Unit 42 shows Vice Society using ExecutionPolicy Bypass command:

powershell.exe -ExecutionPolicy Bypass -file \\[redacted_ip]\s$\w1.ps1

It turns out that the ExecutionPolicy Bypass command is commonly used by a number of ransomware groups.

Another great example of how IABs and ransomware groups use PowerShell is to disable your security tools is in this report from Kroll:

C:\Windows\system32\windowspowershell\v1.0\powershell.exe -Command Set-MpPreference -DisableRealtimeMonitoring $true

Your organization is most likely not using either of these commands (at least I hope not) so hunting for examples of them in PowerShell logs can find malicious ransomware activity early.

Some ransomware groups try to mask their activity by encoding their PowerShell commands by encoding the commands, as pointed out by RedCanary:

powershell.exe -encod VwByAGkAdABlAC0ASABvAHMAdAAgACIAdAB3AGUAZQB0ACwAIAB0AHcAZQBlAHQAIQAiAA==

Their linked report includes methods for detecting the use of encoding in scripts.

These are three quick and relatively easy things you can look for in PowerShell logs that are usually signs of malicious activity. But, because you have built a baseline of PowerShell activity in your network, you can also start looking for anomalous traffic.

For example:

• Scripts running at odd times

• Scripts executed by a new network admin (side note: ANY time a new admin account is created should automatically draw an alert).

• Scripts running on or from machines that don’t normally run PowerShell scripts

• Scripts engaging in unusual (or possibly any) network probing.

Each organization is different and differs in how they use PowerShell. But if you have that baseline, and continuously update the baseline it is easier (not easy, easier) to find the oddities, flag them and stop a ransomware attack before it can do damage.

Most people associate Edgar Allan Poe with horror: The Raven, The Pit and the Pendulum, and The Masque of the Red Death are all masterworks of horror that have been presented in every medium over the last 180 years. But, Poe was much more than horror writer, he also wrote detective stories, science fiction stories and he wrote about cryptography.

In fact, in his lifetime, one his most popular short stories was The Gold-Bug. A story about the hunt for buried pirate treasure in South Carolina that can only be found by solving a cryptogram:

53‡‡†305))6*;4826)4‡.)4‡);80

6*;48†8¶60))85;1‡(;:‡*8†83(88)

5*†;46(;88*96*?;8)*‡(;485);5*†

2:*‡(;4956*2(5*-4)8¶8*;40692

85);)6†8)4‡‡;1(‡9;48081;8:8‡1

;48†85;4)485†528806*81(‡9;48

;(88;4(‡?34;48)4‡;161;:188;‡?;

Which translates to:

A good glass in the bishop's hostel in the devil's seat forty-one degrees and thirteen minutes northeast and by north main branch seventh limb east side shoot from the left eye of the death's-head a bee line from the tree through the shot fifty feet out.

Interestingly, in Poe’s story solving the cryptogram wasn’t enough, the protagonist actually needed to understand the lay of the land in South Carolina to get to the treasure.

The Gold-Bug is what sparked my interest in cryptography at a young age, and I am not alone. While Thomas Jefferson is generally considered the “Father of Cryptography” (a VERY disputed title) in the United States, there is no doubt that Poe popularized the idea of cryptography for the masses (at least in the US).

In fact, in 1936 Chief Signal Officer (and other Father of American Cryptography) William Friedman wrote:

It is a curious fact that popular interest in this country in the subject of cryptography received its first stimulus from Edgar Allan Poe. Should a psychologic association test be made, the word “cipher” would doubtless bring from most laymen the immediate response, “Poe” or “The Gold Bug.1”

But, it wasn’t just The Gold Bug. Poe wrote a series of essays entitled Secret Writing for Graham’s Magazine. He also a wrote a series of popular cryptograms for the Alexander's Weekly Messenger.

In short, as early as the 1840s, Poe had people thinking about cryptography, how to use and challenging them to solve these puzzles.

Friedman spends most of his essay trashing Poe’s cryptography skills, referring to Poe as a “tyro” (beginner or novice) and goes on to compare him to a “conjurer” and even mocks Poe’s preferred cryptogram, the Berryer.

But, there is one thing I think Friedman gets wrong. He quotes Poe from the Graham’s essay:

Few persons can be made to believe that it is not quite an easy thing to invent a method of secret writing which shall baffle investigation. Yet it may be roundly asserted that human ingenuity cannot concoct a cipher which human ingenuity cannot resolve.

The funny thing is, other than possibly OTP’s, most modern cryptologists believe that there isn’t a a cipher that can be written than can’t be solved, with enough resources. In fact, even though Poe couldn’t predict that Charles Babbage would break Le Chiffre Indéchiffrable - what was then considered an indecipherable code - in 1854 Friedman knew that had been accomplished and still felt it was possible to create an unbreakable cipher.

Hey! Get to the Cryptocurrency Part

What does all of this have to do with Cryptocurrency you ask? In 1849 Poe wrote in a letter to Evert Duyckinck:

If you have looked over the Von Kempelen article which I left with your brother, you will have fully perceived its drift. I mean it as a kind of "exercise," or experiment, in the plausible or verisimilar style. Of course there is not one word of truth in it from beginning to end. I thought that such a style, applied to the gold-excitement, could not fail of effect.

If you aren’t familiar with Poe’s article, Von Kempelen and His Discovery, it is an article published in April of 1849 in the magazine Flag of Our Union about a German scientist who found a way to turn lead into gold, raising the price of lead by 200% in Europe. The article is fictional, but there is no indication in the article that is such (similar to the way often people think War of the Worlds was originally broadcast on radio).

We have to remember that Poe was a writer of his time. According to Terence Whalen
in his paper. The Code for Gold: Edgar Allan Poe and Cryptography, that time consisted of alchemists trying to turn lead into gold and the move from gold and silver as primary forms of currency to bank notes:

In Money, Language, and Thought, Marc Shell offers a major reinterpretation of "The Gold-Bug" based upon the correspondence between the events of the story and the general economic context. "At a time," writes Shell, "when alchemists were trying to transform tin into gold by means of alchemy and financiers were turning paper money into gold by means of the newly widespread institution of paper money, Edgar Allan Poe was a poor author who could only wish to exchange his literary papers for money.2

The Gold Bug was written at a time of uncertainty about the changing nature of money. A time when a lot of con-men were offering solutions that weren’t real but there also wasn’t much trust in existing financial institutions.

Whalen, boils the essence of The Gold Bug down to this:

The treasure chest, which contains "no American money,” further indicates the central exchange of the story: not paper for paper, but code for gold.

My emphasis added.

The Gold Bug is readily available online (it is also available in comic book form, which is how I first read it), I’d recommend reading (or re-reading) it and you can start to pick out the similarities between Poe’s time and ours, and how the story could easily be released today as an allegory for cryptocurrency.

Before I begin, I have to thank Helen for the cool new email banner. Ransomware is such a serious topic that it is nice to be able to inject some fun into it when we can.

Speaking of serious topics: PowerShell and Ransomware. We know that initial access brokers and ransomware operators love to use PowerShell during their attacks, so how can organizations better secure it?

Alternatively, should organizations try to secure it or just remove it all together? In their guidance on securing PowerShell both Microsoft and the NSA/CISA/GCSB/GCHQ [PDF] all suggest that removing PowerShell is the wrong answer. It is better to secure it than to remove entirely, especially because so many security and incident response tools rely on PowerShell.

I don’t disagree with this guidance, but I do think it is a bit out of date. For example, in the Microsoft recommendation for client systems they state:

Client systems. After initial infection (by a macro-enabled document or user double-clicking a malicious executable), malware sometimes uses PowerShell as one component of its attack chain. Microsoft’s recommendation is not to block PowerShell completely, as PowerShell is required for many operating system and system management tasks. Microsoft’s recommendation is to limit PowerShell to authorized users and administrators to mitigate the use by commodity malware, as described by point #4 above (“Deploy Device Guard / Application Control Policies”). If Windows Defender Application Control is not an option, security products that block PowerShell from unknown parent processes (such as Word, Excel) are a reasonable middle ground.

Here is my problem with this advice, “…limit PowerShell to authorized users and administrators…” In theory, this works, but we know that in every ransomware attack the attack attempts to gain administrative access, which means that they will easily be able to bypass whatever restrictions are in place. You could make the argument that it is harder to gain administrative access if PowerShell is restricted, but tools like Mimikatz don’t require PowerShell to run.

This also means that organizations have to do a better job of managing least privilege across their Active Directory installation, including not giving everyone in the organization local Admin access (PLEASE, PLEASE, PLEASE DO THIS).

I understand the complications involved in removing PowerShell from client systems. But for organizations that can, it might be the easiest solution. I am going to turn on comments for this post, I would love to hear what you think.

Assuming you can’t remove PowerShell from client workstations, then the advice to restrict who can use PowerShell is good advice but, again, it also means you have to have strong identity and access management policies, which too many organizations do not.

Microsoft also recommends enabling Windows Defender Application Control (or its equivalent in other EDRs) and using that to restrict which programs can execute PowerShell. They recommend that only signed applications should be able to execute PowerShell and also to block commonly used phishing vectors, such as Microsoft Word, from executing PowerShell as well. Again, this feels like outdated advice, we’ve seen a number of attacks where cybercriminals used stolen keys to sign their malware, so it looked like a valid application.

The alternative, of course, is to create an “allow list.” Only applications on that list would be able to execute PowerShell scripts, everything else would be blocked by default.

So, now an organization has to not only have excellent IAM policies, but also application management policies as well. Which, honestly, most organizations, especially larges ones, should have in place — but too many do not.

Finally, both Microsoft and the Government(s) Bulletin above recommend enabling PowerShell Logging. I think this is a critical component to good PowerShell security and it is what I am going to focus on for Part 3 of this series. In short, good log analysis can help overcome a lot of the weaknesses associated with the other suggestions for securing PowerShell.

But, effective PowerShell logging requires good asset management. You have to ensure that you know that you are collecting logs from every systems that is running PowerShell. You also have to know what/where that system is when an alert is generated and be able to respond to the alert quickly.

In short, effective PowerShell security requires good:

• Identity and Access Management

• Application Control

• Asset Management

• Vulnerability Management (you have to keep PowerShell itself patched.

So, essentially, good PowerShell security requires all of the usual good security practice recommendations — go figure.

Today this silly little ransomware blog surpassed 100 subscribers. This may not seem like a big deal, especially since the blog is more than 2 years old. But, given my lack of marketing and inconsistent posting schedule, it is a big and (to me) surprising accomplishment.

Thank you all for your continued support!

This is the first of a 3 part series. In this post I am going to go over how IABs and Ransomware operators use PowerShell during attacks. The next post will cover how to limit access to PowerShell in your network and the 3rd post will cover how to threat hunt for malicious PowerShell usage.

The use of PowerShell starts with initial access. For example, Palo Alto’s Unit 42 documented IcedID’s use of PowerShell during the installation phase. After a victim downloads the trojanized malware it executes a PowerShell script to download the IcedID loader.

The Ukraine Cert documents the use of PowerShell during the installation of SmokeLoader. The installation includes a JavaScript file that uses a PowerShell script to download the malicious executable.

On the ransomware operator side, CISA reports that the BianLian ransomware group uses PowerShell to disable security tools using the following code:

[Ref].Assembly.GetType(‘System.Management .Automation.AmsiUtils’).GetField(‘amsiInitFaile d’,’NonPublic,* Static’).SetValue($null,$true)

Unit 42 also documents how Vice Society used a PowerShell script to automate the process of exfiltrating files from victim networks.

LockBit has also used PowerShell to distribute and execute their ransomware payload. The team at Packt does a nice job of documenting those LockBit scripts.

While these examples are specific to these ransomware groups, the reality is that many different groups use PowerShell to carry out the same tasks and more. Securing PowerShell in your network and hunting for malicious used of PowerShell can go a long way to protect you from ransomware attacks. I’ll talk more about how to do that in the next two posts.

It starts right from the beginning:

We have made multiple attempts to reach out to MGM Resorts International, "MGM". As reported, MGM shutdown computers inside their network as a response to us. We intend to set the record straight.

Are you upset that MGM didn’t want to talk to criminals? No one owes your criminal-ass a response.

After waiting a day, we successfully launched ransomware attacks against more than 100 ESXi hypervisors in their environment on September 11th after trying to get in touch but failing. This was after they brought in external firms for assistance in containing the incident.

Again, they are upset that the incident responders didn’t want to talk to criminals. What were you going to do if they got in touch with you? Go home, quietly? Stop the attack? These were people trying to defend their network, they didn’t have the time to deal with scumbags like you.

The user has consistently been coming into the chat room every several hours, remaining for a few hours, and then leaving. About seven hours ago, we informed the chat user that if they do not respond by 11:59 PM Eastern Standard Time, we will post a statement. Even after the deadline passed, they continued to visit without responding. We are unsure if this activity is automated but would likely assume it is a human checking it.

Again, no one owes you a response, no matter what arbitrary deadline you set. Also, you don’t like it when someone intrudes onto your infrastructure and lurks around doing who knows what? Maybe you should secure your infrastructure better.

We are unable to reveal if PII information has been exfiltrated at this time. If we are unable to reach an agreement with MGM and we are able to establish that there is PII information contained in the exfiltrated data, we will take the first steps of notifying Troy Hunt from HaveIBeenPwned.com. He is free to disclose it in a responsible manner if he so chooses.

Reach an agreement? You mean extort. You are criminals, you don’t reach agreements, you extort victims.

We believe MGM will not agree to a deal with us. Simply observe their insider trading behavior. You believe that this company is concerned for your privacy and well-being while visiting one of their resorts?

Again, it is not a deal. You are extortionists, you extort victims you don’t “make deals.”

We recognize that MGM is mistreating the hotel's customers and really regret that it has taken them five years to get their act together. Other lodging options, including casinos, are undoubtedly open and happy to assist you.

Victim blaming is also a common tactic among ransomware groups. MGM is not mistreating their customers, you are disrupting their infrastructure, and disruption to their customers is entirely YOUR FAULT. This is like a bank robber complaining that a bank couldn’t service customers while everyone in the bank was being held at gun point. It is ridiculous on its face.

We still continue to have access to some of MGM's infrastructure. If a deal is not reached, we shall carry out additional attacks. We continue to wait for MGM to grow a pair and reach out as they have clearly demonstrated that they know where to contact us.

MGM has proved they “grew a pair” by not talking to you and not negotiating with criminal scumbags like yourselves. And once again, IT IS NOT A DEAL, you are criminal scumbags and you need to accept that good organizations don’t want to deal with you.

From the late 1960s well into the 1980s there was an often mocked Public Service Announcement that would run just before the 10:00 PM News. The spot was just a few seconds long, showed the above (original) graphic and the iconic phrase was spoken in a deep baritone voice.

This was in a time when kids were, generally, able to play more freely, usually “until the street lights came on.” And it was supposed to serve as a reminder that parents should know where there kids are.

The same message can be applied to our data today. We all got a start reminder this week when CloudNordic was the victim of a ransomware attack that included not only their customer data, but secondary and tertiary backups. This means that all customer data is, effectively, unrecoverable. Especially since CloudNordic is doing the right thing and refusing to pay the ransom.

But, the truth is, we have been reminded of this all summer thanks to Cl0p’s MoveIT breach. According to TechCrunch, more than 1000 victims have been announced and more than 60 million victims have had data exposed in this breach.

We all need to get better at monitoring our data supply chain. If asset management is a challenge for many organizations, then data management is a nightmare. Asset management is almost always a function of IT, but every part of an organization creates and manages data. On top of that much of the data created in a modern organization is outsourced to second, third and fourth parties.

This means, as many companies are finding out from Cl0p’s MoveIT attack, that even if you do everything correctly if one of your supplier’s suppliers is hit with a ransomware or data theft attack it could leave your company exposed.

Levi Gundert talks about these challenges of monitoring and managing third and fourth party risk in this post. With data extortion increasingly important to ransomware groups (and many testing out the data extortion only model), knowing where your data is being stored, how it is being protected and planing for what to do if that data is exposed is important for all organizations to consider.