CISA Red Team Shares Key Findings to Improve Monitoring and Hardening of Networks

Release Date February 28, 2023
Alert CodeAA23-059A

SUMMARY

The Cybersecurity and Infrastructure Security Agency (CISA) is releasing this Cybersecurity Advisory (CSA) detailing activity and key findings from a recent CISA red team assessment—in coordination with the assessed organization—to provide network defenders recommendations for improving their organization’s cyber posture.

Actions to take today to harden your local environment:

Establish a security baseline of normal network activity; tune network and host-based appliances to detect anomalous behavior.
Conduct regular assessments to ensure appropriate procedures are created and can be followed by security staff and end users.
Enforce phishing-resistant MFA to the greatest extent possible.

In 2022, CISA conducted a red team assessment (RTA) at the request of a large critical infrastructure organization with multiple geographically separated sites. The team gained persistent access to the organization’s network, moved laterally across the organization’s multiple geographically separated sites, and eventually gained access to systems adjacent to the organization’s sensitive business systems (SBSs). Multifactor authentication (MFA) prompts prevented the team from achieving access to one SBS, and the team was unable to complete its viable plan to compromise a second SBSs within the assessment period.

Despite having a mature cyber posture, the organization did not detect the red team’s activity throughout the assessment, including when the team attempted to trigger a security response.

CISA is releasing this CSA detailing the red team’s tactics, techniques, and procedures (TTPs) and key findings to provide network defenders of critical infrastructure organizations proactive steps to reduce the threat of similar activity from malicious cyber actors. This CSA highlights the importance of collecting and monitoring logs for unusual activity as well as continuous testing and exercises to ensure your organization’s environment is not vulnerable to compromise, regardless of the maturity of its cyber posture.

CISA encourages critical infrastructure organizations to apply the recommendations in the Mitigations section of this CSA—including conduct regular testing within their security operations center—to ensure security processes and procedures are up to date, effective, and enable timely detection and mitigation of malicious activity.

Download the PDF version of this report:

CISA Red Team Shares Key Findings to Improve Monitoring and Hardening of Networks(PDF, 1.06 MB )

TECHNICAL DETAILS

Note: This advisory uses the MITRE ATT&CK® for Enterprise framework, version 12. See the appendix for a table of the red team’s activity mapped to MITRE ATT&CK tactics and techniques.

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].) After receiving a request for a red team assessment (RTA) from an organization and coordinating some high-level details of the engagement with certain personnel at the organization, CISA conducted the RTA over a three-month period in 2022.

During RTAs, a CISA red team emulates cyber threat actors to assess an organization’s cyber detection and response capabilities. During Phase I, the red team attempts to gain and maintain persistent access to an organization’s enterprise network while avoiding detection and evading defenses. During Phase II, the red team attempts to trigger a security response from the organization’s people, processes, or technology.

The “victim” for this assessment was a large organization with multiple geographically separated sites throughout the United States. For this assessment, the red team’s goal during Phase I was to gain access to certain sensitive business systems (SBSs).

Phase I: Red Team Cyber Threat Activity

Overview

The organization’s network was segmented with both logical and geographical boundaries. CISA’s red team gained initial access to two organization workstations at separate sites via spearphishing emails. After gaining access and leveraging Active Directory (AD) data, the team gained persistent access to a third host via spearphishing emails. From that host, the team moved laterally to a misconfigured server, from which they compromised the domain controller (DC). They then used forged credentials to move to multiple hosts across different sites in the environment and eventually gained root access to all workstations connected to the organization’s mobile device management (MDM) server. The team used this root access to move laterally to SBS-connected workstations. However, a multifactor authentication (MFA) prompt prevented the team from achieving access to one SBS, and Phase I ended before the team could implement a seemingly viable plan to achieve access to a second SBS.

Initial Access and Active Directory Discovery

The CISA red team gained initial access [TA0001] to two workstations at geographically separated sites (Site 1 and Site 2) via spearphishing emails. The team first conducted open-source research [TA0043] to identify potential targets for spearphishing. Specifically, the team looked for email addresses [T1589.002] as well as names [T1589.003] that could be used to derive email addresses based on the team’s identification of the email naming scheme. The red team sent tailored spearphishing emails to seven targets using commercially available email platforms [T1585.002]. The team used the logging and tracking features of one of the platforms to analyze the organization’s email filtering defenses and confirm the emails had reached the target’s inbox.

The team built a rapport with some targeted individuals through emails, eventually leading these individuals to accept a virtual meeting invite. The meeting invite took them to a red team-controlled domain [T1566.002] with a button, which, when clicked, downloaded a “malicious” ISO file [T1204]. After the download, another button appeared, which, when clicked, executed the file.

Two of the seven targets responded to the phishing attempt, giving the red team access to a workstation at Site 1 (Workstation 1) and a workstation at Site 2. On Workstation 1, the team leveraged a modified SharpHound collector, ldapsearch, and command-line tool, dsquery, to query and scrape AD information, including AD users [T1087.002], computers [T1018], groups [T1069.002], access control lists (ACLs), organizational units (OU), and group policy objects (GPOs) [T1615]. Note: SharpHound is a BloodHound collector, an open-source AD reconnaissance tool. Bloodhound has multiple collectors that assist with information querying.

There were 52 hosts in the AD that had Unconstrained Delegation enabled and a lastlogon timestamp within 30 days of the query. Hosts with Unconstrained Delegation enabled store Kerberos ticket-granting tickets (TGTs) of all users that have authenticated to that host. Many of these hosts, including a Site 1 SharePoint server, were Windows Server 2012R2. The default configuration of Windows Server 2012R2 allows unprivileged users to query group membership of local administrator groups.

The red team queried parsed Bloodhound data for members of the SharePoint admin group and identified several standard user accounts with administrative access. The team initiated a second spearphishing campaign, similar to the first, to target these users. One user triggered the red team’s payload, which led to installation of a persistent beacon on the user’s workstation (Workstation 2), giving the team persistent access to Workstation 2.

Lateral Movement, Credential Access, and Persistence

The red team moved laterally [TA0008] from Workstation 2 to the Site 1 SharePoint server and had SYSTEM level access to the Site 1 SharePoint server, which had Unconstrained Delegation enabled. They used this access to obtain the cached credentials of all logged-in users—including the New Technology Local Area Network Manager (NTLM) hash for the SharePoint server account. To obtain the credentials, the team took a snapshot of lsass.exe [T1003.001] with a tool called nanodump, exported the output, and processed the output offline with Mimikatz.

The team then exploited the Unconstrained Delegation misconfiguration to steal the DC’s TGT. They ran the DFSCoerce python script (DFSCoerce.py), which prompted DC authentication to the SharePoint server using the server’s NTLM hash. The team then deployed Rubeus to capture the incoming DC TGT [T1550.002], [T1557.001]. (DFSCoerce abuses Microsoft’s Distributed File System [MS-DFSNM] protocol to relay authentication against an arbitrary server.[1])

The team then used the TGT to harvest advanced encryption standard (AES)-256 hashes via DCSync [T1003.006] for the krbtgt account and several privileged accounts—including domain admins, workstation admins, and a system center configuration management (SCCM) service account (SCCM Account 1). The team used the krbtgt account hash throughout the rest of their assessment to perform golden ticket attacks [T1558.001] in which they forged legitimate TGTs. The team also used the asktgt command to impersonate accounts they had credentials for by requesting account TGTs [T1550.003].

The team first impersonated the SCCM Account 1 and moved laterally to a Site 1 SCCM distribution point (DP) server (SCCM Server 1) that had direct network access to Workstation 2. The team then moved from SCCM Server 1 to a central SCCM server (SCCM Server 2) at a third site (Site 3). Specifically, the team:

Queried the AD using Lightweight Directory Access Protocol (LDAP) for information about the network’s sites and subnets [T1016]. This query revealed all organization sites and subnets broken down by classless inter-domain routing (CIDR) subnet and description.
Used LDAP queries and domain name system (DNS) requests to identify recently active hosts.
Listed existing network connections [T1049] on SCCM Server 1, which revealed an active Server Message Block (SMB) connection from SCCM Server 2.
Attempted to move laterally to the SCCM Server 2 via AppDomain hijacking, but the HTTPS beacon failed to call back.
Attempted to move laterally with an SMB beacon [T1021.002], which was successful.

The team also moved from SCCM Server 1 to a Site 1 workstation (Workstation 3) that housed an active server administrator. The team impersonated an administrative service account via a golden ticket attack (from SCCM Server 1); the account had administrative privileges on Workstation 3. The user employed a KeePass password manager that the team was able to use to obtain passwords for other internal websites, a kernel-based virtual machine (KVM) server, virtual private network (VPN) endpoints, firewalls, and another KeePass database with credentials. The server administrator relied on a password manager, which stored credentials in a database file. The red team pulled the decryption key from memory using KeeThief and used it to unlock the database [T1555.005].

At the organization’s request, the red team confirmed that SCCM Server 2 provided access to the organization’s sites because firewall rules allowed SMB traffic to SCCM servers at all other sites.

The team moved laterally from SCCM Server 2 to an SCCM DP server at Site 5 and from the SCCM Server 1 to hosts at two other sites (Sites 4 and 6). The team installed persistent beacons at each of these sites. Site 5 was broken into a private and a public subnet and only DCs were able to cross that boundary. To move between the subnets, the team moved through DCs. Specifically, the team moved from the Site 5 SCCM DP server to a public DC; and then they moved from the public DC to the private DC. The team was then able to move from the private DC to workstations in the private subnet.

The team leveraged access available from SCCM 2 to move around the organization’s network for post-exploitation activities (See Post-Exploitation Activity section).

See Figure 1 for a timeline of the red team’s initial access and lateral movement showing key access points.

*Figure 1: Red Team Cyber Threat Activity: Initial Access and Lateral Movement*

While traversing the network, the team varied their lateral movement techniques to evade detection and because the organization had non-uniform firewalls between the sites and within the sites (within the sites, firewalls were configured by subnet). The team’s primary methods to move between sites were AppDomainManager hijacking and dynamic-link library (DLL) hijacking [T1574.001]. In some instances, they used Windows Management Instrumentation (WMI) Event Subscriptions [T1546.003].

The team impersonated several accounts to evade detection while moving. When possible, the team remotely enumerated the local administrators group on target hosts to find a valid user account. This technique relies on anonymous SMB pipe binds [T1071], which are disabled by default starting with Windows Server 2016. In other cases, the team attempted to determine valid accounts based on group name and purpose. If the team had previously acquired the credentials, they used asktgt to impersonate the account. If the team did not have the credentials, they used the golden ticket attack to forge the account.

Post-Exploitation Activity: Gaining Access to SBSs

With persistent, deep access established across the organization’s networks and subnetworks, the red team began post-exploitation activities and attempted to access SBSs. Trusted agents of the organization tasked the team with gaining access to two specialized servers (SBS 1 and SBS 2). The team achieved root access to three SBS-adjacent workstations but was unable to move laterally to the SBS servers:

Phase I ended before the team could implement a plan to move to SBS 1.
An MFA prompt blocked the team from moving to SBS 2, and Phase I ended before they could implement potential workarounds.

However, the team assesses that by using Secure Shell (SSH) session socket files (see below), they could have accessed any hosts available to the users whose workstations were compromised.

Plan for Potential Access to SBS 1

Conducting open-source research [1591.001], the team identified that SBS 1 and 2 assets and associated management/upkeep staff were located at Sites 5 and 6, respectively. Adding previously collected AD data to this discovery, the team was able to identify a specific SBS 1 admin account. The team planned to use the organization’s mobile device management (MDM) software to move laterally to the SBS 1 administrator’s workstation and, from there, pivot to SBS 1 assets.

The team identified the organization’s MDM vendor using open-source and AD information [T1590.006] and moved laterally to an MDM distribution point server at Site 5 (MDM DP 1). This server contained backups of the MDM MySQL database on its D: drive in the Backup directory. The backups included the encryption key needed to decrypt any encrypted values, such as SSH passwords [T1552]. The database backup identified both the user of the SBS 1 administrator account (USER 2) and the user’s workstation (Workstation 4), which the MDM software remotely administered.

The team moved laterally to an MDM server (MDM 1) at Site 3, searched files on the server, and found plaintext credentials [T1552.001] to an application programming interface (API) user account stored in PowerShell scripts. The team attempted to leverage these credentials to browse to the web login page of the MDM vendor but were unable to do so because the website directed to an organization-controlled single-sign on (SSO) authentication page.

The team gained root access to workstations connected to MDM 1—specifically, the team accessed Workstation 4—by:

Selecting an MDM user from the plaintext credentials in PowerShell scripts on MDM 1.
While in the MDM MySQL database,
- Elevating the selected MDM user’s account privileges to administrator privileges, and
- Modifying the user’s account by adding Create Policy and Delete Policy permissions [T1098], [T1548].
Creating a policy via the MDM API [T1106], which instructed Workstation 4 to download and execute a payload to give the team interactive access as root to the workstation.
Verifying their interactive access.
Resetting permissions back to their original state by removing the policy via the MDM API and removing Create Policy and Delete Policy and administrator permissions and from the MDM user’s account.

While interacting with Workstation 4, the team found an open SSH socket file and a corresponding netstat connection to a host that the team identified as a bastion host from architecture documentation found on Workstation 4. The team planned to move from Workstation 4 to the bastion host to SBS 1. Note: A SSH socket file allows a user to open multiple SSH sessions through a single, already authenticated SSH connection without additional authentication.

The team could not take advantage of the open SSH socket. Instead, they searched through SBS 1 architecture diagrams and documentation on Workstation 4. They found a security operations (SecOps) network diagram detailing the network boundaries between Site 5 SecOps on-premises systems, Site 5 non-SecOps on-premises systems, and Site 5 SecOps cloud infrastructure. The documentation listed the SecOps cloud infrastructure IP ranges [T1580]. These “trusted” IP addresses were a public /16 subnet; the team was able to request a public IP in that range from the same cloud provider, and Workstation 4 made successful outbound SSH connections to this cloud infrastructure. The team intended to use that connection to reverse tunnel traffic back to the workstation and then access the bastion host via the open SSH socket file. However, Phase 1 ended before they were able to implement this plan.

Attempts to Access SBS 2

Conducting open-source research, the team identified an organizational branch [T1591] that likely had access to SBS 2. The team queried the AD to identify the branch’s users and administrators. The team gathered a list of potential accounts, from which they identified administrators, such as SYSTEMS ADMIN or DATA SYSTEMS ADMINISTRATOR, with technical roles. Using their access to the MDM MySQL database, the team queried potential targets to (1) determine the target’s last contact time with the MDM and (2) ensure any policy targeting the target’s workstation would run relatively quickly [T1596.005]. Using the same methodology as described by the steps in the Plan for Potential Access to SBS 1 section above, the team gained interactive root access to two Site 6 SBS 2-connected workstations: a software engineering workstation (Workstation 5) and a user administrator workstation (Workstation 6).

The Workstation 5 user had bash history files with what appeared to be SSH passwords mistyped into the bash prompt and saved in bash history [T1552.003]. The team then attempted to authenticate to SBS 2 using a similar tunnel setup as described in the Access to SBS 1 section above and the potential credentials from the user’s bash history file. However, this attempt was unsuccessful for unknown reasons.

On Workstation 6, the team found a .txt file containing plaintext credentials for the user. Using the pattern discovered in these credentials, the team was able to crack the user’s workstation account password [T1110.002]. The team also discovered potential passwords and SSH connection commands in the user’s bash history. Using a similar tunnel setup described above, the team attempted to log into SBS 2. However, a prompt for an MFA passcode blocked this attempt.

See figure 2 for a timeline of the team’s post exploitation activity that includes key points of access.

*Figure 2: Red Team Cyber Threat Activity: Post Exploitation*

Command and Control

The team used third-party owned and operated infrastructure and services [T1583] throughout their assessment, including in certain cases for command and control (C2) [TA0011]. These included:

Cobalt Strike and Merlin payloads for C2 throughout the assessment. Note: Merlin is a post-exploit tool that leverages HTTP protocols for C2 traffic.
- The team maintained multiple Cobalt Strike servers hosted by a cloud vendor. 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 Cobalt Strike servers [T1090.002]. Redirecting servers make it difficult for defenders to attribute assessment activities to the backend team servers. The redirectors used HTTPS reverse proxies to redirect C2 traffic between the target organization’s network and the Cobalt Strike team servers [T1071.002]. The team encrypted all data in transit [T1573] using encryption keys stored on team’s Cobalt Strike servers.
A cloud service to rapidly change the IP address of the team’s redirecting servers in the event of detection and eradication.
Content delivery network (CDN) services to further obfuscate some of the team’s C2 traffic.
- This technique leverages CDNs associated with high-reputation domains so that the malicious traffic appears to be directed towards a reputation domain but is actually redirected to the red team-controlled Cobalt Strike servers.
- The team used domain fronting [T1090.004] to disguise outbound traffic in order to diversify the domains with which the persistent beacons were communicating. This technique, which also leverages CDNs, allows the beacon to appear to connect to third-party domains, such as nytimes.com, when it is actually connecting to the team’s redirect server.

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. See Table 1 for a description of the events, the expected network defender activity, and the organization’s actual response.

Measurable Event	Description	MITRE ATT&CK Technique(s)	Expected Detection Points	Expected Network Defender Reactions	Reported Reactions
Internal Port Scan	Launch scan from inside the network from a previously gained workstation to enumerate ports on target workstation, server, and domain controller system(s).	Network Service Discovery [T1046]	Network Monitoring and Analysis ToolsIntrusion Detection or Prevention SystemsEndpoint Protection Platform	Detect target hosts and portsIdentify associated scanning processAnalyze scanning host once detectedDevelop response plan	None
Comprehensive Active Directory and Host Enumeration	Perform AD enumeration by querying all domain objects from the DC; and enumerating trust relationships within the AD Forest, user accounts, and current session information from every domain computer (Workstation and Server).	Domain Trust Discovery [T1482]Account Discovery: Domain Account [T1087.002]System Owner/User Discovery [T1033]Remote System Discovery [T1018]	Network Monitoring and Analysis ToolsIntrusion Detection or Prevention SystemsEndpoint Protection Platform	Detect target hosts and portsIdentify associated scanning processAnalyze scanning host once detectedDevelop response plan	Collection process stopped before completion. Host isolated and sent for forensics.
Data Exfiltration—1 GB of Data	Send a large amount (1 GB) of mock sensitive information to an external system over various protocols, including ICMP, DNS, FTP, and/or HTTP/S.	Exfiltration Over Alternative Protocol [T1048]	Network Monitoring and Analysis ToolsIntrusion Detection or Prevention SystemsEndpoint Protection Platform	Detect target hosts and portsIdentify associated scanning processAnalyze scanning host once detectedDevelop response plan	None
Malicious Traffic Generation—Workstation to External Host	Establish a session that originates from a target Workstation system directly to an external host over a clear text protocol, such as HTTP.	Application Layer Protocol [T1071]	Intrusion Detection or Prevention SystemsEndpoint Protection PlatformWindows Event Logs	Detect and Identify source IP and source process of enumerationAnalyze scanning host once detectedDevelop response plan	None
Active Directory Account Lockout	Lock out several administrative AD accounts	Account Access Removal [T1531]	Windows Event LogsEnd User Reporting	Detect and Identify source IP and source process of exfiltrationAnalyze host used for exfiltration once detectedDevelop response plan	None
Local Admin User Account Creation (workstation)	Create a local administrator account on a target workstation system.	Create Account: Local Account [T1136.001]Account Manipulation [T1098]	Intrusion Detection or Prevention SystemsEndpoint Protection PlatformWeb Proxy Logs	Detect and identify source IP and source process of malicious trafficInvestigate destination IP addressTriage compromised hostDevelop response plan	None
Local Admin User Account Creation (server)	Create a local administrator account on a target server system.	Create Account: Local Account [T1136.001]Account Manipulation [T1098]	Windows Event Logs	Detect account creationIdentify source of changeVerify change with system ownerDevelop response plan	None
Active Directory Account Creation	Create AD accounts and add it to domain admins group	Create Account: Domain Account [T1136.002]Account Manipulation [T1098]	Windows Event Logs	Detect account creationIdentify source of changeVerify change with system ownerDevelop response plan	None
Workstation Admin Lateral Movement—Workstation to Workstation	Use a previously compromised workstation admin account to upload and execute a payload via SMB and Windows Service Creation, respectively, on several target Workstations.	Valid Accounts: Domain Accounts [T1078.002]Remote Services: SMB/Windows Admin Shares, Sub-technique [T1021.002]Create or Modify System Process: Windows Service [T1543.003]	Windows Event Logs	Detect account compromiseAnalyze compromised hostDevelop response plan	None
Domain Admin Lateral Movement—Workstation to Domain Controller	Use a previously compromised domain admin account to upload and execute a payload via SMB and Windows Service Creation, respectively, on a target DC.	Valid Accounts: Domain Accounts [T1078.002]Remote Services: SMB/Windows Admin Shares, Sub-technique [T1021.002]Create or Modify System Process: Windows Service [T1543.003]	Windows Event Logs	Detect account compromiseTriage compromised hostDevelop response plan	None
Malicious Traffic Generation—Domain Controller to External Host	Establish a session that originates from a target Domain Controller system directly to an external host over a clear text protocol, such as HTTP.	Application Layer Protocol [T1071]	Intrusion Detection or Prevention SystemsEndpoint Protection PlatformWeb Proxy Logs	Detect and identify source IP and source process of malicious trafficInvestigate destination IP addressTriage compromised hostDevelop response plan	None
Trigger Host-Based Protection—Domain Controller	Upload and execute a well-known (e.g., with a signature) malicious file to a target DC system to generate host-based alerts.	Ingress Tool Transfer [T1105]	Endpoint Protection PlatformEndpoint Detection and Response	Detect and identify source IP and source process of malicious trafficInvestigate destination IP addressTriage compromised hostDevelop response plan	Malicious file was removed by antivirus
Ransomware Simulation	Execute simulated ransomware on multiple Workstation systems to simulate a ransomware attack.Note: This technique does NOT encrypt files on the target system.	N/A	End User Reporting	Investigate end user reported eventTriage compromised hostDevelop response Plan	Four users reported event to defensive staff

Findings

Key Issues

The red team noted the following key issues relevant to the security of the organization’s network. These findings contributed to the team’s ability to gain persistent, undetected access across the organization’s sites. See the Mitigations section for recommendations on how to mitigate these issues.

Insufficient host and network monitoring. Most of the red team’s Phase II actions failed to provoke a response from the people, processes, and technology defending the organization’s network. The organization failed to detect lateral movement, persistence, and C2 activity via their intrusion detection or prevention systems, endpoint protection platform, web proxy logs, and Windows event logs. Additionally, throughout Phase I, the team received no deconflictions or confirmation that the organization caught their activity. Below is a list of some of the higher risk activities conducted by the team that were opportunities for detection:
- Phishing
- Lateral movement reuse
- Generation and use of the golden ticket
- Anomalous LDAP traffic
- Anomalous internal share 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
Lack of monitoring on endpoint management systems. The team used the organization’s MDM system to gain root access to machines across the organization’s network without being detected. Endpoint management systems provide elevated access to thousands of hosts and should be treated as high value assets (HVAs) with additional restrictions and monitoring.
KRBTGT never changed. The Site 1 krbtgt account password had not been updated for over a decade. The krbtgt account is a domain default account that acts as a service account for the key distribution center (KDC) service used to encrypt and sign all Kerberos tickets for the domain. Compromise of the krbtgt account could provide adversaries with the ability to sign their own TGTs, facilitating domain access years after the date of compromise. The red team was able to use the krbtgt account to forge TGTs for multiple accounts throughout Phase I.
Excessive permissions to standard users. The team discovered several standard user accounts that have local administrator access to critical servers. This misconfiguration allowed the team to use the low-level access of a phished user to move laterally to an Unconstrained Delegation host and compromise the entire domain.
Hosts with Unconstrained Delegation enabled unnecessarily. Hosts with Unconstrained Delegation enabled store the Kerberos TGTs of all users that authenticate to that host, enabling actors to steal service tickets or compromise krbtgt accounts and perform golden ticket or “silver ticket” attacks. The team performed an NTLM-relay attack to obtain the DC’s TGT, followed by a golden ticket attack on a SharePoint server with Unconstrained Delegation to gain the ability to impersonate any Site 1 AD account.
Use of non-secure default configurations. The organization used default configurations for hosts with Windows Server 2012 R2. The default configuration allows unprivileged users to query group membership of local administrator groups. The red team used and identified several standard user accounts with administrative access from a Windows Server 2012 R2 SharePoint server.

Additional Issues

The team noted the following additional issues.

Ineffective separation of privileged accounts. Some workstations allowed unprivileged accounts to have local administrator access; for example, the red team discovered an ordinary user account in the local admin group for the SharePoint server. If a user with administrative access is compromised, an actor can access servers without needing to elevate privileges. Administrative and user accounts should be separated, and designated admin accounts should be exclusively used for admin purposes.
Lack of server egress control. Most servers, including domain controllers, allowed unrestricted egress traffic to the internet.
Inconsistent host configuration. The team observed inconsistencies on servers and workstations within the domain, including inconsistent membership in the local administrator group among different servers or workstations. For example, some workstations had “Server Admins” or “Domain Admins” as local administrators, and other workstations had neither.
Potentially unwanted programs. The team noticed potentially unusual software, including music software, installed on both workstations and servers. These extraneous software installations indicate inconsistent host configuration (see above) and increase the attack surfaces for malicious actors to gain initial access or escalate privileges once in the network.
Mandatory password changes enabled. During the assessment, the team keylogged a user during a mandatory password change and noticed that only the final character of their password was modified. This is potentially due to domain passwords being required to be changed every 60 days.
Smart card use was inconsistent across the domain. While the technology was deployed, it was not applied uniformly, and there was a significant portion of users without smartcard protections enabled. The team used these unprotected accounts throughout their assessment to move laterally through the domain and gain persistence.

Noted Strengths

The red team noted the following technical controls or defensive measures that prevented or hampered offensive actions:

The organization conducts regular, proactive penetration tests and adversarial assessments and invests in hardening their network based on findings.
- The team was unable to discover any easily exploitable services, ports, or web interfaces from more than three million external in-scope IPs. This forced the team to resort to phishing to gain initial access to the environment.
- Service account passwords were strong. The team was unable to crack any of the hashes obtained from the 610 service accounts pulled. This is a critical strength because it slowed the team from moving around the network in the initial parts of the Phase I.
- The team did not discover any useful credentials on open file shares or file servers. This slowed the progress of the team from moving around the network.
MFA was used for some SBSs. The team was blocked from moving to SBS 2 by an MFA prompt.
There were strong security controls and segmentation for SBS systems. Direct access to SBS were located in separate networks, and admins of SBS used workstations protected by local firewalls.

MITIGATIONS

CISA recommends organizations implement the recommendations in Table 2 to mitigate the issues listed in the 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.

Issue	Recommendation
Insufficient host and network monitoring	Establish a security baseline of normal network traffic and tune network appliances to detect anomalous behavior [CPG 3.1]. Tune host-based products to detect anomalous binaries, lateral movement, and persistence techniques.Create alerts for Windows event log authentication codes, especially for the domain controllers. This could help detect some of the pass-the-ticket, DCSync, and other techniques described in this report.From a detection standpoint, focus on identity and access management (IAM) rather than just network traffic or static host alerts.Consider who is accessing what (what resource), from where (what internal host or external location), and when (what day and time the access occurs).Look for access behavior that deviates from expected or is indicative of AD abuse.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. CISA recommends selecting one tool to administer the network, ensuring logging is turned on [CPG 3.1], and disabling the others.Consider using “honeypot” service principal names (SPNs) to detect attempts to crack account hashes [CPG 1.1].Conduct regular assessments to ensure processes and procedures are up to date and can be followed by security staff and end users.Consider using red team tools, such as SharpHound, for AD enumeration to identify users with excessive privileges and misconfigured hosts (e.g., with `Unconstrained Delegation` enabled).Ensure all commercial tools deployed in your environment are regularly tuned to pick up on relevant activity in your environment.
Lack of monitoring on endpoint management systems	Treat endpoint management systems as HVAs with additional restrictions and monitoring because they provide elevated access to thousands of hosts.
KRBTGT never changed	Change the `krbtgt` account password on a regular schedule such as every 6 to 12 months or if it becomes compromised. Note that this password change must be carefully performed to effectively change the credential without breaking AD functionality. The password must be changed twice to effectively invalidate the old credentials. However, the required waiting period between resets must be greater than the maximum lifetime period of Kerberos tickets, which is 10 hours by default. See Microsoft’s KRBTGT account maintenance considerations guidance for more information.
Excessive permissions to standard users and ineffective separation of privileged accounts	Implement the principle of least privilege:Grant standard user rights for standard user tasks such as email, web browsing, and using line-of-business (LOB) applications.Periodically audit standard accounts and minimize where they have privileged access.Periodically Audit AD permissions to ensure users do not have excessive permissions and have not been added to admin groups.Evaluate which administrative groups should administer which servers/workstations. Ensure group members administrative accounts instead of standard accounts.Separate administrator accounts from user accounts [CPG 1.5]. Only allow designated admin accounts to be used for admin purposes. If an individual user needs administrative rights over their workstation, use a separate account that does not have administrative access to other hosts, such as servers.Consider using a privileged access management (PAM) solution to manage access to privileged accounts and resources [CPG 3.4]. PAM solutions can also log and alert usage to detect any unusual activity and may have helped stop the red team from accessing resources with admin accounts. Note: password vaults associated with PAM solutions should be treated as HVAs with additional restrictions and monitoring (see below).Configure time-based access for accounts set at the admin level and higher. For example, the just-in-time (JIT) access method provisions privileged access when needed and can support enforcement of the principle of least privilege, as well as the Zero Trust model. This is a process in which a network-wide policy is set in place to automatically disable administrator accounts at the AD level when the account is not in direct need. When individual users need the account, they submit their requests through an automated process that enables access to a system but only for a set timeframe to support task completion.
Hosts with `Unconstrained Delegation` enabled	Remove `Unconstrained Delegation` from 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. CISA recommends Windows Server 2019 or greater.Consider disabling or limiting NTLM and WDigest Authentication if possible, including using their use as criteria for prioritizing updates to legacy systems or for segmenting the network. Instead use more modern federation protocols (SAML, OIDC) or Kerberos for authentication with AES-256 bit encryption [CPG 3.4].If NTLM must be enabled, enable Extended Protection for Authentication (EPA) to prevent some NTLM-relay attacks, and implement SMB signing to prevent certain adversary-in-the-middle and pass-the-hash attacks CPG 3.4]. See Microsoft Mitigating NTLM Relay Attacks on Active Directory Certificate Services (AD CS) and Microsoft Overview of Server Message Block signing for more information.
Use of non-secure default configurations	Keep systems and software up to date [CPG 5.1]. If updates cannot be uniformly installed, update insecure configurations to meet updated standards.
Lack of server egress control	Configure internal firewalls and proxies to restrict internet traffic from hosts that do not require it. If a host requires specific outbound traffic, consider creating an allowlist policy of domains.
Large number of credentials in a shared vault	Treat password vaults as HVAs with additional restrictions and monitoring [CPG 3.4]:If on-premise, require MFA for admin and apply network segmentation [CPG 1.3]. Use solutions with end-to-end encryption where applicable [CPG 3.3].If cloud-based, evaluate the provider to ensure use of strong security controls such as MFA and end-to-end encryption [CPG 1.3, 3.3].
Inconsistent host configuration	Establish a baseline/gold-image for workstations and servers and deploy from that image [CPG 2.5]. Use standardized groups to administer hosts in the network.
Potentially unwanted programs	Implement software allowlisting to ensure users can only install software from an approved list [CPG 2.1].Remove unnecessary, extraneous software from servers and workstations.
Mandatory password changes enabled	Consider only requiring changes for memorized passwords in the event of compromise. Regular changing of memorized passwords can lead to predictable patterns, and both CISA and the National Institute of Standards and Technology (NIST) recommend against changing passwords on regular intervals.

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 [CPG 4.3]. Phishing accounts for majority of initial access intrusion events.
Enforce phishing-resistant MFA to the greatest extent possible [CPG 1.3].
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.
- Implement Credential Guard for Windows 10 and Server 2016 (Refer to Microsoft: Manage Windows Defender Credential Guard for more information). For Windows Server 2012R2, enable Protected Process Light for Local Security Authority (LSA).
- Refrain from storing plaintext credentials in scripts [CPG 3.4]. The red team discovered a PowerShell script containing plaintext credentials that allowed them to escalate to admin.
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 Trust network architecture that:

Leverages secure cloud services for key enterprise security capabilities (e.g., identity and access management, endpoint detection and response, 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.

CISA encourages organizational IT leadership to ask their executive leadership the question: Can the organization accept the business risk of NOT implementing critical security controls such as MFA? Risks of that nature should typically be acknowledged and prioritized at the most senior levels of an organization.

VALIDATE SECURITY CONTROLS

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).
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

See CISA’s RedEye tool on CISA’s GitHub page. RedEye is an interactive open-source analytic tool used to visualize and report red team command and control activities. See CISA’s RedEye tool overview video for more information.

REFERENCES
[1] Bleeping Computer: New DFSCoerce NTLM Relay attack allows Windows domain takeover

APPENDIX: MITRE ATT&CK TACTICS AND TECHNIQUES

See Table 3 for all referenced red team tactics and techniques in this advisory. Note: activity was from Phase I unless noted.

	Reconnaissance
Technique Title	ID	Use
Gather Victim Identity Information: Email Addresses	T1589.002	The team found employee email addresses via open-source research.
Gather Victim Identify Information: Employee Names	T1589.003	The team identified employee names via open-source research that could be used to derive email addresses.
Gather Victim Network Information: Network Security Appliances	T1590.006	The team identified the organization’s MDM vendor and leveraged that information to move laterally to SBS-connected assets.
Gather Victim Org Information	T1591	The team conducted open-source research and identified an organizational branch that likely had access to an SBS asset.
Gather Victim Org Information: Determine Physical Locations	T1591.001	The team conducted open-source research to identify the physical locations of upkeep/management staff of selected assets.
Search Open Technical Databases: Scan Databases	T1596.005	The team queried an MDM SQL database to identify target administrators who recently connected with the MDM.
	Resource Development
Technique Title	ID	Use
Acquire Infrastructure	T1583	The team used third-party owned and operated infrastructure throughout their assessment for C2.
Establish Accounts: Email Accounts	T1585.002	The team used commercially available email platforms for their spearphishing activity.
Obtain Capabilities: Tool	T1588.002	The team used the following tools:Cobalt Strike and Merlin payloads for C2.KeeThief to obtain a decryption key from a KeePass databaseRubeus and DFSCoerce in an NTLM relay attack
	Initial Access
Technique Title	ID	Use
Phishing: Spearphishing Link	T1566.002	The team sent spearphishing emails with links to a red-team-controlled domain to gain access to the organization’s systems.
	Execution
Technique Title	ID	Use
Native API	T1106	The team created a policy via the MDM API, which downloaded and executed a payload on a workstation.
User Execution	T1204	Users downloaded and executed the team’s initial access payloads after clicking buttons to trigger download and execution.
	Persistence
Technique Title	ID	Use
Account Manipulation	T1098	The team elevated account privileges to administrator and modified the user’s account by adding Create Policy and Delete Policy permissions.During Phase II, the team created local admin accounts and an AD account; they added the created AD account to a domain admins group.
Create Account: Local Account	T1136.001	During Phase II, the team created a local administrator account on a workstation and a server.
Create Account: Domain Account	T1136.002	During Phase II, the team created an AD account.
Create or Modify System Process: Windows Service	T1543.003	During Phase II, the team leveraged compromised workstation and domain admin accounts to execute a payload via Windows Service Creation on target workstations and the DC.
Event Triggered Execution: Windows Management Instrumentation Event Subscription	T1546.003	The team used WMI Event Subscriptions to move laterally between sites.
Hijack Execution Flow: DLL Search Order Hijacking	T1574.001	The team used DLL hijacking to move laterally between sites.
	Privilege Escalation
Technique Title	ID	Use
Abuse Elevation Control Mechanism	T1548	The team elevated user account privileges to administrator by modifying the user’s account via adding Create Policy and Delete Policy permissions.
	Defense Evasion
Technique Title	ID	Use
Valid Accounts: Domain Accounts	T1078.002	During Phase II, the team compromised a domain admin account and used it to laterally to multiple workstations and the DC.
	Credential Access
Technique Title	ID	Use
OS Credential Dumping: LSASS Memory	T1003.001	The team obtained the cached credentials from a SharePoint server account by taking a snapshot of lsass.exe with a tool called nanodump, exporting the output and processing the output offline with Mimikatz.
OS Credential Dumping: DCSync	T1003.006	The team harvested AES-256 hashes via DCSync.
Brute Force: Password Cracking	T1110.002	The team cracked a user’s workstation account password after learning the user’s patterns from plaintext credentials.
Unsecured Credentials	T1552	The team found backups of a MySQL database that contained the encryption key needed to decrypt SSH passwords.
Unsecured Credentials: Credentials in Files	T1552.001	The team found plaintext credentials to an API user account stored in PowerShell scripts on an MDM server.
Unsecured Credentials: Bash History	T1552.003	The team found bash history files on a Workstation 5, and the files appeared to be SSH passwords saved in bash history.
Credentials from Password Stores: Password Managers	T1555.005	The team pulled credentials from a KeePass database.
Adversary-in-the-middle: LLMNR/NBT-NS Poisoning and SMB Relay	T1557.001	The team ran the DFSCoerce python script, which prompted DC authentication to a server using the server’s NTLM hash. The team then deployed Rubeus to capture the incoming DC TGT.
Steal or Forge Kerberos Tickets: Golden Ticket	T1558.001	The team used the acquired krbtgt account hash throughout their assessment to forge legitimate TGTs.
Steal or Forge Kerberos Tickets: Kerberoasting	T1558.003	The team leveraged Rubeus and DFSCoerce in a NTLM relay attack to obtain the DC’s TGT from a host with Unconstrained Delegation enabled.
	Discovery
Technique Title	ID	Use
System Network Configuration Discovery	T1016	The team queried the AD for information about the network’s sites and subnets.
Remote System Discovery	T1018	The team queried the AD, during phase I and II, for information about computers on the network.
System Network Connections Discovery	T1049	The team listed existing network connections on SCCM Server 1 to reveal an active SMB connection with server 2.
Permission Groups Discovery: Domain Groups	T1069.002	The team leveraged ldapsearch and dsquery to query and scrape active directory information.
Account Discovery: Domain Account	T1087.002	The team queried AD for AD users (during Phase I and II), including for members of a SharePoint admin group and several standard user accounts with administrative access.
Cloud Infrastructure Discovery	T1580	The team found SecOps network diagrams on a host detailing cloud infrastructure boundaries.
Domain Trust Discovery	T1482	During Phase II, the team enumerated trust relationships within the AD Forest.
Group Policy Discovery	T1615	The team scraped AD information, including GPOs.
Network Service Discovery	T1046	During Phase II, the team enumerated ports on target systems from a previously compromised workstation.
System Owner/User Discovery	T1033	During Phase II, the team enumerated the AD for current session information from every domain computer (Workstation and Server).
	Lateral Movement
Technique Title	ID	Use
Remote Services: SMB/Windows Admin Shares	T1021.002	The team moved laterally with an SMB beacon.During Phase II, they used compromised workstation and domain admin accounts to upload a payload via SMB on several target Workstations and the DC.
Use Alternate Authentication Material: Pass the Hash	T1550.002	The team ran the DFSCoerce python script, which prompted DC authentication to a server using the server’s NTLM hash. The team then deployed Rubeus to capture the incoming DC TGT.
Pass the Ticket	T1550.003	The team used the asktgt command to impersonate accounts for which they had credentials by requesting account TGTs.
	Command and Control
Technique Title	ID	Use
Application Layer Protocol	T1071	The team remotely enumerated the local administrators group on target hosts to find valid user accounts. This technique relies on anonymous SMB pipe binds, which are disabled by default starting with Server 2016.During Phase II, the team established sessions that originated from a target Workstation and from the DC directly to an external host over a clear text protocol.
Application Layer Protocol: Web Protocols	T1071.001	The team’s C2 redirectors used HTTPS reverse proxies to redirect C2 traffic.
Application Layer Protocol: File Transfer Protocols	T1071.002	The team used HTTPS reverse proxies to redirect C2 traffic between target network and the team’s Cobalt Strike servers.
Encrypted Channel	T1573	The team’s C2 traffic was encrypted in transit using encryption keys stored on their C2 servers.
Ingress Tool Transfer	T1105	During Phase II, the team uploaded and executed well-known malicious files to the DC to generate host-based alerts.
Proxy: External Proxy	T1090.002	The team used redirectors to redirect C2 traffic between the target organization’s network and the team’s C2 servers.
Proxy: Domain Fronting	T1090.004	The team used domain fronting to disguise outbound traffic in order to diversify the domains with which the persistent beacons were communicating.
	Impact
Technique Title	ID	Use
Account Access Removal	T1531	During Phase II, the team locked out several administrative AD accounts.

Please share your thoughts. We recently updated our anonymous Product Feedback Survey and we’d welcome your feedback.

Source :
https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-059a

Certified Pre-Owned

Will Schroeder
Researcher @SpecterOps . Coding towards chaotic good while living on the decision boundary.

Published in Posts By SpecterOps Team Members
22 min read
Jun 17, 2021

TL;DR Active Directory Certificate Services has a lot of attack potential! Check out our whitepaper “Certified Pre-Owned: Abusing Active Directory Certificate Services” for complete details. We’re also presenting this material at Black Hat USA 2021.

[EDIT 06/22/21] — We’ve updated some of the details for ESC1 and ESC2 in this post which will be shortly updated in the whitepaper.

For the past several months, we (Will Schroeder and Lee Christensen) have been diving into the security of Active Directory Certificate Services (AD CS). While several aspects of Active Directory have received thorough attention from a security perspective, Active Directory Certificate Services has been relatively overlooked. AD CS is Microsoft’s PKI implementation that provides everything from encrypting file systems, to digital signatures, to user authentication (a large focus of our research), and more. While AD CS is not installed by default for Active Directory environments, from our experience in enterprise environments it is widely deployed, and the security ramifications of misconfigured certificate service instances are enormous.

Today we’re releasing the results of our research so far (there is still much to look at, and we know we have missed things) in the form of an extensive whitepaper and a defensive PowerShell toolkit for auditing these issues. The toolkit is heavily defensive focused, but we will also release two offensive tools in ~45 days at Black Hat, as we believe that the issues described in the paper are severe and widespread enough to warrant a delay in the offensive tool release. The whitepaper also contains substantial preventative and detective guidance.

Whitepaper — “Certified Pre-Owned: Abusing Active Directory Certificate Services”
Defensive Toolkit — PSPKIAudit (based on PSPKI)
Offensive Toolkit — (code will be pushed at Black Hat, preemptive IOCs/Yara rules are currently live) Certify and ForgeCert

AD CS and its security implications are complicated, and we highly recommend reading the whitepaper for complete context. This post is a brief summary of the paper, and we will release a number of additional posts in the coming weeks and months to highlight elements of the research.

So why care about this? Certificate abuse can grant an attacker:

Of note, nearly every environment with AD CS that we’ve examined for domain escalation misconfigurations has been vulnerable. It’s hard for us to overstate what a big deal these issues are.

Sidenote: because of the number of attacks we ended up documenting in this research, we have tagged each attack with an ID (e.g., ESC2) as well as each defense (e.g., DETECT3). This is for ease of mapping of attacks to appropriate defenses in the whitepaper.

Active Directory Certificate Services Crash Course

Common Terms and Acronyms

There are a lot of terms and acronyms we’re going to be using throughout this post (and paper), so here’s a quick breakdown of a few for reference:

PKI (Public Key Infrastructure) — a system to manage certificates/public key encryption
AD CS (Active Directory Certificate Services) — Microsoft’s PKI implementation
CA (Certificate Authority) — PKI server that issues certificates
Enterprise CA — CA integrated with AD (as opposed to a standalone CA), offers certificate templates
Certificate Template — a collection of settings and policies that defines the contents of a certificate issued by an enterprise CA
CSR (Certificate Signing Request) — a message sent to a CA to request a signed certificate
EKU (Extended/Enhanced Key Usage) — one or more object identifiers (OIDs) that define how a certificate can be used

Overview

AD CS is a server role that functions as Microsoft’s public key infrastructure PKI implementation. As expected, it integrates tightly with Active Directory and enables the issuing of certificates, which are X.509-formatted digitally signed electronic documents that can be used for encryption, message signing, and/or authentication (our research focus).

The information included in a certificate binds an identity (the subject) to a public/private key pair. An application can then use the key pair in operations as proof of the identity of the user. Certificate Authorities (CAs) are responsible for issuing certificates.

At a high level, clients generate a public-private key pair, and the public key is placed in a certificate signing request (CSR) message along with other details such as the subject of the certificate and the certificate template name. Clients then send the CSR to the Enterprise CA server. The CA server then checks if the client is allowed to request certificates. If so, it determines if it will issue a certificate by looking up the certificate template AD object (more on these shortly) specified in the CSR. The CA will check if the certificate template AD object’s permissions allow the authenticating account to obtain a certificate. If so, the CA generates a certificate using the “blueprint” settings defined by the certificate template (e.g., EKUs, cryptography settings, issuance requirements, etc.) and using the other information supplied in the CSR if allowed by the certificate’s template settings. The CA signs the certificate using its private key and then returns it to the client.

That’s a lot of text. So here’s a graphic:

Certificate Templates

AD CS Enterprise CAs issue certificates with settings defined by AD objects known as certificate templates. These templates are collections of enrollment policies and predefined certificate settings and contain things like “How long is this certificate valid for?”, “What is the certificate used for?”, “How is the subject specified?”, “Who is allowed to request a certificate?”, and a myriad of other settings:

The pKIExtendedKeyUsage attribute on an AD certificate template object contains an array of object identifiers (OIDs) enabled for the template. These EKU object identifiers affect what the certificate can be used for (PKI Solutions has a breakdown of the EKU OIDs available from Microsoft). Our research focused on EKUs that, when present in a certificate, permit authentication to Active Directory. We originally thought that only the “Client Authentication“ OID (1.3.6.1.5.5.7.3.2) enabled this; however, our research also found that the following OID scenarios can enable certificate-based authentication:

*The 1.3.6.1.5.2.3.4 OID is not present in AD CS deployments by default and needs to be added manually, but it does work for client authentication.

Templates also have a number of other interesting settings which we explore in depth in the whitepaper. The paper also covers template “Issuance Requirements” which can function as preventative controls, which we will briefly touch on in this post.

Subject Alternative Names

A Subject Alternative Name (SAN) is an extension that allows additional identities to be bound to a certificate beyond just the subject of the certificate. For example, if a web server hosts content for multiple domains, each applicable domain could be included in the SAN so that the web server only needs a single HTTPS certificate instead of one for each domain.

This is all well and good for HTTPS certificates, but when combined with certificates that allow domain authentication, a dangerous scenario can arise. By default during certificate-based authentication, certificates are mapped to Active Directory accounts based on a user principal name (UPN) specified in the SAN. So, if an attacker can specify an arbitrary SAN when requesting a certificate that enables domain authentication, and the CA creates and signs a certificate using the attacker-supplied SAN, the attacker can become any user in the domain! Domain escalation scenarios can result from various AD CS template misconfigurations that allow unprivileged users to supply an arbitrary SAN in a certificate enrollment. We’ll cover these situations in the Domain Escalation section.

Active Directory Authentication with Certificates

Last year, @_ethicalchaos_ made a PR to Rubeus to implement PKINIT abuse, and covers more details on this in depth in their post on attacking smart card based Active Directory networks. This was a missing link for us offensively, and means that we can now use Rubeus to request a Kerberos ticket granting ticket (TGT) using a certificate enabled for domain authentication:

That’s right, we don’t need a physical smart card or the Windows Credential Store to perform this certificate-based Kerberos authentication! Benjamin Delpy’s (@gentilkiwi) Kekeo has supported this for years, but the Rubeus implementation made it more readily usable for our operations.

During our research, we also found that some protocols use Schannel — the security package backing SSL/TLS — to authenticate domain users. LDAPS is a commonly enabled use case. For example, the following screenshot shows the PowerShell script Get-LdapCurrentUser authenticating to LDAPS using a certificate for authentication and performing an LDAP whoami to see what account authenticated:

Account Persistence

If an Enterprise CA exists, a user (or machine) can request a cert for any template available to them for enrollment. The whitepaper covers theft of existing certificates, but we’re only going to touch on “active” malicious enrollments here. Our goal, in the context of user credential theft, is to request a certificate for a template that allows us to authenticate to Active Directory as that user (or machine). For complete details, see the “Account Persistence” section in the whitepaper.

The Certify.exe find /clientauth command will query LDAP for available templates that we can examine for our desired criteria:

This can also be done via PSPKIAudit with Get-AuditCertificateTemplate | ?{$_.HasAuthenticationEku}

If we have GUI access to a host, we can manually request a certificate through certmgr.msc. Alternatively, Certify (or certreq.exe) can be used be used for these malicious enrollments:

These issued certificates can then be used with Rubeus to authenticate to Active Directory as this user, for as long as the certificate is valid. This is an alternative method of long-term credential theft that doesn’t touch LSASS and can be performed from a non-elevated context!

This also works for machine certificates, which can be combined with S4U2Self to obtain a Kerberos service ticket to any service on the host (e.g., CIFS, HTTP, RPCSS, etc.) as any user. Elad Shamir’s excellent post about Kerberos delegation attacks details this attack scenario.

And since certificates are independent authentication material, these certificates will still be usable even if the user (or computer) resets their password!

Domain Escalation

While there isn’t anything necessarily inherently insecure about AD CS (except for ESC8 as detailed below), it is surprisingly easy to misconfigure its various elements, resulting in ways for unelevated users to escalate in the domain. We’ll briefly cover the main sets of misconfigurations, but again, see the whitepaper for complete details.

Misconfigured Certificate Templates — ESC1

In order to abuse this misconfiguration, the following conditions must be met:

The Enterprise CA grants low-privileged users enrollment rights. The Enterprise CA’s configuration must permit low-privileged users the ability to request certificates. See the “Background — Certificate Enrollment” in the whitepaper paper for more details.
Manager approval is disabled. This setting necessitates that a user with certificate manager permissions review and approve the requested certificate before the certificate is issued. See the “Background — Certificate Enrollment — Issuance Requirements’ section in the whitepaper paper for more details.
No authorized signatures are required. This setting requires any CSR to be signed by an existing authorized certificate. See the “Background — Certificate Enrollment — Issuance Requirements” section in the whitepaper for more details.
An overly permissive certificate template security descriptor grants certificate enrollment rights to low-privileged users. Having certificate enrollment rights allows a low-privileged attacker to request and obtain a certificate based on the template. Enrollment rights are granted via the certificate template AD object’s security descriptor.
The certificate template defines EKUs that enable authentication. Applicable EKUs include Client Authentication (OID 1.3.6.1.5.5.7.3.2), PKINIT Client Authentication (1.3.6.1.5.2.3.4), Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2), Any Purpose (OID 2.5.29.37.0), or no EKU (SubCA).
The certificate template allows requesters to specify a subjectAltName (SAN) in the CSR. If a requester can specify the SAN in a CSR, the requester can request a certificate as anyone (e.g., a domain admin user). The certificate template’s AD object specifies if the requester can specify the SAN in its mspki-certificate-name-flag property. The mspki-certificate-name-flag property is a bitmask and if the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag is present, a requester can specify the SAN. This is surfaced as the “Supply in request” option in the “Subject Name” tab in certtmpl.msc.

Misconfigured Certificate Templates — ESC2

In order to abuse this misconfiguration, the following conditions must be met:

The Enterprise CA grants low-privileged users enrollment rights. Details are the same as in ESC1.
Manager approval is disabled. Details are the same as in ESC1.
No authorized signatures are required. Details are the same as in ESC1.
An overly permissive certificate template security descriptor grants certificate enrollment rights to low-privileged users. Details are the same as in ESC1.
The certificate template defines Any Purpose EKUs or no EKU.

[EDIT 06/22/21]

While templates with these EKUs can’t be used to request authentication certificates as other users without the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag being present (i.e., ESC1), an attacker can use them to authenticate to AD as the user who requested them and these two EKUs are certainly dangerous on their own.

We were initially a bit unclear about the capabilities of the Any Purpose and subordinate CA (SubCA) EKUs, but others reached out and helped us clarify our understanding. An attacker can use a certificate with the Any Purpose EKU for (surprise!) any purpose — client authentication, server authentication, code signing, etc. In contrast, an attacker can use a certificate with no EKUs — a subordinate CA certificate — for any purpose as well but could also use it to sign new certificates. As such, using a subordinate CA certificate, an attacker could specify arbitrary EKUs or fields in the new certificates.

HOWEVER, if the subordinate CA is not trusted by the NTAuthCertificates object (which it won’t be by default), the attacker cannot create new certificates that will work for domain authentication. Still, the attacker can create new certificates with any EKU and arbitrary certificate values, of which there’s plenty the attacker could potentially abuse (e.g., code signing, server authentication, etc.) and might have large implications for other applications in the network like SAML, AD FS, or IPSec.

We feel confident in stating that it’s very bad if an attacker can obtain an Any Purpose or subordinate CA (SubCA) certificate, regardless of whether it’s trusted by NTAuthCertificates or not.

[/EDIT]

Enrollment Agent Templates — ESC3

In order to abuse this misconfiguration, the following conditions must be met:

The Enterprise CA grants low-privileged users enrollment rights. Details are the same as in ESC1.
Manager approval is disabled. Details are the same as in ESC1.
No authorized signatures are required. Details are the same as in ESC1.
An overly permissive certificate template security descriptor grants certificate enrollment rights to low-privileged users. Details are the same as in ESC1.
The certificate template defines the Certificate Request Agent EKU. The Certificate Request Agent OID (1.3.6.1.4.1.311.20.2.1) allows for requesting other certificate templates on behalf of other principals.
Enrollment agent restrictions are not implemented on the CA.

The Certificate Request Agent EKU (OID 1.3.6.1.4.1.311.20.2.1), known as “Enrollment Agent” in Microsoft documentation, allows a principal to enroll for a certificate on behalf of another user. For anyone who enrolls in such a template, the resulting certificate can be used to co-sign requests on behalf of any user, for any Schema Version 1 template or any Schema Version 2+ template that requires the appropriate “Authorized Signatures/Application Policy” Issuance Requirement. This also assumes that there are no limiting Enrollment Agent Restrictions on the CA.

The few sentences before this throwback meme might need a bit of clarification. If an attacker is able to enroll in a template with a “Certificate Request Agent” EKU, they can enroll on behalf of any user for any Version 1 certificate template, or any Version 2+ template configured to explicitly require this co-signing scenario. Schema Version 1 templates don’t implement this type of Issuance Requirement, so all are on the table. Specifically, the User and Machine/Computer templates are prime targets as they contain the Client Authentication EKU and are published by default (though this can be changed), and there are other Version 1 templates that can be vulnerable if published.

If a Version 1 template is duplicated for modification, it automatically becomes Schema Version 2 by default, meaning a “Certificate Request Agent” template will NOT work unless such an issuance requirement is explicitly specified.

A bit confusing? We know. We do our best to break this down in more depth in the whitepaper, but it’s a complex set of interwoven restrictions.

Vulnerable Certificate Template Access Control — ESC4

Certificate templates are securable objects in Active Directory, meaning they have a security descriptor that specifies which Active Directory principals have specific permissions over the template. For more background on Active Directory ACLs, see our (other) whitepaper on the subject.

We say that a template is misconfigured at the access control level if it has Access Control Entries (ACEs) that allow unintended, or otherwise unprivileged, Active Directory principals to edit sensitive security settings in the template. That is, if an attacker is able to chain access to a point that they can actively push a misconfiguration to a template that is not otherwise vulnerable (e.g., by enabling the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT bit in the mspki-certificate-name-flag property for a template that allows for domain authentication), we end up with domain compromise scenarios similar to what we’ve already covered. An example of this we have seen in multiple environments is Domain Computers having FullControl or WriteDacl permissions over a certificate template’s AD object, allowing attackers with access to any AD computer modify the certificate template to a dangerous state. This is a scenario explored in Christoph Falta’s GitHub repo.

Vulnerable PKI Object Access Control — ESC5

We won’t touch on this one as heavily here, but a number of objects outside of certificate templates and the certificate authority itself can have a security impact on the entire AD CS system.

These possibilities include (but are not limited to):

CA server’s AD computer object (i.e., compromise through RBCD)
The CA server’s RPC/DCOM server
Any descendant AD object or container in the container CN=Public Key Services,CN=Services,CN=Configuration,DC=<COMPANY>,DC=<COM> (e.g., the Certificate Templates container, Certification Authorities container, the NTAuthCertificates object, the Enrollment Services container, etc.)

EDITF_ATTRIBUTESUBJECTALTNAME2 — ESC6

Another way to supply arbitrary SANs, described in a CQure Academy post, involves the EDITF_ATTRIBUTESUBJECTALTNAME2 flag. As Microsoft describes, “If this flag is set on the CA, any request (including when the subject is built from Active Directory®) can have user defined values in the subject alternative name.” This means that ANY template configured for domain authentication that also allows unprivileged users to enroll (e.g., the default User template) can be abused to obtain a certificate that allows us to authenticate as a domain admin (or any other active user/machine). As this Keyfactor post describes, this setting “just makes it work”, which is why it’s likely flipped in many environments by sysadmins who don’t fully understand the security implications.

Our normal reaction to seeing this setting in enterprise environments:

Vulnerable Certificate Authority Access Control — ESC7

Outside of certificate templates, a certificate authority itself has permissions (accessible through certsrv.msc) that secure various CA actions. From a security perspective we care about the ManageCA (aka “CA Administrator”) and ManageCertificates (aka “Certificate Manager/Officer”) permissions.

The ManageCA permission grants a principal the ability to perform “Administrative” CA actions, including the modification of persistent configuration data. This includes the EDITF_ATTRIBUTESUBJECTALTNAME2 flag, allowing any principal with the ManageCA permission to fixate ESC6. This can be done with PSPKI’s Enable-PolicyModuleFlag cmdlet.

The ManageCertificates permission allows the principal to approve pending certificate requests, negating the “Manager Approval” Issuance Requirement/protection. So while it can’t be used on its own to compromise the domain, it can function as a protection bypass.

NTLM Relay to AD CS HTTP Endpoints — ESC8

We cover this in more detail in the “Background — Certificate Enrollment” section of the whitepaper, but AD CS supports several HTTP-based enrollment methods via additional server roles that administrators can optionally install:

The certificate enrollment web interface, via installing the Certificate Authority Web Enrollment role. Exposed as an IIS-hosted ASP web enrollment application running at http://<ADCSSERVER>/certsrv/
Certificate enrollment service (CES), via installing the Certificate Enrollment Web Service role. Works in tandem with the Certificate Enrollment Policy (CEP) web service, via installing the Certificate Enrollment Policy Web Service role. Details in the whitepaper.
The network device enrollment service (NDES), via installing the Network Device Enrollment Service role. Exposed as a series of interfaces described in the whitepaper.

These HTTP-based certificate enrollment interfaces are all vulnerable to NTLM relay attacks. Using NTLM relay, an attacker can impersonate an inbound-NTLM-authenticating victim user. While impersonating the victim user, an attacker could access these web interfaces and request a client authentication certificate based on the User or Machine certificate templates.

This attack, like all NTLM relay attacks, requires a victim account to authenticate to an attacker-controlled machine. An attacker can coerce authentication by many means, but a simple technique is to coerce a machine account to authenticate to the attacker’s host using the MS-RPRN RpcRemoteFindFirstPrinterChangeNotification(Ex) methods using a tool like SpoolSample or Dementor. The attacker can then use NTLM relay to impersonate the machine account and request a client authentication certificate (e.g., the default Machine/Computer template) as the victim machine account. If the victim machine account can perform privileged actions such as domain replication (e.g., domain controllers or Exchange servers), the attacker could use this certificate to compromise the domain. Otherwise, the attacker could logon as the victim machine account and use S4U2Self as previously described to access the victim machine’s host OS.

Note: Newer OS’es have patched the MS-RPRN coerced authentication “feature”. However, almost every environment we examine still has Server 2016 machines running, which are still vulnerable to this. There are other ways to coerce accounts to authenticate to an attacker as well.

In summary, if an environment has AD CS installed, along with a vulnerable web enrollment endpoint and at least one certificate template published that allows for domain computer enrollment and client authentication (like the default Machine/Computer template), then an attacker can compromise ANY computer with the spooler service running!

These attack scenarios work because some enrollment HTTP endpoints do not have HTTPS enabled and none of them have any NTLM relay protections enabled by default. Organizations should disable these HTTP-based enrollment server roles if they are not in use. Otherwise, network defenders can disable NTLM authentication using GPOs or configuring the associated IIS applications to only accept Kerberos authentication. If organizations cannot remove the endpoints or outright disable NTLM authentication, they should only allow HTTPS traffic and configure the IIS applications to Extended Protection for Authentication .

This specific issue was reported to MSRC, along with the other template escalation misconfigurations. The official response was, “We determined your finding is valid but does not meet our bar for a security update release.”

Note: While we have verified that this attack is possible, we are waiting to publicly demonstrate it at our Black Hat talk to help facilitate fixing the issue first.

Domain Persistence

Active Directory Enterprise CAs are hooked into the authentication system of AD and the CA root certificate private key is used to sign newly issued certificates. If we stole this private key, would we be able to forge our own certificates that could be used (without a smart card) to authenticate to Active Directory as anyone in the organization?

Spoiler: yes. And this has already been possible with Mimikatz/Kekeo for years. I guess we should call these golden certificates?

The certificate exists on the CA server itself, with its private key protected by machine DPAPI if a TPM/HSM is not used for hardware-based protection. If the key is not hardware protected, Mimikatz and SharpDPAPI can extract the CA certificate and private key from the CA:

With this key, you can create and sign new certificates for ANY user and use these forged certificates to authenticate to AD for as long as the CA cert is valid (default of 5 years, but often longer). Our tool ForgeCert (which will be released at Black Hat USA 2021 along with Certify) can perform these forgeries:

Oh, and these certs can’t be revoked, since they were never actually issued by the CA itself, as detailed by Benjamin Delpy:

Unfortunately, there isn’t a huge amount of public incident response guidance as far as AD CS. But if a root CA’s key is stolen, the entire AD CS system will likely need to be rebuilt, invalidating every issued certificate.

Defensive Advice

Not only are we self-embargoing the offensive tool release for these abuses, but we’ve also spent a large amount of effort researching both preventative and detective controls for these attacks. Part of the motivation for breaking out attacks and associated defensive protections with individual identifiers was to make the whitepaper material as digestible as possible for defenders.

Besides identifying and mitigating the privilege escalation vulnerabilities, something we want to emphasize from an incident response perspective is that it is not enough to reset a compromised user’s password and/or reimage their machine. Certificate theft is trivial in most environments given code execution in a user or computer context and would allow an attacker to authenticate to AD for years — even after the account’s password has been reset. Therefore, when an account or machine is compromised, incident responders should identify and invalidate any certificates associated with the compromised accounts as well. PSPKIAudit’s Get-CertRequest can help perform this type of triage.

As the defenses for these attacks are multi-pronged, at this point we’re recommending defenders study the attacks, read the extensive “Defensive Guidance” section of the whitepaper, and reference Microsoft’s Securing PKI documentation. Defenders can also try out the PSPKIAudit’s Invoke-PKIAudit function the misconfigurations described in this post:

Wrap-up

Even months into this research, we believed that there wasn’t necessarily anything inherently insecure about Active Directory Certificate Services. While the entire system is very dangerous if an organization doesn’t fully understand AD CS or its security implications (as it’s extremely easy to misconfigure) there didn’t appear to be any “out of the box” vulnerabilities. That said, we have seen a proliferation of the ESC1–7 elevation issues in real environments since we began looking in January 2021. We feel administrators have been given a powerful weapon with the safety off for 20 years and there’s been little safety training. An attitude of, “Well, admins should have known better” in this scenario, without even providing a way to audit or investigate these issues programmatically from a defensive context, is, well, a position we suppose.

However, beyond the template misconfiguration scenarios, the ESC8 relay situation is a serious security issue. We reported this relay issue to MSRC on May 19th along with all domain escalation scenarios, and received a response on June 8th of “We determined your finding is valid but does not meet our bar for a security update release. We considered that servers with AD CS roles could mitigate this risk with a change in configuration settings to enable Extended Protection for Authentication (EPA), per this blog post.” MSRC stated that they also opened up a bug concerning the template issues and our comments about poor telemetry with the AD CS feature team, who may consider additional design changes in a future release.

To be clear, based on our research, if you are running AD CS with ANY template a domain computer can enroll in that also allows domain authentication (e.g., the Machine/Computer template that is available by default), ANY system running the spooler service can be compromised. Based on our extensive experience assessing AD environments, we believe this is very bad. If you find you are vulnerable to this, consider contacting your nearest Microsoft representative and question them as to why this insecure default configuration is allowed. As of right now, they have no intentions of directly servicing the issue, but said they may fix it at some indeterminate future date.

From a defensive perspective, you should either immediately enumerate the Web Enrollment interfaces enabled in your environment (possible with PSPKIAudit) and then either remove them, disable NTLM authentication to them, or enforce HTTPS to them and enable EPA on the IIS server component. For specifics on how to do this, please see “Defensive Guidance — Harden AD CS HTTP Endpoints — PREVENT8” in the whitepaper. We also strongly recommend organizations audit their AD CS architecture and certificate templates and treat CA servers (including subordinate CAs) as Tier 0 assets with the same protections as Domain Controllers! The “Defensive Guidance” section of the whitepaper has more information on how to proactively prevent, detect, and respond to the attacks we’ve detailed.

Yes, we’re working to integrate the escalation paths into BloodHound, but as you can see this whole thing is rather complicated, and we want to get it right. But rest assured, it’s currently under development at the moment and will be released in FOSS BloodHound.

And finally, as a disclaimer, we are not stating that we know every security issue concerning AD CS. We took our best shot in this research, but we are confident that there are additional issues and attacker tradecraft implications that we (or others) will find in the coming months, or things we have missed.

Acknowledgements

As is almost always the case, we’re standing on a number of shoulders with this research. The whitepaper gives a more complete treatment of prior work, but as a summary:

Benjamin Delpy for his extensive work on smart cards/certificates with Mimikatz and Kekeo.
PKI Solutions for their excellent posts on PKI in Active Directory, as well as their PSPKI PowerShell module, which our auditing toolkit is based on.
The “Windows Server 2008 — PKI and Certificate Security” book by Brian Komar.
The following open technical specifications provided by Microsoft:
[MS-CERSOD]: Certificate Services Protocols Overview
[MS-CRTD]: Certificate Templates Structure
[MS-CSRA]: Certificate Services Remote Administration Protocol
[MS-ICPR]: ICertPassage Remote Protocol
[MS-WCCE]: Windows Client Certificate Enrollment Protocol
Christoph Falta’s GitHub repo which covers some details on attacking certificate templates, including virtual smart cards as well as some ideas on ACL based abuses.
CQURE’s “The tale of Enhanced Key (mis)Usage” post which covers some Subject Alternative Name abuses.
Keyfactor’s 2016 post “Hidden Dangers: Certificate Subject Alternative Names (SANs)”
@Elkement’s posts “Sizzle @ hackthebox — Unintended: Getting a Logon Smartcard for the Domain Admin!” and “Impersonating a Windows Enterprise Admin with a Certificate: Kerberos PKINIT from Linux” detail certificate template misconfigurations.
Carl Sörqvist wrote up a detailed, and plausible, scenario for how some of these misconfigurations happen titled “Supply in the Request Shenanigans”.
Ceri Coburn released an excellent post in 2020 on “Attacking Smart Card Based Active Directory Networks” detailing some smart card abuse and Rubeus additions.
Brad Hill published a whitepaper titled “Weaknesses and Best Practices of Public Key Kerberos with Smart Cards which provided some good background on Kerberos/PKINIT from a security perspective.

Special thanks to Mark Gamache for collaborating with us on parts of this work. He independently discovered many of these abuses, reached out to us, and brought many additional details to our attention while we were performing this research.

As always, we tried our best to cite the existing work out there that we came across, but we’re sure we missed things.

Whitepaper — “Certified Pre-Owned: Abusing Active Directory Certificate Services”
Defensive Toolkit — PSPKIAudit (based on PSPKI)
Offensive Toolkit — (code will be pushed at Black Hat, preemptive IOCs/Yara rules are currently live) Certify and ForgeCert

Source :

https://posts.specterops.io/certified-pre-owned-d95910965cd2

NSA and CISA Red and Blue Teams Share Top Ten Cybersecurity Misconfigurations

Release Date October 05, 2023
Alert CodeAA23-278A

A plea for network defenders and software manufacturers to fix common problems.

EXECUTIVE SUMMARY

The National Security Agency (NSA) and Cybersecurity and Infrastructure Security Agency (CISA) are releasing this joint cybersecurity advisory (CSA) to highlight the most common cybersecurity misconfigurations in large organizations, and detail the tactics, techniques, and procedures (TTPs) actors use to exploit these misconfigurations.

Through NSA and CISA Red and Blue team assessments, as well as through the activities of NSA and CISA Hunt and Incident Response teams, the agencies identified the following 10 most common network misconfigurations:

Default configurations of software and applications
Improper separation of user/administrator privilege
Insufficient internal network monitoring
Lack of network segmentation
Poor patch management
Bypass of system access controls
Weak or misconfigured multifactor authentication (MFA) methods
Insufficient access control lists (ACLs) on network shares and services
Poor credential hygiene
Unrestricted code execution

These misconfigurations illustrate (1) a trend of systemic weaknesses in many large organizations, including those with mature cyber postures, and (2) the importance of software manufacturers embracing secure-by-design principles to reduce the burden on network defenders:

Properly trained, staffed, and funded network security teams can implement the known mitigations for these weaknesses.
Software manufacturers must reduce the prevalence of these misconfigurations—thus strengthening the security posture for customers—by incorporating secure-by-design and -default principles and tactics into their software development practices.[1]

NSA and CISA encourage network defenders to implement the recommendations found within the Mitigations section of this advisory—including the following—to reduce the risk of malicious actors exploiting the identified misconfigurations.

Remove default credentials and harden configurations.
Disable unused services and implement access controls.
Update regularly and automate patching, prioritizing patching of known exploited vulnerabilities.[2]
Reduce, restrict, audit, and monitor administrative accounts and privileges.

NSA and CISA urge software manufacturers to take ownership of improving security outcomes of their customers by embracing secure-by-design and-default tactics, including:

Embedding security controls into product architecture from the start of development and throughout the entire software development lifecycle (SDLC).
Eliminating default passwords.
Providing high-quality audit logs to customers at no extra charge.
Mandating MFA, ideally phishing-resistant, for privileged users and making MFA a default rather than opt-in feature.[3]

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

TECHNICAL DETAILS

Note: This advisory uses the MITRE ATT&CK^® for Enterprise framework, version 13, and the MITRE D3FEND™ cybersecurity countermeasures framework.[4],[5] See the Appendix: MITRE ATT&CK tactics and techniques section for tables summarizing the threat actors’ activity mapped to MITRE ATT&CK tactics and techniques, and the Mitigations section for MITRE D3FEND countermeasures.

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.[6],[7]

Overview

Over the years, the following NSA and CISA teams have assessed the security posture of many network enclaves across the Department of Defense (DoD); Federal Civilian Executive Branch (FCEB); state, local, tribal, and territorial (SLTT) governments; and the private sector:

Depending on the needs of the assessment, NSA Defensive Network Operations (DNO) teams feature capabilities from Red Team (adversary emulation), Blue Team (strategic vulnerability assessment), Hunt (targeted hunt), and/or Tailored Mitigations (defensive countermeasure development).
CISA Vulnerability Management (VM) teams have assessed the security posture of over 1,000 network enclaves. CISA VM teams include Risk and Vulnerability Assessment (RVA) and CISA Red Team Assessments (RTA).[8] The RVA team conducts remote and onsite assessment services, including penetration testing and configuration review. RTA emulates cyber threat actors in coordination with an organization to assess the organization’s cyber detection and response capabilities.
CISA Hunt and Incident Response teams conduct proactive and reactive engagements, respectively, on organization networks to identify and detect cyber threats to U.S. infrastructure.

During these assessments, NSA and CISA identified the 10 most common network misconfigurations, which are detailed below. These misconfigurations (non-prioritized) are systemic weaknesses across many networks.

Many of the assessments were of Microsoft^® Windows^® and Active Directory^® environments. This advisory provides details about, and mitigations for, specific issues found during these assessments, and so mostly focuses on these products. However, it should be noted that many other environments contain similar misconfigurations. Network owners and operators should examine their networks for similar misconfigurations even when running other software not specifically mentioned below.

1. Default Configurations of Software and Applications

Default configurations of systems, services, and applications can permit unauthorized access or other malicious activity. Common default configurations include:

Default credentials
Default service permissions and configurations settings

Default Credentials

Many software manufacturers release commercial off-the-shelf (COTS) network devices —which provide user access via applications or web portals—containing predefined default credentials for their built-in administrative accounts.[9] Malicious actors and assessment teams regularly abuse default credentials by:

Finding credentials with a simple web search [T1589.001] and using them [T1078.001] to gain authenticated access to a device.
Resetting built-in administrative accounts [T1098] via predictable forgotten passwords questions.
Leveraging default virtual private network (VPN) credentials for internal network access [T1133].
Leveraging publicly available setup information to identify built-in administrative credentials for web applications and gaining access to the application and its underlying database.
Leveraging default credentials on software deployment tools [T1072] for code execution and lateral movement.

In addition to devices that provide network access, printers, scanners, security cameras, conference room audiovisual (AV) equipment, voice over internet protocol (VoIP) phones, and internet of things (IoT) devices commonly contain default credentials that can be used for easy unauthorized access to these devices as well. Further compounding this problem, printers and scanners may have privileged domain accounts loaded so that users can easily scan documents and upload them to a shared drive or email them. Malicious actors who gain access to a printer or scanner using default credentials can use the loaded privileged domain accounts to move laterally from the device and compromise the domain [T1078.002].

Default Service Permissions and Configuration Settings

Certain services may have overly permissive access controls or vulnerable configurations by default. Additionally, even if the providers do not enable these services by default, malicious actors can easily abuse these services if users or administrators enable them.

Assessment teams regularly find the following:

Insecure Active Directory Certificate Services
Insecure legacy protocols/services
Insecure Server Message Block (SMB) service

Insecure Active Directory Certificate Services

Active Directory Certificate Services (ADCS) is a feature used to manage Public Key Infrastructure (PKI) certificates, keys, and encryption inside of Active Directory (AD) environments. ADCS templates are used to build certificates for different types of servers and other entities on an organization’s network.

Malicious actors can exploit ADCS and/or ADCS template misconfigurations to manipulate the certificate infrastructure into issuing fraudulent certificates and/or escalate user privileges to domain administrator privileges. These certificates and domain escalation paths may grant actors unauthorized, persistent access to systems and critical data, the ability to impersonate legitimate entities, and the ability to bypass security measures.

Assessment teams have observed organizations with the following misconfigurations:

ADCS servers running with web-enrollment enabled. If web-enrollment is enabled, unauthenticated actors can coerce a server to authenticate to an actor-controlled computer, which can relay the authentication to the ADCS web-enrollment service and obtain a certificate [T1649] for the server’s account. These fraudulent, trusted certificates enable actors to use adversary-in-the-middle techniques [T1557] to masquerade as trusted entities on the network. The actors can also use the certificate for AD authentication to obtain a Kerberos Ticket Granting Ticket (TGT) [T1558.001], which they can use to compromise the server and usually the entire domain.
ADCS templates where low-privileged users have enrollment rights, and the enrollee supplies a subject alternative name. Misconfiguring various elements of ADCS templates can result in domain escalation by unauthorized users (e.g., granting low-privileged users certificate enrollment rights, allowing requesters to specify a subjectAltName in the certificate signing request [CSR], not requiring authorized signatures for CSRs, granting FullControl or WriteDacl permissions to users). Malicious actors can use a low-privileged user account to request a certificate with a particular Subject Alternative Name (SAN) and gain a certificate where the SAN matches the User Principal Name (UPN) of a privileged account.

Note: For more information on known escalation paths, including PetitPotam NTLM relay techniques, see: Domain Escalation: PetitPotam NTLM Relay to ADCS Endpoints and Certified Pre-Owned, Active Directory Certificate Services.[10],[11],[12]

Insecure legacy protocols/services

Many vulnerable network services are enabled by default, and assessment teams have observed them enabled in production environments. Specifically, assessment teams have observed Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBT-NS), which are Microsoft Windows components that serve as alternate methods of host identification. If these services are enabled in a network, actors can use spoofing, poisoning, and relay techniques [T1557.001] to obtain domain hashes, system access, and potential administrative system sessions. Malicious actors frequently exploit these protocols to compromise entire Windows’ environments.

Malicious actors can spoof an authoritative source for name resolution on a target network by responding to passing traffic, effectively poisoning the service so that target computers will communicate with an actor-controlled system instead of the intended one. If the requested system requires identification/authentication, the target computer will send the user’s username and hash to the actor-controlled system. The actors then collect the hash and crack it offline to obtain the plain text password [T1110.002].

Insecure Server Message Block (SMB) service

The Server Message Block service is a Windows component primarily for file sharing. Its default configuration, including in the latest version of Windows, does not require signing network messages to ensure authenticity and integrity. If SMB servers do not enforce SMB signing, malicious actors can use machine-in-the-middle techniques, such as NTLM relay. Further, malicious actors can combine a lack of SMB signing with the name resolution poisoning issue (see above) to gain access to remote systems [T1021.002] without needing to capture and crack any hashes.

2. Improper Separation of User/Administrator Privilege

Administrators often assign multiple roles to one account. These accounts have access to a wide range of devices and services, allowing malicious actors to move through a network quickly with one compromised account without triggering lateral movement and/or privilege escalation detection measures.

Assessment teams have observed the following common account separation misconfigurations:

Excessive account privileges
Elevated service account permissions
Non-essential use of elevated accounts

Excessive Account Privileges

Account privileges are intended to control user access to host or application resources to limit access to sensitive information or enforce a least-privilege security model. When account privileges are overly permissive, users can see and/or do things they should not be able to, which becomes a security issue as it increases risk exposure and attack surface.

Expanding organizations can undergo numerous changes in account management, personnel, and access requirements. These changes commonly lead to privilege creep—the granting of excessive access and unnecessary account privileges. Through the analysis of topical and nested AD groups, a malicious actor can find a user account [T1078] that has been granted account privileges that exceed their need-to-know or least-privilege function. Extraneous access can lead to easy avenues for unauthorized access to data and resources and escalation of privileges in the targeted domain.

Elevated Service Account Permissions

Applications often operate using user accounts to access resources. These user accounts, which are known as service accounts, often require elevated privileges. When a malicious actor compromises an application or service using a service account, they will have the same privileges and access as the service account.

Malicious actors can exploit elevated service permissions within a domain to gain unauthorized access and control over critical systems. Service accounts are enticing targets for malicious actors because such accounts are often granted elevated permissions within the domain due to the nature of the service, and because access to use the service can be requested by any valid domain user. Due to these factors, kerberoasting—a form of credential access achieved by cracking service account credentials—is a common technique used to gain control over service account targets [T1558.003].

Non-Essential Use of Elevated Accounts

IT personnel use domain administrator and other administrator accounts for system and network management due to their inherent elevated privileges. When an administrator account is logged into a compromised host, a malicious actor can steal and use the account’s credentials and an AD-generated authentication token [T1528] to move, using the elevated permissions, throughout the domain [T1550.001]. Using an elevated account for normal day-to-day, non-administrative tasks increases the account’s exposure and, therefore, its risk of compromise and its risk to the network.

Malicious actors prioritize obtaining valid domain credentials upon gaining access to a network. Authentication using valid domain credentials allows the execution of secondary enumeration techniques to gain visibility into the target domain and AD structure, including discovery of elevated accounts and where the elevated accounts are used [T1087].

Targeting elevated accounts (such as domain administrator or system administrators) performing day-to-day activities provides the most direct path to achieve domain escalation. Systems or applications accessed by the targeted elevated accounts significantly increase the attack surface available to adversaries, providing additional paths and escalation options.

After obtaining initial access via an account with administrative permissions, an assessment team compromised a domain in under a business day. The team first gained initial access to the system through phishing [T1566], by which they enticed the end user to download [T1204] and execute malicious payloads. The targeted end-user account had administrative permissions, enabling the team to quickly compromise the entire domain.

3. Insufficient Internal Network Monitoring

Some organizations do not optimally configure host and network sensors for traffic collection and end-host logging. These insufficient configurations could lead to undetected adversarial compromise. Additionally, improper sensor configurations limit the traffic collection capability needed for enhanced baseline development and detract from timely detection of anomalous activity.

Assessment teams have exploited insufficient monitoring to gain access to assessed networks. For example:

An assessment team observed an organization with host-based monitoring, but no network monitoring. Host-based monitoring informs defensive teams about adverse activities on singular hosts and network monitoring informs about adverse activities traversing hosts [TA0008]. In this example, the organization could identify infected hosts but could not identify where the infection was coming from, and thus could not stop future lateral movement and infections.
An assessment team gained persistent deep access to a large organization with a mature cyber posture. The organization did not detect the assessment team’s lateral movement, persistence, and command and control (C2) activity, including when the team attempted noisy activities to trigger a security response. For more information on this activity, see CSA CISA Red Team Shares Key Findings to Improve Monitoring and Hardening of Networks.[13]

4. Lack of Network Segmentation

Network segmentation separates portions of the network with security boundaries. Lack of network segmentation leaves no security boundaries between the user, production, and critical system networks. Insufficient network segmentation allows an actor who has compromised a resource on the network to move laterally across a variety of systems uncontested. Lack of network segregation additionally leaves organizations significantly more vulnerable to potential ransomware attacks and post-exploitation techniques.

Lack of segmentation between IT and operational technology (OT) environments places OT environments at risk. For example, assessment teams have often gained access to OT networks—despite prior assurance that the networks were fully air gapped, with no possible connection to the IT network—by finding special purpose, forgotten, or even accidental network connections [T1199].

5. Poor Patch Management

Vendors release patches and updates to address security vulnerabilities. Poor patch management and network hygiene practices often enable adversaries to discover open attack vectors and exploit critical vulnerabilities. Poor patch management includes:

Lack of regular patching
Use of unsupported operating systems (OSs) and outdated firmware

Lack of Regular Patching

Failure to apply the latest patches can leave a system open to compromise from publicly available exploits. Due to their ease of discovery—via vulnerability scanning [T1595.002] and open source research [T1592]—and exploitation, these systems are immediate targets for adversaries. Allowing critical vulnerabilities to remain on production systems without applying their corresponding patches significantly increases the attack surface. Organizations should prioritize patching known exploited vulnerabilities in their environments.[2]

Assessment teams have observed threat actors exploiting many CVEs in public-facing applications [T1190], including:

CVE-2019-18935 in an unpatched instance of Telerik^® UI for ASP.NET running on a Microsoft IIS server.[14]
CVE-2021-44228 (Log4Shell) in an unpatched VMware^® Horizon server.[15]
CVE-2022-24682, CVE-2022-27924, and CVE-2022-27925 chained with CVE-2022-37042, or CVE-2022-30333 in an unpatched Zimbra^® Collaboration Suite.[16]

Use of Unsupported OSs and Outdated Firmware

Using software or hardware that is no longer supported by the vendor poses a significant security risk because new and existing vulnerabilities are no longer patched. Malicious actors can exploit vulnerabilities in these systems to gain unauthorized access, compromise sensitive data, and disrupt operations [T1210].

Assessment teams frequently observe organizations using unsupported Windows operating systems without updates MS17-010 and MS08-67. These updates, released years ago, address critical remote code execution vulnerabilities.[17],[18]

6. Bypass of System Access Controls

A malicious actor can bypass system access controls by compromising alternate authentication methods in an environment. If a malicious actor can collect hashes in a network, they can use the hashes to authenticate using non-standard means, such as pass-the-hash (PtH) [T1550.002]. By mimicking accounts without the clear-text password, an actor can expand and fortify their access without detection. Kerberoasting is also one of the most time-efficient ways to elevate privileges and move laterally throughout an organization’s network.

7. Weak or Misconfigured MFA Methods

Misconfigured Smart Cards or Tokens

Some networks (generally government or DoD networks) require accounts to use smart cards or tokens. Multifactor requirements can be misconfigured so the password hashes for accounts never change. Even though the password itself is no longer used—because the smart card or token is required instead—there is still a password hash for the account that can be used as an alternative credential for authentication. If the password hash never changes, once a malicious actor has an account’s password hash [T1111], the actor can use it indefinitely, via the PtH technique for as long as that account exists.

Lack of Phishing-Resistant MFA

Some forms of MFA are vulnerable to phishing, “push bombing” [T1621], exploitation of Signaling System 7 (SS7) protocol vulnerabilities, and/or “SIM swap” techniques. These attempts, if successful, may allow a threat actor to gain access to MFA authentication credentials or bypass MFA and access the MFA-protected systems. (See CISA’s Fact Sheet Implementing Phishing-Resistant MFA for more information.)[3]

For example, assessment teams have used voice phishing to convince users to provide missing MFA information [T1598]. In one instance, an assessment team knew a user’s main credentials, but their login attempts were blocked by MFA requirements. The team then masqueraded as IT staff and convinced the user to provide the MFA code over the phone, allowing the team to complete their login attempt and gain access to the user’s email and other organizational resources.

8. Insufficient ACLs on Network Shares and Services

Data shares and repositories are primary targets for malicious actors. Network administrators may improperly configure ACLs to allow for unauthorized users to access sensitive or administrative data on shared drives.

Actors can use commands, open source tools, or custom malware to look for shared folders and drives [T1135].

In one compromise, a team observed actors use the net share command—which displays information about shared resources on the local computer—and the ntfsinfo command to search network shares on compromised computers. In the same compromise, the actors used a custom tool, CovalentStealer, which is designed to identify file shares on a system, categorize the files [T1083], and upload the files to a remote server [TA0010].[19],[20]
Ransomware actors have used the SoftPerfect^® Network Scanner, netscan.exe—which can ping computers [T1018], scan ports [T1046], and discover shared folders—and SharpShares to enumerate accessible network shares in a domain.[21],[22]

Malicious actors can then collect and exfiltrate the data from the shared drives and folders. They can then use the data for a variety of purposes, such as extortion of the organization or as intelligence when formulating intrusion plans for further network compromise. Assessment teams routinely find sensitive information on network shares [T1039] that could facilitate follow-on activity or provide opportunities for extortion. Teams regularly find drives containing cleartext credentials [T1552] for service accounts, web applications, and even domain administrators.

Even when further access is not directly obtained from credentials in file shares, there can be a treasure trove of information for improving situational awareness of the target network, including the network’s topology, service tickets, or vulnerability scan data. In addition, teams regularly identify sensitive data and PII on shared drives (e.g., scanned documents, social security numbers, and tax returns) that could be used for extortion or social engineering of the organization or individuals.

9. Poor Credential Hygiene

Poor credential hygiene facilitates threat actors in obtaining credentials for initial access, persistence, lateral movement, and other follow-on activity, especially if phishing-resistant MFA is not enabled. Poor credential hygiene includes:

Easily crackable passwords
Cleartext password disclosure

Easily Crackable Passwords

Easily crackable passwords are passwords that a malicious actor can guess within a short time using relatively inexpensive computing resources. The presence of easily crackable passwords on a network generally stems from a lack of password length (i.e., shorter than 15 characters) and randomness (i.e., is not unique or can be guessed). This is often due to lax requirements for passwords in organizational policies and user training. A policy that only requires short and simple passwords leaves user passwords susceptible to password cracking. Organizations should provide or allow employee use of password managers to enable the generation and easy use of secure, random passwords for each account.

Often, when a credential is obtained, it is a hash (one-way encryption) of the password and not the password itself. Although some hashes can be used directly with PtH techniques, many hashes need to be cracked to obtain usable credentials. The cracking process takes the captured hash of the user’s plaintext password and leverages dictionary wordlists and rulesets, often using a database of billions of previously compromised passwords, in an attempt to find the matching plaintext password [T1110.002].

One of the primary ways to crack passwords is with the open source tool, Hashcat, combined with password lists obtained from publicly released password breaches. Once a malicious actor has access to a plaintext password, they are usually limited only by the account’s permissions. In some cases, the actor may be restricted or detected by advanced defense-in-depth and zero trust implementations as well, but this has been a rare finding in assessments thus far.

Assessment teams have cracked password hashes for NTLM users, Kerberos service account tickets, NetNTLMv2, and PFX stores [T1555], enabling the team to elevate privileges and move laterally within networks. In 12 hours, one team cracked over 80% of all users’ passwords in an Active Directory, resulting in hundreds of valid credentials.

Cleartext Password Disclosure

Storing passwords in cleartext is a serious security risk. A malicious actor with access to files containing cleartext passwords [T1552.001] could use these credentials to log into the affected applications or systems under the guise of a legitimate user. Accountability is lost in this situation as any system logs would record valid user accounts accessing applications or systems.

Malicious actors search for text files, spreadsheets, documents, and configuration files in hopes of obtaining cleartext passwords. Assessment teams frequently discover cleartext passwords, allowing them to quickly escalate the emulated intrusion from the compromise of a regular domain user account to that of a privileged account, such as a Domain or Enterprise Administrator. A common tool used for locating cleartext passwords is the open source tool, Snaffler.[23]

10. Unrestricted Code Execution

If unverified programs are allowed to execute on hosts, a threat actor can run arbitrary, malicious payloads within a network.

Malicious actors often execute code after gaining initial access to a system. For example, after a user falls for a phishing scam, the actor usually convinces the victim to run code on their workstation to gain remote access to the internal network. This code is usually an unverified program that has no legitimate purpose or business reason for running on the network.

Assessment teams and malicious actors frequently leverage unrestricted code execution in the form of executables, dynamic link libraries (DLLs), HTML applications, and macros (scripts used in office automation documents) [T1059.005] to establish initial access, persistence, and lateral movement. In addition, actors often use scripting languages [T1059] to obscure their actions [T1027.010] and bypass allowlisting—where organizations restrict applications and other forms of code by default and only allow those that are known and trusted. Further, actors may load vulnerable drivers and then exploit the drivers’ known vulnerabilities to execute code in the kernel with the highest level of system privileges to completely compromise the device [T1068].

MITIGATIONS

Network Defenders

NSA and CISA recommend network defenders implement the recommendations that follow to mitigate the issues identified in 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) as well as with the MITRE ATT&CK Enterprise Mitigations and MITRE D3FEND frameworks.

The CPGs provide a minimum set of practices and protections that CISA and NIST recommend all organizations implement. CISA and NIST based the CPGs on existing cybersecurity frameworks and guidance to protect against the most common and impactful threats, tactics, techniques, and procedures. Visit CISA’s Cross-Sector Cybersecurity Performance Goals for more information on the CPGs, including additional recommended baseline protections.[24]

Mitigate Default Configurations of Software and Applications

Misconfiguration	Recommendations for Network Defenders
Default configurations of software and applications	Modify the default configuration of applications and appliances before deployment in a production environment [M1013],[D3-ACH]. Refer to hardening guidelines provided by the vendor and related cybersecurity guidance (e.g., DISA’s Security Technical Implementation Guides (STIGs) and configuration guides).[25],[26],[27]
Default configurations of software and applications: Default Credentials	Change or disable vendor-supplied default usernames and passwords of services, software, and equipment when installing or commissioning [CPG 2.A]. When resetting passwords, enforce the use of “strong” passwords (i.e., passwords that are more than 15 characters and random [CPG 2.B]) and follow hardening guidelines provided by the vendor, STIGs, NSA, and/or NIST [M1027],[D3-SPP].[25],[26],[28],[29]
Default service permissions and configuration settings: Insecure Active Directory Certificate Services	Ensure the secure configuration of ADCS implementations. Regularly update and patch the controlling infrastructure (e.g., for CVE-2021-36942), employ monitoring and auditing mechanisms, and implement strong access controls to protect the infrastructure.If not needed, disable web-enrollment in ADCS servers. See Microsoft: Uninstall-AdcsWebEnrollment (ADCSDeployment) for guidance.[30]If web enrollment is needed on ADCS servers:Enable Extended Protection for Authentication (EPA) for Client Authority Web Enrollment. This is done by choosing the “Required” option. For guidance, see Microsoft: KB5021989: Extended Protection for Authentication.[31]Enable “Require SSL” on the ADCS server.Disable NTLM on all ADCS servers. For guidance, see Microsoft: Network security Restrict NTLM in this domain – Windows Security \| Microsoft Learn and Network security Restrict NTLM Incoming NTLM traffic – Windows Security.[32],[33]Disable SAN for UPN Mapping. For guidance see, Microsoft: How to disable the SAN for UPN mapping – Windows Server. Instead, smart card authentication can use the `altSecurityIdentities` attribute for explicit mapping of certificates to accounts more securely.[34]Review all permissions on the ADCS templates on applicable servers. Restrict enrollment rights to only those users or groups that require it. Disable the `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` flag from templates to prevent users from supplying and editing sensitive security settings within these templates. Enforce manager approval for requested certificates. Remove `FullControl`, `WriteDacl`, and `Write` property permissions from low-privileged groups, such as domain users, to certificate template objects.
Default service permissions and configuration settings: Insecure legacy protocols/services	Determine if LLMNR and NetBIOS are required for essential business operations.If not required, disable LLMNR and NetBIOS in local computer security settings or by group policy.
Default service permissions and configuration settings: Insecure SMB service	Require SMB signing for both SMB client and server on all systems.[25] This should prevent certain adversary-in-the-middle and pass-the-hash techniques. For more information on SMB signing, see Microsoft: Overview of Server Message Block Signing. [35] Note: Beginning in Microsoft Windows 11 Insider Preview Build 25381, Windows requires SMB signing for all communications.[36]

Mitigate Improper Separation of User/Administrator Privilege

Misconfiguration	Recommendations for Network Defenders
Improper separation of user/administrator privilege:Excessive account privileges,Elevated service account permissions, andNon-essential use of elevated accounts	Implement authentication, authorization, and accounting (AAA) systems [M1018] to limit actions users can perform, and review logs of user actions to detect unauthorized use and abuse. Apply least privilege principles to user accounts and groups allowing only the performance of authorized actions.Audit user accounts and remove those that are inactive or unnecessary on a routine basis [CPG 2.D]. Limit the ability for user accounts to create additional accounts.Restrict use of privileged accounts to perform general tasks, such as accessing emails and browsing the Internet [CPG 2.E],[D3-UAP]. See NSA Cybersecurity Information Sheet (CSI) Defend Privileges and Accounts for more information.[37]Limit the number of users within the organization with an identity and access management (IAM) role that has administrator privileges. Strive to reduce all permanent privileged role assignments, and conduct periodic entitlement reviews on IAM users, roles, and policies.Implement time-based access for privileged accounts. For example, the just-in-time access method provisions privileged access when needed and can support enforcement of the principle of least privilege (as well as the Zero Trust model) by setting network-wide policy to automatically disable admin accounts at the Active Directory level. As needed, individual users can submit requests through an automated process that enables access to a system for a set timeframe. In cloud environments, just-in-time elevation is also appropriate and may be implemented using per-session federated claims or privileged access management tools.Restrict domain users from being in the local administrator group on multiple systems.Run daemonized applications (services) with non-administrator accounts when possible.Only configure service accounts with the permissions necessary for the services they control to operate.Disable unused services and implement ACLs to protect services.

Misconfiguration

Recommendations for Network Defenders

Improper separation of user/administrator privilege:Excessive account privileges,Elevated service account permissions, andNon-essential use of elevated accounts

Implement authentication, authorization, and accounting (AAA) systems [M1018] to limit actions users can perform, and review logs of user actions to detect unauthorized use and abuse. Apply least privilege principles to user accounts and groups allowing only the performance of authorized actions.Audit user accounts and remove those that are inactive or unnecessary on a routine basis [CPG 2.D]. Limit the ability for user accounts to create additional accounts.Restrict use of privileged accounts to perform general tasks, such as accessing emails and browsing the Internet [CPG 2.E],[D3-UAP]. See NSA Cybersecurity Information Sheet (CSI) Defend Privileges and Accounts for more information.[37]Limit the number of users within the organization with an identity and access management (IAM) role that has administrator privileges. Strive to reduce all permanent privileged role assignments, and conduct periodic entitlement reviews on IAM users, roles, and policies.Implement time-based access for privileged accounts. For example, the just-in-time access method provisions privileged access when needed and can support enforcement of the principle of least privilege (as well as the Zero Trust model) by setting network-wide policy to automatically disable admin accounts at the Active Directory level. As needed, individual users can submit requests through an automated process that enables access to a system for a set timeframe. In cloud environments, just-in-time elevation is also appropriate and may be implemented using per-session federated claims or privileged access management tools.Restrict domain users from being in the local administrator group on multiple systems.Run daemonized applications (services) with non-administrator accounts when possible.Only configure service accounts with the permissions necessary for the services they control to operate.Disable unused services and implement ACLs to protect services.

Mitigate Insufficient Internal Network Monitoring

Misconfiguration	Recommendations for Network Defenders
Insufficient internal network monitoring	Establish a baseline of applications and services, and routinely audit their access and use, especially for administrative activity [D3-ANAA]. For instance, administrators should routinely audit the access lists and permissions for of all web applications and services [CPG 2.O],[M1047]. Look for suspicious accounts, investigate them, and remove accounts and credentials, as appropriate, such as accounts of former staff.[39]Establish a baseline that represents an organization’s normal traffic activity, network performance, host application activity, and user behavior; investigate any deviations from that baseline [D3-NTCD],[D3-CSPP],[D3-UBA].[40]Use auditing tools capable of detecting privilege and service abuse opportunities on systems within an enterprise and correct them [M1047].Implement a security information and event management (SIEM) system to provide log aggregation, correlation, querying, visualization, and alerting from network endpoints, logging systems, endpoint and detection response (EDR) systems and intrusion detection systems (IDS) [CPG 2.T],[D3-NTA].

Misconfiguration

Recommendations for Network Defenders

Insufficient internal network monitoring

Establish a baseline of applications and services, and routinely audit their access and use, especially for administrative activity [D3-ANAA]. For instance, administrators should routinely audit the access lists and permissions for of all web applications and services [CPG 2.O],[M1047]. Look for suspicious accounts, investigate them, and remove accounts and credentials, as appropriate, such as accounts of former staff.[39]Establish a baseline that represents an organization’s normal traffic activity, network performance, host application activity, and user behavior; investigate any deviations from that baseline [D3-NTCD],[D3-CSPP],[D3-UBA].[40]Use auditing tools capable of detecting privilege and service abuse opportunities on systems within an enterprise and correct them [M1047].Implement a security information and event management (SIEM) system to provide log aggregation, correlation, querying, visualization, and alerting from network endpoints, logging systems, endpoint and detection response (EDR) systems and intrusion detection systems (IDS) [CPG 2.T],[D3-NTA].

Mitigate Lack of Network Segmentation

Misconfiguration	Recommendations for Network Defenders
Lack of network segmentation	Implement next-generation firewalls to perform deep packet filtering, stateful inspection, and application-level packet inspection [D3-NTF]. Deny or drop improperly formatted traffic that is incongruent with application-specific traffic permitted on the network. This practice limits an actor’s ability to abuse allowed application protocols. The practice of allowlisting network applications does not rely on generic ports as filtering criteria, enhancing filtering fidelity. For more information on application-aware defenses, see NSA CSI Segment Networks and Deploy Application-Aware Defenses.[41]Engineer network segments to isolate critical systems, functions, and resources [CPG 2.F],[D3-NI]. Establish physical and logical segmentation controls, such as virtual local area network (VLAN) configurations and properly configured access control lists (ACLs) on infrastructure devices [M1030]. These devices should be baselined and audited to prevent access to potentially sensitive systems and information. Leverage properly configured Demilitarized Zones (DMZs) to reduce service exposure to the Internet.[42],[43],[44]Implement separate Virtual Private Cloud (VPC) instances to isolate essential cloud systems. Where possible, implement Virtual Machines (VM) and Network Function Virtualization (NFV) to enable micro-segmentation of networks in virtualized environments and cloud data centers. Employ secure VM firewall configurations in tandem with macro segmentation.

Misconfiguration

Recommendations for Network Defenders

Lack of network segmentation

Implement next-generation firewalls to perform deep packet filtering, stateful inspection, and application-level packet inspection [D3-NTF]. Deny or drop improperly formatted traffic that is incongruent with application-specific traffic permitted on the network. This practice limits an actor’s ability to abuse allowed application protocols. The practice of allowlisting network applications does not rely on generic ports as filtering criteria, enhancing filtering fidelity. For more information on application-aware defenses, see NSA CSI Segment Networks and Deploy Application-Aware Defenses.[41]Engineer network segments to isolate critical systems, functions, and resources [CPG 2.F],[D3-NI]. Establish physical and logical segmentation controls, such as virtual local area network (VLAN) configurations and properly configured access control lists (ACLs) on infrastructure devices [M1030]. These devices should be baselined and audited to prevent access to potentially sensitive systems and information. Leverage properly configured Demilitarized Zones (DMZs) to reduce service exposure to the Internet.[42],[43],[44]Implement separate Virtual Private Cloud (VPC) instances to isolate essential cloud systems. Where possible, implement Virtual Machines (VM) and Network Function Virtualization (NFV) to enable micro-segmentation of networks in virtualized environments and cloud data centers. Employ secure VM firewall configurations in tandem with macro segmentation.

Mitigate Poor Patch Management

Misconfiguration	Recommendations for Network Defenders
Poor patch management: Lack of regular patching	Ensure organizations implement and maintain an efficient patch management process that enforces the use of up-to-date, stable versions of OSs, browsers, and software [M1051],[D3-SU].[45]Update software regularly by employing patch management for externally exposed applications, internal enterprise endpoints, and servers. Prioritize patching known exploited vulnerabilities.[2]Automate the update process as much as possible and use vendor-provided updates. Consider using automated patch management tools and software update tools.Where patching is not possible due to limitations, segment networks to limit exposure of the vulnerable system or host.
Poor patch management: Use of unsupported OSs and outdated firmware	Evaluate the use of unsupported hardware and software and discontinue use as soon as possible. If discontinuing is not possible, implement additional network protections to mitigate the risk.[45]Patch the Basic Input/Output System (BIOS) and other firmware to prevent exploitation of known vulnerabilities.

Misconfiguration

Recommendations for Network Defenders

Poor patch management: Lack of regular patching

Ensure organizations implement and maintain an efficient patch management process that enforces the use of up-to-date, stable versions of OSs, browsers, and software [M1051],[D3-SU].[45]Update software regularly by employing patch management for externally exposed applications, internal enterprise endpoints, and servers. Prioritize patching known exploited vulnerabilities.[2]Automate the update process as much as possible and use vendor-provided updates. Consider using automated patch management tools and software update tools.Where patching is not possible due to limitations, segment networks to limit exposure of the vulnerable system or host.

Poor patch management: Use of unsupported OSs and outdated firmware

Evaluate the use of unsupported hardware and software and discontinue use as soon as possible. If discontinuing is not possible, implement additional network protections to mitigate the risk.[45]Patch the Basic Input/Output System (BIOS) and other firmware to prevent exploitation of known vulnerabilities.

Mitigate Bypass of System Access Controls

Misconfiguration	Recommendations for Network Defenders
Bypass of system access controls	Limit credential overlap across systems to prevent credential compromise and reduce a malicious actor’s ability to move laterally between systems [M1026],[D3-CH]. Implement a method for monitoring non-standard logon events through host log monitoring [CPG 2.G].Implement an effective and routine patch management process. Mitigate PtH techniques by applying patch KB2871997 to Windows 7 and newer versions to limit default access of accounts in the local administrator group [M1051],[D3-SU].[46]Enable the PtH mitigations to apply User Account Control (UAC) restrictions to local accounts upon network logon [M1052],[D3-UAP].Deny domain users the ability to be in the local administrator group on multiple systems [M1018],[D3-UAP].Limit workstation-to-workstation communications. All workstation communications should occur through a server to prevent lateral movement [M1018],[D3-UAP].Use privileged accounts only on systems requiring those privileges [M1018],[D3-UAP]. Consider using dedicated Privileged Access Workstations for privileged accounts to better isolate and protect them.[37]

Misconfiguration

Recommendations for Network Defenders

Bypass of system access controls

Limit credential overlap across systems to prevent credential compromise and reduce a malicious actor’s ability to move laterally between systems [M1026],[D3-CH]. Implement a method for monitoring non-standard logon events through host log monitoring [CPG 2.G].Implement an effective and routine patch management process. Mitigate PtH techniques by applying patch KB2871997 to Windows 7 and newer versions to limit default access of accounts in the local administrator group [M1051],[D3-SU].[46]Enable the PtH mitigations to apply User Account Control (UAC) restrictions to local accounts upon network logon [M1052],[D3-UAP].Deny domain users the ability to be in the local administrator group on multiple systems [M1018],[D3-UAP].Limit workstation-to-workstation communications. All workstation communications should occur through a server to prevent lateral movement [M1018],[D3-UAP].Use privileged accounts only on systems requiring those privileges [M1018],[D3-UAP]. Consider using dedicated Privileged Access Workstations for privileged accounts to better isolate and protect them.[37]

Mitigate Weak or Misconfigured MFA Methods

Misconfiguration	Recommendations for Network Defenders
Weak or misconfigured MFA methods: Misconfigured smart cards or tokens	In Windows environments:Disable the use of New Technology LAN Manager (NTLM) and other legacy authentication protocols that are susceptible to PtH due to their use of password hashes [M1032],[D3-MFA]. For guidance, see Microsoft: Network security Restrict NTLM in this domain – Windows Security \| Microsoft Learn and Network security Restrict NTLM Incoming NTLM traffic – Windows Security.[32],[33]Use built-in functionality via Windows Hello for Business or Group Policy Objects (GPOs) to regularly re-randomize password hashes associated with smartcard-required accounts. Ensure that the hashes are changed at least as often as organizational policy requires passwords to be changed [M1027],[D3-CRO]. Prioritize upgrading any environments that cannot utilize this built-in functionality.As a longer-term effort, implement cloud-primary authentication solution using modern open standards. See CISA’s Secure Cloud Business Applications (SCuBA) Hybrid Identity Solutions Architecture for more information.[47] Note: this document is part of CISA’s Secure Cloud Business Applications (SCuBA) project, which provides guidance for FCEB agencies to secure their cloud business application environments and to protect federal information that is created, accessed, shared, and stored in those environments. Although tailored to FCEB agencies, the project’s guidance is applicable to all organizations.[48]
Weak or misconfigured MFA methods: Lack of phishing-resistant MFA	Enforce phishing-resistant MFA universally for access to sensitive data and on as many other resources and services as possible [CPG 2.H].[3],[49]

Misconfiguration

Recommendations for Network Defenders

Weak or misconfigured MFA methods: Misconfigured smart cards or tokens

In Windows environments:Disable the use of New Technology LAN Manager (NTLM) and other legacy authentication protocols that are susceptible to PtH due to their use of password hashes [M1032],[D3-MFA]. For guidance, see Microsoft: Network security Restrict NTLM in this domain – Windows Security | Microsoft Learn and Network security Restrict NTLM Incoming NTLM traffic – Windows Security.[32],[33]Use built-in functionality via Windows Hello for Business or Group Policy Objects (GPOs) to regularly re-randomize password hashes associated with smartcard-required accounts. Ensure that the hashes are changed at least as often as organizational policy requires passwords to be changed [M1027],[D3-CRO]. Prioritize upgrading any environments that cannot utilize this built-in functionality.As a longer-term effort, implement cloud-primary authentication solution using modern open standards. See CISA’s Secure Cloud Business Applications (SCuBA) Hybrid Identity Solutions Architecture for more information.[47] Note: this document is part of CISA’s Secure Cloud Business Applications (SCuBA) project, which provides guidance for FCEB agencies to secure their cloud business application environments and to protect federal information that is created, accessed, shared, and stored in those environments. Although tailored to FCEB agencies, the project’s guidance is applicable to all organizations.[48]

Weak or misconfigured MFA methods: Lack of phishing-resistant MFA

Enforce phishing-resistant MFA universally for access to sensitive data and on as many other resources and services as possible [CPG 2.H].[3],[49]

Mitigate Insufficient ACLs on Network Shares and Services

Misconfiguration	Recommendations for Network Defenders
Insufficient ACLs on network shares and services	Implement secure configurations for all storage devices and network shares that grant access to authorized users only.Apply the principal of least privilege to important information resources to reduce risk of unauthorized data access and manipulation.Apply restrictive permissions to files and directories, and prevent adversaries from modifying ACLs [M1022],[D3-LFP].Set restrictive permissions on files and folders containing sensitive private keys to prevent unintended access [M1022],[D3-LFP].Enable the Windows Group Policy security setting, “Do Not Allow Anonymous Enumeration of Security Account Manager (SAM) Accounts and Shares,” to limit users who can enumerate network shares.

Misconfiguration

Recommendations for Network Defenders

Insufficient ACLs on network shares and services

Implement secure configurations for all storage devices and network shares that grant access to authorized users only.Apply the principal of least privilege to important information resources to reduce risk of unauthorized data access and manipulation.Apply restrictive permissions to files and directories, and prevent adversaries from modifying ACLs [M1022],[D3-LFP].Set restrictive permissions on files and folders containing sensitive private keys to prevent unintended access [M1022],[D3-LFP].Enable the Windows Group Policy security setting, “Do Not Allow Anonymous Enumeration of Security Account Manager (SAM) Accounts and Shares,” to limit users who can enumerate network shares.

Mitigate Poor Credential Hygiene

Misconfiguration	Recommendations for Network Defenders
Poor credential hygiene: easily crackable passwords	Follow National Institute of Standards and Technologies (NIST) guidelines when creating password policies to enforce use of “strong” passwords that cannot be cracked [M1027],[D3-SPP].[29] Consider using password managers to generate and store passwords.Do not reuse local administrator account passwords across systems. Ensure that passwords are “strong” and unique [CPG 2.B],[M1027],[D3-SPP].Use “strong” passphrases for private keys to make cracking resource intensive. Do not store credentials within the registry in Windows systems. Establish an organizational policy that prohibits password storage in files.Ensure adequate password length (ideally 25+ characters) and complexity requirements for Windows service accounts and implement passwords with periodic expiration on these accounts [CPG 2.B],[M1027],[D3-SPP]. Use Managed Service Accounts, when possible, to manage service account passwords automatically.
Poor credential hygiene: cleartext password disclosure	Implement a review process for files and systems to look for cleartext account credentials. When credentials are found, remove, change, or encrypt them [D3-FE]. Conduct periodic scans of server machines using automated tools to determine whether sensitive data (e.g., personally identifiable information, protected health information) or credentials are stored. Weigh the risk of storing credentials in password stores and web browsers. If system, software, or web browser credential disclosure is of significant concern, technical controls, policy, and user training may prevent storage of credentials in improper locations.Store hashed passwords using Committee on National Security Systems Policy (CNSSP)-15 and Commercial National Security Algorithm Suite (CNSA) approved algorithms.[50],[51]Consider using group Managed Service Accounts (gMSAs) or third-party software to implement secure password-storage applications.

Misconfiguration

Recommendations for Network Defenders

Poor credential hygiene: easily crackable passwords

Follow National Institute of Standards and Technologies (NIST) guidelines when creating password policies to enforce use of “strong” passwords that cannot be cracked [M1027],[D3-SPP].[29] Consider using password managers to generate and store passwords.Do not reuse local administrator account passwords across systems. Ensure that passwords are “strong” and unique [CPG 2.B],[M1027],[D3-SPP].Use “strong” passphrases for private keys to make cracking resource intensive. Do not store credentials within the registry in Windows systems. Establish an organizational policy that prohibits password storage in files.Ensure adequate password length (ideally 25+ characters) and complexity requirements for Windows service accounts and implement passwords with periodic expiration on these accounts [CPG 2.B],[M1027],[D3-SPP]. Use Managed Service Accounts, when possible, to manage service account passwords automatically.

Poor credential hygiene: cleartext password disclosure

Implement a review process for files and systems to look for cleartext account credentials. When credentials are found, remove, change, or encrypt them [D3-FE]. Conduct periodic scans of server machines using automated tools to determine whether sensitive data (e.g., personally identifiable information, protected health information) or credentials are stored. Weigh the risk of storing credentials in password stores and web browsers. If system, software, or web browser credential disclosure is of significant concern, technical controls, policy, and user training may prevent storage of credentials in improper locations.Store hashed passwords using Committee on National Security Systems Policy (CNSSP)-15 and Commercial National Security Algorithm Suite (CNSA) approved algorithms.[50],[51]Consider using group Managed Service Accounts (gMSAs) or third-party software to implement secure password-storage applications.

Mitigate Unrestricted Code Execution

Misconfiguration	Recommendations for Network Defenders
Unrestricted code execution	Enable system settings that prevent the ability to run applications downloaded from untrusted sources.[52]Use application control tools that restrict program execution by default, also known as allowlisting [D3-EAL]. Ensure that the tools examine digital signatures and other key attributes, rather than just relying on filenames, especially since malware often attempts to masquerade as common Operating System (OS) utilities [M1038]. Explicitly allow certain .exe files to run, while blocking all others by default.Block or prevent the execution of known vulnerable drivers that adversaries may exploit to execute code in kernel mode. Validate driver block rules in audit mode to ensure stability prior to production deployment [D3-OSM].Constrain scripting languages to prevent malicious activities, audit script logs, and restrict scripting languages that are not used in the environment [D3-SEA]. See joint Cybersecurity Information Sheet: Keeping PowerShell: Security Measures to Use and Embrace.[53]Use read-only containers and minimal images, when possible, to prevent the running of commands.Regularly analyze border and host-level protections, including spam-filtering capabilities, to ensure their continued effectiveness in blocking the delivery and execution of malware [D3-MA]. Assess whether HTML Application (HTA) files are used for business purposes in your environment; if HTAs are not used, remap the default program for opening them from mshta.exe to notepad.exe.

Misconfiguration

Recommendations for Network Defenders

Unrestricted code execution

Enable system settings that prevent the ability to run applications downloaded from untrusted sources.[52]Use application control tools that restrict program execution by default, also known as allowlisting [D3-EAL]. Ensure that the tools examine digital signatures and other key attributes, rather than just relying on filenames, especially since malware often attempts to masquerade as common Operating System (OS) utilities [M1038]. Explicitly allow certain .exe files to run, while blocking all others by default.Block or prevent the execution of known vulnerable drivers that adversaries may exploit to execute code in kernel mode. Validate driver block rules in audit mode to ensure stability prior to production deployment [D3-OSM].Constrain scripting languages to prevent malicious activities, audit script logs, and restrict scripting languages that are not used in the environment [D3-SEA]. See joint Cybersecurity Information Sheet: Keeping PowerShell: Security Measures to Use and Embrace.[53]Use read-only containers and minimal images, when possible, to prevent the running of commands.Regularly analyze border and host-level protections, including spam-filtering capabilities, to ensure their continued effectiveness in blocking the delivery and execution of malware [D3-MA]. Assess whether HTML Application (HTA) files are used for business purposes in your environment; if HTAs are not used, remap the default program for opening them from mshta.exe to notepad.exe.

Software Manufacturers

NSA and CISA recommend software manufacturers implement the recommendations in Table 11 to reduce the prevalence of misconfigurations identified in this advisory. These mitigations align with tactics provided in joint guide Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Security-by-Design and -Default. NSA and CISA strongly encourage software manufacturers apply these recommendations to ensure their products are secure “out of the box” and do not require customers to spend additional resources making configuration changes, performing monitoring, and conducting routine updates to keep their systems secure.[1]

Misconfiguration	Recommendations for Software Manufacturers
Default configurations of software and applications	Embed security controls into product architecture from the start of development and throughout the entire SDLC by following best practices in NIST’s Secure Software Development Framework (SSDF), SP 800-218.[54]Provide software with security features enabled “out of the box” and accompanied with “loosening” guides instead of hardening guides. “Loosening” guides should explain the business risk of decisions in plain, understandable language.
Default configurations of software and applications: Default credentials	Eliminate default passwords: Do not provide software with default passwords that are universally shared. To eliminate default passwords, require administrators to set a “strong” password [CPG 2.B] during installation and configuration.
Default configurations of software and applications: Default service permissions and configuration settings	Consider the user experience consequences of security settings: Each new setting increases the cognitive burden on end users and should be assessed in conjunction with the business benefit it derives. Ideally, a setting should not exist; instead, the most secure setting should be integrated into the product by default. When configuration is necessary, the default option should be broadly secure against common threats.
Improper separation of user/administrator privilege:Excessive account privileges,Elevated service account permissions, andNon-essential use of elevated accounts	Design products so that the compromise of a single security control does not result in compromise of the entire system. For example, ensuring that user privileges are narrowly provisioned by default and ACLs are employed can reduce the impact of a compromised account. Also, software sandboxing techniques can quarantine a vulnerability to limit compromise of an entire application.Automatically generate reports for:Administrators of inactive accounts. Prompt administrators to set a maximum inactive time and automatically suspend accounts that exceed that threshold.Administrators of accounts with administrator privileges and suggest ways to reduce privilege sprawl.Automatically alert administrators of infrequently used services and provide recommendations for disabling them or implementing ACLs.
Insufficient internal network monitoring	Provide high-quality audit logs to customers at no extra charge. Audit logs are crucial for detecting and escalating potential security incidents. They are also crucial during an investigation of a suspected or confirmed security incident. Consider best practices such as providing easy integration with a security information and event management (SIEM) system with application programming interface (API) access that uses coordinated universal time (UTC), standard time zone formatting, and robust documentation techniques.
Lack of network segmentation	Ensure products are compatible with and tested in segmented network environments.
Poor patch management: Lack of regular patching	Take steps to eliminate entire classes of vulnerabilities by embedding security controls into product architecture from the start of development and throughout the SDLC by following best practices in NIST’s SSDF, SP 800-218.[54] Pay special attention to:Following secure coding practices [SSDF PW 5.1]. Use memory-safe programming languages where possible, parametrized queries, and web template languages.Conducting code reviews [SSDF PW 7.2, RV 1.2] against peer coding standards, checking for backdoors, malicious content, and logic flaws.Testing code to identify vulnerabilities and verify compliance with security requirements [SSDF PW 8.2].Ensure that published CVEs include root cause or common weakness enumeration (CWE) to enable industry-wide analysis of software security design flaws.
Poor patch management: Use of unsupported operating OSs and outdated firmware	Communicate the business risk of using unsupported OSs and firmware in plain, understandable language.
Bypass of system access controls	Provide sufficient detail in audit records to detect bypass of system controls and queries to monitor audit logs for traces of such suspicious activity (e.g., for when an essential step of an authentication or authorization flow is missing).
Weak or Misconfigured MFA Methods: Misconfigured Smart Cards or Tokens	Fully support MFA for all users, making MFA the default rather than an opt-in feature. Utilize threat modeling for authentication assertions and alternate credentials to examine how they could be abused to bypass MFA requirements.
Weak or Misconfigured MFA Methods: Lack of phishing-resistant MFA	Mandate MFA, ideally phishing-resistant, for privileged users and make MFA a default rather than an opt-in feature.[3]
Insufficient ACL on network shares and services	Enforce use of ACLs with default ACLs only allowing the minimum access needed, along with easy-to-use tools to regularly audit and adjust ACLs to the minimum access needed.
Poor credential hygiene: easily crackable passwords	Allow administrators to configure a password policy consistent with NIST’s guidelines—do not require counterproductive restrictions such as enforcing character types or the periodic rotation of passwords.[29]Allow users to use password managers to effortlessly generate and use secure, random passwords within products.
Poor credential hygiene: cleartext password disclosure	Salt and hash passwords using a secure hashing algorithm with high computational cost to make brute force cracking more difficult.
Unrestricted code execution	Support execution controls within operating systems and applications “out of the box” by default at no extra charge for all customers, to limit malicious actors’ ability to abuse functionality or launch unusual applications without administrator or informed user approval.

VALIDATE SECURITY CONTROLS

In addition to applying mitigations, NSA and CISA recommend exercising, testing, and validating your organization’s security program against the threat behaviors mapped to the MITRE ATT&CK for Enterprise framework in this advisory. NSA and CISA recommend 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 12–Table 21).
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 and NSA recommend continually testing your security program, at scale, in a production environment to ensure optimal performance against the MITRE ATT&CK techniques identified in this advisory.

LEARN FROM HISTORY

The misconfigurations described above are all too common in assessments and the techniques listed are standard ones leveraged by multiple malicious actors, resulting in numerous real network compromises. Learn from the weaknesses of others and implement the mitigations above properly to protect the network, its sensitive information, and critical missions.

WORKS CITED

Disclaimer of Endorsement

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

Trademarks

Active Directory, Microsoft, and Windows are registered trademarks of Microsoft Corporation.
MITRE ATT&CK is registered trademark and MITRE D3FEND is a trademark of The MITRE Corporation.
SoftPerfect is a registered trademark of SoftPerfect Proprietary Limited Company.
Telerik is a registered trademark of Progress Software Corporation.
VMware is a registered trademark of VMWare, Inc.
Zimbra is a registered trademark of Synacor, Inc.

Purpose

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

Contact

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

To report suspicious activity contact CISA’s 24/7 Operations Center at report@cisa.gov or (888) 282-0870. When available, please include the following information regarding the incident: date, time, and location of the incident; type of activity; number of people affected; type of equipment used for the activity; the name of the submitting company or organization; and a designated point of contact.

Appendix: MITRE ATT&CK Tactics and Techniques

See Table 12–Table 21 for all referenced threat actor tactics and techniques in this advisory.

Technique Title	ID	Use
Active Scanning: Vulnerability Scanning	T1595.002	Malicious actors scan victims for vulnerabilities that be exploited for initial access.
Gather Victim Host Information	T1592	Malicious actors gather information on victim client configurations and/or vulnerabilities through vulnerabilities scans and searching the web.
Gather Victim Identity Information: Credentials	T1589.001	Malicious actors find default credentials through searching the web.
Phishing for Information	T1598	Malicious actors masquerade as IT staff and convince a target user to provide their MFA code over the phone to gain access to email and other organizational resources.

Technique Title	ID	Use
External Remote Services	T1133	Malicious actors use default credentials for VPN access to internal networks.
Valid Accounts: Default Accounts	T1078.001	Malicious actors gain authenticated access to devices by finding default credentials through searching the web.Malicious actors use default credentials for VPN access to internal networks, and default administrative credentials to gain access to web applications and databases.
Exploit Public-Facing Application	T1190	Malicious actors exploit CVEs in Telerik UI, VM Horizon, Zimbra Collaboration Suite, and other applications for initial access to victim organizations.
Phishing	T1566	Malicious actors gain initial access to systems by phishing to entice end users to download and execute malicious payloads.
Trust Relationship	T1199	Malicious actors gain access to OT networks despite prior assurance that the networks were fully air gapped, with no possible connection to the IT network, by finding special purpose, forgotten, or even accidental network connections.

Technique Title	ID	Use
Software Deployment Tools	T1072	Malicious actors use default or captured credentials on software deployment tools to execute code and move laterally.
User Execution	T1204	Malicious actors gain initial access to systems by phishing to entice end users to download and execute malicious payloads or to run code on their workstations.
Command and Scripting Interpreter	T1059	Malicious actors use scripting languages to obscure their actions and bypass allowlisting.
Command and Scripting Interpreter: Visual Basic	T1059.005	Malicious actors use macros for initial access, persistence, and lateral movement.

Technique Title	ID	Use
Account Manipulation	T1098	Malicious actors reset built-in administrative accounts via predictable, forgotten password questions.

Technique Title	ID	Use
Valid Accounts	T1078	Malicious actors analyze topical and nested Active Directory groups to find privileged accounts to target.
Valid Accounts: Domain Accounts	T1078.002	Malicious actors obtain loaded domain credentials from printers and scanners and use them to move laterally from the network device.
Exploitation for Privilege Escalation	T1068	Malicious actors load vulnerable drivers and then exploit their known vulnerabilities to execute code in the kernel with the highest level of system privileges to completely compromise the device.

Technique Title	ID	Use
Obfuscated Files or Information: Command Obfuscation	T1027.010	Malicious actors often use scripting languages to obscure their actions.

Technique Title	ID	Use
Adversary-in-the-Middle	T1557	Malicious actors force a device to communicate through actor-controlled systems, so they can collect information or perform additional actions.
Adversary-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay	T1557.001	Malicious actors execute spoofing, poisoning, and relay techniques if Link-Local Multicast Name Resolution (LLMNR), NetBIOS Name Service (NBT-NS), and Server Message Block (SMB) services are enabled in a network.
Brute Force: Password Cracking	T1110.002	Malicious actors capture user hashes and leverage dictionary wordlists and rulesets to extract cleartext passwords.
Credentials from Password Stores	T1555	Malicious actors gain access to and crack credentials from PFX stores, enabling elevation of privileges and lateral movement within networks.
Multi-Factor Authentication Interception	T1111	Malicious actors can obtain password hashes for accounts enabled for MFA with smart codes or tokens and use the hash via PtH techniques.
Multi-Factor Authentication Request Generation	T1621	Malicious actors use “push bombing” against non-phishing resistant MFA to induce “MFA fatigue” in victims, gaining access to MFA authentication credentials or bypassing MFA, and accessing the MFA-protected system.
Steal Application Access Token	T1528	Malicious actors can steal administrator account credentials and the authentication token generated by Active Directory when the account is logged into a compromised host.
Steal or Forge Authentication Certificates	T1649	Unauthenticated malicious actors coerce an ADCS server to authenticate to an actor-controlled server, and then relay that authentication to the web certificate enrollment application to obtain a trusted illegitimate certificate.
Steal or Forge Kerberos Tickets: Golden Ticket	T1558.001	Malicious actors who have obtained authentication certificates can use the certificate for Active Directory authentication to obtain a Kerberos TGT.
Steal or Forge Kerberos Tickets: Kerberoasting	T1558.003	Malicious actors obtain and abuse valid Kerberos TGTs to elevate privileges and laterally move throughout an organization’s network.
Unsecured Credentials: Credentials in Files	T1552.001	Malicious actors find cleartext credentials that organizations or individual users store in spreadsheets, configuration files, and other documents.

Technique Title	ID	Use
Account Discovery	T1087	Malicious actors with valid domain credentials enumerate the AD to discover elevated accounts and where they are used.
File and Directory Discovery	T1083	Malicious actors use commands, such as `net share`, open source tools, such as SoftPerfect Network Scanner, or custom malware, such as CovalentStealer to discover and categorize files.Malicious actors search for text files, spreadsheets, documents, and configuration files in hopes of obtaining desired information, such as cleartext passwords.
Network Share Discovery	T1135	Malicious actors use commands, such as net share, open source tools, such as SoftPerfect Network Scanner, or custom malware, such as CovalentStealer, to look for shared folders and drives.

Technique Title	ID	Use
Exploitation of Remote Services	T1210	Malicious actors can exploit OS and firmware vulnerabilities to gain unauthorized network access, compromise sensitive data, and disrupt operations.
Remote Services: SMB/Windows Admin Shares	T1021.002	If SMB signing is not enforced, malicious actors can use name resolution poisoning to access remote systems.
Use Alternate Authentication Material: Application Access Token	T1550.001	Malicious actors with stolen administrator account credentials and AD authentication tokens can use them to operate with elevated permissions throughout the domain.
Use Alternate Authentication Material: Pass the Hash	T1550.002	Malicious actors collect hashes in a network and authenticate as a user without having access to the user’s cleartext password.

Technique Title	ID	Use
Data from Network Shared Drive	T1039	Malicious actors find sensitive information on network shares that could facilitate follow-on activity or provide opportunities for extortion.

Source :
https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-278a

The PQXDH Key Agreement Protocol

Revision 1, 2023-05-24 [PDF]

Ehren Kret, Rolfe Schmidt

1. Introduction

This document describes the “PQXDH” (or “Post-Quantum Extended Diffie-Hellman”) key agreement protocol. PQXDH establishes a shared secret key between two parties who mutually authenticate each other based on public keys. PQXDH provides post-quantum forward secrecy and a form of cryptographic deniability but still relies on the hardness of the discrete log problem for mutual authentication in this revision of the protocol.

PQXDH is designed for asynchronous settings where one user (“Bob”) is offline but has published some information to a server. Another user (“Alice”) wants to use that information to send encrypted data to Bob, and also establish a shared secret key for future communication.

2. Preliminaries

2.1. PQXDH parameters

An application using PQXDH must decide on several parameters:

Name	Definition
curve	A Montgomery curve for which XEdDSA [1] is specified, at present this is one of curve25519 or curve448
hash	A 256 or 512-bit hash function (e.g. SHA-256 or SHA-512)
info	An ASCII string identifying the application with a minimum length of 8 bytes
pqkem	A post-quantum key encapsulation mechanism (e.g. Crystals-Kyber-1024 [2])
EncodeEC	A function that encodes a curve public key into a byte sequence
DecodeEC	A function that decodes a byte sequence into a curve public key and is the inverse of EncodeEC
EncodeKEM	A function that encodes a pqkem public key into a byte sequence
DecodeKEM	A function that decodes a byte sequence into a pqkem public key and is the inverse of EncodeKEM

For example, an application could choose curve as curve25519, hash as SHA-512, info as “MyProtocol”, and pqkem as CRYSTALS-KYBER-1024.

The recommended implementation of EncodeEC consists of a single-byte constant representation of curve followed by little-endian encoding of the u-coordinate as specified in [3]. The single-byte representation of curve is defined by the implementer. Similarly the recommended implementation of DecodeEC reads the first byte to determine the parameter curve. If the first byte does not represent a recognized curve, the function fails. Otherwise it applies the little-endian decoding of the u-coordinate for curve as specified in [3].

The recommended implementation of EncodeKEM consists of a single-byte constant representation of pqkem followed by the encoding of PQKPK specified by pqkem. The single-byte representation of pqkem is defined by the implementer. Similarly the recommended implementation of DecodeKEM reads the first byte to determine the parameter pqkem. If the first byte does not represent a recognized key encapsulation mechanism, the function fails. Otherwise it applies the decoding specified by the selected key encapsulation mechanism.

2.2. Cryptographic notation

Throughout this document, all public keys have a corresponding private key, but to simplify descriptions we will identify key pairs by the public key and assume that the corresponding private key can be accessed by the key owner.

This document will use the following notation:

The concatenation of byte sequences X and Y is X || Y.
DH(PK1, PK2) represents a byte sequence which is the shared secret output from an Elliptic Curve Diffie-Hellman function involving the key pairs represented by public keys PK1 and PK2. The Elliptic Curve Diffie-Hellman function will be either the X25519 or X448 function from [3], depending on the curve parameter.
Sig(PK, M, Z) represents the byte sequence that is a curve XEdDSA signature on the byte sequence M which was created by signing M with PK’s corresponding private key and using 64 bytes of randomness Z. This signature verifies with public key PK. The signing and verification functions for XEdDSA are specified in [1].
KDF(KM) represents 32 bytes of output from the HKDF algorithm [4] using hash with inputs:
- HKDF input key material = F || KM, where KM is an input byte sequence containing secret key material, and F is a byte sequence containing 32 0xFF bytes if curve is curve25519, and 57 0xFF bytes if curve is curve448. As in in XEdDSA [1], F ensures that the first bits of the HKDF input key material are never a valid encoding of a scalar or elliptic curve point.
- HKDF salt = A zero-filled byte sequence with length equal to the hash output length, in bytes.
- HKDF info = The concatenation of string representations of the 4 PQXDH parameters info, curve, hash, and pqkem into a single string separated with ‘_’ such as “MyProtocol_CURVE25519_SHA-512_CRYSTALS-KYBER-1024”. The string representations of the PQXDH parameters are defined by the implementer.
(CT, SS) = PQKEM-ENC(PK) represents a tuple of the byte sequence that is the KEM ciphertext, CT, output by the algorithm pqkem together with the shared secret byte sequence SS encapsulated by the ciphertext using the public key PK.
PQKEM-DEC(PK, CT) represents the shared secret byte sequence SS decapsulated from a pqkem ciphertext using the private key counterpart of the public key PK used to encapsulate the ciphertext CT.

2.3. Roles

The PQXDH protocol involves three parties: Alice, Bob, and a server.

Alice wants to send Bob some initial data using encryption, and also establish a shared secret key which may be used for bidirectional communication.
Bob wants to allow parties like Alice to establish a shared key with him and send encrypted data. However, Bob might be offline when Alice attempts to do this. To enable this, Bob has a relationship with some server.
The server can store messages from Alice to Bob which Bob can later retrieve. The server also lets Bob publish some data which the server will provide to parties like Alice. The amount of trust placed in the server is discussed in Section 4.9.

In some systems the server role might be divided between multiple entities, but for simplicity we assume a single server that provides the above functions for Alice and Bob.

2.4. Elliptic Curve Keys

PQXDH uses the following elliptic curve public keys:

Name	Definition
IK_A	Alice’s identity key
IK_B	Bob’s identity key
EK_A	Alice’s ephemeral key
SPK_B	Bob’s signed prekey
(OPK_B¹, OPK_B², …)	Bob’s set of one-time prekeys

The elliptic curve public keys used within a PQXDH protocol run must either all be in curve25519 form, or they must all be in curve448 form, depending on the curve parameter [3].

Each party has a long-term identity elliptic curve public key (IK_A for Alice, IK_B for Bob).

Bob also has a signed prekey SPK_B, which he changes periodically and signs each time with IK_B, and a set of one-time prekeys (OPK_B¹, OPK_B², …), which are each used in a single PQXDH protocol run. (“Prekeys” are so named because they are essentially protocol messages which Bob publishes to the server prior to Alice beginning the protocol run.) These keys will be uploaded to the server as described in Section 3.2.

During each protocol run, Alice generates a new ephemeral key pair with public key EK_A.

2.5. Post-Quantum Key Encapsulation Keys

PQXDH uses the following post-quantum key encapsulation public keys:

Name	Definition
PQSPK_B	Bob’s signed last-resort pqkem prekey
(PQOPK_B¹, PQOPK_B², …)	Bob’s set of signed one-time pqkem prekeys

The pqkem public keys used within a PQXDH protocol run must all use the same pqkem parameter.

Bob has a signed last-resort post-quantum prekey PQSPK_B, which he changes periodically and signs each time with IK_B, and a set of signed one-time prekeys (PQOPK_B¹, PQOPK_B², …) which are also signed with IK_B and each used in a single PQXDH protocol run. These keys will be uploaded to the server as described in Section 3.2. The name “last-resort” refers to the fact that the last-resort prekey is only used when one-time pqkem prekeys are not available. This can happen when the number of prekey bundles downloaded for Bob exceeds the number of one-time pqkem prekeys Bob has uploaded (see Section 3 for details about the role of the server).

3. The PQXDH protocol

3.1. Overview

PQXDH has three phases:

Bob publishes his elliptic curve identity key, elliptic curve prekeys, and pqkem prekeys to a server.
Alice fetches a “prekey bundle” from the server, and uses it to send an initial message to Bob.
Bob receives and processes Alice’s initial message.

The following sections explain these phases.

3.2. Publishing keys

Bob generates a sequence of 64-byte random values Z_SPK, Z_PQSPK, Z₁, Z₂, … and publishes a set of keys to the server containing:

Bob’s curve identity key IK_B
Bob’s signed curve prekey SPK_B
Bob’s signature on the curve prekey Sig(IK_B, EncodeEC(SPK_B), Z_SPK)
Bob’s signed last-resort pqkem prekey PQSPK_B
Bob’s signature on the pqkem prekey Sig(IK_B, EncodeKEM(PQSPK_B), Z_PQSPK)
A set of Bob’s one-time curve prekeys (OPK_B¹, OPK_B², OPK_B³, …)
A set of Bob’s signed one-time pqkem prekeys (PQOPK_B¹, PQOPK_B², PQOPK_B³, …)
The set of Bob’s signatures on the signed one-time pqkem prekeys (Sig(IK_B, EncodeKEM(PQOPK_B¹), Z₁), Sig(IK_B, EncodeKEM(PQOPK_B²), Z₂), Sig(IK_B, EncodeKEM(PQOPK_B³), Z₃), …)

Bob only needs to upload his identity key to the server once. However, Bob may upload new one-time prekeys at other times (e.g. when the server informs Bob that the server’s store of one-time prekeys is getting low).

For both the signed curve prekey and the signed last-resort pqkem prekey, Bob will upload a new prekey along with its signature using IK_B at some interval (e.g. once a week or once a month). The new signed prekey and its signatures will replace the previous values.

After uploading a new pair of signed curve and signed last-resort pqkem prekeys, Bob may keep the private key corresponding to the previous pair around for some period of time to handle messages using it that may have been delayed in transit. Eventually, Bob should delete this private key for forward secrecy (one-time prekey private keys will be deleted as Bob receives messages using them; see Section 3.4).

3.3. Sending the initial message

To perform a PQXDH key agreement with Bob, Alice contacts the server and fetches a “prekey bundle” containing the following values:

Bob’s curve identity key IK_B
Bob’s signed curve prekey SPK_B
Bob’s signature on the curve prekey Sig(IK_B, EncodeEC(SPK_B), Z_SPK)
One of either Bob’s signed one-time pqkem prekey PQOPK_Bⁿ or Bob’s last-resort signed pqkem prekey PQSPK_B if no signed one-time pqkem prekey remains. Call this key PQPK_B.
Bob’s signature on the pqkem prekey Sig(IK_B, EncodeKEM(PQPK_B), Z_PQPK)
(Optionally) Bob’s one-time curve prekey OPK_Bⁿ

The server should provide one of Bob’s curve one-time prekeys if one exists and then delete it. If all of Bob’s curve one-time prekeys on the server have been deleted, the bundle will not contain a one-time curve prekey element.

The server should prefer to provide one of Bob’s pqkem one-time signed prekeys PQOPK_Bⁿ if one exists and then delete it. If all of Bob’s pqkem one-time signed prekeys on the server have been deleted, the bundle will instead contain Bob’s pqkem last-resort signed prekey PQSPK_B.

Alice verifies the signatures on the prekeys. If any signature check fails, Alice aborts the protocol. Otherwise, if all signature checks pass, Alice then generates an ephemeral curve key pair with public key EK_A. Alice additionally generates a pqkem encapsulated shared secret:

    (CT, SS) = PQKEM-ENC(PQPK_B)
               shared secret SS
               ciphertext CT

If the bundle does not contain a curve one-time prekey, she calculates:

    DH₁ = DH(IK_A, SPK_B)
    DH₂ = DH(EK_A, IK_B)
    DH₃ = DH(EK_A, SPK_B)
    SK = KDF(DH₁ || DH₂ || DH₃ || SS)

If the bundle does contain a curve one-time prekey, the calculation is modified to include an additional DH:

DH₄ = DH(EK_A, OPK_B)
SK = KDF(DH₁ || DH₂ || DH₃ || DH₄ || SS)

After calculating SK, Alice deletes her ephemeral private key, the DH outputs, the shared secret SS, and the ciphertext CT.

Alice then calculates an “associated data” byte sequence AD that contains identity information for both parties:

AD = EncodeEC(IK_A) || EncodeEC(IK_B)

Alice may optionally append additional information to AD, such as Alice and Bob’s usernames, certificates, or other identifying information.

Alice then sends Bob an initial message containing:

Alice’s identity key IK_A
Alice’s ephemeral key EK_A
The pqkem ciphertext CT encapsulating SS for PQPK_B
Identifiers stating which of Bob’s prekeys Alice used
An initial ciphertext encrypted with some AEAD encryption scheme [5] using AD as associated data and using an encryption key which is either SK or the output from some cryptographic PRF keyed by SK.

The initial ciphertext is typically the first message in some post-PQXDH communication protocol. In other words, this ciphertext typically has two roles, serving as the first message within some post-PQXDH protocol, and as part of Alice’s PQXDH initial message.

The initial message must be encoded in an unambiguous format to avoid confusion of the message items by the recipient.

After sending this, Alice may continue using SK or keys derived from SK within the post-PQXDH protocol for communication with Bob, subject to the security considerations discussed in Section 4.

3.4. Receiving the initial message

Upon receiving Alice’s initial message, Bob retrieves Alice’s identity key and ephemeral key from the message. Bob also loads his identity private key and the private key(s) corresponding to the signed prekeys and one-time prekeys Alice used.

Using these keys, Bob calculates PQKEM-DEC(PQPK_B, CT) as the shared secret SS and repeats the DH and KDF calculations from the previous section to derive SK, and then deletes the DH values and SS values.

Bob then constructs the AD byte sequence using IK_A and IK_B as described in the previous section. Finally, Bob attempts to decrypt the initial ciphertext using SK and AD. If the initial ciphertext fails to decrypt, then Bob aborts the protocol and deletes SK.

If the initial ciphertext decrypts successfully, the protocol is complete for Bob. For forward secrecy, Bob deletes the ciphertext and any one-time prekey private key that was used. Bob may then continue using SK or keys derived from SK within the post-PQXDH protocol for communication with Alice subject to the security considerations discussed in Section 4.

4. Security considerations

The security of the composition of X3DH [6] with the Double Ratchet [7] was formally studied in [8] and proven secure under the Gap Diffie-Hellman assumption (GDH)[9]. PQXDH composed with the Double Ratchet retains this security against an adversary without access to a quantum computer, but strengthens the security of the initial handshake to require the solution of both GDH and Module-LWE [10]. The remainder of this section discusses an incomplete list of further security considerations.

4.1. Authentication

Before or after a PQXDH key agreement, the parties may compare their identity public keys IK_A and IK_B through some authenticated channel. For example, they may compare public key fingerprints manually, or by scanning a QR code. Methods for doing this are outside the scope of this document.

Authentication in PQXDH is not quantum-secure. In the presence of an active quantum adversary, the parties receive no cryptographic guarantees as to who they are communicating with. Post-quantum secure deniable mutual authentication is an open research problem which we hope to address with a future revision of this protocol.

If authentication is not performed, the parties receive no cryptographic guarantee as to who they are communicating with.

4.2. Protocol replay

If Alice’s initial message doesn’t use a one-time prekey, it may be replayed to Bob and he will accept it. This could cause Bob to think Alice had sent him the same message (or messages) repeatedly.

To mitigate this, a post-PQXDH protocol may wish to quickly negotiate a new encryption key for Alice based on fresh random input from Bob. This is the typical behavior of Diffie-Hellman-based ratcheting protocols [7].

Bob could attempt other mitigations, such as maintaining a blacklist of observed messages, or replacing old signed prekeys more rapidly. Analyzing these mitigations is beyond the scope of this document.

4.3. Replay and key reuse

Another consequence of the replays discussed in the previous section is that a successfully replayed initial message would cause Bob to derive the same SK in different protocol runs.

For this reason, any post-PQXDH protocol that uses SK to derive encryption keys MUST take measures to prevent catastrophic key reuse. For example, Bob could use a DH-based ratcheting protocol to combine SK with a freshly generated DH output to get a randomized encryption key [7].

4.4. Deniability

Informally, cryptographic deniability means that a protocol neither gives its participants a publishable cryptographic proof of the contents of their communication nor proof of the fact that they communicated. PQXDH, like X3DH, aims to provide both Alice and Bob deniablilty that they communicated with each other in a context where a “judge” who may have access to one or more party’s secret keys is presented with a transcript allegedly created by communication between Alice and Bob.

We focus on offline deniability because if either party is collaborating with a third party during protocol execution, they will be able to provide proof of their communication to such a third party. This limitation on “online” deniability appears to be intrinsic to the asynchronous setting [11].

PQXDH has some forms of cryptographic deniability. Motivated by the goals of X3DH, Brendel et al. [12] introduce a notion of 1-out-of-2 deniability for semi-honest parties and a “big brother” judge with access to all parties’ secret keys. Since either Alice or Bob can create a fake transcript using only their own secret keys, PQXDH has this deniability property. Vatandas, et al. [13] prove that X3DH is deniable in a different sense subject to certain “Knowledge of Diffie-Hellman Assumptions”. PQXDH is deniable in this sense for Alice, subject to the same assumptions, and we conjecture that it is deniable for Bob subject to an additional Plaintext Awareness (PA) assumption for pqkem. We note that Kyber uses a variant of the Fujisaki-Okamoto transform with implicit rejection [14] and is therefore not PA as is. However, in PQXDH, an AEAD ciphertext encrypted with the session key is always sent along with the Kyber ciphertext. This should offer the same guarantees as PA. We encourage the community to investigate the precise deniability properties of PQXDH.

These assertions all pertain to deniability in the classical setting. As discussed in [15] we expect that for future revisions of this protocol (that provide post-quantum mutual authentication) assertions about deniability against semi-honest quantum advsersaries will hold. Deniability in the face of malicious quantum adversaries requires further research.

4.5. Signatures

It might be tempting to omit the prekey signature after observing that mutual authentication and forward secrecy are achieved by the DH calculations. However, this would allow a “weak forward secrecy” attack: A malicious server could provide Alice a prekey bundle with forged prekeys, and later compromise Bob’s IK_B to calculate SK.

Alternatively, it might be tempting to replace the DH-based mutual authentication (i.e. DH₁ and DH₂) with signatures from the identity keys. However, this reduces deniability, increases the size of initial messages, and increases the damage done if ephemeral or prekey private keys are compromised, or if the signature scheme is broken.

4.6. Key compromise

Compromise of a party’s private keys has a disastrous effect on security, though the use of ephemeral keys and prekeys provides some mitigation.

Compromise of a party’s identity private key allows impersonation of that party to others. Compromise of a party’s prekey private keys may affect the security of older or newer SK values, depending on many considerations.

A full analysis of all possible compromise scenarios is outside the scope of this document, however a partial analysis of some plausible scenarios is below:

If either an elliptic curve one-time prekey (OPK_B) or a post-quantum key encapsulation one-time prekey (PQOPK_B) are used for a protocol run and deleted as specified, then a compromise of Bob’s identity key and prekey private keys at some future time will not compromise the older SK.
If one-time prekeys were not used for a protocol run, then a compromise of the private keys for IK_B, SPK_B, and PQSPK_B from that protocol run would compromise the SK that was calculated earlier. Frequent replacement of signed prekeys mitigates this, as does using a post-PQXDH ratcheting protocol which rapidly replaces SK with new keys to provide fresh forward secrecy [7].
Compromise of prekey private keys may enable attacks that extend into the future, such as passive calculation of SK values, and impersonation of arbitrary other parties to the compromised party (“key-compromise impersonation”). These attacks are possible until the compromised party replaces his compromised prekeys on the server (in the case of passive attack); or deletes his compromised signed prekey’s private key (in the case of key-compromise impersonation).

4.7. Passive quantum adversaries

PQXDH is designed to prevent “harvest now, decrypt later” attacks by adversaries with access to a quantum computer capable of computing discrete logarithms in curve.

If an attacker has recorded the public information and the message from Alice to Bob, even access to a quantum computer will not compromise SK.
If a post-quantum key encapsulation one-time prekey (PQOPK_B) is used for a protocol run and deleted as specified then compromise after deletion and access to a quantum computer at some future time will not compromise the older SK.
If post-quantum one-time prekeys were not used for a protocol run, then access to a quantum computer and a compromise of the private key for PQSPK_B from that protocol run would compromise the SK that was calculated earlier. Frequent replacement of signed prekeys mitigates this, as does using a post-PQXDH ratcheting protocol which rapidly replaces SK with new keys to provide fresh forward secrecy [7].

4.8. Active quantum adversaries

PQXDH is not designed to provide protection against active quantum attackers. An active attacker with access to a quantum computer capable of computing discrete logarithms in curve can compute DH(PK₁, PK₂) and Sig(PK, M, Z) for all elliptic curve keys PK₁, PK₂, and PK. This allows an attacker to impersonate Alice by using the quantum computer to compute the secret key corresponding to PK_A then continuing with the protocol. A malicious server with access to such a quantum computer could impersonate Bob by generating new key pairs PQSPK’_B and PQOPK’_B, computing the secret key corresponding to PK_B, then using PK_B to sign the newly generated post-quantum KEM keys and delivering these attacker-generated keys in place of Bob’s post-quantum KEM key when Alice requests a prekey bundle.

It is tempting to consider adding a post-quantum identity key that Bob could use to sign the post-quantum prekeys. This would prevent the malicious server attack described above and provide Alice a cryptographic guarantee that she is communicating with Bob, but it does not provide mutual authentication. Bob does not have any cryptographic guarantee about who he is communicating with. The post-quantum KEM and signature schemes being standardized by NIST [16] do not provide a mechanism for post-quantum deniable mutual authentication, although this can be achieved through the use of a post-quantum ring signature or designated verifier signature [12], [15]. We urge the community to work toward standardization of these or other mechanisms that will allow deniable mutual authentication.

4.9. Server trust

A malicious server could cause communication between Alice and Bob to fail (e.g. by refusing to deliver messages).

If Alice and Bob authenticate each other as in Section 4.1, then the only additional attack available to the server is to refuse to hand out one-time prekeys, causing forward secrecy for SK to depend on the signed prekey’s lifetime (as analyzed in Section 4.6).

This reduction in initial forward secrecy could also happen if one party maliciously drains another party’s one-time prekeys, so the server should attempt to prevent this (e.g. with rate limits on fetching prekey bundles).

4.10. Identity binding

Authentication as in Section 4.1 does not necessarily prevent an “identity misbinding” or “unknown key share” attack.

This results when an attacker (“Charlie”) falsely presents Bob’s identity key fingerprint to Alice as his (Charlie’s) own, and then either forwards Alice’s initial message to Bob, or falsely presents Bob’s contact information as his own. The effect of this is that Alice thinks she is sending an initial message to Charlie when she is actually sending it to Bob.

To make this more difficult the parties can include more identifying information into AD, or hash more identifying information into the fingerprint, such as usernames, phone numbers, real names, or other identifying information. Charlie would be forced to lie about these additional values, which might be difficult.

However, there is no way to reliably prevent Charlie from lying about additional values, and including more identity information into the protocol often brings trade-offs in terms of privacy, flexibility, and user interface. A detailed analysis of these trade-offs is beyond the scope of this document.

4.11. Risks of weak randomness sources

In addition to concerns about the generation of the keys themselves, the security of the PQKEM shared secret relies on the random source available to Alice’s machine at the time of running the PQKEM-ENC operation. This leads to a situation similar to what we face with a Diffie-Hellman exchange. For both Diffie-Hellman and Kyber, if Alice has weak entropy then the resulting shared secret will have low entropy when conditioned on Bob’s public key. Thus both the classical and post-quantum security of SK depend on the strength of Alice’s random source.

Kyber hashes Bob’s public key with Alice’s random bits to generate the shared secret, making Bob’s key contributory, as it is with a Diffie-Hellman key exchange. This does not reduce the dependence on Alice’s entropy source, as described above, but it does limit Alice’s ability to control the post-quantum shared secret. Not all KEMs make Bob’s key contributory and this is a property to consider when selecting pqkem.

5. IPR

This document is hereby placed in the public domain.

6. Acknowledgements

The PQXDH protocol was developed by Ehren Kret and Rolfe Schmidt as an extension of the X3DH protocol [6] by Moxie Marlinspike and Trevor Perrin. Thanks to Trevor Perrin for discussions on the design of this protocol.

Thanks to Bas Westerbaan, Chris Peikert, Daniel Collins, Deirdre Connolly, John Schanck, Jon Millican, Jordan Rose, Karthik Bhargavan, Loïs Huguenin-Dumittan, Peter Schwabe, Rune Fiedler, Shuichi Katsumata, Sofía Celi, and Yo’av Rieck for helpful discussions and editorial feedback.

Thanks to the Kyber team [17] for their work on the Kyber key encapsulation mechanism.

7. References

[1]

T. Perrin, “The XEdDSA and VXEdDSA Signature Schemes,” 2016. https://signal.org/docs/specifications/xeddsa/

[2]

“Module-lattice-based key-encapsulation mechanism standard.” https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.ipd.pdf

[3]

A. Langley, M. Hamburg, and S. Turner, “Elliptic Curves for Security.” Internet Engineering Task Force; RFC 7748 (Informational); IETF, Jan-2016. http://www.ietf.org/rfc/rfc7748.txt

[4]

H. Krawczyk and P. Eronen, “HMAC-based Extract-and-Expand Key Derivation Function (HKDF).” Internet Engineering Task Force; RFC 5869 (Informational); IETF, May-2010. http://www.ietf.org/rfc/rfc5869.txt

[5]

P. Rogaway, “Authenticated-encryption with Associated-data,” in Proceedings of the 9th ACM Conference on Computer and Communications Security, 2002. http://web.cs.ucdavis.edu/~rogaway/papers/ad.pdf

[6]

M. Marlinspike and T. Perrin, “The X3DH Key Agreement Protocol,” 2016. https://signal.org/docs/specifications/x3dh/

[7]

T. Perrin and M. Marlinspike, “The Double Ratchet Algorithm,” 2016. https://signal.org/docs/specifications/doubleratchet/

[8]

K. Cohn-Gordon, C. Cremers, B. Dowling, L. Garratt, and D. Stebila, “A formal security analysis of the signal messaging protocol,” J. Cryptol., vol. 33, no. 4, 2020. https://doi.org/10.1007/s00145-020-09360-1

[9]

T. Okamoto and D. Pointcheval, “The gap-problems: A new class of problems for the security of cryptographic schemes,” in Proceedings of the 4th international workshop on practice and theory in public key cryptography: Public key cryptography, 2001.

[10]

A. Langlois and D. Stehlé, “Worst-case to average-case reductions for module lattices,” Des. Codes Cryptography, vol. 75, no. 3, Jun. 2015. https://doi.org/10.1007/s10623-014-9938-4

[11]

N. Unger and I. Goldberg, “Deniable Key Exchanges for Secure Messaging,” in Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security, 2015. https://cypherpunks.ca/~iang/pubs/dake-ccs15.pdf

[12]

J. Brendel, R. Fiedler, F. Günther, C. Janson, and D. Stebila, “Post-quantum asynchronous deniable key exchange and the signal handshake,” in Public-key cryptography – PKC 2022 – 25th IACR international conference on practice and theory of public-key cryptography, virtual event, march 8-11, 2022, proceedings, part II, 2022, vol. 13178. https://doi.org/10.1007/978-3-030-97131-1_1

[13]

N. Vatandas, R. Gennaro, B. Ithurburn, and H. Krawczyk, “On the cryptographic deniability of the signal protocol,” in Applied cryptography and network security – 18th international conference, ACNS 2020, rome, italy, october 19-22, 2020, proceedings, part II, 2020, vol. 12147. https://doi.org/10.1007/978-3-030-57878-7_10

[14]

D. Hofheinz, K. Hövelmanns, and E. Kiltz, “A modular analysis of the fujisaki-okamoto transformation,” in Theory of cryptography – 15th international conference, TCC 2017, baltimore, MD, USA, november 12-15, 2017, proceedings, part I, 2017, vol. 10677. https://doi.org/10.1007/978-3-319-70500-2_12

[15]

K. Hashimoto, S. Katsumata, K. Kwiatkowski, and T. Prest, “An efficient and generic construction for signal’s handshake (X3DH): Post-quantum, state leakage secure, and deniable,” J. Cryptol., vol. 35, no. 3, 2022. https://doi.org/10.1007/s00145-022-09427-1

[16]

NIST, “Post-quantum cryptography.” https://csrc.nist.gov/Projects/post-quantum-cryptography

[17]

“Kyber key encapsulation mechanism.” https://pq-crystals.org/kyber/

Source :
https://signal.org/docs/specifications/pqxdh/

Top 5 Security Misconfigurations Causing Data Breaches in 2023

Edward Kost
updated May 15, 2023

Security misconfigurations are a common and significant cybersecurity issue that can leave businesses vulnerable to data breaches. According to the latest data breach investigation report by IBM and the Ponemon Institute, the average cost of a breach has peaked at US$4.35 million. Many data breaches are caused by avoidable errors like security misconfiguration. By following the tips in this article, you could identify and address a security error that could save you millions of dollars in damages.

Learn how UpGuard can help you detect data breach risks >

What is a Security Misconfiguration?

A security misconfiguration occurs when a system, application, or network device’s settings are not correctly configured, leaving it exposed to potential cyber threats. This could be due to default configurations left unchanged, unnecessary features enabled, or permissions set too broadly. Hackers often exploit these misconfigurations to gain unauthorized access to sensitive data, launch malware attacks, or carry out phishing attacks, among other malicious activities.

What Causes Security Misconfigurations?

Security misconfigurations can result from various factors, including human error, lack of awareness, and insufficient security measures. For instance, employees might configure systems without a thorough understanding of security best practices, security teams might overlook crucial security updates due to the growing complexity of cloud services and infrastructures.

Additionally, the rapid shift to remote work during the pandemic has increased the attack surface for cybercriminals, making it more challenging for security teams to manage and monitor potential vulnerabilities.

List of Common Types of Security Configurations Facilitating Data Breaches

Some common types of security misconfigurations include:

1. Default Settings

With the rise of cloud solutions such as Amazon Web Services (AWS) and Microsoft Azure, companies increasingly rely on these platforms to store and manage their data. However, using cloud services also introduces new security risks, such as the potential for misconfigured settings or unauthorized access.

A prominent example of insecure default software settings that could have facilitated a significant breach is the Microsoft Power Apps data leak incident of 2021. By default, Power Apps portal data feeds were set to be accessible to the public.

Unless developers specified for OData feeds to be set to private, virtually anyone could access the backend databases of applications built with Power Apps. UpGuard researchers located the exposure and notified Microsoft, who promptly addressed the leak. UpGuard’s detection helped Microsoft avoid a large-scale breach that could have potentially compromised 38 million records.

Read this whitepaper to learn how to prevent data breaches >

2. Unnecessary Features

Enabling features or services not required for a system’s operation can increase its attack surface, making it more vulnerable to threats. Some examples of unnecessary product features include remote administration tools, file-sharing services, and unused network ports. To mitigate data breach risks, organizations should conduct regular reviews of their systems and applications to identify and disable or remove features that are not necessary for their operations.

Additionally, organizations should practice the principle of least functionality, ensuring that systems are deployed with only the minimal set of features and services required for their specific use case.

3. Insecure Permissions

Overly permissive access controls can allow unauthorized users to access sensitive data or perform malicious actions. To address this issue, organizations should implement the principle of least privilege, granting users the minimum level of access necessary to perform their job functions. This can be achieved through proper role-based access control (RBAC) configurations and regular audits of user privileges. Additionally, organizations should ensure that sensitive data is appropriately encrypted both in transit and at rest, further reducing the risk of unauthorized access.

4. Outdated Software

Failing to apply security patches and updates can expose systems to known vulnerabilities. To protect against data breaches resulting from outdated software, organizations should have a robust patch management program in place. This includes regularly monitoring for available patches and updates, prioritizing their deployment based on the severity of the vulnerabilities being addressed, and verifying the successful installation of these patches.

Additionally, organizations should consider implementing automated patch management solutions and vulnerability scanning tools to streamline the patching process and minimize the risk of human error.

5. Insecure API Configurations

APIs that are not adequately secured can allow threat actors to access sensitive information or manipulate systems. API misconfigurations – like the one that led to T-Mobile’s 2023 data breach, are becoming more common. As more companies move their services to the cloud, securing these APIs and preventing the data leaks they facilitate is becoming a bigger challenge.

To mitigate the risks associated with insecure API configurations, organizations should implement strong authentication and authorization mechanisms, such as OAuth 2.0 or API keys, to ensure only authorized clients can access their APIs. Additionally, organizations should conduct regular security assessments and penetration testing to identify and remediate potential vulnerabilities in their API configurations.

Finally, adopting a secure software development lifecycle (SSDLC) and employing API security best practices, such as rate limiting and input validation, can help prevent data breaches stemming from insecure APIs.

Learn how UpGuard protects against third-party breaches >

How to Avoid Security Misconfigurations Impacting Your Data Breach Resilience

To protect against security misconfigurations, organizations should:

1. Implement a Comprehensive Security Policy

Implement a cybersecurity policy covering all system and application configuration aspects, including guidelines for setting permissions, enabling features, and updating software.

2. Implement a Cyber Threat Awareness Program

An essential security measure that should accompany the remediation of security misconfigurations is employee threat awareness training. Of those who recently suffered cloud security breaches, 55% of respondents identified human error as the primary cause.

With your employees equipped to correctly respond to common cybercrime tactics that preceded data breaches, such as social engineering attacks and social media phishing attacks, your business could avoid a security incident should threat actors find and exploit an overlooked security misconfiguration.

Phishing attacks involve tricking individuals into revealing sensitive information that could be used to compromise an account or facilitate a data breach. During these attacks, threat actors target account login credentials, credit card numbers, and even phone numbers to exploit Multi-Factor authentication.

Learn the common ways MFA can be exploited >

Phishing attacks are becoming increasingly sophisticated, with cybercriminals using automation and other tools to target large numbers of individuals.

Here’s an example of a phishing campaign where a hacker has built a fake login page to steal a customer’s banking credentials. As you can see, the fake login page looks almost identical to the actual page, and an unsuspecting eye will not notice anything suspicious.

‍

Because this poor cybersecurity habit is common amongst the general population, phishing campaigns could involve fake login pages for social media websites, such as LinkedIn, popular websites like Amazon, and even SaaS products. Hackers implementing such tactics hope the same credentials are used for logging into banking websites.

Cyber threat awareness training is the best defense against phishing, the most common attack vector leading to data breaches and ransomware attacks.

Because small businesses often lack the resources and expertise of larger companies, they usually don’t have the budget for additional security programs like awareness training. This is why, according to a recent report, 61% of small and medium-sized businesses experienced at least one cyber attack in the past year, and 40% experienced eight or more attacks.

Luckily, with the help of ChatGPT, small businesses can implement an internal threat awareness program at a fraction of the cost. Industries at a heightened risk of suffering a data breach, such as healthcare, should especially prioritize awareness of the cyber threat landscape.

Learn how to implement an internal cyber threat awareness campaign >

3. Use Multi-Factor Authentication

MFA and strong access management control to limit unauthorized access to sensitive systems and data.

Previously compromised passwords are often used to hack into accounts. MFA adds additional authentication protocols to the login process, making it difficult to compromise an account, even if hackers get their hands on a stolen password

4. Use Strong Access Management Controls

Identity and Access Management (IAM) systems ensure users only have access to the data and applications they need to do their jobs and that permissions are revoked when an employee leaves the company or changes roles.

The 2023 Thales Dara Threat Report found that 28% of respondents found IAM to be the most effective data security control preventing personal data compromise.

5. Keep All Software Patched and Updated

Keep all environments up-to-date by promptly applying patches and updates. Consider patching a “golden image” and deploying it across your environment. Perform regular scans and audits to identify potential security misconfigurations and missing patches.

An attack surface monitoring solution, such as UpGuard, can detect vulnerable software versions that have been impacted by zero-days and other known security flaws.

6. Deploy Security Tools

Security tools, such as intrusion detection and prevention systems (IDPS) and security information and event management (SIEM) solutions, to monitor and respond to potential threats.

It’s essential also to implement tools to defend against tactics often used to complement data breach attempts, for example. DDoS attacks – a type of attack where a server is flooded with fake traffic to force it offline, allowing hackers to exploit security misconfigurations during the chaos of excessive downtime.

Another important security tool is a data leak detection solution for discovering compromised account credentials published on the dark web. These credentials, if exploited, allow hackers to compress the data breach lifecycle, making these events harder to detect and intercept.

Dara leaks compressing the data breach lifecycle.

Learn how to detect and prevent data leaks >

7. Implement a Zero-Trust Architecture

One of the main ways that companies can protect themselves from cloud-related security threats is by implementing a Zero Trust security architecture. This approach assumes all requests for access to resources are potentially malicious and, therefore, require additional verification before granting access.

Learn how to implement a Zero-Trust Architecture >

A Zero-Trust approach to security assumes that all users, devices, and networks are untrustworthy until proven otherwise.

8. Develop a Repeatable Hardening Process

Establish a process that can be easily replicated to ensure consistent, secure configurations across production, development, and QA environments. Use different passwords for each environment and automate the process for efficient deployment. Be sure to address IoT devices in the hardening process.

These devices tend to be secured with their default factory passwords, making them highly vulnerable to DDoS attacks.

9. Implement a Secure Application Architecture

Design your application architecture to obfuscate general access to sensitive resources using the principle of network segmentation.

Learn more about network segmentation >

Cloud infrastructure has become a significant cybersecurity issue in the last decade. Barely a month goes by without a major security breach at a cloud service provider or a large corporation using cloud services.

10. Maintain a Structured Development Cycle

Facilitate security testing during development by adhering to a well-organized development process. Following cybersecurity best practices this early in the development process sets the foundation for a resilient security posture that will protect your data even as your company scales.

Implement a secure software development lifecycle (SSDLC) that incorporates security checkpoints at each stage of development, including requirements gathering, design, implementation, testing, and deployment. Additionally, train your development team in secure coding practices and encourage a culture of security awareness to help identify and remediate potential vulnerabilities before they make their way into production environments.

11. Review Custom Code

If using custom code, employ a static code security scanner before integrating it into the production environment. These scanners can automatically analyze code for potential vulnerabilities and compliance issues, reducing the risk of security misconfigurations.

Additionally, have security professionals conduct manual reviews and dynamic testing to identify issues that may not be detected by automated tools. This combination of automated and manual testing ensures that custom code is thoroughly vetted for security risks before deployment.

12. Utilize a Minimal Platform

Remove unused features, insecure frameworks, and unnecessary documentation, samples, or components from your platform. Adopt a “lean” approach to your software stack by only including components that are essential for your application’s functionality.

This reduces the attack surface and minimizes the chances of security misconfigurations. Furthermore, keep an inventory of all components and their associated security risks to better manage and mitigate potential vulnerabilities.

13. Review Cloud Storage Permissions

Regularly examine permissions for cloud storage, such as S3 buckets, and incorporate security configuration updates and reviews into your patch management process. This process should be a standard inclusion across all cloud security measures. Ensure that access controls are properly configured to follow the principle of least privilege, and encrypt sensitive data both in transit and at rest.

Implement monitoring and alerting mechanisms to detect unauthorized access or changes to your cloud storage configurations. By regularly reviewing and updating your cloud storage permissions, you can proactively identify and address potential security misconfigurations, thereby enhancing your organization’s data breach resilience.

How UpGuard Can Help

UpGuard’s IP monitoring feature monitors all IP addresses associated with your attack surface for security issues, misconfigurations, and vulnerabilities. UpGuard’s attack surface monitoring solution can also identify common misconfigurations and security issues shared across your organization and its subsidiaries, including the exposure of WordPress user names, vulnerable server versions, and a range of attack vectors facilitating first and third data breaches.

UpGuard’s Risk Profile feature displays security vulnerabilities associated with end-of-life software.

To further expand its mitigation of data breach threat categories, UpGuard offersa data leak detection solution that scans ransomware blogs on the dark web for compromised credentials, and any leaked data could help hackers breach your network and sensitive resources.

UpGuard's ransomware blog detection feature. — UpGuard’s ransomware blog detection feature.

Source :
https://www.upguard.com/blog/security-misconfigurations-causing-data-breaches

Cybersecurity and Social Responsibility: Ethical Considerations

Kyle Chin
updated Aug 21, 2023

Cybersecurity is necessary to protect data from criminals. However, the world of cybersecurity is not so simple. Therefore, a discussion of cybersecurity ethics needs to examine the morality of businesses collecting, processing, using, and storing data.

How cybersecurity professionals affect security measures is also worth exploring. Businesses and individuals should ask themselves whether the ends justify the means and to what extent they are willing to sacrifice data privacy for data protection.

This post underlines the ethical concerns and cybersecurity issues surrounding information security policies, procedures, systems, and teams and how they ought to contribute to the well-being of consumers.

What Are Ethics in Cybersecurity?

Ethics can be described as ideals and values that determine how people live and, increasingly, how businesses and their employees work.

While it is far from the technical specifications of networks and device configurations, it is an increasingly important part of business operations. It can be codified and included in an organization’s framework, determining acceptable behavior throughout the company in any scenario.

One of the main benefits of a strong ethical foundation for a business is that it will have a moral compass to help make ethical decisions in a rapidly changing business environment. The world is experiencing massive changes in information technology with advancements in artificial intelligence, machine learning algorithms, 5G, and data collection and processing.

The cyber threat landscape is also rapidly evolving, and businesses must make critical decisions about protecting themselves and their clients. With cybercrime on the rise and emerging threats driven by new technology such as AI, businesses need to elevate their cybersecurity. Doing so without sacrificing the customers or clients they set out to protect requires a strong ethical foundation and a written code of conduct.

The ACM Code of Ethics and Professional Conduct

In 1992, the Association for Computing Machinery (ACM) developed its Code of Ethics and Professional Conduct for computer systems workers. While it is not mandated, except for members of the ACM, it can be a useful starting point for Chief Information Security Officers (CISOs) and other stakeholders to think about and take a stance on ethical practices when tackling sensitive cybersecurity issues.

The Code of Ethics was revisited and revised in 2018. While the cloud stands to make more updates in the face of 5G, AI, and other advances in computing, it remains a valuable resource for anyone seeking to define ethical standards concerning computer systems and technology.

Having a clear set of ethical principles is helpful because it can clarify and speed up important decision-making in an increasingly complex, rapidly evolving cyber threat landscape.

The ACM Code of Ethics is divided into four categories:

General Ethical Principles
Professional Responsibilities
Professional Leadership Principles
Compliance with the Code

General Ethical Principles

The General Ethical Principles section makes the following assertions about the role of computing professionals. Computing professionals should:

Use their skills to benefit society and people’s well-being, and note that everyone is a stakeholder in computing.
Avoid negative and unjust consequences, noting that well-intended actions can result in harm that they should then mitigate.
Fully disclose all pertinent computing issues and not misrepresent data while being transparent about their capabilities to perform necessary tasks.
Demonstrate respect and tolerance for all people.
Credit the creators of the resources they use.
Respect privacy, using best cybersecurity practices, including data limitation.
Honor confidentiality, including trade secrets, business strategies, and client data.

Professional Responsibilities

The Professional Responsibilities section also says that computing professionals must prioritize high-quality services, maintain competence and ethical practice, promote computing awareness, and perform their duties within authorized boundaries.

Strive to achieve high quality in both the processes and products of professional work.
Maintain high standards of professional competence, conduct, and ethical practice.
Know and respect existing rules pertaining to professional work.
Accept and provide an appropriate professional review.
Give comprehensive and thorough evaluations of computer systems and their impacts, including analysis of possible risks.
Perform work only in areas of competence.
Foster public awareness and understanding of computing, related technologies, and their consequences.
Access computing and communication resources only when authorized or when compelled by the public good.
Design and implement systems that are robustly and usably secure.

Professional Leadership Principles

Professional Leadership pertains to any position within an organization that has influence or managerial responsibilities over other members and has increased responsibilities to uphold certain values set by the organization.

Ensure that the public good is the central concern during all professional computing work.
Articulate, encourage acceptance of, and evaluate fulfillment of social responsibilities by the organization or group members.
Manage personnel and resources to enhance the quality of working life.
Articulate, apply, and support policies and processes that reflect the principles of the Code.
Create opportunities for members of the organization or group to grow as professionals.
Use care when modifying or retiring systems.
Recognize and take special care of systems that become integrated into the infrastructure of society.

Compliance with the Code

Of course, compliance with the Code of Ethics is the only way to ensure cybersecurity professionals uphold certain ethical standards. Without enforcement of the Code of Ethics or similar ethical considerations, it is impossible to document and recognize adherence to ethics and social responsibility.

Uphold, promote, and respect the principles of the Code.
Treat violations of the Code as inconsistent with membership in the ACM.

Corporate Social Responsibility and Cybersecurity

To compete with other businesses and delivery the user experiences that consumers expect, modern businesses are obligated to collect and process increasing amounts of data. This particular genie is already out of the bottle, so the question is not really whether big data should exist but how businesses use and protect data.

Cybersecurity helps prevent and mitigate data breaches and attacks that threaten information security, so it is crucial for public safety and well-being, as well as helping to ensure the longevity of businesses. There is so much at stake that cybersecurity professionals should be willing to come under scrutiny by those in and outside the field.

Cyber ethics encapsulates common courtesy, trust, and legal considerations. Acting ethically should protect individuals, organizations, and the wider economy. So it’s vital for cyber professionals and the organizations that employ them. The following considerations will explore what makes effective cybersecurity and explain how poor cybersecurity is not only ineffective but also potentially unethical.

Information Security

Businesses have a moral obligation to protect their customers and business partners. They benefit from data that allows them to operate and can give them a competitive advantage, but they need to protect that information from hackers and accidental leaks.

Unfortunately, businesses that are hacked are often at fault. While nobody deserves to be hacked, a business’s moral obligations to consumers are such that they are expected to have adequate cybersecurity for their computer systems and respond promptly and decisively in the event of a cyber incident.

Equifax’s 2017 cyber attack is a prime example of a business that damaged its reputation due to inadequate cybersecurity and poor response to attacks. It was hacked around May 2017 but did not disclose the breach until September.

While Equifax’s president for Europe said that protecting consumer and client data was always its top priority, it failed to follow through with patching a software security vulnerability it knew about in March and failed to let affected customers know so that they could take steps to protect themselves from phishing, identity theft, and other kinds of fraud.

Equifax’s human and technological failures compromised 14.5 million sensitive data records, including addresses, birth dates, driver’s licenses, and social security numbers. It also puts the firm’s morality into question, as it processes sensitive information and purports to help customers with their financial security, but its ineffective cybersecurity procedures put those people at risk.

Transparency

Ethically, businesses should be prepared to disclose the risks inherent to the business if they could substantially affect people, whether customers, business partners, or their supply chain.

Data breach reporting is a significant part of a business’s transparency. While reporting a breach highlights a business in crisis, failing to report promptly can lead to a more significant loss of trust, criticism from industry professionals, and sometimes, as in Equifax’s case, action from investigators.

Even if a business operates in an unregulated industry or a cyber attack does not cause business disruption or affect clients, reporting all data breaches is a worthwhile ethical consideration. The more businesses report cyber attacks, the more information there is for cybersecurity experts and industry professionals to share and learn from. This protects other businesses and their clients from emerging threats.

While revealing a vulnerability or data breach according to applicable regulations may not be necessary, there is a moral question as to whether this information should be shared regardless. Being transparent about discovering vulnerabilities can help all businesses protect their information systems and clients.

Cyber incidents are varied, and cybercriminals are continually researching new methods to apply and vulnerabilities to exploit. So how businesses respond to threats and potential threats needs to change on a case-by-case basis. However, they can base their decision-making on an explicit, underlying ethical framework that guides the business according to its values and corporate social responsibility.

While some businesses reject revealing data breaches “unnecessarily” for fear of losing trust or business, disclosing data breaches late can cause more damage and even harsh penalties. Handling a crisis professionally and ethically can even be good for a firm’s reputation, as in the case of Norsk Hydro’s handling of the fallout from its 2017 ransomware attack, which impressed industry professionals and cybersecurity experts.

Organizations and their cybersecurity teams can reap rewards from being proactive and enacting policies and procedures according to a defined, documented code of ethics.

Security vs. Privacy Protection

A prime ethical dilemma in cybersecurity concerns cybersecurity experts’ privileged access to sensitive information. In effect, they must understand how cybercriminals operate and be able theoretically to perform the same feats without crossing the line into the territory of black hat hackers.

Cybersecurity professionals set access privileges, monitor network activity, and can read people’s emails. They can scan machines and therefore can compromise and protect people’s personal lives.

Collecting data leads to ethical questions but so does protecting it. Ethically, everyone deserves dignity, which is tied in with privacy. But how do businesses achieve privacy when they collect customer data, and that data must be protected?

Social engineering and identity theft are among the biggest cyber risks to the public. This is partly because it can affect people beyond those whose data is stored. With stolen data, a cybercriminal can launch phishing attacks against the victim and their associates.

Keeping personally identifiable information (PII) secure, therefore, is paramount. However, that requires personnel to access and in some ways manipulate that data. Anyone working in cybersecurity is walking a tightrope of ethical issues every day. It’s helpful to acknowledge this so that grey areas can be defined and clients are reassured.

Confidentiality

Excellent cybersecurity is not just about technical standards. Cybersecurity professionals need to demonstrate their moral standards when handling sensitive data. During daily duties, cybersecurity professionals will have access to confidential data and files. This could include sensitive data such as payroll details, private emails, and medical records.

Intellectual property theft is one of the most costly cybercrime, as stealing a business’s product designs and concepts can give opponents an unfair advantage while saving them the massive cost and time investment of product development. Nation-states may sponsor cyber espionage to achieve this advantage, risking destabilizing the affected nation’s market and economy. Intellectual property theft can be a serious risk to human life in a critical infrastructure industry, such as defense or healthcare.

It almost goes without saying that cybersecurity staff shouldn’t say anything to the public about the confidential data and intellectual property they see, nor should they store or transmit it in any way that is not aligned with the business’s goals to protect data. “Almost” because ethical debates often involve bringing things out of the shadows and into the light.

An implicit understanding may not be enough to ensure the confidentiality of sensitive data. It’s better to have documented policies and procedures regarding confidentiality and the organization’s attitude to how cybersecurity interacts with personal data.

On April 13, 2023, federal investigators arrested Jake Teixeira, an air national guardsman, concerning the unauthorized transmission of classified US intelligence documents. Teixeira’s role in the Massachusetts Air National Guard was as a Cyber Transport Systems Journeyman responsible for maintaining communication networks.

While there are some claims that he acted as a whistleblower, he shared the documents in a small private group on a social media platform, not seeming to have intended to share it with a wider audience.

Nonetheless, this massive data security breach calls into question cybersecurity professionals’ commitment to upholding the law when faced with tempting confidential information. Cybersecurity teams must be continuously committed and engaged to perform their duties honorably, within the law, and according to the expectations of their employers.

Although The Association for Computing Machinery (ACM) developed a Code of Ethics and Professional Conduct for computer systems workers, ethics in cybersecurity is not regulated. Ethics can’t be ensured by law enforcement.

Having said that, unethical behavior can lead to fines, loss of revenue, and loss of customers, so businesses and cybersecurity professionals will benefit from addressing ethics seriously.

While there’s no handy accreditation that cybersecurity staff can achieve to attest to their honesty, hiring organizations should look at a cybersecurity firm’s history and culture for evidence of its ethical stance on cybersecurity.

Security

Cybersecurity professionals cannot have a lapse of concentration or a couple of days where they’re off their game and let things slide. Responsibility for others’ information security is a massive contractual and ethical responsibility. Almost no matter what the individual does, scrutiny will be on any assigned cybersecurity team or professional in the event of a cyber incident.

Cybersecurity professionals must maintain their competence level, respect sensitive information privacy, and uphold the well-being of those they serve. It requires honesty for these team members to evaluate their skills, abilities, and alertness and ensure that they take the appropriate action to stay on top of their game.

Ethical Hacking

Ethical hacking refers to sanctioned hacking by businesses onto their own systems to discover vulnerabilities and security gaps. Ethical hackers attempt to find vulnerabilities to exploit and break into information systems to fix those issues before cybercriminals find them.

But now imagine an ethical break-in, in which an ethical burglar break into people’s homes and then advises them on which locks they should have used and where to hide their laptops. Ethical hackers use illegal means to achieve positive results.

To protect data from hackers, particularly when they are using increasingly sophisticated methods and rapidly advancing technologies, cybersecurity professionals must use the same techniques. Cybersecurity programmers need to know how to commit crimes by black hat hackers, such as stealing credit card data. What stops them from doing this, however, is that ethical principles separate them.

Cyber professionals must be aware of computer ethics since what they do gives them access to privileged information. This is especially true for professionals working in critical infrastructure, including defense, healthcare, finance, and manufacturing, where the consequences of unethical actions regarding sensitive data could cause serious harm to individuals, organizations, and the economy.

Cybersecurity professionals and businesses that need them must understand cyber ethics and insist that a moral code is always evident in their attitude and behavior.

Whistleblowing

Before the dark web became known as a haven for hackers and cybercriminals to extort money, purchase malware, and prepare to commit multiple kinds of cybercrime, it existed in large part to protect whistleblowers.

Whistleblowing refers to someone reporting their organization’s wrongdoing, typically an employee. A whistleblower’s objection might be that the organization or someone in it is acting illegally, fraudulently, immorally, or without proper regard for safety or human rights. Furthermore, the issue should be in the public interest.

Public sector whistleblowers are protected by the First Amendment. Even so, whistleblowing might be considered a grey area when considering cyber ethics.

If a cybersecurity expert reveals confidential information to stop a harmful practice, the objective is good, but how they achieved this breaks the ethical confidentiality essential to that employee-employer relationship.

Edward Snowden famously blew the whistle on the National Security Agency’s unethical, invasive surveillance of innocent US citizens. While the former computer intelligence consultant and CIA systems administrator is a hero to many, his actions were criminal. The US Department of Justice charged him with stealing government property and violating the Espionage Act of 1917.

Jesselyn Radack, from the Government Accountability Project, argued that Snowden’s contract with the Government was less important than the social contract of a democracy.

Security vs. Functionality

While organizations have a responsibility to society to protect data, they need to balance this requirement with maintaining functionality. A technically workable cybersecurity solution is not necessarily the best if it prevents the organization from operating. This is a moral debate because organizations won’t always use the most secure cybersecurity practices or systems. Operating a modern business means navigating such trade-offs daily.

Cybersecurity experts have a responsibility to balance securing information and keeping organizations running. Some businesses need to be able to work quickly, such as in healthcare where the most robust security system could slow daily operations and risk human life. A holistic approach to information security is required based on thorough risk management.

Source :
https://www.upguard.com/blog/cybersecurity-ethics

Exploring the ePrivacy Directive

Leah Sadoian
updated Sep 15, 2023

There are a variety of cybersecurity regulations in Europe, including the ePrivacy Directive, which focuses on enhancing data protection, processing personal data, and privacy in the digital age. This Directive, recently updated with the ePrivacy regulation, continues the European Union’s ongoing efforts to create cohesive and comprehensive European data protection and cybersecurity standards across all member states.

Upgrade your organization’s cybersecurity standards with UpGuard Breachsight >

What is the ePrivacy Directive?

The Privacy and Electronic Communications Directive 2002/58/EC, or the ePrivacy Directive, is a European Union cybersecurity directive on data protection and privacy protection. The current ePrivacy Directive addresses the growing landscape of new digital technologies and electronic communications services. The Directive aims to harmonize national protection of fundamental rights within the EU, including privacy, confidentiality, and free data movement.

The ePrivacy Directive was enacted in 2002. It required each EU Member State to pass its national data protection and privacy laws, regulating essential issues like consent, spam marketing, cookies, and confidentiality.

Key Components of the ePrivacy Directive

Since the ePrivacy Directive focuses on the protection of online privacy in the electronic communications sector, the Directive’s key components include standards around how people communicate with each other electronically, aligning them with recent technological advancements.

Cookies and Consent Mechanisms

A significant component of the ePrivacy Directive is cookies, which are small data files websites use to track user behavior. Specifically, the Directive states that websites must obtain informed user consent before storing or retrieving any information on their electronic devices, giving the ePrivacy Directive the nickname “cookie law.”

Gaining this consent includes providing end-users with information about the purpose of the data storage and an opportunity to accept or opt-out. Many websites utilize a cookie banner to obtain cookie consent for website visitors. However, cookies essential for site functionality or for delivering a service requested by a user (like tracking the items in an online shopping cart) are exempt from this requirement. Note that the Directive applies to both first-party and third-party cookies.

Protection of Personal Data in Communications

Concerning data protection, the Directive states that providers of electronic communication services must ensure that their services are secure—which in turn secures any personal data that may be shared through those services. Standard electronic communication services include email and instant messaging.

These providers must also inform their users whenever a risk, such as a data breach or ransomware attack, leaves their personal data vulnerable to misuse.

Data Retention

Data retention refers to how companies retain your data, and the ePrivacy Directive includes standards for this practice.

Specifically, the Directive states that when providers of services no longer need your data, they must erase or anonymize it. There are specific situations in which data retention is allowed, such as billing services or issues of national security.

Otherwise, data may only be retained if a user consents to it, and they must also be informed why the data is being processed and the length of time it will be stored.

Unsolicited Marketing Communications

The ePrivacy Directive includes strict restrictions on the use of digital marketing communications. Unsolicited communications for direct marketing purposes are not allowed without the recipient’s consent. This includes email and text message marketing.

Typically, this is done through opt-in or opt-out systems determined by individual EU member states. However, the overall rule is that marketing communications cannot be sent without explicit consent from the user.

Location Data

The ePrivacy Directive sets instructions for using location data obtained through electronic communications. Specifically, location data must be processed with informed consent and should be anonymized when no longer needed.

This provision is very relevant for mobile service providers and location-based services. Like the marketing communications provision, an opt-in or opt-out mechanism allows users to provide explicit consent before location data is provided.

Communications Confidentiality

Companies that provide electronic communication services must implement appropriate security measures to safeguard users’ data. They must also notify users and relevant authorities in case of any security breaches involving personal data. Additionally, the Directive governs how traffic data, which includes information about communication between individuals, can be processed and stored.

Even though the primary goal of the ePrivacy Directive is to protect confidentiality, it does allow for the retention of metadata for billing, service quality, and other purposes. Member states may require data retention under specific conditions, often related to national security or criminal investigations.

Member State Laws

The ePrivacy Directive is a directive that requires every EU Member State to establish national laws to accomplish the Directive’s goals. There is some variation in the regulations across different countries due to this, unlike the GDPR, which is a regulation and applies directly throughout the EU.

How the ePrivacy Directive Affects the GDPR

The General Data Protection Regulation (GDPR) is a mandatory regulation in Europe that protects the personal data of its citizens. Since the GDPR and the ePrivacy directive both concern data privacy, they work in tandem across various components.

Scope: The ePrivacy Directive focuses explicitly on the electronic communications sector, and the GDPR extends data privacy laws to other industries that process personal data.
Consent: Both the ePrivacy Directive and the GDPR focus on user consent, but the GDPR also outlines principles of lawful processing, including contractual necessity, legitimate interests, and legal obligation.‍
Confidentiality vs. Data Protection: The ePrivacy Directive is primarily concerned with the privacy and security of electronic communications, and the GDPR includes broader concepts of data protection like data minimization, accountability, and individuals’ rights to access, rectify, and erase personal data.‍
Security Measures: The ePrivacy Directive requires providers of electronic communication services to implement security measures to protect user information. At the same time, the GDPR mandates robust security measures and includes the concept of “data protection by design and default.”‍
Data Breach Notifications: Both require notification of data breaches to users and regulatory authorities. The ePrivacy Directive only requires communication service providers to provide notification, but the GDPR extends that requirement to all data controllers and processors.

Who Must Comply with the ePrivacy Directive?

The ePrivacy Directive applies to entities providing electronic communication services in the EU, including but not limited to:

Telecommunication Companies: Traditional telecom providers offer fixed or mobile telephony services.
Internet Service Providers (ISPs): Entities providing internet connectivity services.
Over-the-top (OTT) Providers: Companies that offer online communication services, such as instant messaging apps and VoIP services like Skype or WhatsApp.
Website Owners: Any website that uses cookies or similar technologies to track user behavior must comply with the Directive.
Email and SMS Marketers: Businesses that send marketing messages via email or SMS must adhere to the rules set by the Directive.
Location-Based Services: Services that use location data also fall under the Directive’s jurisdiction.

Penalties for Noncompliance

Penalties for failing to comply with the ePrivacy Directive may differ across EU Member States, as each country is responsible for incorporating the Directive into national law. As a result, penalties can vary from monetary fines to legal actions, and the severity of the consequences will depend on the nature of the breach and the location of the incident. Below are some typical types of penalties that may be enforced:

Financial Fines: These can vary widely from state to state but are generally designed to be dissuasive. Some countries have a cap on fines, while others may calculate them as a percentage of the annual turnover of the offending company.
Legal Sanctions: In some instances, severe or repeat violations may result in legal action, including the possibility of criminal charges.
Reputational Damage: Beyond legal penalties, companies that violate ePrivacy laws often suffer significant reputational damage, which can result in loss of customer trust and revenue.
Cease and Desist Orders: Regulatory bodies may require the violating entity to stop the offending action immediately, often at the cost of temporarily or permanently turning off a service or feature.
Data Audits: In some cases, the regulatory bodies may require a thorough audit of data protection practices within the offending organization.
Notification Requirements: Failing to notify the authorities and individuals affected by a data breach, as stipulated by the Directive, can lead to additional penalties.

In 2022, Google and Meta were both found to be in violation of the ePrivacy Directive and faced steep fines for their non-compliance. France’s Commission Nationale Informatique & Libertés (CNIL) fined Google €150M and Facebook another €60M for not offering an option for users to reject non-essential cookies in line with the option to accept all tracking. This violates the ePrivacy Directive’s requirements around cookies and consent mechanisms.

The Future: Introducing the ePrivacy Regulation

Since 2002, the digital communications industry has evolved rapidly, which means the ePrivacy Directive needed drastic updating. In 2017, The European Commission proposed the ePrivacy Regulation, which aims to replace the existing ePrivacy Directive and better align it with the General Data Protection Regulation (GDPR) data protection laws.

The regulation is still under discussion amongst the EU Council because of the scope of the rules and the impact it would have on big tech companies, large telecom providers, and even areas of online advertising, media, and national security.

This new legislation is a regulation of the European Parliament and Council of the European Union. It specifies and complements the ePrivacy Directive on privacy-related topics such as the confidentiality of communications, consumer privacy controls through electronic consent and browsers, and cookies.

Key Differences

Legal Form and Scope: As a directive, member states must achieve specific goals but have the authority to decide how to do so, which can lead to differences in implementation across countries. The ePrivacy Regulation is a directly applicable law that becomes enforceable across the European Union, creating greater consistency.‍
Cookies and Trackers: The ePrivacy Regulation expands on the requirement for user consent before utilizing cookies and tracking technologies but simplifies the rules around this requirement. This can include allowing users to consent through browser extensions and specific exceptions for cookies that improve user experience.‍
Consent: The ePrivacy Regulation aligns the ePrivacy Directive’s requirements for user consent with the GDPR’s more stringent standards. This also simplifies consent mechanisms.‍
Electronic Marketing: The ePrivacy Regulation extends the ePrivacy Directive’s restriction on unsolicited communications for marketing purposes to cover new marketing methods and forms of electronic communication, like marketing through social media platforms.‍
Data Protection and Security: The ePrivacy Directive requires service providers to utilize security measures and report data breaches. The ePrivacy Regulation aligns those requirements with the GDPR’s broader data protection framework, which has stricter data breach notification timelines.‍
Penalties: Instead of allowing individual member states to determine penalties for noncompliance, the ePrivacy Regulation adopts a penalty framework similar to the GDPR, with fines based on a company’s global turnover, up to 4% or up to €20 million, whichever is higher. It also gives more power to Data Protection Authorities, aligning it with the GDPR.‍
International Impact: The ePrivacy Regulation’s alignment with the GDPR means data protection standards are not just primarily focused on EU member states but now affect any company that offers services or data transfers to EU residents (even if they are not located within the EU).

UpGuard Helps Your Organization Stay Compliant with Privacy Regulations

Enhance your organization’s data privacy standards with UpGuard. Whether you’re looking to stay compliant with the EU’s ePrivacy Regulation or the CCPA in the states, our all-in-one attack surface management platform, BreachSight, helps you understand the risks impacting your external security posture and know that your assets are constantly monitored and protected.

UpGuard BreachSight features include:

Security Ratings: Use our security ratings for a data-driven, objective, and dynamic measurement of your organization’s security posture. Our security ratings are generated by analyzing trusted commercial, open-source, and proprietary threat intelligence feeds and non-intrusive data collection methods.
Continuous Security Monitoring: Get real-time information about misconfigurations, understand your risk profile, and get started in minutes, not weeks, with our fully integrated solution and API. Because we use externally verifiable information, you won’t have to lift a finger to get started.
Attack Surface Reduction: Reduce your attack surface by discovering exploitable vulnerabilities and permutations of your domains at risk of typosquatting.
Data Protection: UpGuard’s proprietary Data Leak Search Engine scans every corner of the Internet and identifies data that presents a risk. It monitors your Internet presence and doesn’t check every website where we can find cloud storage buckets and source code repos.
Workflows and Waivers: Simplify and accelerate how you remediate issues, waive risks, and respond to security queries. Use our real-time data to get information about risks, rely on our workflows to track progress, and know precisely when issues are fixed.
Security Profile: Eliminate security questionnaires and stop answering the same questions repeatedly. Create an UpGuard security profile and share it before being asked.
Reporting and Insights: The Reports Library makes accessing tailor-made reports for different stakeholders in one centralized location easier and faster. See all risks–across various domains, IPs, and categories–in the UpGuard platform or extract the data directly from the API.
Business Operation Management: Share access to your UpGuard account with other team members with confidence. Each user gets an individual account with fine-grained access control.
Third-Party Integrations: Integrate and extend the UpGuard platform with other tools with our easy-to-use API that can save hours of human time.

Source :
https://www.upguard.com/blog/eprivacy-directive

What is ISO 31000? An Effective Risk Management Strategy

Edward Kost
updated Sep 14, 2023

ISO 31000 was specifically developed to help organizations effectively cope with unexpected events while managing risks. Besides mitigating operational risks, ISO 31000 supports increased resilience across all risk management categories, including the most complicated group to manage effectively – digital threats.

Whether you’re considering implementing ISO 31000 or you’re not very familiar with this framework, this post provides a comprehensive overview of the standard.

Learn how UpGuard simplifies Vendor Risk Management >

What is ISO 31000?

ISO 31000 is an international standard outlining a risk management structure supporting effective risk management strategies. The standard is divided into three sections:

Principles
Framework
Process

Principles

The objective of all of the principles of ISO 31000 is to simultaneously increase the value and protection aspects of a management system.

The 11 principles of ISO 31000 are as follows:

Risk management creates and protects value – Risk management should support objective achievement and performance improvements across various sectors, including human health and safety, cybersecurity, regulatory compliance, environmental protection, governance, and reputation.
Risk management is an integral part of all organizational processes – Risk management shouldn’t be separated from the main body of a management system. It should be integrated into an organization’s processes to create a risk-aware culture. Management teams should champion this cultural change.
Risk management is systematic, structured, and timely – Risk management should cover the complete scope of systemic risk. It shouldn’t be focused on a single business component prone to risks, like the sales cycle.
Risk management is tailored – A risk management program should be tailored to your objectives within the context of internal and external risk profiles.
Risk management is transparent and inclusive – All appropriate stakeholders and decision-makers should be involved in ensuring risk management remains relevant and updated.
Risk management is dynamic, iterative, and responsive to change – A risk management program shouldn’t be based on a rigid template. It should be dynamic, capable of conforming to changing internal and external threat landscapes.
Risk management is based on the best available information – Risk management processes shouldn’t be limited to historical data, stakeholders’ feedback, forecasts, and expert judgments. It’s essential to consider the limitation of data sources and the likely possibility of divergent opinions among experts.
Risk management is part of decision-making – Risk management should help leadership teams make intelligent risk mitigation decisions by understanding which risks should be prioritized to maximize impact.‍
Risk management takes human and cultural factors into account – All risk management activities should be assigned to individuals with the most relevant competencies. Appropriate tools should be available to these individuals to support their efforts as much as possible.‍
Risk management facilitates continual improvement of the organization – Strategies should be developed to ensure risk management efforts are continuously improving.‍
Risk management explicitly addresses uncertainty – Risk management should directly address uncertainty by understanding its nature and finding ways to mitigate it.

Framework

The framework component of the ISO 31000 standard outlines the structure of a risk management framework, but not in a prescriptive way. The objective is to help organizations integrate risk management into their overall management system based on their unique risk exposure context. Businesses should implement the framework through the lens of their risk management objectives, prioritizing the most relevant aspect of the proposed framework. This flexibility makes any management system capable of mapping to ISO 31000, making the standard industry agnostic.

ISO 31000 can be implemented by any industry to reduce enterprise risk, regardless of size or existing risk management process.

The driving factor for the framework aspect of ISO 31000 is the management team’s commitment to embedding a risk management culture across all organizational levels.

Leadership and commitment branching out into 5 points - integration, design, implementation, evaluation, and improvement.

The five framework pillars of ISO 31000 are as follows:

Integration – The risk management framework should be integrated into all business processes, a change that follows the management team’s push for a cultural shift towards greater risk awareness.
Design – The design of the final risk management framework must consider the organization’s unique risk exposure and risk appetite.
Implementation – An implementation strategy should consider potential roadblocks, resources, timeframes, key personnel, and mechanisms for tracking the framework’s efficacy following implementation.
Evaluation – The evaluation components broaden the focus on measuring framework efficacy. This process could involve appealing to various data sources, such as customer complaints, the number of unexpected risk-related events, etc.
Improvement – This is the final step of the popular management system design model, Plan Do, Check Act (PDCA). Improvements should be made based on the insights gathered in the evaluation phase. The objective of each improvement interaction is to reduce the number of surprises caused by the risk management framework.

The design of the risk framework should be based on business objectives and a risk management policy within an organization’s unique risk context (the contextualization of risks is a recurring theme in ISO 31000).

Risk management policy feeding program design which is part of a cycle consissting of - program design, implementation, monitoring, improvement.

The Framework stage sets the broad risk management context, which is then refined in the Process stage, setting the foundation for more meaningful insights gathered through risk assessments.

Process

The process approach to ISO 31000 is represented graphically as follows:

Communication and Consultation

The first stage of this process approach is communication and consultation. The more cross-functional opinions that are heard, the more comprehensive your risk management efforts will be. This stage draws upon ISO 31000’s inclusivity and cultural factor principles.

Communications aren’t just limited to internal functions. External stakeholders should be involved in all decision-making processes. This will encourage stakeholder involvement in all stages of the risk management program’s development – which supports the primary objective of the Framework stage in ISO 31000:2018.

Scope, Context, and Criteria

Ideally, many of these mechanisms should already be established in your management system. The scope of all management activities is performed within the organization’s context, as defined in ISO 9001 Clause 4.1.

Contextual intelligence is a consideration of all internal and external issues impacting the achievement of business objectives. Contextualization can be achieved by gathering information from the following sources:

Risk assessment of internal and external risk factors
Internal audits
Organization policy statements
The use of a SWOT template (Strengths, Weaknesses, Opporitnies, Threats)
Strategy documents
Questionnaires (for internal and external process investigations)
Interviews (with stakeholders, senior management, cross-functional teams including finance, human resources, engineering, training, etc.).

Learn about UpGuard’s security questionnaires >

The criteria used to assess risk depends on the most appropriate initiative and objective methodology as outlined in the value creation principle of ISO 31000.

This could include

Strategic objectives
Operational objectives
Business objectives
Health and safety objectives
Cybersecurity objectives

Start by narrowing your focus to a single scope. Then, after the process has been proven to work, expand your scope into other regions.

Risk Assessment

After defining your scope, context, and criteria, the actual risk assessment process begins. There are three primary stages in the risk assessment lifecycle.

Risk Identification – Understanding the source of discovered risks and their classification (whether they originate from internal or external attack surfaces)
Risk Analysis – Understanding the impact of identified risks and potential risks and the efficacy of their associated security controls.
Risk Evaluation – A comparison of discovered risks against your risk register.
Deciding which risk should be addressed based on an acceptance criterion defined by your risk appetite.

Learn about UpGuard’s vendor risk assessment features >

Risk evaluation data will determine which actions need to take place. Any control adjustments or framework improvements will be relative to each unique scope, context, and criteria scenario.

Stakeholders should be involved in deciding how to best respond to risk evaluation insights.

Risk Treatment

The risk treatment stage is where you decide the best course of action. These decisions will depend on your risk appetite, which defines the threshold between the levels of risk that can be accepted and those that need to be addressed.

Different types of risk should be considered, including:

Strategic risks
Cybersecurity risks
Reputational risks

Security controls suppress cybersecurity inherent risks within acceptable risk appetite levels

Your methodology for treating risks depends on the risk culture being developed by the management team. Some organizations have a very low-risk tolerance, while others (such as those in heavily regulatory industries like healthcare) have a very low tolerance to risk. These tolerance bands are decided during the calculation of your risk appeite. If your risk appetite has already been determined, revise it to ensure it’s clear enough to support the risk management standards of ISO 31000.

Learn how to calculate your risk appetite >

A risk matrix is helpful in the risk treatment phase as it indicates what risks should be prioritized in remediation efforts to minimize impact.

In the context of Vendor Risk Management, a risk matrix indicates which vendors pose the most significant risk to an organization’s security posture.

For a deep dive into Vendor Risk Management, read this post.

These insights, coupled with an ability to project the impact of selected

remediation tasks, help response teams optimize their risk treatment efforts, supporting the continuous improvement objectives of ISO 3100

Remediation impact projections on the UpGuard platform.

Another form of risk treatment is to outsource the responsibility to a third party. For example, third-party risk management, the process of managing security risks caused by third-party vendors, could be outsourced to a team of cybersecurity experts. Your organization will still be responsible for the outcome of detected risks but without the added burden of also having to manage them.

The benefit of reduced internal resources makes outsourcing third-party risk management a very economical choice for scaling businesses.

Watch this video to learn about UpGuard’s Third-Party Risk Management Service.

https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Ffast.wistia.net%2Fembed%2Fiframe%2Fzi5w6pr0ay&display_name=Wistia%2C+Inc.&url=https%3A%2F%2Fupguard.wistia.com%2Fmedias%2Fzi5w6pr0ay&image=https%3A%2F%2Fembed-ssl.wistia.com%2Fdeliveries%2F09cd5e73ebe661e959c48e0fcca9a693.jpg%3Fimage_crop_resized%3D960x540&key=96f1f04c5f4143bcb0f2e68c87d65feb&type=text%2Fhtml&schema=wistia

Monitoring and Review

Evaluating the effectiveness of your implemented risk framework will determine whether or not your ISO 31000 risk management program was a profitable investment. During each review and iteration process, be sure to keep the human and cultural factor principle front of mind – don’t forget the people impacted by each iteration.

Your risk mitigation objectives shouldn’t be so ambitious that you must handcuff your employees. You need to strike the perfect balance between risk management, risk acceptance, and employee well-being.

Recording and Reporting

Finally, all risk management activities should be recorded. Not only will this support stakeholders with their ongoing risk-based strategic decisions, but it will also provide you with a reference for tracking your management systems maturity throughout the ISO 31000 implementation lifecycle.

Source :
https://www.upguard.com/blog/what-is-iso-31000 https://www.upguard.com/blog/what-is-iso-31000

A Comprehensive Guide on Cybersecurity for Business Travelers

28.06.2023

Business travel has become an integral part of many professionals’ lives, enabling them to expand networks and explore new opportunities. However, it also exposes travelers to various cyber risks that can compromise sensitive data and business operations.

In this comprehensive guide, we will examine the world of cybersecurity for business travelers, providing valuable insights and practical tips to ensure data protection while on the go.

The Cyber Risks of Business Travel

Traveling on business opens up both individuals and organizations to countless cyber risks, including vulnerabilities associated with public Wi-Fi connections, the risk of device theft, weak password security, compliance issues, insecure email traffic, and unsecured file-sharing platforms.

These risks can lead to unauthorized access, data breaches, and severe financial and reputational consequences if not properly addressed. Below we outline those risks in further detail so that you may avoid them:

Public Wi-Fi Connections

These networks, often found in hotels, airports, and coffee shops, are often unsecured and easily exploited by cyberhackers. Connecting to these networks puts sensitive data at risk of interception, allowing cybercriminals to steal login credentials, financial information, and other confidential data. It is essential for business travelers to exercise caution and avoid transmitting sensitive information or accessing critical accounts while connected to public Wi-Fi.

Device Theft

The loss or theft of laptops, smartphones, or tablets not only results in financial loss but also grants illicit access to valuable company information. Cybercriminals may exploit stolen devices to gain access to sensitive data, compromise corporate networks, or launch phishing attacks against colleagues and clients.

Implementing physical security measures such as using laptop locks and keeping devices within sight can help deter theft while encrypting data and enabling remote wiping capabilities can mitigate the risks associated with device loss or theft.

Password Security

Weak or reused passwords can provide easy access to unauthorized individuals. Implementing strong, unique passwords across all devices and accounts adds an extra layer of protection. Additionally, enabling two-factor authentication (2FA) enhances security by requiring an additional verification step.

Compliance

It’s important to ensure that personal and business data remain compliant with relevant laws, such as the General Data Protection Regulation (GDPR). Implementing encryption protocols and secure file storage solutions helps maintain compliance and mitigate risks.

Insecure Email Traffic

Business travelers must be careful when using public or unsecured networks to send sensitive information via email. Implementing end-to-end encryption, using secure email providers, and avoiding opening suspicious attachments or clicking on unknown links are vital precautions to protect against email-based attacks.

File Sharing

File sharing can introduce serious security risks. It’s critical to utilize secure file-sharing platforms that encrypt data both in transit and at rest. It’s advisable to implement access controls and permissions to restrict file sharing to authorized individuals only. Also, regularly reviewing and updating file-sharing policies can also help prevent evolving cybersecurity threats.

Cybersecurity Tips for Business Travelers

As we mentioned above, cybercriminals are constantly targeting business travelers, seeking to exploit vulnerabilities in their devices and steal sensitive information. Therefore, it is imperative for business travelers to be well-equipped with effective cybersecurity tips and best practices to safeguard their valuable data and protect their digital assets while on the move.

Here are some simple yet effective things you can do to help keep the hackers at bay:

Lock Your Screens

This simple yet crucial step helps prevent unauthorized access to private or sensitive information. By enabling screen locks, such as passcodes, PINs, or biometric authentication (fingerprints or facial recognition), business travelers can create an additional layer of security that ensures that data remains protected even if their device falls into the wrong hands

Use Public Wi-Fi Sparingly

Public Wi-Fi networks found in hotels, airports, and coffee shops are infamous for their lack of security. When connecting to public Wi-Fi, business travelers expose their data to potential interception by hackers.

As such, it is highly advisable to use public Wi-Fi as sparingly as possible and avoid transmitting any sensitive information, such as login credentials, financial data, or confidential documents.

Instead, business travelers should consider using their mobile network or setting up a personal hotspot with a secure password, or utilizing a virtual private network (VPN) to encrypt internet traffic and protect private data from prying eyes.

Disable the Auto-Connect Feature

Most devices have a feature that automatically connects to available Wi-Fi networks. While this is extremely convenient, this feature can be a security risk. Disabling the auto-connect feature ensures that the device doesn’t automatically connect to untrusted or potentially malicious networks.

It also provides more control over network connections, allowing business travelers to evaluate the security of each network before connecting and minimizing the risk of unwittingly joining an insecure network.

Avoid Location-Sharing

Sharing locations through social media platforms or apps can compromise privacy and potentially put business travelers at risk. This is because cybercriminals can use location data to track movement, identify patterns, and exploit absence from certain locations.

By refraining from location-sharing, business travelers can maintain a higher level of privacy and reduce the chances of becoming a target for physical theft or cyber-attacks.

Use Anti-virus Protection and Run OS Updates

Installing reliable anti-virus software on devices is crucial for detecting and preventing malware infections. Anti-virus protection helps safeguard against various threats, including viruses, ransomware, and spyware.

Additionally, keeping the operating system (OS) up to date with the latest security patches and updates is essential. This is because operating system updates often include bug fixes, vulnerability patches, and security enhancements that protect against known exploits and vulnerabilities.

Update Your Passwords

Regularly updating passwords is an essential cybersecurity practice for business travelers. Strong, unique passwords provide an additional layer of protection against unauthorized access. It is recommended to use a combination of upper and lowercase letters, numbers, and special characters when creating passwords.

Travelers should avoid reusing passwords across different accounts or platforms, as this increases the risk of a single password compromise leading to multiple account breaches. Implementing a password manager can also help generate and securely store complex passwords for easy and secure access.

Disable Bluetooth

Bluetooth technology allows wireless connections between devices, but it also presents potential security risks. Cybercriminals know this and often exploit Bluetooth vulnerabilities to gain unauthorized access to business travelers’ devices or intercept sensitive data. Disabling Bluetooth when not in use mitigates these risks and reduces the likelihood of being targeted through Bluetooth-related attacks.

Turn Off NFC (Near-Field Communication)

NFC enables contactless communication between devices. While NFC can be convenient for certain tasks, it also presents security risks, such as unauthorized access or data theft. Turning off NFC when not required helps prevent potential attacks and keeps business travelers’ devices and data secure.

Back up Information on the Cloud

Regularly backing up data on secure cloud storage services provides an additional layer of protection against data loss. In the event of device theft, damage, or loss, having all information securely stored in the cloud ensures that users can access and retrieve important files, documents, and data from any device with internet access.

Be Vigilant

Maintaining a vigilant mindset is crucial for business travelers. Staying alert for phishing attempts, suspicious links, and unfamiliar emails or messages is vital.

Hackers often exploit travel-related scenarios to trick individuals into revealing sensitive information or downloading malware.

By being cautious, double-checking before clicking on links or providing personal information, and staying informed about common phishing techniques, can significantly reduce the risk of falling victim to cyber-attacks.

By implementing the above cybersecurity tips, business travelers can enhance their digital security, reduce the risk of data breaches, and protect their sensitive information while on the go.

Cybersecurity Tips for Businesses

Organizations of all sizes must prioritize cybersecurity to protect their sensitive data, intellectual property, and customer information. Implementing effective cybersecurity measures is essential to safeguarding against cyber threats and minimizing the risk of data breaches.

Here are some essential tips for businesses to enhance their cybersecurity posture:

Implement Public Wi-Fi Policies

Establish clear policies and guidelines for employees regarding the use of public Wi-Fi networks. This includes educating them about the risks associated with public Wi-Fi and providing instructions on how to connect securely or avoid using untrusted networks altogether.

Implement VPN Usage Policies

Administer the use of virtual private networks (VPNs) when accessing company resources remotely. Implement policies that require employees to connect to a business VPN to ensure encrypted and secure communication, especially when accessing sensitive data or using public networks.

Train Your Employees to Keep Their Devices Secure

Conduct regular training sessions to educate employees on best practices for device security. This includes creating strong passwords, enabling two-factor authentication (2FA), keeping software and applications updated, and avoiding suspicious websites and downloads.

Train Employees for a Response Plan

Develop and train employees on a comprehensive incident response plan. Ensure they understand the steps to take in the event of a cybersecurity incident, including who to notify, how to preserve evidence, and how to mitigate further damage.

Encourage Situational Awareness

Foster a culture of cybersecurity awareness among employees by promoting situational awareness. Encourage them to be vigilant and identify potential threats, such as phishing emails, suspicious activities, or social engineering attempts. Encourage reporting of any suspicious incidents promptly.

Protect Mobile Devices With Strong Passwords and 2FA

Emphasize the importance of strong passwords and enable two-factor authentication (2FA) on all company-owned mobile devices. This provides an additional layer of security and prevents unauthorized access to sensitive information.

Require Regular Software Updates

Make it a policy for employees to frequently update their software, applications, and operating systems. This ensures that devices have the latest security patches and protections against emerging threats.

Provide Traveling Employees With Charging Devices

Equip traveling employees with reliable charging devices to inhibit the use of public charging stations, which can be compromised to deliver malware or steal data.

Issue Travel-Only Laptops

Provide dedicated laptops specifically for business travel. These travel-only laptops should be hardened and secured with robust security measures, minimizing the risk of data exposure while on the move.

Update Devices After Traveling

After returning from travel, ensure that employees’ devices undergo thorough security checks and updates. This helps address any potential security vulnerabilities or malware that may have been acquired during travel.

Implement a Mobile Device Management Solution

Deploy a mobile device management (MDM) solution to enforce security policies, remotely manage and monitor devices, and protect sensitive data on mobile devices. MDM solutions provide centralized control and enhanced security for company-owned devices, especially for those used by traveling employees.

Unlock Advanced Security With Perimeter 81

Cybersecurity is of increasingly paramount importance for business travelers and organizations. The risks and threats faced while on the move require a proactive and comprehensive approach to protect sensitive information and mitigate potential breaches.

By implementing the cybersecurity tips outlined in this article, both business travelers and their organizations can significantly enhance their digital security posture, ensuring that sensitive information and digital assets are safeguarded, and enabling them to focus on their professional endeavors while minimizing the risks associated with their journeys.

Need a business VPN to use? We have the leading VPN and ZTNA technology suite to help you secure your business. Book a demo today!

FAQs

What are some good cybersecurity practices when going on a business trip?

To ensure cybersecurity while on business trips, there are several essential practices to follow. First, it is crucial to use secure and trusted networks, avoiding public Wi-Fi whenever possible. Instead, connect to secure networks such as virtual private networks (VPNs) or mobile hotspots with strong encryption.

Additionally, enabling two-factor authentication (2FA) adds an extra layer of security by requiring an additional verification step, like a unique code sent to a mobile device, along with a password. Keeping devices and software updated is also vital, as regular updates help protect against known vulnerabilities.

Implementing strong password practices, being cautious of phishing attempts, securing physical devices, and regularly backing up important data are further measures that business travelers should adopt.

What is cybersecurity in tourism?

Cybersecurity in tourism refers to the protection of digital assets, data, and systems within the tourism industry. It involves employing measures to safeguard against cyber threats, data breaches, and unauthorized access to sensitive information.

In the tourism sector, cybersecurity is vital to ensure the integrity and confidentiality of customer data, financial transactions, and other sensitive information.

It encompasses practices such as securing online booking platforms, protecting customer payment information, educating employees about cyber threats, and maintaining robust data protection protocols to instill confidence and trust in travelers.

What type of businesses need cybersecurity?

All businesses, regardless of size or industry, need cybersecurity measures to protect their digital assets and sensitive information. While certain industries face higher risks, such as financial institutions, healthcare organizations, e-commerce companies, government agencies, and technology firms, it is crucial to recognize that cybersecurity is relevant to all businesses.

Cyber threats can impact any organization that utilizes digital technologies, stores customer data or relies on online systems for operations. Safeguarding digital assets and customer information should be a priority for businesses across industries.

Source :
https://www.perimeter81.com/blog/network/cybersecurity-for-business-travelers

Key Insights into Healthcare Compliance in 2023

27.07.2023

Healthcare compliance in 2023 is being driven by a combination of increased regulatory scrutiny, technological advancements, and a growing focus on patient-centric care. As a result, organizations are increasingly expected to adhere to stringent regulations, safeguard patient data, maintain ethical practices, and ensure the delivery of high-quality care.

This necessitates a proactive approach to compliance, with healthcare providers and institutions striving to stay ahead by adopting robust systems, training staff, and embracing innovative solutions to mitigate risks and protect both patients and their reputation.

What is Healthcare Compliance?

Compliance is the adherence to regulations, guidelines, and ethical standards aimed at safeguarding patient privacy, data security, and overall quality of care. It involves staying up to date with evolving laws, implementing necessary measures, and ensuring organizational practices align with industry standards.

Healthcare Compliance Regulations

Healthcare compliance regulations include:

The Health Insurance Portability and Accountability Act (HIPAA), which sets standards for protecting patient health information and establishes penalties for non-compliance.
The Affordable Care Act (ACA), which focuses on improving healthcare access and quality while combating fraud and abuse.
The Centers for Medicare and Medicaid Services (CMS), which plays a crucial role by overseeing programs and regulations related to these government-sponsored healthcare services.

Compliance with these regulations is essential for healthcare organizations to maintain trust, avoid penalties, and provide high-quality care.

Who Regulates the Healthcare Industry?

The healthcare industry is regulated by several entities, including government agencies and regulatory bodies. In the United States, the primary regulators include:

The U.S. Department of Health and Human Services (HHS), which oversees several agencies responsible for healthcare regulation, such as the Centers for Medicare and Medicaid Services (CMS) and the Office for Civil Rights (OCR).
The Food and Drug Administration (FDA) who regulate drugs, medical devices, and food safety
The Drug Enforcement Administration (DEA) who monitor controlled substances. State health departments and professional boards.

What are the Most Important Healthcare Regulations?

Several regulations stand out as the most important in the healthcare industry as follows:

The Social Security Act

The Social Security Act, enacted in 1935, is a landmark piece of legislation in the United States that established the Social Security program. It provides benefits to retirees, disabled individuals, and surviving family members, aiming to alleviate poverty and provide economic security.

The Health Insurance Portability and Accountability Act (HIPAA)

The Health Insurance Portability and Accountability Act (HIPAA), enacted in 1996, safeguards the privacy and security of individuals’ health information. It sets standards for the electronic exchange of health information, ensures the confidentiality of medical records, and grants patients certain rights over their health data.

The Health Information Technology for Economic and Clinical Health ACT (HITECH)

The Health Information Technology for Economic and Clinical Health Act (HITECH) was passed in 2009 as part of the American Recovery and Reinvestment Act. It promotes the adoption and meaningful use of electronic health records (EHRs) and strengthens privacy and security protections for health information.

The False Claims Act

The False Claims Act is a federal law that dates back to the Civil War era. It allows private individuals, known as whistleblowers, to file lawsuits on behalf of the government against those who defraud federal programs, such as Medicare and Medicaid, by submitting false claims for payment.

The Anti-Kickback Statute

The Anti-Kickback Statute prohibits the exchange of anything of value in return for referrals or generating business for federal healthcare programs. This law aims to prevent kickbacks and improper financial arrangements that could compromise medical judgment and inflate healthcare costs.

The Physician Self-Referral Law

The Physician Self-Referral Law, also known as the Stark Law, prohibits physicians from referring Medicare or Medicaid patients to entities in which they have a financial interest, with exceptions. This law prevents potential conflicts of interest that could influence medical decision-making and billing practices.

The Patient Protection and Affordable Care Act

The Patient Protection and Affordable Care Act (ACA), passed in 2010, is a comprehensive healthcare reform law. It expands access to health insurance, implements consumer protections, such as prohibiting denial of coverage due to pre-existing conditions, and introduces various cost-containment measures.

The Interoperability and Patient Access Final Rule

The Interoperability and Patient Access Final Rule, issued in 2020, is part of the 21st Century Cures Act. It requires healthcare providers, health plans, and health information technology developers to improve interoperability and facilitate patient access to their electronic health information.

The Hospital Price Transparency Final Rule

The Hospital Price Transparency Final Rule, implemented in 2021, requires hospitals to disclose their standard charges for healthcare services in a machine-readable format. This rule aims to increase price transparency, empower patients to make informed decisions and promote competition in the healthcare market.

Why is Healthcare Compliance so Important?

Healthcare compliance is necessary due to the following main reasons:

First and foremost, it ensures that healthcare organizations operate in accordance with applicable laws, regulations, and industry standards. Compliance helps protect patient safety and privacy by ensuring that healthcare providers follow protocols for handling sensitive health information, maintaining secure systems, and implementing proper safeguards against data breaches.

By adhering to compliance regulations, healthcare organizations demonstrate their commitment to maintaining the highest standards of care and ethical practices.

Moreover, healthcare compliance helps mitigate legal and financial risks. Non-compliance can result in severe consequences, such as hefty fines, penalties, and legal actions, which can significantly impact an organization’s reputation and financial stability. By actively engaging in compliance efforts, healthcare organizations can minimize the risk of violations, protect their reputation, and avoid potential litigation.

Finally, healthcare compliance promotes a culture of integrity, accountability, and transparency. It encourages healthcare professionals to adhere to ethical guidelines, maintain accurate records, and engage in responsible billing practices.

Compliance programs also promote internal monitoring, auditing, and reporting mechanisms, fostering an environment where unethical or fraudulent activities are detected and addressed promptly.

Ultimately, healthcare compliance helps ensure the delivery of high-quality care, protects patients’ rights, and maintains the trust of individuals seeking healthcare services.

Privacy & Quality Patient Care

Protecting patient privacy is essential for ensuring quality patient care. When patients trust that their personal health information will remain confidential, they are far more likely to share vital details with healthcare providers, leading to accurate diagnoses and tailored treatment plans.

By implementing robust privacy measures, healthcare organizations can uphold patient confidentiality, enhance trust, and maintain the integrity of the patient-provider relationship, improving the quality of care delivered.

Healthcare Worker Protection

By implementing measures such as appropriate staffing levels, comprehensive training, and access to personal protective equipment, healthcare organizations can protect their workers from occupational hazards, minimize the risk of injuries or infections, and promote a healthy work environment.

Safeguarding healthcare workers’ physical and mental well-being contributes to their ability to provide quality care and ensures the sustainability of the healthcare workforce.

Avoiding Fraud

Healthcare fraud involves deceptive practices such as submitting false claims, providing unnecessary services, or billing for services not rendered. By implementing robust fraud detection and prevention mechanisms, such as auditing processes and internal controls, healthcare organizations can identify and prevent fraudulent activities.

This helps protect valuable healthcare resources, ensure that funds are directed towards legitimate patient care, and maintain the public’s trust in the healthcare system.

Staying Compliant with Regulations

By staying compliant, healthcare organizations mitigate legal and financial risks, maintain their reputation, and demonstrate a commitment to providing high-quality care while upholding ethical standards. Regular monitoring, training, and robust compliance programs are key to achieving and maintaining regulatory compliance.

10 Best Practices for Creating a Healthcare Compliance Plan

By implementing key strategies, organizations can establish a strong foundation for compliance and risk management as follows:

1. Designate a Chief Compliance Officer

Designate a CCO who has the authority and resources to develop, implement, and oversee the compliance program, ensuring adherence to regulatory requirements and promoting a culture of compliance throughout the organization.

2. Educate the Employees

Employees should be knowledgeable about their roles and responsibilities in maintaining compliance, including privacy and security of patient information, ethical billing practices, and reporting mechanisms for potential compliance violations.

3. Build an Effective Compliance Reporting System

Clear reporting channels, such as hotlines or anonymous reporting mechanisms, should be in place to capture and address compliance-related issues promptly.

4. Build a Risk Mitigation Plan

Conduct regular risk assessments to proactively identify vulnerabilities, implement controls and mitigation strategies, and monitor ongoing compliance to minimize the likelihood of compliance breaches.

5. Ensure Cybersecurity at Every Level

Implement robust security measures, such as encryption, access controls, and regular security audits to safeguard electronic health records and other sensitive information from unauthorized access or breaches.

6. Make Sure Your Telemedicine Services Are Secure

Implement secure telemedicine platforms, encryption protocols, and HIPAA-compliant telehealth practices to maintain compliance while delivering remote care.

7. Use a Compliant Talent Acquisition Process

Establish a compliant talent acquisition process that includes thorough background checks, verification of licenses and credentials, and adherence to equal employment opportunity guidelines. By ensuring compliance in the hiring process, organizations can minimize the risk of employing individuals with a history of compliance violations.

8. Develop Very Clear Policies

Put clear and comprehensive policies and procedures in place that cover all aspects of healthcare compliance, including privacy, security, billing, and ethical conduct. Policies should be readily accessible, regularly reviewed, and updated to reflect changes in regulations or organizational practices.

9. Conduct Regular Compliance Audits

Carry out regular compliance audits to assess the effectiveness of the compliance program, identify areas for improvement, and ensure ongoing adherence to regulatory requirements. Audits should include internal reviews, assessments of documentation and procedures, and external audits if necessary.

10. Address Noncompliance Swiftly

Establish protocols for investigating and resolving compliance violations, implementing corrective actions, and ensuring accountability. Timely response and appropriate disciplinary measures demonstrate a commitment to compliance and discourage further non-compliance.

The Repercussions of Noncompliance

Noncompliance with healthcare regulations can have severe consequences which can include financial penalties, legal actions, damage to reputation, loss of trust, and potential harm to patients. Subsequently, it is essential for healthcare organizations to prioritize compliance and proactively mitigate risks.

To help ensure your organization’s compliance, we recommend using a comprehensive compliance checklist our HIPAA Compliance Checklist.

Source :
https://www.perimeter81.com/blog/compliance/healthcare-compliance