AA22-187A: North Korean State-Sponsored Cyber Actors Use Maui Ransomware to Target the Healthcare and Public Health Sector

This post was originally published on this site

Original release date: July 6, 2022

Summary

The Federal Bureau of Investigation (FBI), Cybersecurity and Infrastructure Security Agency (CISA), and the Department of the Treasury (Treasury) are releasing this joint Cybersecurity Advisory (CSA) to provide information on Maui ransomware, which has been used by North Korean state-sponsored cyber actors since at least May 2021 to target Healthcare and Public Health (HPH) Sector organizations.

This joint CSA provides information—including tactics, techniques, and procedures (TTPs) and indicators of compromise (IOCs)—on Maui ransomware obtained from FBI incident response activities and industry analysis of a Maui sample. The FBI, CISA, and Treasury urge HPH Sector organizations as well as other critical infrastructure organizations to apply the recommendations in the Mitigations section of this CSA to reduce the likelihood of compromise from ransomware operations. Victims of Maui ransomware should report the incident to their local FBI field office or CISA. 

The FBI, CISA, and Treasury highly discourage paying ransoms as doing so does not guarantee files and records will be recovered and may pose sanctions risks. Note: in September 2021, Treasury issued an updated advisory highlighting the sanctions risks associated with ransomware payments and the proactive steps companies can take to mitigate such risks. Specifically, the updated advisory encourages U.S. entities to adopt and improve cybersecurity practices and report ransomware attacks to, and fully cooperate with, law enforcement. The updated advisory states that when affected parties take these proactive steps, Treasury’s Office of Foreign Assets Control (OFAC) would be more likely to resolve apparent sanctions violations involving ransomware attacks with a non-public enforcement response.

For more information on state-sponsored North Korean malicious cyber activity, see CISA’s North Korea Cyber Threat Overview and Advisories webpage. 

Download the PDF version of this report: pdf, 553 kb.

Technical Details

Since May 2021, the FBI has observed and responded to multiple Maui ransomware incidents at HPH Sector organizations. North Korean state-sponsored cyber actors used Maui ransomware in these incidents to encrypt servers responsible for healthcare services—including electronic health records services, diagnostics services, imaging services, and intranet services. In some cases, these incidents disrupted the services provided by the targeted HPH Sector organizations for prolonged periods. The initial access vector(s) for these incidents is unknown.

Maui Ransomware

Maui ransomware (maui.exe) is an encryption binary. According to industry analysis of a sample of Maui (SHA256: 5b7ecf7e9d0715f1122baf4ce745c5fcd769dee48150616753fec4d6da16e99e) provided in Stairwell Threat Report: Maui Ransomware—the ransomware appears to be designed for manual execution [TA0002] by a remote actor. The remote actor uses command-line interface [T1059.008] to interact with the malware and to identify files to encrypt. 

Maui uses a combination of Advanced Encryption Standard (AES), RSA, and XOR encryption to encrypt [T1486] target files:

  1. Maui encrypts target files with AES 128-bit encryption. Each encrypted file has a unique AES key, and each file contains a custom header with the file’s original path, allowing Maui to identify previously encrypted files. The header also contains encrypted copies of the AES key.
  2. Maui encrypts each AES key with RSA encryption.
    • Maui loads the RSA public (maui.key) and private (maui.evd) keys in the same directory as itself. 
  3. Maui encodes the RSA public key (maui.key) using XOR encryption. The XOR key is generated from hard drive information (.PhysicalDrive0).

During encryption, Maui creates a temporary file for each file it encrypts using GetTempFileNameW(). Maui uses the temporary to stage output from encryption. After encrypting files, Maui creates maui.log, which contains output from Maui execution. Actors likely exfiltrate [TA0010] maui.log and decrypt the file using associated decryption tools.

See Stairwell Threat Report: Maui Ransomware for additional information on Maui ransomware, including YARA rules and a key extractor.

Indicators of Compromise

See table 1 for Maui ransomware IOCs obtained from FBI incident response activities since May 2021. 
 

Table 1: Maui Ransomware IOCs

Indicator Type Value
Filename maui.exe
maui.log
maui.key
maui.evd
aui.exe
MD5 Hash 4118d9adce7350c3eedeb056a3335346
9b0e7c460a80f740d455a7521f0eada1
fda3a19afa85912f6dc8452675245d6
2d02f5499d35a8dffb4c8bc0b7fec5c2
c50b839f2fc3ce5a385b9ae1c05def3a
a452a5f693036320b580d28ee55ae2a3
a6e1efd70a077be032f052bb75544358
802e7d6e80d7a60e17f9ffbd62fcbbeb
SHA256 Hash 5b7ecf7e9d0715f1122baf4ce745c5fcd769dee48150616753fec4d6da16e99e
45d8ac1ac692d6bb0fe776620371fca02b60cac8db23c4cc7ab5df262da42b78
56925a1f7d853d814f80e98a1c4890b0a6a84c83a8eded34c585c98b2df6ab19
830207029d83fd46a4a89cd623103ba2321b866428aa04360376e6a390063570
458d258005f39d72ce47c111a7d17e8c52fe5fc7dd98575771640d9009385456
99b0056b7cc2e305d4ccb0ac0a8a270d3fceb21ef6fc2eb13521a930cea8bd9f
3b9fe1713f638f85f20ea56fd09d20a96cd6d288732b04b073248b56cdaef878
87bdb1de1dd6b0b75879d8b8aef80b562ec4fad365d7abbc629bcfc1d386afa6

 

Attribution to North Korean State-Sponsored Cyber Actors

The FBI assesses North Korean state-sponsored cyber actors have deployed Maui ransomware against Healthcare and Public Health Sector organizations. The North Korean state-sponsored cyber actors likely assume healthcare organizations are willing to pay ransoms because these organizations provide services that are critical to human life and health. Because of this assumption, the FBI, CISA, and Treasury assess North Korean state-sponsored actors are likely to continue targeting HPH Sector organizations. 

Mitigations

The FBI, CISA, and Treasury urge HPH Sector organizations to:

  • Limit access to data by deploying public key infrastructure and digital certificates to authenticate connections with the network, Internet of Things (IoT) medical devices, and the electronic health record system, as well as to ensure data packages are not manipulated while in transit from man-in-the-middle attacks. 
  • Use standard user accounts on internal systems instead of administrative accounts, which allow for overarching administrative system privileges and do not ensure least privilege.  
  • Turn off network device management interfaces such as Telnet, SSH, Winbox, and HTTP for wide area networks (WANs) and secure with strong passwords and encryption when enabled. 
  • Secure personal identifiable information (PII)/patient health information (PHI) at collection points and encrypt the data at rest and in transit by using technologies such as Transport Layer Security (TPS). Only store personal patient data on internal systems that are protected by firewalls, and ensure extensive backups are available if data is ever compromised. 
  • Protect stored data by masking the permanent account number (PAN) when it is displayed and rendering it unreadable when it is stored—through cryptography, for example. 
  • Secure the collection, storage, and processing practices for PII and PHI, per regulations such as the Health Insurance Portability and Accountability Act of 1996 (HIPAA). Implementing HIPAA security measures can prevent the introduction of malware on the system. 
  • Implement and enforce multi-layer network segmentation with the most critical communications and data resting on the most secure and reliable layer. 
  • Use monitoring tools to observe whether IoT devices are behaving erratically due to a compromise. 
  • Create and regularly review internal policies that regulate the collection, storage, access, and monitoring of PII/PHI.

In addition, the FBI, CISA, and Treasury urge all organizations, including HPH Sector organizations, to apply the following recommendations to prepare for, mitigate/prevent, and respond to ransomware incidents.

Preparing for Ransomware

  • Maintain offline (i.e., physically disconnected) backups of data, and regularly test backup and restoration. These practices safeguard an organization’s continuity of operations or at least minimize potential downtime from a ransomware incident and protect against data losses.
    • Ensure all backup data is encrypted, immutable (i.e., cannot be altered or deleted), and covers the entire organization’s data infrastructure. 
  • Create, maintain, and exercise a basic cyber incident response plan and associated communications plan that includes response procedures for a ransomware incident.

Mitigating and Preventing Ransomware

  • Install updates for operating systems, software, and firmware as soon as they are released. Timely patching is one of the most efficient and cost-effective steps an organization can take to minimize its exposure to cybersecurity threats. Regularly check for software updates and end-of-life notifications and prioritize patching known exploited vulnerabilities. Consider leveraging a centralized patch management system to automate and expedite the process.
  • If you use Remote Desktop Protocol (RDP), or other potentially risky services, secure and monitor them closely.
    • Limit access to resources over internal networks, especially by restricting RDP and using virtual desktop infrastructure. After assessing risks, if RDP is deemed operationally necessary, restrict the originating sources, and require multifactor authentication (MFA) to mitigate credential theft and reuse. If RDP must be available externally, use a virtual private network (VPN), virtual desktop infrastructure, or other means to authenticate and secure the connection before allowing RDP to connect to internal devices. Monitor remote access/RDP logs, enforce account lockouts after a specified number of attempts to block brute force campaigns, log RDP login attempts, and disable unused remote access/RDP ports.
    • Ensure devices are properly configured and that security features are enabled. Disable ports and protocols that are not being used for a business purpose (e.g., RDP Transmission Control Protocol Port 3389). 
    • Restrict Server Message Block (SMB) Protocol within the network to only access servers that are necessary and remove or disable outdated versions of SMB (i.e., SMB version 1). Threat actors use SMB to propagate malware across organizations.
    • Review the security posture of third-party vendors and those interconnected with your organization. Ensure all connections between third-party vendors and outside software or hardware are monitored and reviewed for suspicious activity.
    • Implement listing policies for applications and remote access that only allow systems to execute known and permitted programs under an established.
    • Open document readers in protected viewing modes to help prevent active content from running.
  • Implement user training program and phishing exercises to raise awareness among users about the risks of visiting suspicious websites, clicking on suspicious links, and opening suspicious attachments. Reinforce the appropriate user response to phishing and spearphishing emails. 
  • Require MFA for as many services as possible—particularly for webmail, VPNs, accounts that access critical systems, and privileged accounts that manage backups. 
  • Use strong passwords and avoid reusing passwords for multiple accounts. See CISA Tip Choosing and Protecting Passwords and National Institute of Standards and Technology (NIST) Special Publication 800-63B: Digital Identity Guidelines for more information.
  • Require administrator credentials to install software.
  • Audit user accounts with administrative or elevated privileges and configure access controls with least privilege in mind.
  • Install and regularly update antivirus and antimalware software on all hosts.
  • Only use secure networks and avoid using public Wi-Fi networks. Consider installing and using a VPN.
  • Consider adding an email banner to messages coming from outside your organizations.
  • Disable hyperlinks in received emails.

Responding to Ransomware Incidents

If a ransomware incident occurs at your organization:

  • Follow your organization’s Ransomware Response Checklist (see Preparing for Ransomware section). 
  • Scan backups. If possible, scan backup data with an antivirus program to check that it is free of malware. This should be performed using an isolated, trusted system to avoid exposing backups to potential compromise.
  • Follow the notification requirements as outlined in your cyber incident response plan. 
  • Report incidents to the FBI at a local FBI Field Office, CISA at us-cert.cisa.gov/report, or the U.S. Secret Service (USSS) at a USSS Field Office
  • Apply incident response best practices found in the joint Cybersecurity Advisory, Technical Approaches to Uncovering and Remediating Malicious Activity, developed by CISA and the cybersecurity authorities of Australia, Canada, New Zealand, and the United Kingdom.

Note: the FBI, CISA, and Treasury strongly discourage paying ransoms as doing so does not guarantee files and records will be recovered and may pose sanctions risks. 

Request for Information

The FBI is seeking any information that can be shared, to include boundary logs showing communication to and from foreign IP addresses, bitcoin wallet information, the decryptor file, and/or benign samples of encrypted files. As stated above, the FBI discourages paying ransoms. Payment does not guarantee files will be recovered and may embolden adversaries to target additional organizations, encourage other criminal actors to engage in the distribution of ransomware, and/or fund illicit activities. However, the FBI understands that when victims are faced with an inability to function, all options are evaluated to protect shareholders, employees, and customers. Regardless of whether you or your organization have decided to pay the ransom, the FBI, CISA, and Treasury urge you to promptly report ransomware incidents to the FBI at a local FBI Field Office, CISA at us-cert.cisa.gov/report, or the USSS at a USSS Field Office. Doing so provides the U.S. Government with critical information needed to prevent future attacks by identifying and tracking ransomware actors and holding them accountable under U.S. law.

Resources 

  • For more information and resources on protecting against and responding to ransomware, refer to StopRansomware.gov, a centralized, U.S. whole-of-government webpage providing ransomware resources and alerts.
  • CISA’s Ransomware Readiness Assessment is a no-cost self-assessment based on a tiered set of practices to help organizations better assess how well they are equipped to defend and recover from a ransomware incident.
  • A guide that helps organizations mitigate a ransomware attack and provides a Ransomware Response Checklists: CISA-Multi-State Information Sharing and Analysis Center (MS-ISAC) Joint Ransomware Guide.
  • The U.S. Department of State’s Rewards for Justice (RFJ) program offers a reward of up to $10 million for reports of foreign government malicious activity against U.S. critical infrastructure. See the RFJ website for more information and how to report information securely. 

Acknowledgements

The FBI, CISA, and Treasury would like to thank Stairwell for their contributions to this CSA. 

Contact Information

To report suspicious or criminal activity related to information found in this Joint Cybersecurity Advisory, contact your local FBI field office at fbi.gov/contact-us/field, or the FBI’s 24/7 Cyber Watch (CyWatch) at (855) 292-3937 or by e-mail at CyWatch@fbi.gov. When available, please include the following information regarding the incident: date, time, and location of the incident; type of activity; number of people affected; type of equipment used for the activity; the name of the submitting company or organization; and a designated point of contact. To request incident response resources or technical assistance related to these threats, contact CISA at report@cisa.gov

Revisions

  • July 6, 2022: Initial Version

This product is provided subject to this Notification and this Privacy & Use policy.

How Many SANs are Insane?, (Wed, Jul 6th)

This post was originally published on this site

x509 certificates, as they are used for TLS, can include multiple "Subject Alternative Names" (SANs) to be used with various websites. Experimenting with numerous ways to detect TLS anomalies, I looked at my Zeek x509 logs to summarize how many names are present in certificates.

My Zeek logs are stored in JSON format to make it easier to send them to Elasticsearch. But I also prefer the jq over the zeek native tool zeek-cut (personal preference).

I used this command line to summarize the logs:

zcat x509.log | jq '."san.dns" | length' | sort | uniq -c | sort -n

Based on this methodology, the maximum number of SANs per certificate is close to 500, but most are using 100 hostnames or less.

number of certificates with specific number of SANs

But the real question: What is normal?

It turns out there is no real "hard" limit. The RFCs leave it up to the implementation to define how many SANs to allow [1]. Different certificate authorities implement different limits:

Let's Encrypt [2] , GoDaddy[3]: 100
Comodo[4]: 1,000 (some older references appear to state 2,000 are allowed)

So, in short: it appears that 100 is "safe." For larger numbers, you may run into implementation-specific issues.

]1] https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.6
[2] https://letsencrypt.org/docs/rate-limits/
[3] https://www.godaddy.com/web-security/multi-domain-san-ssl-certificat
[4] https://comodosslstore.com/comodo-mdc-ssl.aspx


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.

EternalBlue 5 years after WannaCry and NotPetya, (Tue, Jul 5th)

This post was originally published on this site

We are about two months past the 5-year anniversary of WannaCry outbreak[1] and about a week past the 5-year anniversary of NotPetya outbreak[2]. Since both WannaCry and NotPetya used the EternalBlue[3] exploit in order to spread, I thought that it might be interesting to take a look at how many internet-facing systems still remain vulnerable to it.

7-Zip & MoW: "For Office files", (Mon, Jul 4th)

This post was originally published on this site

As I explained in my diary entry "7-Zip & MoW", the MoW on a ZIP file can be set to be propagated by 7-Zip to Office files only (propagation setting "For Office files").

My tests showed that this was based on the file extension of the Office file. As I received some questions about this, I took a look at the 7-Zip source code.

Here is the code that determines whether to write a Zone.Identifier ADS or not depending on the setting for Zone.Identifier propagation:

It uses function FindExt2 to check if the extension of the extracted file (_diskFilePath) matches a list of predefined extensions (kOfficeExtensions).

This is the predefined list kOfficeExtensions:

Notice that the extension RTF is not in this list.

And while I was browsing the source code, I also took a look at the possible registry values for this setting:

7-Zip deletes registry values if they are not used (-1).

That is why you will find values 1 (all files) and 2 (Office files only) only in the registry.

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

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

PowerShell Extension for Visual Studio Code June 2022 Update

This post was originally published on this site

We are excited to announce that an update to the PowerShell Extension for Visual Studio Code is now available on the extension marketplace.

This release fixes a number of issues related to IntelliSense and enables updates to PowerShell Editor Services (the engine of the VS Code extension) for other clients, such as Emacs and Vim with LSP plug-ins.

Updates from the June releases

Some highlights of June releases:

For the full list of changes please refer to our changelog.

IntelliSense improvements

In this release we have made a number of improvements to IntelliSense (the general term for various code editing features including: code completion, parameter info, tool-tip hovers, etc.).

Mark completion request handler as serial

Previously, if you typed Get- very quickly, you’d get no results at all. This stops completion from being cancelled whenever a DidChangeTextDocument notification is sent. This also lets completion cancel some other expensive requests like code lenses, which means everything is both speedier and less flaky.

Fix tasks never completing if cancelled quickly

We were exiting SynchronousTask.ExecuteSynchronously early if the cancellation was already requested. This was not setting our state correctly, causing the caller to just fall off without warning. This made some things like finally and using disposals never happen, which led to a lot of erratic behavior!

Make alias discovery possible on idle

The use of Runspace.SessionStateProxy while the pipeline thread is busy (even if you are on the pipeline thread) results in an exception. By fixing this we can also cancel GetAliasesAsync (a slow operation) when needed, and do it while idling instead of startup.

Add “space” character to completion trigger characters

Adding the “space” character to completion triggers lets us automatically give completion results for parameter values. This also required building in some support for marking completion results as “incomplete”. This means that the client will not cache results when standard identifier characters are typed.

Mainly, this solves the scenario where you type space, get file completion results, and then type -. You expect to then get parameter names, but without marking “incomplete”, it will instead filter the file results.

Also fixed a scenario where you type $script: and on typing the : it would not update to available script scope variables.

Make completion requests cancellable

Now any completion results from custom argument completers can be cancelled if they take too long and the user keeps typing. In non-remote runspaces, we can also use it as a completion source that we can cancel by way of issuing a pipeline stop request.

What’s next for the project?

We are currently building out regression tests for the extension to cover everything we broke and subsequently fixed during the major rewrite earlier this year. We have a strong focus on quality, and want to ensure we continue to deliver a production-ready, high-quality extension to you, our users. We have made a large investment in improving the extension so we want to be able to confidently continue to iterate on this project without inadvertently impacting the performance, stability, or feature set. We’ve begun this work already, and are tracking in our GitHub repository.

Getting support and giving feedback

While we hope the new implementation provides a much better user experience, there are bound to be issues. Please let us know if you run into anything.

If you encounter any issues with the PowerShell Extension in Visual Studio Code or have feature requests, the best place to get support is through our GitHub repository.

Sydney

PowerShell Team

The post PowerShell Extension for Visual Studio Code June 2022 Update appeared first on PowerShell Team.

Skyline Advisor Pro Proactive Findings – June Edition

This post was originally published on this site

Tweet VMware Skyline Advisor Pro releases new Proactive Findings every month. Findings are prioritized by trending issues in VMware Support, issues raised through post escalation review, security vulnerabilities, and issues raised from VMware engineering, and customers. For the month of June, we released 41 new Findings. Of these, there are 37 Findings based on trending … Continued

The post Skyline Advisor Pro Proactive Findings – June Edition appeared first on VMware Support Insider.

AA22-181A: #StopRansomware: MedusaLocker

This post was originally published on this site

Original release date: June 30, 2022

Summary

Actions to take today to mitigate cyber threats from ransomware:
• Prioritize remediating known exploited vulnerabilities.
• Train users to recognize and report phishing attempts.
• Enable and enforce multifactor authentication.

Note: this joint Cybersecurity Advisory (CSA) is part of an ongoing #StopRansomware effort to publish advisories for network defenders that detail various ransomware variants and ransomware threat actors. These #StopRansomware advisories include recently and historically observed tactics, techniques, and procedures (TTPs) and indicators of compromise (IOCs) to help organizations protect against ransomware. Visit stopransomware.gov to see all #StopRansomware advisories and to learn more about other ransomware threats and no-cost resources.

The Federal Bureau of Investigation (FBI), the Cybersecurity and Infrastructure Security Agency (CISA), the Department of the Treasury, and the Financial Crimes Enforcement Network (FinCEN) are releasing this CSA to provide information on MedusaLocker ransomware. Observed as recently as May 2022, MedusaLocker actors predominantly rely on vulnerabilities in Remote Desktop Protocol (RDP) to access victims’ networks. The MedusaLocker actors encrypt the victim’s data and leave a ransom note with communication instructions in every folder containing an encrypted file. The note directs victims to provide ransomware payments to a specific Bitcoin wallet address. MedusaLocker appears to operate as a Ransomware-as-a-Service (RaaS) model based on the observed split of ransom payments. Typical RaaS models involve the ransomware developer and various affiliates that deploy the ransomware on victim systems. MedusaLocker ransomware payments appear to be consistently split between the affiliate, who receives 55 to 60 percent of the ransom; and the developer, who receives the remainder. 

Download the PDF version of this report: pdf, 633 kb

Technical Details

MedusaLocker ransomware actors most often gain access to victim devices through vulnerable Remote Desktop Protocol (RDP) configurations [T1133]. Actors also frequently use email phishing and spam email campaigns—directly attaching the ransomware to the email—as initial intrusion vectors [T1566].

MedusaLocker ransomware uses a batch file to execute PowerShell script invoke-ReflectivePEInjection [T1059.001]. This script propagates MedusaLocker throughout the network by editing the EnableLinkedConnections value within the infected machine’s registry, which then allows the infected machine to detect attached hosts and networks via Internet Control Message Protocol (ICMP) and to detect shared storage via Server Message Block (SMB) Protocol. 

MedusaLocker then: 

  • Restarts the LanmanWorkstation service, which allows registry edits to take effect. 
  • Kills the processes of well-known security, accounting, and forensic software. 
  • Restarts the machine in safe mode to avoid detection by security software [T1562.009].
  • Encrypts victim files with the AES-256 encryption algorithm; the resulting key is then encrypted with an RSA-2048 public key [T1486]. 
  • Runs every 60 seconds, encrypting all files except those critical to the functionality of the victim’s machine and those that have the designated encrypted file extension. 
  • Establishes persistence by copying an executable (svhost.exe or svhostt.exe) to the %APPDATA%Roaming directory and scheduling a task to run the ransomware every 15 minutes. 
  • Attempts to prevent standard recovery techniques by deleting local backups, disabling startup recovery options, and deleting shadow copies [T1490].

MedusaLocker actors place a ransom note into every folder containing a file with the victim’s encrypted data. The note outlines how to communicate with the MedusaLocker actors, typically providing victims one or more email address at which the actors can be reached. The size of MedusaLocker ransom demands appears to vary depending on the victim’s financial status as perceived by the actors. 

Indicators of Compromise

Encrypted File Extensions
.1btc .matlock20 .marlock02 .readinstructions
.bec .mylock .jpz.nz .marlock11
.cn .NET1 .key1 .fileslocked
.datalock .NZ .lock .lockfilesUS
.deadfilesgr .tyco .lockdata7 .rs
.faratak .uslockhh .lockfiles .tyco
.fileslock .zoomzoom .perfection .uslockhh
.marlock13 n.exe .Readinstruction .marlock08
.marlock25 nt_lock20 .READINSTRUCTION  
.marlock6 .marlock01 .ReadInstructions  

 

Ransom Note File Names
how_to_ recover_data.html  how_to_recover_data.html.marlock01
instructions.html  READINSTRUCTION.html 
!!!HOW_TO_DECRYPT!!! How_to_recovery.txt
readinstructions.html  readme_to_recover_files
recovery_instructions.html  HOW_TO_RECOVER_DATA.html
recovery_instruction.html  

 

Payment Wallets
14oxnsSc1LZ5M2cPZeQ9rFnXqEvPCnZikc 
1DRxUFhvJjGUdojCzMWSLmwx7Qxn79XbJq 
18wRbb94CjyTGkUp32ZM7krCYCB9MXUq42 
1AbRxRfP6yHePpi7jmDZkS4Mfpm1ZiatH5
1Edcufenw1BB4ni9UadJpQh9LVx9JGtKpP
1DyMbw6R9PbJqfUSDcK5729xQ57yJrE8BC 
184ZcAoxkvimvVZaj8jZFujC7EwR3BKWvf 
14oH2h12LvQ7BYBufcrY5vfKoCq2hTPoev
bc1qy34v0zv6wu0cugea5xjlxagsfwgunwkzc0xcjj
bc1q9jg45a039tn83jk2vhdpranty2y8tnpnrk9k5q
bc1qz3lmcw4k58n79wpzm550r5pkzxc2h8rwmmu6xm
1AereQUh8yjNPs9Wzeg1Le47dsqC8NNaNM
1DeNHM2eTqHp5AszTsUiS4WDHWkGc5UxHf
1HEDP3c3zPwiqUaYuWZ8gBFdAQQSa6sMGw
1HdgQM9bjX7u7vWJnfErY4MWGBQJi5mVWV
1nycdn9ebxht4tpspu4ehpjz9ghxlzipll
12xd6KrWVtgHEJHKPEfXwMVWuFK4k1FCUF
1HZHhdJ6VdwBLCFhdu7kDVZN9pb3BWeUED
1PormUgPR72yv2FRKSVY27U4ekWMKobWjg
14cATAzXwD7CQf35n8Ea5pKJPfhM6jEHak
1PopeZ4LNLanisswLndAJB1QntTF8hpLsD

 

Email Addresses
willyhill1960@tutanota[.]com  unlockfile@cock[.]li
zlo@keem[.]ne  unlockmeplease@airmail[.]cc 
zlo@keemail[.]me  unlockmeplease@protonmail[.]com 
zlo@tfwno[.]gf  willyhill1960@protonmail[.]com 
support@ypsotecs[.]com support@imfoodst[.]com 

 

Email Addresses
traceytevin@protonmail[.]com  support@itwgset[.]com
unlock_file@aol[.]com  support@novibmaker[.]com
unlock_file@outlook[.]com  support@securycasts[.]com 
support@exoprints[.]com rewmiller-1974@protonmail[.]com
support@exorints[.]com  rpd@keemail[.]me
support@fanbridges[.]com  soterissylla@wyseil[.]com 
support@faneridges[.]com support@careersill[.]com 
perfection@bestkoronavirus[.]com  karloskolorado@tutanota[.]com
pool1256@tutanota[.]com  kevynchaz@protonmail[.]com 
rapid@aaathats3as[.]com korona@bestkoronavirus[.]com
rescuer@tutanota[.]com lockPerfection@gmail[.]com
ithelp01@decorous[.]cyou lockperfection@gmail[.]com 
ithelp01@wholeness[.]business mulierfagus@rdhos[.]com
ithelp02@decorous[.]cyou [rescuer]@cock[.]li 
ithelp02@wholness[.]business 107btc@protonmail[.]com 
ithelpresotre@outlook[.]com 33btc@protonmail[.]com 
cmd@jitjat[.]org  777decoder777@protonmail[.]com
coronaviryz@gmail[.]com 777decoder777@tfwno[.]gf
dec_helper@dremno[.]com andrewmiller-1974@protonmail[.]com
dec_helper@excic[.]com  angelomartin-1980@protonmail[.]com
dec_restore@prontonmail[.]com  ballioverus@quocor[.]com
dec_restore1@outlook[.]com beacon@jitjat[.]org
bitcoin@sitesoutheat[.]com  beacon@msgsafe[.]io
briansalgado@protonmail[.]com best666decoder@tutanota[.]com 
bugervongir@outlook[.]com bitcoin@mobtouches[.]com 
best666decoder@protonmail[.]com  encrypt2020@outlook[.]com 
decoder83540@cock[.]li fast-help@inbox[.]lv
decra2019@gmail[.]com  fuc_ktheworld1448@outlook[.]com
diniaminius@winrof[.]com  fucktheworld1448@cock[.]li
dirhelp@keemail[.]me  gartaganisstuffback@gmail[.]com 

 

Email Addresses
emaila.elaich@iav.ac[.]ma gavingonzalez@protonmail[.]com
emd@jitjat[.]org gsupp@onionmail[.]org
encrypt2020@cock[.]li  gsupp@techmail[.]info
best666decoder@protonmail[.]com  helper@atacdi[.]com 
ithelp@decorous[.]cyou helper@buildingwin[.]com 
ithelp@decorous[.]cyoum helprestore@outlook[.]com
ithelp@wholeness[.]business helptorestore@outlook[.]com

 

TOR Addresses
http://gvlay6u4g53rxdi5.onion/6-iSm1B1Ehljh8HYuXGym4Xyu1WdwsR2Av-6tXiw1BImsqoLh7pd207Rl6XYoln7sId 
http://gvlay6u4g53rxdi5.onion/8-grp514hncgblilsjtd32hg6jtbyhlocr5pqjswxfgf2oragnl3pqno6fkqcimqin
http://gvlay6y4g53rxdi5.onion/21-8P4ZLCsMETPaLw9MkSlXJsNZWdHe0rxjt-XmBgZLWlm5ULGFCOJFuVdEymmxysofwu
http://gvlay6u4g53rxdi5.onion/2l-8P4ZLCsMTPaLw9MkSlXJsNZWdHeOrxjtE9lck1MuXPYo29daQys6gomZZXUImN7Z 
http://gvlay6u4g53rxdi5.onion/21-8P4ZLCsMTPaLw9MkSlXJsNZWdHe0rxjt-DcaE9HeHywqSHvdcIwOndCS4PuWASX8g 
http://gvlay6u4g53rxdi5.onion/21-8P4ZLCsMTPaLw9MkSlXJsNZWdHe0rxjt-kB4rQXGKyxGiLyw7YDsMKSBjyfdwcyxo
http://gvlay6u4g53rxdi5.onion/21-8P4ZLCsMTPaLw9MkSlXJsNZWdHe0rxjt-bET6JbB9vEMZ7qYBPqUMCxOQExFx4iOi 
http://gvlay6u4g53rxdi5. onion/8-MO0Q7O97Hgxvm1YbD7OMnimImZJXEWaG-RbH4TvdwVTGQB3X6VOUOP3lgO6YOJEOW
http://gvlay6u4g53rxdi5.onion/8-gRp514hncgb1i1sjtD32hG6jTbUh1ocR-Uola2Fo30KTJvZX0otYZgTh5txmKwUNe 
http://gvlay6u4g53rxdi5.onion/21-E6UQFCEuCn4KvtAh4TonRTpyHqFo6F6L-OWQwD1w1Td7hY7IGUUjxmHMoFSQW6blg 
http://gvlay6u4g53rxdi5.onion/21-E6UQFCEuCn4KvtAh4TonRTpyHqFo6F6L-uGHwkkWCoUtBbZWN50sSS4Ds8RABkrKy 
http://gvlay6u4g53rxdi5.onion/21-E6UQFCEuCn4KvtAh4TonRTpyHqFo6F6L-Tj3PRnQlpHc9OftRVDGAWUulvE80yZbc 
http://gvlay6u4g53rxdi5.onion/8-Ww5sCBhsL8eM4PeAgsfgfa9lrqa81r31-tDQRZCAUe4164X532j9Ky16IBN9StWTH 
http://gvlay6u4g53rxdi5.onion/21-wIq5kK9gGKiTmyups1U6fABj1VnXIYRB-I5xek6PG2EbWlPC7C1rXfsqJBlWlFFfY
qd7pcafncosqfqu3ha6fcx4h6sr7tzwagzpcdcnytiw3b6varaeqv5yd.onion
http://medusacegu2ufmc3kx2kkqicrlcxdettsjcenhjena6uannk5f4ffuyd.onion/leakdata/paigesmusic-leakdata-closed-part1

 

Disclaimer: Many of these observed IP addresses are several years old and have been historically linked to MedusaLocker ransomware. We recommend these IP addresses be investigated or vetted by organizations prior to taking action, such as blocking.

IP Address Last Observed
195.123.246.138 Nov-2021
138.124.186.221 Nov-2021
159.223.0.9 Nov-2021
45.146.164.141 Nov-2021
185.220.101.35 Nov-2021
185.220.100.249 Sep-2021
50.80.219.149 Sep-2021
185.220.101.146 Sep-2021
185.220.101.252 Sep-2021
179.60.150.97 Sep-2021
84.38.189.52 Sep-2021
94.232.43.63 Jul-2021
108.11.30.103 Apr-2021
194.61.55.94 Apr-2021
198.50.233.202 Apr-2021
40.92.90.105 Jan-2021
188.68.216.23 Dec-2020
87.251.75.71 Dec-2020
196.240.57.20 Oct-2020
198.0.198.5 Aug-2020
194.5.220.122 Mar-2020
194.5.250.124 Mar-2020
194.5.220.124 Mar-2020
104.210.72.161 Nov-2019

 

MITRE ATT&CK Techniques

MedusaLocker actors use the ATT&CK techniques listed in Table 1.

Table 1: MedusaLocker Actors ATT&CK Techniques for Enterprise

Initial Access
Technique Title ID Use
External Remote Services T1133 MedusaLocker actors gained access to victim devices through vulnerable RDP configurations.
Phishing T1566 MedusaLocker actors used phishing and spearphishing to obtain access to victims’ networks.
Execution
Technique Title ID Use
Command and Scripting Interpreter: PowerShell

T1059.001

MedusaLocker actors may abuse PowerShell commands and scripts for execution.
Defense Evasion
Technique Title ID Use
Impair Defenses: Safe Mode Boot

T1562.009

MedusaLocker actors may abuse Windows safe mode to disable endpoint defenses. Safe mode starts up the Windows operating system with a limited set of drivers and services.
Impact
Technique Title ID Use
Data Encrypted for Impact T1486 MedusaLocker actors encrypt data on target systems or on large numbers of systems in a network to interrupt availability to system and network resources.
Inhibit System Recovery T1490 MedusaLocker actors may deny access to operating systems containing features that can help fix corrupted systems, such as backup catalog, volume shadow copies, and automatic repair.

 

Mitigations

  • Implement a recovery plan that maintains and retains multiple copies of sensitive or proprietary data and servers in a physically separate, segmented, and secure location (i.e., hard drive, storage device, or the cloud).
  • Implement network segmentation and maintain offline backups of data to ensure limited interruption to the organization.
  • Regularly back up data and password protect backup copies stored offline. Ensure copies of critical data are not accessible for modification or deletion from the system where the data resides.
  • Install, regularly update, and enable real time detection for antivirus software on all hosts.
  • Install updates for operating systems, software, and firmware as soon as possible.
  • Review domain controllers, servers, workstations, and active directories for new and/or unrecognized accounts.
  • Audit user accounts with administrative privileges and configure access controls according to the principle of least privilege. 
  • Disable unused ports.
  • Consider adding an email banner to emails received from outside your organization.
  • Disable hyperlinks in received emails.
  • Enforce multifactor authentication (MFA).
  • Use National Institute of Standards and Technology (NIST) standards for developing and managing password policies:
    • Use longer passwords consisting of at least 8 characters and no more than 64 characters in length.
    • Store passwords in hashed format using industry-recognized password managers.
    • Add password user “salts” to shared login credentials.
    • Avoid reusing passwords.
    • Implement multiple failed login attempt account lockouts.
    • Disable password “hints”.
    • Refrain from requiring password changes unless there is evidence of password compromise. Note: NIST guidance suggests favoring longer passwords and no longer require regular and frequent password resets. Frequent password resets are more likely to result in users developing password “patterns” cyber criminals can easily decipher.
    • Require administrator credentials to install software.
  • Only use secure networks; avoid using public Wi-Fi networks.
  • Consider installing and using a virtual private network (VPN) to establish secure remote connections.
  • Focus on cybersecurity awareness and training. Regularly provide users with training on information security principles and techniques as well as overall emerging cybersecurity risks and vulnerabilities, such as ransomware and phishing scams.

 
Resources

  • Stopransomware.gov is a whole-of-government approach that gives one central location for ransomware resources and alerts.
  • Resource to mitigate a ransomware attack: CISA-Multi-State Information Sharing and Analysis Center (MS-ISAC) Joint Ransomware Guide
  • No-cost cyber hygiene services: Cyber Hygiene Services and Ransomware Readiness Assessment

Reporting

  • To report an incident and request technical assistance, contact CISA at cisaservicedesk@cisa.dhs.gov or 888-282-0870, or FBI through a local field office. 
  • Financial Institutions must ensure compliance with any applicable Bank Secrecy Act requirements, including suspicious activity reporting obligations. Indicators of compromise (IOCs), such as suspicious email addresses, file names, hashes, domains, and IP addresses, can be provided under Item 44 of the Suspicious Activity Report (SAR) form. For more information on mandatory and voluntary reporting of cyber events via SARs, see FinCEN Advisory FIN-2016-A005, Advisory to Financial Institutions on Cyber-Events and Cyber-Enabled Crime, October 25, 2016; and FinCEN Advisory FIN-2021-A004, Advisory on Ransomware and the Use of the Financial System to Facilitate Ransom Payments, November 8, 2021, which updates FinCEN Advisory FIN-2020-A006.
  • The U.S. Department of State’s Rewards for Justice (RFJ) program offers a reward of up to $10 million for reports of foreign government malicious activity against U.S. critical infrastructure. See the RFJ website for more information and how to report information securely.

Contact Information

To report suspicious or criminal activity related to information found in this Joint Cybersecurity Advisory, contact your local FBI field office at www.fbi.gov/contact-us/field-offices. When available, please include the following information regarding the incident: date, time, and location of the incident; type of activity; number of people affected; type of equipment used for the activity; the name of the submitting company or organization; and a designated point of contact. To report incidents and anomalous activity or to request incident response resources or technical assistance related to this threat, contact CISA at report@cisa.gov.

Revisions

  • June 30, 2022: Initial Version

This product is provided subject to this Notification and this Privacy & Use policy.

Case Study: Cobalt Strike Server Lives on After Its Domain Is Suspended, (Thu, Jun 30th)

This post was originally published on this site

Introduction

How do threat actors behind a Cobalt Strike server keep it running after its domain is taken down?  If the server is not hosted through the domain registrar, it merely keeps running on the same IP address.

Today's diary is a case study where Cobalt Strike remained active on the same IP address at least one week after its domain was suspended.

Traffic Forensics

On Tuesday 2022-06-28, I generated a Qakbot infection in my lab and saw Cobalt Strike HTTPS traffic on 147.78.47[.]223 over TCP port 443 as shown below.


Shown above:  Traffic from a Qakbot infection with Cobalt Strike on Tuesday 2022-06-28 filtered in Wireshark.

Examining the certificate in Wireshark reveals it's a Let's Encrypt certificate for moros[.]icu.  Let's Encrypt is a legitimate free, automated, and open certificate authority (CA).  While used by many valid websites, this service is commonly abused by threat actors, including those behind malicious Cobalt Strike activity.


Shown above:  Reviewing certificate issuer data associated with Cobalt Strike traffic on 147.78.47[.]223 in Wireshark.

Investigating the Malicious Server

Viewing the certificate from 147.78.47[.]223 in a web browser reveals it was originally issued for moros[.]icu through Let's Encrypt on 2022-06-20 and is no longer valid for that IP.


Shown above:  Connecting to the Cobalt Strike server using a web browser.


Shown above:  Certificate data for moros[.]icu shown in a web browser.

The domain moros[.]icu was reported and suspended less than one day after it was registered through Namecheap, but its server was set up through a legitimate hosting provider at Flyservers.  Kudos to @ian_kenefick and Namecheap for quickly taking action and suspending this malicious domain!


Shown above: Tweets showing moros[.]icu was suspended on 2022-06-21.


Shown above:  My own confirmation that moros[.]icu no longer works.


Shown above:  Whois lookup for 147.78.47[.]223 using whois.domaintools.com.

The certificate's validity did not matter for Cobalt Strike activity I found on Tuesday 2022-06-28.  Since the traffic was generated by malware instead of a web browser, HTTPS still worked.

Flyservers has been a hosting provider since 2001, and it appears to be a legitimate company.  I've emailed their abuse address to report the malicious server on 147.78.47[.]223.

Final Words

Threat actors continually abuse legitimate hosting providers and certificate authorities (CAs), presumably through fraudulent accounts.  Both free and paid services are incredibly susceptible to criminal abuse.  Even Cobalt Strike is a legitimate red team tool commonly abused by various threat actors.

Security professionals can quickly report abuse cases, and service providers can rapidly shut down individual violations.  However, threat actors can easily recover, and malware-related servers will continue to be an issue for defenders everywhere.

This case study reveals how criminal activity can circumvent domain takedowns.  It also illustrates how time-intensive the associated investigation and corrective actions can be.

Brad Duncan
brad [at] malware-traffic-analysis.net

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

Iron Castle Systems