By: Shannon Murphy, Greg Young March 20, 2024 Read time: 2 min (589 words)
On February 26, 2024, the National Institute of Standards and Technology (NIST) released the official 2.0 version of the Cyber Security Framework (CSF).
What is the NIST CSF?
The NIST CSF is a series of guidelines and best practices to reduce cyber risk and improve security posture. The framework is divided into pillars or “functions” and each function is subdivided into “categories” which outline specific outcomes.
As titled, it is a framework. Although it was published by a standards body, it is not a technical standard.
https://www.nist.gov/cyberframework
What Is the CSF Really Used For?
Unlike some very prescriptive NIST standards (for example, crypto standards like FIPS-140-2), the CSF framework is similar to the ISO 27001 certification guidance. It aims to set out general requirements to inventory security risk, design and implement compensating controls, and adopt an overarching process to ensure continuous improvement to meet shifting security needs.
It’s a high-level map for security leaders to identify categories of protection that are not being serviced well. Think of the CSF as a series of buckets with labels. You metaphorically put all the actions, technology deployments, and processes you do in cybersecurity into these buckets, and then look for buckets with too little activity in them or have too much activity — or repetitive activity — and not enough of other requirements in them.
The CSF hierarchy is that Functions contain many Categories — or in other words, there are big buckets that contain smaller buckets.
What Is New in CSF 2.0?
The most noteworthy change is the introduction of Governance as a sixth pillar in the CSF Framework. This shift sees governance being given significantly more importance from just a mention within the previous five Categories to now being its owna separate Function.
According to NIST the Govern function refers to how an organization’s, “cybersecurity risk management strategy, expectations, and policy are established, communicated, and monitored.” This is a positive and needed evolution, as when governance is weak, it often isn’t restricted to a single function (e.g. IAM) and can be systemic.
Governance aligns to a broader paradigm shift where we see cybersecurity becoming highly relevant within the business context as an operational risk. The Govern expectation is cybersecurity is integrated into the broader enterprise risk management strategy and requires dedicated accountability and oversight.
There are some other reassignments and minor changes in the remaining five Categories. CSF version 1.0 was published in 2014, and 1.1 in 2018. A lot has changed in security since then. The 2.0 update acknowledges that a review has been conducted.
As a framework, the CISO domain has not radically changed. Yes, the technology has radically evolved, but the greatest evolution in the CISO role really has been around governance: greater interaction with C-suite and board, while some activities have been handed off to operations.
So How Will This Impact Me in the Short Term?
The update to the NIST CSF provides a fresh opportunity to security leaders to start or reopen conversations with business leaders on evolving needs.
The greatest impact will be to auditors and consultants who will need to make formatting changes to their templates and work products to align with version 2.0.
CISOs and security leaders will have to make some similar changes to how they track and report compliance.
But overall, the greatest impact (aside from some extra billable cybersecurity consulting fees) will be a boost of relevance to the CSF that could attract new adherents both through security leaders choosing to look at themselves through the CSF lens and management asking the same of CISOs.
Just in time for Data Privacy Day 2024 on January 28, the EU Commission is calling for evidence to understand how the EU’s General Data Protection Regulation (GDPR) has been functioning now that we’re nearing the 6th anniversary of the regulation coming into force.
We’re so glad they asked, because we have some thoughts. And what better way to celebrate privacy day than by discussing whether the application of the GDPR has actually done anything to improve people’s privacy?
The answer is, mostly yes, but in a couple of significant ways – no.
Overall, the GDPR is rightly seen as the global gold standard for privacy protection. It has served as a model for what data protection practices should look like globally, it enshrines data subject rights that have been copied across jurisdictions, and when it took effect, it created a standard for the kinds of privacy protections people worldwide should be able to expect and demand from the entities that handle their personal data. On balance, the GDPR has definitely moved the needle in the right direction for giving people more control over their personal data and in protecting their privacy.
In a couple of key areas, however, we believe the way the GDPR has been applied to data flowing across the Internet has done nothing for privacy and in fact may even jeopardize the protection of personal data. The first area where we see this is with respect to cross-border data transfers. Location has become a proxy for privacy in the minds of many EU data protection regulators, and we think that is the wrong result. The second area is an overly broad interpretation of what constitutes “personal data” by some regulators with respect to Internet Protocol or “IP” addresses. We contend that IP addresses should not always count as personal data, especially when the entities handling IP addresses have no ability on their own to tie those IP addresses to individuals. This is important because the ability to implement a number of industry-leading cybersecurity measures relies on the ability to do threat intelligence on Internet traffic metadata, including IP addresses.
Location should not be a proxy for privacy
Fundamentally, good data security and privacy practices should be able to protect personal data regardless of where that processing or storage occurs. Nevertheless, the GDPR is based on the idea that legal protections should attach to personal data based on the location of the data – where it is generated, processed, or stored. Articles 44 to 49 establish the conditions that must be in place in order for data to be transferred to a jurisdiction outside the EU, with the idea that even if the data is in a different location, the privacy protections established by the GDPR should follow the data. No doubt this approach was influenced by political developments around government surveillance practices, such as the revelations in 2013 of secret documents describing the relationship between the US NSA (and its Five Eyes partners) and large Internet companies, and that intelligence agencies were scooping up data from choke points on the Internet. And once the GDPR took effect, many data regulators in the EU were of the view that as a result of the GDPR’s restrictions on cross-border data transfers, European personal data simply could not be processed in the United States in a way that would be consistent with the GDPR.
This issue came to a head in July 2020, when the European Court of Justice (CJEU), in its “Schrems II” decision1, invalidated the EU-US Privacy Shield adequacy standard and questioned the suitability of the EU standard contractual clauses (a mechanism entities can use to ensure that GDPR protections are applied to EU personal data even if it is processed outside the EU). The ruling in some respects left data protection regulators with little room to maneuver on questions of transatlantic data flows. But while some regulators were able to view the Schrems II ruling in a way that would still allow for EU personal data to be processed in the United States, other data protection regulators saw the decision as an opportunity to double down on their view that EU personal data cannot be processed in the US consistent with the GDPR, therefore promoting the misconception that data localization should be a proxy for data protection.
In fact, we would argue that the opposite is the case. From our own experience and according to recent research2, we know that data localization threatens an organization’s ability to achieve integrated management of cybersecurity risk and limits an entity’s ability to employ state-of-the-art cybersecurity measures that rely on cross-border data transfers to make them as effective as possible. For example, Cloudflare’s Bot Management product only increases in accuracy with continued use on the global network: it detects and blocks traffic coming from likely bots before feeding back learnings to the models backing the product. A diversity of signal and scale of data on a global platform is critical to help us continue to evolve our bot detection tools. If the Internet were fragmented – preventing data from one jurisdiction being used in another – more and more signals would be missed. We wouldn’t be able to apply learnings from bot trends in Asia to bot mitigation efforts in Europe, for example. And if the ability to identify bot traffic is hampered, so is the ability to block those harmful bots from services that process personal data.
The need for industry-leading cybersecurity measures is self-evident, and it is not as if data protection authorities don’t realize this. If you look at any enforcement action brought against an entity that suffered a data breach, you see data protection regulators insisting that the impacted entities implement ever more robust cybersecurity measures in line with the obligation GDPR Article 32 places on data controllers and processors to “develop appropriate technical and organizational measures to ensure a level of security appropriate to the risk”, “taking into account the state of the art”. In addition, data localization undermines information sharing within industry and with government agencies for cybersecurity purposes, which is generally recognized as vital to effective cybersecurity.
In this way, while the GDPR itself lays out a solid framework for securing personal data to ensure its privacy, the application of the GDPR’s cross-border data transfer provisions has twisted and contorted the purpose of the GDPR. It’s a classic example of not being able to see the forest for the trees. If the GDPR is applied in such a way as to elevate the priority of data localization over the priority of keeping data private and secure, then the protection of ordinary people’s data suffers.
Applying data transfer rules to IP addresses could lead to balkanization of the Internet
The other key way in which the application of the GDPR has been detrimental to the actual privacy of personal data is related to the way the term “personal data” has been defined in the Internet context – specifically with respect to Internet Protocol or “IP” addresses. A world where IP addresses are always treated as personal data and therefore subject to the GDPR’s data transfer rules is a world that could come perilously close to requiring a walled-off European Internet. And as noted above, this could have serious consequences for data privacy, not to mention that it likely would cut the EU off from any number of global marketplaces, information exchanges, and social media platforms.
This is a bit of a complicated argument, so let’s break it down. As most of us know, IP addresses are the addressing system for the Internet. When you send a request to a website, send an email, or communicate online in any way, IP addresses connect your request to the destination you’re trying to access. These IP addresses are the key to making sure Internet traffic gets delivered to where it needs to go. As the Internet is a global network, this means it’s entirely possible that Internet traffic – which necessarily contains IP addresses – will cross national borders. Indeed, the destination you are trying to access may well be located in a different jurisdiction altogether. That’s just the way the global Internet works. So far, so good.
But if IP addresses are considered personal data, then they are subject to data transfer restrictions under the GDPR. And with the way those provisions have been applied in recent years, some data regulators were getting perilously close to saying that IP addresses cannot transit jurisdictional boundaries if it meant the data might go to the US. The EU’s recent approval of the EU-US Data Privacy Framework established adequacy for US entities that certify to the framework, so these cross-border data transfers are not currently an issue. But if the Data Privacy Framework were to be invalidated as the EU-US Privacy Shield was in the Schrems II decision, then we could find ourselves in a place where the GDPR is applied to mean that IP addresses ostensibly linked to EU residents can’t be processed in the US, or potentially not even leave the EU.
If this were the case, then providers would have to start developing Europe-only networks to ensure IP addresses never cross jurisdictional boundaries. But how would people in the EU and US communicate if EU IP addresses can’t go to the US? Would EU citizens be restricted from accessing content stored in the US? It’s an application of the GDPR that would lead to the absurd result – one surely not intended by its drafters. And yet, in light of the Schrems II case and the way the GDPR has been applied, here we are.
A possible solution would be to consider that IP addresses are not always “personal data” subject to the GDPR. In 2016 – even before the GDPR took effect – the Court of Justice of the European Union (CJEU) established the view in Breyer v. Bundesrepublik Deutschland that even dynamic IP addresses, which change with every new connection to the Internet, constituted personal data if an entity processing the IP address could link the IP addresses to an individual. While the court’s decision did not say that dynamic IP addresses are always personal data under European data protection law, that’s exactly what EU data regulators took from the decision, without considering whether an entity actually has a way to tie the IP address to a real person3.
The question of when an identifier qualifies as “personal data” is again before the CJEU: In April 2023, the lower EU General Court ruled in SRB v EDPS4 that transmitted data can be considered anonymised and therefore not personal data if the data recipient does not have any additional information reasonably likely to allow it to re-identify the data subjects and has no legal means available to access such information. The appellant – the European Data Protection Supervisor (EDPS) – disagrees. The EDPS, who mainly oversees the privacy compliance of EU institutions and bodies, is appealing the decision and arguing that a unique identifier should qualify as personal data if that identifier could ever be linked to an individual, regardless of whether the entity holding the identifier actually had the means to make such a link.
If the lower court’s common-sense ruling holds, one could argue that IP addresses are not personal data when those IP addresses are processed by entities like Cloudflare, which have no means of connecting an IP address to an individual. If IP addresses are then not always personal data, then IP addresses will not always be subject to the GDPR’s rules on cross-border data transfers.
Although it may seem counterintuitive, having a standard whereby an IP address is not necessarily “personal data” would actually be a positive development for privacy. If IP addresses can flow freely across the Internet, then entities in the EU can use non-EU cybersecurity providers to help them secure their personal data. Advanced Machine Learning/predictive AI techniques that look at IP addresses to protect against DDoS attacks, prevent bots, or otherwise guard against personal data breaches will be able to draw on attack patterns and threat intelligence from around the world to the benefit of EU entities and residents. But none of these benefits can be realized in a world where IP addresses are always personal data under the GDPR and where the GDPR’s data transfer rules are interpreted to mean IP addresses linked to EU residents can never flow to the United States.
Keeping privacy in focus
On this Data Privacy Day, we urge EU policy makers to look closely at how the GDPR is working in practice, and to take note of the instances where the GDPR is applied in ways that place privacy protections above all other considerations – even appropriate security measures mandated by the GDPR’s Article 32 that take into account the state of the art of technology. When this happens, it can actually be detrimental to privacy. If taken to the extreme, this formulaic approach would not only negatively impact cybersecurity and data protection, but even put into question the functioning of the global Internet infrastructure as a whole, which depends on cross-border data flows. So what can be done to avert this?
First, we believe EU policymakers could adopt guidelines (if not legal clarification) for regulators that IP addresses should not be considered personal data when they cannot be linked by an entity to a real person. Second, policymakers should clarify that the GDPR’s application should be considered with the cybersecurity benefits of data processing in mind. Building on the GDPR’s existing recital 49, which rightly recognizes cybersecurity as a legitimate interest for processing, personal data that needs to be processed outside the EU for cybersecurity purposes should be exempted from GDPR restrictions to international data transfers. This would avoid some of the worst effects of the mindset that currently views data localization as a proxy for data privacy. Such a shift would be a truly pro-privacy application of the GDPR.
Visit 1.1.1.1 from any device to get started with our free app that makes your Internet faster and safer.
To learn more about our mission to help build a better Internet, start here. If you’re looking for a new career direction, check out our open positions.
By: Shinji Robert Arasawa, Joshua Aquino, Charles Steven Derion, Juhn Emmanuel Atanque, Francisrey Joshua Castillo, John Carlo Marquez, Henry Salcedo, John Rainier Navato, Arianne Dela Cruz, Raymart Yambot, Ian Kenefick January 09, 2024 Read time: 8 min (2105 words)
A threat actor we track under the Intrusion set Water Curupira (known to employ the Black Basta ransomware) has been actively using Pikabot. a loader malware with similarities to Qakbot, in spam campaigns throughout 2023.
Pikabot is a type of loader malware that was actively used in spam campaigns by a threat actor we track under the Intrusion set Water Curupira in the first quarter of 2023, followed by a break at the end of June that lasted until the start of September 2023. Other researchers have previously noted its strong similarities to Qakbot, the latter of which was taken down by law enforcement in August 2023. An increase in the number of phishing campaigns related to Pikabot was recorded in the last quarter of 2023, coinciding with the takedown of Qakbot — hinting at the possibility that Pikabot might be a replacement for the latter (with DarkGate being another temporary replacement in the wake of the takedown).
Pikabot’s operators ran phishing campaigns, targeting victims via its two components — a loader and a core module — which enabled unauthorized remote access and allowed the execution of arbitrary commands through an established connection with their command-and-control (C&C) server. Pikabot is a sophisticated piece of multi-stage malware with a loader and core module within the same file, as well as a decrypted shellcode that decrypts another DLL file from its resources (the actual payload).
In general, Water Curupira conducts campaigns for the purpose of dropping backdoors such as Cobalt Strike, leading to Black Basta ransomware attacks (coincidentally, Black Basta also returned to operations in September 2023). The threat actor conducted several DarkGate spam campaigns and a small number of IcedID campaigns in the early weeks of the third quarter of 2023, but has since pivoted exclusively to Pikabot.
Pikabot, which gains initial access to its victim’s machine through spam emails containing an archive or a PDF attachment, exhibits the same behavior and campaign identifiers as Qakbot.
Figure 1. Our observations from the infection chain based on Trend’s investigation
Initial access via email
The malicious actors who send these emails employ thread-hijacking, a technique where malicious actors use existing email threads (possibly stolen from previous victims) and create emails that look like they were meant to be part of the thread to trick recipients into believing that they are legitimate. Using this technique increases the chances that potential victims would select malicious links or attachments. Malicious actors send these emails using addresses (created either through new domains or free email services) with names that can be found in original email threads hijacked by the malicious actor. The email contains most of the content of the original thread, including the email subject, but adds a short message on top directing the recipient to open the email attachment.
This attachment is either a password-protected archive ZIP file containing an IMG file or a PDF file. The malicious actor includes the password in the email message. Note that the name of the file attachment and its password vary for each email.
Figure 2. Sample email with a malicious ZIP attachmentFigure 3. Sample email with a malicious PDF attachment
The emails containing PDF files have a shorter message telling the recipient to check or view the email attachment.
The first stage of the attack
The attached archive contains a heavily obfuscated JavaScript (JS) with a file size amounting to more than 100 KB. Once executed by the victim, the script will attempt to execute a series of commands using conditional execution.
Figure 4. Files extracted to the attached archive (.zip or .img)Figure 5. Deobfuscated JS command
The script attempts command execution using cmd.exe. If this initial attempt is unsuccessful, the script proceeds with the following steps: It echoes a designated string to the console and tries to ping a specified target using the same string. In case the ping operation fails, the script employs Curl.exe to download the Pikabot payload from an external server, saving the file in the system’s temporary directory.
Subsequently, the script will retry the ping operation. If the retry is also unsuccessful, it uses rundll32.exe to execute the downloaded Pikabot payload (now identified as a .dll file) with “Crash” as the export parameter. The sequence of commands concludes by exiting the script with the specified exit code, ciCf51U2FbrvK.
We were able to observe another attack chain where the malicious actors implemented a more straightforward attempt to deliver the payload. As before, similar phishing techniques were performed to trick victims into downloading and executing malicious attachments. In this case, password-protected archive attachments were deployed, with the password contained in the body of the email.
However, instead of a malicious script, an IMG file was extracted from the attachment. This file contained two additional files — an LNK file posing as a Word document and a DLL file, which turned out to be the Pikabot payload extracted straight from the email attachment:
Figure 6. The content of the IMG file
Contrary to the JS file observed earlier, this chain maintained its straightforward approach even during the execution of the payload.
Once the victim is lured into executing the LNK file, rundll32.exe will be used to run the Pikabot DLL payload using an export parameter, “Limit”.
The content of the PDF file is disguised to look like a file hosted on Microsoft OneDrive to convince the recipient that the attachment is legitimate. Its primary purpose is to trick victims into accessing the PDF file content, which is a link to download malware.
Figure 7. Malicious PDF file disguised to look like a OneDrive attachment; note the misspelling of the word “Download”
When the user selects the download button, it will attempt to access a malicious URL, then proceed to download a malicious JS file (possibly similar to the previously mentioned JS file).
The delivery of the Pikabot payload via PDF attachment is a more recent development, emerging only in the fourth quarter of 2023.
We discovered an additional variant of the malicious downloader that employed obfuscation methods involving array usage and manipulation:
Figure 8. Elements of array “_0x40ee” containing download URLs and JS methods used for further execution
Nested functions employed array manipulation methods using “push” and “shift,” introducing complexity to the code’s structure and concealing its flow to hinder analysis. The presence of multiple download URLs, the dynamic creation of random directories using the mkdir command, and the use of Curl.exe, as observed in the preceding script, are encapsulated within yet another array. The JavaScript will run multiple commands in an attempt to retrieve the malicious payload from different external websites using Curl.exe, subsequently storing it in a random directory created using mkdir.
Figure 9. Payload retrieval commands using curl.exe
The rundll32.exe file will continue to serve as the execution mechanism for the payload, incorporating its export parameter.
Figure 10. Payload execution using rundll32.exe
The Pikabot payload
We analyzed the DLL file extracted from the archive shown in Figure 6 and found it to be a sample of a 32-bit DLL file with 1515 exports. Calling its export function “Limit”, the file will decrypt and execute a shellcode that identifies if the process is being debugged by calling the Windows API NtQueryInformationProcess twice with the flag 0x7 (ProcessDebugPort) on the first call and 0x1F ProcessDebugFlags on the second call. This shellcode also decrypts another DLL file that it loads into memory and then eventually executes.
Figure 11. The shellcode calling the entry point of the decrypted DLL file
The decrypted DLL file will execute another anti-analysis routine by loading incorrect libraries and other junk to detect sandboxes. This routine seems to be copied from a certain GitHub article.
Security/Virtual Machine/Sandbox DLL files
Real DLL files
Fake DLL files
cmdvrt.32.dll
kernel32.dll
NetProjW.dll
cmdvrt.64.dll
networkexplorer.dll
Ghofr.dll
cuckoomon.dll
NlsData0000.dll
fg122.dll
pstorec.dll
avghookx.dll
avghooka.dll
snxhk.dll
api_log.dll
dir_watch.dll
wpespy.dll
Table 1. The DLL files loaded to detect sandboxes
After performing the anti-analysis routine, the malware loads a set of PNG images from its resources section which contains an encrypted chunk of the core module and then decrypts them. Once the core payload has been decrypted, the Pikabot injector creates a suspended process (%System%\SearchProtocolHost) and injects the core module into it. The injector uses indirect system calls to hide its injection.
Figure 12. Loading the PNG images to build the core module
Resolving the necessary APIs is among the malware’s initial actions. Using a hash of each API (0xF4ACDD8, 0x03A5AF65E, and 0xB1D50DE4), Pikabot uses two functions to obtain the addresses of the three necessary APIs, GetProcAddress, LoadLibraryA, and HeapFree. This process is done by looking through kernel32.dll exports. The rest of the used APIs are resolved using GetProcAddress with decrypted strings. Other pertinent strings are also decrypted during runtime before they are used.
Figure 13. Harvesting the GetProcAddress and LoadLibrary API
The Pikabot core module checks the system’s languages and stops its execution if the language is any of the following:
Russian (Russia)
Ukrainian (Ukraine)
It will then ensure that only one instance of itself is running by creating a hard-coded mutex, {A77FC435-31B6-4687-902D-24153579C738}.
The next stage of the core module involves obtaining details about the victim’s system and forwarding them to a C&C server. The collected data uses a JSON format, with every data item using the wsprintfW function to fill its position. The stolen data will look like the image in Figure 13 but with the collected information before encryption:
Figure 14. Stolen information in JSON format before encryption
Pikabot seems to have a binary version and a campaign ID. The keys 0fwlm4g and v2HLF5WIO are present in the JSON data, with the latter seemingly being a campaign ID.
The malware creates a named pipe and uses it to temporarily store the additional information gathered by creating the following processes:
whoami.exe /all
ipconfig.exe /all
netstat.exe -aon
Each piece of information returned will be encrypted before the execution of the process.
A list of running processes on the system will also be gathered and encrypted by calling CreateToolHelp32Snapshot and listing processes through Process32First and Process32Next.
Once all the information is gathered, it will be sent to one of the following IP addresses appended with the specific URL, cervicobrachial/oIP7xH86DZ6hb?vermixUnintermixed=beatersVerdigrisy&backoff=9zFPSr:
70[.]34[.]209[.]101:13720
137[.]220[.]55[.]190:2223
139[.]180[.]216[.]25:2967
154[.]61[.]75[.]156:2078
154[.]92[.]19[.]139:2222
158[.]247[.]253[.]155:2225
172[.]233[.]156[.]100:13721
However, as of writing, these sites are inaccessible.
C&C servers and impact
As previously mentioned, Water Curupira conducts campaigns to drop backdoors such as Cobalt Strike, which leads to Black Basta ransomware attacks.It is this potential association with a sophisticated type of ransomware such as Black Basta that makes Pikabot campaigns particularly dangerous.
The threat actor also conducted several DarkGate spam campaigns and a small number of IcedID campaigns during the early weeks of the third quarter of 2023, but has since pivoted exclusively to Pikabot.
Lastly, we have observed distinct clusters of Cobalt Strike beacons with over 70 C&C domains leading to Black Basta, and which have been dropped via campaigns conducted by this threat actor.
Security recommendations
To avoid falling victim to various online threats such as phishing, malware, and scams, users should stay vigilant when it comes to emails they receive. The following are some best practices in user email security:
Always hover over embedded links with the pointer to learn where the link leads.
Check the sender’s identity. Unfamiliar email addresses, mismatched email and sender names, and spoofed company emails are signs that the sender has malicious intent.
If the email claims to come from a legitimate company, verify both the sender and the email content before downloading attachments or selecting embedded links.
Keep operating systems and all pieces of software updated with the latest patches.
Regularly back up important data to an external and secure location. This ensures that even if you fall victim to a phishing attack, you can restore your information.
A multilayered approach can help organizations guard possible entry points into their system (endpoint, email, web, and network). Security solutions can detect malicious components and suspicious behavior, which can help protect enterprises.
Trend Vision One™ provides multilayered protection and behavior detection, which helps block questionable behavior and tools before ransomware can do any damage.
Trend Cloud One™ – Workload Security protects systems against both known and unknown threats that exploit vulnerabilities. This protection is made possible through techniques such as virtual patching and machine learning.
Trend Micro™ Deep Discovery™ Email Inspector employs custom sandboxing and advanced analysis techniques to effectively block malicious emails, including phishing emails that can serve as entry points for ransomware.
Trend Micro Apex One™ offers next-level automated threat detection and response against advanced concerns such as fileless threats and ransomware, ensuring the protection of endpoints.
Indicators of Compromise (IOCs)
The indicators of compromise for this blog entry can be found here.
By: Trend Micro December 06, 2023 Read time: 4 min (971 words)
In this blog entry, we discuss predictions from Trend Micro’s team of security experts about the drivers of change that will figure prominently in 2024.
Digital transformations in the year ahead will be led by organizations pursuing a pioneering edge from the integration of emergent technologies. Advances in cloud technology, artificial intelligence and machine learning (AI/ML), and Web3 are poised to reshape the threat landscape, giving it new frontiers outside the purview of traditional defenses. However, these technological developments are only as efficient as the IT structures that support them. In 2024, business leaders will have to take measures to ensure that their organization’s systems and processes are equipped to stay in step with these modern solutions — not to mention the newfound security challenges that come with implementing and securing them.
As the new year draws closer, decision-makers will need to stay on top of key trends and priority areas in enterprise cybersecurity if they are to make room for growth and fend off any upcoming threats along their innovation journey. In this blog entry, we discuss predictions from Trend Micro’s team of security experts about the drivers of change that will figure prominently next year.
Misconfigurations will allow cybercriminals to scale up their attacks using cloud-native worms
Enterprises should come into 2024 prepared to ensure that their cloud resources can’t be turned against them in “living-off-the-cloud” attacks. Security teams need to closely monitor cloud environments in anticipation of cyberattacks that, tailored with worming capabilities, can also abuse cloud misconfigurations to gain a foothold in their targets and use rootkits for persistence. Cloud technologies like containerized applications are especially at risk as once infected, these can serve as a launchpad from which attackers can spread malicious payloads to other accounts and services. Given their ability to infect multiple containers at once, leverage vulnerabilities at scale, and automate various tasks like reconnaissance, exploitation, and achieving persistence, worms will endure as a prominent tactic among cybercriminals next year.
AI-generated media will give rise to more sophisticated social engineering scams
The gamut of use cases for generative AI will be a boon not only for enterprises but also for fraudsters seeking new ways of profiteering in 2024. Though they’re often behind the curve when it comes to new technologies, expect cybercriminals — swayed by the potential of lucrative pay — to incorporate AI-generated lures as part of their upgraded social engineering attacks. Notably, despite the shutdown of malicious large language model (LLM) tool WormGPT, similar tools could still emerge from the dark web. In the interim, cybercriminals will also continue to find other ways to circumvent the limitations of legitimate AI tools available online. In addition to their use of digital impostors that combine various AI-powered tools in emerging threats like virtual kidnapping, we predict that malicious actors will resort specifically to voice cloning in more targeted attacks.
The rising tide of data poisoning will be a scourge on ML models under training
Integrating machine-learning (ML) models into their operations promises to be a real game changer for businesses that are banking on the potential of these models to supercharge innovation and productivity. As we step into 2024, attempts to corrupt the training data of these models will start gaining ground. Threat actors will likely carry out these attacks by taking advantage of a model’s data-collection phase or by compromising its data storage or data pipeline infrastructure. Specialized models using focused datasets will also be more vulnerable to data poisoning than LLMs and generative AI models trained on extensive datasets, which will prompt security practitioners to pay closer attention to the risks associated with tapping into external resources for ML training data.
Attackers will take aim at software supply chains through their CI/CD pipelines
Software supply chains will have a target on their back in 2024, as cybercriminals will aim to infiltrate them through their continuous integration and delivery (CI/CD) systems. For example, despite their use in expediting software development, components and code sourced from third-party libraries and containers are not without security risks, such as lacking thorough security audits, containing malicious or outdated components, or harboring overlooked vulnerabilities that could open the door to code-injection attacks. The call for developers to be wary of anything sourced from third parties will therefore remain relevant next year. Similarly, to safeguard the resilience of critical software development pipelines and weed out bugs in the coming year, DevOps practitioners should exercise caution and conduct routine scans of any external code they plan to use.
New extortion schemes and criminal gangs will be built around the blockchain
Whereas public blockchains are hardened by continuous cyberattacks, the same can’t be said of their permissioned counterparts because of the latter’s centralized nature. This lack of hard-won resilience will drive malicious actors to develop new extortion business models specific to private blockchains next year. In such extortion operations, criminals could use stolen keys to insert malicious data or modify existing records on the blockchain and then demand a payoff to stay mum on the attack. Threat actors can also strong-arm their victims into paying the ransom by wresting control of enough nodes to encrypt an entire private blockchain. As for criminal groups, we predict that 2024 will see the debut of the first criminal organizations running entirely on blockchains with smart contract or decentralized autonomous organizations (DAOs).
Countering future cyberthreats
Truly transformative technologies inevitably cross the threshold into standard business operations. But as they make that transition from novel to industry norm, newly adopted tools and solutions require additional layers of protection if they are to contribute to an enterprise’s expansion. So long as their security stance is anchored on preparedness and due diligence, organizations stand to reap the benefits from a growing IT stack without exposing themselves to unnecessary risks. To learn more about the key security considerations and challenges that lie ahead for organizations and end users, read our report, “Critical Scalability: Trend Micro Security Predictions for 2024.”
Dirk Schrader Published: November 14, 2023 Updated: November 24, 2023
In the wake of escalating cyber-attacks and data breaches, the ubiquitous advice of “don’t share your password” is no longer enough. Passwords remain the primary keys to our most important digital assets, so following password security best practices is more critical than ever. Whether you’re securing email, networks, or individual user accounts, following password best practices can help protect your sensitive information from cyber threats.
Read this guide to explore password best practices that should be implemented in every organization — and learn how to protect vulnerable information while adhering to better security strategies.
The Secrets of Strong Passwords
A strong password is your first line of defense when it comes to protecting your accounts and networks. Implement these standard password creation best practices when thinking about a new password:
Complexity: Ensure your passwords contain a mix of uppercase and lowercase letters, numbers, and special characters. It should be noted that composition rules, such as lowercase, symbols, etc. are no longer recommended by NIST — so use at your own discretion.
Length: Longer passwords are generally stronger — and usually, length trumps complexity. Aim for at least 6-8 characters.
Unpredictability: Avoid using common phrases or patterns. Avoid using easily guessable information like birthdays or names. Instead, create unique strings that are difficult for hackers to guess.
Combining these factors makes passwords harder to guess. For instance, if a password is 8 characters long and includes uppercase letters, lowercase letters, numbers and special characters, the total possible combinations would be (26 + 26 + 10 + 30)^8. This astronomical number of possibilities makes it exceedingly difficult for an attacker to guess the password.
Of course, given NIST’s updated guidance on passwords, the best approach to effective password security is using a password manager — this solution will not only help create and store your passwords, but it will automatically reject common, easy-to-guess passwords (those included in password dumps). Password managers greatly increase security against the following attack types.
Password-Guessing Attacks
Understanding the techniques that adversaries use to guess user passwords is essential for password security. Here are some of the key attacks to know about:
Brute-Force Attack
In a brute-force attack, an attacker systematically tries every possible combination of characters until the correct password is found. This method is time-consuming but can be effective if the password is weak.
Strong passwords help thwart brute force attacks because they increase the number of possible combinations an attacker must try, making it unlikely they can guess the password within a reasonable timeframe.
Dictionary Attack
A dictionary attack is a type of brute-force attack in which an adversary uses a list of common words, phrases and commonly used passwords to try to gain access.
Unique passwords are essential to thwarting dictionary attacks because attackers rely on common words and phrases. Using a password that isn’t a dictionary word or a known pattern significantly reduces the likelihood of being guessed. For example, the string “Xc78dW34aa12!” is not in the dictionary or on the list of commonly used passwords, making it much more secure than something generic like “password.”
Dictionary Attack with Character Variations
In some dictionary attacks, adversaries also use standard words but also try common character substitutions, such as replacing ‘a’ with ‘@’ or ‘e’ with ‘3’. For example, in addition to trying to log on using the word “password”, they might also try the variant “p@ssw0rd”.
Choosing complex and unpredictable passwords is necessary to thwart these attacks. By using unique combinations and avoiding easily guessable patterns, you make it challenging for attackers to guess your password.
How Password Managers Enhance Security
Password managers are indispensable for securely storing and organizing your passwords. These tools offer several key benefits:
Security: Password managers store passwords and enter them for you, eliminating the need for users to remember them all. All users need to remember is the master password for their password manager tool. Therefore, users can use long, complex passwords as recommended by best practices without worrying about forgetting their passwords or resorting to insecure practices like writing passwords down or reusing the same password for multiple sites or applications.
Password generation: Password managers can generate a strong and unique password for user accounts, eliminating the need for individuals to come up with them.
Encryption: Password managers encrypt password vaults, ensuring the safety of data — even if it is compromised.
Convenience: Password managers enable users to easily access passwords across multiple devices.
When selecting a password manager, it’s important to consider your organization’s specific needs, such as support for the platforms you use, price, ease of use and vendor breach history. Conduct research and read reviews to identify the one that best aligns with your organization’s requirements. Some noteworthy options include Netwrix Password Secure, LastPass, Dashlane, 1Password and Bitwarden.
How Multifactor Authentication (MFA) Adds an Extra Layer of Security
Multifactor authentication strengthens security by requiring two or more forms of verification before granting access. Specifically, you need to provide at least two of the following authentication factors:
Something you know: The classic example is your password.
Something you have: Usually this is a physical device like a smartphone or security token.
Something you are: This is biometric data like a fingerprint or facial recognition.
MFA renders a stolen password worthless, so implement it wherever possible.
Password Expiration Management
Password expiration policies play a crucial role in maintaining strong password security. Using a password manager that creates strong passwords also has an influence on password expiration. If you do not use a password manager yet, implement a strategy to check all passwords within your organization; with a rise in data breaches, password lists (like the known rockyou.txt and its variations) used in brute-force attacks are constantly growing. The website haveibeenpawned.com offers a service to check whether a certain password has been exposed. Here’s what users should know about password security best practices related to password expiration:
Follow policy guidelines: Adhere to your organization’s password expiration policy. This includes changing your password when prompted and selecting a new, strong password that meets the policy’s requirements.
Set reminders: If your organization doesn’t enforce password expiration via notifications, set your own reminders to change your password when it’s due. Regularly check your email or system notifications for prompts.
Avoid obvious patterns: When changing your password, refrain from using variations of the previous one or predictable patterns like “Password1,” “Password2” and so on.
Report suspicious activity: If you notice any suspicious account activity or unauthorized password change requests, report them immediately to your organization’s IT support service or helpdesk.
Be cautious with password reset emails: Best practice for good password security means being aware of scams. If you receive an unexpected email prompting you to reset your password, verify its authenticity. Phishing emails often impersonate legitimate organizations to steal your login credentials.
Password Security and Compliance
Compliance standards require password security and password management best practices as a means to safeguard data, maintain privacy and prevent unauthorized access. Here are a few of the laws that require password security:
HIPAA (Health Insurance Portability and Accountability Act): HIPAA mandates that healthcare organizations implement safeguards to protect electronic protected health information (ePHI), which includes secure password practices.
PCI DSS (Payment Card Industry Data Security Standard): PCI DSS requires organizations that handle payment card data on their website to implement strong access controls, including password security, to protect cardholder data.
GDPR (General Data Protection Regulation): GDPR requires organizations that store or process the data of EU residents to implement appropriate security measures to protect personal data. Password security is a fundamental aspect of data protection under GDPR.
FERPA (Family Educational Rights and Privacy Act): FERPA governs the privacy of student education records. It includes requirements for securing access to these records, which involves password security.
Organizations subject to these compliance standards need to implement robust password policies and password security best practices. Failure to do so can result in steep fines and other penalties.
There are also voluntary frameworks that help organizations establish strong password policies. Two of the most well known are the following:
NIST Cybersecurity Framework: The National Institute of Standards and Technology (NIST) provides guidelines and recommendations, including password best practices, to enhance cybersecurity.
ISO 27001: ISO 27001 is an international standard for information security management systems (ISMSs). It includes requirements related to password management as part of its broader security framework.
Password Best Practices in Action
Now, let’s put these password security best practices into action with an example:
Suppose your name is John Doe and your birthday is December 10, 1985. Instead of using “JohnDoe121085” as your password (which is easily guessable), follow these good password practices:
Create a long, unique (and unguessable) password, such as: “M3an85DJ121!”
If you are looking to strengthen your security, follow these password best practices:
Remove hints or knowledge-based authentication: NIST recommends not using knowledge-based authentication (KBA), such as questions like “What town were you born in?” but instead, using something more secure, like two-factor authentication.
Encrypt passwords: Protect passwords with encryption both when they are stored and when they are transmitted over networks. This makes them useless to any hacker who manages to steal them.
Avoid clear text and reversible forms: Users and applications should never store passwords in clear text or any form that could easily be transformed into clear text. Ensure your password management routine does not use clear text (like in an XLS file).
Choose unique passwords for different accounts: Don’t use the same, or even variations, of the same passwords for different accounts. Try to come up with unique passwords for different accounts.
Use a password management: This can help select new passwords that meet security requirements, send reminders of upcoming password expiration, and help update passwords through a user-friendly interface.
Enforce strong password policies: Implement and enforce strong password policies that include minimum length and complexity requirements, along with a password history rule to prevent the reuse of previous passwords.
Update passwords when needed: You should be checking and – if the results indicate so – updating your passwords to minimize the risk of unauthorized access, especially after data breaches.
Monitor for suspicious activity: Continuously monitor your accounts for suspicious activity, including multiple failed login attempts, and implement account lockouts and alerts to mitigate threats.
Educate users: Conduct or partake in regular security awareness training to learn about password best practices, phishing threats, and the importance of maintaining strong, unique passwords for each account.
Implement password expiration policies: Enforce password expiration policies that require password changes at defined circumstances to enhance security.
How Netwrix Can Help
Adhering to password best practices is vital to safeguarding sensitive information and preventing unauthorized access.
Netwrix Password Secure provides advanced capabilities for monitoring password policies, detecting and responding to suspicious activity and ensuring compliance with industry regulations. With features such as real-time alerts, comprehensive reporting and a user-friendly interface, it empowers organizations to proactively identify and address password-related risks, enforce strong password policies, and maintain strong security across their IT environment.
Conclusion
In a world where cyber threats are constantly evolving, adhering to password management best practices is essential to safeguard your digital presence. First and foremost, create a strong and unique password for each system or application — remember that using a password manager makes it much easier to adhere to this critical best practice. In addition, implement multifactor authentication whenever possible to thwart any attacker who manages to steal your password. By following the guidelines, you can enjoy a safer online experience and protect your valuable digital assets.
Dirk Schrader is a Resident CISO (EMEA) and VP of Security Research at Netwrix. A 25-year veteran in IT security with certifications as CISSP (ISC²) and CISM (ISACA), he works to advance cyber resilience as a modern approach to tackling cyber threats. Dirk has worked on cybersecurity projects around the globe, starting in technical and support roles at the beginning of his career and then moving into sales, marketing and product management positions at both large multinational corporations and small startups. He has published numerous articles about the need to address change and vulnerability management to achieve cyber resilience.
The realm of Network Monitoring Tools, Software, and Vendors is Huge, to say the least. New software, tools, and utilities are being launched almost every year to compete in an ever-changing marketplace of IT monitoring, server monitoring, and system monitoring software.
I’ve test-driven, played with and implemented dozens during my career and this guide rounds up the best ones in an easy-to-read format and highlighted their main strengths and why I think they are in the top class of tools to use in your IT infrastructure and business.
Some of the features I am looking for are device discovery, uptime/downtime indicators, along with robust and thorough alerting systems (via email/SMS), NetFlow and SNMP Integration as well as considerations that are important with any software purchase such as ease of use and value for money.
The features from above were all major points of interest when evaluating software suites for this article and I’ll try to keep this article as updated as possible with new feature sets and improvements as they are released.
Here is our list of the top network monitoring tools:
Auvik – EDITOR’S CHOICE This cloud platform provides modules for LAN monitoring, Wi-Fi monitoring, and SaaS system monitoring. The network monitoring package discovers all devices, maps the network, and then implements automated performance tracking. Get a 14-day free trial.
SolarWinds Network Performance Monitor – FREE TRIAL The leading network monitoring system that uses SNMP to check on network device statuses. This monitoring tool includes autodiscovery that compiles an asset inventory and automatically draws up a network topology map. Runs on Windows Server. Start 30-day free trial.
Checkmk – FREE TRIAL This hybrid IT infrastructure monitoring package includes a comprehensive network monitor that provides device status tracking and traffic analysis functions via the integration with ntop. Available as a Linux install package, Docker package, appliance and cloud application available in cloud marketplaces. Get a 30-day free trial.
Datadog Network Monitoring – FREE TRIAL Provides good visibility over each of the components of your network and the connections between them – be it cloud, on-premises or hybrid environment. Troubleshoot infrastructure, apps and DNS issues effortlessly.
ManageEngine OpManager – FREE TRIAL An SNMP-based network monitor that has great network topology layout options, all based on an autodiscovery process. Installs on Windows Server and Linux.
NinjaOne RMM – FREE TRIAL This cloud-based system provides remote monitoring and management for managed service providers covering the systems of their clients.
Site24x7 Network Monitoring – FREE TRIAL A cloud-based monitoring system for networks, servers, and applications. This tool monitors both physical and virtual resources.
Atera – FREE TRIAL A cloud-based package of remote monitoring and management tools that include automated network monitoring and a network mapping utility.
Below you’ll find an updated list of the Latest Tools & Software to ensure your network is continuously tracked and monitored at all times of the day to ensure the highest up-times possible. Most of them have free Downloads or Trials to get you started for 15 to 30 days to ensure it meets your requirements.
What should you look for in network monitoring tools?
We reviewed the market for network monitoring software and analyzed the tools based on the following criteria:
An automated service that can perform network monitoring unattended
A device discovery routine that automatically creates an asset inventory
A network mapping service that shows live statuses of all devices
Alerts for when problems arise
The ability to communicate with network devices through SNMP
A free trial or a demo for a no-cost assessment
Value for money in a package that provides monitoring for all network devices at a reasonable price
With these selection criteria in mind, we have defined a shortlist of suitable network monitoring tools for all operating systems.
Auvik is a SaaS platform that offers a network discovery and mapping system that automates enrolment and then continues to operate in order to spot changes in network infrastructure. This system is able to centralize and unify the monitoring of multiple sites.
Key Features:
A SaaS package that includes processing power and storage space for system logs as well as the monitoring software
Centralizes the monitoring of networks on multiple sites
Watches over network device statuses
Offers two plans: Essential and Performance
Network traffic analysis included in the higher plan
Monitors virtual LANs as well as physical networks
Autodiscovery service
Network mapping
Alerts for automated monitoring
Integrations with third-party complimentary systems
Why do we recommend it?
Auvik is a cloud-based network monitoring system. It reaches into your network, identifies all connected devices, and then creates a map. While SolarWinds Network Performance Monitor also performs those tasks, Auvik is a much lighter tool that you don’t have to host yourself and you don’t need deep technical knowledge to watch over a network with this automated system.
Auvik’s network monitoring system is automated, thanks to its system of thresholds. The service includes out-of-the-box thresholds that are placed on most of the metrics that the network monitor tracks. It is also possible to create custom thresholds.
Once the monitoring service is operating, if any of the thresholds are crossed, the system raises an alert. This mechanism allows technicians to get on with other tasks, knowing that the thresholds give them time to avert system performance problems that would be noticeable to users.
Network management tools that are included in the Auvik package include configuration management to standardize the settings of network devices and prevent unauthorized changes.
The processing power for Auvik is provided by the service’s cloud servers. However, the system requires collectors to be installed on each monitored site. This software runs on Windows Server and Ubuntu Linux. It is also possible to run the collector on a VM. Wherever the collector is located, the system manager still accesses the service’s console, which is based on the Auvik server, through any standard Web browser.
Who is it recommended for?
Smaller businesses that don’t have a team to support IT would benefit from Auvik. It needs no software maintenance and the system provides automated alerts when issues arise, so your few IT staff can get on with supporting other resources while Auvik looks after the network.
PROS:
A specialized network monitoring tool
Additional network management utilities
Configuration management included
A cloud-based service that is accessible from anywhere through any standard Web browser
Data collectors for Windows Server and Ubuntu Linux
CONS:
The system isn’t expandable with any other Auvik modules
Auvik doesn’t publish its prices by you can access a 14-day free trial.
EDITOR’S CHOICE
Auvik is our top pick for a network monitoring tool because it is a hosted SaaS package that provides all of your network monitoring needs without you needing to maintain the software. The Auvik platform installs an agent on your site and then sets itself up by scanning the network and identifying all devices. The inventory that this system generates gives you details of all of your equipment and provides a basis for network topology maps. Repeated checks on the network gather performance statistics and if any metric crosses a threshold, the tool will generate an alert. You can centralize the monitoring of multiple sites with this service.
PRTG Network Monitor software is commonly known for its advanced infrastructure management capabilities. All devices, systems, traffic, and applications in your network can be easily displayed in a hierarchical view that summarizes performance and alerts. PRTG monitors the entire IT infrastructure using technology such as SNMP, WMI, SSH, Flows/Packet Sniffing, HTTP requests, REST APIs, Pings, SQL, and a lot more.
Key Features:
Autodiscovery that creates and maintains a device inventory
Live network topology maps are available in a range of formats
Monitoring for wireless networks as well as LANs
Multi-site monitoring capabilities
SNMP sensors to gather device health information
Ping to check on device availability
Optional extra sensors to monitor servers and applications
System-wide status overviews and drill-down paths for individual device details
A protocol analyzer to identify high-traffic applications
A packet sniffer to collect packet headers for analysis
Color-coded graphs of live data in the system dashboard
Capacity planning support
Alerts on device problems, resource shortages, and performance issues
Notifications generated from alerts that can be sent out by email or SMS
Available for installation on Windows Server or as a hosted cloud service
Why do we recommend it?
Paessler PRTG Network Monitor is a very flexible package. Not only does it monitor networks, but it can also monitor endpoints and applications. The PRTG system will discover and map your network, creating a network inventory, which is the basis for automated monitoring. You put together your ideal monitoring system by choosing which sensors to turn on. You pay for an allowance of sensors.
It is one of the best choices for organizations with low experience in network monitoring software. The user interface is really powerful and very easy to use.
A very particular feature of PRTG is its ability to monitor devices in the data center with a mobile app. A QR code that corresponds to the sensor is printed out and attached to the physical hardware. The mobile app is used to scan the code and a summary of the device is displayed on the mobile screen.
In summary, Paessler PRTG is a flexible package of sensors that you can tailor to your own needs by deciding which monitors to activate. The SNMP-based network performance monitoring routines include an autodiscovery system that generates a network asset inventory and topology maps. You can also activate traffic monitoring features that can communicate with switches through NetFlow, sFlow, J-Flow, and IPFIX. QoS and NBAR features enable you to keep your time-sensitive applications working properly.
Who is it recommended for?
PRTG is available in a Free edition, which is limited to 100 sensors. This is probably enough to support a small network. Mid-sized and large organizations should be interested in paying for larger allowances of sensors. The tool can even monitor multiple sites from one location.
PROS:
Uses a combination of packet sniffing, WMI, and SNMP to report network performance data
Fully customizable dashboard is great for both lone administrators as well as NOC teams
Drag and drop editor makes it easy to build custom views and reports
Supports a wide range of alert mediums such as SMS, email, and third-party integrations into platforms like Slack
Each sensor is specifically designed to monitor each application, for example, there are prebuilt sensors whose specific purpose is to capture and monitor VoIP activity
Supports a freeware version
CONS:
Is a very comprehensive platform with many features and moving parts that require time to learn
PRTG has a very flexible pricing plan, to get an idea visit their official pricing webpage below. It is free to use for up to 50 sensors. Beyond that you get a 30-day free trial to figure out your network requirements.
SolarWinds Network Performance Monitor is easy to setup and can be ready in no time. The tool automatically discovers network devices and deploys within an hour. Its simple approach to oversee an entire network makes it one of the easiest to use and most intuitive user interfaces.
Key Features:
Automatically Network Discovery and Scanning for Wired and Wifi Computers and Devices
Support for Wide Array of OEM Vendors
Forecast and Capacity Planning
Quickly Pinpoint Issues with Network Performance with NetPath™ Critical Path visualization feature
Easy to Use Performance Dashboard to Analyze Critical Data points and paths across your network
Robust Alerting System with options for Simple/Complex Triggers
Monitor Hardware Health of all Servers, Firewalls, Routers, Switches, Desktops, laptops and more
Real-Time Network and Netflow Monitoring for Critical Network Components and Devices
Why do we recommend it?
SolarWinds Network Performance Monitor is the leading network monitoring tool in the world and this is the system that the other monitor providers are chasing. Like many other network monitors, this system uses the Simple Network Management Protocol (SNMP) to gather reports on network devices. The strength of SolarWinds lies in the deep technical knowledge of its support advisors, which many other providers lack.
The product is highly customizable and the interface is easy to manage and change very quickly. You can customize the web-based performance dashboards, charts, and views. You can design a tailored topology for your entire network infrastructure. You can also create customized dependency-aware intelligent alerts and much more.
The software is sold by separate modules based on what you use. SolarWinds Network Performance Monitor Price starts from $1,995 and is a one-time license including 1st-year maintenance.
SolarWinds NPM has an Extensive Feature list that make it One of the Best Choices for Network Monitoring Solutions
SolarWinds NPM is able to track the performance of networks autonomously through the use of SNMP procedures, producing alerts when problems arise. Alerts are generated if performance dips and also in response to emergency notifications sent out by device agents. This system means that technicians don’t have to watch the monitoring screen all the time because they know that they will be drawn back to fix problems by an email or SMS notification.
NetPath Screenshot
Who is it recommended for?
SolarWinds Network Performance Monitor is an extensive network monitoring system and it is probably over-engineered for use by a small business. Mid-sized and large companies would benefit from using this tool.
PROS:
Supports auto-discovery that builds network topology maps and inventory lists in real-time based on devices that enter the network
Has some of the best alerting features that balance effectiveness with ease of use
Supports both SNMP monitoring as well as packet analysis, giving you more control over monitoring than similar tools
Uses drag and drop widgets to customize the look and feel of the dashboard
Tons of pre-configured templates, reports, and dashboard views
CONS:
This is a feature-rich enterprise tool designed for sysadmin, non-technical users may some features overwhelming
Checkmk is an IT asset monitoring package that has the ability to watch over networks, servers, services, and applications. The network monitoring facilities in this package provide both network device status tracking and network traffic monitoring.
Features of this package include:
Device discovery that cycles continuously, spotting new devices and removing retired equipment
Creation of a network inventory
Registration of switches, routers, firewalls, and other network devices
Creation of a network topology map
Continuous device status monitoring with SNMP
SNMP feature report focus for small businesses
Performance thresholds with alerts
Wireless network monitoring
Protocol analysis
Traffic throughput statistics per link
Switch port monitoring
Gateway transmission speed tracking
Network traffic data extracted with ntop
Can monitor a multi-vendor environment
Why do we recommend it?
The Checkmk combination of network device monitoring and traffic monitoring in one tool is rare. Most network monitoring service creators split those two functions so that you have to buy two separate packages. The Checkmk system also gives you application and server monitoring along with the network monitoring service.
The Checkmk system is easy to set up, thanks to its autodiscovery mechanism. This is based on SNMP. The program will act as an SNMP Manager, send out a broadcast requesting reports from device agents, and then compile the results into an inventory. The agent is the Checkmk package itself if you choose to install the Linux version or it is embedded on a device if you go for the hardware option. If you choose the Checkmk Cloud SaaS option, that platform will install an agent on one of your computers.
The SNMP Manager constantly re-polls for device reports and the values in these appear in the Checkmk device monitoring screen. The platform also updates its network inventory according to the data sent back by device agents in each request/response round. The dashboard also generates a network topology map from information in the inventory. So, that map updates whenever the inventory changes.
While gathering information through SNMP, the tool also scans the headings of passing packets on the network to compile traffic statistics. Basically, the tool provides a packet count which enables it to quickly calculate a traffic throughput rate. Data can also be segmented per protocol, according to the TCP port number in each header.
Who is it recommended for?
Checkmk has a very wide appeal because of its three editions. Checkmk Raw is free and will appeal to small businesses. This is an adaptation of Nagios Core. The paid version of the system is called Checkmk Enterprise and that is designed for mid-sized and large businesses. Checkmk Cloud is a SaaS option.
PROS:
Provides both network device monitoring and traffic tracking
Automatically discovers devices and creates a network inventory
Free version available
Options for on-premises or SaaS delivery
Monitors wireless networks as well as LANs
Available for installation on Linux or as an appliance
Datadog Network Monitoring supervises the performance of network devices. The service is a cloud-based system that is able to explore a network and detect all connected devices. With the information from this research, the network monitor will create an asset inventory and draw up a network topology map. This procedure means that the system performs its own setup routines.
Features of this package include:
Monitors networks anywhere, including remote sites
Joins together on-premises and cloud-based resource monitoring
Integrates with other Datadog modules, such as log management
Offers an overview of all network performance and drill-down details of each device
Facilitates troubleshooting by identifying performance dependencies
Includes DNS server monitoring
Gathers SNMP device reports
Blends performance data from many information sources
Includes data flow monitoring
Offers tag-based packet analysis utilities in the dashboard
Integrates protocol analyzers
Performance threshold baselining based on machine learning
Alerts for warnings over evolving performance issues
Datadog Network Monitoring services are split into two modules that are part of a cloud platform of many system monitoring and management tools. These two packages are called Network Performance Monitoring and Network Device Monitoring, which are both subscription services. While the device monitoring package works through SNMP, the performance monitor measures network traffic levels.
The autodiscovery process is ongoing, so it spots any changes you make to your network and instantly updates the inventory and the topology map. The service can also identify virtual systems and extend monitoring of links out to cloud resources.
Datadog Network Monitoring provides end-to-end visibility of all connections, which are also correlated with performance issues highlighted in log messages. The dashboard for the system is resident in the cloud and accessed through any standard browser. This centralizes network performance data from many sources and covers the entire network, link by link and end to end.
You can create custom graphs, metrics, and alerts in an instant, and the software can adjust them dynamically based on different conditions. Datadog prices start from free (up to five hosts), Pro $15/per host, per month and Enterprise $23 /per host, per month.
Who is it recommended for?
The two Datadog network monitoring packages are very easy to sign up for. They work well together to get a complete view of network activities. The pair will discover all of the devices on your network and map them, then startup automated monitoring. These are very easy-to-use systems that are suitable for use by any size of business.
PROS:
Has one of the most intuitive interfaces among other network monitoring tools
Cloud-based SaaS product allows monitoring with no server deployments or onboarding costs
Can monitor both internally and externally giving network admins a holistic view of network performance and accessibility
Supports auto-discovery that builds network topology maps on the fly
Changes made to the network are reflected in near real-time
Allows businesses to scale their monitoring efforts reliably through flexible pricing options
CONS:
Would like to see a longer trial period for testing
At its core, ManageEngine OpManager is infrastructure management, network monitoring, and application performance management “APM” (with APM plug-in) software.
Key Features:
Includes server monitoring as well as network monitoring
Autodiscovery function for automatic network inventory assembly
Constant checks on device availability
A range of network topology map options
Automated network mapping
Performs an SNMP manager role, constantly polling for device health statuses
Receives SNMP Traps and generates alerts when device problems arise
Implements performance thresholds and identifies system problems
Watches over resource availability
Customizable dashboard with color-coded dials and graphs of live data
Forwards alerts to individuals by email or SMS
Available for Windows Server and Linux
Can be enhanced by an application performance monitor to create a full stack supervisory system
Free version available
Distributed version to supervise multiple sites from one central location
Why do we recommend it?
ManageEngine OpManager is probably the biggest threat to SolarWind’s leading position. This package monitors servers as well as networks. This makes it a great system for monitoring virtualizations.
When it comes to network management tools, this product is well balanced when it comes to monitoring and analysis features.
The solution can manage your network, servers, network configuration, and fault & performance; It can also analyze your network traffic. To run Manage Engine OpManager, it must be installed on-premises.
A highlight of this product is that it comes with pre-configured network monitor device templates. These contain pre-defined monitoring parameters and intervals for specific device types. The essential edition product can be purchased for $595 which allows up to 25 devices.
Who is it recommended for?
A nice feature of OpManager is that it is available for Linux as well as Windows Server for on-premises installation and it can also be used as a service on AWS or Azure for businesses that don’t want to run their own servers. The pricing for this package is very accessible for mid-sized and large businesses. Small enterprises with simple networks should use the Free edition, which is limited to covering a network with three connected devices.
PROS:
Designed to work right away, features over 200 customizable widgets to build unique dashboards and reports
Leverages autodiscovery to find, inventory, and map new devices
Uses intelligent alerting to reduce false positives and eliminate alert fatigue across larger networks
Supports email, SMS, and webhook for numerous alerting channels
Integrates well in the ManageEngine ecosystem with their other products
CONS:
Is a feature-rich tool that will require a time investment to properly learn
NinjaOne is a remote monitoring and management (RMM) package for managed service providers (MSPs). The system reaches out to each remote network through the installation of an agent on one of its endpoints. The agent acts as an SNMP Manager.
Key Features:
Based on the Simple Network Management Protocol
SNMP v1, 2, and 3
Device discovery and inventory creation
Continuous status polling for network devices and endpoints
Live traffic data with NetFlow, IPFIX, J-Flow, and sFlow
Traffic throughput graphs
Customizable detail display
Performance graphs
Switch port mapper
Device availability checks
Syslog processing for device status reports
Customizable alerts
Notifications by SMS or email
Related endpoint monitoring and management
Why do we recommend it?
NinjaOne RMM enables each technician to support multiple networks simultaneously. The alerting mechanism in the network monitoring service means that you can assume that everything is working fine on a client’s system unless you receive a notification otherwise. The network tracking service sets itself up automatically with a discovery routine.
The full NinjaOne RMM package provides a full suite of tools for administering a client’s system. The network monitoring service is part of that bundle along with endpoint monitoring and patch management.
The Ninja One system onboards a new client site automatically through a discovery service that creates both hardware and software inventories. The data for each client is kept separate in a subaccount. Technicians that need access to that client’s system for investigation need to be set up with credentials.
The network monitoring system provides both device status tracking and network traffic analysis. The service provides notifications if a dive goes offline or throughput drops.
Who is it recommended for?
This service is built with a multi-tenant architecture for use by managed service providers. However, IT departments can also use the system to manage their own networks and endpoints. The service is particularly suitable for simultaneously monitoring multiple sites. The console for the RMM is based in the cloud and accessed through any standard Web browser.
PROS:
A cloud-based package that onboards sites through the installation of an agent
Auto discovery for network devices and endpoints
Network device status monitoring
Network traffic analysis
Syslog message scanning
CONS:
No price list
NinjaOne doesn’t publish a price list so you start your buyer’s journey by accessing a 14-day free trial.
Site24x7 is a monitoring service that covers networks, servers, and applications. The network monitoring service in this package starts off by exploring the network for connected devices. IT logs its findings in a network inventory and draws up a network topology map.
Key Features:
A hosted cloud-based service that includes CPU time and performance data storage space
Can unify the monitoring of networks on site all over the world
Uses SNMP to check on device health statuses
Gives alerts on resource shortages, performance issues, and device problems
Generates notifications to forward alerts by email or SMS
Root cause analysis features
Autodiscovery for a constantly updated network device inventory
Automatic network topology mapping
Includes internet performance monitoring for utilities such as VPNs
Specialized monitoring routines for storage clusters
Monitors boundary and edge services, such as load balancers
Offers overview and detail screens showing the performance of the entire network and also individual devices
Includes network traffic flow monitoring
Facilities for capacity planning and bottleneck identification
Integrates with application monitoring services to create a full stack service
Why do we recommend it?
Site24x7 Network Monitoring is part of a platform that is very similar to Datadog. A difference lies in the number of modules that Site24x7 offers – it has far fewer than Datadog. Site24x7 bundles its modules into packages with almost all plans providing monitoring for networks, servers, services, applications, and websites. Site24x7 was originally developed to be a SaaS plan for ManageEngine but then was split out into a separate brand, so there is very solid expertise behind this platform.
The Network Monitor uses procedures from the Simple Network Management Protocol (SNMP) to poll devices every minute for status reports. Any changes in the network infrastructure that are revealed by these responses update the inventory and topology map.
The results of the device responses are interpreted into live data in the dashboard of the monitor. The dashboard is accessed through any standard browser and its screens can be customized by the user.
The SNMP system empowers device agents to send out a warning without waiting for a request if it detects a problem with the device that it is monitoring. Site24x7 Infrastructure catches these messages, which are called Traps, and generates an alert. This alert can be forwarded to technicians by SMS, email, voice call, or instant messaging post.
The Network Monitor also has a traffic analysis function. This extracts throughput figures from switches and routers and displays data flow information in the system dashboard. This data can also be used for capacity planning.
Who is it recommended for?
The plans for Site24x7 are very reasonably priced, which makes them accessible to businesses of all sizes. Setup for the system is automated and much of the ongoing monitoring processes are carried out without any manual intervention.
PROS:
One of the most holistic monitoring tools available, supporting networks, infrastructure, and real user monitoring in a single platform
Uses real-time data to discover devices and build charts, network maps, and inventory reports
Is one of the most user-friendly network monitoring tools available
User monitoring can help bridge the gap between technical issues, user behavior, and business metrics
Supports a freeware version for testing
CONS:
Is a very detailed platform that will require time to fully learn all of its features and options
Site24x7 costs $9 per month when paid annually. It is available for a free trial.
Atera is a package software that was built for managed service providers. It is a SaaS platform and it includes professional service automation (PSA) and remote monitoring and management (RMM) systems.
Why do we recommend it?
Atera is a package of tools for managed service providers (MSPs). Alongside remote network monitoring capabilities, this package provides automated monitoring services for all IT operations. The package also includes some system management tools, such as a patch manager. Finally, the Atera platform offers Professional Services Automation (PSA) tools to help the managers of MSPs to run their businesses.
The network monitoring system operates remotely through an agent that installs on Windows Server. The agent enables the service to scour the network and identify all of the network devices that run it. This is performed using SNMP, with the agent acting as the SNMP Manager.
The SNMP system enables the agent to spot Traps, which warn of device problems. These are sent to the Atera network monitoring dashboard, where they appear as alerts. Atera offers an automated topology mapping service, but this is an add-on to the main subscription packages.
Who is it recommended for?
Atera charges for its platform per technician, so it is very affordable for MSPs of all sizes. This extends to sole technicians operating on a contract basis and possibly fielding many small business clients.
ManageEngine RMM Central provides sysadmins with everything they need to support their network. Automated asset discovery makes deployment simple, allowing you to collect all devices on your network by the end of the day.
Key Features
Automated network monitoring and asset discovery
Built-in remote access with various troubleshooting tools
Flexible alert integrations
With network and asset metrics collected, administrators can quickly see critical insights automatically generated by the platform. With over 100 automated reports it’s easy to see exactly where your bottlenecks are and what endpoints are having trouble.
Administrators can configure their own SLAs with various automated alert options and even pair those alerts with other automation that integrate into their helpdesk workflow.
PROS:
Uses a combination of packet sniffing, WMI, and SNMP to report network performance data
Fully customizable dashboard is great for both lone administrators as well as NOC teams
Drag and drop editor makes it easy to build custom views and reports
Supports a wide range of alert mediums such as SMS, email, and third-party integrations into platforms like Slack
CONS:
Is a very comprehensive platform with many features and moving parts that require time to learn
You can run commands on one or hundreds of computers with a single PowerShell command. Windows PowerShell supports remote computing using various technologies, including WMI, RPC, and WS-Management.
PowerShell supports WMI, WS-Management, and SSH remoting. In PowerShell 7 and higher, RPC is supported only on Windows.
For more information about remoting in PowerShell, see the following articles:
Many Windows PowerShell cmdlets have the ComputerName parameter that enables you to collect data and change settings on one or more remote computers. These cmdlets use varying communication protocols and work on all Windows operating systems without any special configuration.
Typically, cmdlets that support remoting without special configuration have the ComputerName parameter and don’t have the Session parameter. To find these cmdlets in your session, type:
Using the WS-Management protocol, Windows PowerShell remoting lets you run any Windows PowerShell command on one or more remote computers. You can establish persistent connections, start interactive sessions, and run scripts on remote computers.
To use Windows PowerShell remoting, the remote computer must be configured for remote management. For more information, including instructions, see About Remote Requirements.
Once you have configured Windows PowerShell remoting, many remoting strategies are available to you. This article lists just a few of them. For more information, see About Remote.
Start an interactive session
To start an interactive session with a single remote computer, use the Enter-PSSession cmdlet. For example, to start an interactive session with the Server01 remote computer, type:
PowerShellCopy
Enter-PSSession Server01
The command prompt changes to display the name of the remote computer. Any commands that you type at the prompt run on the remote computer and the results are displayed on the local computer.
To end the interactive session, type:
PowerShellCopy
Exit-PSSession
For more information about the Enter-PSSession and Exit-PSSession cmdlets, see:
To run a command on one or more computers, use the Invoke-Command cmdlet. For example, to run a Get-UICulture command on the Server01 and Server02 remote computers, type:
LCID Name DisplayName PSComputerName
---- ---- ----------- --------------
1033 en-US English (United States) server01.corp.fabrikam.com
1033 en-US English (United States) server02.corp.fabrikam.com
Run a Script
To run a script on one or many remote computers, use the FilePath parameter of the Invoke-Command cmdlet. The script must be on or accessible to your local computer. The results are returned to your local computer.
For example, the following command runs the DiskCollect.ps1 script on the remote computers, Server01 and Server02.
Use the New-PSSession cmdlet to create a persistent session on a remote computer. The following example creates remote sessions on Server01 and Server02. The session objects are stored in the $s variable.
Now that the sessions are established, you can run any command in them. And because the sessions are persistent, you can collect data from one command and use it in another command.
For example, the following command runs a Get-HotFix command in the sessions in the $s variable and it saves the results in the $h variable. The $h variable is created in each of the sessions in $s, but it doesn’t exist in the local session.
PowerShellCopy
Invoke-Command -Session $s {$h = Get-HotFix}
Now you can use the data in the $h variable with other commands in the same session. The results are displayed on the local computer. For example:
PowerShellCopy
Invoke-Command -Session $s {$h | where {$_.InstalledBy -ne "NT AUTHORITY\SYSTEM"}}
Advanced Remoting
PowerShell includes cmdlets that allow you to:
Configure and create remote sessions both from the local and remote ends
Create customized and restricted sessions
Import commands from a remote session that actually run implicitly on the remote session
Configure the security of a remote session
PowerShell on Windows includes a WSMan provider. The provider creates a WSMAN: drive that lets you navigate through a hierarchy of configuration settings on the local computer and remote computers.
[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.
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:
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.)
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/
The network device enrollment service (NDES), via installing the Network Device Enrollment Servicerole. 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?
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’sGet-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 serioussecurity 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:
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.
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.
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.
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.
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 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.
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.
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].
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.
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.
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]
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]
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Malicious actors exploit CVEs in Telerik UI, VM Horizon, Zimbra Collaboration Suite, and other applications for initial access to victim organizations.
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.
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.
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
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.
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.
Malicious actors can steal administrator account credentials and the authentication token generated by Active Directory when the account is logged into a compromised host.
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.
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.
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.
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
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.
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.
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.
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.
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.
Real Commonwealth Bank Login Page.Fake Commonwealth Bank Login Page
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.
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.
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.
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.
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.
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.
