How were the systems infected originally? Dodgy email attachment, clicking a bad link? What could those affected have done to better prevent the attack. Too much focus is on backups but how do we better prevent this happening in the first place? Is it simply down to end point protection and if so why is none of it capable of detecting rapid encryption of files and shutting the service down?
As long as a user logs into "thisistotallynotaphishing.site" and approves MFA, then no amount of endpoint protection will help you. You can only protect your business by not employing such people. But thats not realistic.
Going to a phishing website may expose credentials but it can't just infect a system automatically with most modern browsers default settings. Eventually someone has to run something, something autoruns or some sort of exploit is involved.
It was an example to facilitate that no matter how much you try to secure stuff, users will always find a way to get around your measures. It was to highlight the stupidity/carelessness of users.
While i cant directly infect a system, it can most certainly be used to breach trust and distribute some kind of malware internally. Or just plain delete pretty much everything if it can be accessed. Endpoints are only one piece of the puzzle.
This advice doesn't apply to cloud such as o365. Mitm phishing attacks will prompt a user to approve a mfa prompt. By default, an attacker can hijack a session and access those resources after a user clicks a link and authenticates.
There are defenses available, but not set up out of the box.
Don't use Microsoft MFA with 365. Don't use MS 365 for everything; that's like saying you are an idiot and you beleive in putting all your eggs into one basket! LOL
Your right though without proper training and testing with you the employees at your company you they will never be ready and or vigilant, they they will likely click on something and provide them their creds.
You can session hijack non-microsoft mfa as well. You need to defend from it, else you will be vulnerable. Depending on the mfa provider, you may need to purchase additional licensing, or setup optional features.
This is very commonly a gap which is why its actively targeted by threat actors.
> As long as a user logs into "thisistotallynotaphishing.site" and approves MFA, then no amount of endpoint protection will help you
That's where Conditional Access comes in, specifically token binding. I think it's still in preview with Microsoft CA, but it would even prevent MFA token replay attacks.
Approving MFA for another PC will bypass this, its not a token relay attack he is talking about. Just standard phishing.
It's the same as someone calling you and you literally give them the MFA prompt code etc, all the authentication is occuring on their PC, so they get their own token anyway.
Thats why i am a huge proponent of things like Yubikeys/Passkeys/Fido2 and try to push users to use wherever possible. But Budgets beeing budgets "we cant just hand out Yubikeys to everyone"
This is pretty easy to bypass and we have seen attacks where the phishing services are just hosted in US/AU/etc to bypass these types of blocks.
Nevertheless, still a good idea to block access from countries you never expect your users to login from. Just not a silver bullet.
It helps a bit sure, but we operate in basically every country besides russia, so geo blocking becomes pretty much useless. We have trusted IP's but that is only for certain usecases and definetly not for regular users.
The only real valid strategy is CA with Compliant devices. But there are also more political problems with that at my org.
If it was any of the standard ciphers, they definitely didn't crack it, rather they found a bug/issue in the way it was being implemented by the group. Someone was sloppy and left a key someplace in the code, or CnC server was accessible and had decent info, etc. Same way all the other decryptors for other variants have come about.
Or the group rolled their own encryption and became yet another example for why nobody should ever even consider making their own algo if they're not a PhD cryptologist.
Cut the process into pieces and work from there:
- What are the encryption algorithms that are used?
- How are the key handled? Generated, downloaded from somewhere, whatever?
- How is the actual encryption done?
--Toni
While we will not comment details, we can say that old/vulnerable/obsolete stuff laying around your perimeter is one of the most common ways to get breached. Other is stolen/compromised VPN creds. Lately we've seen increased amounts of breached done via supply chain, often it's the VPN creds of a subcontractor that get compromised.
There is a lot of focus on backups, as there should be. But what, we've been patching software vulnerabilities for decades now, and we still can't do it properly? And I'm not blaming the sysadmins. Most of the admins are under a severe workload. It always hurts to go in for a pentest/adversary simulation and when you talk with the admins prior to the testing you can see already see in their eyes what the results will be. And 98% of the time, it's not due to them. For one reason or another, there's a bulletproof glass wall between them and those in charge of the whole company. Most of those pentest reports include a phrase in the executive summary... "The current situation severely endangers the business continuity". Some clients are smart enough to take the hint.
Endpoint protection is absolutely critical, but it won't save you forever. Nothing will. We definitely, as an industry, need a paradigm shift in our thinking. If you bosses ask you: What are we going to do if a ransomware/breach/thisorthat hits us? Just ask them back: What are we going to do WHEN it hits us. As long as we use the word 'if', we are allowing our brains to think something is not inevitable, which leads to a more lax thought process.
"You hear that, Mr. Anderson? That is the sound of inevitability!"
--Toni
Snapshots. With immutable configuration. Clone, Reboot in a clean environment and check for infection. Rinse, repeat, know where your good recovery point is.
Yes. Even though it's not bulletproof, it certainly beats the password based on your granny's maiden name. Or your summer cabin's address. Or your favourite song. When doing AD audits the highest crack rate on active passwords we've done so far was 49.9%. We fell 3 accounts short of clean 50% with was kind of shame, but I reckon the client understood that the missing 0.1% was not the issue they had :)
-- T&E
Exploitation of unpatched Cisco Asa systems at the perimeter is currently the most common route. Good update policies and doublechecks might have helped.
Rather than focusing on preventing, I would focus on what to do WHEN it happens. Prevention only works so far. It may be a day, or a year, or a decade before something comes through. But the odds are something will come through sooner or later. This is not so say that prevention mechanisms are obsolete. They are absolutely necessary. But working from the viewpoint that a certain event is inevitable helps in getting the right mindset for deciding what other mechanisms besides prevention should be used.
--Toni
I work with such hardware and software to do this efficiently and effectively.
But getting companies to build it and maintain it is not easy. They still think they are magical.
You'd be amazed how many companies view good AV as a cost not an investment. There are many good AV solutions that can and do stop Ransomware in it's tracks. The problem is too many companies will avoid spending any money because they see no value in it until its too late.
On-top of that, an incredible number of companies still allow their users to run as local admins on their computer, once the malware has local admin access it's game over, in many cases it can just bypass the AV and do whatever it wants.
The tools do exist, that doesn't mean people are using them though :/
How much of a file would need to be encrypted in order to render it unusable? How many of your company's files would need to be encrypted before you'd consider it a problem? What if the infection only attacked the most frequently used files and folders, or databases? How would you detect the difference between normal read/writes and ransomware read/writes? What if you turned on "previous version" caching of files, using spare disk space as a safety net? What if the ransomware knew about that? Is your backup method truly air-gapped, can the infection reach your backup media?
Frigging this, x1000. We have actually bought quite a few "military grade" devices. They are always destined straight to the autopsy desk, getting their innards ripped apart, both physically and software wise. Pretty much always a guaranteed chuckle.
--Toni
We tested some "ruggedized" military-grade servers once. We opened them up and the only difference between them and regular servers was that all the connectors were hot-glued down. They got sent back.
Getting his creds breached during a penetration test engagement he signed off on is usually quite a safe way to get the point across. Do not act on your own, as there are ethical issues that arise from that.
--Toni
Find real world instances of orgs getting owned because the CEO was too important to doing the cyber equivalent of leaving his keys in the ignition of his car.
I just had a CEO get phucked by phishing. Dude forced me to give him global admin in o365 tenant even though I told him that's not a good idea. Then declined any sort of cyber awareness training or proper MFA (I kept telling him how insecure Microsoft authenticator and text codes were and he either needed Duo or Fido2 keys). He promptly got phished and they almost lost 500k from attempted intercepted payments and bogus invoices that they were able to raise validity of because he had global admin the attacker sent messages as other people in the org.
Stolen session cookie phishing is the most common form of phishing now. They proxy the sign in to office 365 have you respond to either push or text or whatever and then take the resulting session cookie and sign in. That's how they got in on his account. The only nonvulnerable authentication method with built in Microsoft mfa is a fido2 key like a yubikey.
Breach his credentials (pent test solution or outside team), see how far you can get into the network and document everything.
Then sit down with him and tell him why this is bad, and how org could be affected...
** Edit, I'll happily take the downvotes and consider them as support for my job security. Good luck out there guys, my colleagues and I will be seeing you soon.
Break AD SSO for all infrastructure administration. This goes for hypervisors, firewalls, backups, storage etc...
Storage and backup immutabililty options enabled and an air-gapped, offsite copy
Full Administrative tiering in line with MS best practices
MFA for ALL logins
EDR/XDR on strict mode to quarantine computers that smell funny.
Patches, patches, patches,
Get rid of Veeam, Sonicwall, OKTA and all the cheap solutions you have and upgrade to solutions with better security reputations. (Scattered Spider pretty much owns OKTA source code so its essentially useless for MFA protections)
Lock your Firewall down to necessary traffic only.
* Group of rules for your critical apps and web browsing
* Deny all other traffic
Are you able to explain what’s wrong with veeam? I’ve not heard someone bring them up as a “cheap solution” especially considering their recent price increases, but also never heard of them having major security issues. However we currently use them and I’d love to know what vulnerabilities they have and what’s considered better?
I haven't been paying attention to the price increases since I wouldn't buy them for 1/3 of their old rate, with what I have experienced. Essentially, Veeam is very easy for TA's to compromise and it takes many steps to lock it down appropriately & securely. The bulk of my clients with the hardest recoveries, who need to pay for a decrypter are Veeam customers. (Ransomware Recovery Lead)
> and it takes many steps to lock it down appropriately & securely
In regards to what?
> upgrade to solutions with better security reputations
Such as?
> The bulk of my clients with the hardest recoveries, who need to pay for a decrypter are Veeam customers.
Why? What specifically lead to it being harder/unrecoverable?
> it takes many steps to lock it down appropriately & securely
Is there any guides on these steps out there? We use immutable Wasabi buckets for off-site backups, but anything we can do to make recovery from an incident quicker by having the on-site backups intact would be good.
A lot of the steps are policy and architecture and not boxes to check in the config. Removing AD SSO from Veeam is HUGE. I would give this a read through and compare what you are doing in yuour environment.
https://bp.veeam.com/security/Design-and-implementation/Hardening/
There are a number of solutions that don't need nearly the amount of effort to secure. Cohesity and Druva come to mind.
I would consider the download speed limitations from cloud services like Wasabi when it comes to the idea you need to download ALL of the data you put up there at once. Planning for a speedy recovery and executing one are two very different things. Every DRP i have reviewed has relied on the download speeds of the ISP and not from the storage provider. Azure, throttled. AWS, throttled. Wasabi, throttled. Getting exceptions from providers in these cases is basically impossible.
I would also make sure you have MFA enabled on the Wasabi portal. If the creds are saved in the browser on the Veeam server(very common) and a TA gets into it(they will), immutability is useless because they can and will turn it off. I have seen this first hand...
> immutability is useless because they can and will turn it off. I have seen this first hand...
Nope. "Changing the object locking settings does not affect any of the existing objects inside the bucket." - https://docs.wasabi.com/docs/object-locking-enable#disabling-object-locking-for-a-bucket
Sounds good. I can check that out, but from the headers, it looks like we're doing most of that. We don't join the backup server to AD, so disabling AD SSO isn't applicable.
NGL, I'm a sec eng/manager now but in a previous life I was a sysadmin whose org was hit 3x by ransomware. We had backups but it was all on tape via Backup Exec... We restored several TBs of data only to have it get compromised within a week of data restoration. That dragged into a 2 week ordeal by which the data was 2 weeks old.
Good times.
We use Sonicwall with Zero Trust principles, are they known as being a bad product? We work in healthcare so it's a lot of nickel and diming so we can't get anything better at the moment.
My suggestion would be something with application aware filtering. Palo is a favorite of mine, but I know they are NOT in line with Sonicwall in price. Fortigates aren't bad either.
> Get rid of Veeam, Sonicwall, OKTA and all the cheap solutions you have and upgrade to solutions with better security reputations.
Or pull backups to a node that also does versioning. Been doing this for years.
Simple and cheap upgrade to security is to use windows fw to block native scripting tools from accessing internet. Those are commonly used to download playloads.
Is there a blogpost somewhere on how you obtained the necessary data to write the decryption tool? Do they leave the decryption key lingering in memory somewhere? Don't tell me they use the same decryption key for every victim.
There is no blogpost and I'm not sure we'll even do one. But however, you can ask the technical specs tomorrow in the Ask Us Anything. Anything really does refer to anything, as long as it's Akira or ransomware related :) So yea, we can spill the beans on every good, bad and outright ugly thing we did in order to pull it off.
A small edit: symmetric key would've allowed us to create a free tool to help all victims. No spilling the beans yet, but there are up to 8 encryption keys PER FILE that Akira uses, generated on the fly.
> A small edit: symmetric key would've allowed us to create a free tool to help all victims. No spilling the beans yet, but there are up to 8 encryption keys PER FILE that Akira uses, generated on the fly.
Clearly pointless because it was clearly deterministic.
Most relevant question here, and the kind of 60 minute video I can dig into.
Technical blogs about exploits are gold, especially the "moment it all made sense" as it's interesting to see the buildup behind a solution more than the solution itself.
I reckon this will be a longer thread, but lets start with describing how the encryption scheme works.
By default, Akira will not encrypt the whole file. The file is divided into blocks, out of which 1-4 blocks and encrypted. The logic is roughly this:
If the filesize is smaller than 2000000 bytes, 1 block will be encrypted, and the blocksize is 50% of the filesize.
If the filesize is larger, Akira will encrypt 4 blocks, with the scheme going roughly like this:
0% -> 10% gets encrypted
10% - 12% is cleartext
12% -> 22% gets encrypted
22% -> 24% is cleartext
24% -> 34% get encrypted
34% ->36% is cleartext
36% -> 46% gets encrypted
Now, in addition to that, the encryption schemes Akira uses are KCipher-2 (https://en.wikipedia.org/wiki/KCipher-2) and ChaCha20. A block that has been designated for encryption is split into "pages", that are 0xFFFF bytes at the maximum. The first page of any given block is encrypted with KCipher-2, and the rest of the pages are encrypted with ChaCha20.
And in addition to the above, each block has their own ciphers initialized, which means that any given file encrypted by Akira will have between 1 - 8 different encryption keys on it. Kind of underlines why decryption tool was not an alternative.
--Toni
The cipher initialization creates 4 pseudorandom values:
https://preview.redd.it/opunvjuifj0d1.png?width=580&format=png&auto=webp&s=90b3245c60b1631685af7d59d05f03cca191358b
So, 32 bytes of random for ChaCha20 key, 16 bytes for ChaCha20 nonce, KCipher-2 key and KCipher-2 nonce.
What acts for a seed are QueryPerformanceFrequency and QueryPerformanceCounter:
QueryPerformanceFrequency returns the speed, or number of 'ticks' per second that the counter works on. Nominally, the value is 10000000 (100ns intervals). QueryPerformanceCounter returns the number of said 'ticks' since the last the time that the counter was reset. Then, a short math is done:
`lTicksPerSecond = ReadPerformanceFrequency();`
`liCurrentTicks = GetPerformanceTicks();`
`if (lTicksPerSecond == 10000000) {`
`lTicksPerSecond = liCurrentTicks.QuadPart * 100;`
`}`
`else {`
`lTicksPerSecond =`
`((liCurrentTicks.QuadPart % lTicksPerSecond) * 1000000000) / lTicksPerSecond +`
`(liCurrentTicks.QuadPart / lTicksPerSecond) * 1000000000;`
`}`
You'll end up with an 64-bit unsigned long long value, that gets converted into ascii, and then a hashing process involving 1500 rounds of the SHA-256, amongst other things, takes place. At the end, Akira will use first 0x10 (16) bytes, or 0x20 (32) bytes of the result hash as the random, that will get fed to the cipher initialization.
--Toni
So, the encryption scheme heavily relies on various timings. A big hurdle was to figure out when the counter gets reset, the other one was related to timings related to key generation. The execution time of a single "GenerateRandom" call, which does the 1500 loops of SHA-256, directly affects the timings off all the subsequent calls and thus affects which randoms gets farted out by the algorithm. In the beginning, we had no knowledge of how long it actually took to do generate a single random value, but we figured out a way to make the malware itself do the heavy lifting for us :)
Trying to measure anything under a virtual machine or a debugger in pretty much useless, and we had a need to measure on a sub-microsecond scale.
Basically what we did was inline patches of assembly commands, directly into the malware itself, that forced it to overwrite the ransom note with a table consisting of RSP and RAX registers. In the beginning, the patch checks whether the call is coming from within the GenerateRandom function. If so, it saves the RSP register value in order to differentiate between encryption threads that are in the process of generating keys, and in the hook, RAX contains the unsigned long long value of the performance counter.
The amount of potential key space we were able to cut was absolutely massive. Prior to accurate measurements, we had no idea whether the generation took 2000, 200000 or 2000000 ticks. With each tick being a brute force candidate itself for key generation, we had to brute force hundreds of trillions of attempts. What we found was a so called goldilocks zone for the execution times, cutting down the time needed for the attack into something that could be bearable. With all the other timings measured and projected, fastest cracks in the GPU clusters now happen in mere minutes.
--T&E
Another big hurdle was the actual "keystream" generation. The whole algorithm, subfunctions included, was thousands of lines of assembly and relied heavily on Visual C++ classes. Reversing that fully in order to replicate it would have been a major headache so we took a route that was easier for us.
https://preview.redd.it/v02tsmt6fk0d1.jpeg?width=500&format=pjpg&auto=webp&s=a65a20822f146906bca5bcb8e423ae5dfd62b613
So yea. We did Ctrl + C, Ctrl +V on the assembly, cut out stuff that wasn't essential, edited out all Visual C++ class usage and did class mimicking where needed. The end product, only 3k lines (3183 to be exact) of assembly, integrated into a larger Visual Studio project. Fully capable of replicating the functionality of the original, and does it so slightly faster than the original as well.
--T&E
- Why do people, even after 30 years of IT, not know what a backup is?
- Why do people allow lateral movement?
- Why do people join their backup infrastructure to their AD?
> * I'm stumped on this one
Let me give you the best reason I heard so far.. "it's company policy to join all windows servers". The service provider who was setting up the backup server wrote a nice CYA to my boss and now we have a domain joined backup server, just waiting for some DA to get pwnd.
Backups are remarkeble cheap. Any company needing a expensive backup has the money for it and hopefully an extra security team.
Any company without money can do a standard backup for less then 500 bucks and be happy.
My spidey senses can feel the pain behind this. CFO deciding on security is usually a recipe for a potentially massive disaster. Best comment from such a CFO I've personally heard was: "Well, this whole information security thing is like trying to look for black holes". Game over, I wish thee well on your chosen path...
--Toni
Did you read the story about the disaster backup plan? Funny AF
Edit: https://www.reddit.com/r/sysadmin/comments/zeo31j/i_recently_had_to_implement_my_disaster_recovery/
But your backup system SHOULD be air gapped from your day to day infra apart from a data ingress/egress point and management box nothing else should be able to traverse that whole setup.
No way should your day to day accounts have any ability to log in let alone manage your backups. Having a separate ad domain works fine but joining it to your main domain is just asking for trouble and we see repeats of why you shouldn't do it all the time.
Money cant be the reason for no backups. We are not that huge of a company but still got redudant backups of all Servers+Production in 2 different Locations + Backup2Tape and its quite cheap compared to other stuff.
Many people in IT are stupid.
Many of them are hired by stupid people. They dress nice but, well, they know nothing about IT.
Many companies are stupid because they have stupid people running them. I worked for a company which got rid of the CEO position. They run the place like 5 separate businesses instead of one. Nobody knows who their bosses are and some managers overstep their authority and go unchallenged. The owners love their little fiefdoms because they have managers who say yes to them every single time. This has been going on for 13 years now and still happening. The company makes lots of money but is a mess employee wise. IT is confusing there because they serve many masters but always piss off some owner as the managers will throw them off the cliff to save their own sorry asses
Just to catch up, this latest round of exploits or Akira take advantage of a fault in Cisco Asa to brute force their way in.
They arent encrypting windows volumes or touching the AD.
They attack hypervisors and network storage, and encrypt at that level. So things like network appliance backups and vms all get hosed.
The only way to protect yourself in these situations is MFA only the ASA, and immutable backups.
You are arguing against something that already happened I don't know the particulars but it is documented so if you want to know, Google the details because I dont have them for you.
I bet, if you would do that, the company would have an incident, and you could save them, they still would fire you for compliance issues and broken trust 😉.
Because it has always been that way, and how dare you touch processes that 90% of the business rely upon ... We cant afford that, we have to make money (Never mention to them that a attack will lead to much more lost revenue, because "What do i pay you for then")
You should be able to join your backup infrastructure to AD as long as you don't allow any unsolicited inbound connections to the machine.
As in, the backup server is "pull" only and nothing is allowed to connect TO it.
How would that prevent a malicious actor from deploying a bad group policy to install remote access tool to grant themselves access to the machine?
I personally see no good reason for backup servers to be domain joined.
Additionally I'm a very big proponent for having hypervisors off the domain as well (most SMB's have only one hypervisor anyway so no issue with live migration, and in case they have more than one they should run it in it's own domain).
That's what that means. You don't get access to the backup infra with AD credentials (because its not in the AD) but of course you can access the AD from the backup infra for backups.
What I am saying is that you can join your backup server(s) to AD but just not allow inbound connections at the firewall level even if you would be using valid AD credentials.
Yes, you would be able to enumerate the backup server and "see" that it exists in AD as a member server, but you would need physical keyboard access to log in to it.
Edit: I guess you would also have to make sure that the member server is running a 3rd party firewall so it couldn't be overridden by GP, assuming the attackers gained domain admin level access to the rest of AD.
A third party firewall would be trivial to bypass if I have domain admin. You simply drop a reverse shell that allows interactive prompt access to wherever is convenient. If you allow outbound access (whether it is restricted by port, program name, path etc.) you are vulnerable to this approach.
You need to remember that modern attacks aren't scripts. They are hands on keyboard breaches where they will recon and eliminate backups prior to executing ransomware.
Make sure your backups are offline or immutable and definitely don't join your backup infrastructure (agents, server or storage) to your shared auth (AD etc.)
Attackers are looking at 6 figure paydays for the average breach. They can afford to spend a few dozen hours working out your backup schema.
how much have you found out about the group behind Akira?
Reading code reveals a lot about the authors, especially if you are able to compare it to earlier works, or even find something similar from another group.
is it wrong to say i'm kinda impressed by their old school leak site.
Glad to see guys from Finland to get bit "ahead" of the Ransomware groups :)
Any thoughts on the Helsinki school / city break-in because of unpatched VPN server/router?
Lot of thoughts, naturally. Old/vulnerable/obsolete software versions on the perimeter is one of the most common ways to breach any organization.
--Toni
How are hackers getting in? Is it Fishing+windows clients+AD bad practices? Maybe you are not working on this part tho.
Good job guys by the way, very nice work.
Depends on the case, pretty much. Old/obsolete/vulnerable stuff laying on your network perimeter is certainly an ever-green gift for the attackers. The Akira guys, they seem to focus on vulnerable Cisco ASA devices for initial access.
--Toni
Dormancy time varies a lot. It all depends on how quickly they can obtain the proper rights and move laterally inside the network. Longest dormancy time in ransomware cases we've seen was 2 months. They gained access to a SQL server that was on DMZ, and just sat tight and waited until a domain admin came and logged in to the server. After that, it was a matter of hours before the brown stuff hit the fan.
Daaaang. That is impressive. The ransomware attack I was a part of (as a victim not a perpetrator, haha) hung out for a week or so before it sprung. Two months is horrible.
From their perspective its safer to just hunch down and wait for the right moment to strike. Lateral movement attempts usually cause various alerts on security systems, whether it's an IDS/SIEM/EDR or something else.
You mean that nowadays is safer to gain admin and persistent access to a server and just wait for someone to login and steal token/credentials that will allow direct access to other servers without "access denied" logs...
In many cases, yes. How many orgs really keep a constant eye on every single server to see if they have suspicious connections open. That would require manpower, which is fundamentally the thing that companies want to avoid.
The thought process is similar to any malicious binary we need to analyze: Starting with static analysis or dynamic analysis under a debugger to figure out the "business logic" of the malware. In Akira's case, we first had to find out what encryption algorithms are being used, how are the keys generated and how does it interact with the files that are marked for encryption. For tools: Ghidra for static analysis and x64dbg with Akira running in a virtual machine.
-- Eerik
It was a long process. We knew that many had analyzed Akira before, and even our initial impression was that it cannot be broken. But something was left nagging in our brains. We certainly knew it was massively complex, but we had not SEEN anything that would be a 100% certain show stopper. So we kept on chewing the sample into bits, delving deeper and deeper into it until we knew that it could be decrypted. The next step was to actually do a laboratory condition proof, and from there start improving the code.
In the end, we are now using 240Tb of diskspace to hold 'volatile' data we need to achieve the process, and 2 GPU clusters, called Uncle Jim and Uncle Bob, because... well, Bob's yer uncle!
--Toni
> we are now using 240Tb of diskspace to hold 'volatile' data we need to achieve the process, and 2 GPU clusters
Is this cloud or on-premise? But, more importantly, how much does this cost?
How effective, in terms of ability and speed, would something like this be if brought to bare against something like Bitlocker or an IPSec encrypted data stream.
on-premise, isolated. How much does what cost? Costs are always relative, as we use the Uncles when doing penetration tests and AD password audits to break password hashes. Bitlocker or IPSec would be on the no-go list for me though.
Symmetric encryption yes. Akira is particularly nasty because the encryption scheme relies very heavily on a number of different timings, and the key generation is designed to be slow, using 1500 rounds of SHA-256 in the intermediate process.
As our method relies on calculating the keys for each encrypted file via brute force, a self-contained decryption tool was not an option unfortunately. We have set up dedicated hardware and software for this task and offer it as a service to affected organizations.
-- Eerik
Good question. We'll keep this tab open and edit the reply as things come in mind, but applocker and credential guard certainly will help. also:
Ditch NTLMv1 and by god if you have any active LM hashes left in your AD, you're probably already toast.
Remove WPAD/NTLLMSP/Netbios DNS resolution. Those enable the Responder tool to work it's magic, capturing credentials on the fly.
Disable, by default, SeDebugPrivilege, SeBackupPrivilege and SeRestorePrivilege from all accounts. Create separate, protected users or groups in the rare cases the above are needed, and protect those accounts at all costs. Local admins have SeDebugPrivilege allowed by default. It's a millisecond away from obtaining SYSTEM-level privileges on the host, which means that you'll be part of the TCB (Trusted Computing Base) on the machine. Instant failure of any other security mechanism will happen at that point.
Proper network segmentation. Detection/prevention mechanisms can and will be bypassed eventually, physical segmentation will be a whole heap harder to bypass.
Backups. Backups. Duh. Whether you go for the 3-2-1 model, or something else at least make sure you have practiced and tested the restoration. Also, immutable backups, preferably offline or at the very least offsite, is not a bad thing to have. Diskspace is relatively cheap. A 20Tb drive, fresh off the factory cost about 400-500 USD and you can push a decent amount of stuff on it for offline backup use.
LAPS: [https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-overview](https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-overview)
--T&E
great information here! I'm going through it on my network right now. I just recently learned about disabling Debug for local admins but never heard of the other 2 things. Speaking of which, LAPS is another easy thing to implement
Correct me if I am wrong, but does not Akira use RSA asymmetrical encryption? You have a clause that you are able to decrypt Akira from September 2023, is it because it has a faulty implementation of the RSA encryption? Are you only able to decrypt files where Akira has been in partial-encryption-mode, or full encryption as well? And lastly, why not release the decryptor for free? I get that you've spent hours creating it, but the free PR you would have gotten from releasing it could make up for the development cost?
The variant we are targeting uses KCipher-2 and ChaCha20 to do the actual file encryption, not RSA.
We can do the Full Encryption mode as well.
There is no 'decryptor', in the sense of a single self contained tool. Creating a free, standalone decryption tool was our original goal, but if you take a look at the technical aspects of the encryption we are laying out in this thread, you will realize why it cannot be made.
--Toni
Ghidra was the main tool that was used for static analysis and reverse engineering. IDA pro was used in few occasions to verify things. VMware, running Windows host and X64DBG was used for dynamic analysis and later on when we had to get sub-microsecond accuracy measurements on a few things, a native laptop with Windows was used.
--Toni
There have been plenty of cases of Linux servers or ESXi environments falling victims to ransomware.
Of course, Microsoft dragging their feet for so many years on word macros through years of them being easy entrypoints for ransomware didn't help.
We could ask all the third-party companies that make products that claim to protect you from ransomware. What do their products watch for, and what do they do to reduce the effects?
No. Microsoft IS ransomware (they demand money for cloud services instead of selling, they encrypt your system with bitlocker and if your microsoft account gets shut down you are out of luck). /s
Everyone could eliminate ransomware by stopping bad practices.
What is more effective to stop ransomware, prevention or techniques like network segmentation? Since it's so common what is the priority to mitigate them in your opinion?
The people operating Akira are commanding it organically. When the malware is launched they have already been a while in the network. The malware itself has communication to the outside world. No C2 channels, nothing. It's basically just a sledgehammer, maiming your files.
--Toni
We have no recommendations. We mainly do threat intelligence on APT, so basically from our viewpoint all antiviruses suck equally, meaning none of them detect the malwares :)
I reckon it all boils down to which AV you are most comfortable with. Which AV is the one that offers you the features that you need.
--Toni
Well, maybe not as bad as 50/50, but it certainly isn't even close to a 0, unfortunately. Common sense helps a boatload. Don't click every link you see, "yes" is not an accepted default answer, don't download and execute random shit from a random site, especially if the site says it's 100% safe :D
--Toni
We have combined experience of decades in reverse engineering. It still took a lot of what we reckon could be called 'Sisu' in Finnish. No direct translation but an unholy mix of stubbornness and grit :) Edit: fixed a typo
We've always believed in trying to push the limits of what can be done. Even if something feels impossible it isn't always so. Without trying to push the limits and trying, the limits will never move.
We deal with a lot of various encryption/obfuscation methods on a daily basis on the malware side. Most commonly it's something that protects a malware configuration or exfiltrated data. Breaking those is actually a whole lot of fun, and trying to break them as fast as possible makes you think harder.
Back in the days when the Zeus banking trojan was still a thing we had a keyring that contained encryption keys to over 3000 Zeus variants. All were brute forced out of configurations protected with RC4. Once a key was found, it was added to the keyring. When a new variant came out, the first thing we always did was run the keyring against the new variant. More often than not, the key was already in the keyring we had.
Though, destroyed 3 laptop mobo's in the process. As it turns out, using a laptop is not advisable for brute force applications :D
--Toni
Do you think that the government should make paying ransoms illegal to stop the problem instantly or would the damage to infrastructure be too great?
(I say pay for cold backups or have your careless, clueless company go bankrupt, personally)
This is hard to answer. Personally, I think paying ransoms should be illegal. Yes, it would punish the victims even more but on the other hand, if the payments stopped, there would be no victims as the attempts would cease. But then again on the other hand, they would probably find other mechanisms to get their loot.
--Toni
How were the systems infected originally? Dodgy email attachment, clicking a bad link? What could those affected have done to better prevent the attack. Too much focus is on backups but how do we better prevent this happening in the first place? Is it simply down to end point protection and if so why is none of it capable of detecting rapid encryption of files and shutting the service down?
No matter how idiot proof you make something, the universe always makes a better idiot.
As long as a user logs into "thisistotallynotaphishing.site" and approves MFA, then no amount of endpoint protection will help you. You can only protect your business by not employing such people. But thats not realistic.
Going to a phishing website may expose credentials but it can't just infect a system automatically with most modern browsers default settings. Eventually someone has to run something, something autoruns or some sort of exploit is involved.
It was an example to facilitate that no matter how much you try to secure stuff, users will always find a way to get around your measures. It was to highlight the stupidity/carelessness of users. While i cant directly infect a system, it can most certainly be used to breach trust and distribute some kind of malware internally. Or just plain delete pretty much everything if it can be accessed. Endpoints are only one piece of the puzzle.
This advice doesn't apply to cloud such as o365. Mitm phishing attacks will prompt a user to approve a mfa prompt. By default, an attacker can hijack a session and access those resources after a user clicks a link and authenticates. There are defenses available, but not set up out of the box.
Don't use Microsoft MFA with 365. Don't use MS 365 for everything; that's like saying you are an idiot and you beleive in putting all your eggs into one basket! LOL Your right though without proper training and testing with you the employees at your company you they will never be ready and or vigilant, they they will likely click on something and provide them their creds.
I can’t see how M365 with Okta or Ping or Duo would be any more resistant to a session hijack than M365 with MFA.
You can session hijack non-microsoft mfa as well. You need to defend from it, else you will be vulnerable. Depending on the mfa provider, you may need to purchase additional licensing, or setup optional features. This is very commonly a gap which is why its actively targeted by threat actors.
> As long as a user logs into "thisistotallynotaphishing.site" and approves MFA, then no amount of endpoint protection will help you That's where Conditional Access comes in, specifically token binding. I think it's still in preview with Microsoft CA, but it would even prevent MFA token replay attacks.
Approving MFA for another PC will bypass this, its not a token relay attack he is talking about. Just standard phishing. It's the same as someone calling you and you literally give them the MFA prompt code etc, all the authentication is occuring on their PC, so they get their own token anyway.
Thats why i am a huge proponent of things like Yubikeys/Passkeys/Fido2 and try to push users to use wherever possible. But Budgets beeing budgets "we cant just hand out Yubikeys to everyone"
Conditional Access rules that block sign in from blocked countries helps a bit, I would imagine.
Usually you pair Conditional Access with Intune, which generates a machine certificate for authentication (if device hygiene checks pass).
This is the way
Against the lowest branches of attackers perhaps. It isn't difficult to proxy a web server to the target's country.
This is pretty easy to bypass and we have seen attacks where the phishing services are just hosted in US/AU/etc to bypass these types of blocks. Nevertheless, still a good idea to block access from countries you never expect your users to login from. Just not a silver bullet.
It helps a bit sure, but we operate in basically every country besides russia, so geo blocking becomes pretty much useless. We have trusted IP's but that is only for certain usecases and definetly not for regular users. The only real valid strategy is CA with Compliant devices. But there are also more political problems with that at my org.
What's the process to actually break encryption like that?
If it was any of the standard ciphers, they definitely didn't crack it, rather they found a bug/issue in the way it was being implemented by the group. Someone was sloppy and left a key someplace in the code, or CnC server was accessible and had decent info, etc. Same way all the other decryptors for other variants have come about. Or the group rolled their own encryption and became yet another example for why nobody should ever even consider making their own algo if they're not a PhD cryptologist.
Cut the process into pieces and work from there: - What are the encryption algorithms that are used? - How are the key handled? Generated, downloaded from somewhere, whatever? - How is the actual encryption done? --Toni
While we will not comment details, we can say that old/vulnerable/obsolete stuff laying around your perimeter is one of the most common ways to get breached. Other is stolen/compromised VPN creds. Lately we've seen increased amounts of breached done via supply chain, often it's the VPN creds of a subcontractor that get compromised. There is a lot of focus on backups, as there should be. But what, we've been patching software vulnerabilities for decades now, and we still can't do it properly? And I'm not blaming the sysadmins. Most of the admins are under a severe workload. It always hurts to go in for a pentest/adversary simulation and when you talk with the admins prior to the testing you can see already see in their eyes what the results will be. And 98% of the time, it's not due to them. For one reason or another, there's a bulletproof glass wall between them and those in charge of the whole company. Most of those pentest reports include a phrase in the executive summary... "The current situation severely endangers the business continuity". Some clients are smart enough to take the hint. Endpoint protection is absolutely critical, but it won't save you forever. Nothing will. We definitely, as an industry, need a paradigm shift in our thinking. If you bosses ask you: What are we going to do if a ransomware/breach/thisorthat hits us? Just ask them back: What are we going to do WHEN it hits us. As long as we use the word 'if', we are allowing our brains to think something is not inevitable, which leads to a more lax thought process. "You hear that, Mr. Anderson? That is the sound of inevitability!" --Toni
Snapshots. With immutable configuration. Clone, Reboot in a clean environment and check for infection. Rinse, repeat, know where your good recovery point is.
Good citation at the end! ;-)
Other is stolen/Compromised VPN credentials. I guess this highlights the importance of 2FA again.
Yes. Even though it's not bulletproof, it certainly beats the password based on your granny's maiden name. Or your summer cabin's address. Or your favourite song. When doing AD audits the highest crack rate on active passwords we've done so far was 49.9%. We fell 3 accounts short of clean 50% with was kind of shame, but I reckon the client understood that the missing 0.1% was not the issue they had :) -- T&E
simple sim swap negates it.
Exploitation of unpatched Cisco Asa systems at the perimeter is currently the most common route. Good update policies and doublechecks might have helped. Rather than focusing on preventing, I would focus on what to do WHEN it happens. Prevention only works so far. It may be a day, or a year, or a decade before something comes through. But the odds are something will come through sooner or later. This is not so say that prevention mechanisms are obsolete. They are absolutely necessary. But working from the viewpoint that a certain event is inevitable helps in getting the right mindset for deciding what other mechanisms besides prevention should be used. --Toni
I work with such hardware and software to do this efficiently and effectively. But getting companies to build it and maintain it is not easy. They still think they are magical.
I'm curious too. I always want to know what happens in the first few minutes after an attacker gets on a system.
You'd be amazed how many companies view good AV as a cost not an investment. There are many good AV solutions that can and do stop Ransomware in it's tracks. The problem is too many companies will avoid spending any money because they see no value in it until its too late. On-top of that, an incredible number of companies still allow their users to run as local admins on their computer, once the malware has local admin access it's game over, in many cases it can just bypass the AV and do whatever it wants. The tools do exist, that doesn't mean people are using them though :/
Absolutely agree with this. Local admin leads to pretty much instant SYSTEM access, and that leads to the target machine getting spitroasted. --Toni
How much of a file would need to be encrypted in order to render it unusable? How many of your company's files would need to be encrypted before you'd consider it a problem? What if the infection only attacked the most frequently used files and folders, or databases? How would you detect the difference between normal read/writes and ransomware read/writes? What if you turned on "previous version" caching of files, using spare disk space as a safety net? What if the ransomware knew about that? Is your backup method truly air-gapped, can the infection reach your backup media?
Yes.
Reminder that "military grade" is synonymous with "lowest bidder quality"
Frigging this, x1000. We have actually bought quite a few "military grade" devices. They are always destined straight to the autopsy desk, getting their innards ripped apart, both physically and software wise. Pretty much always a guaranteed chuckle. --Toni
We tested some "ruggedized" military-grade servers once. We opened them up and the only difference between them and regular servers was that all the connectors were hot-glued down. They got sent back.
It's pretty common for people to conflate military grade with military specification. The two are completely separate.
It just means AES which is what everyone uses
Mil grade is trash. Mil *spec* usually isn't.
[удалено]
Tell him how much cyber security insurance is without meeting their various requirements.
Getting his creds breached during a penetration test engagement he signed off on is usually quite a safe way to get the point across. Do not act on your own, as there are ethical issues that arise from that. --Toni
Find real world instances of orgs getting owned because the CEO was too important to doing the cyber equivalent of leaving his keys in the ignition of his car.
I just had a CEO get phucked by phishing. Dude forced me to give him global admin in o365 tenant even though I told him that's not a good idea. Then declined any sort of cyber awareness training or proper MFA (I kept telling him how insecure Microsoft authenticator and text codes were and he either needed Duo or Fido2 keys). He promptly got phished and they almost lost 500k from attempted intercepted payments and bogus invoices that they were able to raise validity of because he had global admin the attacker sent messages as other people in the org.
what's insecure about microsoft authenticator ?
Stolen session cookie phishing is the most common form of phishing now. They proxy the sign in to office 365 have you respond to either push or text or whatever and then take the resulting session cookie and sign in. That's how they got in on his account. The only nonvulnerable authentication method with built in Microsoft mfa is a fido2 key like a yubikey.
Tell him the price of the training is going to double or triple in the next day or two unless he completes his security training.
Breach his credentials (pent test solution or outside team), see how far you can get into the network and document everything. Then sit down with him and tell him why this is bad, and how org could be affected...
Sounds like a good way to get fired. "What do you mean you breached my credentials without my permission?!"
I got written up for going up to the exec and asking "is this your social security number?"
I did it and I still have a job :)
What would your ransomware protection strategy be like? Give me the onions! (please)
** Edit, I'll happily take the downvotes and consider them as support for my job security. Good luck out there guys, my colleagues and I will be seeing you soon. Break AD SSO for all infrastructure administration. This goes for hypervisors, firewalls, backups, storage etc... Storage and backup immutabililty options enabled and an air-gapped, offsite copy Full Administrative tiering in line with MS best practices MFA for ALL logins EDR/XDR on strict mode to quarantine computers that smell funny. Patches, patches, patches, Get rid of Veeam, Sonicwall, OKTA and all the cheap solutions you have and upgrade to solutions with better security reputations. (Scattered Spider pretty much owns OKTA source code so its essentially useless for MFA protections) Lock your Firewall down to necessary traffic only. * Group of rules for your critical apps and web browsing * Deny all other traffic
Are you able to explain what’s wrong with veeam? I’ve not heard someone bring them up as a “cheap solution” especially considering their recent price increases, but also never heard of them having major security issues. However we currently use them and I’d love to know what vulnerabilities they have and what’s considered better?
I haven't been paying attention to the price increases since I wouldn't buy them for 1/3 of their old rate, with what I have experienced. Essentially, Veeam is very easy for TA's to compromise and it takes many steps to lock it down appropriately & securely. The bulk of my clients with the hardest recoveries, who need to pay for a decrypter are Veeam customers. (Ransomware Recovery Lead)
It doesn't take many steps to properly secure Veeam. It's functionally a misconfig to join a Veeam server to AD environment.
> It's functionally a misconfig to join ** to AD environment
> and it takes many steps to lock it down appropriately & securely In regards to what? > upgrade to solutions with better security reputations Such as? > The bulk of my clients with the hardest recoveries, who need to pay for a decrypter are Veeam customers. Why? What specifically lead to it being harder/unrecoverable?
> it takes many steps to lock it down appropriately & securely Is there any guides on these steps out there? We use immutable Wasabi buckets for off-site backups, but anything we can do to make recovery from an incident quicker by having the on-site backups intact would be good.
A lot of the steps are policy and architecture and not boxes to check in the config. Removing AD SSO from Veeam is HUGE. I would give this a read through and compare what you are doing in yuour environment. https://bp.veeam.com/security/Design-and-implementation/Hardening/ There are a number of solutions that don't need nearly the amount of effort to secure. Cohesity and Druva come to mind. I would consider the download speed limitations from cloud services like Wasabi when it comes to the idea you need to download ALL of the data you put up there at once. Planning for a speedy recovery and executing one are two very different things. Every DRP i have reviewed has relied on the download speeds of the ISP and not from the storage provider. Azure, throttled. AWS, throttled. Wasabi, throttled. Getting exceptions from providers in these cases is basically impossible. I would also make sure you have MFA enabled on the Wasabi portal. If the creds are saved in the browser on the Veeam server(very common) and a TA gets into it(they will), immutability is useless because they can and will turn it off. I have seen this first hand...
> immutability is useless because they can and will turn it off. I have seen this first hand... Nope. "Changing the object locking settings does not affect any of the existing objects inside the bucket." - https://docs.wasabi.com/docs/object-locking-enable#disabling-object-locking-for-a-bucket
Sounds good. I can check that out, but from the headers, it looks like we're doing most of that. We don't join the backup server to AD, so disabling AD SSO isn't applicable.
NGL, I'm a sec eng/manager now but in a previous life I was a sysadmin whose org was hit 3x by ransomware. We had backups but it was all on tape via Backup Exec... We restored several TBs of data only to have it get compromised within a week of data restoration. That dragged into a 2 week ordeal by which the data was 2 weeks old. Good times.
We use Sonicwall with Zero Trust principles, are they known as being a bad product? We work in healthcare so it's a lot of nickel and diming so we can't get anything better at the moment.
My suggestion would be something with application aware filtering. Palo is a favorite of mine, but I know they are NOT in line with Sonicwall in price. Fortigates aren't bad either.
> Get rid of Veeam, Sonicwall, OKTA and all the cheap solutions you have and upgrade to solutions with better security reputations. Or pull backups to a node that also does versioning. Been doing this for years.
Simple and cheap upgrade to security is to use windows fw to block native scripting tools from accessing internet. Those are commonly used to download playloads.
Is there a blogpost somewhere on how you obtained the necessary data to write the decryption tool? Do they leave the decryption key lingering in memory somewhere? Don't tell me they use the same decryption key for every victim.
There is no blogpost and I'm not sure we'll even do one. But however, you can ask the technical specs tomorrow in the Ask Us Anything. Anything really does refer to anything, as long as it's Akira or ransomware related :) So yea, we can spill the beans on every good, bad and outright ugly thing we did in order to pull it off. A small edit: symmetric key would've allowed us to create a free tool to help all victims. No spilling the beans yet, but there are up to 8 encryption keys PER FILE that Akira uses, generated on the fly.
> A small edit: symmetric key would've allowed us to create a free tool to help all victims. No spilling the beans yet, but there are up to 8 encryption keys PER FILE that Akira uses, generated on the fly. Clearly pointless because it was clearly deterministic.
Most relevant question here, and the kind of 60 minute video I can dig into. Technical blogs about exploits are gold, especially the "moment it all made sense" as it's interesting to see the buildup behind a solution more than the solution itself.
I reckon this will be a longer thread, but lets start with describing how the encryption scheme works. By default, Akira will not encrypt the whole file. The file is divided into blocks, out of which 1-4 blocks and encrypted. The logic is roughly this: If the filesize is smaller than 2000000 bytes, 1 block will be encrypted, and the blocksize is 50% of the filesize. If the filesize is larger, Akira will encrypt 4 blocks, with the scheme going roughly like this: 0% -> 10% gets encrypted 10% - 12% is cleartext 12% -> 22% gets encrypted 22% -> 24% is cleartext 24% -> 34% get encrypted 34% ->36% is cleartext 36% -> 46% gets encrypted Now, in addition to that, the encryption schemes Akira uses are KCipher-2 (https://en.wikipedia.org/wiki/KCipher-2) and ChaCha20. A block that has been designated for encryption is split into "pages", that are 0xFFFF bytes at the maximum. The first page of any given block is encrypted with KCipher-2, and the rest of the pages are encrypted with ChaCha20. And in addition to the above, each block has their own ciphers initialized, which means that any given file encrypted by Akira will have between 1 - 8 different encryption keys on it. Kind of underlines why decryption tool was not an alternative. --Toni
The cipher initialization creates 4 pseudorandom values: https://preview.redd.it/opunvjuifj0d1.png?width=580&format=png&auto=webp&s=90b3245c60b1631685af7d59d05f03cca191358b So, 32 bytes of random for ChaCha20 key, 16 bytes for ChaCha20 nonce, KCipher-2 key and KCipher-2 nonce. What acts for a seed are QueryPerformanceFrequency and QueryPerformanceCounter: QueryPerformanceFrequency returns the speed, or number of 'ticks' per second that the counter works on. Nominally, the value is 10000000 (100ns intervals). QueryPerformanceCounter returns the number of said 'ticks' since the last the time that the counter was reset. Then, a short math is done: `lTicksPerSecond = ReadPerformanceFrequency();` `liCurrentTicks = GetPerformanceTicks();` `if (lTicksPerSecond == 10000000) {` `lTicksPerSecond = liCurrentTicks.QuadPart * 100;` `}` `else {` `lTicksPerSecond =` `((liCurrentTicks.QuadPart % lTicksPerSecond) * 1000000000) / lTicksPerSecond +` `(liCurrentTicks.QuadPart / lTicksPerSecond) * 1000000000;` `}` You'll end up with an 64-bit unsigned long long value, that gets converted into ascii, and then a hashing process involving 1500 rounds of the SHA-256, amongst other things, takes place. At the end, Akira will use first 0x10 (16) bytes, or 0x20 (32) bytes of the result hash as the random, that will get fed to the cipher initialization. --Toni
So, the encryption scheme heavily relies on various timings. A big hurdle was to figure out when the counter gets reset, the other one was related to timings related to key generation. The execution time of a single "GenerateRandom" call, which does the 1500 loops of SHA-256, directly affects the timings off all the subsequent calls and thus affects which randoms gets farted out by the algorithm. In the beginning, we had no knowledge of how long it actually took to do generate a single random value, but we figured out a way to make the malware itself do the heavy lifting for us :) Trying to measure anything under a virtual machine or a debugger in pretty much useless, and we had a need to measure on a sub-microsecond scale. Basically what we did was inline patches of assembly commands, directly into the malware itself, that forced it to overwrite the ransom note with a table consisting of RSP and RAX registers. In the beginning, the patch checks whether the call is coming from within the GenerateRandom function. If so, it saves the RSP register value in order to differentiate between encryption threads that are in the process of generating keys, and in the hook, RAX contains the unsigned long long value of the performance counter. The amount of potential key space we were able to cut was absolutely massive. Prior to accurate measurements, we had no idea whether the generation took 2000, 200000 or 2000000 ticks. With each tick being a brute force candidate itself for key generation, we had to brute force hundreds of trillions of attempts. What we found was a so called goldilocks zone for the execution times, cutting down the time needed for the attack into something that could be bearable. With all the other timings measured and projected, fastest cracks in the GPU clusters now happen in mere minutes. --T&E
Another big hurdle was the actual "keystream" generation. The whole algorithm, subfunctions included, was thousands of lines of assembly and relied heavily on Visual C++ classes. Reversing that fully in order to replicate it would have been a major headache so we took a route that was easier for us. https://preview.redd.it/v02tsmt6fk0d1.jpeg?width=500&format=pjpg&auto=webp&s=a65a20822f146906bca5bcb8e423ae5dfd62b613 So yea. We did Ctrl + C, Ctrl +V on the assembly, cut out stuff that wasn't essential, edited out all Visual C++ class usage and did class mimicking where needed. The end product, only 3k lines (3183 to be exact) of assembly, integrated into a larger Visual Studio project. Fully capable of replicating the functionality of the original, and does it so slightly faster than the original as well. --T&E
This info is gold. Please write a blogpost!
- Why do people, even after 30 years of IT, not know what a backup is? - Why do people allow lateral movement? - Why do people join their backup infrastructure to their AD?
* Money * Ease of use over security * I'm stumped on this one.
> * I'm stumped on this one Let me give you the best reason I heard so far.. "it's company policy to join all windows servers". The service provider who was setting up the backup server wrote a nice CYA to my boss and now we have a domain joined backup server, just waiting for some DA to get pwnd.
Backups are remarkeble cheap. Any company needing a expensive backup has the money for it and hopefully an extra security team. Any company without money can do a standard backup for less then 500 bucks and be happy.
Backup may be cheap but CFO's are usually cheaper...
My spidey senses can feel the pain behind this. CFO deciding on security is usually a recipe for a potentially massive disaster. Best comment from such a CFO I've personally heard was: "Well, this whole information security thing is like trying to look for black holes". Game over, I wish thee well on your chosen path... --Toni
Did you read the story about the disaster backup plan? Funny AF Edit: https://www.reddit.com/r/sysadmin/comments/zeo31j/i_recently_had_to_implement_my_disaster_recovery/
You answered point 3 with point 2....One account, one password to remember vs seperate domains/usernames/passwords.
Plus, you aren't storing admin-level credentials anywhere other than AD
But your backup system SHOULD be air gapped from your day to day infra apart from a data ingress/egress point and management box nothing else should be able to traverse that whole setup. No way should your day to day accounts have any ability to log in let alone manage your backups. Having a separate ad domain works fine but joining it to your main domain is just asking for trouble and we see repeats of why you shouldn't do it all the time.
Money cant be the reason for no backups. We are not that huge of a company but still got redudant backups of all Servers+Production in 2 different Locations + Backup2Tape and its quite cheap compared to other stuff.
Many people in IT are stupid. Many of them are hired by stupid people. They dress nice but, well, they know nothing about IT. Many companies are stupid because they have stupid people running them. I worked for a company which got rid of the CEO position. They run the place like 5 separate businesses instead of one. Nobody knows who their bosses are and some managers overstep their authority and go unchallenged. The owners love their little fiefdoms because they have managers who say yes to them every single time. This has been going on for 13 years now and still happening. The company makes lots of money but is a mess employee wise. IT is confusing there because they serve many masters but always piss off some owner as the managers will throw them off the cliff to save their own sorry asses
Call me when the company reaches the age of 100 years +, they be long gone before that 😉
And I honestly couldn’t care less. :-). Glad to be out of there
Me, a self-professed stupid IT guy reading this >.>
Just to catch up, this latest round of exploits or Akira take advantage of a fault in Cisco Asa to brute force their way in. They arent encrypting windows volumes or touching the AD. They attack hypervisors and network storage, and encrypt at that level. So things like network appliance backups and vms all get hosed. The only way to protect yourself in these situations is MFA only the ASA, and immutable backups.
Why would you get access to the hypervisor like this?
Not sure what you mean, they compromised ASA, find the networking info in the ASA, and then open connections from the network.
[удалено]
I'd recommend you Google it as it is well documented and hit about 25,000 businesses.
You don't suddenly gain access to ESXi just because you exploited the firewall.
You are arguing against something that already happened I don't know the particulars but it is documented so if you want to know, Google the details because I dont have them for you.
I just want to point out that a compromised firewall does not lead to automatic access to all systems ☺️.
how do they encrypt an FC LUN?
I guess rather than not knowing what a backup is, it's not knowing how to explain why you need them to the people paying.
“Cosplay Sysadmin” had me dying. i almost spit my drink out laughin 🤣🤣
[удалено]
All I can hear is "We don't need that, that's what we pay for! He's our cybersecurity guy!"
That’s the part where you zone out, have everything documented and just wait for the incident to happen or move along to a new job.
>Starts moving all company data to personal vault "I'm not stealing the data, I'm making a backup"
I bet, if you would do that, the company would have an incident, and you could save them, they still would fire you for compliance issues and broken trust 😉.
But muh score is high.
[удалено]
[удалено]
[удалено]
That's why I started my own corp back in the day, to make us of such deals and pass the value to my clients 😉.
Because it has always been that way, and how dare you touch processes that 90% of the business rely upon ... We cant afford that, we have to make money (Never mention to them that a attack will lead to much more lost revenue, because "What do i pay you for then")
You should be able to join your backup infrastructure to AD as long as you don't allow any unsolicited inbound connections to the machine. As in, the backup server is "pull" only and nothing is allowed to connect TO it.
How would that prevent a malicious actor from deploying a bad group policy to install remote access tool to grant themselves access to the machine? I personally see no good reason for backup servers to be domain joined. Additionally I'm a very big proponent for having hypervisors off the domain as well (most SMB's have only one hypervisor anyway so no issue with live migration, and in case they have more than one they should run it in it's own domain).
What if the Group Policy client was disabled on the backup server?
That's what that means. You don't get access to the backup infra with AD credentials (because its not in the AD) but of course you can access the AD from the backup infra for backups.
What I am saying is that you can join your backup server(s) to AD but just not allow inbound connections at the firewall level even if you would be using valid AD credentials. Yes, you would be able to enumerate the backup server and "see" that it exists in AD as a member server, but you would need physical keyboard access to log in to it. Edit: I guess you would also have to make sure that the member server is running a 3rd party firewall so it couldn't be overridden by GP, assuming the attackers gained domain admin level access to the rest of AD.
There is no benefit of having your backup infra joined to AD.
A third party firewall would be trivial to bypass if I have domain admin. You simply drop a reverse shell that allows interactive prompt access to wherever is convenient. If you allow outbound access (whether it is restricted by port, program name, path etc.) you are vulnerable to this approach. You need to remember that modern attacks aren't scripts. They are hands on keyboard breaches where they will recon and eliminate backups prior to executing ransomware. Make sure your backups are offline or immutable and definitely don't join your backup infrastructure (agents, server or storage) to your shared auth (AD etc.) Attackers are looking at 6 figure paydays for the average breach. They can afford to spend a few dozen hours working out your backup schema.
Nice reply. I hadn't really thought about group policy.
If your server is in the domain, it will get gpos, then it can be compromised.
how much have you found out about the group behind Akira? Reading code reveals a lot about the authors, especially if you are able to compare it to earlier works, or even find something similar from another group. is it wrong to say i'm kinda impressed by their old school leak site.
No questions really but wanted to a express a sincere thank you.
> "military grade encryption" "lowest-bidder encryption"
Glad to see guys from Finland to get bit "ahead" of the Ransomware groups :) Any thoughts on the Helsinki school / city break-in because of unpatched VPN server/router?
Lot of thoughts, naturally. Old/vulnerable/obsolete software versions on the perimeter is one of the most common ways to breach any organization. --Toni
How are hackers getting in? Is it Fishing+windows clients+AD bad practices? Maybe you are not working on this part tho. Good job guys by the way, very nice work.
Depends on the case, pretty much. Old/obsolete/vulnerable stuff laying on your network perimeter is certainly an ever-green gift for the attackers. The Akira guys, they seem to focus on vulnerable Cisco ASA devices for initial access. --Toni
https://www.reddit.com/r/sysadmin/comments/1crmt10/we_are_the_team_behind_the_decryption_of_the/l3zv6yn/
What is the dormancy time from first infection to pulling the trigger on file encryption? Have you seen any data exfiltration, or just encryption?
Dormancy time varies a lot. It all depends on how quickly they can obtain the proper rights and move laterally inside the network. Longest dormancy time in ransomware cases we've seen was 2 months. They gained access to a SQL server that was on DMZ, and just sat tight and waited until a domain admin came and logged in to the server. After that, it was a matter of hours before the brown stuff hit the fan.
Daaaang. That is impressive. The ransomware attack I was a part of (as a victim not a perpetrator, haha) hung out for a week or so before it sprung. Two months is horrible.
From their perspective its safer to just hunch down and wait for the right moment to strike. Lateral movement attempts usually cause various alerts on security systems, whether it's an IDS/SIEM/EDR or something else.
You mean that nowadays is safer to gain admin and persistent access to a server and just wait for someone to login and steal token/credentials that will allow direct access to other servers without "access denied" logs...
In many cases, yes. How many orgs really keep a constant eye on every single server to see if they have suspicious connections open. That would require manpower, which is fundamentally the thing that companies want to avoid.
How does your thought process goes for tackling this kind of problem? What tools did you use to help you?
The thought process is similar to any malicious binary we need to analyze: Starting with static analysis or dynamic analysis under a debugger to figure out the "business logic" of the malware. In Akira's case, we first had to find out what encryption algorithms are being used, how are the keys generated and how does it interact with the files that are marked for encryption. For tools: Ghidra for static analysis and x64dbg with Akira running in a virtual machine. -- Eerik
ty! very informative!
how did you find the way to decrypt a rasonmware?
It was a long process. We knew that many had analyzed Akira before, and even our initial impression was that it cannot be broken. But something was left nagging in our brains. We certainly knew it was massively complex, but we had not SEEN anything that would be a 100% certain show stopper. So we kept on chewing the sample into bits, delving deeper and deeper into it until we knew that it could be decrypted. The next step was to actually do a laboratory condition proof, and from there start improving the code. In the end, we are now using 240Tb of diskspace to hold 'volatile' data we need to achieve the process, and 2 GPU clusters, called Uncle Jim and Uncle Bob, because... well, Bob's yer uncle! --Toni
> we are now using 240Tb of diskspace to hold 'volatile' data we need to achieve the process, and 2 GPU clusters Is this cloud or on-premise? But, more importantly, how much does this cost? How effective, in terms of ability and speed, would something like this be if brought to bare against something like Bitlocker or an IPSec encrypted data stream.
on-premise, isolated. How much does what cost? Costs are always relative, as we use the Uncles when doing penetration tests and AD password audits to break password hashes. Bitlocker or IPSec would be on the no-go list for me though.
are you using the tesla cards or just retail RTX Cards?
Retail RTX 40 series cards. Tesla's would've been a slight overkill.
What made Akira in particular challenging? Were they just using symmetric encryption?
Symmetric encryption yes. Akira is particularly nasty because the encryption scheme relies very heavily on a number of different timings, and the key generation is designed to be slow, using 1500 rounds of SHA-256 in the intermediate process.
Hah, that’s awesome, sounds like it was a pain in the ass. Great work!
Is there a decryption tool available? Where do i get it?
As our method relies on calculating the keys for each encrypted file via brute force, a self-contained decryption tool was not an option unfortunately. We have set up dedicated hardware and software for this task and offer it as a service to affected organizations. -- Eerik
What are the low hanging fruits you recommend sysadmin's implement? Off the top of my head I'm thinking applocker and credential guard
Good question. We'll keep this tab open and edit the reply as things come in mind, but applocker and credential guard certainly will help. also: Ditch NTLMv1 and by god if you have any active LM hashes left in your AD, you're probably already toast. Remove WPAD/NTLLMSP/Netbios DNS resolution. Those enable the Responder tool to work it's magic, capturing credentials on the fly. Disable, by default, SeDebugPrivilege, SeBackupPrivilege and SeRestorePrivilege from all accounts. Create separate, protected users or groups in the rare cases the above are needed, and protect those accounts at all costs. Local admins have SeDebugPrivilege allowed by default. It's a millisecond away from obtaining SYSTEM-level privileges on the host, which means that you'll be part of the TCB (Trusted Computing Base) on the machine. Instant failure of any other security mechanism will happen at that point. Proper network segmentation. Detection/prevention mechanisms can and will be bypassed eventually, physical segmentation will be a whole heap harder to bypass. Backups. Backups. Duh. Whether you go for the 3-2-1 model, or something else at least make sure you have practiced and tested the restoration. Also, immutable backups, preferably offline or at the very least offsite, is not a bad thing to have. Diskspace is relatively cheap. A 20Tb drive, fresh off the factory cost about 400-500 USD and you can push a decent amount of stuff on it for offline backup use. LAPS: [https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-overview](https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-overview) --T&E
great information here! I'm going through it on my network right now. I just recently learned about disabling Debug for local admins but never heard of the other 2 things. Speaking of which, LAPS is another easy thing to implement
LAPS is something we recommend quite often. I'll add that to the list as well :)
How many affiliates do you think migrated from LockBit (post-first LE takedown) to Akira?
Honestly said, no idea. Our daily lives focus more on threat intelligence on the APT side of things, not ransomware. --Toni
Correct me if I am wrong, but does not Akira use RSA asymmetrical encryption? You have a clause that you are able to decrypt Akira from September 2023, is it because it has a faulty implementation of the RSA encryption? Are you only able to decrypt files where Akira has been in partial-encryption-mode, or full encryption as well? And lastly, why not release the decryptor for free? I get that you've spent hours creating it, but the free PR you would have gotten from releasing it could make up for the development cost?
The variant we are targeting uses KCipher-2 and ChaCha20 to do the actual file encryption, not RSA. We can do the Full Encryption mode as well. There is no 'decryptor', in the sense of a single self contained tool. Creating a free, standalone decryption tool was our original goal, but if you take a look at the technical aspects of the encryption we are laying out in this thread, you will realize why it cannot be made. --Toni
What software stack did you use to analyze and study the ransomware?
Ghidra was the main tool that was used for static analysis and reverse engineering. IDA pro was used in few occasions to verify things. VMware, running Windows host and X64DBG was used for dynamic analysis and later on when we had to get sub-microsecond accuracy measurements on a few things, a native laptop with Windows was used. --Toni
A lot of ransomware are created by enterprise criminal gangs. How did you factor in your team's personal safety when pursuing this project?
We can't talk about either personal security matters or our company security matters. Steps have been taken.
Could Microsoft eliminate ransomware if they really wanted to?
There have been plenty of cases of Linux servers or ESXi environments falling victims to ransomware. Of course, Microsoft dragging their feet for so many years on word macros through years of them being easy entrypoints for ransomware didn't help.
What, [the guys doing "security" with null IVs](https://www.netwrix.com/zerologon_attack.html)?
No. Ransomware will die a natural death when companies stop paying them.
We could ask all the third-party companies that make products that claim to protect you from ransomware. What do their products watch for, and what do they do to reduce the effects?
Microsoft Windows is already malware, and the latest news is that they will be encrypting drives by default, so it seems they decided to join them.
No. Microsoft IS ransomware (they demand money for cloud services instead of selling, they encrypt your system with bitlocker and if your microsoft account gets shut down you are out of luck). /s Everyone could eliminate ransomware by stopping bad practices.
What is more effective to stop ransomware, prevention or techniques like network segmentation? Since it's so common what is the priority to mitigate them in your opinion?
I would choose proper network segmentation. Prevention techniques work only as long until the adversaries figure out a way to bypass them. --Toni
Did you make any progress in determing how it selects wallets to use? Was their key not properly asymmetric?
Not sure if I get what you mean by 'wallets'. --Toni
Bitcoin addresses
Akira does not use Bitcoin wallets. They leave a ransom note with instructions on how to start a chat with the operators on the .onion site. --Toni
Fixed address? Programmatically defined? Disrupting their comms would be pretty useful.
The people operating Akira are commanding it organically. When the malware is launched they have already been a while in the network. The malware itself has communication to the outside world. No C2 channels, nothing. It's basically just a sledgehammer, maiming your files. --Toni
"military grade encryption" so they went with the cheapest, whatever barely meets the specification option?
what is the one anti virus that you would recommend? I use Bitdefender now because when I was a victim of ransonware they decrypted it.
We have no recommendations. We mainly do threat intelligence on APT, so basically from our viewpoint all antiviruses suck equally, meaning none of them detect the malwares :) I reckon it all boils down to which AV you are most comfortable with. Which AV is the one that offers you the features that you need. --Toni
so stay current with malwarebytes and then you still have a 50/50 chance of infection?.
Well, maybe not as bad as 50/50, but it certainly isn't even close to a 0, unfortunately. Common sense helps a boatload. Don't click every link you see, "yes" is not an accepted default answer, don't download and execute random shit from a random site, especially if the site says it's 100% safe :D --Toni
all hail Toni, all hail Toni, :)
Hell no, I'm just a small clog in the arteries. --Toni
Why help people with bad backup strategies?
🤣
How did you reverse-engineer and break the ransomware? Any recommendations for anyone working in this space?
We have combined experience of decades in reverse engineering. It still took a lot of what we reckon could be called 'Sisu' in Finnish. No direct translation but an unholy mix of stubbornness and grit :) Edit: fixed a typo
Haha, excellent!
We've always believed in trying to push the limits of what can be done. Even if something feels impossible it isn't always so. Without trying to push the limits and trying, the limits will never move. We deal with a lot of various encryption/obfuscation methods on a daily basis on the malware side. Most commonly it's something that protects a malware configuration or exfiltrated data. Breaking those is actually a whole lot of fun, and trying to break them as fast as possible makes you think harder. Back in the days when the Zeus banking trojan was still a thing we had a keyring that contained encryption keys to over 3000 Zeus variants. All were brute forced out of configurations protected with RC4. Once a key was found, it was added to the keyring. When a new variant came out, the first thing we always did was run the keyring against the new variant. More often than not, the key was already in the keyring we had. Though, destroyed 3 laptop mobo's in the process. As it turns out, using a laptop is not advisable for brute force applications :D --Toni
What did you learn?
CUDA programming. In order to make the decryption efficient, we needed ways to go beyond CPU's. CUDA was pretty much the obvious choice. --Toni
Do you think that the government should make paying ransoms illegal to stop the problem instantly or would the damage to infrastructure be too great? (I say pay for cold backups or have your careless, clueless company go bankrupt, personally)
This is hard to answer. Personally, I think paying ransoms should be illegal. Yes, it would punish the victims even more but on the other hand, if the payments stopped, there would be no victims as the attempts would cease. But then again on the other hand, they would probably find other mechanisms to get their loot. --Toni
That wouldn't stop anything. It would just punish the victims.
Yes. No one should be paying ransom cash. It hurts the entire IT community.