Understanding REvil: The Ransomware Gang Behind the Kaseya Attack | Hacker News Reader

Understanding REvil: The Ransomware Gang Behind the Kaseya Attack

unit42.paloaltonetworks.com

94 pointsweinzierl26 comments

How can “Excel macro” be still an attack vector after is issue has been known for 23 years? Or malicious email attachment?

> Below are the five unique entry vectors observed thus far in 2021.

- A user downloads a malicious email attachment that, when opened, initiates a payload that downloads and installs a QakBot variant of malware. In at least one case, the version of QakBot we observed collected emails stored on the local system, archived them and exfiltrated them to an attacker controlled server.

- In one instance, a malicious ZIP file attachment containing a macro-embedded Excel file that led to an Ursnif infection was used to initially compromise the victim network. Several actors utilized compromised credentials to access internet-facing systems via RDP. It’s unclear how the actors gained access to the credentials in these instances.

- An actor exploited a vulnerability in a client SonicWall appliance categorized as CVE-2021-20016 to gain access to credentials needed to access the environment.

- An actor utilized the Exchange CVE-2021-27065 and CVE-2021-26855 vulnerabilities to gain access to an internet-facing Exchange server, which ultimately allowed the actor to create a local administrator account named “admin” that was added to the “Remote Desktop Users” group.

@miohtama ..

You musn't never ever mention Microsoft windows in relation to malware. Remember it's ransomware or banking malware, never windows malware :]

Supply-chain!

Excel is a major component of Shadow IT:

* User has an important problem * Central IT will not oblige for whatever good or bad reason * User is both required and forbidden to resolve the problem, decides Central IT can stuff it, and writes a powerfull excel macro. * Other have the same pain, so User's macro gets copied, cloned, weirdly mutated etc... * At some point data has to be exchanged with another company, so they semi accidentally get the macro too. This introduces a required potentially malicious email atachment. * In all of this, everybody conspires to get Central IT out of it, as they will stop the macro and cause much pain and delay for everyone involved. In a lot of cases, Central IT does its utmost best to not officially notice the macro.

This is generally good, as it allows big corporations to survive, even in spite of Central IT. But it also means things like this attack easily happen.

Almost every organisation with more than about 150 people will over time devolve to some kind of soviet state with all kinds of institutionalized insanity. As long as humanity has not solved that sociological problem, this attack is the kind of fallout to expect.

Well, a lot of times it's not that Central IT won't oblige, it's more that the business

1. The busines doesn't want to spend money on procuring or developing a reasonable solution

2. They prefer the organic growth pattern by having a non-IT asset run development instead of having to do the long arduous task of requirements gathering and all the political battles involved.

Both of you are right on item one.

Hah yes we did this at the last company I worked for to categorize shipping info from our freight company’s api to an excel spreadsheet. Mostly did it because we didn’t want to check email all the time and IT did not want to give us a vps to run it on.

This attack apparently departed from previous tactics:

They deployed the payload via a trusted channel (Kaseya) which allowed deployment of any executable via system privs.

They looked for certain AV products and only executed if it was on their list.

They didn't delete shadow copies. (to avoid behavioral detection)

They didn't try to exfiltrate data. (to avoid behavioral detection)

They did a combo of automation and typical hollywood hacker on keyboard command and control.

No dwell time.

The ransomware has code which avoids computers that use Russian[1]

[1]: https://twitter.com/MalwareTechBlog/status/14129099009512202...

Why link to a tweet of a screenshot of a story about the report?

This is the source. https://www.trustwave.com/en-us/resources/blogs/spiderlabs-b...

And as far as I can tell they just arbitrarily claim that without evidence. The way they say it also makes it sound like a partial list of blocked languages, based on former USSR countries like Syria.

Syria is not a former USSR country my dude.

Syria has a lot of ties with Russia.

I'm aware, that's what the report says.

They were very much a soviet-bloc ally.

You think that they don't attack Russian/Ex countries and "Syria" means that claim they are Ex/Russian related is arbitrary?

They famously released Syrian data for free, a month or so later added the Syrian language to the ransomware -

https://krebsonsecurity.com/2019/07/is-revil-the-new-gandcra...

I'm saying they provide no evidence for the claim. They spend a long time going over what is in the config, which they link to, then just say "and they don't target these languages."

Your links supposed anonymous forum post is better evidence, though it's only evidence on the Syria claim is an unlinked announcement and the actions of a group they guess is related.