Microsoft also published a blog post that provides links to various remediation solutions and outlines their actions in response to the outage, which include working with CrowdStrike to expedite restoring services to disrupted systems.
In the blog post, Microsoft estimates the outage affected 8.5 million Windows devices. Microsoft notes that this number makes up less than one percent of all Windows machines.
Update 12:30 p.m., EDT, July 20, 2024:
CrowdStrike continues to provide updated guidance on yesterday’s widespread IT outage, including remediation steps for specific environments.
Information on how the update to the CrowdStrike Falcon sensor configuration file, Channel File 291, caused the logic error that led to the outage.
A discussion of the root cause analysis CrowdStrike is undertaking to determine how the logic error occurred.
Cyber threat actors continue to leverage the outage to conduct malicious activity, including phishing attempts. CISA continues to work closely with CrowdStrike and other private sector and government partners to actively monitor any emerging malicious activity.
According to a new CrowdStrike blog, threat actors have been distributing a malicious ZIP archive file. This activity appears to be targeting Latin America-based CrowdStrike customers. The blog provides indicators of compromise and recommendations.
Update 7:30 p.m., EDT, July 19, 2024:
The CrowdStrike guidance is updated with additional guidance regarding impacts to specific environments, e.g., Azure, AWS.
Threat actors continue to use the widespread IT outage for phishing and other malicious activity. CISA urges organizations to ensure they have robust cybersecurity measures to protect their users, assets, and data against this activity.
CISA continues to monitor the situation and will update this Alert to provide continued support.
Initial Alert (11:30 a.m., EDT, July 19, 2024):
CISA is aware of the widespread outage affecting Microsoft Windows hosts due to an issue with a recent CrowdStrike update and is working closely with CrowdStrike and federal, state, local, tribal and territorial (SLTT) partners, as well as critical infrastructure and international partners to assess impacts and support remediation efforts. CrowdStrike has confirmed the outage:
Impacts Windows 10 and later systems.
Does not impact Mac and Linux hosts.
Is due to the CrowdStrike Falcon content update and not to malicious cyber activity.
Of note, CISA has observed threat actors taking advantage of this incident for phishing and other malicious activity. CISA urges organizations and individuals to remain vigilant and only follow instructions from legitimate sources. CISA recommends organizations to remind their employees to avoid clicking on phishing emails or suspicious links.
Cisco released security updates to address vulnerabilities in Cisco software. A cyber threat actor could exploit some of these vulnerabilities to take control of an affected system.
CISA encourages users and administrators to review the following advisories and apply necessary updates:
Ivanti released security updates to address vulnerabilities in Ivanti Endpoint Manager (EPM) and Ivanti Endpoint Manager for Mobile (EPMM). A cyber threat actor could exploit some of these vulnerabilities to take control of an affected system.
CISA encourages users and administrators to review the following Ivanti advisories and apply the necessary updates:
Vulnerabilities: Out-of-bounds Write, Deserialization of Untrusted Data, Uncontrolled Resource Consumption, Improper Privilege Management, Use of Default Credentials, Weak Password Requirements, Exposure of Sensitive Information to an Unauthorized Actor
2. RISK EVALUATION
Successful exploitation of these vulnerabilities could allow an unauthorized person or process to eavesdrop, view or modify data, gain system access, perform code execution, install unauthorized software, or affect system data integrity to negatively impact system confidentiality, integrity, or availability.
A validated user not explicitly authorized to have access to certain sensitive information could access Philips Vue PACS on the same network to expose that information.
CRITICAL INFRASTRUCTURE SECTORS: Healthcare and Public Health
COUNTRIES/AREAS DEPLOYED: Worldwide
COMPANY HEADQUARTERS LOCATION: Netherlands
3.4 RESEARCHER
TAS Health NZ and Camiel van Es reported these vulnerabilities to Philips.
4. MITIGATIONS
Philips recommends the following mitigations:
For vulnerabilities CVE-2020-36518, CVE-2020-11113, CVE-2020-35728, CVE-2021-20190, CVE-2020-14061, CVE-2020-10673, CVE-2019-12814, CVE-2017-17485, CVE-2023-40223, and CVE-2023-40159, Philips recommends upgrading to the latest Vue PACS version 12.2.8.400* released in August 2023.
For CVE-2021-28165, Philips recommends configuring the Vue PACS environment per D000763414 – Vue_PACS_12_Ports_Protocols_Services_Guide available on Incenter. Philips also recommends upgrading to the Vue PACS version 12.2.8.410* released in October 2023.
For CVE-2023-40704 and CVE-2023-40539, Philips recommends configuring the Vue PACS environment per 8G7607 – Vue PACS User Guide Rev G available on Incenter.
For managed services customers, new releases will be made available upon resource availability. Releases are subject to country specific regulations. Users with questions regarding their specific Philips Vue PACS installations and new release eligibility should contact their local Philips Sales representative or submit a request in the Philips Informatics Support portal.
Locate control system networks and remote devices behind firewalls and isolating them from business networks.
When remote access is required, use more secure methods, such as virtual private networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.
CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.
Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.
No known public exploitation specifically targeting these vulnerabilities has been reported to CISA at this time.
A denial-of-service vulnerability exists in the OpenSSL library used in MELSOFT MaiLab due to improper verification of cryptographic signature resulting from improper implementation of the POLY1305 message authentication code (MAC).
Mitsubishi Electric reported these vulnerabilities to CISA.
4. MITIGATIONS
Mitsubishi Electric recommends users install the fixed version (ver.1.06G or later) and update the software. For information about how to install the fixed version, please contact your local Mitsubishi Electric representative.
Mitsubishi Electric recommends that users take the following mitigations to minimize the risk of exploiting this vulnerability:
When internet access is required, use a firewall or a virtual private network (VPN) to prevent unauthorized access.
Use the products within a control system, and protect the network and devices in the control system with a firewall to block access from untrusted networks and hosts.
Restrict physical access to the PC on which the product is installed and the network to which the PC is connected to prevent unauthorized access.
Do not click on web links in emails or other messages from untrusted sources. Also, do not open attachments from untrusted emails.
CISA recommends users take defensive measures to minimize the risk of exploitation of this vulnerability. CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.
Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.
No known public exploitation specifically targeting this vulnerability has been reported to CISA at this time. This vulnerability has a high attack complexity.
CISA released three Industrial Control Systems (ICS) advisories on July 18, 2024. These advisories provide timely information about current security issues, vulnerabilities, and exploits surrounding ICS.
Oracle released its quarterly Critical Patch Update Advisory for July 2024 to address vulnerabilities in multiple products. A cyber threat actor could exploit some of these vulnerabilities to take control of an affected system.
CISA encourages users and administrators to review the following Oracle Critical Patch Update Advisory and apply the necessary updates:
Subnet PowerSYSTEM Center products are vulnerable to a prototype pollution vulnerability, which may allow an authenticated attacker to elevate permissions.
CRITICAL INFRASTRUCTURE SECTORS: Critical Manufacturing, Energy
COUNTRIES/AREAS DEPLOYED: Worldwide
COMPANY HEADQUARTERS LOCATION: Canada
3.4 RESEARCHER
Subnet Solutions Inc. reported this vulnerability to CISA.
4. MITIGATIONS
Subnet Solutions recommends users upgrade to PowerSYSTEM Center versions 2020 Update 21 or later. To obtain this software, contact Subnet Solution's Customer Service.
CISA recommends users take defensive measures to minimize the risk of exploitation of this vulnerability, such as:
Locate control system networks and remote devices behind firewalls and isolating them from business networks.
When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.
CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.
Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.
CISA also recommends users take the following measures to protect themselves from social engineering attacks:
Do not click web links or open attachments in unsolicited email messages.
CVE-2022-22948 VMware vCenter Server Incorrect Default File Permissions Vulnerability
These types of vulnerabilities are frequent attack vectors for malicious cyber actors and pose significant risks to the federal enterprise.
Binding Operational Directive (BOD) 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities established the Known Exploited Vulnerabilities Catalog as a living list of known Common Vulnerabilities and Exposures (CVEs) that carry significant risk to the federal enterprise. BOD 22-01 requires Federal Civilian Executive Branch (FCEB) agencies to remediate identified vulnerabilities by the due date to protect FCEB networks against active threats. See theBOD 22-01 Fact Sheet for more information.
Although BOD 22-01 only applies to FCEB agencies, CISA strongly urges all organizations to reduce their exposure to cyberattacks by prioritizing timely remediation of Catalog vulnerabilities as part of their vulnerability management practice. CISA will continue to add vulnerabilities to the catalog that meet the specified criteria.
CISA released one Industrial Control Systems (ICS) advisory on July 16, 2024. These advisories provide timely information about current security issues, vulnerabilities, and exploits surrounding ICS.
A privilege escalation vulnerability exists in the affected products which could allow a malicious user with basic privileges to access functions which should only be available to users with administrative level privileges. If exploited, an attacker could read sensitive data and create users. For example, a malicious user with basic privileges could perform critical functions such as creating a user with elevated privileges, or reading sensitive information in the "views" section.
Rockwell Automation reported this vulnerability to CISA.
4. MITIGATIONS
Rockwell Automation recommends users update to Pavilion8 version 6.0 or greater.
Users using the affected software and who are not able to upgrade to one of the corrected versions are encouraged to apply security best practices, where possible.
Limit access to only users who need it.
Periodically review user access and privileges to confirm accuracy.
Locate control system networks and remote devices behind firewalls and isolating them from business networks.
When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.
CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.
Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.
No known public exploitation specifically targeting this vulnerability has been reported to CISA at this time.
These types of vulnerabilities are frequent attack vectors for malicious cyber actors and pose significant risks to the federal enterprise.
Binding Operational Directive (BOD) 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities established the Known Exploited Vulnerabilities Catalog as a living list of known Common Vulnerabilities and Exposures (CVEs) that carry significant risk to the federal enterprise. BOD 22-01 requires Federal Civilian Executive Branch (FCEB) agencies to remediate identified vulnerabilities by the due date to protect FCEB networks against active threats. See theBOD 22-01 Fact Sheet for more information.
Although BOD 22-01 only applies to FCEB agencies, CISA strongly urges all organizations to reduce their exposure to cyberattacks by prioritizing timely remediation of Catalog vulnerabilities as part of their vulnerability management practice. CISA will continue to add vulnerabilities to the catalog that meet the specified criteria.
On July 12, AT&T released a public statement on unauthorized access of customer data from a third-party cloud platform. AT&T also provided recommendations and resources for affected customers.
CISA encourages customers to review the following AT&T article for additional information and follow necessary guidance to help protect personal information.
Successful exploitation of this vulnerability could allow an attacker to cause a denial-of-service condition, exfiltrate data, or obtain a high degree of control over the device and subsequent systems, including remote code execution.
3. TECHNICAL DETAILS
3.1 AFFECTED PRODUCTS
The following versions of Anybus-CompactCom 30, an industrial communication interface, are affected if they include a web server:
The Anybus-CompactCom 30 products are vulnerable to a XSS attack caused by the lack of input sanitation checks. As a consequence, it is possible to insert HTML code into input fields and store the HTML code. The stored HTML code will be embedded in the page and executed by host browser the next time the page is loaded, enabling social engineering attacks.
Vincenzo Giuseppe Colacino of Secoore reported this vulnerability to CISA.
4. MITIGATIONS
HMS recommends users implement at least one of the following:
Add password protection to all webpages served by the Anybus-CompactCom 30 module.
Disable or add the option to allow the end-user to disable the webserver in the AnybusCompactCom 30.
Make sure these products are used locally within a secure network utilizing proper network infrastructure controls. This will help ensure that unused or unnecessary protocols from unauthorized sources are blocked.
Ensure that control systems and devices are situated behind firewalls, ensuring their isolation from the corporate network.
Replace the Anybus-CompactCom 30 module with a Anybus-CompactCom 40 module.
When remote access is required, use more secure methods, such as virtual private networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.
CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.
Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.
CISA also recommends users take the following measures to protect themselves from social engineering attacks:
Do not click web links or open attachments in unsolicited email messages.
The affected applications contain an out of bounds read past the end of an allocated structure while parsing specially crafted PDF files. This could allow an attacker to execute code in the context of the current process.
Siemens has identified the following specific workarounds and mitigations users can apply to reduce risk:
All affected products: Do not open untrusted PDF files in affected applications.
As a general security measure, Siemens recommends protecting network access to devices with appropriate mechanisms. To operate the devices in a protected IT environment, Siemens recommends configuring the environment according to Siemens' operational guidelines for industrial security and following recommendations in the product manuals.
Locate control system networks and remote devices behind firewalls and isolating them from business networks.
When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs). Recognize VPNs may have vulnerabilities, should be updated to the most recent version available, and are only as secure as the connected devices.
CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.
Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.
No known public exploitation specifically targeting this vulnerability has been reported to CISA at this time. This vulnerability is not exploitable remotely.
Vulnerabilities: Exposure of Sensitive Information to an Unauthorized Actor, Incorrect Privilege Assignment, Exposure of Sensitive System Information to an Unauthorized Control Sphere
2. RISK EVALUATION
Successful exploitation could allow an attacker to obtain user credentials, the MACSEC key, or create a remote shell to the affected system.
3. TECHNICAL DETAILS
3.1 AFFECTED PRODUCTS
The following products of Siemens, are affected:
RUGGEDCOM i800: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM i800NC: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM i801: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM i801NC: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM i802: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM i802NC: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM i803: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM i803NC: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM M969: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM M969NC: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM M2100: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM M2100NC: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM M2200: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM M2200NC: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RMC30: Versions prior to V4.3.10 (CVE-2023-52237, CVE-2024-39675)
RUGGEDCOM RMC30NC: Versions prior to V4.3.10 (CVE-2023-52237, CVE-2024-39675)
RUGGEDCOM RMC8388 V4.X: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RMC8388 V5.X: Versions prior to V5.9.0 (CVE-2023-52237, CVE-2024-38278)
RUGGEDCOM RMC8388NC V4.X: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RMC8388NC V5.X: Versions prior to V5.9.0 (CVE-2023-52237, CVE-2024-38278)
RUGGEDCOM RP110: Versions prior to V4.3.10 (CVE-2023-52237, CVE-2024-39675)
RUGGEDCOM RP110NC: Versions prior to V4.3.10 (CVE-2023-52237, CVE-2024-39675)
RUGGEDCOM RS400: Versions prior to V4.3.10 (CVE-2023-52237, CVE-2024-39675)
RUGGEDCOM RS400NC: Versions prior to V4.3.10 (CVE-2023-52237, CVE-2024-39675)
RUGGEDCOM RS401: Versions prior to V4.3.10 (CVE-2023-52237, CVE-2024-39675)
RUGGEDCOM RS401NC: Versions prior to V4.3.10 (CVE-2023-52237, CVE-2024-39675)
RUGGEDCOM RS416: Versions prior to V4.3.10 (CVE-2023-52237, CVE-2024-39675)
RUGGEDCOM RS416NC: Versions prior to V4.3.10 (CVE-2023-52237, CVE-2024-39675)
RUGGEDCOM RS416NCv2 V4.X: Versions prior to V4.3.10 (CVE-2023-52237, CVE-2024-39675)
RUGGEDCOM RS416NCv2 V5.X: Versions prior to V5.9.0 (CVE-2023-52237, CVE-2024-38278, CVE-2024-39675)
RUGGEDCOM RS416P: Versions prior to V4.3.10 (CVE-2023-52237, CVE-2024-39675)
RUGGEDCOM RS416PNC: Versions prior to V4.3.10 (CVE-2023-52237, CVE-2024-39675)
RUGGEDCOM RS416PNCv2 V4.X: Versions prior to V4.3.10 (CVE-2023-52237, CVE-2024-39675)
RUGGEDCOM RS416PNCv2 V5.X: Versions prior to V5.9.0 (CVE-2023-52237, CVE-2024-38278, CVE-2024-39675)
RUGGEDCOM RS416Pv2 V4.X: Versions prior to V4.3.10 (CVE-2023-52237, CVE-2024-39675)
RUGGEDCOM RS416Pv2 V5.X: Versions prior to V5.9.0 (CVE-2023-52237, CVE-2024-38278, CVE-2024-39675)
RUGGEDCOM RS416v2 V4.X: Versions prior to V4.3.10 (CVE-2023-52237, CVE-2024-39675)
RUGGEDCOM RS416v2 V5.X: Versions prior to V5.9.0 (CVE-2023-52237, CVE-2024-38278, CVE-2024-39675)
RUGGEDCOM RS900: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RS900 (32M) V4.X: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RS900 (32M) V5.X: Versions prior to V5.9.0 (CVE-2023-52237, CVE-2024-38278)
RUGGEDCOM RS900G: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RS900G (32M) V4.X: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RS900G (32M) V5.X: Versions prior to V5.9.0 (CVE-2023-52237, CVE-2024-38278)
RUGGEDCOM RS900GNC: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RS900GNC(32M) V4.X: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RS900GNC(32M) V5.X: Versions prior to V5.9.0 (CVE-2023-52237, CVE-2024-38278)
RUGGEDCOM RS900GP: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RS900GPNC: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RS900L: All versions (CVE-2023-52237)
RUGGEDCOM RS900LNC: All versions (CVE-2023-52237)
RUGGEDCOM RS900M-GETS-C01: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RS900M-GETS-XX: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RS900M-STND-C01: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RS900M-STND-XX: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RS900MNC-GETS-C01: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RS900MNC-GETS-XX: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RS900MNC-STND-XX: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RS900MNC-STND-XX-C01: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RS900NC: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RS900NC(32M) V4.X: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RS900NC(32M) V5.X: Versions prior to V5.9.0 (CVE-2023-52237, CVE-2024-38278)
RUGGEDCOM RS900W: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RS910: Versions prior to V4.3.10 (CVE-2023-52237, CVE-2024-39675)
RUGGEDCOM RS910L: All versions (CVE-2023-52237, CVE-2024-39675)
RUGGEDCOM RS910LNC: All versions (CVE-2023-52237, CVE-2024-39675)
RUGGEDCOM RS910NC: Versions prior to V4.3.10 (CVE-2023-52237, CVE-2024-39675)
RUGGEDCOM RS910W: Versions prior to V4.3.10 (CVE-2023-52237, CVE-2024-39675)
RUGGEDCOM RS920L: All versions (CVE-2023-52237, CVE-2024-39675)
RUGGEDCOM RS920LNC: All versions (CVE-2023-52237, CVE-2024-39675)
RUGGEDCOM RS920W: All versions (CVE-2023-52237, CVE-2024-39675)
RUGGEDCOM RS930L: All versions (CVE-2023-52237)
RUGGEDCOM RS930LNC: All versions (CVE-2023-52237)
RUGGEDCOM RS930W: All versions (CVE-2023-52237)
RUGGEDCOM RS940G: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RS940GNC: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RS969: All versions (CVE-2023-52237)
RUGGEDCOM RS969NC: All versions (CVE-2023-52237)
RUGGEDCOM RS1600: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RS1600F: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RS1600FNC: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RS1600NC: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RS1600T: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RS1600TNC: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RS8000: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RS8000A: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RS8000ANC: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RS8000H: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RS8000HNC: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RS8000NC: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RS8000T: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RS8000TNC: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RSG907R: Versions prior to V5.9.0 (CVE-2023-52237, CVE-2024-38278)
RUGGEDCOM RSG908C: Versions prior to V5.9.0 (CVE-2023-52237, CVE-2024-38278)
RUGGEDCOM RSG909R: Versions prior to V5.9.0 (CVE-2023-52237, CVE-2024-38278)
RUGGEDCOM RSG910C: Versions prior to V5.9.0 (CVE-2023-52237, CVE-2024-38278)
RUGGEDCOM RSG920P V4.X: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RSG920P V5.X: Versions prior to V5.9.0 (CVE-2023-52237, CVE-2024-38278)
RUGGEDCOM RSG920PNC V4.X: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RSG920PNC V5.X: Versions prior to V5.9.0 (CVE-2023-52237, CVE-2024-38278)
RUGGEDCOM RSG2100: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RSG2100 (32M) V4.X: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RSG2100 (32M) V5.X: Versions prior to V5.9.0 (CVE-2023-52237, CVE-2024-38278)
RUGGEDCOM RSG2100NC: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RSG2100NC(32M) V4.X: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RSG2100NC(32M) V5.X: Versions prior to V5.9.0 (CVE-2023-52237, CVE-2024-38278)
RUGGEDCOM RSG2100P: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RSG2100PNC: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RSG2200: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RSG2200NC: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RSG2288 V4.X: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RSG2288 V5.X: Versions prior to V5.9.0 (CVE-2023-52237, CVE-2024-38278)
RUGGEDCOM RSG2288NC V4.X: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RSG2288NC V5.X: Versions prior to V5.9.0 (CVE-2023-52237, CVE-2024-38278)
RUGGEDCOM RSG2300 V4.X: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RSG2300 V5.X: Versions prior to V5.9.0 (CVE-2023-52237, CVE-2024-38278)
RUGGEDCOM RSG2300NC V4.X: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RSG2300NC V5.X: Versions prior to V5.9.0 (CVE-2023-52237, CVE-2024-38278)
RUGGEDCOM RSG2300P V4.X: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RSG2300P V5.X: Versions prior to V5.9.0 (CVE-2023-52237, CVE-2024-38278)
RUGGEDCOM RSG2300PNC V4.X: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RSG2300PNC V5.X: Versions prior to V5.9.0 (CVE-2023-52237, CVE-2024-38278)
RUGGEDCOM RSG2488 V4.X: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RSG2488 V5.X: Versions prior to V5.9.0 (CVE-2023-52237, CVE-2024-38278)
RUGGEDCOM RSG2488NC V4.X: Versions prior to V4.3.10 (CVE-2023-52237)
RUGGEDCOM RSG2488NC V5.X: Versions prior to V5.9.0 (CVE-2023-52237, CVE-2024-38278)
RUGGEDCOM RSL910: Versions prior to V5.9.0 (CVE-2023-52237, CVE-2024-38278)
RUGGEDCOM RSL910NC: Versions prior to V5.9.0 (CVE-2023-52237, CVE-2024-38278)
RUGGEDCOM RST916C: Versions prior to V5.9.0 (CVE-2023-52237, CVE-2024-38278)
RUGGEDCOM RST916P: Versions prior to V5.9.0 (CVE-2023-52237, CVE-2024-38278)
RUGGEDCOM RST2228: Versions prior to V5.9.0 (CVE-2023-52237, CVE-2023-52238, CVE-2024-38278)
RUGGEDCOM RST2228P: Versions prior to V5.9.0 (CVE-2023-52237, CVE-2023-52238, CVE-2024-38278)
The web server of the affected devices allow a low privileged user to access hashes and password salts of all system's users, including admin users. An attacker could use the obtained information to brute force the passwords offline.
The web server of the affected systems leaks the MACSEC key in clear text to a logged in user. An attacker with the credentials of a low privileged user could retrieve the MACSEC key and access (decrypt) the ethernet frames sent by authorized recipients.
The affected products with IP forwarding enabled wrongly make available certain remote services in non-managed VLANs, even if these services are not intentionally activated. An attacker could leverage this vulnerability to create a remote shell to the affected system.
In some configurations, the affected products wrongly enable the Modbus service in non-managed VLANS. Only serial devices are affected by this vulnerability.
(CVE-2024-39675) RUGGEDCOM RS416Pv2 V5.X, RUGGEDCOM RS416v2 V5.X, RUGGEDCOM RS416NCv2 V5.X, RUGGEDCOM RS416PNCv2 V5.X: Update to V5.9.0 or later version
(CVE-2023-52238) RUGGEDCOM RST2228, RUGGEDCOM RST2228P: Update to V5.9.0 or later version
(CVE-2024-39675) RUGGEDCOM RS910L, RUGGEDCOM RS910LNC, RUGGEDCOM RS920L, RUGGEDCOM RS920LNC, RUGGEDCOM RS920W: Currently no fix is planned
(CVE-2023-52237) RUGGEDCOM RS900L, RUGGEDCOM RS900LNC, RUGGEDCOM RS910L, RUGGEDCOM RS910LNC, RUGGEDCOM RS920L, RUGGEDCOM RS920LNC, RUGGEDCOM RS920W, RUGGEDCOM RS930L, RUGGEDCOM RS930LNC, RUGGEDCOM RS930W, RUGGEDCOM RS969, RUGGEDCOM RS969NC: Currently no fix is planned
Siemens has identified the following specific workarounds and mitigations users can apply to reduce risk:
(CVE-2023-52237, CVE-2023-52238) Disable the webserver if not required on the affected systems. Restrict the access to Port 80/tcp and 443/tcp to trusted IP address only
(CVE-2024-38278) RUGGEDCOM RMC8388 V5.X, RUGGEDCOM RMC8388NC V5.X, RUGGEDCOM RS416NCv2 V5.X, RUGGEDCOM RS416PNCv2 V5.X, RUGGEDCOM RS416Pv2 V5.X, RUGGEDCOM RS416v2 V5.X, RUGGEDCOM RS900 (32M) V5.X, RUGGEDCOM RS900G (32M) V5.X, RUGGEDCOM RS900GNC(32M) V5.X, RUGGEDCOM RS900NC(32M) V5.X, RUGGEDCOM RSG2100 (32M) V5.X, RUGGEDCOM RSG2100NC(32M) V5.X, RUGGEDCOM RSG2288 V5.X, RUGGEDCOM RSG2288NC V5.X, RUGGEDCOM RSG2300 V5.X, RUGGEDCOM RSG2300NC V5.X, RUGGEDCOM RSG2300P V5.X, RUGGEDCOM RSG2300PNC V5.X, RUGGEDCOM RSG2488 V5.X, RUGGEDCOM RSG2488NC V5.X, RUGGEDCOM RSG907R, RUGGEDCOM RSG908C, RUGGEDCOM RSG909R, RUGGEDCOM RSG910C, RUGGEDCOM RSG920P V5.X, RUGGEDCOM RSG920PNC V5.X, RUGGEDCOM RSL910, RUGGEDCOM RSL910NC, RUGGEDCOM RST2228, RUGGEDCOM RST2228P, RUGGEDCOM RST916C, RUGGEDCOM RST916P: For CVE-2024-38278: Disable the IP Forwarding if not required on the affected system. Also note, the IP forwarding is disabled by default
(CVE-2024-39675) RUGGEDCOM RMC30, RUGGEDCOM RMC30NC, RUGGEDCOM RP110, RUGGEDCOM RP110NC, RUGGEDCOM RS400, RUGGEDCOM RS400NC, RUGGEDCOM RS401, RUGGEDCOM RS401NC, RUGGEDCOM RS416, RUGGEDCOM RS416NC, RUGGEDCOM RS416NCv2 V4.X, RUGGEDCOM RS416NCv2 V5.X, RUGGEDCOM RS416P, RUGGEDCOM RS416PNC, RUGGEDCOM RS416PNCv2 V4.X, RUGGEDCOM RS416PNCv2 V5.X, RUGGEDCOM RS416Pv2 V4.X, RUGGEDCOM RS416Pv2 V5.X, RUGGEDCOM RS416v2 V4.X, RUGGEDCOM RS416v2 V5.X, RUGGEDCOM RS910, RUGGEDCOM RS910L, RUGGEDCOM RS910LNC, RUGGEDCOM RS910NC, RUGGEDCOM RS910W, RUGGEDCOM RS920L, RUGGEDCOM RS920LNC, RUGGEDCOM RS920W: Disable the Modbus Server if not required on the affected system. Restrict the access to Port 502/tcp to trusted IP address only. Also note, Modbus is disabled by default
As a general security measure, Siemens recommends protecting network access to devices with appropriate mechanisms. To operate the devices in a protected IT environment, Siemens recommends configuring the environment according to Siemens' operational guidelines for industrial security and following recommendations in the product manuals.
For more information see the associated Siemens security advisory SSA-170375 in HTML and CSAF.
CISA recommends users take defensive measures to minimize the risk of exploitation of these vulnerabilities. CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.
Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.
No known public exploitation specifically targeting these vulnerabilities has been reported to CISA at this time.
Affected applications are vulnerable to command injection due to missing server side input sanitation when loading VxLAN configurations. This could allow an authenticated attacker to execute arbitrary code with root privileges.
Affected applications are vulnerable to command injection due to missing server side input sanitation when loading SNMP configurations. This could allow an attacker with the right to modify the SNMP configuration to execute arbitrary code with root privileges.
As a general security measure, Siemens recommends protecting network access to devices with appropriate mechanisms. To operate the devices in a protected IT environment, Siemens recommends configuring the environment according to Siemens' operational guidelines for industrial security and following recommendations in the product manuals.
Locate control system networks and remote devices behind firewalls and isolating them from business networks.
When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.
CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.
Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.
No known public exploitation specifically targeting these vulnerabilities has been reported to CISA at this time.
Successful exploitation of this vulnerability could allow an attacker to cause a type confusion and execute arbitrary code within the affected application.
3. TECHNICAL DETAILS
3.1 AFFECTED PRODUCTS
The following products of Siemens, are affected:
Totally Integrated Automation Portal (TIA Portal): All versions
Totally Integrated Automation Portal (TIA Portal) V18: All versions
Affected applications do not properly restrict the .NET BinaryFormatter when deserializing user-controllable input. This could allow an attacker to cause a type confusion and execute arbitrary code within the affected application. This is the same issue that exists for .NET BinaryFormatter https://docs.microsoft.com/enus/visualstudio/code-quality/ca2300.
Avoid uploading PLC software from untrusted devices or MMC cards
As a general security measure, Siemens recommends protecting network access to devices with appropriate mechanisms. To operate the devices in a protected IT environment, Siemens recommends configuring the environment according to Siemens' operational guidelines for industrial security and following recommendations in the product manuals.
Locate control system networks and remote devices behind firewalls and isolating them from business networks.
When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.
CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.
Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.
CISA also recommends users take the following measures to protect themselves from social engineering attacks:
Do not click web links or open attachments in unsolicited email messages.
No known public exploitation specifically targeting this vulnerability has been reported to CISA at this time. This vulnerability is not exploitable remotely.
The system service of affected applications is vulnerable to command injection due to missing server side input sanitation when loading VPN configurations. This could allow an authenticated local attacker to execute arbitrary code with system privileges.
The system service of affected applications is vulnerable to command injection due to missing server side input sanitation when loading proxy configurations. This could allow an authenticated local attacker to execute arbitrary code with system privileges.
The system service of affected applications is vulnerable to command injection due to missing server side input sanitation when loading VPN configurations. This could allow an administrative remote attacker running a corresponding SINEMA Remote Connect Server to execute arbitrary code with system privileges on the client system.
CRITICAL INFRASTRUCTURE SECTORS: Critical Manufacturing, Commercial Facilities, Energy, Food and Agriculture, Healthcare and Public Health, Transportation Systems, Water and Wastewater Systems
COUNTRIES/AREAS DEPLOYED: Worldwide
COMPANY HEADQUARTERS LOCATION: Germany
3.4 RESEARCHER
Siemens reported these vulnerabilities to CISA.
4. MITIGATIONS
Siemens has released a new version for SINEMA Remote Connect Client and recommends updating to version (V3.2 HF1 or later.
As a general security measure, Siemens recommends protecting network access to devices with appropriate mechanisms. To operate the devices in a protected IT environment, Siemens recommends configuring the environment according to Siemens' operational guidelines for industrial security and following recommendations in the product manuals.
For more information see the associated Siemens security advisory SSA-868282 in HTML and CSAF.
CISA recommends users take defensive measures to minimize the risk of exploitation of these vulnerabilities. CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.
Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.
No known public exploitation specifically targeting these vulnerabilities has been reported to CISA at this time.
Due to an improper input validation, an unauthenticated threat actor can send a malicious message to invoke a local or remote executable and cause a remote code execution condition on the affected device.
Due to an improper input validation, an unauthenticated threat actor can send a malicious message to invoke SQL injection into the program and cause a remote code execution condition on the affected device.
Due to an improper input validation, an unauthenticated threat actor can send a malicious message to a monitor thread within ThinServer and cause a denial-of-service condition on the affected device.
Rockwell Automation reported these vulnerabilities to CISA.
4. MITIGATIONS
Rockwell Automation has corrected the reported vulnerabilities in the following versions available at the ThinManager download site: 11.1.8, 11.2.9 12.0.7, 12.1.8, 13.0.5, 13.1.3, 13.2.2
Rockwell Automation recommends users of the affected software to apply the risk mitigations from the list below. Users are also recommended to implement Rockwell Automation's suggested security best practices to minimize the potential risk of vulnerability.
Locate control system networks and remote devices behind firewalls and isolating them from business networks.
When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.
CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.
Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.
No known public exploitation specifically targeting these vulnerabilities has been reported to CISA at this time.
CISA released twenty-one Industrial Control Systems (ICS) advisories on July 11, 2024. These advisories provide timely information about current security issues, vulnerabilities, and exploits surrounding ICS.
Vulnerabilities: Incorrect User Management, Unrestricted Upload of File with Dangerous Type, Forced Browsing, Improper Check for Unusual or Exceptional Conditions, Client-Side Enforcement of Server-Side Security, Incorrect Authorization, Creation of Temporary File With Insecure Permissions, Improper Restriction of Excessive Authentication Attempts, Incorrect Permission Assignment for Critical Resource, Allocation of Resources Without Limits or Throttling
2. RISK EVALUATION
Successful exploitation of these vulnerabilities could allow an attacker to cause a denial-of service condition, learn vulnerable credentials, escalate privileges, modify users outside of scope, gain access to participant groups, use temporary credentials for authentication bypass, or execute arbitrary code.
3. TECHNICAL DETAILS
3.1 AFFECTED PRODUCTS
The following products of Siemens, are affected:
Siemens SINEMA Remote Connect Server: All versions prior to V3.2 SP1
The affected application creates temporary user credentials for UMC (User Management Component) users. An attacker could use these temporary credentials for authentication bypass in certain scenarios.
The affected application allows users to upload encrypted backup files. As part of this backup, files can be restored without correctly checking the path of the restored file. This could allow an attacker with access to the backup encryption key to upload malicious files, that could potentially lead to remote code execution.
The affected application allows users to upload encrypted backup files. This could allow an attacker with access to the backup encryption key and with the right to upload backup files to create a user with administrative privileges.
Affected devices do not properly validate the authentication when performing certain actions in the web interface allowing an unauthenticated attacker to access and edit device configuration information of devices for which they have no privileges.
Affected devices do not properly validate the authentication when performing certain actions in the web interface allowing an unauthenticated attacker to access and edit VxLAN configuration information of networks for which they have no privileges.
Affected products allow to upload certificates. An authenticated attacker could upload a crafted certificates leading to a permanent denial-of-service situation. In order to recover from such an attack, the offending certificate needs to be removed manually.
The affected applications can be configured to allow users to manage own users. A local authenticated user with this privilege could use this modify users outside of their own scope as well as to escalate privileges.
Affected applications do not properly separate the rights to edit device settings and to edit settings for communication relations. This could allow an authenticated attacker with the permission to manage devices to gain access to participant groups that the attacked does not belong to.
The affected application does not properly assign rights to temporary files created during its update process. This could allow an authenticated attacker with the 'Manage firmware updates' role to escalate their privileges on the underlying OS level.
The affected application does not properly implement brute force protection against user credentials in its web API. This could allow an attacker to learn user credentials that are vulnerable to brute force attacks.
The affected application does not properly implement brute force protection against user credentials in its Client Communication component. This could allow an attacker to learn user credentials that are vulnerable to brute force attacks.
The affected application allows authenticated, low privilege users with the 'Manage own remote connections' permission to retrieve details about other users and group memberships.
Affected applications do not properly handle log rotation. This could allow an unauthenticated remote attacker to cause a denial of service condition through resource exhaustion on the device.
Siemens has identified the following specific workarounds and mitigations users can apply to reduce risk:
SINEMA Remote Connect Server: Update to V3.2 SP1 or later version
As a general security measure, Siemens recommends protecting network access to devices with appropriate mechanisms. To operate the devices in a protected IT environment, Siemens recommends configuring the environment according to Siemens' operational guidelines for industrial security and following recommendations in the product manuals.
Locate control system networks and remote devices behind firewalls and isolating them from business networks.
When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs). Recognize VPNs may have vulnerabilities, should be updated to the most recent version available, and are only as secure as the connected devices.
CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.
Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.
CISA also recommends users take the following measures to protect themselves from social engineering attacks:
Do not click web links or open attachments in unsolicited email messages.
Vulnerabilities: Out-of-bounds Read, Out-of-bounds Write, Type Confusion, Improper Restriction of Operations within the Bounds of a Memory Buffer, Stack-based Buffer Overflow
2. RISK EVALUATION
Successful exploitation of these vulnerabilities could allow an attacker to execute code in the context of the current process.
The affected applications contain an out of bounds read past the end of an allocated structure while parsing specially crafted IGS files. This could allow an attacker to execute code in the context of the current process.
The affected application contains an out of bounds write past the end of an allocated buffer while parsing a specially crafted IGS part file. This could allow an attacker to execute code in the context of the current process.
The affected application contains a type confusion vulnerability while parsing IGS files. This could allow an attacker to execute code in the context of the current process.
The affected application is vulnerable to memory corruption while parsing specially crafted IGS files. This could allow an attacker to execute code in the context of the current process.
The affected applications contain an out of bounds read past the end of an allocated structure while parsing specially crafted IGS files. This could allow an attacker to execute code in the context of the current process.
The affected applications contain an out of bounds read past the end of an allocated structure while parsing specially crafted IGS files. This could allow an attacker to execute code in the context of the current process.
The affected applications contain an out of bounds read past the end of an allocated structure while parsing specially crafted IGS files. This could allow an attacker to execute code in the context of the current process.
The affected application contains a type confusion vulnerability while parsing IGS files. This could allow an attacker to execute code in the context of the current process.
The affected application contains a type confusion vulnerability while parsing IGS files. This could allow an attacker to execute code in the context of the current process.
The affected applications contain an out of bounds read past the end of an allocated structure while parsing specially crafted IGS files. This could allow an attacker to execute code in the context of the current process.
The affected applications contain an out of bounds read past the end of an allocated structure while parsing specially crafted IGS files. This could allow an attacker to execute code in the context of the current process.
The affected applications contain an out of bounds read past the end of an allocated structure while parsing specially crafted IGS files. This could allow an attacker to execute code in the context of the current process.
The affected applications contain a stack overflow vulnerability while parsing specially strings as argument for one of the application binaries. This could allow an attacker to execute code in the context of the current process.
The affected applications contain an out of bounds read past the end of an allocated structure while parsing specially crafted BMP files. This could allow an attacker to execute code in the context of the current process.
The affected applications contain an out of bounds read past the end of an allocated structure while parsing specially crafted BMP files. This could allow an attacker to execute code in the context of the current process.
Siemens has identified the following specific workarounds and mitigations users can apply to reduce risk:
Do not open untrusted IGS, BDF or BMP files using Simcenter Femap
As a general security measure, Siemens recommends protecting network access to devices with appropriate mechanisms. To operate the devices in a protected IT environment, Siemens recommends configuring the environment according to Siemens' operational guidelines for industrial security and following recommendations in the product manuals.
Locate control system networks and remote devices behind firewalls and isolating them from business networks.
When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs). Recognize VPNs may have vulnerabilities, should be updated to the most recent version available, and are only as secure as the connected devices.
CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.
Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.
CISA also recommends users take the following measures to protect themselves from social engineering attacks:
Do not click web links or open attachments in unsolicited email messages.
No known public exploitation specifically targeting these vulnerabilities has been reported to CISA at this time. These vulnerabilities are not exploitable remotely.
In early 2023, the Cybersecurity and Infrastructure Security Agency (CISA) conducted a SILENTSHIELD red team assessment against a Federal Civilian Executive Branch (FCEB) organization. During SILENTSHIELD assessments, the red team first performs a no-notice, long-term simulation of nation-state cyber operations. The team mimics the techniques, tradecraft, and behaviors of sophisticated threat actors and measures the potential dwell time actors have on a network, providing a realistic assessment of the organization’s security posture. Then, the team works directly with the organization’s network defenders, system administrators, and other technical staff to address strengths and weaknesses found during the assessment. The team’s goal is to assist the organization with refining their detection, response, and hunt capabilities—particularly hunting unknown threats.
In coordination with the assessed organization, CISA is releasing this Cybersecurity Advisory (CSA) detailing the red team’s activity and tactics, techniques, and procedures (TTPs); associated network defense activity; and lessons learned to provide network defenders with recommendations for improving their organization’s detection capabilities and cyber posture.
During the first phase, the SILENTSHIELD team gained initial access by exploiting a known vulnerability in an unpatched web server in the victim’s Solaris enclave. Although the team fully compromised the enclave, they were unable to move into the Windows portion of the network due to a lack of credentials. In a parallel effort, the team gained access to the Windows network through phishing. They then discovered unsecured administrator credentials, allowing them to pivot freely throughout the Windows environment, which resulted in full domain compromise and access to tier zero assets. The team then identified that the organization had trust relationships with multiple external partner organizations and was able to exploit and pivot to an external organization. The red team remained undetected by network defenders throughout the first phase.
The red team’s findings underscored the importance of defense-in-depth and using diversified layers of protection. The organization was only able to fully understand the extent of the red team’s compromise by running full diagnostics from all data sources. This involved analyzing host-based logs, internal network logs, external (egress) network logs, and authentication logs.
The red team’s findings also demonstrated the value of using tool-agnostic and behavior-based indicators of compromise (IOCs) and of applying an “allowlist” approach to network behavior and systems, rather than a “denylist” approach, which predominantly results in an unmanageable amount of noise. The red team’s findings illuminated the following lessons learned for network defenders about how to reduce and respond to risk:
Lesson learned: The assessed organization had insufficient controls to prevent and detect malicious activity.
Lesson learned: The organization did not effectively or efficiently collect, retain, and analyze logs.
Lesson learned: Bureaucratic processes and decentralized teams hindered the organization’s network defenders.
Lesson learned: A “known-bad” detection approach hampered detection of alternate TTPs.
To reduce risk of similar malicious cyber activity, CISA encourages organizations to apply the recommendations in the Mitigations section of this advisory, including those listed below:
Apply defense-in-depth principles by using multiple layers of security to ensure comprehensive analysis and detection of possible intrusions.
Use robust network segmentation to impede lateral movement across the network.
Establish baselines of network traffic, application execution, and account authentication. Use these baselines to enforce an “allowlist” philosophy rather than denying known-bad IOCs. Ensure monitoring and detection tools and procedures are primarily behavior-based, rather than IOC-centric.
CISA recognizes that insecure software contributes to these identified issues and urges software manufacturers to embrace Secure by Design principles and implement the recommendations in the Mitigations section of this CSA, including those listed below, to harden customer networks against malicious activity and reduce the likelihood of domain compromise:
Eliminate default passwords.
Provide logging at no additional charge.
Work with security information and event management (SIEM) and security orchestration, automation, and response (SOAR) providers—in conjunction with customers—to understand how response teams use logs to investigate incidents.
CISA has authority to hunt for and identify, with or without advance notice to or authorization from agencies, threats and vulnerabilities within federal information systems (see generally 44 U.S.C. § 3553[b][7]). The target organization for this assessment was a large U.S. FCEB organization. CISA conducted the SILENTSHIELD assessment over an approximately eight-month period in 2023, with three of the months consisting of a technical collaboration phase:
Adversary Emulation Phase: The teamstarted byemulating a sophisticated nation-state actor by simulating known initial access and post-exploitation TTPs. The team’s goal was to compromise the assessed organization’s domain and identify attack paths to other networks. After completion of their initial objectives, the team diversified its deployed tools and tradecraft to mimic a wider and often less sophisticated set of threat actors to elicit network defender attention. CISA red team members did not clean up or delete system logs, allowing defenders to investigate all artifacts and identify the full scope of a breach.
Collaboration Phase: The SILENTSHIELD team met regularly with senior staff and technical personnel to discuss issues with the organization’s cyber defensive capabilities. During this phase, the team:
Proposed new behavior-based and tool-agnostic detections to uncover additional tradecraft used during the Adversary Emulation Phase. They also evaluated the organization’s improvements according to current CISA priorities and public guidance.
Troubleshot existing detection steps to show how certain TTPs evaded IOC-based detections.
Deconflicted events from CISA red team activity, indicating unexpected network/application behavior or the potential presence of a real adversary in the network.
Note: The team’s goal during this phase was to build the organization’s ability to detect malicious activity based on adversary behavior (i.e., TTPs) vice relying on known IOCs.
This advisory, drafted in coordination with the assessed organization, details the red team’s activity and TTPs, associated network defense activity, and lessons learned to provide network defenders recommendations for improving their organization’s defensive cyber posture. The advisory also provides recommendations to software manufacturers to harden their customer networks against malicious activity and reduce the likelihood of domain compromise.
TECHNICAL DETAILS
Note: This advisory uses the MITRE ATT&CK for Enterprise framework, version 15. See the MITRE ATT&CK Tactics and Techniques section for a table of the threat actors’ activity mapped to MITRE ATT&CK® tactics and techniques. 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.
During the Adversary Emulation phase, the red team gained initial access to the organization’s Solaris enclave by exploiting a known vulnerability in an unpatched web server. They gained separate access to the Windows environment by phishing and were able to compromise the full domain and its parent domain. See Figure 1 for a timeline of this assessment and the sections below for details on the team’s activity and TTPs.
Figure 1: SILENTSHIELD assessment timeline
Adversary Emulation Phase
Exploitation of the Solaris Enclave
Reconnaissance, Initial Access, and Command and Control
CISA’s red team used open source tools and third-party services to probe the organization’s internet-facing surface [T1594]. This included non-intrusive port scans for common ports and Domain Name System (DNS) enumeration [T1590.002]. These efforts revealed the organization’s web server was unpatched for CVE-2022-21587, an unauthenticated remote code execution (RCE) vulnerability in Oracle Web Applications Desktop Integrator. For three months the assessed organization failed to patch this vulnerability, and the team exploited it for initial access.
The exploit provided code execution on a backend application server (SERVER 1) that handled incoming requests from the public-facing web server. The red team used this exploit to upload and run a secure Python remote access tool (RAT). Because the application server had full external internet egress via Transmission Control Protocol (TCP) ports 80 and 443, the RAT enabled consistent command and control (C2) traffic [T1071.001].
Note: After gaining access, the team promptly informed the organization’s trusted agents of the unpatched device, but the organization took over two weeks to apply the available patch. Additionally, the organization did not perform a thorough investigation of the affected servers, which would have turned up IOCs and should have led to a full incident response. About two weeks after the team obtained access, exploit code was released publicly into a popular open source exploitation framework. CISA identified that the vulnerability was exploited by an unknown third party. CISA added this CVE to its Known Exploited Vulnerabilities Catalog on Feb. 2, 2023.
Credential Access, Command and Control, and Privilege Escalation
Once on SERVER 1, the red team probed the host’s files and folder structure [T1005] and identified several old and globally accessible .tar backup files, which included a readable copy of an /etc/shadow file containing the hash for a privileged service account (ACCOUNT 1). The team quickly cracked the account’s weak password using a common wordlist [T1110.002]. They then established an outbound Secure Shell Protocol (SSH) connection over TCP port 80 and used a reverse tunnel to SSH back into SERVER 1, where they were prompted to reset ACCOUNT 1’s expired password [T1571] (see Figure 2). The team identified the account was enabled on a subset of containers, but it had not been actively used in a significant amount of time; the team changed this account’s password to a strong password.
Figure 2: Exploitation of the Solaris Enclave
The team discovered ACCOUNT 1 was a local administrator with sudo/root access and used it to move laterally (see the next section).
Lateral Movement and Persistence
Servers in the Solaris enclave did not use centralized authentication but had a mostly uniform set of local accounts and permissions [T1078.002]. This allowed the red team to use ACCOUNT 1 to move through much of the network segment via SSH [T1021.004].
Some servers allowed external internet access and the team deployed RATs on a few of these hosts for C2. They deployed several different RATs to diversify network traffic signatures and obfuscate the on-disk and in-memory footprints. These tools communicated to a red team redirector over TCP/443, through valid HTTPS messages, and over SSH through non-standard ports (80 and 443) [T1571]. Much of the traffic was not blocked by a firewall, and the organization lacked application layer firewalls capable of detecting protocol mismatches on common ports.
The team then moved laterally to multiple servers, including high value assets, that did not allow internet access. Using reverse SSH tunnels, the team moved into the environment and used a SOCKS proxy [T1090] to progress forward through the network. They configured implants with TCP bind listeners bound to random high ports to connect directly with some of these hosts without creating new SSH login events (see Figure 3).
Figure 3: Example of Lateral Movement in the Solaris Enclave
Once on other internal hosts, the team data mined each for sensitive information and credentials. They obtained personally identifiable information (PII), shadow files, a crackable pass-phrase protected administrator SSH key, and a plaintext password [T1552.003] in a user’s .bash_history. These data mined credentials provided further avenues for unprivileged access through the network. The team also used SSH tunnels to remotely mount Network File System (NFS) file shares, spoofing uid and gid values to access all files and folders.
To protect against reboots or other disruptions, the team primarily persisted on hosts using the cron utility [T1053.003], as well as the at utility [T1053.002], to run scheduled tasks and blend into the environment. Additionally, SSH private keys provided persistent access to internal pivot hosts and would have continued to enable access even if passwords were rotated.
Full Enclave Compromise
Although ACCOUNT 1 allowed the team to move laterally to much of the Solaris enclave, the account did not provide privileged access to all hosts in the network because a subset of hosts had changed the password (which denied privileged access via that account). However, the team analyzed recent user logins using the last command and identified a network security appliance scanning service account (ACCOUNT 2) that logged in regularly to an internal host using password-based authentication. As part of its periodic vulnerability scanning, ACCOUNT 2 would connect to each host via SSH and run sudo with a relative path instead of the absolute path /usr/local/bin/sudo. The local path created a path hijack vulnerability, which allowed the red team to hijack the execution flow and capture the account’s password [T1574.007].
The harvested password granted unrestricted privileged access to the entire Solaris enclave.
Exploitation of the Windows Domain
While the compromise of the Solaris enclave facilitated months of persistent access to sensitive systems, including web applications and databases, it did not lead to the immediate compromise of the corporate Windows environment. Once in the Windows domain, the red team identified several service accounts with weak passwords. It is likely that an adversary could have continued the Solaris attack path through prolonged password spraying attacks, or by leveraging credentials obtained externally (e.g., dark web credential dumps) (see Figure 4).
Figure 4: Exploitation of Solaris enclave
The team exploited the Windows domain through other access vectors and eventually proved the undetected pivot between the domains could be made after they obtained Windows credentials.
Reconnaissance and Initial Access
While attempting to pivot into Windows from Solaris, the red team conducted open source information gathering about the organization. They harvested employee names [T1589.003] and used the information to derive email addresses based on the target’s email naming scheme. After identifying names, emails, and job titles, the team selected several phishing targets who regularly interacted with the public [T1591.004]. One user triggered a phishing payload that provided initial access to a workstation.
The team then placed a simple initial access RAT on the workstation in a user-writable folder and obtained user-level persistence through an added registry run key, which called back to a red team redirector via HTTPS. The team assessed what was running on the host in terms of antivirus (AV) and Endpoint Detection and Response (EDR) and used the implant to inject a more capable, full-fledged RAT directly into memory, which pointed to a separate redirector. The assessed organization’s tools failed to categorize C2 traffic as anomalous even when a bug in one of the implants caused 8 GB of continuous network traffic to flow in one afternoon.
Credentialed Access and Privilege Escalation
Internal network information was freely available to unprivileged, domain-joined users, and the team queried hundreds of megabytes of Active Directory (AD) data using a custom rewrite of dsquery.exe in .NET and Beacon Object File (BOF) ldapsearch from the phished user’s workstation. The team then data mined numerous internal file servers for accessible shares [T1083]. The team found a password file left from a previous employee on an open, administrative IT share, which contained plaintext usernames and passwords for several privileged service accounts. With the harvested Lightweight Directory Access Protocol (LDAP) information, the team identified one of the accounts (ACCOUNT 3) had system center operations manager (SCOM) administrator privileges and domain administrator privileges for the parent domain. They identified another account (ACCOUNT 4) that also had administrative permissions for most servers in the domain. The passwords for both accounts had not been updated in over eight years and were not enrolled in the organization’s identity management (IDM).
Lateral Movement and Persistence
The team used valid accounts and/or tokens with varied techniques for lateral movement. Techniques included scheduled task manipulation, service creation, and application domain hijacking [T1574.014]. For credential usage, the implemented IDM in the organization’s network hampered the red team’s ability to pivot as it blocked common credential manipulation techniques like pass-the-hash [T1550.002] and pass-the-ticket [T1550.003]. The red team found ways to circumvent the IDM, including using plaintext passwords to create genuine network logon sessions [T1134.003] for certain accounts not registered with the IDM, as well as impersonating the tokens of currently logged-in users to piggyback off valid sessions [T1134.001].
The red team tailored payloads to blend with the network’s environment and did not reuse IOCs like filenames or file hashes, especially for persisted implants. Remote queries for directory listings, scheduled tasks, services, and running processes provided the information for the red team to masquerade as legitimate activity [T1036.004].
The team emulated normal network activity by installing HTTPS beaconing agents on workstations where normal users browse the web, establishing internal network pivots with TCP bind and SMB listeners. They primarily relied on creating Windows services as their persistence mechanism.
The red team used the data mined credentials for ACCOUNT 3 to move laterally from the workstation to a SCOM server. Once there, using ACCOUNT 4, the team targeted a Systems Center Configurations Manager (SCCM) server, as it was an advantageous network vantage point. The SCCM server had existing logged-in server administrators whose usernames followed a predictable naming pattern (correlating administrative roles and privilege levels), allowing them to determine which account to use to pivot to other hosts.
The team targeted the organization’s jump servers frequented by highly privileged administrative accounts. Red team operators used stolen SCCM server administrator credentials to compromise one of the organization’s server-administrator jump hosts. They learned that the organization separated some, but not all, accounts onto separate jump servers by role (e.g., workstation administrators and server administrators had separate jump points, but server and domain administrators occasionally shared the same jump hosts). Once a domain administrator logged in, the red team stole the administrator’s session token and laterally moved to a domain controller where they pulled credentials for the entire domain via DCSync [T1003.006], obtaining full domain compromise (see Figure 5).
Figure 5: Exploitation of the Windows Domain
After compromising the domain, the team confirmed access to sensitive servers, including multiple high value assets (HVAs) and tier zero assets. None of the accessed servers had any noticeable additional protections or network access restrictions despite their sensitivity and critical functions in the network. Remote administration and access of these critical systems should be restricted to designated, role-based accounts coming from specific network enclaves and/or workstations. Isolation with these access vector limitations protects them from compromise and sharply reduces the associated noise, allowing defenders to more easily identify abnormal behavior.
Pivoting Into External Trusted Partners
The team inspected the organization’s trust relationships with other organizational domains through LDAP [T1482] and identified connections to multiple external FCEB partner organizations, one of which they subsequently used to move laterally.
The team pulled LDAP information from PARTNER DC 1 and kerberoasted the domain, yielding one valid service account with a weak password they quickly cracked, but the team was unable to move laterally with this account because it lacked appropriate privileges. However, PARTNER 1 had trusted relationships with a second partner’s domain controller (PARTNER DC 2). Using the acquired PARTNER 1 credentials, the red team discovered PARTNER 2 also had a kerberoastable, highly privileged administrative service account whose password cracked, allowing the team to laterally move to a PARTNER 2 host from the original victim network (see Figure 6).
figure 6: path of exploitation into external fceb organizations
These cross-organizational attack paths are rarely identified or tested in regular assessments or audits due to network ownership, legal agreements, and/or vendor opacity. However, they remain a valuable access vector for advanced persistent threat (APT) actors.
Experimentation with access into trusted partner domains included the modification of local system firewall rules on the source domain controller to allow specific source and destination IPs. The organization’s host-based monitoring systems failed to identify the addition and removal of the red team’s firewall exceptions.
Defense Evasion Techniques
Solaris Enclave Figure 5: Exploitation of the Windows Domain
Due to the lack of application allowlisting, the red team regularly masqueraded as legitimate software to remain undetected by the organization’s network defenders [T1036]. Additionally, by default, command auditing in Solaris via the lastcomm command only captures the program being run—full file path and any command line arguments are not recorded. For example:
A real file: /opt/splunkforwarder/bin/splunkd
A malicious copy: /opt/splunkforwarder/splunkd
Command auditing logs: splunkd
The team also hid common artifacts to obfuscate their operational activity, including modifying file timestamps [T1070.006] and permissions with the touch and chmod/chown commands [T1222.002] to blend with other files in the environment.
Windows Domain
The team used a diverse range of accounts, backdoors, and C2 channels with different network footprints to obfuscate activity [T1027].
Diversification of account usage, backdoors, and C2 channels further obfuscated red team activity in the domain. Lateral movement to new hosts featured a variety of accounts to reduce the risk of detection. When harvesting credentials, the team selected several backup accounts for each role (e.g., server admin, workstation admin, domain admin, service accounts) in case the intended account was locked, disabled, or flagged as compromised.
To emphasize the value of tool-agnostic/behavior-based detections, the red team deployed over seven different implants to mimic real-world adversaries’ diverse use of open source, commercial off-the-shelf (COTS), and custom RATs. Each featured different host and network signatures to evade out-of-the-box EDR detections and every implant had unique artifacts both on-disk and in-memory. The team also evaded EDR/AV by using proprietary loaders and beacon object files (BOFs) to make direct API calls and allow self-injection of .NET executables to run additional capabilities.
All the deployed tools had different network C2 channel footprints. Some beaconing agents connected via HTTPS to legitimate domains owned by the red team. Others used domain fronting [T1090.004] to leverage common content delivery network (CDN) functionality. Outbound traffic sent to public websites not owned by the red team had a Host header that told the CDN provider it should redirect traffic to red-team-controlled IP addresses. Internal pivots used SMB on port 445 and TCP bind listeners on ephemeral high ports. The team tailored both to mimic named pipes and network connections already seen in the domain and evade detection.
Collaborative Phase
Five months into the assessment, the red team officially notified the organization’s security operations center (SOC) of the ongoing activity and began engaging directly with SOC leadership. At this point, the organization had not submitted deconflictions and did not appear to be actively investigating CISA SILENTSHIELD assessment activity.
During this phase, CISA refrained from providing TTPs or IOCs (such as concrete hosts, filenames, or C2 domains) to allow the organization to develop and test its own detection metrics. The team held weekly discussions with the organization’s senior technical staff, SOC, and system administrators, which led to measurable improvements in response times for known techniques and behavior-based detections that uncovered previously unknown tradecraft. Specifically, the red team worked with the organization to assist them with synthesizing the following data sources to identify the extent of the red team’s compromise:
EDR alerts;
YARA scans;
C2 domains and techniques;
Internal pivot hosts;
Admin accounts used to pivot;
Memory dumps, revealing attempts to pass credentials; and
Email logs documenting the initial breach via phishing.
Every cyber threat actor has a unique set of TTPs. Nevertheless, nearly all adversaries perform the same basic steps:
Command execution (initial access and lateral movement);
Establish C2 channels and exfiltrate data;
Establish persistence;
Escalate privileges; and
Use and abuse credentials.
All TTPs have corresponding artifacts, but not all IOCs are created equal. Fixating on a hyper-focused set of IOCs can catch known threats but impedes efforts to identify unknown adversaries employing different TTPs.
Major themes discussed during this phase that improved the organization’s behavior-based detection capabilities included log collection, forensic analysis, relying on IOCs for detection, monitoring and investigation management, and Sysmon misconfigurations.
Log Collection
The assessed organizations had ineffective and insufficient logs, and network defenders were not using logs to proactively detect anomalous behavior. With the red team’s assistance, the organization identified logging issues caused by hardware failures, limited backups, network bandwidth, and limited log collection and retention policies (only 60–90 days). In other cases, critical data was captured but not analyzed because artifacts were moved to cold storage.
The organization’s network defenders identified procedural and other roadblocks when attempting to acquire new forensic data. For example, affected servers could not be taken offline for imaging because there was no process in place to do so without impacting the organization’s operations. Additionally, attempts to capture forensic data via packet captures occurred directly on the compromised Solaris and Windows hosts, where the red team observed the data being collected and therefore had the opportunity to disrupt collection, tamper with evidence files, and better adapt and evade their defenses.
Forensic Analysis
Defenders did not monitor C2 egress via DNS. They believed their parent entity was monitoring their DNS traffic, absolving them of a need to collect and monitor logs for their analyses.
Forensic analysts blindly trusted the timestamps for files and persistence mechanisms without realizing they had been tampered with. Bogus times added to persistence mechanisms (such as scheduled tasks) led defenders to misjudge the timeline of the breach. Red team operators regularly adjusted the last-modified timestamp of files and folders—using either the native touch -r command or implants’ timestomp command to disguise the last-modified timestamp captured in the output of ls –la. Secondary file timestamps identified with ls -lu or ls -lc would have revealed abnormal file attributes, in addition to more reliable anomalies found during proper forensic investigation.
Reliance on Known IOCs
The red team used diversified TTPs in the Adversary Emulation phase to reflect the ability of cyber threat actors to bypass conventional, known-bad detection strategies. The network defenders did not detect much of the team’s activity. For example:
After identifying a red team payload, network defenders wrote tailored YARA rules that signatured specific behavior of the red team’s loader, which uncovered several similar payloads but failed to catch any of the other six C2 frameworks.
Organization network defenders used a combination of custom and open source detection rules (such as CommandLine=kerberoast* or files called bloodhound.zip) and did not detect the team’s kerberoasting activity.
Regular Monitoring and Investigation Management
Conversations with SOC leadership revealed several procedural issues that led to slow or incomplete analysis of the red team’s intrusion and activity. For example:
While EDR products detected and quarantined several of the red team’s tools, including the initial phishing payload, the organization’s daily procedures did not always include review of EDR alerts. The red team worked with the organization to ensure rapid response to EDR alerts became a fundamental part of network defenders’ daily workflows. This allowed SOC personnel to identify new attempts at lateral movement.
Solaris network owners discovered that several firewalls had inadvertently been misconfigured or disabled. The organization’s technical teams worked directly with the red team to fix errors and to reorganize and revalidate the network topology.
Network defenders had poor operational security and alerted the red team of investigations. For example:
In one instance, after receiving incoming beacons from what was evidently a sandboxed environment, the payload was not renamed from its original file, allowing the red team to immediately identify how much of their access was under scrutiny. Organizations must ensure sandboxed environments are safe, secure, and thoroughly sandboxed.
The red team observed system administrators reviewing forensic artifacts tied to the team’s Solaris payload—searching for files, running packet captures for outbound C2 traffic, and port scanning the C2 redirector. Team members simply reinstalled their persistence with a new redirector and file path, sidestepping the informal investigation.
IT teams were siloed from the SOC, who had no knowledge of the system administrator’s weeks long investigation into the anomalous network behavior.
While the organization compartmented most of its threat hunting and incident response in a separate domain, staff still used the compromised corporate domain accounts to communicate the details of active investigations and assessments.
Sysmon Misconfigurations
The red team had a productive exchange with the organization on their Sysmon configuration, which the team abused throughout the assessment. The red team identified several misconfigurations:
Deployment teams pushed the ruleset (stored as a .xml file) to a globally readable C:\Windows directory. There were no rules in place to catch adversaries reading the configurations from disk or the registry. As a result, CISA’s red team was provided explicit file paths to safely place their payloads.
Rules targeted a single, tool-specific IOC rather than a technique (e.g., sc.exe rather than service creation events).
Exceptions were overly permissive (for example, excluding all Image entries anywhere in C:\Program Files (x86)\Google\Update\*).
LESSONS LEARNED AND KEY FINDINGS
The red team noted the following lessons learned and key findings relevant to the security of the assessed organization’s network. These specific findings contributed to the team’s ability to gain persistent access across the organization’s network. See the Mitigations section for recommendations on how to address these findings.
Lesson Learned: The assessed organization had insufficient controls to prevent and detect malicious activity.
Finding #1: The organization’s perimeter network was not adequately firewalled from its internal network, which failed to restrict outbound traffic. A majority of the organization’s hosts, including domain controllers, had internet connectivity to broad AWS EC2 ranges, allowing the red team to make outbound web requests without triggering IDS/IPS responses. These successful connections revealed the lack of an application layer firewall capable of detecting protocol mismatches on common ports.
Finding #2: The assessed organization had insufficient network segmentation.The lack of network segmentation allowed the red team to move into, within, and out of both the Solaris and Windows domain. This also enabled them to gather a massive amount of data about the organization and its systems. Internal servers could reach almost any other domain host, regardless of type (server vs. workstation), purpose (user laptop, file server, IDM server, etc.), or physical location. Use of network address translation (NAT) between different parts of the network further obfuscated data streams, hindering incident response.
Finding #3: The organization had trust relationships with multiple partner organizations, which—when combined with weak credentials and network connectivity—allowed the red team to exploit and move laterally to a partner domain controller. This highlights the risk of blindly allowing third party network connectivity and the importance of regularly monitoring both privileged access and transitive trusted credential material.
Finding #4: The organization’s defensive staff did not sufficiently isolate their defensive investigative activity. Organizations should always communicate information pertaining to suspected incidents out-of-band, rather than from within a domain that they know to be compromised. While the defensive systems were shunted to another domain with correct (one-way) trusts, the red team identified a likely attack vector to that domain via the same, previously compromised IDM server. Some analysts also performed dynamic analysis of suspected implants from an internet-connected sandbox, tipping the red team to the specific files and hosts that were under investigation.
Finding #5: Network defenders were not familiar with the intricacies of their IDM solution. The CISA red team identified accounts not enrolled in the IDM and successfully used those and already existing user access tokens to bypass IDM. The appliance, in its active configuration, was not exhaustively tested against common credential manipulation techniques nor were any alerts on anomalous behavior being monitored.
Finding #6: The organization had some role-based host segmentation, but it was not granular enough. The organization used clearly defined roles (server administrator and domain administrator) but did not sufficiently segregate the accounts to their own servers or systems, enabling privilege escalation.
Lesson Learned: The organization did not effectively or efficiently collect, retain, and analyze logs.
Finding #7: Defensive analysts did not have the information they needed due to a combination of issues with collecting, storing, and processing logs. Other policies collected too much useless data, generating noise and slowing investigation.
Finding #8: Network defenders’ daily procedures did not always include analysis of EDR alerts, and the tools that were installed only provided a 30-day retention for quarantined files. Consequently, investigators were unable to access timely information that may have led to earlier detection of the red team’s activity.
Finding #9: Forensic analysts trusted host artifacts that could have been modified by an adversary. In particular, file timestamps and packet captures were scrutinized without considering the possibility of malicious tampering.
Lesson Learned: Bureaucratic communication and decentralized teams hindered the organization’s network defenders.
Finding #10: The organization’s technical staff were spread across decentralized teams. Siloed team structure meant that IT, security, and other technical teams lacked consistency with their tools, creating too much noise for defenders to sift through.
Finding #11: The SOC team lacked the agency to rapidly update or deploy rulesets through the fractured IT teams. The organization diffused responsibility for individual tools, such as Sysmon, across multiple groups, hampering timeliness and maintenance of a defensive posture.
Finding #12: The organization’s forensics team produced an incident response report which documented the red team’s initial exploitation of the Solaris enclave. However, the report was limited in scope and did not adequately document the red team’s ability to expand and persist. The success of the red team’s first phase, using publicly known TTPs, illustrated the business risk to all Solaris hosts and, by extension, the Windows environment. Moreover, the organization’s internal report only focused on vulnerable servers and did not account for a cyber threat actor’s ability to expand and persist in the Solaris enclave.
The Solaris administrator’s investigations of the red team failed to appear in either the report or in SOC deconflictions. An admin’s inquiry into unusual and probably malicious activity, particularly in the middle of an investigation of confirmed breaches of adjacent hosts, should have been considered in the report as evidence of lateral movement.
Lesson Learned: A “known-bad” detection approach hampered detection of alternate TTPs.
Finding #13: Defenders hyper-focused on specific IOCs, such as file attributes, particular C2 frameworks, or C2 domains. The organization’s network defenders did not initially employ tool-agnostic detections, causing them to positively identify some red team tools, but remain blind to the full extent of the compromise. They were accustomed to catching internal red teams that used specific TTPs; introducing a new “threat actor” with new TTPs sidestepped nearly all detections.
Finding #14: Detection rules were visible from compromised systems, allowing the red team to sidestep detections based on hardcoded rules and exceptions.
Finding #15: There was insufficient restriction of administrative tools. The technical staff lacked a standardized set of administrative tools, leaving all remote administration protocols available for use by admins, CISA red team, or adversaries. This also created excessive noise for defenders to effectively sift through to determine expected versus anomalous activity.
Finding #16: There was insufficient tracking of software. There was no apparent approval or tracking process for software installation across the domain, preventing defensive analysts from identifying abnormal software placed by the red team. A comprehensive inventory of approved software would help defenders identify abnormal behavior and facilitate the deployment of application allow-listing.
NOTED STRENGTHS
The assessed organization promptly planned for and resolved multiple identified issues, including with:
Windows service accounts: The organization eliminated over 30 percent of service accounts which were deemed unnecessary. There is an on-going effort to change service account passwords and apply DoD recommended STIG compliance (over 85 percent have been changed since the publication of this report).
IDM: The organization is looking into how to improve their IDM implementation and apply additional security alerts and preventions for possible misuse of credentials. They plan to implement additional identity-based monitoring capabilities in front of tier zero assets.
Egress: The organization implemented new processes to detect and prevent servers from anomalously egressing outside of the network to the internet.
Host-based solutions: The organization used additional features of their antivirus software, such as reputation scores, to look for all executable file type outliers of to identify anomalous instances.
Hosts: The organization decommissioned clusters of servers and completely rebuilt them from scratch after identifying numerous irreparable issues and misconfigurations.
Solaris credentials: The organization changed passwords, removed SSH keys, restricted permissions, and removed unnecessary accounts.
MITIGATIONS
Network Defenders
CISA recommends organizations implement the recommendations in Table 1 to mitigate the findings listed in the Lessons Learned and Key Findings section of this advisory. 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. See CISA’s Cross-Sector Cybersecurity Performance Goals for more information on the CPGs, including additional recommended baseline protections.
Table 1: Recommendations to Mitigate Identified Issues
Finding
Recommendation
Inadequate firewall between perimeter and internal devices
Deploy internal and external network firewalls to inspect, log, and/or block unknown or unauthorized traffic.
Perform deep packet inspection to detect mismatched application traffic or encrypted data flows.
Restrict outbound internet egress to hosts whenever possible.
Establish a baseline of normal user activity, including unique IPs or domains.
Insufficient Network Segmentation
Apply the principle of least privilege to limit the exposure of systems and services in the demilitarized zone (DMZ).
Segment the DMZ based on the sensitivity of systems and services as well as the internal network [CPG 2.F].
Segment networks to protect assets and workstations from direct exposure to the internet by considering the criticality of the asset to business functions, sensitivity of the data traversing the asset, and requirements for internet access to the asset.
Implement and regularly test firewalls, access control lists, and intrusion prevention systems.
Take advantage of opportunities to create natural network segmentation. Securely configured VPNs used for remote laptops, for instance, create an easy place to filter and monitor incoming traffic.
Trust relationships between domains were overly permissive
Restrict network connectivity (ingress and egress) to only necessary services between trusted domains [CPG 2.E].
Regularly monitor privileged access via Foreign Security Principals (FSPs).
Conduct regular security audits and penetration testing by internal and external parties.
Develop and implement a comprehensive Incident Response Plan (IRP) and conduct regular drills and simulations [CPG 2.S].
IDM solutions were not fully understood and utilized
Enroll all accounts in IDM solutions and test against common credential manipulation techniques.
Integrate the IDM solution with other systems and applications, allowing for the streamlining of workflows.
Insufficient role-based host segmentation
Establish Role-Based Access Controls (RBAC) to systematically assign permissions based on job functions [CPG 2.E].
Implement a comprehensive security model incorporating micro-segmentation at the host level.
Failure to monitor EDR alerts daily
Develop and document Standard Operating Procedures (SOPs) for handling EDR alerts [CPG 5.A].
Establish and maintain incident response playbooks.
Conduct regular audits and reviews of the EDR alert handling process.
Host artifacts were overly trusted
Operationalize and deploy File Integrity Monitoring (FIM) solutions.
Regularly review and adjust access permissions, adhering to the principle of least privilege [CPG 2.E].
Establish proper forensic processes to ensure integrity.
Bureaucracy and decentralization of network defenders hampered communication and consistency
Introduce cross-training initiatives to cultivate a collaborative culture.
Encourage the establishment of cross-functional projects.
Utilize collaboration platforms that seamlessly integrate various tools and systems.
Insufficient internal incident response report
Promote a culture of ongoing improvement while also fostering a proactive approach among employees to promptly report suspicious activities.
Treat suspected incidents of compromise as a confirmed breach, and account for a threat actor’s ability to move laterally when defining the scope of incident response efforts.
Focus on known/common IOCs
Employ centralized logging and tool-agnostic detection methods.
Leverage threat intelligence feeds by integrating them into a SIEM tool.
Implement regular updates for IOCs and TTPs, with the capability for customization to address the specific threat landscape [CPG 3.A].
Detection rules were visible from compromised systems
Integrate runtime detection mechanisms while removing world-readable configuration files from installer deployments where applicable.
Insufficient restriction of admin tools
Enhance security posture by implementing application allowlisting to ensure only trusted and approved applications are permitted [CPG 2.Q].
Apply the principle of least privilege by granting users only the minimum level of access necessary to perform job functions.
Insufficient tracking of software
Conduct a comprehensive inventory of assets and establish a baseline for behavior [CPG 1.A].
Utilize a Software Asset Management (SAM) solution that offers comprehensive tracking, reporting, and compliance management capabilities.
Deploy automated discovery and monitoring tools to continuously scan and identify new and existing software.
CISA recommends organizations implement the recommendations in Table 2 to mitigate other identified issues that can be uncovered through traditional penetration tests or red team assessments.
Table 2: Recommendations to Mitigate Identified Issues
Issue
Recommendation
Accounts were overprivileged and the organization’s network contained unnecessary service accounts
Apply the principle of least privilege when assigning permissions to user accounts. Audit existing group memberships, strip unnecessary privileges, and prune unnecessary nested groups/users.
Monitor for account lockout, especially on administrative accounts, and switch to a manual account unlock policy.
Increase monitoring for higher-risk accounts, such as service accounts, that are highly privileged and have a predictable pattern of behavior (e.g., scans that reliably run at a certain hour of the day).
Privileged users should have dedicated role-based user accounts and associated jump hosts to log into critical resources.
Insufficient EDR configuration
Ensure all hosts have a form of EDR installed.
Deploy an EDR capable of catching commonly known obfuscation or execution techniques.
Insecure and insufficient credentials
Ensure sensitive credentials and documents are not stored in an accessible place.
Note: The above mitigations apply to critical infrastructure organizations with on-premises or hybrid environments. CISA encourage all organizations to prioritize purchasing products from manufacturers who demonstrate secure by design principles, such as evidenced by follow-on publications from companies who have signed the Secure by Design Pledge.
Software Manufacturers
CISA recognizes that insecure software is the root cause of many flaws; the responsibility should not rest on the end user. CISA urges software manufacturers to implement the following:
Eliminate default passwordsand determine what password practices should be required (such as minimum password length and disallowing known breached passwords). Configure software to use more secure authentication schemes by default.
Provide logging at no additional charge. Cloud services and on-premises products should commit to generating and storing security related logs at no additional cost.
Work with security information and event management (SIEM) and security orchestration, automation, and response (SOAR) providers—in conjunction with customers—to understand how response teams use logs to investigate incidents. The goal is to develop logs that yield a comprehensive story of the event.
Remove unnecessary software dependencies. Unnecessary software increases the attack surface available to adversaries and may introduce additional vulnerabilities. Mitigating these additional vulnerabilities requires significant investment, consuming resources like time, technical personnel, and adding to the level of security effort.
These mitigations align with tactics provided in the joint guide Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software. CISA urges software manufacturers to take ownership of improving the security outcomes of their customers by applying these and other secure by design tactics. By using secure by design tactics, software manufacturers can make their product lines secure “out of the box” without requiring customers to spend additional resources making configuration changes, purchasing security software and logs, monitoring, and making routine updates.
In addition to applying mitigations, CISA recommends 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 recommends testing your existing security controls inventory to assess how they perform against the ATT&CK techniques described in this advisory.
To get started:
Select an ATT&CK technique described in this advisory (see Tables 3–11).
Align your security technologies against the technique.
Test your technologies against the technique.
Analyze your detection and prevention technologies’ performance.
Repeat the process for all security technologies to obtain a set of comprehensive performance data.
Tune your security program, including people, processes, and technologies, based on the data generated by this process.
CISA recommends 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.
The information in this report is being provided “as is” for informational purposes only. CISA does 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.
VERSION HISTORY
July 11, 2024: Initial version.
APPENDIX: MITRE ATT&CK TACTICS AND TECHNIQUES
See Tables 3–11 for all referenced threat actor tactics and techniques in this advisory.
CISA’s red team used open source tools and services to probe the organization’s internet-facing presence and gather information, including names, roles, and contact information.
CISA’s red team collected the assessed organizations’ employee names to use their email addresses for specific targeting based on roles and responsibilities.
CISA’s red team inspected the assessed organization’s domain trust relationships through LDAP and identified potential connections in external organizations to which to move laterally.
The red team data mined numerous internal servers and discovered one misconfigured share that contained plaintext usernames and passwords for several privileged service accounts.
Table 7: Privilege Escalation
Technique Title
ID
Use
Hijack Execution Flow: Path Interception by PATH Environment Variable
The red team hijacked the execution flow of a program that used a relative path instead of an absolute path, which enabled the capture of the account’s password.
The red team’s operations were hindered by the organization’s IDM when it blocked the team's attempts to bypass system access controls using different hash types for authentication.
Use Alternate Authentication Material: Pass the Ticket
CISA’s red team’s operations were hindered by the organization’s IDM when it blocked the team’s attempts to bypass system access controls using Kerberos tickets for authentication.
CISA’s red team searched each host for files containing sensitive or interesting information such as password hashes, account information, network configurations, etc.
The red team enumerated local files and running processes to gather information for their payloads and persistence mechanisms to appear as legitimate activity.
The red team modified file permissions with touch and chmod/chown commands to obfuscate their activity and blend in with other files in the environment.
Today, CISA and FBI are releasing their newest Secure by Design Alert in the series, Eliminating OS Command Injection Vulnerabilities, in response to recent well-publicized threat actor campaigns that exploited OS command injection defects in network edge devices (CVE-2024-20399, CVE-2024-3400, CVE-2024-21887) to target and compromise users. These vulnerabilities allowed unauthenticated malicious actors to remotely execute code on network edge devices.
OS command injection vulnerabilities have long been preventable by clearly separating user input from the contents of a command. Despite this finding, OS command injection vulnerabilities—many of which result from CWE-78—are still a prevalent class of vulnerability.
CISA and FBI urge CEOs and other business leaders at technology manufacturers to request their technical leaders analyze past occurrences of this class of defect and develop a plan to eliminate them in the future. For more on how to champion Secure by Design principles, visit our webpage. To join with the 150+ other companies who have signed our Secure by Design pledge, visit here.
CVE-2024-23692 Rejetto HTTP File Server Improper Neutralization of Special Elements Used in a Template Engine Vulnerability
CVE-2024-38080 Microsoft Windows Hyper-V Privilege Escalation Vulnerability
CVE-2024-38112 Microsoft Windows MSHTML Platform Spoofing Vulnerability
These types of vulnerabilities are frequent attack vectors for malicious cyber actors and pose significant risks to the federal enterprise.
Binding Operational Directive (BOD) 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities established the Known Exploited Vulnerabilities Catalog as a living list of known Common Vulnerabilities and Exposures (CVEs) that carry significant risk to the federal enterprise. BOD 22-01 requires Federal Civilian Executive Branch (FCEB) agencies to remediate identified vulnerabilities by the due date to protect FCEB networks against active threats. See theBOD 22-01 Fact Sheet for more information.
Although BOD 22-01 only applies to FCEB agencies, CISA strongly urges all organizations to reduce their exposure to cyberattacks by prioritizing timely remediation of Catalog vulnerabilities as part of their vulnerability management practice. CISA will continue to add vulnerabilities to the catalog that meet the specified criteria.
Citrix released security updates to address vulnerabilities in multiple Citrix products. A cyber threat actor could exploit some of these vulnerabilities to take control of an affected system.
CISA encourages users and administrators to review the following and apply necessary updates:
Adobe released security updates to address multiple vulnerabilities in Adobe software. A cyber threat actor could exploit some of these vulnerabilities to take control of an affected system.
CISA encourages users and administrators to review the following Adobe Security Bulletins and apply necessary updates:
Microsoft released security updates to address vulnerabilities in multiple products. A cyber threat actor could exploit some of these vulnerabilities to take control of an affected system.
CISA encourages users and administrators to review the following and apply necessary updates:
Under certain circumstances the camera may be susceptible to known vulnerabilities associated with JQuery versions prior to 3.5.0 third-party component
Aligning with CISA recommendations, Johnson Controls recommends taking steps to minimize risks to all building automation systems.
CISA recommends users take defensive measures to minimize the risk of exploitation of this vulnerability. CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.
Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.
CISA also recommends users take the following measures to protect themselves from social engineering attacks:
Do not click web links or open attachments in unsolicited email messages.
No known public exploitation specifically targeting this vulnerability has been reported to CISA at this time. This vulnerability has a high attack complexity.
CISA released seven Industrial Control Systems (ICS) advisories on July 9, 2024. These advisories provide timely information about current security issues, vulnerabilities, and exploits surrounding ICS.
Delta Electronics CNCSoft-G2 lacks proper validation of the length of user-supplied data prior to copying it to a fixed-length stack-based buffer. If a target visits a malicious page or opens a malicious file an attacker can leverage this vulnerability to execute code in the context of the current process.
Delta Electronics CNCSoft-G2 lacks proper validation of user-supplied data, which can result in a memory corruption condition. If a target visits a malicious page or opens a malicious file an attacker can leverage this vulnerability to execute code in the context of the current process.
Delta Electronics CNCSoft-G2 lacks proper validation of user-supplied data, which can result in a read past the end of an allocated buffer. If a target visits a malicious page or opens a malicious file an attacker can leverage this vulnerability to execute code in the context of the current process.
Delta Electronics CNCSoft-G2 lacks proper validation of the length of user-supplied data prior to copying it to a fixed-length heap-based buffer. If a target visits a malicious page or opens a malicious file an attacker can leverage this vulnerability to execute code in the context of the current process.
Locate control system networks and remote devices behind firewalls and isolating them from business networks.
When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.
CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.
Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.
CISA also recommends users take the following measures to protect themselves from social engineering attacks:
Do not click web links or open attachments in unsolicited email messages.
No known public exploitation specifically targeting these vulnerabilities has been reported to CISA at this time. These vulnerabilities are not exploitable remotely.
Locate control system networks and remote devices behind firewalls and isolating them from business networks.
When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.
CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.
Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.
CISA also recommends users take the following measures to protect themselves from social engineering attacks:
Do not click web links or open attachments in unsolicited email messages.
Successful exploitation of this vulnerability could allow an attacker to tamper with, destroy, disclose, or delete information in the product, or cause a denial-of-service (DoS) condition on the product.
3. TECHNICAL DETAILS
3.1 AFFECTED PRODUCTS
The following versions of Mitsubishi Electric MELIPC Series MI5122-VW, an industrial PC, are affected:
MI5122-VW: Firmware versions "05" up to and including "07"
In Mitsubishi Electric MELIPC Series MI5122-VW firmware versions "05" up to and including "07", a local attacker may execute arbitrary code by saving a malicious file to a specific folder. As a result, the attacker may disclose, tamper with, destroy or delete information in the product, or cause a denial-of-service (DoS) condition on the product.
Mitsubishi Electric reported this vulnerability to CISA.
4. MITIGATIONS
Mitsubishi Electric has fixed the vulnerability in the following products:
MI5122-VW: firmware versions "08" or later
Customers using the affected product should take workarounds and mitigations in Mitsubishi Electric advisory 2024-003, because updating the product to the fixed version is not available.
Please refer to Mitsubishi Electric's user manual for how to check the firmware version.
MELIPC MI5000 Series User's Manual (Startup) "Appendix 17 Checking Production Information and Firmware Version"
Locate control system networks and remote devices behind firewalls and isolating them from business networks.
When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.
CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.
Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.
No known public exploitation specifically targeting this vulnerability has been reported to CISA at this time. This vulnerability is not exploitable remotely.
Locate control system networks and remote devices behind firewalls and isolating them from business networks.
When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.
CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.
Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.
No known public exploitation specifically targeting this vulnerability has been reported to CISA at this time.
CISA has collaborated with the Australian Signals Directorate’s Australian Cyber Security Centre (ASD's ACSC) to release an advisory, People’s Republic of China (PRC) Ministry of State Security APT40 Tradecraft in Action outlining a PRC state-sponsored cyber group’s activity. The following organizations also collaborated with ASD's ACSC on the guidance:
The National Security Agency (NSA);
The Federal Bureau of Investigation (FBI);
The United Kingdom’s National Cyber Security Centre (NCSC-UK);
The Canadian Centre for Cyber Security (CCCS);
The New Zealand National Cyber Security Centre (NCSC-NZ);
The German Federal Intelligence Service (BND) and Federal Office for the Protection of the Constitution (BfV);
The Republic of Korea’s National Intelligence Service (NIS) and NIS’ National Cyber Security Center (NCSC); and
Japan’s National Center of Incident Readiness and Strategy for Cybersecurity (NISC) and National Policy Agency (NPA).
The advisory is based on current ACSC-led incident response investigations and shared understanding of a PRC state-sponsored cyber group, APT40—also known as Kryptonite Panda, GINGHAM TYPHOON, Leviathan and Bronze Mohawk in industry reporting.
APT 40 has previously targeted organizations in various countries, including Australia and the United States. Notably, APT 40 possesses the ability to quickly transform and adapt vulnerability proofs of concept (POCs) for targeting, reconnaissance, and exploitation operations. APT 40 identifies new exploits within widely used public software such as Log4J, Atlassian Confluence and Microsoft Exchange to target the infrastructure of the associated vulnerability.
CISA urges all organizations and software manufacturers to review the advisory to help identify, prevent, and remediate APT 40 intrusions. Software vendors are also urged to incorporate Secure by Design principles into their practices to limit the impact of threat actor techniques and to strengthen the security posture of their products for their customers.
For more information on PRC state-sponsored threat actor activity, see CISA’s People's Republic of China Cyber Threat. To learn more about secure by design principles and practices, visit CISA’s Secure by Design webpage.
This advisory, authored by the Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC), the United States Cybersecurity and Infrastructure Security Agency (CISA), the United States National Security Agency (NSA), the United States Federal Bureau of Investigation (FBI), the United Kingdom National Cyber Security Centre (NCSC-UK), the Canadian Centre for Cyber Security (CCCS), the New Zealand National Cyber Security Centre (NCSC-NZ), the German Federal Intelligence Service (BND) and Federal Office for the Protection of the Constitution (BfV), the Republic of Korea’s National Intelligence Service (NIS) and NIS’ National Cyber Security Center, and Japan’s National Center of Incident Readiness and Strategy for Cybersecurity (NISC) and National Police Agency (NPA)—hereafter referred to as the “authoring agencies”—outlines a People’s Republic of China (PRC) state-sponsored cyber group and their current threat to Australian networks. The advisory draws on the authoring agencies’ shared understanding of the threat as well as ASD’s ACSC incident response investigations.
The PRC state-sponsored cyber group has previously targeted organizations in various countries, including Australia and the United States, and the techniques highlighted below are regularly used by other PRC state-sponsored actors globally. Therefore, the authoring agencies believe the group, and similar techniques remain a threat to their countries’ networks as well.
The authoring agencies assess that this group conduct malicious cyber operations for the PRC Ministry of State Security (MSS). The activity and techniques overlap with the groups tracked as Advanced Persistent Threat (APT) 40 (also known as Kryptonite Panda, GINGHAM TYPHOON, Leviathan and Bronze Mohawk in industry reporting). This group has previously been reported as being based in Haikou, Hainan Province, PRC and receiving tasking from the PRC MSS, Hainan State Security Department.[1]
The following Advisory provides a sample of significant case studies of this adversary’s techniques in action against two victim networks. The case studies are consequential for cybersecurity practitioners to identify, prevent and remediate APT40 intrusions against their own networks. The selected case studies are those where appropriate remediation has been undertaken reducing the risk of re-exploitation by this threat actor, or others. As such, the case studies are naturally older in nature, to ensure organizations were given the necessary time to remediate.
To download the PDF version of this report, visit the following link, APT40 Advisory.
Activity Summary
APT40 has repeatedly targeted Australian networks as well as government and private sector networks in the region, and the threat they pose to our networks is ongoing. The tradecraft described in this advisory is regularly observed against Australian networks.
Notably, APT40 possesses the capability to rapidly transform and adapt exploit proof-of-concept(s) (POCs) of new vulnerabilities and immediately utilize them against target networks possessing the infrastructure of the associated vulnerability. APT40 regularly conducts reconnaissance against networks of interest, including networks in the authoring agencies’ countries, looking for opportunities to compromise its targets. This regular reconnaissance postures the group to identify vulnerable, end-of-life or no longer maintained devices on networks of interest, and to rapidly deploy exploits. APT40 continues to find success exploiting vulnerabilities from as early as 2017.
APT40 rapidly exploits newly public vulnerabilities in widely used software such as Log4J (CVE-2021-44228), Atlassian Confluence (CVE-2021-31207, CVE-2021-26084) and Microsoft Exchange (CVE-2021-31207, CVE-2021-34523, CVE-2021-34473). ASD’s ACSC and the authoring agencies expect the group to continue using POCs for new high-profile vulnerabilities within hours or days of public release.
Figure 1: TTP Flowchart for APT40 activity
This group appears to prefer exploiting vulnerable, public-facing infrastructure over techniques that require user interaction, such as phishing campaigns, and places a high priority on obtaining valid credentials to enable a range of follow-on activities. APT40 regularly uses web shells [T1505.003] for persistence, particularly early in the life cycle of an intrusion. Typically, after successful initial access APT40 focuses on establishing persistence to maintain access on the victim’s environment. However, as persistence occurs early in an intrusion, it is more likely to be observed in all intrusions—regardless of the extent of compromise or further actions taken.
Notable Tradecraft
Although APT40 has previously used compromised Australian websites as command and control (C2) hosts for its operations, the group have evolved this technique [T1594].
APT40 has embraced the global trend of using compromised devices, including small-office/home-office (SOHO) devices, as operational infrastructure and last-hop redirectors [T1584.008] for its operations in Australia. This has enabled the authoring agencies to better characterize and track this group’s movements.
Many of these SOHO devices are end-of-life or unpatched and offer a soft target for N-day exploitation. Once compromised, SOHO devices offer a launching point for attacks that is designed to blend in with legitimate traffic and challenge network defenders [T1001.003].
APT40 does occasionally use procured or leased infrastructure as victim-facing C2 infrastructure in its operations; however, this tradecraft appears to be in relative decline.
Tooling
ASD’s ACSC are sharing some of the malicious files identified during the investigations outlined below. These files have been uploaded to VirusTotal to enable the wider network defense and cyber security communities to better understand the threats they need to defend against.
ASD’s ACSC are sharing two anonymized investigative reports to provide awareness of how the actors employ their tools and tradecraft.
Case Study 1
This report has been anonymized to enable wider dissemination. The impacted organization is hereafter referred to as “the organization.” Some specific details have been removed to protect the identity of the victim and incident response methods of ASD’s ACSC.
Executive Summary
This report details the findings of the ASD’s ACSC investigation into the successful compromise of the organization’s network between July and September 2022. This investigative report was provided to the organization to summarize observed malicious activity and frame remediation recommendations. The findings indicate the compromise was undertaken by APT40.
In mid-August, the ASD’s ACSC notified the organization of malicious interactions with their network from a likely compromised device being used by the group in late August and, with the organization’s consent, the ASD’s ACSC deployed host-based sensors to likely affected hosts on the organization’s network. These sensors allowed ASD’s ACSC incident response analysts to undertake a thorough digital forensics investigation. Using available sensor data, the ASD’s ACSC analysts successfully mapped the group’s activity and created a detailed timeline of observed events.
From July to August, key actor activity observed by the ASD’s ACSC included:
Host enumeration, which enables an actor to build their own map of the network;
Web shell use, giving the actor an initial foothold on the network and a capability to execute commands; and
Deployment of other tooling leveraged by the actor for malicious purposes.
The investigation uncovered evidence of large amounts of sensitive data being accessed and evidence that the actors moved laterally through the network [T1021.002]. Much of the compromise was facilitated by the group’s establishment of multiple access vectors into the network, the network having a flat structure, and the use of insecure internally developed software that could be used to arbitrarily upload files. Exfiltrated data included privileged authentication credentials that enabled the group to log in, as well as network information that would allow the actors to regain unauthorized access if the original access vector was blocked. No additional malicious tooling was discovered beyond those on the initially exploited machine; however, a group’s access to legitimate and privileged credentials would negate the need for additional tooling. Findings from the investigation indicate the organization was likely deliberately targeted by APT40, as opposed to falling victim opportunistically to a publicly known vulnerability.
Investigation Findings
In mid-August 2022, the ASD’s ACSC notified the organization that a confirmed malicious IP believed to be affiliated with a state-sponsored cyber group had interacted with the organization’s computer networks between at least July and August. The compromised device probably belonged to a small business or home user.
In late August, the ASD’s ACSC deployed a host-based agent to hosts on the organization’s network which showed evidence of having been impacted by the compromise.
Some artefacts which could have supported investigation efforts were not available due to the configuration of logging or network design. Despite this, the organization’s readiness to provide all available data enabled ASD’s ACSC incident responders to conduct comprehensive analysis and to form an understanding of likely APT40 activity on the network.
In September, after consultation with the ASD’s ACSC, the organization decided to denylist the IP identified in the initial notification. In October, the organization commenced remediation.
Details
Beginning in July, actors were able to test and exploit a custom web application [T1190] running on <webapp>2-ext, which enables the group to establish a foothold in the network demilitarized zone (DMZ). This was leveraged to enumerate both the network as well as all visible domains. Compromised credentials [T1078.002] were used to query the Active Directory [T1018] and exfiltrate data by mounting file shares [T1039] from multiple machines within the DMZ. The actor carried out a Kerberoasting attack in order to obtain valid network credentials from a server [T1558.003]. The group were not observed gaining any additional points of presence in either the DMZ or the internal network.
Visual Timeline
The below timeline provides a broad overview of the key phases of malicious actor activity observed on the organization’s network.
Detailed Timeline
July: The actors established an initial connection to the front page of a custom web application [T1190] built for the organization (hereafter referred to as the “web application” or “webapp”) via a transport layer security (TLS) connection [T1102]. No other noteworthy activity was observed.
July: The actors begin enumerating the web application’s website looking for endpoints[2] to further investigate.
July: The actors concentrate on attempts to exploit a specific endpoint.
July: The actors are able to successfully POST to the web server, probably via a web shell placed on another page. A second IP, likely employed by the same actors, also begins posting to the same URL. The actors created and tested a number of likely web shells.
The exact method of exploitation is unknown, but it is clear that the specific endpoint was targeted to create files on <webapp>2-ext.
ASD's ACSC believes that the two IP address connections were part of the same intrusion due to their shared interest and initial connections occurring minutes apart.
July: The group continue to conduct host enumeration, looking for privilege escalation opportunities, and deploying a different web shell. The actors log into the web application using compromised credentials for <firstname.surname>@<organisation domain>.
The actors’ activity does not appear to have successfully achieved privilege escalation on <webapp>2-ext. Instead, the actors pivoted to network-based activity.
July: The actor tests the compromised credentials for a service account[3] which it likely found hardcoded in internally accessible binaries.
July: The actors deploy the open-source tool Secure Socket Funnelling, which was used to connect out to the malicious infrastructure. This connection is employed to tunnel traffic from the actor's attack machines into the organization’s internal networks, whose machine names are exposed in event logs as they attempt to use the credentials for the service account.
August: The actors are seen conducting a limited amount of activity, including failing to establish connections involving the service account.
August: The actors perform significant network and Active Directory enumeration. A different compromised account is subsequently employed to mount shares[4] on Windows machines within the DMZ, enabling successful data exfiltration.
This seems to be opportunistic usage of a stolen credential on mountable machines in the DMZ. Firewalls blocked the actor from targeting the internal network with similar activity.
August – September: The SSF tool re-established a connection to a malicious IP. The group are not observed performing any additional activities until their access is blocked.
September: The organization blocks the malicious IP by denylisting it on their firewalls.
Actor Tactics and Techniques
The MITRE ATT&CK framework is a documented collection of tactics and techniques employed by threat actors in cyberspace. The framework was created by U.S. not-for-profit The MITRE Corporation and functions as a common global language around threat actor behavior.
The ASD’s ACSC assesses the following techniques and tactics to be relevant to the actor’s malicious activity:
The actor enumerated the custom web application’s website to identify opportunities for accessing the network.
Initial Access
T1190 – Exploit Public-Facing Application (regarding exploiting the custom web application)
T1078.002 – Valid Accounts: Domain Accounts (regarding logging on with comprised credentials)
Exploiting internet-exposed custom web applications provided an initial point of access for the actor. The actor was later able to use credentials they had compromised to further their access to the network.
Execution
T1059 – Command and Scripting Interpreter (regarding command execution through the web shell)
T1072 – Software Deployment Tools (regarding the actor using open-source tool Secure Socket Funnelling (SSF) to connect to an IP)
Persistence
T1505.003 – Server Software Component: Web Shell (regarding use of a web shell and SSF to establish access)
Credential Access
T1552.001 – Credentials from Password Stores (regarding password files relating to building management system [BMS])
T1558.003 – Steal or Forge Kerberos Tickets: Kerberoasting (regarding attack to gain network credentials)
Lateral movement
T1021.002 – Remote Services: SMB Shares (regarding the actor mounting SMB shares from multiple devices)
Collection
T1213 – Data from Information Repositories (regarding manuals/documentation found on the BMS server)
Exfiltration
T1041 – Exfiltration Over C2 Channel (regarding the actor’s data exfiltration from Active Directory and mounting shares)
Case Study 2
This report has been anonymized to enable wider dissemination. The impacted organization is hereafter referred to as “the organization.” Some specific details have been removed to protect the identity of the victim and incident response methods of ASD’s ACSC.
Executive Summary
This report details the findings of ASD’s ACSC investigation into the successful compromise of the organization’s network in April 2022. This investigation report was provided to the organization to summarize observed malicious activity and frame remediation recommendations. The findings indicate the compromise was undertaken by APT40.
In May 2022, ASD’s ACSC notified an organization of suspected malicious activity impacting the organization’s network since April 2022. Subsequently, the organization informed ASD's ACSC that they had discovered malicious software on an internet‑facing server which provided the login portal for the organization’s corporate remote access solution. This server used a remote access login and identity management product and will be referred to in this report as 'the compromised appliance'. This report details the investigation findings and remediation advice developed for the organization in response to the investigation conducted by the ASD’s ACSC.
Evidence indicated that part of the organization’s network had been compromised by malicious cyber actor(s) via the organization’s remote access login portal since at least April 2022. This server may have been compromised by multiple actors, and was likely affected by a remote code execution (RCE) vulnerability that was widely publicized around the time of the compromise.
Key actor activity observed by the ASD’s ACSC included:
Host enumeration, which enables an actor to build their own map of the network;
Exploitation of internet-facing applications and web shell use, giving the actor an initial foothold on the network and a capability to execute commands;
Exploitation of software vulnerabilities to escalate privileges; and
Credential collection to enable lateral movement.
The ASD’s ACSC discovered that a malicious actor had exfiltrated several hundred unique username and password pairs on the compromised appliance in April 2022, as well as a number of multi-factor authentication codes and technical artefacts related to remote access sessions. Upon a review by the organization, the passwords were found to be legitimate. The ASD’s ACSC assesses that the actor may have collected these technical artefacts to hijack or create a remote login session as a legitimate user, and access the organization’s internal corporate network using a legitimate user account.
Investigation Summary
The ASD’s ACSC determined that the actor compromised appliance(s) which provide remote login sessions for organization staff and used this compromise to attempt to conduct further activity. These appliances consist of three load-balanced hosts where the earliest evidence of compromise was detected. The organization shut down two of the three load-balanced hosts shortly after the initial compromise. As a result, all subsequent activity occurred on a single host. The other servers associated with the compromised appliance were also load-balanced in a similar manner. For legibility, all compromised appliances are referred to in most of this report as a “single appliance.”
The actor is believed to have used publicly known vulnerabilities to deploy web shells to the compromised appliance from April 2022 onwards. Threat actors from the group are assessed to have attained escalated privileges on the appliance. The ASD’s ACSC could not determine the full extent of the activity due to lack of logging availability. However, evidence on the device indicates that an actor achieved the following:
The collection of several hundred genuine username and password pairs; and
The collection of technical artefacts which may have allowed a malicious actor to access a virtual desktop infrastructure (VDI) session as a legitimate user.
The ASD’s ACSC assesses that the actor would have sought to further the compromise of the organisation network. The artefacts exfiltrated by the actor may have allowed them to hijack or initiate virtual desktop sessions as a legitimate user, possibly as a user of their choice, including administrators. The actor may have used this access vector to further compromise organization services to achieve persistence and other goals.
Other organization appliances within the hosting provider managed environment did not show evidence of compromise.
Access
The host with the compromised appliance provided authentication via Active Directory and a webserver, for users connecting to VDI sessions [T1021.001].
Location
Compromised appliance hostnames (load-balanced)
Datacentre 1
HOST1, HOST2, HOST3
The appliance infrastructure also included access gateway hosts that provide a tunnel to the VDI for the user, once they possess an authentication token generated and downloaded from the appliance.
There was no evidence of compromise of any of these hosts. However, the access gateway hosts logs showed evidence of significant interactions with known malicious IP addresses. It is likely that this reflected activity that occurred on this host, or network connections with threat actor infrastructure that reached this host. The nature of this activity could not be determined using available evidence but indicates that the group sought to move laterally in the organization’s network [TA0008].
Internal Hosts
The ASD’s ACSC investigated limited data from the internal organization’s network segment. Attempted or successful malicious activity known to have impacted the internal organization’s network segment includes actor access to VDI-related artefacts, the scraping of an internal SQL server [T1505.001], and unexplained traffic observed going from known malicious IP addresses through the access gateway appliances [TA0011].
Using their access to the compromised appliance, the group collected genuine usernames, passwords [T1003], and MFA token values [T1111]. The group also collected JSON Web Tokens (JWTs) [T1528], which is an authentication artefact used to create virtual desktop login sessions. The actor may have been able to use these to create or hijack virtual desktop sessions [T1563.002] and access the internal organization network segment as a legitimate user [T1078].
The actor also used access to the compromised appliance to scrape an SQL server [T1505.001], which resided in the organization’s internal network. It is likely that the actor had access to this data.
Evidence available from the access gateway appliance revealed that network traffic occurred through or to this device from known malicious IP addresses. As described above, this may indicate that malicious cyber actors impacted or utilized this device, potentially to pivot into the internal network.
Investigation Timeline
The below list provides a timeline of key activities discovered during the investigation.
Time
Event
April 2022
Known malicious IP addresses interact with access gateway host HOST7. The nature of the interactions could not be determined.
April 2022
All hosts, HOST1, HOST2 and HOST3, were compromised by a malicious actor or actors, and web shells were placed on the hosts.
A log file was created or modified on HOST2. This file contains credential material likely captured by a malicious actor.
The /etc/security/opasswd and /etc/shadow files were modified on HOST1 and HOST3, indicating that passwords were changed. Evidence available on HOST1 suggests that the password for user ‘sshuser’ was changed.
April 2022
HOST2 was shut down by the organization.
Additional web shells (T1505.003) were created on HOST1 and HOST3. HOST1experienced SSH brute force attempts from HOST3.
A log file was modified (T1070) on HOST3. This file contains credential material (T1078) likely captured by a malicious actor.
JWTs were captured (T1528) and output to a file on HOST3.
HOST3 was shut down by the organization. All activity after this time occurs on HOST1.
April 2022
Additional web shells were created on HOST1 (T1505.003). JWTs were captured and output to a file on HOST1.
April 2022
Additional web shells are created on HOST1 (T1505.003), and a known malicious IP address interacts with the host (TA0011).
A known malicious IP address interacts with access gateway host HOST7.
May 2022
A known malicious IP address interacted with access gateway host HOST7 (TA0011).
An authentication event for a user is linked to a known malicious IP address in logs on HOST1. An additional web shell is created on this host (T1505.003).
May 2022
A script on HOST1 was modified by an actor (T1543). This script contains functionality which would have scraped data from an internal SQL server.
May 2022
An additional log file on HOST1 was last modified (T1070). This file contains username and password pairs for the organization network, which are believed to be legitimate (T1078).
May 2022
An additional log file was last modified (T1070). This file contains JWTs collected from HOST1.
May 2022
Additional web shells were created on HOST1 (T1505.003). On this date, the organization reported the discovery of a web shell with creation date in April 2022 to ASD’s ACSC
May 2022
A number of scripts were created on HOST1, including one named Log4jHotPatch.jar.
May 2022
The iptables-save command was used to add two open ports to the access gateway host. The ports were 9998 and 9999 (T1572).
Actor Tactics and Techniques
Highlighted below are several tactics and techniques identified during the investigation.
The group likely exploited RCE, privilege escalation, and authentication bypass vulnerabilities in the remote access login and identity management product to gain initial access to the network.
This initial access method is considered the most likely due to the following:
The server was vulnerable to these CVEs at the time;
Attempts to exploit these vulnerabilities from known actor infrastructure; and
The first known internal malicious activity occurred shortly after attempted exploitation attempts were made.
Execution
T1059.004 Command and Scripting Interpreter: Unix Shell
The group successfully exploited the above vulnerabilities may have been able to run commands in a Unix shell available on the affected appliance.
Complete details of the commands run by actors cannot be provided as they were not logged by the appliance.
Actors deployed several web shells on the affected appliance. It is possible that multiple distinct actors deployed web shells, but that only a smaller number of actors conducted activity using these web shells.
Web shells would have allowed for arbitrary command execution by the actor on the compromised appliances.
Available evidence does not describe the level of privilege attained by actors. However, using web shells, the actors would have achieved a level of privilege comparable to that of the web server on the compromised appliance. Vulnerabilities believed to have been present on the compromised appliance
would have allowed the actors to attain root privileges.
Evidence on the compromised appliance showed that the actor had captured several hundred username-password pairs, in clear text, which are believed to be legitimate. It is likely that these were captured using some modification to the genuine authentication process which output the credentials to a file.
T1111 Multi-Factor Authentication Interception The actor also captured the value of MFA tokens
corresponding to legitimate logins. These were likely captured by modifying the genuine authentication process to output these values to a file. There is no evidence of compromise of the “secret server’ which stores the unique values that provide for the security of MFA tokens.
The actor is believed to have captured JWTs by capturing HTTP traffic on the compromised appliance. There is evidence that the utility tcpdump was executed on the compromised appliance, which may have been how the actor captured these JWTs.
As described above, the actor captured JWTs, which are analogous to web session cookies. These could have been reused by the actor to establish further access.
There is evidence that network scanning utility nmap was executed on the compromised appliance to scan other appliances in the same network segment. This was likely used by the actor to discover other reachable network services which might present opportunities for lateral movement.
Collection
Available evidence does not reveal how actors collected data or exactly what was collected from the compromised appliance or from other systems. However, it is likely that actors had access to all files on the compromised appliance, including the captured credentials [T1003], MFA token values [T1111], and JWTs described above.
Command and Control
T1071.001 Application Layer Protocol: Web Protocols
Actors used web shells for command and control. Web shell commands would have been passed over HTTPS using the existing web server on the appliance [T1572].
T1001.003 Data Obfuscation: Protocol Impersonation
Actors used compromised devices as a launching point for attacks that are designed to blend in with legitimate traffic.
Detection and mitigation recommendations
The ASD’s ACSC strongly recommends implementing the ASD Essential Eight Controls and associated Strategies to Mitigate Cyber Security Incidents. Below are recommendations for network security actions that should be taken to detect and prevent intrusions by APT40, followed by specific mitigations for four key TTPs summarized in Table 1.
Detection
Some of the files identified above were dropped in locations such as C:\Users\Public\* and C:\Windows\ Temp\*. These locations can be convenient spots for writing data as they are usually world writable, that is, all user accounts registered in Windows have access to these directories and their subdirectories. Often, any user can subsequently access these files, allowing opportunities for lateral movement, defense evasion, low-privilege execution and staging for exfiltration.
The following Sigma rules look for execution from suspicious locations as an indicator of anomalous activity. In all instances, subsequent investigation is required to confirm malicious activity and attribution.
Title: World Writable Execution - Temp
ID: d2fa2d71-fbd0-4778-9449-e13ca7d7505c
Description: Detect process execution from C:\ Windows\Temp.
Background: This rule looks specifically for execution out of C:\ Windows\Temp\*. Temp is more broadly used by benign applications and thus a lower confidence malicious indicator than execution out of other world writable subdirectories in C:\Windows.
Removing applications executed by the SYSTEM or NETWORK SERVICE users substantially reduces the quantity of benign activity selected by this rule.
This means that the rule may miss malicious executions at a higher privilege level but it is recommended to use other rules to determine if a user is attempting to elevate privileges to SYSTEM.
Investigation:
Examine information directly associated with this file execution, such as the user context, execution integrity level, immediate follow-on activity and images loaded by the file.
Investigate contextual process, network, file and other supporting data on the host to help make an assessment as to whether the activity is malicious.
If necessary attempt to collect a copy of the file for reverse engineering to determine whether it is legitimate.
condition: temp and not (common_temp_path or system_user or dismhost or known_parent)
False positives:
Allowlist auditing applications have been observed running executables from Temp.
Temp will legitimately contain an array of setup applications and launchers, so it will be worth considering how prevalent this behavior is on a monitored network (and whether or not it can be allowlisted) before deploying this rule.
Level: low
Title: World Writable Execution - Non-Temp System Subdirectory
ID: 5b187157-e892-4fc9-84fc-aa48aff9f997
Description: Detect process execution from a world writable location in a subdirectory of the Windows OS install location.
Background:
This rule looks specifically for execution out of world writable directories within C:\ and particularly C:\Windows\*, with the exception of C:\Windows\Temp (which is more broadly used by benign applications and thus a lower confidence malicious indicator).
AppData folders are excluded if a file is run as SYSTEM - this is a benign way in which many temporary application files are executed.
After completing an initial network baseline and identifying known benign executions from these locations, this rule should rarely fire.
Investigation:
Examine information directly associated with this file execution, such as the user context, execution integrity level, immediate follow-on activity and images loaded by the file.
Investigate contextual process, network, file and other supporting data on the host to help make an assessment as to whether the activity is malicious.
If necessary attempt to collect a copy of the file for reverse engineering to determine whether it is legitimate.
appdata: Image|contains: '\\AppData\\' User: 'SYSTEM' condition: writable_path and not appdata
False positives:
Allowlist auditing applications have been observed running executables from these directories.
It is plausible that scripts and administrative tools used in the monitored environment(s) may be located in one of these directories and should be addressed on a case-by-case basis.
Level: high
Title: World Writable Execution - Users
ID: 6dda3843-182a-4214-9263-925a80b4c634
Description: Detect process execution from C:\Users\Public\* and other world writable folders within Users.
Background:
AppData folders are excluded if a file is run as SYSTEM - this is a benign way in which many temporary application files are executed.
Investigation:
Examine information directly associated with this file execution, such as the user context, execution integrity level, immediate follow-on activity and images loaded by the file.
Investigate contextual process, network, file and other supporting data on the host to help make an assessment as to whether the activity is malicious.
If necessary attempt to collect a copy of the file for reverse engineering to determine whether it is legitimate.
appdata: Image|contains: '\\AppData\\' User: 'SYSTEM' condition: users and not appdata
False positives:
It is plausible that scripts and administrative tools used in the monitored environment(s) may be located in Public or a subdirectory and should be addressed on a case-by-case basis.
Level: medium
Mitigations
Logging
During ASD’s ACSC investigations, a common issue that reduces the effectiveness and speed of investigative efforts is a lack of comprehensive and historical logging information across a number of areas including web server request logs, Windows event logs and internet proxy logs.
Promptly patch all internet exposed devices and services, including web servers, web applications, and remote access gateways. Consider implementing a centralized patch management system to automate and expedite the process. ASD’s ACSC recommend implementation of the ISM’s Guidelines for System Management, specifically, the System Patching controls where applicable.
Most exploits utilized by the actor were publicly known and had patches or mitigations available.
Organizations should ensure that security patches or mitigations are applied to internet facing infrastructure within 48 hours, and where possible, use the latest versions of software and operating systems.
Network Segmentation
Network segmentation can make it significantly more difficult for adversaries to locate and gain access to an organizations sensitive data. Segment networks to limit or block lateral movement by denying traffic between computers unless required. Important servers such as Active Directory and other authentication servers should only be able to be administered from a limited number of intermediary servers or “jump servers.” These servers should be closely monitored, be well secured and limit which users and devices are able to connect to them.
Regardless of instances identified where lateral movement is prevented, additional network segmentation could have further limited the amount of data the actors were able to access and extract.
Additional Mitigations
The authoring agencies also recommend the following mitigations to combat APT40 and others’ use of the TTPs below.
Disable unused or unnecessary network services, ports and protocols.
Use well-tuned Web application firewalls (WAFs) to protect webservers and applications.
Enforce least privilege to limit access to servers, file shares, and other resources.
Use multi-factor authentication (MFA) and managed service accounts to make credentials harder to crack and reuse. MFA should be applied to all internet accessible remote access services, including:
For additional general detection and mitigation advice, please consult the Mitigations and Detection sections on the MITRE ATT&CK technique web page for each of the techniques identified in the MITRE ATT&CK summary at the end of this advisory.
Reporting
Australian organizations: visit cyber.gov.au or call 1300 292 371 (1300 CYBER 1) to report cybersecurity incidents and to access alerts and advisories.
Canadian organizations: report incidents by emailing CCCS at contact@cyber.gc.ca.
New Zealand organizations: report cyber security incidents to incidents@ncsc.govt.nz or call 04 498 7654.
United Kingdom organizations: report a significant cyber security incident at National Cyber Security Centre (monitored 24 hours) or, for urgent assistance, call 03000 200 973.
U.S. organizations: report incidents and anomalous activity to CISA 24/7 Operations Center at report@cisa.gov or (888) 282-0870 and/or to the FBI via your local FBI field office, the FBI’s 24/7 CyWatch at (855) 292-3937, or CyWatch@fbi.gov. When available, please include the following information regarding the incident: date, time, and location of the incident; type of activity; number of people affected; type of equipment used for the activity; the name of the submitting company or organization; and a designated point of contact.
Disclaimer
The information in this report is being provided “as is” for informational purposes only. The authoring agencies 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 authoring agencies.
MITRE ATT&CK – Historical APT40 Tradecraft of Interest
Locate control system networks and remote devices behind firewalls and isolating them from business networks.
When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.
CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.
Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.
No known public exploitation specifically targeting this vulnerability has been reported to CISA at this time.
CISA released seven Industrial Control Systems (ICS) advisories on July 2, 2024. These advisories provide timely information about current security issues, vulnerabilities, and exploits surrounding ICS.
These types of vulnerabilities are frequent attack vectors for malicious cyber actors and pose significant risks to the federal enterprise.
Binding Operational Directive (BOD) 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities established the Known Exploited Vulnerabilities Catalog as a living list of known Common Vulnerabilities and Exposures (CVEs) that carry significant risk to the federal enterprise. BOD 22-01 requires Federal Civilian Executive Branch (FCEB) agencies to remediate identified vulnerabilities by the due date to protect FCEB networks against active threats. See theBOD 22-01 Fact Sheet for more information.
Although BOD 22-01 only applies to FCEB agencies, CISA strongly urges all organizations to reduce their exposure to cyberattacks by prioritizing timely remediation of Catalog vulnerabilities as part of their vulnerability management practice. CISA will continue to add vulnerabilities to the catalog that meet the specified criteria.
Vulnerabilities: Allocation of Resources Without Limits or Throttling, Improper Neutralization, Uncontrolled Search Path Element, Improper Authentication, Unsafe Reflection
2. RISK EVALUATION
Successful exploitation of these vulnerabilities could result in denial of service, improper privilege management, or potentially remote code execution.
3. TECHNICAL DETAILS
3.1 AFFECTED PRODUCTS
ICONICS reports that the following versions of ICONICS Product Suite are affected:
ICONICS Suite including GENESIS64, Hyper Historian, AnalytiX, and MobileHMI: Version 10.97.2 (CVE-2022-2650, CVE-2023-4807)
AlarmWorX Multimedia (AlarmWorX64 MMX): All versions prior to 10.97.3 (CVE-2024-1182)
MobileHMI: All versions prior to 10.97.3 (CVE-2024-1573)
ICONICS Suite including GENESIS64, Hyper Historian, AnalytiX, and MobileHMI: All versions prior to 10.97.3 (CVE-2024-1574)
A bug in OpenSSL that might corrupt the internal state of the application on the Windows 64 platform when running on newer X86_64 processors supporting the AVX512-IFMA instructions.
The GENESIS64 Automatic Login feature, when used with MobileHMI in a certain specific condition, can result in improper privileges being given to a non-logged-in user.
Use of externally-controlled input to select classes or code (‘Unsafe Reflection') condition in the licensing service (used by ICONICS licensing) can result in an improper authorization condition.
COMPANY HEADQUARTERS LOCATION: ICONICS is headquartered in the United States. Mitsubishi Electric is headquartered in Japan.
3.4 RESEARCHER
Asher Davila of Palo Alto Networks reported AlarmWorX64 MMX Pager Agent vulnerability to ICONICS.
4. MITIGATIONS
Versions 10.97.3 and later have mitigations for these vulnerabilities. ICONICS recommends that users of its products take the following mitigation steps:
Use the 10.97.3 version.
If planning to use the AlarmWorX64 MMX Pager agent, follow the guidelines provided in the ICONICS Whitepaper on Security Vulnerabilities June 2024 edition.
ICONICS and Mitsubishi Electric recommends updating the ICONICS Suite with the latest security patches as they become available. ICONICS Suite security patches may be found here (login required).
ICONICS and Mitsubishi Electric is releasing security updates as critical fixes/rollup releases. Refer to the ICONICS Whitepaper on Security Vulnerabilities, the most recent version of which can be found here, and to the Mitsubishi Electric security advisory for information on the availability of the security updates.
CISA recommends users take defensive measures to minimize the risk of exploitation of these vulnerabilities, such as:
Locate control system networks and remote devices behind firewalls and isolating them from business networks.
When remote access is required, use more secure methods, such as virtual private networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.
CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.
Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.
CISA also recommends users take the following measures to protect themselves from social engineering attacks:
Do not click web links or open attachments in unsolicited email messages.
No known public exploitation specifically targeting these vulnerabilities has been reported to CISA at this time. These vulnerabilities have a high attack complexity.
Under certain circumstances, when the controller is in factory reset mode waiting for initial setup, it will broadcast its MAC address, serial number, and firmware version. Once configured, the controller will no longer broadcast this information.
Locate control system networks and remote devices behind firewalls and isolating them from business networks.
When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.
CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.
Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.
No known public exploitation specifically targeting this vulnerability has been reported to CISA at this time. This vulnerability is not exploitable remotely. This vulnerability has a high attack complexity.
Juniper Networks released a security bulletin to address a vulnerability in Junos OS: SRX Series. A cyber threat actor could exploit this vulnerability to cause a denial-of-service condition.
Users and administrators are encouraged to review the following and apply the necessary updates:
Progress Software released a security bulletin to address a vulnerability in MOVEit Transfer. A cyber threat actor could exploit this vulnerability to take control of an affected system.
Users and administrators are encouraged to review the following bulletin and apply the necessary updates:
The affected product's WEB HMI server's function to process HTTP requests has a security flaw (reflected XSS) that allows the execution of malicious scripts. Therefore, if a client PC with inadequate security measures accesses a product URL containing a malicious request, the malicious script may be executed on the client PC.
The affected products have built-in accounts with no passwords set. Therefore, if the product is operated without a password set by default, an attacker can break into the affected product.
CRITICAL INFRASTRUCTURE SECTORS: Critical Manufacturing, Energy, Food and Agriculture
COUNTRIES/AREAS DEPLOYED: Worldwide
COMPANY HEADQUARTERS LOCATION: Japan
3.4 RESEARCHER
Yokogawa reported these vulnerabilities to CISA.
4. MITIGATIONS
Yokogawa recommends customers using FAST/TOOLS to update to R10.04 and first apply patch software R10.04 SP3 and afterwards apply patch software I12560.
Yokogawa recommends customers using Collaborative Information Server (CI Server) to update to R1.03.00 and apply patch software R10.04 SP3.
For both platforms, if the password for the default account has not been changed, please change that password according to the documentation included with the patch software.
Yokogawa strongly recommends all customers to establish and maintain a full security program, not only for the vulnerability identified in this YSAR. Security program components are: Patch updates, Anti-virus, Backup and recovery, zoning, hardening, whitelisting, firewall, etc. Yokogawa can assist in setting up and running the security program continuously. For considering the most effective risk mitigation plan, as a starting point, Yokogawa can perform a security risk assessment.
For questions related to this report, please contact Yokogawa.
CISA recommends users take defensive measures to minimize the risk of exploitation of these vulnerabilities. CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.
Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.
CISA also recommends users take the following measures to protect themselves from social engineering attacks:
Do not click web links or open attachments in unsolicited email messages.
Johnson Controls recommends taking steps to minimize risks to all building automation systems. Further ICS security notices and product security guidance are located at the Johnson Controls product security website
CISA recommends users take defensive measures to minimize the risk of exploitation of this vulnerability, such as:
Locate control system networks and remote devices behind firewalls and isolating them from business networks.
When remote access is required, use more secure methods, such as virtual private networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.
CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.
Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.
CISA also recommends users take the following measures to protect themselves from social engineering attacks:
Do not click web links or open attachments in unsolicited email messages.
ATTENTION: Exploitable remotely/low attack complexity/public exploits are available
Vendor: marKoni
Equipment: Markoni-D (Compact) FM Transmitters, Markoni-DH (Exciter+Amplifiers) FM Transmitters
Vulnerabilities: Command Injection, Use of Hard-coded Credentials, Use of Client-Side Authentication, Improper Access Control
2. RISK EVALUATION
Successful exploitation of these vulnerabilities could allow an attacker to tamper with the product to bypass authentication or perform remote code execution.
3. TECHNICAL DETAILS
3.1 AFFECTED PRODUCTS
The following versions of TELSAT marKoni FM Transmitters are affected:
Markoni-D (Compact) FM Transmitters: All versions prior to 2.0.1
Markoni-DH (Exciter+Amplifiers) FM Transmitters: All versions prior to 2.0.1
TELSAT marKoni FM Transmitters are vulnerable to a command injection vulnerability through the manipulation of settings and could allow an attacker to gain unauthorized access to the system with administrative privileges.
TELSAT marKoni FM Transmitters are vulnerable to an attacker exploiting a hidden admin account that can be accessed through the use of hard-coded credentials.
TELSAT marKoni FM Transmitters are vulnerable to users gaining unauthorized access to sensitive information or performing actions beyond their designated permissions.
Locate control system networks and remote devices behind firewalls and isolating them from business networks.
When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.
CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.
Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.
No known public exploitation specifically targeting these vulnerabilities has been reported to CISA at this time.
Johnson Controls recommends taking steps to minimize risks to all building automation systems. Further ICS security notices and product security guidance are located at the Johnson Controls product security website
CISA recommends users take defensive measures to minimize the risk of exploitation of this vulnerability, such as:
Locate control system networks and remote devices behind firewalls and isolating them from business networks.
When remote access is required, use more secure methods, such as virtual private networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.
CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.
Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.
CISA also recommends users take the following measures to protect themselves from social engineering attacks:
Do not click web links or open attachments in unsolicited email messages.
Johnson Controls recommends taking steps to minimize risks to all building automation systems. Further ICS security notices and product security guidance are located at Johnson Controls product security website: https://www.johnsoncontrols.com/cyber-solutions/security-advisories Organizations observing any suspected malicious activity should follow their established internal procedures and report their findings to CISA for tracking and correlation against other incidents.
CISA recommends users take defensive measures to minimize the risk of exploitation of this vulnerability, such as:
Locate control system networks and remote devices behind firewalls and isolating them from business networks.
When remote access is required, use more secure methods, such as virtual private networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.
CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.
Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.
CISA also recommends users take the following measures to protect themselves from social engineering attacks:
Do not click web links or open attachments in unsolicited email messages.
Login
