Executive Summary

The United States National Security Agency (NSA), the U.S. Federal Bureau of Investigation (FBI), the U.S. Cybersecurity and Infrastructure Security Agency (CISA), the Japan National Police Agency (NPA), and the Japan National Center of Incident Readiness and Strategy for Cybersecurity (NISC) (hereafter referred to as the “authoring agencies”) are releasing this joint cybersecurity advisory (CSA) to detail activity of the People’s Republic of China (PRC)-linked cyber actors known as BlackTech. BlackTech has demonstrated capabilities in modifying router firmware without detection and exploiting routers’ domain-trust relationships for pivoting from international subsidiaries to headquarters in Japan and the U.S. — the primary targets. The authoring agencies recommend implementing the mitigations described to detect this activity and protect devices from the backdoors the BlackTech actors are leaving behind.

BlackTech (a.k.a. Palmerworm, Temp.Overboard, Circuit Panda, and Radio Panda) actors have targeted government, industrial, technology, media, electronics, and telecommunication sectors, including entities that support the militaries of the U.S. and Japan. BlackTech actors use custom malware, dual-use tools, and living off the land tactics, such as disabling logging on routers, to conceal their operations. This CSA details BlackTech’s tactics, techniques, and procedures (TTPs), which highlights the need for multinational corporations to review all subsidiary connections, verify access, and consider implementing Zero Trust models to limit the extent of a potential BlackTech compromise.

For more information on the risks posed by this deep level of unauthorized access, see the CSA People’s Republic of China State-Sponsored Cyber Actors Exploit Network Providers and Devices.[1]

Download the PDF version of this report: PDF, 808 KB

Technical Details

This advisory uses the MITRE^® ATT&CK^® for Enterprise framework, version 13.1. See the Appendix: MITRE ATT&CK Techniques for all referenced TTPs.

Background

Active since 2010, BlackTech actors have historically targeted a wide range of U.S. and East Asia public organizations and private industries. BlackTech actors’ TTPs include developing customized malware and tailored persistence mechanisms for compromising routers. These TTPs allow the actors to disable logging [T1562] and abuse trusted domain relationships [T1199] to pivot between international subsidiaries and domestic headquarters’ networks.

Observable TTPs

BlackTech cyber actors use custom malware payloads and remote access tools (RATs) to target victims’ operating systems. The actors have used a range of custom malware families targeting Windows^®, Linux^®, and FreeBSD^® operating systems. Custom malware families employed by BlackTech include:

• BendyBear [S0574]
• Bifrose
• BTSDoor
• FakeDead (a.k.a. TSCookie) [S0436]
• Flagpro [S0696]
• FrontShell (FakeDead’s downloader module)
• IconDown
• PLEAD [S0435]
• SpiderPig
• SpiderSpring
• SpiderStack
• WaterBear [S0579]

BlackTech actors continuously update these tools to evade detection [TA0005] by security software. The actors also use stolen code-signing certificates [T1588.003] to sign the malicious payloads, which make them appear legitimate and therefore more difficult for security software to detect [T1553.002].

BlackTech actors use living off the land TTPs to blend in with normal operating system and network activities, allowing them to evade detection by endpoint detection and response (EDR) products. Common methods of persistence on a host include NetCat shells, modifying the victim registry [T1112] to enable the remote desktop protocol (RDP) [T1021.001], and secure shell (SSH) [T1021.004]. The actors have also used SNScan for enumeration [TA0007], and a local file transfer protocol (FTP) server [T1071.002] to move data through the victim network. For additional examples of malicious cyber actors living off the land, see People’s Republic of China State-Sponsored Cyber Actor Living off the Land to Evade Detection.[2]

Pivoting from international subsidiaries

The PRC-linked BlackTech actors target international subsidiaries of U.S. and Japanese companies. After gaining access [TA0001] to the subsidiaries’ internal networks, BlackTech actors are able to pivot from the trusted internal routers to other subsidiaries of the companies and the headquarters’ networks. BlackTech actors exploit trusted network relationships between an established victim and other entities to expand their access in target networks.

Specifically, upon gaining an initial foothold into a target network and gaining administrator access to network edge devices, BlackTech cyber actors often modify the firmware to hide their activity across the edge devices to further maintain persistence in the network. To extend their foothold across an organization, BlackTech actors target branch routers—typically smaller appliances used at remote branch offices to connect to a corporate headquarters—and then abuse the trusted relationship [T1199] of the branch routers within the corporate network being targeted. BlackTech actors then use the compromised public-facing branch routers as part of their infrastructure for proxying traffic [TA0011], blending in with corporate network traffic, and pivoting to other victims on the same corporate network [T1090.002].

Maintaining access via stealthy router backdoors

BlackTech has targeted and exploited various brands and versions of router devices. TTPs against routers enable the actors to conceal configuration changes, hide commands, and disable logging while BlackTech actors conduct operations. BlackTech actors have compromised several Cisco^® routers using variations of a customized firmware backdoor [T1542.004]. The backdoor functionality is enabled and disabled through specially crafted TCP or UDP packets [T1205]. This TTP is not solely limited to Cisco routers, and similar techniques could be used to enable backdoors in other network equipment.

In some cases, BlackTech actors replace the firmware for certain Cisco IOS^®-based routers with malicious firmware. Although BlackTech actors already had elevated privileges [TA0004] on the router to replace the firmware via command-line execution, the malicious firmware is used to establish persistent backdoor access [TA0003] and obfuscate future malicious activity. The modified firmware uses a built-in SSH backdoor [T1556.004], allowing BlackTech actors to maintain access to the compromised router without BlackTech connections being logged [T1562.003]. BlackTech actors bypass the router’s built-in security features by first installing older legitimate firmware [T1601.002] that they then modify in memory to allow the installation of a modified, unsigned bootloader and modified, unsigned firmware [T1601.001]. The modified bootloader enables the modified firmware to continue evading detection [T1553.006], however, it is not always necessary.

BlackTech actors may also hide their presence and obfuscate changes made to compromised Cisco routers by hiding Embedded Event Manager (EEM) policies—a feature usually used in Cisco IOS to automate tasks that execute upon specified events—that manipulate Cisco IOS Command-Line Interface (CLI) command results. On a compromised router, the BlackTech-created EEM policy waits for specific commands to execute obfuscation measures or deny execution of specified legitimate commands. This policy has two functions: (1) to remove lines containing certain strings in the output of specified, legitimate Cisco IOS CLI commands [T1562.006], and (2) prevent the execution of other legitimate CLI commands, such as hindering forensic analysis by blocking copy, rename, and move commands for the associated EEM policy [T1562.001].

Firmware replacement process

BlackTech actors utilize the following file types to compromise the router. These files are downloaded to the router via FTP or SSH.

BlackTech actors use the Cisco router’s CLI to replace the router’s IOS image firmware. The process begins with the firmware being modified in memory—also called hot patching—to allow the installation of a modified bootloader and modified firmware capable of bypassing the router’s security features. Then, a specifically constructed packet triggers the router to enable the backdoor that bypasses logging and the access control list (ACL). The steps are as follows:

1. Download old legitimate firmware.
2. Set the router to load the old legitimate firmware and reboot with the following command(s):
   

   config t no boot system usbflash0 [filename] boot system usbflash0 [filename] end write reload

3. Download the modified bootloader and modified firmware.
4. Set the router to load the modified firmware with the following command(s):
   

   conf t no boot system usbflash0 [filename] boot system usbflash0 [filename] end write

5. Load the modified bootloader (the router reboots automatically) with the following command:
   

   upgrade rom file bootloader

6. Enable access by sending a trigger packet that has specific values within the UDP data or TCP Sequence Number field and the Maximum Segment Size (MSS) parameter within the TCP Options field.

Modified bootloader

To allow the modified bootloader and firmware to be installed on Cisco IOS without detection, the cyber actors install an old, legitimate firmware and then modify that running firmware in memory to bypass firmware signature checks in the Cisco ROM Monitor (ROMMON) signature validation functions. The modified version’s instructions allow the actors to bypass functions of the IOS Image Load test and the Field Upgradeable ROMMON Integrity test.

Modified firmware

BlackTech actors install modified IOS image firmware that allows backdoor access via SSH to bypass the router’s normal logging functions. The firmware consists of a Cisco IOS loader that will load an embedded IOS image.

BlackTech actors hook several functions in the embedded Cisco IOS image to jump to their own code. They overwrite existing code to handle magic packet checking, implement an SSH backdoor, and bypass logging functionality on the compromised router. The modified instructions bypass command logging, IP address ACLs, and error logging.

To enable the backdoor functions, the firmware checks for incoming trigger packets and enables or disables the backdoor functionality. When the backdoor is enabled, associated logging functions on the router are bypassed. The source IP address is stored and used to bypass ACL handling for matching packets. The SSH backdoor includes a special username that does not require additional authentication.

Detection and Mitigation Techniques

In order to detect and mitigate this BlackTech malicious activity, the authoring agencies strongly recommend the following detection and mitigation techniques. It would be trivial for the BlackTech actors to modify values in their backdoors that would render specific signatures of this router backdoor obsolete. For more robust detection, network defenders should monitor network devices for unauthorized downloads of bootloaders and firmware images and reboots. Network defenders should also monitor for unusual traffic destined to the router, including SSH.

The following are the best mitigation practices to defend against this type of malicious activity:

• Disable outbound connections by applying the “transport output none” configuration command to the virtual teletype (VTY) lines. This command will prevent some copy commands from successfully connecting to external systems.
  Note: An adversary with unauthorized privileged level access to a network device could revert this configuration change.[3]
• Monitor both inbound and outbound connections from network devices to both external and internal systems. In general, network devices should only be connecting to nearby devices for exchanging routing or network topology information or with administrative systems for time synchronization, logging, authentication, monitoring, etc. If feasible, block unauthorized outbound connections from network devices by applying access lists or rule sets to other nearby network devices. Additionally, place administrative systems in separate virtual local area networks (VLANs) and block all unauthorized traffic from network devices destined for non-administrative VLANs.[4]
• Limit access to administration services and only permit IP addresses used by network administrators by applying access lists to the VTY lines or specific services. Monitor logs for successful and unsuccessful login attempts with the “login on-failure log” and “login on-success log” configuration commands, or by reviewing centralized Authentication, Authorization, and Accounting (AAA) events.[3]
• Upgrade devices to ones that have secure boot capabilities with better integrity and authenticity checks for bootloaders and firmware. In particular, highly prioritize replacing all end-of-life and unsupported equipment as soon as possible.[3],[5]
• When there is a concern that a single password has been compromised, change all passwords and keys.[3]
• Review logs generated by network devices and monitor for unauthorized reboots, operating system version changes, changes to the configuration, or attempts to update the firmware. Compare against expected configuration changes and patching plans to verify that the changes are authorized.[3]
• Periodically perform both file and memory verification described in the Network Device Integrity (NDI) Methodology documents to detect unauthorized changes to the software stored and running on network devices.[3]
• Monitor for changes to firmware. Periodically take snapshots of boot records and firmware and compare against known good images.[3]

Works Cited

[1]    Joint CSA, People’s Republic of China State-Sponsored Cyber Actors Exploit Network Providers and Devices, https://media.defense.gov/2022/Jun/07/2003013376/-1/-1/0/CSA_PRC_SPONSORED_CYBER_ACTORS_EXPLOIT_NETWORK_PROVIDERS_DEVICES_TLPWHITE.PDF
[2]    Joint CSA, People’s Republic of China State-Sponsored Cyber Actor Living off the Land to Evade Detection, https://media.defense.gov/2023/May/24/2003229517/-1/-1/0/CSA_PRC_State_Sponsored_Cyber_Living_off_the_Land_v1.1.PDF
[3]    NSA, Network Infrastructure Security Guide, https://media.defense.gov/2022/Jun/15/2003018261/-1/-1/0/CTR_NSA_NETWORK_INFRASTRUCTURE_SECURITY_GUIDE_20220615.PDF
[4]    NSA, Performing Out-of-Band Network Management, https://media.defense.gov/2020/Sep/17/2002499616/-1/-1/0/PERFORMING_OUT_OF_BAND_NETWORK_MANAGEMENT20200911.PDF 
[5]    Cisco, Attackers Continue to Target Legacy Devices, https://community.cisco.com/t5/security-blogs/attackers-continue-to-target-legacy-devices/ba-p/4169954

Disclaimer of endorsement

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

Trademark recognition

Cisco and Cisco IOS are registered trademarks of Cisco Technology, Inc.
FreeBSD is a registered trademark of The FreeBSD Foundation.
Linux is a registered trademark of Linus Torvalds.
MITRE and MITRE ATT&CK are registered trademarks of The MITRE Corporation.
Windows is a registered trademark of Microsoft Corporation.

Purpose

This document was developed in furtherance of the authoring agencies’ cybersecurity missions, including their responsibilities to identify and disseminate cyber threats, and to develop and issue cybersecurity specifications and mitigations.

Contact

NSA Cybersecurity Report Questions and Feedback: CybersecurityReports@nsa.gov 
NSA’s Defense Industrial Base Inquiries and Cybersecurity Services: DIB_Defense@cyber.nsa.gov 
NSA Media Inquiries / Press Desk: 443-634-0721, MediaRelations@nsa.gov

U.S. organizations: Report incidents and anomalous activity to CISA 24/7 Operations Center at Report@cisa.dhs.gov, cisa.gov/report, or (888) 282-0870 and/or to the FBI via your local FBI field office.

Appendix: MITRE ATT&CK Techniques

See Tables 2-9 for all referenced BlackTech tactics and techniques in this advisory.

Source de l’article sur us-cert.gov

SUMMARY

The Cybersecurity and Infrastructure Security Agency (CISA), Federal Bureau of Investigation (FBI), and Cyber National Mission Force (CNMF) identified the presence of indicators of compromise (IOCs) at an Aeronautical Sector organization as early as January 2023. Analysts confirmed that nation-state advanced persistent threat (APT) actors exploited CVE-2022-47966 to gain unauthorized access to a public-facing application (Zoho ManageEngine ServiceDesk Plus), establish persistence, and move laterally through the network. This vulnerability allows for remote code execution on the ManageEngine application. Additional APT actors were also observed exploiting CVE-2022-42475 to establish presence on the organization’s firewall device.

CISA and co-sealers are releasing this joint Cybersecurity Advisory (CSA) to provide network defenders with tactics, techniques, and procedures (TTPs), IOCs, and methods to detect and protect against similar exploitation.

Download the PDF version of this report:

For a downloadable copy of IOCs, see:

For a downloadable copy of the Malware Analysis Report (MAR) accompanying this CSA, see:

Note: This advisory uses the MITRE ATT&CK® for Enterprise framework, version 13. See Tables 3-13 for the APT actors’ activity mapped to MITRE ATT&CK tactics and techniques with corresponding mitigation and/or detection recommendations.

Overview

By request of the impacted organization, CISA conducted an incident response engagement from February to April 2023. CISA and co-sealers assess that beginning as early as January 2023, multiple nation-state APT actors were present on the organization’s network via at least two initial access vectors:

• Initial Access Vector 1: APT actors exploited CVE-2022-47966 to access the organization’s web server hosting the public-facing application, Zoho ManageEngine ServiceDesk Plus.
• Initial Access Vector 2: APT actors exploited CVE-2022-42475 to access the organization’s firewall device.

CISA and co-sealers identified an array of threat actor activity, to include overlapping TTPs across multiple APT actors. Per the activity conducted, APT actors often scan internet-facing devices for vulnerabilities that can be easily exploited. Firewall, virtual private networks (VPNs), and other edge network infrastructure continue to be of interest to malicious cyber actors. When targeted, they can be leveraged to expand targeted network access, serve as malicious infrastructure, or a mixture of both.

APT Actor Activity

Initial Access Vector 1

As early as January 2023, APT actors exploited CVE-2022-47966 [T1190] for initial access to the organization’s web server hosting the public-facing application, Zoho ManageEngine ServiceDesk Plus. CISA observed indications in log files that a connection to the known malicious IP address 192.142.226[.]153 was made as part of initial exploitation.

Through exploitation of CVE-2022-47966, APT actors achieved root level access on the web server and created a local user account [T1136.001] named Azure with administrative privileges [T1068]. Actors were further able to download malware, enumerate the network, collect administrative user credentials, and move laterally through the organization’s network. CISA and co-sealers were unable to determine if proprietary information was accessed, altered, or exfiltrated. This was due to the organization not clearly defining where their data was centrally located and CISA having limited network sensor coverage.

Initial Access Vector 2

Additional APT actors exploited CVE-2022-42475 on the organization’s firewall device, which was indicated by multiple successful VPN connections from known-malicious IPs between February 1-16, 2023. It was identified that APT actors compromised and used disabled, legitimate administrative account credentials [T1078.003] from a previously hired contractor—of which the organization confirmed the user had been disabled prior to the observed activity.

Analysis identified that a common behavior for these threat actors was to use disabled administrative account credentials and delete logs from several critical servers in the environment [T1070.001]. This prevented the ability to detect follow-on exploitation or data exfiltration. CISA and co-sealers were also unable to further track the activity due to the organization not having Network Address Translation (NAT) IP logging enabled.

APT actors initiated multiple Transport Layer Security (TLS)-encrypted sessions [T1573.002] on Transmission Control Protocol (TCP) port 10443 [T1571], indicating successful exchanges of data transfer from the firewall device. APT actors were observed connecting to the device from the following actor-controlled C2 IP addresses:

• 144.202.2[.]71
• 207.246.105[.]240
• 45.77.121[.]232
• 47.90.240[.]218

APT actors further leveraged legitimate credentials to move from the firewall to a web server, where multiple web shells were loaded—among other locations, such as the OWA server—into the following directories. Note: The following file paths to these web shells were received in coordination with a trusted third-party; however, the artifacts were not received for analysis.

• c:Program FilesMicrosoft Office Web AppsRootWebsiteen-usresource.aspx
• c:inetpubwwwrootuninetcssfont-awesomecssdiscover.ashx
• c:inetpubwwwrootuninetcssfont-awesomecssconfiglogin.ashx
• c:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions15templatelayoutsapproveinfo.aspx
• c:Program FilesMicrosoft Office Web AppsRootWebsiteinfos.aspx
• c:Program FilesMicrosoft Office Web AppsRootWebsiteerrorinfo.aspx
• c:Program FilesMicrosoft Office Web AppsRootWebsiteinfos.ashx
• c:Program FilesMicrosoft Office Web AppsRootWebsiteen-userror.aspx
• c:Program FilesMicrosoft Office Web AppsRootWebsiteen-usinfos.aspx
• c:Program FilesMicrosoft Office Web AppsRootWebsiteen-usinfo.aspx
• c:Program FilesMicrosoft Office Web AppsRootWebsiteen-usinfo-1.aspx
• c:Program FilesMicrosoft Office Web AppsRootWebsiteen-usnew_list.aspx
• c:Program FilesMicrosoft Office Web AppsRootWebsiteen-userrorinfo.aspx
• c:Program FilesMicrosoft Office Web AppsRootWebsiteen-uslgnbotr.ashx
• c:inetpubpasswordchangeLECPNJYRH.aspx
• c:inetpubpasswordchange9ehj.aspx
• c:inetpubwwwrootwssVirtualDirectoriesPortal80_vti_pvtservicesinfo.ashx
• c:inetpubwwwrootwssVirtualDirectoriesPortal80_vti_pvtservices.aspx
• c:inetpubredirectedSites[REDACTED]productsuns1fw.aspx
• c:inetpubredirectedSites[REDACTED]productsuns1ew.aspx

The following IP addresses were identified as associated with the loaded web shells:

• 45.90.123[.]194
• 154.6.91[.]26
• 154.6.93[.]22
• 154.6.93[.]5
• 154.6.93[.]12
• 154.6.93[.]32
• 154.6.93[.]24
• 184.170.241[.]27
• 191.96.106[.]40
• 102.129.145[.]232

Forensic Timeline of APT Actor Activity

Tables 1 and 2 list the timeline of events discovered during the incident response, as well as tools used by the APT actors to conduct their operations, respectively. All timestamps are presented in Coordinated Universal Time (UTC).

Post-engagement analysis was extended but analysts were unable to determine additional actions taken by the APT actors, likely due to a lack of sensor coverage and data unavailability. With the data available, it was determined APT actors used the tools listed in Table 2 during their operations.

MITRE ATT&CK TACTICS AND TECHNIQUES

See Tables 3-13 for all referenced APT actors’ tactics and techniques for enterprise environments in this advisory. For assistance with mapping malicious cyber activity to the MITRE ATT&CK framework, see CISA and MITRE ATT&CK’s Best Practices for MITRE ATT&CK Mapping and CISA’s Decider Tool.

DETECTION METHODS

CISA and co-sealers recommend reviewing Tables 3-13: Identified ATT&CK Techniques for Enterprise in conjunction with the detections in this section to identify similar activity.

• Enable logging for new user creation [DS0002], as well as monitor executed commands and arguments for actions that are associated with local account creation, such as net user /add, useradd, and dscl -create [DS0017].
• Monitor for newly constructed scheduled tasks by enabling the “Microsoft-Windows-TaskScheduler/Operational” setting within the event logging service. Monitor for changes made to scheduled tasks that may attempt to manipulate features of their artifacts to make them appear legitimate or benign to users and/or security tools [DS0003].
• Monitor for API calls that may create or modify Windows services (ex: CreateServiceW()) to repeatedly execute malicious payloads as part of persistence [DS0009].
• Monitor executed commands and arguments that may attempt to access credential material stored in the process memory of the LSASS [DS0017].
• Monitor for user accounts logged into systems associated with RDP (ex: Windows EID 4624 Logon Type 10) [DS0028].
• Monitor for newly-constructed network connections associated with pings/scans that may attempt to collect a listing of other systems by IP address, hostname, or other logical identifier on a network that may be used for lateral movement from the current system [DS0029].
• Conduct full port scans (1-65535) on internet-facing systems—not just a subset of the ports.

MITIGATIONS

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

Manage Vulnerabilities and Configurations [CPG 1.E, CPG 3.A]

CISA and co-sealers identified that exploitation of CVE-2022-47966 granted initial access to the public-facing application, Zoho ManageEngine ServiceDesk Plus. Multiple Zoho ManageEngine on-premises products, such as ServiceDesk Plus through 14003, allow remote code execution due to use of version 1.4.1 of Apache XML Security for Java (also known as xmlsec) from the Apache Santuario project. Due to the xmlsec XSLT features by design in that version, the application is responsible for certain security protections. CISA and co-sealers recommend the following:

• Document device configurations [CPG 2.O]. Organizations should maintain updated documentation describing the current configuration details of all critical IT assets (and OT, where applicable), as this facilitates more effective vulnerability and response activities.
• Keep all software up to date and patch systems for known exploited vulnerabilities. In places with known exploited vulnerabilities on an endpoint device (e.g., firewall security appliances), conduct investigation prior to patching [CPG 1.E].
• Follow a routine patching cycle [M1051] for all operating systems, applications, and software (including all third-party software) to mitigate the potential for exploitation.
• Prioritize remediation of vulnerabilities on internet-facing systems, for example, by conducting continuous automated and/or routine vulnerability scans [M1016]. CISA offers a range of services at no cost, including scanning and testing to help organizations reduce exposure to threats via mitigating attack vectors. Specifically, Cyber Hygiene services can help provide a second-set of eyes on organizations’ internet-accessible assets. Organizations can email vulnerability@cisa.dhs.gov with the subject line, “Requesting Cyber Hygiene Services” to get started. For additional guidance on remediating these vulnerabilities, see CISA Insights – Remediate Vulnerabilities for Internet-Accessible Systems.
• Deploy security.txt files [CPG 4.C]. All public-facing web domains have a security.txt file that conforms to the recommendations in RFC 9116.[9]

Segment Networks [CPG 2.F]

CISA and co-sealers identified that the organization did not employ proper network segmentation, such as a demilitarized zone (DMZ), during the initial discovery phase of the incident response. A DMZ serves as a perimeter network that protects and adds an extra layer of security to an organization’s internal local area network (LAN) from untrusted traffic.

• Employ proper network segmentation, such as a DMZ, and ensure to address the following recommendations. Note: The end goal of a DMZ network is to allow an organization to access untrusted networks, such as the internet, while ensuring its private network or LAN remains secure. Organizations typically store external-facing services and resources, as well as servers for DNS, File Transfer Protocol (FTP), mail, proxy, Voice over Internet Protocol (VoIP), and web servers in the DMZ [CPG 2.K, CPG 2.W].
  • Limit internet-facing port exposure for critical resources in the DMZ networks.
  • Limit exposed ports to only required IP addresses and avoid placing wildcards in destination port or host entries.
  • Ensure unsecured protocols like FTP and HTTP are limited in use and restricted to specific IP ranges.
  • If data flows from untrusted zone to trusted zone, ensure it is conducted over a secure protocol like HTTPS with mandatory multi-factor authentication.
• Use a firewall or web-application firewall (WAF) and enable logging to prevent/detect potential exploitation attempts [M1050]. Review ingress and egress firewall rules and block all unapproved protocols. Limit risky (but approved) protocols through rules.
  • Use WAF to limit exposure to just approved ports, as well as monitor file changes in web directories.
• Implement network segmentation to separate network segments based on role and functionality. Proper network segmentation significantly reduces the ability for threat actor lateral movement by controlling traffic flows between—and access to—various subnetworks. See CISA’s Layering Network Security Through Segmentation infographic and the National Security Agency’s (NSA’s) Segment Networks and Deploy Application-Aware Defenses.

Manage Accounts, Permissions, and Workstations

APT actors were able to leverage disabled administrative accounts, as well as clear logs on several critical servers, which prevented the ability to detect follow-on exploitation or data exfiltration. CISA and co-sealers recommend the following:

• Use phishing-resistant multi-factor authentication (MFA) [CPG 2.H] (e.g., security tokens) for remote access and access to any sensitive data repositories. Implement phishing-resistant MFA for as many services possible—particularly for webmail and VPNs—for accounts that access critical systems and privileged accounts that manage backups. MFA should also be used for remote logins [M1032]. For additional guidance on secure MFA configurations, visit cisa.gov/MFA and CISA’s Implementing Phishing-Resistant MFA Factsheet.
• Employ strong password management alongside other attribute-based information, such as device information, time of access, user history, and geolocation data. Set a password policy to require complex passwords for all users (minimum of 16 characters) and enforce this new requirement as users’ passwords expire [CPG 2.A, CPG 2.B, CPG 2.C].
• Implement the principle of least privilege to decrease threat actors’ abilities to access key network resources.
• Limit the ability of a local administrator account to log in from a local interactive session [CPG 2.E] (e.g., “Deny access to this computer from the network”) and prevent access via an RDP session.
• Establish policy and procedure for the prompt removal of unnecessary (disabled) accounts and groups from the enterprise that are no longer needed, especially privileged accounts. Implement and enforce use of Local Administrator Password Solution (LAPS).
• Control and limit local administration, ensuring administrative users do not have access to other systems outside of the local machine and across the domain.
• Create a change control process for all privilege escalations and role changes on user accounts. Enable alerts on privilege escalations and role changes, as well as log privileged user changes in the network environment and create alerts for abnormal events.
• Create and deploy a secure system baseline image to all workstations. See Microsoft’s guidance on Using Security Baselines in Your Organization.
• Implement policies to block workstation-to-workstation RDP connections [CPG 2.V] through a Group Policy Object on Windows, or by a similar mechanism. The RDP service should be disabled if it is unnecessary [M1042].

Secure Remote Access Software

Remote access software provides a proactive and flexible approach for organizations to internally oversee networks, computers, and other devices; however, cyber threat actors increasingly co-opt these tools for access to victim systems. APT actors were observed using legitimate remote access tools—ConnectWise ScreenConnect and AnyDesk—to connect to victim hosts within the organization’s environment and further conduct malicious operations. CISA and co-sealers recommend the following:

• Establish a software behavior baseline to detect anomalies in behavior [CPG 2.T, CPG 2.U].
• Monitor for unauthorized use of remote access software using endpoint detection tools.

For more information, see CISA’s joint Guide to Securing Remote Access Software on best practices for using remote capabilities and how to detect and defend against malicious actors abusing this software.

Other Best Practice Mitigation Recommendations

• Use application allowlists on domain controllers, administrative hosts, and other sensitive systems. Following exploitation of the public-facing application (Zoho ManageEngine ServiceDesk Plus), APT actors were able to download and execute multiple files on the system, which were then utilized to enumerate the network and perform reconnaissance operations.
  • Use directory allowlisting rather than attempting to list every possible permutation of applications in a network environment. Safe defaults allow applications to run from PROGRAMFILES, PROGRAMFILES(X86), and SYSTEM32. Disallow all other locations unless an exception is granted and documented. Application directory allowlisting can be enabled through Microsoft Software Restriction Policy or AppLocker and can prevent the execution of unauthorized software.
• Audit scheduled tasks and validate all findings via a Group Policy Object (GPO) or endpoint detection and response (EDR) solution.
• Follow Microsoft’s Best Practices for Securing Active Directory.
• Review NSA’s Network Infrastructure Security Guide.

VALIDATE SECURITY CONTROLS

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

To get started:

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

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

RESOURCES

• NIST: NVD CVE-2022-47966
• NIST: NVD CVE-2022-42475
• CISA: KEV List
• MITRE ATT&CK for Enterprise v13.1
• CISA, MITRE: Best Practices for MITRE ATT&CK Mapping
• CISA: Decider Tool
• CISA: Cross-Sector Cybersecurity Performance Goals
• CISA: Cyber Hygiene Services
• CISA: Remediate Vulnerabilities for Internet-Accessible Systems
• CISA: Layering Network Security Through Segmentation
• NSA: Segment Networks and Deploy Application-Aware Defenses
• CISA: MFA
• CISA: Implementing Phishing-Resistant MFA
• Microsoft: Using Security Baselines in Your Organization
• CISA: Guide to Securing Remote Access Software
• Microsoft: Best Practices for Securing Active Directory
• NSA: Network Infrastructure Security Guide

DISCLAIMER

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

REFERENCES

1. Snort: Known Malicious User-Agent String – Mirai
2. MITRE: Mimikatz
3. MITRE: Ngrok
4. AA22-320A: Iranian Government-Sponsored APT Actors Compromise Federal Network, Deploy Crypto Miner, Credential Harvester
5. AA22-294A: #StopRansomware: Daixin Team
6. AA23-075A: #StopRansomware: LockBit 3.0
7. GitHub: Interactsh
8. Microsoft: Quser
9. Internet Engineering Task Force (IETF): RFC 9116

VERSION HISTORY

September 7, 2023: Initial version.

Source de l’article sur us-cert.gov

SUMMARY

The following cybersecurity agencies coauthored this joint Cybersecurity Advisory (CSA):

• United States: The Cybersecurity and Infrastructure Security Agency (CISA), National Security Agency (NSA), and Federal Bureau of Investigation (FBI)
• Australia: Australian Signals Directorate’s Australian Cyber Security Centre (ACSC)
• Canada: Canadian Centre for Cyber Security (CCCS)
• New Zealand: New Zealand National Cyber Security Centre (NCSC-NZ) and Computer Emergency Response Team New Zealand (CERT NZ)
• United Kingdom: National Cyber Security Centre (NCSC-UK)

This advisory provides details on the Common Vulnerabilities and Exposures (CVEs) routinely and frequently exploited by malicious cyber actors in 2022 and the associated Common Weakness Enumeration(s) (CWE). In 2022, malicious cyber actors exploited older software vulnerabilities more frequently than recently disclosed vulnerabilities and targeted unpatched, internet-facing systems.

The authoring agencies strongly encourage vendors, designers, developers, and end-user organizations to implement the recommendations found within the Mitigations section of this advisory—including the following—to reduce the risk of compromise by malicious cyber actors.

• Vendors, designers, and developers: Implement secure-by-design and -default principles and tactics to reduce the prevalence of vulnerabilities in your software.
  • Follow the Secure Software Development Framework (SSDF), also known as SP 800-218, and implement secure design practices into each stage of the software development life cycle (SDLC). As part of this, establish a coordinated vulnerability disclosure program that includes processes to determine root causes of discovered vulnerabilities.
  • Prioritize secure-by-default configurations, such as eliminating default passwords, or requiring addition configuration changes to enhance product security.
  • Ensure that published CVEs include the proper CWE field identifying the root cause of the vulnerability.
• End-user organizations:
  • Apply timely patches to systems. Note: First check for signs of compromise if CVEs identified in this CSA have not been patched.
  • Implement a centralized patch management system.
  • Use security tools, such as endpoint detection and response (EDR), web application firewalls, and network protocol analyzers.
  • Ask your software providers to discuss their secure by design program and to provide links to information about how they are working to remove classes of vulnerabilities and to set secure default settings.

Download the PDF version of this report:

TECHNICAL DETAILS

Key Findings

In 2022, malicious cyber actors exploited older software vulnerabilities more frequently than recently disclosed vulnerabilities and targeted unpatched, internet-facing systems. Proof of concept (PoC) code was publicly available for many of the software vulnerabilities or vulnerability chains, likely facilitating exploitation by a broader range of malicious cyber actors.

Malicious cyber actors generally have the most success exploiting known vulnerabilities within the first two years of public disclosure—the value of such vulnerabilities gradually decreases as software is patched or upgraded. Timely patching reduces the effectiveness of known, exploitable vulnerabilities, possibly decreasing the pace of malicious cyber actor operations and forcing pursuit of more costly and time-consuming methods (such as developing zero-day exploits or conducting software supply chain operations).

Malicious cyber actors likely prioritize developing exploits for severe and globally prevalent CVEs. While sophisticated actors also develop tools to exploit other vulnerabilities, developing exploits for critical, wide-spread, and publicly known vulnerabilities gives actors low-cost, high-impact tools they can use for several years. Additionally, cyber actors likely give higher priority to vulnerabilities that are more prevalent in their specific targets’ networks. Multiple CVE or CVE chains require the actor to send a malicious web request to the vulnerable device, which often includes unique signatures that can be detected through deep packet inspection.

Top Routinely Exploited Vulnerabilities

Table 1 shows the top 12 vulnerabilities the co-authors observed malicious cyber actors routinely exploiting in 2022:

• CVE-2018-13379. This vulnerability, affecting Fortinet SSL VPNs, was also routinely exploited in 2020 and 2021. The continued exploitation indicates that many organizations failed to patch software in a timely manner and remain vulnerable to malicious cyber actors.
• CVE-2021-34473, CVE-2021-31207, CVE-2021-34523. These vulnerabilities, known as ProxyShell, affect Microsoft Exchange email servers. In combination, successful exploitation enables a remote actor to execute arbitrary code. These vulnerabilities reside within the Microsoft Client Access Service (CAS), which typically runs on port 443 in Microsoft Internet Information Services (IIS) (e.g., Microsoft’s web server). CAS is commonly exposed to the internet to enable users to access their email via mobile devices and web browsers.
• CVE-2021-40539. This vulnerability enables unauthenticated remote code execution (RCE) in Zoho ManageEngine ADSelfService Plus and was linked to the usage of an outdated third-party dependency. Initial exploitation of this vulnerability began in late 2021 and continued throughout 2022.
• CVE-2021-26084. This vulnerability, affecting Atlassian Confluence Server and Data Center (a web-based collaboration tool used by governments and private companies) could enable an unauthenticated cyber actor to execute arbitrary code on vulnerable systems. This vulnerability quickly became one of the most routinely exploited vulnerabilities after a PoC was released within a week of its disclosure. Attempted mass exploitation of this vulnerability was observed in September 2021.
• CVE-2021- 44228. This vulnerability, known as Log4Shell, affects Apache’s Log4j library, an open-source logging framework incorporated into thousands of products worldwide. An actor can exploit this vulnerability by submitting a specially crafted request to a vulnerable system, causing the execution of arbitrary code. The request allows a cyber actor to take full control of a system. The actor can then steal information, launch ransomware, or conduct other malicious activity.[1] Malicious cyber actors began exploiting the vulnerability after it was publicly disclosed in December 2021, and continued to show high interest in CVE-2021- 44228 through the first half of 2022.
• CVE-2022-22954, CVE-2022-22960. These vulnerabilities allow RCE, privilege escalation, and authentication bypass in VMware Workspace ONE Access, Identity Manager, and other VMware products. A malicious cyber actor with network access could trigger a server-side template injection that may result in remote code execution. Exploitation of CVE-2022-22954 and CVE-2022-22960 began in early 2022 and attempts continued throughout the remainder of the year.
• CVE-2022-1388. This vulnerability allows unauthenticated malicious cyber actors to bypass iControl REST authentication on F5 BIG-IP application delivery and security software.
• CVE-2022-30190. This vulnerability impacts the Microsoft Support Diagnostic Tool (MSDT) in Windows. A remote, unauthenticated cyber actor could exploit this vulnerability to take control of an affected system.
• CVE-2022-26134. This critical RCE vulnerability affects Atlassian Confluence and Data Center. The vulnerability, which was likely initially exploited as a zero-day before public disclosure in June 2022, is related to an older Confluence vulnerability (CVE-2021-26084), which cyber actors also exploited in 2022.

Additional Routinely Exploited Vulnerabilities

In addition to the 12 vulnerabilities listed in Table 1, the authoring agencies identified vulnerabilities—listed in Table 2—that were also routinely exploited by malicious cyber actors in 2022.

MITIGATIONS

Vendors and Developers

The authoring agencies recommend vendors and developers take the following steps to ensure their products are secure by design and default:

• Identify repeatedly exploited classes of vulnerability. Perform an analysis of both CVEs and known exploited vulnerabilities to understand which classes of vulnerability are identified more than others. Implement appropriate mitigations to eliminate those classes of vulnerability. For example, if a product has several instances of SQL injection vulnerabilities, ensure all database queries in the product use parameterized queries, and prohibit other forms of queries.
• Ensure business leaders are responsible for security. Business leaders should ensure that proactive steps to eliminate entire classes of security vulnerabilities, rather than only making one-off patches when new vulnerabilities are discovered.
• Follow the SSDF (SP 800-218) and implement secure design practices into each stage of the SDLC. Pay attention to:
  • Prioritizing the use of memory safe languages wherever possible [SSDF PW 6.1].
  • Exercising due diligence when selecting software components (e.g., software libraries, modules, middleware, frameworks) to ensure robust security in consumer software products [SSDF PW 4.1].
  • Setting up secure development team practices; this includes conducting peer code reviews, working to a common organization secure coding standard, and maintaining awareness of language specific security concerns [SSDF PW.5.1, PW.7.1, PW.7.2].
  • Establishing a vulnerability disclosure program to verify and resolve security vulnerabilities disclosed by people who may be internal or external to the organization [SSDF RV.1.3]. As part of this, establish processes to determine root causes of discovered vulnerabilities.
  • Using static and dynamic application security testing (SAST/DAST) tools to analyze product source code and application behavior to detect error-prone practices [SSDF PW.7.2, PW.8.2].
  • Configuring production-ready products to have to most secure settings as default and providing guidance on the risks of changing each setting [SSDF PW.9.1, PW9.2]
• Prioritize secure-by-default configurations such as eliminating default passwords, implementing single sign on (SSO) technology via modern open standards, and providing high-quality audit logs to customers with no additional configuration and at no extra charge.
• Ensure published CVEs include the proper CWE field identifying the root cause of the vulnerability to enable industry-wide analysis of software security and design flaws.

For more information on designing secure-by-design and -default products, including additional recommended secure-by-default configurations, see joint guide Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Security-by-Design and -Default.

End-User Organizations

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

Vulnerability and Configuration Management

• Update software, operating systems, applications, and firmware on IT network assets in a timely manner [CPG 1.E]. Prioritize patching known exploited vulnerabilities, especially those CVEs identified in this CSA, then critical and high vulnerabilities that allow for remote code execution or denial-of-service on internet-facing equipment. For patch information on CVEs identified in this CSA, refer to the appendix.
  • If a patch for a known exploited or critical vulnerability cannot be quickly applied, implement vendor-approved workarounds.
  • Replace end-of-life software (i.e., software no longer supported by the vendor).
• Routinely perform automated asset discovery across the entire estate to identify and catalogue all the systems, services, hardware and software.
• Implement a robust patch management process and centralized patch management system that establishes prioritization of patch applications [CPG 1.A].
  • Organizations that are unable to perform rapid scanning and patching of internet-facing systems should consider moving these services to mature, reputable cloud service providers (CSPs) or other managed service providers (MSPs). Reputable MSPs can patch applications—such as webmail, file storage, file sharing, and chat and other employee collaboration tools—for their customers. However, MSPs and CSPs can expand their customer’s attack surface and may introduce unanticipated risks, so organizations should proactively collaborate with their MSPs and CSPs to jointly reduce risk [CPG 1.F]. For more information and guidance, see the following resources.
    • CISA Insights Risk Considerations for Managed Service Provider Customers
    • CISA Insights Mitigations and Hardening Guidance for MSPs and Small- and Mid-sized Businesses
    • ACSC advice on How to Manage Your Security When Engaging a Managed Service Provider
• Document secure baseline configurations for all IT/OT components, including cloud infrastructure. Monitor, examine, and document any deviations from the initial secure baseline [CPG 2.O].
• Perform regular secure system backups and create known good copies of all device configurations for repairs and/or restoration. Store copies off-network in physically secure locations and test regularly [CPG 2.R].
• Maintain an updated cybersecurity incident response plan that is tested at least annually and updated within a risk informed time frame to ensure its effectiveness [CPG 2.S].

Identity and Access Management

• Enforce phishing-resistant multifactor authentication (MFA) for all users, without exception. [CPG 2.H].
• Enforce MFA on all VPN connections. If MFA is unavailable, require employees engaging in remote work to use strong passwords [CPG 2.A, 2.B, 2.C, 2.D, 2.G].
• Regularly review, validate, or remove privileged accounts (annually at a minimum) [CPG 2.D, 2.E].
• Configure access control under the principle of least privilege [CPG 2.Q].
  • Ensure software service accounts only provide necessary permissions (least privilege) to perform intended functions (using non-administrative privileges where feasible).
    Note: See CISA’s Capacity Enhancement Guide – Implementing Strong Authentication and ACSC’s guidance on Implementing Multi-Factor Authentication for more information on authentication system hardening.

Protective Controls and Architecture

• Properly configure and secure internet-facing network devices, disable unused or unnecessary network ports and protocols, encrypt network traffic, and disable unused network services and devices [CPG 2.V, 2.W, 2X].
  • Harden commonly exploited enterprise network services, including Link-Local Multicast Name Resolution (LLMNR) protocol, Remote Desktop Protocol (RDP), Common Internet File System (CIFS), Active Directory, and OpenLDAP.
  • Manage Windows Key Distribution Center (KDC) accounts (e.g., KRBTGT) to minimize Golden Ticket attacks and Kerberoasting.
  • Strictly control the use of native scripting applications, such as command-line, PowerShell, WinRM, Windows Management Instrumentation (WMI), and Distributed Component Object Model (DCOM).

• Implement Zero Trust Network Architecture (ZTNA) to limit or block lateral movement by controlling access to applications, devices, and databases. Use private virtual local area networks [CPG 2.F, 2.X]. Note: See the Department of Defense’s Zero Trust Reference Architecture for additional information on Zero Trust.
• Continuously monitor the attack surface and investigate abnormal activity that may indicate cyber actor or malware lateral movement [CPG 2.T].
  • Use security tools, such as endpoint detection and response (EDR) and security information and event management (SIEM) tools. Consider using an information technology asset management (ITAM) solution to ensure EDR, SIEM, vulnerability scanner, and other similar tools are reporting the same number of assets [CPG 2.T, 2.V].
  • Use web application firewalls to monitor and filter web traffic. These tools are commercially available via hardware, software, and cloud-based solutions, and may detect and mitigate exploitation attempts where a cyber actor sends a malicious web request to an unpatched device [CPG 2.B, 2.F].
  • Implement an administrative policy and/or automated process configured to monitor unwanted hardware, software, or programs against an allowlist with specified approved versions [CPG 2.Q].
  • Use a network protocol analyzer to examine captured data, including packet-level data.

Supply Chain Security

• Reduce third-party applications and unique system/application builds—provide exceptions only if required to support business critical functions [CPG 2.Q].
• Ensure contracts require vendors and/or third-party service providers to:
  • Provide notification of security incidents and vulnerabilities within a risk informed time frame [CPG 1.G, 1.H, 1.I].
  • Supply a Software Bill of Materials (SBOM) with all products to enhance vulnerability monitoring and to help reduce time to respond to identified vulnerabilities [CPG 4.B].
• Ask your software providers to discuss their secure by design program and to provide links to information about how they are working to remove classes of vulnerabilities, and to set secure default settings.

RESOURCES

• For information on the top vulnerabilities routinely exploited in 2016 through 2019, 2020, and 2021, see:
  • Joint CSA Top 10 Routinely Exploited Vulnerabilities
  • Joint CSA Top Routinely Exploited Vulnerabilities
  • Joint CSA 2021 Top Routinely Exploited Vulnerabilities
• See the appendix for additional partner resources on the vulnerabilities mentioned in this CSA.
• See ACSC’s Essential Eight mitigation strategies for additional mitigations.
• See ACSC’s Cyber Supply Chain Risk Management for additional considerations and advice.

DISCLAIMER

The information in this report is being provided “as is” for informational purposes only. CISA, FBI, NSA, ACSC, CCCS, NCSC-NZ, CERT NZ, and NCSC-UK do not endorse any commercial product or service, including any subjects of analysis. Any reference to specific commercial products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply endorsement, recommendation, or favoring.

PURPOSE

This document was developed by CISA, NSA, FBI, ACSC, CCCS, NCSC-NZ, CERT NZ, and NCSC-UK in furtherance of their respective cybersecurity missions, including their responsibilities to develop and issue cybersecurity specifications and mitigations.

REFERENCES

[1] Apache Log4j Vulnerability Guidance

VERSION HISTORY

August 3, 2023: Initial version.

APPENDIX: PATCH INFORMATION AND ADDITIONAL RESOURCES FOR TOP EXPLOITED VULNERABILITIES

Source de l’article sur us-cert.gov

SUMMARY

The Australian Signals Directorate’s Australian Cyber Security Centre (ACSC), U.S. Cybersecurity and Infrastructure Security Agency (CISA), and U.S. National Security Agency (NSA) are releasing this joint Cybersecurity Advisory to warn vendors, designers, and developers of web applications and organizations using web applications about insecure direct object reference (IDOR) vulnerabilities. IDOR vulnerabilities are access control vulnerabilities enabling malicious actors to modify or delete data or access sensitive data by issuing requests to a website or a web application programming interface (API) specifying the user identifier of other, valid users. These requests succeed where there is a failure to perform adequate authentication and authorization checks.

These vulnerabilities are frequently exploited by malicious actors in data breach incidents because they are common, hard to prevent outside the development process, and can be abused at scale. IDOR vulnerabilities have resulted in the compromise of personal, financial, and health information of millions of users and consumers.

ACSC, CISA, and NSA strongly encourage vendors, designers, developers, and end-user organizations to implement the recommendations found within the Mitigations section of this advisory—including the following—to reduce prevalence of IDOR flaws and protect sensitive data in their systems.

• Vendors, designers, and developers of web application frameworks and web applications: Implement secure-by-design and -default principles and ensure software performs authentication and authorization checks for every request that modifies, deletes, and accesses sensitive data.
  • Use automated tools for code review to identify and remediate IDOR and other vulnerabilities.
  • Use indirect reference maps, ensuring that IDs, names, and keys are not exposed in URLs. Replace them with cryptographically strong, random values—specifically use a universally unique identifier (UUID) or a globally unique identifier (GUID).
  • Exercise due diligence when selecting third-party libraries or frameworks to incorporate into your application and keep all third-party frameworks and dependencies up to date.
• All end-user organizations, including organizations with software-as-a-service (SaaS) models:
  • Use due diligence when selecting web applications. Follow best practices for supply chain risk management and only source from reputable vendors.
  • Apply software patches for web applications as soon as possible.
• End-user organizations deploying on-premises software, infrastructure-as-a-service (IaaS), or private cloud models:
  • Review the available authentication and authorization checks in web applications that enable modification of data, deletion of data, or access to sensitive data.
  • Conduct regular, proactive vulnerability scanning and penetration testing to help ensure internet-facing web applications and network boundaries are secure.

Download the PDF version of this report:

TECHNICAL DETAILS

Description

IDOR vulnerabilities are access control vulnerabilities in web applications (and mobile phone applications [apps] using affected web API) that occur when the application or API uses an identifier (e.g., ID number, name, or key) to directly access an object (e.g., a database record) but does not properly check the authentication or authorization of the user submitting the request. Depending on the type of IDOR vulnerability, malicious actors can access sensitive data, modify or delete objects, or access functions.

• Horizontal IDOR vulnerabilities occur when a user can access data that they should not be able to access at the same privilege level (e.g., other user’s data).
• Vertical IDOR vulnerabilities occur when a user can access data that they should not be able to access because the data requires a higher privilege level.
• Object-level IDOR vulnerabilities occur when a user can modify or delete an object that they should not be able to modify or delete.
• Function-level IDOR vulnerabilities occur when a user can access a function or action that they should not be able to access.

Typically, these vulnerabilities exist because an object identifier is exposed, passed externally, or easily guessed—allowing any user to use or modify the identifier.

• In body manipulation, an actor modifies the HTML form field data in the body of a POST request to impact targeted records.
• In URL tampering, an actor modifies an identifier in URLs to impact targeted records.
• In cookie ID manipulation, the actor modifies an identifier in a cookie to an identifier of a different user (including administrative users) in an attempt to gain access to that account.
• In HTTP/JSON request tampering, an actor uses a web proxy to intercept and alter arbitrary portions of legitimate requests, including values inside JSON objects.

Impact

These vulnerabilities are common[1] and hard to prevent outside the development process since each use case is unique and cannot be mitigated with a simple library or security function. Additionally, malicious actors can detect and exploit them at scale using automated tools. These factors place end-user organizations at risk of data leaks (where information is unintentionally exposed) or large-scale data breaches (where a malicious actor obtains exposed sensitive information). Data leaks or breaches facilitated by IDOR vulnerabilities include:

• An October 2021 global data leak incident where mobile phone data, including text messages, call records, photos, and geolocation from hundreds of thousands of devices was exposed by insecure “stalkerware” apps.[2] The apps collected and relayed data from the phones to the same foreign server infrastructure, which contained an IDOR vulnerability, CVE-2022-0732.[3] This led to exposure of the collected app data.[4]
• A 2019 data breach incident where more than 800 million personal financial files, including bank statements, bank account numbers, and mortgage payment documents, from a U.S. Financial Services Sector organization were exposed.[5],[6]
• A 2012 data breach incident where a malicious cyber actor obtained the personal data of more than 100,000 mobile device owners from a U.S. Communications Sector organization’s publicly accessible website.[7]

MITIGATIONS

Vendors and Developers

ACSC, CISA, and NSA recommend that vendors, designers, and implementors of web applications—including organizations that build and deploy software (such as HR tools) for their internal use and organizations that create open-source projects—implement the following mitigations. These mitigations may reduce prevalence of IDOR vulnerabilities in software and help ensure products are secure-by-design and -default.

• Implement and inject secure-by-design and -default principles and best practices into each stage of the software development life cycle (SDLC). Particular recommended practices are defined in the National Institute of Security and Technology’s (NIST’s) Secure Software Development Framework (SSDF), SP 800-218. Lend special attention to:
  • Conducting code reviews [SSDF PW 7.2, RV 1.2] against peer coding standards, checking for backdoors, malicious content, or logic flaws.
    • ACSC, CISA, and NSA recommend using automated code analysis tools for all supported releases to identify and remediate vulnerabilities.
  • Following secure coding practices [SSDF PW 5.1] for web and mobile applications to ensure that they properly validate user input and generate strong user IDs.
    • Use indirect reference maps, such that IDs, names, and keys are not exposed in URLs. Replace them with cryptographically strong, random values—specifically use a UUID or a GUID. Note: UUIDs and GUIDs should not be used for security capabilities. See Request for Comment (RFC) 4122 for more information.
    • Configure applications to deny access by default and ensure the application performs authentication and authorization checks for every request to modify data, delete data, and access sensitive data. For example:
      • Normalize requests. There are many ways to encode and decode web inputs. Decode and normalize inputs before creating access control checkpoints. Ensure the access control system and other parts of the web application perform the same normalization.
      • Implement parameter verification leveraging syntactic and logical validation, such that web applications validate all inputs received with every HTTP/S request. Denying invalid requests can reduce the burden on the access control system.
        • Syntactic validation verifies that for each input the incoming value meets your applications’ expectations. When doing syntactic validation, verify that strings are within the minimum and maximum length required, strings do not contain unacceptable characters, numeric values are within the minimum and maximum boundaries, and the input is of the proper data type.
        • Logical validation adds checks to see if the input values make sense and are consistent with design intent. When doing logical validation, verify authorization checks are performed in the correct locations, are of varying pedigree, and that there is error handling of failed authentication and authorization requests.
    • Use CAPTCHA to limit automated invalid user requests where feasible.
    • Use memory-safe programming languages where possible.
  • Testing code to identify vulnerabilities and verify compliance with security requirements [SSDF PW 8.2].
  • Use automated testing tools to facilitate testing, fuzz testing tools to find issues with input handling,[8] and penetration testing to simulate how a threat actor may exploit the software. Consider using dynamic application security testing (DAST) tools to identify IDOR vulnerabilities in web applications.
  • Conducting role-based training [SSDF PO 2.2] for personnel responsible for secure software development.
  • Exercising due diligence when selecting third-party libraries or frameworks to incorporate into your application [SSDF PW 4.1].
    • Review and evaluate third-party components in the context of their expected use.
    • Verify the integrity of the product through hash or signature verification.
    • If provided, review component’s Software Bill of Materials (SBOM) for outdated, vulnerable, or unauthorized applications before using it.
    • Keep all third-party frameworks and dependencies up to date to limit vulnerability inheritance. Note: Organizations should maintain an inventory or catalog of third-party frameworks and dependencies to assist with proactive updates. Consider using tools to identify project dependencies and known vulnerabilities in third-party code. See OWASP’s Top Ten Proactive Controls 2018, C2: Leverage Security Frameworks and Libraries, for more information.

      For more information, see the joint Enduring Security Framework’s Securing the Software Supply Chain: Recommended Practices Guide for Developers, CISA’s Supply Chain Risk Management Essentials, and ACSC’s Cyber Supply Chain Risk Management.

• Establish a vulnerability disclosure program to verify and resolve security vulnerabilities disclosed by people who may be internal or external to the organization.

Additionally, ACSC, CISA, and NSA recommend following cybersecurity best practices in production and enterprise environments. Software developers are high-value targets because their customers deploy software on their own trusted networks. For best practices, see:

• ACSC’s Essential Eight. The Essential Eight are prioritized strategies to help cybersecurity professionals mitigate cybersecurity incidents caused by various cyber threats.
• CISA’s Cross-Sector Cybersecurity Performance Goals (CPGs). The CPGs, developed by CISA and NIST, are a prioritized subset of IT and OT security practices that can meaningfully reduce the likelihood and impact of known cyber risks and common tactics, techniques, and procedures. Because the CPGs are a subset of best practices, ACSC, CISA, and NSA also recommend software manufacturers implement a comprehensive information security program based on a recognized framework, such as the NIST Cybersecurity Framework (CSF).
• NSA’s Top Ten Cybersecurity Mitigations. The Top Ten sets priorities for enterprise activities to counter a broad range of exploitation techniques and minimize mission impact.

All End-User Organizations

ACSC, CISA, and NSA recommend that all end-user organizations, including those with on-premises software, SaaS, IaaS, and private cloud models, implement the mitigations below to improve their cybersecurity posture.

• Exercise due diligence when selecting web applications. Follow best practices for supply chain risk management and source from reputable vendors that demonstrate commitment to secure-by-design and -default principles.
  • Verify the integrity of the product through hash or signature verification.
  • If provided, review the SBOM for outdated, vulnerable, or unauthorized applications before using the product.

    For more information, see the Enduring Security Framework’s Securing the Software Supply Chain: Recommended Practices Guide for Customers, CISA’s Supply Chain Risk Management Essentials, and ACSC’s Cyber Supply Chain Risk Management.

• Apply software patches for web applications as soon as possible.
• Configure the application to log and generate alerts from tamper attempts—with this information, network defenders can investigate and take appropriate follow-on actions.
  • Establish a baseline to efficiently identify abnormal behavior. Note: Web application error codes such as HTTP 404 and HTTP 403 are associated with common enumeration techniques.
  • Aggregate logs into a centralized solution (e.g., a security information and event management [SIEM] tool) to facilitate active monitoring and threat hunting.
• Create, maintain, and exercise a basic cyber incident response plan (IRP) and associated communications plan. Plans should include response and notification procedures for data breach and cyber incidents. For more information, see:
  • ACSC: Preparing for and Responding to Cyber Incidents
  • ACSC: Cyber Incident Response Plan – Guidance
  • ACSC: Cyber Incident Response Readiness Checklist
  • Office of the Australian Information Commissioner (OAIC): Data Breach Preparation and Response
  • OIAC: Data Breach Response Plan
  • CISA: Incident Response Plan Basics
  • CISA: Federal Government Cybersecurity Incident and Vulnerability Response Playbook (Although tailored to U.S. Federal Civilian Branch (FCEB) agencies, these playbooks provide operational procedures for planning and conducting cybersecurity incident and vulnerability response activities and detail steps for both incident and vulnerability response.)
  • CISA: Protecting Sensitive and Personal Information from Ransomware-Caused Data Breaches

Additionally, ACSC, CISA, and NSA recommend following cybersecurity practices. For best practices, see ACSC’s Essential Eight, CISA’s CPGs, and NSA’s Top Ten Cybersecurity Mitigation Strategies.

End-User Organizations with On-Premises Software, IaaS, or Private Cloud Models

ACSC, CISA, and NSA recommend that organizations:

• Conduct regular, proactive penetration testing to ensure network boundaries, as well as web applications, are secure. Prioritize web applications that are internet-facing and contain user login functionality. Such testing may be beyond the technical or financial capabilities of some organizations. Consider using a trusted third party for penetration testing to discover new attack vectors (notably prior to deployment of new or altered internet-facing services). Note: Organizations should consult with their legal counsel as appropriate to determine which systems and applications can be included in the scope of the penetration testing.
  • Use web application penetration testing tools to capture the user identifier sent to the web server when requesting a web page containing sensitive data and map all locations where user input is used to reference objects directly. Test with users of various privilege levels (e.g., a normal user and admin user).
• Use DAST and other vulnerability scanners to detect IDOR vulnerabilities. DAST tools identify vulnerabilities in web applications with penetration tests and generate automated alerts. Note: Exercise due diligence when selecting DAST tools. Not all DAST tools can detect IDOR vulnerabilities—tools with the ability may need the environment configured in a specific way and may also need custom rules in place. Sufficient DAST tools often ingest the application API documentation to build a model of the application. While these tools can be used to detect IDOR vulnerabilities, they are not foolproof and should be used with other security testing methods to ensure comprehensive coverage.
• Immediately report detected vulnerabilities to the vendor or developer. Alternatively (or if the vendor or developer fails to respond), report the vulnerability to CISA at cisa.gov/report.
• Consider establishing a vulnerability disclosure program to verify, resolve, and report security vulnerabilities disclosed by people who may be internal or external to the organization.
• Use a web application firewall (WAF) to filter, monitor, and block malicious HTTP/S traffic traveling to the web application.
• Use a data loss prevention (DLP) tool to prevent unauthorized data from leaving the application.

ACSC, CISA, and NSA recommend that organizations with on-premises software or IaaS consider using SaaS models for their internet-facing websites.

End-User Organizations with SaaS Models

Organizations leveraging SaaS with sufficient resources may consider conducting penetration testing and using vulnerability scanners. However, such tests may interfere with service provider operations. Organizations should consult with their legal counsel as appropriate to determine what can be included in the scope of the penetration testing.

INCIDENT RESPONSE

If you or your organization are victim to a data breach or cyber incident, follow relevant cyber incident response and communications plans, as appropriate.

• Australia: Australian organizations that have been impacted or require assistance in regards to a cybersecurity incident can contact ACSC via 1300 CYBER1 (1300 292 371), or by submitting a report to cyber.gov.au.
• United States: U.S. organizations may report cybersecurity incidents to CISA’s 24/7 Operations Center at Report@cisa.dhs.gov, cisa.gov/report, or (888) 282-0870. When available, please include the 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.

RESOURCES

• For additional guidance on designing secure-by-design and -default products, see joint guide Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Security-by-Design and -Default.
• For additional guidance on protecting against data breaches, see ACSC’s webpage on data breaches.

REFERENCES

[1] A01 Broken Access Control – OWASP Top 10:2021

[2] A massive ‘stalkerware’ leak puts the phone data of thousands at risk

[3] Mobile device monitoring services do not authenticate API requests

[4] Behind the stalkerware network spilling the private phone data of hundreds of thousands

[5] First American Financial Corp. Leaked Hundreds of Millions of Title Insurance Records

[6] Biggest Data Breaches in US History [Updated 2023]

[7] AT&T Hacker ‘Weev’ Sentenced to 3.5 Years in Prison

[8] Fuzzing | OWASP Foundation

DISCLAIMER

The information in this report is being provided “as is” for informational purposes only. ACSC, CISA, and NSA do not endorse any commercial product or service, including any subjects of analysis. Any reference to specific commercial products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply its endorsement, recommendation, or favoring by the United States or Australian Governments, and this guidance shall not be used for advertising or product endorsement purposes.

PURPOSE

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

Source de l’article sur us-cert.gov

SUMMARY

In June 2023, a Federal Civilian Executive Branch (FCEB) agency identified suspicious activity in their Microsoft 365 (M365) cloud environment. The agency reported the activity to Microsoft and the Cybersecurity and Infrastructure Security Agency (CISA), and Microsoft determined that advanced persistent threat (APT) actors accessed and exfiltrated unclassified Exchange Online Outlook data.

CISA and the Federal Bureau of Investigation (FBI) are releasing this joint Cybersecurity Advisory to provide guidance to critical infrastructure organizations on enhancing monitoring of Microsoft Exchange Online environments. Organizations can enhance their cyber posture and position themselves to detect similar malicious activity by implementing logging recommendations in this advisory. Organizations that identify suspicious, anomalous activity should contact Microsoft for proceeding with mitigation actions due to the cloud-based infrastructure affected, as well as report to CISA and the FBI.

Download the PDF version of this report:

TECHNICAL DETAILS

In Mid-June 2023, an FCEB agency observed MailItemsAccessed events with an unexpected ClientAppID and AppID in M365 Audit Logs. The MailItemsAccessed event is generated when licensed users access items in Exchange Online mailboxes using any connectivity protocol from any client. The FCEB agency deemed this activity suspicious because the observed AppId did not normally access mailbox items in their environment. The agency reported the activity to Microsoft and CISA.

Microsoft determined that APT actors accessed and exfiltrated unclassified Exchange Online Outlook data from a small number of accounts. The APT actors used a Microsoft account (MSA) consumer key to forge tokens to impersonate consumer and enterprise users. Microsoft remediated the issue by first blocking tokens issued with the acquired key and then replacing the key to prevent continued misuse.[1]

The affected FCEB agency identified suspicious activity by leveraging enhanced logging—specifically of MailItemsAccessed events—and an established baseline of normal Outlook activity (e.g., expected AppID). The MailItemsAccessed event enables detection of otherwise difficult to detect adversarial activity.

CISA and FBI are not aware of other audit logs or events that would have detected this activity. Critical infrastructure organizations are strongly urged to implement the logging recommendations in this advisory to enhance their cybersecurity posture and position themselves to detect similar malicious activity.

LOGGING

CISA and the FBI strongly encourage critical infrastructure organizations to ensure audit logging is enabled. Note: Per CISA’s Microsoft Exchange Online Microsoft 365 Minimum Viable Secure Configuration Baselines, FCEB agencies shall enable audit logging. These minimum viable secure configuration baselines are part of CISA’s Secure Cloud Business Applications (SCuBA) Project, which provides guidance for FCEB agencies securing their cloud business application environments and protecting federal information created, accessed, shared, and stored in those environments. Although tailored to FCEB agencies, the project provides security guidance applicable to all organizations with cloud environments. The Office of Management and Budget (OMB) M-21-31 requires Microsoft audit logs be retained for at least twelve months in active storage and an additional eighteen months in cold storage. This can be accomplished either by offloading the logs out of the cloud environment or natively through Microsoft by creating an audit log retention policy.

In addition to enabling audit logging, CISA and FBI strongly encourage organizations to:

• Enable Purview Audit (Premium) logging. This logging requires licensing at the G5/E5 level. See Microsoft’s guidance on Assigning Microsoft 365 Licenses to Users for additional information.
• Ensure logs are searchable by operators. The relevant logs need to be accessible to operational teams in a platform (e.g., security operations center [SOC] tooling) that enables hunting for this activity and distinguishing it from expected behavior within the environment.
• Enable Microsoft 365 Unified Audit Logging (UAL). UAL should be enabled by default, but organizations are encouraged to validate these settings.
• Understand your organization’s cloud baseline. Organizations are encouraged to look for outliers and become familiar with baseline patterns to better understand abnormal versus normal traffic.

GENERAL CLOUD MITIGATIONS

All mitigation actions for this activity are the responsibility of Microsoft due to the cloud-based infrastructure affected; however, CISA and the FBI recommend that critical infrastructure organizations implement the following to harden their cloud environments. Although, these mitigations will not prevent this or related activity where actors leverage compromised consumer keys, they will reduce the impact of less sophisticated malicious activity targeting cloud environments. Note: These mitigations align with CISA’s SCuBA Technical Reference Architecture (TRA), which describes essential components of security services and capabilities to secure and harden cloud business applications, including the platforms hosting the applications.

• Apply CISA’s recommended baseline security configurations for Microsoft Defender for Office 365, Azure Active Directory, Exchange Online, OneDrive for Business, Power BI, Power Platform, SharePoint Online, and Teams [SCuBA TRA Section 6.6].
• Separate administrator accounts from user accounts according to the National Institute of Standards and Technology’s (NIST’s) guidance, AC-5: Separation of Duties. Only allow designated administrator accounts to be used for administration purposes. If an individual user requires administrative rights over their workstation, use a separate account without administrative access to other hosts.
• Collect and store access and security logs for secure cloud access (SCA) solutions, endpoint solutions, cloud applications/platforms and security services, such as firewalls, data loss prevention systems, and intrusion detection systems [SCuBA TRA Section 6.8.1].
• Use a telemetry hosting solution (e.g., SIEM solution) that aggregates logs and telemetry data to facilitate internal organization monitoring, auditing, alerting, and threat detection activities [SCuBA TRA Section 6.8.1].
• Review contractual relationships with all Cloud Service Providers (CSPs) and ensure contracts include:
  • Security controls the customer deems appropriate.
  • Appropriate monitoring and logging of provider-managed customer systems.
  • Appropriate monitoring of the service provider’s presence, activities, and connections to the customer network.
  • Notification of confirmed or suspected activity.

REPORTING SUSPICIOUS ACTIVITY

Organizations are encouraged to report suspicious activity to CISA via CISA’s 24/7 Operations Center (report@cisa.gov or 888-282-0870). The FBI encourages recipients of this document to report information concerning suspicious or criminal activity to their local FBI field office or IC3.gov.

RESOURCES

• CISA: Microsoft Exchange Online Microsoft 365 Minimum Viable Secure Configuration Baselines
• CISA: SCuBA Project
• Microsoft: Assigning Microsoft 365 Licenses to Users
• CISA: SCuBA TRA
• CISA: Recommended Baseline Security Configurations (Microsoft)
  • Defender for Office 365
  • Azure Active Directory
  • Exchange Online
  • OneDrive for Business
  • Power BI
  • Power Platform
  • SharePoint Online
  • Teams
• NIST: AC-5: Separation of Duties

REFERENCES

[1] Microsoft Security Response Center (MSRC) blog: Microsoft mitigates China-based threat actor Storm-0558 targeting of customer email

ACKNOWLEDGEMENTS

Microsoft contributed to this CSA.

DISCLAIMER

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

Source de l’article sur us-cert.gov