The NCIRP is the nation’s strategic framework for coordinated response to cyber incidents along four lines of effort: Asset Response, Threat Response, Intelligence Support, and Affected Entity Response. It includes coordination mechanisms, key decision points, and priority activities across the cyber incident response lifecycle. The NCIRP also identifies structures that response stakeholders should leverage to coordinate cyber incidents requiring cross-sector, public-private, or federal coordination; however, it is not meant to be a step-by-step instruction manual.
CISA collaborated extensively with government and industry partners to provide an agile, actionable updated framework that ensures coherent coordination to match the pace of our adversaries. Key updates in this draft include:
A defined path for non-federal stakeholders to participate in coordination of cyber incident response;
Improved usability by streamlining content and aligning to an operational lifecycle;
Relevant legal and policy changes impacting agency roles and responsibilities; and
A predictable cycle for future updates of the NCIRP.
“Today’s increasingly complex threat environment demands that we have a seamless, agile, and effective incident response framework,” said CISA Director Jen Easterly. “This draft NCIRP Update leverages the lessons learned over the past several years to achieve a deeper unity of effort between the government and the private sector. We encourage public comment and feedback to help us ensure its maximum effectiveness.”
As the nation’s cyber defense agency and national coordinator for critical infrastructure security, the Cybersecurity and Infrastructure Security Agency leads the national effort to understand, manage, and reduce risk to the digital and physical infrastructure Americans rely on every hour of every day.
Actions enhance visibility and reduce potential entry points for PRC-affiliated cyber threats
WASHINGTON – The Cybersecurity and Infrastructure Security Agency (CISA), National Security Agency (NSA), Federal Bureau of Investigation (FBI) and international partners published today a joint guide, Enhanced Visibility and Hardening Guidance for Communications Infrastructure, that provides best practices to protect against a People’s Republic of China (PRC)-affiliated threat actor that has compromised networks of major global telecommunications providers. The recommended practices are for network engineers and defenders of communications infrastructure to strengthen visibility and harden network devices against this broad and significant cyber espionage campaign.
CISA and FBI recently warned of this campaign. This guide recommends actions to quickly identify anomalous behavior, vulnerabilities and threats, and to respond to a cyber incident. It also guides organizations to reduce existing vulnerabilities, improve secure configuration habits, and limit potential entry points.
“The PRC-affiliated cyber activity poses a serious threat to critical infrastructure, government agencies, and businesses. This guide will help telecommunications and other organizations detect and prevent compromises by the PRC and other cyber actors,” said CISA Executive Assistant Director for Cybersecurity Jeff Greene. “Along with our US and international partners, we urge software manufacturers to incorporate Secure by Design principles into their development lifecycle to strengthen the security posture of their customers. Software manufacturers should review our Secure by Design resources and put their principles into practice.”
“Threat actors affiliated with the People’s Republic of China (PRC) are targeting commercial telecommunications providers to compromise sensitive data and engage in cyber espionage,” said Assistant Director Bryan Vorndran of the FBI’s Cyber Division. “Together with our interagency partners, the FBI issued guidance to enhance the visibility of network defenders and to harden devices against PRC exploitation. We strongly encourage organizations to review and implement the recommended measures in this guide and to report suspicious activity to their local FBI field office.”
Although tailored to communications infrastructure sector, this guidance may also apply to organizations with on-premises enterprise equipment. CISA encourages all critical infrastructure organizations to implement security best practices.
As the nation’s cyber defense agency and national coordinator for critical infrastructure security, the Cybersecurity and Infrastructure Security Agency leads the national effort to understand, manage, and reduce risk to the digital and physical infrastructure Americans rely on every hour of every day.
The Addition of 29 New Entities to the UFLPA Entity List Brings the List to 107
WASHINGTON – Today, the Department of Homeland Security (DHS), on behalf of the Forced Labor Enforcement Task Force (FLETF), announced the addition of 29 companies based in the People’s Republic of China (PRC) to the Uyghur Forced Labor Prevention Act (UFLPA) Entity List – bringing the total number of entities on the UFLPA Entity List to 107.The FLETF, chaired by DHS, is taking these steps as part of its commitment to eliminating the use of forced labor practices in U.S. supply chains and promoting accountability for the ongoing genocide and crimes against humanity against Uyghurs and other religious and ethnic minority groups in the Xinjiang Uyghur Autonomous Region (XUAR).
“Forced labor is a violation of basic human rights,” said Secretary of Homeland Security Alejandro N. Mayorkas. “The Department of Homeland Security has aggressively enforced the Uyghur Forced Labor Prevention Act, preventing goods made through forced labor from entering our country, investigating and exposing more than 100 bad actors, and helping American businesses avoid inadvertently profiting from this modern form of slavery. Alongside our government, industry, and civil society partners, the United States is making progress towards the eradication of forced labor while supporting economic fairness, safeguarding human rights, and holding perpetrators accountable.”
“Today’s enforcement actions make it clear — the United States will not tolerate forced labor in the goods entering our markets,” said the Under Secretary for Policy, Robert Silvers, who serves as Chair of the Federal Labor Enforcement Task Force. “The Uyghur Forced Labor Prevention Act is a powerful tool in the fight against forced labor, and we are using it to its full potential. We urge companies to take responsibility, know their supply chains, and act ethically.”
The UFLPA has been a key instrument for the Biden-Harris administration’s fight against forced labor, particularly in the XUAR, and in safeguarding U.S. supply chains. Through the Department’s initiatives, the administration has prioritized ethical sourcing and production, reinforcing global workers’ rights and empowering consumers to make informed, values-based choices. This work underscores a commitment to building a fairer and more responsible global trade system.
Effective November 25, 2024, U.S. Customs and Border Protection will apply a rebuttable presumption that goods produced by the named 29 entities will be prohibited from entering the United States as a result of the companies’ activities, either sourcing materials from the XUAR or working with the government of Xinjiang to recruit, transport, transfer, harbor, orreceive Uyghurs, Kazakhs, Kyrgyz, or members of other persecuted groups out of the XUAR.
Tianjin Tianwei Food Co., Ltd. (formerly known as Tianjin Sanhe Fruit and Vegetable Co., Ltd.) is a company located in Tianjin, China that processes fruit, vegetable, and agricultural products, especially tomato products, and integrates raw material planting, picking, production, processing, trade, and scientific research and development. The United States Government has reasonable cause to believe, based on specific and articulable information, that Tianjin Tianwei Food Co., Ltd. sources material, specifically tomatoes, from the XUAR. Information reviewed by the FLETF, including publicly available information, indicates that Tianjin Tianwei Food Co., Ltd. sources tomatoes from the XUAR, including from Bazhou, Xinjiang.
Xinjiang Zhonghe Co., Ltd., (also known as Xinjiang Joinworld Co., Ltd.), is a company located in the XUAR that primarily focuses on the research, development, production, and sales of electronic materials and aluminum and alloy products including high-purity aluminum, electronic aluminum foil, electrode foil, and other aluminum and alloy products. These products are primarily used in electronic equipment, wires, and cables in a wide range of downstream products, including household appliances, automobiles, and aerospace applications. The United States Government has reasonable cause to believe, based on specific and articulable information, that Xinjiang Zhonghe Co., Ltd. works with the government of the XUAR to recruit and transfer Uyghurs out of the XUAR. Information reviewed by the FLETF, including publicly available information, indicates Xinjiang Zhonghe cooperates with local Xinjiang governments in Yingjisha County and participates in government-sponsored poverty alleviation and labor programs to recruit and transfer Uyghurs. The FLETF therefore determined that the activities of Xinjiang Zhonghe Co., Ltd. satisfy the criteria for addition to the UFLPA Entity List described in Section 2(d)(2)(B)(ii).
Xinjiang Nonferrous Metals Industry Group Co., Ltd. and three of its subsidiaries: Western Gold Co., Ltd., Western Gold Karamay Hatu Gold Mine Co., Ltd. and Western Gold Hami Gold Mine Co., Ltd. are located in the XUAR. Xinjiang Nonferrous Metals Industry Group Co., Ltd. (“Xinjiang Nonferrous”) is a state-owned enterprise based in Urumqi, Xinjiang that mines, smelts, and processes raw metallic materials, including copper, lithium, beryllium, nickel, manganese, and gold. Western Gold Co., Ltd. (Western Gold) is a majority-owned subsidiary of Xinjiang Nonferrous that mines, processes, and sells gold and manganese resources, as well as chromium ore and iron ore mining and processing. Western Gold KaramayHatu Gold Mine Co., Ltd. (Western Gold Karamay Hatu Gold Mine) is a wholly owned subsidiary of Western Gold that mines and processes gold and chromium ores. Western Gold Hami Gold Mine Co., Ltd. (Western Gold Hami Gold Mine) is a wholly owned subsidiary of Western Gold that mines and processes gold ores. The United States Government has reasonable cause to believe, based on specific and articulable information, that Xinjiang Nonferrous, Western Gold, Western Gold KaramayHatu Gold Mine, and Western Gold Hami Gold Mine work with the government of Xinjiang to recruit, transfer, or receive workers, including Uyghurs, out of Xinjiang. Information reviewed by the FLETF, including publicly available information, indicates Xinjiang Nonferrous, Western Gold, Western Gold Karamay Hatu Gold Mine, and Western Gold Hami Gold Mine worked with the Xinjiang government, including local Xinjiang governments, to recruit, transfer, or receive Uyghurs from Xinjiang, including Hotan and Kashgar prefectures. The FLETF therefore determined that the activities of Xinjiang Nonferrous, Western Gold, Western Gold Karamay Hatu Gold Mine, and Western Gold Hami Gold Mine satisfy the criteria for addition to the UFLPA Entity List described in Section 2(d)(2)(B)(ii).
23 Entities in the Agricultural Sector: The FLETF has identified 23 entities engaged in the production and sale of agricultural products, including tomato paste and tomato products, walnuts, red dates, raisins, and other products. The FLETF has reasonable cause to believe, based on specific and articulable information, that the entities source agricultural products from the XUAR and sell them on online wholesale sites. That information has been corroborated by other publicly available information indicating that the entities source goods from the XUAR. Given information that indicates all 23 companies source agricultural products from the XUAR, the FLETF determined that the activities of the entities satisfy the criteria for addition to the UFLPA Entity List under Section 2(d)(2)(B)(v). The 23 entities are:
Anhui Yaozhiyuan Biotechnology Development Co., Ltd. (also known as Anhui Yaozhiyuan Chinese Herbal Medicine Co., Ltd.; Anhui Yaozhiyuan Chinese Medicinal Materials Co., Ltd.; and Anhui Yaozhiyuan Biological Technology Development Co., Ltd.)
Annan Canned Food Co., Ltd. (also known as Nanling County Annan Canned Food Co., Ltd.)
Dalian Sunspeed Foods Co., Ltd. (also known as Dalian Shengchi International Trade Co., Ltd.)
Gansu Yasheng International Trading Co., Ltd. (also known as Gansu Yasheng International Trade Co., Ltd.; and Yasheng International Trade; and formerly known as Gansu Yasheng International Trade Group Co., Ltd.)
Hangzhou Union Biotechnology Co., Ltd. (also known as Hangzhou Youer Biotechnology Co., Ltd.; Youer Biotech; and Union Biotech)
Hebei Suguo International Trade Co., Ltd. (also known as Suguo International)
Hebei Tomato Industry Co., Ltd. (also known as Hebei Temeite Industrial Group Co., Ltd.; and formerly known as Hebei Temeite International Trade Co., Ltd.)
Hunan Nanmo Biotechnology Co., Ltd. (also known as Hunan Nanmomo Technology Co., Ltd.)
Inner Mongolia Qileyuan Food Co., Ltd.
Inner Mongolia Xuanda Food Co., Ltd. (also known as Xuanda Food; and formerly known as Wuyuan County Xuanda Cereals, Oils and Foods Co., Ltd.)
Jinan Haihong International Trade Co., Ltd. (formerly known as Jinan Haifang Trading Co., Ltd.)
Jining Pengjie Trading Co., Ltd.
Junan Jinsheng Import & Export Co., Ltd. (also known as Junan County Jinsheng Import and Export Co., Ltd.)
Kingherbs Limited (also known as Changsha Jincao Biotechnology Co., Ltd.)
Qingdao Vital Nutraceutical Ingredients BioScience Co., Ltd. (also known as Qingdao Weiyikang Biotechnology Co., Ltd.)
Shanghai JUMP Machinery & Technology Co., Ltd. (also known as Shanghai Jiapai Machinery Technology Co., Ltd.; and formerly known as Shanghai Chituma Food Machinery Technology Co., Ltd.)
Sichuan Yuan’an Pharmaceutical Co., Ltd. (also known as Sichuan Yuanan Pharmaceutical Co., Ltd.)
Taiyuan Weishan International Economic Business Co., Ltd. (also known as Taiyuan Weishan International Trade Co., Ltd.)
The TNN Development Limited (also known as Dehui (Dalian) International Trade Co., Ltd.)
Tianjin Dunhe International Trade Co., Ltd. (also known as Dunhe Foods)
Tianjin Kunyu International Co., Ltd. (also known as China Kunyu Industrial Co., Ltd.)
Weifang Alice Food Co., Ltd.
Zhangzhou Hang Fat Import & Export Co., Ltd. (also known as ZhangzhouHengfa Import and Export Co., Ltd.)
In addition to the 29 new entities, the FLETF added a listed entity to an additional UFLPA Entity List sub-list and the FLETF modified the name of the listed entity through a technical correction.
Xinjiang Daqo New Energy Co., Ltd., (also known as Xinjiang Great New Energy Co., Ltd.; Xinjiang Daxin Energy Co., Ltd.; and Xinjiang Daqin Energy Co., Ltd.), is a company located in Shihezi, XUAR that produces high purity polysilicon materials. This company was first listed on the UFLPA Entity List, pursuant to Section 2(d)(2)(B)(i), in June 2022. The United States Government has reasonable cause to believe, based on specific and articulable information, that Xinjiang Daqo New Energy Co., Ltd. sources silicon powder from the XUAR. The FLETF therefore determined that the activities of Xinjiang Daqo New Energy Co., Ltd. satisfy the criteria for addition to the UFLPA Entity List described in Section 2(d)(2(B)(v).
Xinjiang East Hope Nonferrous Metals Co., Ltd., is a company located in the XUAR that manufactures nonferrous metals, nonferrous metal alloys products, and metal materials. The company also participates in power generation, transmission, and supply activities. When it was first added to the UFLPA Entity List in June 2022, the FLETF included one known alias, “Xinjiang Nonferrous.” Information reviewed by the FLETF indicates that “Xinjiang Nonferrous” is not an alias of Xinjiang East Hope Nonferrous Metals Co., Ltd. Therefore, the FLETF has determined that a technical correction is required to change the name of the entity “Xinjiang East Hope Nonferrous Metals Co., Ltd.” as it appears on Section 2(d)(2)(B)(i) to remove the alias “Xinjiang Nonferrous.”
DHS will publish the revised UFLPA Entity List as an appendix to a Federal Register notice.
The UFLPA, signed into law by President Joseph R. Biden, Jr. in December 2021, mandates that CBP apply a rebuttable presumption that goods that are either mined, produced or manufactured wholly or in part in the XUAR, or produced by entities identified on the UFLPA Entity List, are prohibited from importation into the United States, unless the Commissioner of CBP determines, by clear and convincing evidence, that the goods were not produced with forced labor. CBP began enforcing the UFLPA in June 2022. Since then, CBP has reviewed more than 10,000 shipments valued at more than $3.6 billion under the UFLPA.
This expansion of the UFLPA Entity List reflects DHS’ prioritization of combatting the introduction of forced labor into U.S. supply chains.
The Cybersecurity and Infrastructure Security Agency (CISA) conducted a red team assessment (RTA) at the request of a critical infrastructure organization. During RTAs, CISA’s red team simulates real-world malicious cyber operations to assess an organization’s cybersecurity detection and response capabilities. In coordination with the assessed organization, CISA is releasing this Cybersecurity Advisory to detail the red team’s activity—including their tactics, techniques, and procedures (TTPs) and associated network defense activity. Additionally, the advisory contains lessons learned and key findings from the assessment to provide recommendations to network defenders and software manufacturers for improving their organizations’ and customers’ cybersecurity posture.
Within this assessment, the red team (also referred to as ‘the team’) gained initial access through a web shell left from a third party’s previous security assessment. The red team proceeded to move through the demilitarized zone (DMZ) and into the network to fully compromise the organization’s domain and several sensitive business system (SBS) targets. The assessed organization discovered evidence of the red team’s initial activity but failed to act promptly regarding the malicious network traffic through its DMZ or challenge much of the red team’s presence in the organization’s Windows environment.
The red team was able to compromise the domain and SBSs of the organization as it lacked sufficient controls to detect and respond to their activities. The red team’s findings illuminate lessons learned for network defenders and software manufacturers about how to respond to and reduce risk.
Lesson Learned: The assessed organization had insufficient technical controls to prevent and detect malicious activity. The organization relied too heavily on host-based endpoint detection and response (EDR) solutions and did not implement sufficient network layer protections.
Lesson Learned: The organization’s staff require continuous training, support, and resources to implement secure software configurations and detect malicious activity. Staff need to continuously enhance their technical competency, gain additional institutional knowledge of their systems, and ensure they are provided sufficient resources by management to have the conditions to succeed in protecting their networks.
Lesson Learned: The organization’s leadership minimized the business risk of known attack vectors for the organization. Leadership deprioritized the treatment of a vulnerability their own cybersecurity team identified, and in their risk-based decision-making, miscalculated the potential impact and likelihood of its exploitation.
To reduce risk of similar malicious cyber activity, CISA encourages critical infrastructure organizations to apply the recommendations in the Mitigations section of this advisory to ensure security processes and procedures are up to date, effective, and enable timely detection and mitigation of malicious activity.
This document illustrates the outsized burden and costs of compensating for insecure software and hardware borne by critical infrastructure owners and operators. The expectation that owners and operators should maintain the requisite sophisticated cyber defense skills creates undue risk. Technology manufacturers must assume responsibility for product security. Recognizing that insecure software contributes to these identified issues, CISA urges software manufacturers to embrace Secure by Design principles and implement the recommendations in the Mitigations section of this advisory, including those listed below:
Embed security into product architecture throughout the entire software development lifecycle (SDLC).
Eliminate default passwords.
Mandate MFA, ideally phishing-resistant MFA, for privileged users and make MFA a default, rather than opt-in, feature.
Download the PDF version of this report:
INTRODUCTION
CISA has authority to—upon request—provide analyses, expertise, and other technical assistance to critical infrastructure owners and operators and provide operational and timely technical assistance to federal and non-federal entities with respect to cybersecurity risks. (See generally 6 U.S.C. §§ 652[c][5], 659[c][6]). The target organization for this assessment was a critical infrastructure organization in the United States. After receiving a request for an RTA from the organization and coordinating the high-level details of the engagement, CISA conducted the RTA over approximately a three-month period.
During RTAs, a CISA red team simulates real-world threat actors to assess an organization’s cybersecurity detection and response capabilities. During Phase I, the red team attempts to gain and maintain persistent access to an organization’s enterprise network, avoid detection, evade defenses, and access SBSs. During Phase II, the red team attempts to trigger a security response from the organization’s people, processes, and/or technology.
Drafted in coordination with the assessed organization, this advisory details the red team’s activity and TTPs, associated network defense activity, and lessons learned to provide network defenders with recommendations for improving an organization’s cybersecurity posture. The advisory also provides recommendations for 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® Matrix for Enterprise framework, version 15. See the MITRE ATT&CK Tactics and Techniques section for a table of the red team’s activity mapped to MITRE ATT&CK tactics and techniques with corresponding mitigation and/or detection recommendations. 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.
Phase I: Red Team Cyber Threat Activity
Overview
The CISA red team operated without prior knowledge of the organization’s technology assets and began the assessment by conducting open source research on the target organization to gain information about its network [T1590], defensive tools [T1590.006], and employees [T1589.003]. The red team designed spearphishing campaigns [T1566] tailored to employees most likely to communicate with external parties. The phishing attempts were ultimately unsuccessful—targets ran the payloads [T1204], but their execution did not result in the red team gaining access into the network.
After the failed spearphishing campaigns, the red team continued external reconnaissance of the network [T1595] and discovered a web shell [T1505.003] left from a previous bug bounty program. The red team used this for initial access [TA0001] and immediately reported it to the organization’s trusted agents (TAs). The red team leveraged that access to escalate privileges [TA0004] on the host, discover credential material on a misconfigured Network File System (NFS) share [T1552.001], and move from a DMZ to the internal network [TA0008].
With access to the internal network, the red team gained further access to several SBSs. The red team leveraged a certificate for client authentication [T1649] they discovered on the NFS share to compromise a system configured for Unconstrained Delegation. This allowed the red team to acquire a ticket granting ticket (TGT) for a domain controller [T1558.001]. The red team used that TGT to further compromise the domain. The red team leveraged this level of access to exploit SBS targets provided by the organization’s TAs.
The assessed organization detected much of the red team’s activity in their Linux infrastructure after CISA alerted them via other channels to the vulnerability the red team used for initial access. Once given an official notification of a vulnerability, the organization’s network defenders began mitigating the vulnerability. Network defenders removed the site hosting the web shell from the public internet but did not take the server itself offline. A week later, network defenders officially declared an incident once they determined the web shell was used to breach the internal network. For several weeks, network defenders terminated much of the red team’s access until the team maintained implants on only four hosts. Network defenders successfully delayed the red team from accessing many SBSs that required additional positioning, forcing the red team to spend time refortifying their access in the network. Despite these actions, the red team was still able to access a subset of SBSs. Eventually, the red team and TAs decided that the network defenders would stand down to allow the red team to continue its operations in a monitoring mode. In monitoring mode, network defenders would report what they observed of the red team’s access, but not continue to block and terminate it.
See Figure 1 for a timeline of the red team’s activity with key points access. See the following sections for additional details, including the red team’s TTPs.
Figure 1: Timeline of Red Team Cyber Threat Activity
Initial Access
Following an unsuccessful spearphishing campaign, the red team gained initial access to the target by exploiting an internet-facing Linux web server [T1190] discovered through reconnaissance [TA0043] of the organization’s external internet protocol (IP) space [T1590.005].
The red team first conducted open source research [T1593] to identify information about the organization’s network including the tools used to protect the network and potential targets for spearphishing. The red team looked for email addresses [T1589.002] and names to infer email addresses from the organization’s email syntax (discovered during reconnaissance). Following, the red team sent tailored spearphishing emails to 13 targets [T1566.002]. Of these 13 targets, one user responded and executed two malicious payloads [T1204.002]. However, the payloads failed to bypass a previously undiscovered technical control employed by the victim organization, which prevented the red team’s first attempt to gain initial access.
To find an alternate pathway for initial access, the red team conducted reconnaissance with several publicly available tools, such as Shodan and Censys, to discover accessible devices and services on the internet [T1596.005]. The red team identified an old and unpatched service with a known XML External Entity (XXE) vulnerability and leveraged a public proof of concept to deploy a web shell. The associated product had an exposed endpoint—one that system administrators should typically block from the public internet—that allowed the red team to discover a preexisting web shell on the organization’s Linux web server. The preexisting web shell allowed the red team to run arbitrary commands on the server [T1059] as a user (WEBUSER1). Using the web shell, the red team identified an open internal proxy server [T1016] to send outbound communications to the internet via Hypertext Transfer Protocol Secure (HTTPS). The red team then downloaded [T1105] and executed a Sliver payload that utilized this proxy to establish command and control (C2) over this host, calling back to their infrastructure [TA0011].
Note: Because the web shell and unpatched vulnerability allowed actors to easily gain initial access to the organization, the CISA red team determined this was a critical vulnerability. CISA reported both the vulnerability and the web shell to the organization in an official vulnerability notification so the organization could remediate both issues. Following this notification, the victim organization initiated threat hunting activities, detecting some of the red team’s activity. The TAs determined that network defenders had previously identified and reported the vulnerability but did not remediate it. Further, the TAs found that network defenders were unaware of the web shell and believed it was likely leftover from prior VDP activity. See the Defense Evasion and Victim Network Defense Activities section for more information.
Linux Infrastructure Compromise
Local Privilege Escalation and Credential Access
The red team then moved laterally from the web server to the organization’s internal network using valid accounts [T1078] as the DMZ was not properly segmented from the organization’s internal domain.
The red team acquired credentials [TA0006] by first escalating privileges on the web server. The team discovered that WEBUSER1 had excessive sudo rights, allowing them to run some commands as root commands without a password. They used these elevated rights to deploy a new callback with root access [T1548.003].
With root access to the web server, the team had full access to the organization’s directories and files on a NFS share with no_root_squash enabled. If no_root_squash is used, remote root users can read and change any file on the shared file system and leave a trojan horse [T1080] for other users to inadvertently execute. On Linux operating systems this option is disabled by default, yet the organization enabled it to accommodate several legacy systems. The organization’s decision to enable the no_root_squash option allowed the red team to read all the files on the NFS share once it escalated its privileges on a single host with the NFS share mounted. This NFS share hosted the home directories of hundreds of Linux users—many of which had privileged access to one or more servers—and was auto-mounted when those users logged into Linux hosts in the environment.
The red team used its escalated privileges to search for private certificate files, Secure Shell (SSH) private keys, passwords, bash command histories [T1552.003], and other sensitive data across all user files on the NFS share [T1039]. The team initially obtained 61 private SSH keys [T1552.004] and a file containing valid cleartext domain credentials (DOMAINUSER1) that the team used to authenticate to the organization’s domain [T1078.002].
Linux Command and Control
In the organization’s Linux environment, the red team leveraged HTTPS connections for C2 [T1071.001]. Most of the Linux systems could not directly access the internet, but the red team circumvented this by leveraging an open internal HTTPS proxy [T1090.001] for their traffic.
Lateral Movement and Persistence
The red team’s acquisition of SSH private keys generated for user and service accounts facilitated unrestricted lateral movement to other Linux hosts [T1021.004]. This acquisition included two highly privileged accounts with root access to hundreds of servers. Within one week of initial access, the team moved to multiple Linux servers and established persistence [TA0003] on four. The team used a different persistence mechanism on each Linux host, so network defenders would be less likely to discover the red team’s presence on all four hosts. The team temporarily backdoored several scripts run at boot time to maintain persistence [T1037], ensuring the original versions of the scripts were re-enabled once the team successfully achieved persistence. Some of the team’s techniques included modifying preexisting scripts run by the cron utility [T1053.003] and ifup-post scripts [T1037.003].
Of note, the team gained root access to an SBS-adjacent infrastructure management server that ran Ansible Tower. Access to this Ansible Tower system [T1072] provided easy access to multiple SBSs. The team discovered a root SSH private key on the host, which allowed the team to move to six SBSs across six different sensitive IP ranges. A week after the team provided screenshots of root access to the SBSs to the TAs, the TAs deconflicted the red team’s access to the Ansible Tower system that network defenders discovered. The organization detected the compromise by observing abnormal usage of the root SSH private key. The root SSH private key was used to log into multiple hosts at times and for durations outside of preestablished baselines. In a real compromise, the organization would have had to shut down the server, significantly impacting business operations.
Windows Domain Controller Compromise
Approximately two weeks after gaining initial access, the red team compromised a Windows domain controller. This compromise allowed the team to move laterally to all domain-joined Windows hosts within the organization.
To first gain situational awareness about the organization’s environment, the red team exfiltrated Active Directory (AD) information [TA0010] from a compromised Linux host that had network access to a Domain Controller (DC). The team queried Lightweight Directory Access Protocol (Over SSL)—(LDAPS)—to collect information about users [T1087.002], computers [T1018], groups [T1069.002], access control lists (ACL), organizational units (OU), and group policy objects (GPO) [T1615]. Unfortunately, the organization did not have detections to monitor for anomalous LDAP traffic. A non-privileged user querying LDAP from the organization’s Linux domain should have alerted network defenders.
The red team observed a total of 42 hosts in AD that were not DCs, but had Unconstrained Delegation enabled. Hosts with Unconstrained Delegation enabled store the Kerberos TGTs of any user that authenticates to them. With sufficient privileges, an actor can obtain those tickets and impersonate associated users. A compromise of any of these hosts could lead to the escalation of privileges within the domain. Network defenders should work with system administrators to determine whether Unconstrained Delegation is necessary for their systems and limit the number of systems with Unconstrained Delegation unnecessarily enabled.
The red team observed insufficient network segmentation between the organization’s Linux and Windows domains. This allowed for Server Message Block (SMB) and Kerberos traffic to a DC and a domain server with Unconstrained Delegation enabled (UDHOST). The team discovered an unprotected Personal Information Exchange (.pfx) file on the NFS home share that they believed was for UDHOST based on its naming convention.
Equipped with the .pfx file, the red team used Rubeus—an open source toolset for Kerberos interaction and abuses—to acquire a TGT and New Technology Local Area Network Manager (NTLM) hash for UDHOST from the DC. The team then used the TGT to abuse the Server-for-User-to-Self (S4U2Self) Kerberos extension to gain administrative access to UDHOST.
The red team leveraged this administrative access to upload a modified version of Rubeus in monitor mode to capture incoming tickets [T1040] on UDHOST with Rubeus’ /monitor command. Next, the team ran DFSCoerce.py to force the domain controller to authenticate to UDHOST [T1187]. The team then downloaded the captured tickets from UDHOST.
With the DC’s TGT, the team used Domain Controller Sync (DCSync) through their Linux tunnels to acquire the hash of several privileged accounts—including domain, enterprise, and server administrators—and the critical krbtgt account [T1003.006].
Gaining access to AD is not unusual for most of CISA’s Red Team engagements, but it is rare to find network defenders who can secure and monitor it quickly and effectively.
Once the team harvested the credentials needed, they moved laterally to nearly any system in the Windows domain (see Figure 2) through the following steps (hereafter, this combination of techniques is referred to as the “Preferred Lateral Movement Technique”):
The team either forged a golden ticket using the krbtgt hash or requested a valid TGT using the hashes they exfiltrated for a specific account before loading the ticket into their session for additional authentication.
The team dropped an inflated Dynamic Link Library (DLL) file associated with legitimate scheduled tasks on the organization’s domain.
When the scheduled task executed on its own or through the red team’s prompting, the DLL hijack launched a C2 implant.
Figure 2: Movement to Domain Controller
Windows Command and Control
The red team initially established C2 on a workstation over HTTPS before connecting to servers over SMB [T1071.002] in the organization’s Windows environment. To connect to certain SBSs later in its activity, the team again relied on HTTPS for C2.
Post-Exploitation Activity: Gaining Access to SBSs
After the red team gained persistent access to Linux and Windows systems across the organization’s networks, the team began post-exploitation activities and attempted to access SBSs. The TAs provided a scope of the organization’s Classless Inter-Domain Routing (CIDR) ranges that contained SBSs. The team gained root access to multiple Linux servers in these ranges. The TAs then instructed the red team to exploit its list of primary targets: admin workstations and network ranges that included OT networks. The team only achieved access to the first two targets and did not find a path to the OT networks. While the team was able to affect the integrity of data derived from OT devices and applications, it was unable to find and access the organization’s internal network where the OT devices resided.
To gain access to the SBSs, the team first gained access to Microsoft System Center Configuration Manager (SCCM) servers, which managed most of the domain’s Windows systems. To access the SCCM servers, the team leveraged their AD data to identify administrators [T1087] of these targets. One of the users they previously acquired credentials for via DCSync was an administrator on the SCCM servers. The red team then used the Preferred Lateral Movement Technique to eventually authenticate to the SCCM servers. See Figure 3.
Figure 3: Attack Path to SCCM Server
Admin Workstations
The first specific set of SBS targets provided by the TAs were admin workstations. These systems are used across various sensitive networks external to, or inaccessible from, the internal network where the team already had access. Normally, authorized personnel leverage these administrator workstations to perform administrator functions. CISA’s red team targeted these systems in the hopes that an authorized—but unwitting—user would move the tainted system to another network, resulting in a callback from the sensitive target network.
The red team reviewed AD data to identify these administrator systems. Through their review, the team discovered a subset of Windows workstations that could be identified with a prefix and determined a group likely to have administrative rights to the workstations.
With access to the SCCM server, the red team utilized their Preferred Lateral Movement Technique to gain access to each admin workstation target (see Figure 4).
Figure 4: Attack Path from SCCM Server to Admin Workstations
The red team maintained access to these systems for several weeks, periodically checking where they were communicating from to determine if they had moved to another network. Eventually, the team lost access to these systems without a deconfliction. To the best of the red team’s knowledge, these systems either did not move to new networks or, if they did, those systems no longer had the ability to communicate with red team’s C2 infrastructure.
Additional Host and Other Subnets
Figure 5: Attack Path from SCCM Server to Host and Other Subnets
After compromising admin workstations, the red team requested that the TAs prioritize additional systems or IP ranges. The TAs provided four CIDR ranges to target:
A corporate DMZ that contained a mixture of systems and other subnets.
A second subnet.
A third subnet.
An internal network that contained OT devices.
Access to the corporate DMZ was necessary to reach the second and third ranges, and the red team hoped that gaining access to these would facilitate access to the fourth range.
The red team followed a familiar playbook to gain access to these SBSs from another SCCM server. First, the team performed reverse DNS lookups [T1596.001] on IP addresses within the ranges the TAs provided. They then scanned SMB port 445/TCP [T1046] from a previously compromised SCCM server to discover Windows hosts it could access on the corporate DMZ. The team discovered the server could connect to a host within the target IP range and that the system was running an outdated version of Windows Server 2012 R2. The default configuration of Windows Server 2012 R2 allows unprivileged users to query the group membership of local administrator groups. The red team discovered a user account [T1069] by querying the Windows Server 2012 R2 target that was in a database administrator group. The team leveraged its Preferred Lateral Movement Technique to authenticate to the target as that user, then repeated that technique to access a database. This database receives information from OT devices used to feed monitoring dashboards, information which factors into the organization’s decision-making process [T1213].
The new host had several active connections to systems in the internal ranges of the second and third subnets. Reverse domain name system (DNS) lookup requests for these hosts failed to return any results. However, the systems were also running Windows Server 2012 R2. The red team used Windows API calls to NetLocalGroupEnum and NetLocalGroupGetMembers to query local groups [T1069.001], revealing the system names for these targets as a result. The red team performed their Preferred Lateral Movement Technique to gain access to these hosts in the second and third provided network ranges.
With access to these subnets, the red team began exploring a path to systems on a private subnet where OT devices resided but failed to locate a path to that fourth subnet.
Corporate Workstations of Critical Infrastructure Administrators and Operators
Next, the red team targeted the corporate workstations of the administrators and operators of the organization’s critical infrastructure. Because the team lacked knowledge of the organization’s OT devices and failed to discover a path to the private subnet where they resided, they instead tried to locate users that interacted with human machine interfaces (HMI). Access to such users could enable the team to access the HMI, which serves as a dashboard for OT.
The red team leveraged its AD data once again, combining this data with user information from SCCM to identify targets by job role and their primary workstation. Then the team targeted the desktop of a critical infrastructure administrator, the workstation of another critical infrastructure administrator, and the workstations of three critical infrastructure operators spread across two geographically disparate sites.
The AD data revealed users in a group that were administrators of all the targets. The red team then repeated their Preferred Lateral Movement Technique and identified a logged-in user connected to a “System Status and Alarm Monitoring” interface. The team discovered credentials to the interface in the user’s home directory, proxied through the system, and accessed the HMI interface over HTTP. The team did not pursue further activity involving the interface because their remaining assessment time was limited. Additionally, they did not discover a way to compromise the underlying OT devices.
Command and Control
The team used third-party owned and operated infrastructure and services [T1583] throughout its assessment, including in certain cases for command and control (C2). The tools that the red team obtained included [T1588.002]:
Sliver, Mythic, Cobalt Strike, and other commercial C2 frameworks.
The team maintained multiple command and control servers hosted by several cloud vendors. They configured each server with a different domain and used the servers for communication with compromised hosts. These servers retained all assessment data.
Two commercially available cloud-computing platforms.
The team used these platforms to create flexible and dynamic redirect servers to send traffic to the team’s servers [T1090.002]. Redirecting servers make it difficult for defenders to attribute assessment activities to the backend team servers. The redirectors use HTTPS reverse proxies to redirect C2 traffic between the target organization’s network and the team servers. The team encrypted all data in transit [T1573] and secured all data at rest through a VPN with multifactor authentication.
Content delivery network (CDN) services.
This technique leverages CDNs associated with high-reputation domains, causing malicious traffic to appear directed towards a reputational domain. However, it is redirected to red team-controlled servers. This allows the team to obfuscate some of their C2 traffic.
The team used domain fronting [T1090.004] to disguise outbound traffic, diversifying communications between the domains and the persistent beacons. This technique (which also leverages CDNs) allows the beacon to appear to connect to third-party domains but instead connects to the team’s redirect server.
Defense Evasion and Victim Network Defense Activities
Most of the encounters between the red team and network defenders occurred in the organization’s Linux environment. The red team leveraged Linux tradecraft in an attempt to evade network defenses. In response, network defenders’ threat hunting activities identified some of the team’s presence in their Linux environment. To evade defenses, the red team reordered the process identifier (PID) of its executable processes to appear closer to the kernel and minimize the team’s likelihood of detection. The team also modified its processes [T1055] by changing their names in memory and at execution. In addition, they used Python scripts [T1059.006] run in memory [T1620] to avoid on-disk detection. Some of the red team’s Linux persistence techniques included modifying preexisting scripts run by the cron utility and creating backdoors through ifup-post scripts and .bashrc. Network defenders ultimately identified the team’s backdoor in .bashrc [T1546.004].
Defenders also successfully detected anomalous activity on their Ansible Tower host and other systems in their Linux environment. The defenders actively analyzed NetFlow data, which helped them identify the red team’s persistence and lateral movement. To mitigate the impact of the red team’s tactics, network defenders would have needed to shut down a critical server as part of their incident response activities. A shut down would have resulted in downtime for hundreds of systems, including SBSs.
The organization’s EDR solutions largely failed to protect the organization. EDR detected only a few of the red team’s payloads in the organization’s Windows and Linux environments. In the instance the EDR protected the organization from the initial phishing payload, it generated an alert that network defenders neither read nor responded to. The red team excelled in bypassing EDR solutions by avoiding the use of basic “known-bad” detections the tools would capture. The team also inflated its file sizes above the upload threshold of the organization’s EDR [T1027.001]. In addition, the organization completely lacked any EDR solution in a legacy environment. As such, the red team’s persistence there went undetected throughout the assessment.
Network defenders failed to detect red team activity in the organization’s Windows environment due to a lack of proper identity management. Specifically, network defenders failed to detect and respond to the red team’s S4U2Self, asktgs, dcsync, and golden ticket activity. Had the organization monitored for unusual activity involving AD and Kerberos, they would have detected more red team activity.
Lastly, there were significant deficiencies in the organization’s DMZ that should have detected traffic into the organization’s internal network over the ports used by SMB and LDAPS. Network defenders never properly implemented an intrusion detection system (IDS) or intrusion prevention system (IPS) to monitor the DMZ at the network level. This lack of implementation resulted in a failure to detect malicious network traffic through their DMZ. Further, the red team was able to move laterally through the DMZ because there was an open internal proxy with internet access that enabled the team’s C2.
Phase II: Red Team Measurable Events Activity
The red team executed 13 measurable events designed to provoke a response from the people, processes, and technology defending the organization’s network. The red team did not have full visibility into the organization’s responses to these events and lacked the support of a white team to help assess the organization’s responses. See Table 1 for a description of the events, the organization’s actual response, and key takeaways.
Table 1: Measurable Events
Measurable Event
Description
MITRE ATT&CK Technique(s)
Organization’s Reported Reactions
Key Takeaways
Internal Port Scan
Launches a scan from inside the network from a previously gained workstation to enumerate ports on target workstation, server, and domain controller system(s).
Identified an AD enumeration tool and temporarily blocked access to one C2 domain, which resulted in the red team temporarily losing access to six SCCM servers.
The organization did not report identifying the port scan. In addition, with proper network segmentation, the scan’s target hosts should not have been able to communicate.
Comprehensive Active Directory and Host Enumeration
Performs AD enumeration by querying all domain objects from the DC and enumerates trust relationships within the AD Forest, user accounts, and current session information from every domain computer (workstation and server).
Identified an AD enumeration tool and temporarily blocked access to one C2 domain, which resulted in the red team temporarily losing access to six SCCM servers.
The organization did not report identifying the port scan. In addition, with proper network segmentation, the scan’s target hosts should not have been able to communicate.
Data Exfiltration—1 GB of Data
Sends a large amount (1GB) of mock sensitive information to an external host.
A proxy likely blocked 1GB of data exfiltration during the red team’s first attempt. However, the team’s second attempt was successful when they exfiltrated the data in 100MB blocks. Hours after the data exfiltration, the organization blocked the domain used for C2 and removed access to the compromised host.
Organizations should implement web proxies that contain data threshold restrictions. Furthermore, network defenders need to manually analyze proxy data to determine whether there is legitimate outbound traffic or potentially malicious data exfiltration.
Malicious Traffic Generation- Workstation to External Host
Establishes a session that originates from a target workstation system directly to an external host over a clear text protocol, such as HTTP.
The organization’s password policy locked out the AD accounts. However, within minutes the accounts reopened, likely due to a group policy and/or an automated response.
There was no identified active response from the organization. Organizations should monitor AD account activity in Windows event logs against baselines to detect anomalous and potentially malicious activity.
Local Admin User Account Creation (workstation)
Creates a local administrator account on a target workstation system.
An alert existed for this action but was disabled at the time the original event was triggered, thus it was undetected. After coordination between the TAs and red team revealed this lapse, the alert was enabled, the red team performed the action once again, and this time, TAs provided a screenshot of the alert from their monitoring dashboards.
Detection tools are only useful when network defenders tune them appropriately and effectively monitor alerts. At first, the organization missed an opportunity to respond to a tool that should have produced a true positive alert because it was misconfigured.
Domain Admin Lateral Movement—Workstation to Domain Controller and Workstation to Workstation
Compromises a Domain Admin account and uses it to run PSExec on multiple workstations and domain controllers.
Detect malicious use of standard tools like PSExec that malicious cyber actors may use for lateral movement by monitoring Windows logs for anomalous activity. In addition, organizations should look for abnormal communications between workstations.
Malicious Traffic Generation- Domain Controller to External Host
Establishes a session that originates from a target domain controller system directly to an external host over a clear text protocol, such as HTTP.
Malicious file was removed by host-based endpoint protection system.
Host based detection tools can be helpful in detecting known IOCs. However, organizations should focus on detecting anomalous behavior by monitoring their networks and hosts against good baselines. The blocking of this well-known tool on a DC should trigger an urgent investigation.
Ransomware Simulation
Executes simulated ransomware on multiple workstation systems to simulate a ransomware attack.
Note: This technique does not encrypt files on the target system.
N/A
Two out of nine users reported the event to defensive staff who identified all hosts that executed the ransomware. Five users likely rebooted their systems when observing the ransomware, one logged off and on, one closed the ransomware application repeatedly and continued working, one locked their screen, and another user exited the ransomware process after two hours.
Security awareness training should provide employees effective tools on how to respond to ransomware activity.
LESSONS LEARNED AND KEY FINDINGS
The red team noted the following lessons learned relevant to all organizations generated from the security assessment of the organization’s network. These 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 mitigate these findings.
Lesson Learned: Insufficient Technical Controls
The assessed organization had insufficient technical controls to prevent and detect malicious activity. The organization relied too heavily on host-based EDR solutions and did not implement sufficient network layer protections.
Finding #1: The organization’s perimeter network was not adequately firewalled from its internal network, which allowed the red team a path through the DMZ to internal networks. A properly configured network should block access to a path from the DMZ to other internal networks.
Finding #2: The organization was too reliant on its host-based tools and lacked network layer protections, such as well-configured web proxies or intrusion prevention systems (IPS). The organization’s EDR solutions also failed to catch all the red team’s payloads. Below is a list of some of the higher risk activities conducted by the team that were opportunities for detection:
Phishing;
Kerberoasting;
Generation and use of golden tickets;
S4U2self abuse;
Anomalous LDAP traffic;
Anomalous NFS enumeration;
Unconstrained Delegation server compromise;
DCSync;
Anomalous account usage during lateral movement;
Anomalous outbound network traffic;
Anomalous outbound SSH connections to the team’s cloud servers from workstations; and
Use of proxy servers from hosts intended to be restricted from internet access.
Finding #3: The organization had insufficient host monitoring in a legacy environment. The organization had hosts with a legacy operating system without a local EDR solution, which allowed the red team to persist for several months on the hosts undetected.
Lesson Learned: Continuous Training, Support, and Resources
The organization’s staff requires continuous training, support, and resources to implement secure software configurations and detect malicious activity. Staff need to continuously enhance their technical competency, gain additional institutional knowledge of their systems, and ensure are provided sufficient resources by management to adequately protect their networks.
Finding #4: The organization had multiple systems configured insecurely. This allowed the red team to compromise, maintain persistence, and further exploit those systems (i.e., access credentials, elevate privileges, and move laterally). Insecure system configurations included:
Default server configurations. The organization used default configurations for hosts with Windows Server 2012 R2, which allows unprivileged users to query membership of local administrator groups. This enabled the red team to identify several standard user accounts with administrative access. Note: By default, NFS shares change the root user to the nfsnobody user, an unprivileged user account. In this way, users with local root access are prevented from gaining root level access over the mounted NFS share. Here, the organization deviated from the secure by default configuration and implemented the no_root_squash option to support a few legacy systems instead. This deviation from the default allowed the red team to escalate their privileges over the domain.
Hosts with Unconstrained Delegationenabled unnecessarily. Hosts with Unconstrained Delegation enabled will store the Kerberos TGTs of all users that authenticate to that host. This affords threat actors the opportunity to steal TGTs, including the TGT for a domain controller, and use them to escalate their privileges over the domain.
Insecure Account Configuration. The organization had an account running a Linux webserver with excessive privileges. The entry for that user in the sudoers file—which controls user rights—contained paths with wildcards where that user had write access, allowing the team to escalate privileges. Note: This file should only contain specific paths to executable files that a user needs to run as another user or root, and not a wildcard. Users should not have write access over any file in the sudoers entry.
Finding #5: The red team’s activities generated security alerts that network defenders did not review. In many instances, the organization relied too heavily on known IOCs and their EDR solutions instead of conducting independent analysis of their network activity compared against baselines.
Finding #6: The organization lacked proper identity management. Because network defenders did not implement a centralized identity management system in their Linux network, they had to manually query every Linux host for artifacts related to the red team’s lateral movement through SSH. Defenders also failed to detect anomalous activity in their organization’s Windows environment because of poor identity management.
Lesson Learned: Business Risk
The organization’s leadership minimized the business risk of known attack vectors for their organization. Leadership deprioritized the treatment of a vulnerability their own cybersecurity team identified, and in their risk-based decision-making, miscalculated the potential impact and likelihood of its exploitation.
Finding #7: The organization used known insecure and outdated software. The red team discovered software on one of the organization’s web servers that was outdated.
After their operations, the red team learned the insecure and outdated software was a known security concern. The organization’s security team alerted management to the risks associated this software, but management accepted the risk.
Next, the security team implemented a VDP program, which resulted in a participant exploiting the vulnerability for initial access. The VDP program helped the security team gain management support, and they implemented a web application firewall (WAF) as a compensating control. However, they did not adequately mitigate the vulnerability as they configured the WAF to be only in monitoring mode. The security team either did not have processes (or implement them properly) to scan, assess, and test whether they treated the vulnerability effectively.
Additional Findings
The red team noted the following additional issues relevant to the security of the organization’s network that contributed to their activity.
Unsecured Keys and Credentials. The organization stored many private keys that lacked password protection, allowing the red team to steal the keys and use them for authentication purposes.
The private key of a PFX file was not password protected, allowing the red team to use that certificate to authenticate to active directory, access UDHOST, and eventually compromise the DC. In addition, the organization did not require password protection of SSH private keys. Note: Without a password protected key, an actor can more easily steal the private key and use it to authenticate to a system through SSH.
The organization had files in a home share that contained cleartext passwords. The accounts included, among other accounts, a system administrator. Note: The organization appeared to store cleartext passwords in the description and user password sections of Active Directory accounts. These passwords were accessible to all domain users.
Email Address Verification. The active Microsoft Office 365 configuration allows an unauthenticated external user to validate email addresses through observing error messages in the form of HTTP 302 versus HTTP 200 responses. This misconfiguration helps threat actors verify email addresses before sending phishing emails.
Noted Strengths
The red team noted the following technical controls or defensive measures that prevented or hampered offensive actions:
Network defenders detected the initial compromise and some red team movement. After being alerted of the web shell, the organization initiated hunt activities, detected initial access, and tracked some of the red team’s Phase I movements. The organization terminated much of the red team’s access to the organization’s internal network. Of note, once the organization’s defenders discovered the red team’s access, the red team spent significant time and resources continuously refortifying their access to the network.
Host-based EDR solutions prevented initial access by phishing. The EDR stopped the execution of multiple payloads the red team sent to a user of the organization over a week long period. The organization leveraged two products on workstations, one that was publicly discoverable and another the red team did not learn about until gaining initial access. The product the red team was unaware of, and did not test their payload against, was responsible for stopping the execution of their payloads.
Strong domain password policy. The organization’s domain password policy neutralized the red team’s attempts to crack hashes and spray passwords. The team was unable to crack any hashes of all 115 service accounts it targeted.
Effective separation of privileges. The organization’s administrative users had separate accounts for performing privileged actions versus routine activities. This makes privilege escalation more difficult for threat actors.
MITIGATIONS
Network Defenders
CISA recommends organizations implement the recommendations in Table 2 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 2: Recommendations to Mitigate Identified Findings
Finding
Recommendation
Insufficient Network Segmentation of DMZ
Apply the principle of least privilege to limit the exposure of systems and services in the DMZ.
Segment the DMZ based on the sensitivity of systems and services [CPG 2.F].
Implement firewalls, access control lists, and intrusion prevention systems.
Insufficient Network Monitoring
Establish a security baseline of normal network traffic and tune network appliances to detect anomalous behavior. Tune host-based products to detect anomalous binaries, lateral movement, and persistence techniques [CPG 3.A].
Create alerts for Windows event log authentication codes, especially for the domain controllers. This chttps://www.cisa.gov/cross-sector-cybersecurity-performance-goals#DetectingRelevantThreatsandTTPs3Aould help detect some of the pass-the-ticket, DCSync, and other techniques described in this report.
Reduce the attack surface by limiting the use of legitimate administrative pathways and tools such as PowerShell, PsExec, and WMI, which are often used by malicious actors. Select one tool to administer the network, enable logging, and disable the others.
Insufficient Host Monitoring in Legacy Environment
Implement an EDR solution to monitor Solaris hosts for suspicious activity and to detect breaches [CPG 3.A].
Insecure configurations of systems
Do not use the no_root_squashoption.
RemoveUnconstrained Delegationfrom all servers. If Unconstrained Delegation functionality is required, upgrade operating systems and applications to leverage other approaches (e.g., Constrained Delegation) or explore whether systems can be retired or further isolated from the enterprise.
Consider disabling or limiting NTLM and WDigest Authentication if possible. Instead, use modern federation protocols (SAML, OIDC) or Kerberos for authentication with AES-256 bit encryption.
Ensure thesudoersfile contains only essential commands, avoids the use of wildcards, and contains password requirements for command execution.
Lack centralized identity management and monitoring systems
From a detection standpoint, focus on identity and access management (IAM) rather than just network traffic or static host alerts.
Examine who is accessing a resource, what is being accessed, where the request originates, and the time of activity.
Use of known insecure and outdated software
Keep systems and software up to date. If updates cannot be uniformly installed, update insecure configurations to meet updated standards.
Insecure Keys and Credentials
Implement a password protection policy for all certificates that contain private keys that ensures every certificate is encrypted with a strong password. Ensure all certificates are stored in a secure location [CPG 2.L].
Regularly audit network shares to identify files that contain passwords accessible to multiple users [CPG 2.L].
Provide training on the proper use of password management tools.
Implement a policy that prohibits storing passwords in plaintext, and regularly review and audit Active Directory for plain text passwords [CPG 2.L].
If system administrators must store passwords in active directory, restrict access to only users who require them.
Additionally, CISA recommends organizations implement the mitigations below to improve their cybersecurity posture:
Provide users with regular training and exercises, specifically related to phishing emails. Phishing accounts for majority of initial access intrusion events.
Reduce the risk of credential compromise via the following:
Place domain admin accounts in the protected users group to prevent caching of password hashes locally; this also forces Kerberos AES authentication as opposed to weaker RC4 or NTLM authentication protocols.
Upgrade to Windows Server 2019 or greater and Windows 10 or greater. These versions have security features not included in older operating systems.
As a long-term effort, CISA recommends organizations prioritize implementing a more modern, Zero Trustnetwork architecture that:
Leverages secure cloud services for key enterprise security capabilities (e.g., identity and access management, endpoint detection and response, and policy enforcement).
Upgrades applications and infrastructure to leverage modern identity management and network access practices.
Centralizes and streamlines access to cybersecurity data to drive analytics for identifying and managing cybersecurity risks.
Invests in technology and personnel to achieve these goals.
Software Manufacturers
The above mitigations apply to critical infrastructure organizations with on-premises or hybrid environments. Recognizing that insecure software is the root cause of many of these flaws and responsibility should not fall on the end user, CISA urges software manufacturers to implement the following:
Embed security into product architecturethroughout the entire software development lifecycle (SDLC).
Eliminate default passwords. Do not provide software with default passwords. To eliminate default passwords, require administrators to set a strong password [CPG 2.B] during installation and configuration.
Design products so that the compromise of a single security control does not result in compromise of the entire system. For example, narrowly provision user privileges by default and employ ACLs to reduce the impact of a compromised account. This will make it more difficult for a malicious cyber actor to escalate privileges and move laterally.
Mandate MFA, ideally phishing-resistant MFA, for privileged users and make MFA a default, rather than opt-in, feature.
Reduce hardening guide size, with a focus on systems being secure by default. In this scenario, the red team noticed default Windows Server 2012 configurations that allowed them to enumerate privileged accounts. Important: Manufacturers need to implement routine nudges that are built into the product rather than relying on administrators to have the time, expertise, and awareness to interpret hardening guides.
These mitigations align with principles 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 security outcomes of their customers by applying these and other secure by design practices. By adhering to secure by design principles, 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 Table 3 to Table 16).
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.
RESOURCES
APPENDIX: MITRE ATT&CK TACTICS AND TECHNIQUES
See Table 3 to Table 16 for all referenced red team tactics and techniques in this advisory. Note: Unless noted, activity took place during Phase I. 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.
The team conducted reconnaissance with several publicly available tools, such as Shodan and Censys, to discover accessible devices and services on the internet.
The team’s phishing attempts were ultimately unsuccessful; targets ran the payloads, but their execution did not result in the red team gaining access into the network.
After the failed spearphishing campaigns, the red team continued external reconnaissance of the network and discovered a web shell left from a previous VDP program.
The team used its escalated privileges to search for private certificate files, Secure Shell (SSH) private keys, passwords, bash command histories, and other sensitive data across all user files on the NFS share.
The team queried LDAPS to collect information about users, computers, groups, access control lists (ACL), organizational units (OU), and group policy objects (GPO). During Phase II, the team performed AD enumeration by querying all domain objects from the DC, as well as enumerating trust relationships within the AD Forest, user accounts, and current session information from every domain computer.
The team queried LDAPS to collect information about users, computers, groups, access control lists (ACL), organizational units (OU), and group policy objects (GPO). During Phase II, the team performed AD enumeration by querying all domain objects from the DC as well as enumerating trust relationships within the AD Forest, user accounts, and current session information from every domain computer.
The team queried LDAPS to collect information about users, computers, groups, access control lists (ACL), organizational units (OU), and group policy objects (GPO).
The team queried LDAPS to collect information about users, computers, groups, access control lists (ACL), organizational units (OU), and group policy objects (GPO).
During Phase II, the team performed AD enumeration by querying all domain objects from the DC, as well as enumerating trust relationships within the AD Forest, user accounts, and current session information from every domain computer.
The team’s acquisition of SSH private keys of user and service accounts, including two highly privileged accounts with root access to hundreds of servers, facilitated unrestricted lateral movement to other Linux hosts.
During Phase II, the team established a session that originated from a target Workstation system directly to an external host over a clear text protocol, such as HTTP.
WASHINGTON – Today the Cybersecurity and Infrastructure Security Agency (CISA) released a new Venue Guide for Security Considerations to help venue operators enhance safety, protect assets, and create secure environments through effective security measures and best practices.
“Venues have increasingly become targets, yet many lack the resources to secure their day-to-day operations and special events effectively,” said Dr. David Mussington, CISA’s Executive Assistant Director for Infrastructure Security. “In response, and in collaboration with industry experts and security professionals, our agency has developed this guide to empower venue operators with the tools needed to identify and manage risk effectively.”
This guide aims to help venue operators enhance safety, protect assets, and create secure environments through effective security measures and best practices by:
Providing guidance for venues, such as evaluating security measures, complexity levels, costs, options, and threats mitigated by these measures. By balancing these factors, venues can create a secure environment for operators and guests.
Recommending broadly applicable considerations for evaluating security practices, such as assessing measures and improving physical security compliance to ensure staff and visitor safety.
Offering actionable guidance for prioritizing the most effective security practices and proactively reducing the risk of major threats.
Providing venue operators with a tailored menu of security options, allowing them to select the most suitable and effective measures for their venue’s budget, size, location, and risk factors.
###
About CISA
As the nation’s cyber defense agency and national coordinator for critical infrastructure security, the Cybersecurity and Infrastructure Security Agency leads the national effort to understand, manage, and reduce risk to the digital and physical infrastructure Americans rely on every hour of every day.
Washington – The Cybersecurity and Infrastructure Security Agency (CISA) announced the launch of CISA Learning, a learning management system that will modernize training and education for its employees and key stakeholders. This transformative platform is a critical component of CISA’s ongoing efforts to streamline and enhance its enterprise learning environment, ensuring the same training available to CISA personnel is also available free of charge to the nation’s veterans and partners from federal, state, local, tribal, and territorial levels of government. CISA Learning replaces the Federal Virtual Training Environment (FedVTE). Courses and functionalities from FedVTE will be fully transitioned to CISA Learning, ensuring that users continue to have uninterrupted access to critical training content.
“CISA Learning will provide an easy to navigate, modernized learning management system, building on the existing tools and resources that have been instrumental in providing free cybersecurity training to government employees, contractors, and U.S. veterans.” said CISA Chief People Officer Dr. Elizabeth Kolmstetter. “This is part of CISA’s commitment to helping to train and grow the nation’s cybersecurity workforce to better protect the critical infrastructure Americans rely on every day.”
Enhanced Capabilities to Support Growth
CISA Learning is designed to meet the agency’s evolving needs. It will offer a range of scalable training solutions, including:
Classroom-Based Courses
Virtual Instructor-Led Training
Self-Paced Online Modules
With these features, CISA Learning will provide a more adaptable and engaging training experience, enabling users to access courses at their convenience, whether from an office, at home, or in the field.
Centralized Learning Hub for Streamlined Education
As CISA transitions to this centralized platform, all training programs will now be housed under one unified system, reducing the need to use multiple platforms. This will foster a more seamless and holistic user experience. CISA Learning will enable:
Improved Student Administration: Simplified processes for course enrollment, tracking, and reporting.
Enhanced Reporting Capabilities: Detailed insights into course completion and student progress, enabling data-driven decisions for training program development.
Transition from FedVTE to CISA Learning
FedVTE users, including personnel from the federal government, SLTT agencies, and veterans, will benefit from a more robust and scalable platform that meets modern cybersecurity challenges. The Office of the Chief People Officer’s Training and Education branch, in partnership with the Office of Personnel Management’s (OPM) USA Learning platform, will lead this transition, ensuring a smooth shift to the new system.
A New Era for CISA Training
CISA Learning represents a significant milestone in the agency’s workforce and stakeholder development, as it prepares to meet the demands of an ever-changing cybersecurity landscape. The new LMS will be the cornerstone of CISA’s strategy to maintain its position as a leader in cybersecurity education and training.
For more information on the transition from FedVTE or the new portal, please visit CISA Learning | NICCS.
###
About CISA
As the nation’s cyber defense agency and national coordinator for critical infrastructure security, the Cybersecurity and Infrastructure Security Agency leads the national effort to understand, manage, and reduce risk to the digital and physical infrastructure Americans rely on every hour of every day.
First-of-its kind collaboration with industry and civil society recommends new guidance to advance the responsible use of AI in America’s essential services
WASHINGTON – Today, the Department of Homeland Security (DHS) released a set of recommendations for the safe and secure development and deployment of Artificial Intelligence (AI) in critical infrastructure, the “Roles and Responsibilities Framework for Artificial Intelligence in Critical Infrastructure” (“Framework”). This first-of-its kind resource was developed by and for entities at each layer of the AI supply chain: cloud and compute providers, AI developers, and critical infrastructure owners and operators – as well as the civil society and public sector entities that protect and advocate for consumers. The Artificial Intelligence Safety and Security Board (“Board”), a public-private advisory committee established by DHS Secretary Alejandro N. Mayorkas, identified the need for clear guidance on how each layer of the AI supply chain can do their part to ensure that AI is deployed safely and securely in U.S. critical infrastructure. This product is the culmination of considerable dialogue and debate among the Board, composed of AI leaders representing industry, academia, civil society, and the public sector. The report complements other work carried out by the Administration on AI safety, such as the guidance from the AI Safety Institute, on managing a wide range of misuse and accident risks.
America’s critical infrastructure – the systems that power our homes and businesses, deliver clean water, allow us to travel safely, facilitate the digital networks that connect us, and much more – is vital to domestic and global safety and stability. These sectors are increasingly deploying AI to improve the services they provide, build resilience, and counter threats. AI is, for example, helping to quickly detect earthquakes and predict aftershocks, prevent blackouts and other electric-service interruptions, and sort and distribute mail to American households. These uses do not come without risk, and vulnerabilities introduced by the implementation of this technology may expose critical systems to failures or manipulation by nefarious actors. Given the increasingly interconnected nature of these systems, their disruption can have devastating consequences for homeland security.
“AI offers a once-in-a-generation opportunity to improve the strength and resilience of U.S. critical infrastructure, and we must seize it while minimizing its potential harms. The Framework, if widely adopted, will go a long way to better ensure the safety and security of critical services that deliver clean water, consistent power, internet access, and more,” said Secretary Alejandro N. Mayorkas. “The choices organizations and individuals involved in creating AI make today will determine the impact this technology will have in our critical infrastructure tomorrow. I am grateful for the diverse expertise of the Artificial Intelligence Safety and Security Board and its members, each of whom informed these guidelines with their own real-world experiences developing, deploying, and promoting the responsible use of this extraordinary technology. I urge every executive, developer, and elected official to adopt and use this Framework to help build a safer future for all.”
If adopted and implemented by the stakeholders involved in the development, use, and deployment of AI in U.S. critical infrastructure, this voluntary Framework will enhance the harmonization of and help operationalize safety and security practices, improve the delivery of critical services, enhance trust and transparency among entities, protect civil rights and civil liberties, and advance AI safety and security research that will further enable critical infrastructure to deploy emerging technology responsibly. Despite the growing importance of this technology to critical infrastructure, no comprehensive regulation currently exists.
DHS identified three primary categories of AI safety and security vulnerabilities in critical infrastructure: attacks using AI, attacks targeting AI systems, and design and implementation failures. To address these vulnerabilities, the Framework recommends actions directed to each of the key stakeholders supporting the development and deployment of AI in U.S. critical infrastructure as follows:
Cloud and compute infrastructure providers play an important role in securing the environments used to develop and deploy AI in critical infrastructure, from vetting hardware and software suppliers to instituting strong access management and protecting the physical security of data centers powering AI systems. The Framework encourages them to support customers and processes further downstream of AI development by monitoring for anomalous activity and establishing clear pathways to report suspicious and harmful activities.
AI developers develop, train, and/or enable critical infrastructure to access AI models, often through software tools or specific applications. The Framework recommends that AI developers adopt a Secure by Design approach, evaluate dangerous capabilities of AI models, and ensure model alignment with human-centric values. The Framework further encourages AI developers to implement strong privacy practices; conduct evaluations that test for possible biases, failure modes, and vulnerabilities; and support independent assessments for models that present heightened risks to critical infrastructure systems and their consumers.
Critical infrastructure owners and operators manage the secure operations and maintenance of key systems, which increasingly rely on AI to reduce costs, improve reliability and boost efficiency. They are looking to procure, configure, and deploy AI in a manner that protects the safety and security of their systems. The Framework recommends a number of practices focused on the deployment-level of AI systems, to include maintaining strong cybersecurity practices that account for AI-related risks, protecting customer data when fine-tuning AI products, and providing meaningful transparency regarding their use of AI to provide goods, services, or benefits to the public. The Framework encourages critical infrastructure entities to play an active role in monitoring the performance of these AI systems and share results with AI developers and researchers to help them better understand the relationship between model behavior and real-world outcomes.
Civil society, including universities, research institutions, and consumer advocates engaged on issues of AI safety and security, are critical to measuring and improving the impact of AI on individuals and communities. The Framework encourages civil society’s continued engagement on standards development alongside government and industry, as well as research on AI evaluations that considers critical infrastructure use cases. The Framework envisions an active role for civil society in informing the values and safeguards that will shape AI system development and deployment in essential services.
Public sector entities, including federal, state, local, tribal, and territorial governments, are essential to the responsible adoption of AI in critical infrastructure, from supporting the use of this technology to improve public services to advancing standards of practice for AI safety and security through statutory and regulatory action. The United States is a world leader in AI; accordingly, the Framework encourages continued cooperation between the federal government and international partners to protect all global citizens, as well as collaboration across all levels of government to fund and support efforts to advance foundational research on AI safety and security.
President Biden directed Secretary Mayorkas to establish the Board to advise the Secretary, the critical infrastructure community, other private sector stakeholders, and the broader public on the safe and secure development and deployment of AI technology in our nation’s critical infrastructure. Secretary Mayorkas convened the Board for the first time in May 2024, and Board Members identified a number of issues impacting the safe use and deployment of this technology, including: the lack of common approaches for the deployment of AI, physical security flaws, and a reluctance to share information within industries.
The Framework is designed to help address these concerns and complements and advances existing guidance and analysis from the White House, the AI Safety Institute, the Cybersecurity and Infrastructure Security Agency, and other federal partners.
“Ensuring the safe, secure, and trustworthy development and use of AI is vital to the future of American innovation and critical to our national security. This new Framework will complement the work we’re doing at the Department of Commerce to help ensure AI is responsibly deployed across our critical infrastructure to help protect our fellow Americans and secure the future of the American economy.” – Secretary of Commerce, Gina Raimondo
“The Framework correctly identifies that AI systems may present both opportunities and challenges for critical infrastructure. Its developer-focused provisions highlight the importance of evaluating model capabilities, performing security testing, and building secure internal systems. These are key areas for continued analysis and discussion as our understanding of AI capabilities and their implications for critical infrastructure continues to evolve.” – Dario Amodei, CEO and Co-Founder, Anthropic
“I would like to thank the Board for their leadership in developing this important Framework and appreciate the opportunity to provide input that reflects critical infrastructure needs. AI holds the promise to create significant opportunities for our world, but we must ensure the technology is deployed thoughtfully and responsibly. The Framework, developed through countless hours of collaboration and negotiation, provides a foundation for how business, government, and all segments of our society can work together to enhance accountability, integration, and cooperation. I’m looking forward to continued work with our partners in this effort.” – Ed Bastian, CEO, Delta Air Lines
“The AI Roles and Responsibilities Framework promotes collaboration among all key stakeholders with a goal of establishing clear guidelines that prioritize trust, transparency and accountability — all essential elements in harnessing AI’s enormous potential for innovation while safeguarding critical services. Salesforce is committed to humans and AI working together to advance critical infrastructure industries in the U.S. We support this framework as a vital step toward shaping the future of AI in a safe and sustainable manner.” – Marc Benioff, Chair and CEO, Salesforce
“Humane Intelligence fully endorses the ‘Roles and Responsibilities Framework for Artificial Intelligence in Critical Infrastructure,’ developed by the AI Safety and Security Board. This comprehensive framework offers essential guidance for the responsible and secure use of AI across the United States. As an organization dedicated to advancing safe and ethical AI practices, we believe the voluntary responsibilities outlined are crucial steps toward enhancing the safety, security, and trustworthiness of AI systems. By addressing five key roles – cloud and compute infrastructure providers, AI developers, critical infrastructure owners and operators, civil society, and the public sector – the Framework thoughtfully recognizes the diverse stakeholders involved in safeguarding our nation’s critical infrastructure. The emphasis on securing environments, driving responsible model and system design, implementing data governance, ensuring safe and secure deployment, and monitoring performance and impact aligns closely with our mission. We commend the AI Safety and Security Board for providing clear technical and process recommendations that will help ensure AI systems not only function effectively but also serve the public good in a safe and ethical manner. Humane Intelligence is committed to supporting these principles and will continue working with partners across sectors to promote the responsible development and deployment of AI in critical infrastructure.” – Dr. Rumman Chowdhury, CEO & Co-founder, Humane Intelligence
“This Framework recognizes that proper governance of AI in the critical infrastructure ecosystem is a multistakeholder endeavor. If companies, governments, and NGOs embrace the voluntary roles and responsibilities this Framework envisions, deployment of AI in critical infrastructure is more likely to protect security, privacy, civil rights, and civil liberties than would otherwise be the case.” – Alexandra Reeve Givens, President and CEO, Center for Democracy & Technology
“Artificial intelligence has incredible potential to create efficiencies and innovations, and this Framework takes a thoughtful approach to balancing those opportunities with the risks and challenges it creates. Partnership and collaboration between the public and private sectors will be critical as we work to incorporate these advances into infrastructure and services while also taking steps to mitigate potential harm. This Framework represents an important step towards fostering accountability, safety, and security while embracing this technology and the future.” – Bruce Harrell, Mayor of Seattle
“We are pleased that the Roles and Responsibilities Framework prioritizes civil rights to ensure the equitable deployment of AI. The Framework reflects an understanding that in order for our nation’s critical infrastructure to be best protected, AI must first be safe and effective. That starts with ensuring that all applications of AI both defend and promote equal opportunity. The DHS Framework makes significant progress toward meeting those goals.” – Damon Hewitt, President and Executive Director, Lawyers’ Committee for Civil Rights Under Law
“We are proud to be part of the U.S. Department of Homeland Security’s AI Safety and Security Board to develop a Framework that will help encourage the responsible use of AI in the energy industry while ensuring critical infrastructure is protected from cyber threats. With our companywide focus on safety, resilience, and driving innovation, we plan to adopt the Framework in the relevant aspects of our business to promote the further integration of advanced AI technologies in support of sustainable energy development.” – Vicki Hollub, President and CEO, Occidental Petroleum
“As we move into the AI era, our foremost responsibility is ensuring these technologies are safe and beneficial. The DHS AI Framework provides guiding principles that will help us safeguard society, and we support this effort.” – Jensen Huang, Founder and CEO, NVIDIA
“The DHS Roles and Responsibilities Framework for Artificial Intelligence in Critical Infrastructure is a powerful tool to help guide the responsible deployment of AI across America’s critical infrastructure and IBM is proud to support its development. We look forward to continuing to work with the Department to promote shared and individual responsibilities in the advancement of trusted AI systems.” – Arvind Krishna, Chairman and CEO, IBM
“Academia and civil society are vital to deploying AI in critical infrastructure safely. This is a crucial, nonpartisan issue with profound impacts on the nation’s well-being. This Framework reaffirms the commitment to security, transparency, and public trust. Through rigorous research and cross-sector collaboration, we can help create a resilient AI ecosystem that prioritizes the public good.” – Fei-Fei Li, Ph.D., Co-Director, Stanford Human-centered Artificial Intelligence Institute
“Artificial Intelligence technology is already here. The only question is whether we choose to be proactive or reactive when it comes to leveraging the benefits of AI and guarding against vulnerabilities. I applaud the Biden-Harris Administration and the work of the U.S. Department of Homeland Security’s AI Safety and Security Board for their commitment to seizing this moment and putting forth a responsible Framework that will benefit the American people. In partnership, Maryland will continue to work with federal leaders to unlock the power of innovation so we can deliver real results for our communities.” – Wes Moore, Governor of Maryland
“Technology must be built on a foundation of integrity at the highest levels, and DHS’s Roles and Responsibilities Framework for Artificial Intelligence in Critical Infrastructure will ensure the public and private sectors work closely together to enable AI solutions that are secure, reliable, and trustworthy. As a leader in networking and security that will connect and protect the responsible AI revolution, Cisco is proud to have contributed to the Framework alongside important government, industry, and civil society partners. We look forward to supporting the efforts by Secretary Mayorkas and the Department of Homeland Security.” – Chuck Robbins, Chair and CEO, Cisco; Chair, Business Roundtable
“The collaboration between government, industry, and civil society organizations proved beneficial in establishing the DHS ‘Roles and Responsibilities Framework for AI in Critical Infrastructure’ to protect the nation’s assets. The Framework lays out principles for safe and secure AI that averts anticipated and unforeseen risks, and places equal importance on the preservation of civil and human rights for the people and communities impacted by emerging technologies. The Board’s intention to harmonize these goals is a promising first step in the future application and adherence to the Framework.” – Nicol Turner Lee, Ph.D., Senior Fellow and Director of the Center for Technology Innovation, Brookings Institution
“The use of AI in critical infrastructure merits strong measures to prevent harm and ensure everyone has equal access to information, goods, and services. DHS’s outlining of stakeholders’ roles and responsibilities is an important first step to protecting everyone in the U.S. from discrimination in the deployment of AI systems in our nation’s infrastructure.” – Maya Wiley, President and CEO, The Leadership Conference on Civil and Human Rights
DHS is responsible for the overall security and resilience of the nation’s critical infrastructure, which hundreds of millions of Americans rely on every day to light their homes, conduct business, exchange information, and put food on the table. In the 2025 Homeland Threat Assessment, the Department advised that domestic and foreign adversaries will continue to threaten the integrity of our nation’s critical infrastructure due to the cascading impacts on U.S. industries and our standard of living. These threats range from, but are not limited to, the use of AI to span or scale physical attacks; targeted attacks on AI systems supporting critical infrastructure; and failures in AI design and implementation that affect critical infrastructure operations.
To learn more about the Framework or the ways DHS is safely and responsibly leveraging AI to protect the homeland, visit the Artificial Intelligence at DHS webpage.
The U.S. government’s continued investigation into the People’s Republic of China (PRC) targeting of commercial telecommunications infrastructure has revealed a broad and significant cyber espionage campaign.
Specifically, we have identified that PRC-affiliated actors have compromised networks at multiple telecommunications companies to enable the theft of customer call records data, the compromise of private communications of a limited number of individuals who are primarily involved in government or political activity, and the copying of certain information that was subject to U.S. law enforcement requests pursuant to court orders. We expect our understanding of these compromises to grow as the investigation continues.
The Federal Bureau of Investigation (FBI) and the Cybersecurity and Infrastructure Security Agency (CISA) continue to render technical assistance, rapidly share information to assist other potential victims, and work to strengthen cyber defenses across the commercial communications sector. We encourage any organization that believes it might be a victim to engage its local FBI Field Office or CISA.
New trilateral arrangement formalizes collaboration on the production of Arctic and polar icebreakers
WASHINGTON – Officials representing the Governments of the United States, Canada, and Finland today signed a Memorandum of Understanding (MOU) to begin working together to develop world-class Arctic and polar icebreakers through the exchange of knowledge, information, and resources in each of our countries. Today’s landmark MOU builds off the launch of the Icebreaker Collaboration Effort (ICE) Pact by Prime Minister Trudeau, President Stubb, and President Biden on the margins of the NATO Washington Summit in July.
In signing the ICE Pact MOU, we have embarked on a transformative partnership that strengthens our ability to uphold international rules and maintain security in the Arctic and Antarctic regions. By jointly developing and producing world-class Arctic and polar icebreakers, we are laying the foundation for a resilient and competitive shipbuilding industry, capable of meeting both national and global demand for these critical assets. This arrangement underscores our collective commitment to peace, stability, and prosperity in the Arctic and polar regions, and is a testament to the strength of allied cooperation in addressing strategic challenges.
Each of our nations recognizes the need to enhance our Arctic and polar icebreaking capabilities to assert our collective presence in the Arctic and Antarctic regions. Building these specialized vessels at a faster pace, on a larger scale, and at competitive costs is a shared priority as we uphold safety and security in these strategically important areas.
The ICE Pact includes four components: 1) enhanced information exchange between the United States, Canada, and Finland; 2) workforce development collaboration; 3) engagement with allies and partners, and; 4) research and development. Given the high costs of shipbuilding, long-term orders are essential for shipyard success in each of our countries. The collective investment in our domestic shipyards has the potential to scale production and reduce the cost of Arctic and polar icebreakers for our own use and for our allies and partners.
By leveraging our collective expertise and resources, the MOU will facilitate knowledge, information, and resource sharing with shipyards, with the potential to create high-quality manufacturing jobs in the maritime infrastructure industry. ICE Pact will help provide the stability necessary to support the production of Arctic and polar icebreakers and strengthen our shipbuilding industries.
As leaders of Arctic nations, Canada, Finland, and the United States recognize the enduring importance of the region to our shared economic, climate, and national security. Today, we commit to deepen our cooperation to ensure that the polar and Arctic regions remain peaceful, cooperative, and prosperous. Officials from each nation signed a trilateral Memorandum of Understanding (MOU) to formalize the Icebreaker Collaboration Effort (ICE) Pact, a landmark initiative that advances Arctic and polar icebreaker development by combining our collective knowledge, resources, and expertise.
Through the ICE Pact, our governments will strengthen our longstanding ties. As the first initiative under this arrangement, we commit to a collaborative effort to build best-in-class Arctic and polar icebreakers and related capabilities in each of our countries by sharing expertise, information, and resources. Canada, Finland, and the United States will work together to develop an implementation plan to produce these critical vessels, supporting allies and partners with responsibilities in the Arctic and Antarctic regions.
This partnership has the potential to consolidate demand and increase production in our respective shipyards, allowing for efficient and affordable construction of these specialized vessels. By strategically pooling our expertise in Arctic and polar vessel production, together we will take advantage of opportunities to help strengthen demand for shipbuilding, and seek to attract high-quality jobs, support maritime infrastructure supply chains critical to national security, and help support sales to other countries. We invite allies and partners globally to purchase Arctic and polar icebreakers from Canadian, Finnish, and U.S. shipyards, and benefit from reduced costs and faster delivery schedules that ICE Pact will enable.
Beyond joint production of Arctic and polar icebreakers and related capabilities, this partnership will also enable likeminded nations to uphold international rules, norms, and standards, ensuring peace and stability in the Arctic and Antarctic regions for generations to come.