cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
ericgeater
Community Champion

Report on the May 2023 ransomware event in Dallas

Here's a little late-night reading from the City of Dallas, for anyone who'd like to understand the ransomware attack and remediation response they dealt with earlier this year.  I'm surprised the report is out this fast, but hats off to them for purportedly tackling this event.

-----------
A claim is as good as its veracity.
4 Replies
JoePete
Advocate I

While they go into detail describing the city of Dallas, ransomware, and the attacker (Royal) in question, they gloss over the most important element - the vector of attack. 

 

Example: "Royal’s initial access utilized the basic service domain service account, connecting to a server." To 99 percent of their audience, this is gobblygook, and yet it is the most critical piece of information: How did this attack take place? Dallas CIO and CISO have both been quoted as saying the attackers used "stolen credentials."  Piecing this together, I'm guessing some admin exercised less-than-good practices in creating some service account utilizing their credentials, which likely had far more privileges than whatever the service account needed to do. There are variations on that, but the credentials should not have been subject to pilfering (create distinct accounts) and the service account shouldn't have been able to grant the access it did (least privilege).

 

The Microsoft ecosystem just becomes an accelerant for this spark of vulnerability thanks to BATLOADER and Cobalt Strike. Homogeneity and excessive trust allowed one mistake to turn into pervasive access throughout the system. There is a requisite level of effort, policies, procedures, and controls (to ensure those policies and procedures) that doesn't seem to have happened. This is what drives me up a wall. We start throwing out all these fancy-sounding code names we've assigned to attackers and the malware they use, when the reality is the attack happened, not because some cyber Voldemort cast a spell, but because we skipped important steps. Why were those steps skipped? That's what the report should focus on. My guess is an honest evaluation will reveal poor communication and poor accountability that ultimately under-resourced or under-supervised these operations.

ericgeater
Community Champion

People like us get mad because final reports often leave out a lot of context clues.  Maybe that's a huge courtesy to not further embarrass the person who was likely the source of origin.

 

Me?  I'm not quite as nice.  I want the world to know it was 23fb72db1458cabd2df5d3c26c433698* and his unpatched RDP server.

 

* md5 if you're feeling frisky

-----------
A claim is as good as its veracity.
denbesten
Community Champion


@JoePete wrote:

they gloss over the most important element - the vector of attack. 


Keep the target audience in mind:

 

This document provides an After-Action Report (AAR) to the Mayor, City Council, and City Executive Leadership

This audience cares more about "As obligated under State law", "$8.5 million", and "39,590 hours".

 

Notable to me is that vector was a compromised credential and "legitimate remote access" tools (which I take to mean that they were owned by the City; not installed by the bad actor), yet the recommendations do not include anything to protect credentials, nor strengthen remote access, such as MFA, client certs, or VPNs.

 

It would also have been helpful to include a few technical details so that others could ensure the same attack would not succeed against them.

JoePete
Advocate I


@denbesten wrote:
This audience cares more about "As obligated under State law", "$8.5 million", and "39,590 hours".

Makes me recall some of my days in state government when a higher-up once said to me in a meeting, "I think you are telling us things that we'd rather not hear."

 

My dismay is more with the authors than the audience. One of the concepts in failure analysis is "no fault." The purpose is not to assign culpability, but rather, just to understand the failure mechanism and the probability of it happening again so that, ideally, it doesn't happen again. Often it does come down to human factors, but it never points to a single individual. If the sys admin in question made an error, was it because the person was overworked? was it because they were undertrained? was it because they shouldn't have been hired in the first place? These are all system/governance level errors. The entire document is a waste unless you dig into that level, or as you say:

 


It would also have been helpful to include a few technical details so that others could ensure the same attack would not succeed against them.