[HN Gopher] Akira ransomware can be cracked with sixteen RTX 409...
       ___________________________________________________________________
        
       Akira ransomware can be cracked with sixteen RTX 4090 GPUs in
       around ten hours
        
       Author : Ozarkian
       Score  : 126 points
       Date   : 2025-03-17 11:06 UTC (11 hours ago)
        
 (HTM) web link (www.tomshardware.com)
 (TXT) w3m dump (www.tomshardware.com)
        
       | wkat4242 wrote:
       | Interesting. I thought crypto lockers were kinda extinct though
       | because most companies have their backup ducks in a row now so
       | threat actors tend to go for blackmail of data exposure now.
       | 
       | Also, most XDRs detect this behaviour really well now.
        
         | ziddoap wrote:
         | > _because most companies have their backup ducks in a row_
         | 
         | That is the most optimistic thing I've read in a long time!
         | 
         | I still consult with companies storing all of the company-owned
         | accounts (facebook, instagram, website admin, government & tax
         | portals, etc.) in a spreadsheet called "passwords.xlsx", in a
         | folder called "passwords", on the root of the network with no
         | access control. Frequently.
         | 
         | (they do not have their backup ducks in a row, nor have any
         | clue what "XDR" stands for)
        
           | wkat4242 wrote:
           | Really? We really don't do that anymore. We have a strong XDR
           | (Extended Detection and Response), basically Antivirus +
           | behavioural analysis + SIEM integration. A managed password
           | manager, and even detection for such behaviour of stored
           | passwords in plain text or office files (through Microsoft
           | Purview DLP). XDR is an evolution of EDR (Endpoint Detection
           | and Response) with a bit more in terms of data sources added
           | (and a lot of marketing "Our <..>DR is better than yours
           | because we have a cooler letter" :P
           | 
           | Basically an XDR looks not only at malware but also at
           | potentially malicious actions. This is a much more complete
           | view because not every malicious action is triggered by
           | malware. It can also be simply a user (and AI
           | automation/control will be a new thing there). Big names in
           | this are Crowdstrike (yes that one that killed half the
           | enterprises), SentinelOne, Microsoft Defender for Endpoint
           | (not to be confused with the normal consumer defender). An
           | XDR will notice when a PC is doing a port scan, when a
           | process is trying to gain root rights, when significant
           | numbers of files are suddenly rewritten. It will immediately
           | kill the process and/or trigger a ticket to the SOC (Security
           | Operations Center). Who can take global actions on all
           | endpoints to immediately kill the malware everywhere. It's
           | pretty cool, you can trace back the entire process history,
           | what launched what, what was were the system call parameters
           | etc.
           | 
           | Big companies really have this stuff figured out.
           | Unfortunately exfiltration is harder to detect if the
           | malicious actor is doing it through a cloud service that the
           | company also subscribes to.
           | 
           | If a company doesn't know what XDR is they are probably < 100
           | employees.
        
             | ziddoap wrote:
             | > _If a company doesn 't know what XDR is they are probably
             | < 100 employees._
             | 
             | Indeed, I do cybersec consulting primarily for small to
             | medium-sized businesses.
             | 
             | And I would say, especially for small businesses, somewhere
             | over half of them have no backup plan (among all the other
             | issues). So, sadly, it is far from true that "most
             | companies have their backup ducks in a row" .
        
               | wkat4242 wrote:
               | True, I was mainly thinking about the enterprise field in
               | which I work.
               | 
               | Of course those are also the fattest targets for these
               | actors. We get some really serious stuff very regularly.
               | Which I can't elaborate on, but I mean, the threat model
               | for a small / medium business is also much less heavy.
               | 
               | Also, most enterprises have cybersecurity insurance that
               | will just pay out (and thus keep this activity going,
               | sadly). I don't think smaller businesses would have that.
        
               | technion wrote:
               | My time consulting across random organisations really has
               | been the complete exact opposite of what you describe.
               | 
               | I've walked into billion dollar orgs and campaigned
               | unsuccessfully for backups. And I have seen sole traders
               | with cyber insurance.
        
             | MadsRC wrote:
             | Data exfil detection is a game of whack-a-mole. There is an
             | endless variation of ways I can get data of your machine or
             | out of your network.
             | 
             | Your time is much better spend detecting or preventing
             | compromise.
        
               | wkat4242 wrote:
               | Yes, but for a company our size, to have something
               | notable exfiltrated you are usually speaking about large
               | volumes as well, which are easier to detect.
               | 
               | And yes compromise detection is of course the priority.
               | But it's not just one or the other. We do everything at
               | the same time. The swiss cheese model and all that.
        
               | recursive wrote:
               | Whatever your company size is, there are many other
               | company sizes that exist.
        
             | regularfry wrote:
             | > most companies have their backup ducks in a row now
             | 
             | > If a company doesn't know what XDR is they are probably <
             | 100 employees.
             | 
             | To say that "most companies are < 100 employees" would be
             | to understate the margin by which that is true. According
             | to https://www.naics.com/business-lists/counts-by-company-
             | size/, there are 17,769,699 companies total in the US, of
             | which 166,964 are > 100 employees (leaving the unknowns to
             | one side). That's less than 1%.
        
               | CPLX wrote:
               | Right but half of all people employed in the US work for
               | companies with 100+ employees.
        
               | ziddoap wrote:
               | I would not expect anyone who says "most businesses" in a
               | sentence to be using the definition "the minority of
               | businesses that most people work for".
        
         | dylan604 wrote:
         | The hack is essentially free for the attackers. All it takes is
         | one ransom to be paid to make it worth their time. Every one
         | after that is just bonus.
        
           | wongarsu wrote:
           | The hackers still have opportunity cost. Also the support
           | costs (communicating with victims who may or may not pay),
           | paying for payload delivery (either explicitly by letting
           | someone else do it, or by putting in hours to do it
           | themselves), server costs, the ransomware software itself
           | might be bought or acquired in a SaaS or affiliate model.
           | 
           | Just because it's crime doesn't mean it's free money
        
         | bongodongobob wrote:
         | I would venture to say that most companies actually don't have
         | a backup solution at all. The other half is mixed between just
         | scheduled copies to a NAS and/or do not do regular back up
         | tests. Source: years of contracting for small-medium sized
         | business.
        
       | pc86 wrote:
       | Can someone smarter than me clarify if this also means a single
       | 4090 can crack it in about 160 hours? Or are there a lot of other
       | efficiencies gained by adding multiple GPUs together?
        
         | ffhhj wrote:
         | Or 160 cards take 1 hour?
        
           | bayindirh wrote:
           | More like 2, probably. If you have the lanes, of course. =]
        
         | bayindirh wrote:
         | From my educated guess, A single 4090 can crack it around ~140,
         | since there will be some scaling losses. Also, this is an
         | optimistic take since we don't expect the VRAM won't have any
         | bit-flip events during this time, under load.
         | 
         | If you can have 10 Tesla cards, the number will be a bit
         | shorter (around 14, I guess), since NVLink is much more
         | efficient and creates a mesh between cards without hitting the
         | PCIe.
        
           | patates wrote:
           | Remembering the good old days when you could use it to
           | connect consumer cards...
        
             | rtkwe wrote:
             | The advantages from SLI were always well below doubling and
             | usually more like 50%. As frame rates and everything else
             | has gotten higher and more complex the overhead of SLI got
             | more and more onerous to the point where it barely gave
             | much of an advantage to support at all.
        
           | fwip wrote:
           | Doesn't have any scaling losses - it's a very parallel
           | problem. Divide the keyspace N ways, run N brute-force
           | searches. Similarly, it doesn't benefit from a faster
           | connection to other nodes or main memory.
           | 
           | Most bit-flips won't matter - either you get a false positive
           | which is ruled out trivially, or the 1-in-$SearchSpace chance
           | you get the false negative.
        
             | jerf wrote:
             | For education's sake and better internet search terms,
             | there's some terms for this, the most popular of which is
             | "embarassingly parallel":
             | https://en.wikipedia.org/wiki/Embarrassingly_parallel
             | 
             | And agreed; coordination costs are negligible next to the
             | cost of the calculation, so it should be effectively
             | linear, and dominated by the luck of the draw on when the
             | correct key is selected.
        
         | splix wrote:
         | Seems so. Article initially says that it takes ~7 days (168
         | hours) to decrypt on a single card, but later suggests to use
         | multiple.
        
         | speerer wrote:
         | Actually, the result that's being announced is exactly this
         | parallel property.From the article:
         | 
         | > "With an RTX 4090, the Tinyhack found they could crack the
         | encrypted ransomware'd files in seven days, and with 16 GPUs,
         | the process would take just over ten hours."
         | 
         | (and 160h [?] 7 days)
        
       | fbn79 wrote:
       | So... what is the estimated cost to find the key using AWS H100
       | or similar service?
        
         | Cycl0ps wrote:
         | Back of the napkin math:
         | 
         | Googling the TFlops as an estimate of power shows a roughly 12x
         | improvement on the H100 over the 4090. A single 4090 takes 160
         | hours so a single H100 should take about 13 hours.
         | 
         | AWS will rent a p5.48xlarge instance of 8xH100 for $31.464/hr.
         | That will take roughly two hours and cost around $60 bucks.
         | 
         | Assume I'm off by an order of magnitude, this is still a
         | reasonable cost to recover key infrastructure. If the
         | $60/endpoint stands then it would be reasonable to recover
         | workstations this way
        
           | dylan604 wrote:
           | Only for versions of encryption that was done before the
           | attackers update their encryption key. Not saying it's not a
           | win, but just a temporary one for hacks using this specific
           | version
           | 
           | But for anyone that is affected and refuses to pay a ransom,
           | this is a potential win for someone with the prowess to do
           | it. Then again, would someone with that prowess have gotten
           | attacked like this? chicken meets egg??
        
         | binarymax wrote:
         | On Lambda cloud, an 8x H100 is $14.32/hr. H100s are better than
         | 4090s, So if you count setup time it's probably about $100
        
       | autoexec wrote:
       | I'm sure they'll be updating the encryption to something more
       | difficult to crack instead of lowering the ransom demand to beat
       | cloud server prices. I'd rather pay more to a server farm and
       | wait days to get my data back than give any reward to the asshole
       | scammers who locked it away.
        
         | ourmandave wrote:
         | And its probably cheaper than buying a copy of your own data
         | off the dark web they dumped because you didn't pay.
        
           | swarnie wrote:
           | Getting it dumped online simply isn't an option depending on
           | the legislative region and industry.
        
       | treesknees wrote:
       | Posted 3 days ago https://news.ycombinator.com/item?id=43365083
        
       | adzm wrote:
       | Linked in the article, but the post describing the details is
       | here: https://tinyhack.com/2025/03/13/decrypting-encrypted-
       | files-f...
        
       | frollogaston wrote:
       | I always wondered if ransomware is making some compromises in
       | security so it can encrypt the disk so quickly and covertly.
        
       ___________________________________________________________________
       (page generated 2025-03-17 23:01 UTC)