MITRE ATT&CK & D3FEND: Step-by-Step Guide to Closing Security Visibility Gaps

MITRE ATT&CK & D3FEND: Step-by-Step Guide to Closing Security Visibility Gaps

In this article, summarized from a recent managed detection and response webinar, we’ll explain what MITRE D3FEND is, how it complements the MITRE ATT&CK framework, and how you can use it to identify and close gaps in security visibility.

It’s no secret that cybercrime is on the rise with attacks happening more frequently and for higher and higher profits. Tuning our threat detection and response capabilities is more important than ever. But, as with most things in cybersecurity, that’s easier said than done.

One of the primary roadblocks to better threat detection is understanding your security visibility priorities and any gaps you may have within that visibility. Trying to get visibility into every single thing happening in your environment, however, is expensive, and for most organizations, impossible.

Fortunately, there are some really valuable frameworks out there like MITRE ATT&CK and MITRE D3FEND that can help streamline threat detection capabilities. These are free tools that anyone can use in order to prioritize detection and close security visibility gaps.

Read the blog: “Four Roadblocks to Faster Threat Detection & Response”


MITRE D3FEND is a new project from MITRE, the creators of the well-known ATT&CK framework, that establishes relationships between attack techniques, countermeasures and digital artifacts. From the MITRE website:

D3FEND is a knowledge base, but more specifically a knowledge graph, of cybersecurity countermeasure techniques. In the simplest sense, it is a catalog of defensive cybersecurity techniques and their relationships to offensive/adversary techniques.

The D3FEND matrix

The D3FEND matrix categorizes countermeasure techniques into five stages of defense:

  1. Harden – application hardening, platform hardening, credential hardening, message hardening
  2. Detect – network traffic analysis, process analysis, file analysis, platform monitoring, identifier analysis, message analysis, user behavior analysis
  3. Isolate – network isolation, execution isolation
  4. Deceive – decoy environment, decoy object
  5. Evict – credential eviction, process eviction

Each countermeasure is mapped to related MITRE ATT&CK techniques as well as any artifacts generated by the associated ATT&CK techniques. For example, the MITRE ATT&CK initial access technique of “Spearphishing Attachment” (T1566.001) would produce a MITRE D3FEND artifact of “Inbound Internet Mail Traffic” (D3FEND Artifact):

Figure 1. D3FEND inferred relationships for a spearphishing attack


D3FEND is a fairly new project that MITRE says is still in an experimental phase. We still find it incredibly valuable, especially when used in conjunction with the ATT&CK framework to prioritize security visibility requirements – and in the future, potentially even guide organizations in improving their resiliency by reducing attack surface.

MITRE ATT&CK – A knowledge base of attacker tactics and techniques

If you’re familiar with the ATT&CK framework, which I’m assuming at this point most of us are, you know that it’s an offensive model that looks at relationships between known threat actors, the techniques they used to perpetrate their attacks. Additionally, MITRE has categorized techniques into “tactics” which map roughly to stages in the cyber-attack killchain. MITRE also provides some (somewhat limited) guidance around mitigations and data sources to leverage for detection and mitigation, but those really just scratch the surface and have been fairly focused on endpoint telemetry.

MITRE D3FEND – A knowledge base of cybersecurity countermeasure techniques

D3FEND is the defensive counterpart to MITRE ATT&CK, providing countermeasures that can be implemented to harden defenses and detect, isolate, deceive, and evict attackers from the environment.

The connective tissue between the two frameworks are the digital artifacts that particular attack techniques generate. The techniques attackers use will produce some kind of digital evidence such as logs, network traffic, newly created user accounts, changes to email rules or application configurations, etc. Knowing which artifacts to look for allows us to implement the appropriate security visibility to detect threat actors abusing those techniques. Additionally, understanding where an attack technique falls – within an attack killchain – allows us to prioritize countermeasures and disrupt attackers as early as possible.

Watch our recent webinar to learn how to strengthen your threat detection and response capabilities

A Step-by-Step Guide on How to Use MITRE frameworks to prioritize and close security visibility gaps

Step 1 – Define your cybersecurity threat model.

First things first, you’re going to need a threat model. Without this, you’ll end up spinning your wheels trying to stop every potential threat to your organization. Threat modeling allows you to narrow in on the actual threat actors that may be targeting your organization based on factors like industry sector and geographic presence. Knowing those adversaries, you can better understand their objectives and which MITRE ATT&CK techniques and tactics they might use against you to compromise your environment and achieve their objectives.

At minimum, your threat model should accomplish the following five things:

  • Provide you an understanding of threat actors targeting potentially targeting your organization
  • Provide you an understanding of threat actor objectives (corporate espionage, financial gain, data theft, causing physical harm, etc) and a rough understanding of how threat actors attack (which techniques & tactics they use)
  • Mapping ATT&CK techniques to your technology stack – and understanding which are applicable to your environment (do you use containers? If not, techniques related to Docker containers are not applicable)
  • Understanding your attack surface
  • Some details regarding remediation and risk reduction steps

Step 2 – Prioritize high overlap cyber-attack techniques based on the killchain stage, using MITRE ATT&CK

With your threat model defined, you should have a good understanding of the types of threat actors targeting your organization, and you can start to identify where there is a high overlap of MITRE ATT&CK techniques these different threat actors using at each stage of the killchain.

Let’s say your threat model identifies APT28, more commonly known as Fancy Bear, as a threat actor that may be targeting your organization. You can reference the MITRE ATT&CK database to find the common techniques leveraged by APT28 to perform reconnaissance, gain initial access, establish persistence, etc.

Unless you’re very lucky, there’s not just one threat actor targeting your environment. So the next step is to cross-reference the techniques used by Fancy Bear with the techniques used by other threat actors to see if there are any techniques with really high overlap.

At Kudelski Security, we’ve developed a tool that helps speed up and visualize this cross-referencing step. In the example below, we can see that 42 of the threat actors we think are targeting our organization are leveraging Spearphishing Attachments to gain initial access. If we can prevent or detect a technique that’s very early on in the attack chain, then we have a much better chance of reducing the overall impact to the organization. For that reason, maybe Spearphishing Attachments should be our highest priority from a security visibility and detection perspective.


Figure 2.  A screenshot from Kudelski Security’s threat modeling tool that shows high overlap attacker techniques based on the MITRE ATT&CK database

Once we’ve gotten really good at detecting Spearphishing Attachments, we may want to move on to detecting users clicking on Spearphishing Links, then maybe Drive-by Compromise and so on. If you can understand where attackers are succeeding and the techniques that they’re using, you can prioritize what your visibility should be.

Learn more about Kudelski Security’s managed threat detection and response capabilities

Step 3 – Understand data requirements for technique detection and create a data checklist

Once you’ve got your list of offensive techniques prioritized, you need to understand the data that’s required to potentially detect each technique.

This is usually where we see the most failures when it comes to threat detection. Either you’re collecting too much data, or you think you’re collecting everything you need to when in reality, really valuable logs (which may not be enabled by default) aren’t even turned on or being collected. This is often the case in standard Windows Active Directory Environments. We talk a lot more about this in our blog “Four Roadblocks to Faster Threat Detection & Response.”

Going back to our Spearphishing Attachment example, the MITRE database will tell us what data we need to collect in order to detect Spearphishing Attachments. According to MITRE, we should be collecting data related to:

  • File creation
  • Application log content
  • Network traffic content
  • Network traffic flow

This becomes our data checklist. If we’re already collecting this data or at least have the ability to collect it, then we know we have what we need to detect this specific technique. Your objective here is to better understand the data you’re sending to your security visibility tooling, identify any gaps you might have and then start closing those gaps.

You will have to balance how easy the data is to collect with how valuable the data is in detecting an attack. Of course, you’ll want to tackle any low hanging fruit. Enabling object access and change logs in Active Directory is pretty simple. Making a change across HTTP web server in your environment when you don’t have centralized configuration management capabilities is not.

Ultimately, you’ll have to decide if the juice is worth the squeeze. If a complicated change could give you better visibility into your overlapping techniques, it may be worth considering.

Step 4 – Prioritize your attack mitigations, using MITRE D3FEND

As the saying goes, the best offense is a good defense. With steps 1-3 complete, it’s time to think about how you can prevent these types of attacks, applying mitigations or countermeasures designed to stop specific techniques from evening working in the first place.

Let’s look again at the MITRE D3FEND countermeasure database for the Spearphishing Attachment technique. You can see that there are 18 potential countermeasures that could either harden, detect, deceive or isolate the attack.

Figure 3. The 18 MITRE D3FEND countermeasures for spearphishing

That’s a lot to take on at once, so we recommend prioritizing mitigations with these four things in mind:

  1. Mitigate techniques early in the killchain – the earlier in an attack campaign you mitigate, the less impact to your overall environment
  2. Prioritize based on value and ease of deployment – don’t tackle the hardest thing first, even if it’s the most valuable
  3. Leverage available audit modes and early adopters – Some mitigations may impact the way your users are used to working. Your job is to reduce risk while also ensuring your business can still function. Leverage “audit” modes of preventative tooling to understand the potential impact of a mitigation and identify things you need to whitelist.
  4. Consider user experience – build a process internally to handle exceptions to your mitigations

Get in Touch

We find both the MITRE ATT&CK and MITRE D3FEND frameworks really valuable and have incorporated them into our managed threat detection and response capabilities. Our team uses data from both in the internal tool we’ve built to help our team execute threat modeling and identify data requirements as outlined in this post. Though the tool is not a requirement for what we’re recommending, it can help streamline efforts.

If you’re interested in learning more about the tool or our managed threat detection and response capabilities in general, get in touch with our team here.

“INCONTROLLER” / “PIPEDREAM” ICS Toolkit Targeting Energy Sector

“INCONTROLLER” / “PIPEDREAM” ICS Toolkit Targeting Energy Sector

This advisory was written by Travis Holland and Eric Dodge of the Kudelski Security Threat Detection & Research Team


Incontroller/Pipedream is a collection of sophisticated tools thought to be created by group dubbed  “Chernovite” by Dragos. Chernovite is assessed to be a a state-sponsored adversary, with the intention for use in future operations. The primary focus for this toolkit is for use in the electric and natural gas verticals; however, it is not limited to solely those. At this time, the CFC has no intelligence that Pipedream has been successfully deployed in the wild at this time. This has provided researchers time to evaluate the tools proactively. This is a suite of utilities designed to allow for access to and manipulation of Schneider Electric and Omron PLCs, as well as Open Platform Communications (OPC) Unified Architecture OPC-UA servers. Dragos, an ICS focused cyber security company, has broken Incontroller/Pipedream into five categories:  Evilscholar, Badomen, Mousehole, Dusttunnel and Lazycargo.


  • Evilscholar: Provides the capabilities to discover, access and manipulate Schneider Electric PLCs.
  • Badomen: Provides the capability to scan, identify and access Omron software and PLCs.
  • Mousehole: The tool is designed around interacting and accessing OPC Unified Architecture (UA) servers which allow for enumerating nodeids and brute forcing credentials.
  • Dusttunnel: Remote operation implant to establish persistence and command and control.
  • Lazycargo: Interface that drops and exploits a known vulnerable ASRock driver to elevate credentials.


When properly used these tools allow for an attacked to scan for devices, brute force passwords, close connections, and even crash the targeted device. PLC implants are utilized to execute untrusted code from the PLCs, these implants could be on an impacted PLC for long durations, requiring firmware forensic analysis to reveal its presence.


The CFC has worked with its ICS-aware Network intrusion Detection System (IDS) partner, Claroty, who has written and published detection signature for PipeDream. All clients of the CFC’s MDR for O.T have had these signatures updated for their Claroty deployments.

Affected Systems

This impacts the following systems typically located in electrical substations and communicating through IEC-104 protocol:

  • Systems vulnerable to CVE-2020-15368; ASRock driver exploit
  • Schneider Electric MODICON and MODICON Nano PLCs, including (but may not be limited to):
    • TM251, TM241, M258, M238, LMC058, and LMC078
  • OMRON Sysmac NJ and NX PLCs, including (but may not be limited to):
    • NEX NX1P2, NX-SL3300, NX-ECC203, NJ501-1300, S8VK, and R88D-1SN10F-ECT
  • OPC Unified Architecture (OPC UA) Servers

Learn more about the increasing importance for OT cybersecurity in the Energy, Oil and Gas Industry by downloading the eBook.

Technical Details

Incontroller/Pipedream is a sophisticated and modular set of tools that an attacker can leverage once they have established access within an environment. The foothold is established by any vector available to the attacker and is followed up with utilization of the ASRock driver exploit (CVE-2020-15368) to further escalate their privileges, and to move through the environment. The ASRock exploit is rather trivial, and only requires administrative access to further escalate privileges and execute arbitrary code with kernel privileges.


The modular architecture and automation of the tool allows for easy addition of more components as needed (such the ASRock exploit) could easily be swapped in favor of another exploit or tool. Depending on the PLC type there are different actions and objectives that the threat actor would look to achieve.

Capabilities of the tooling per impacted vendor


Schneider Electric Devices:

  • Rapidly scan and identify all Schneider PLC’s on other network via UDP multicast over port 27127
  • Brute force Schneider PLC passwords via CODESYS over port 1740
  • Conduct denial-of-service attacks to prevent network communication to the PLC
  • Drop connections, forcing re-authentication to the PLC to gather credentials
  • Crash the PLC, for a power cycle and configuration recovery
  • Pushing custom Modbus commands/packets
  • Retrieving file/directory listings
  • Deleting files
  • Adding a route if the device gateway IP exists on a different interface
  • Connecting to specific devices


Omron devices:

  • Scanning for Omron via FINS protocol over port 9600
  • Parsing out HTTP response from Omron devices
  • Retrieving MAC addresses of devices
  • Polling for what devices are connected to the PLC
  • Backup and restoration of arbitrary files to or from the PLC
  • Loading custom agents on the PLCs to allow for additional capabilities
  • Wiping the device’s memory and resetting it
  • Activating the Telnet daemon
  • Connecting to the device via the Telnet daemon and uploading or executing payloads and commands
  • Perform a network capture
  • Killing processes on the device
  • Transferring files to the device
  • Connecting and communicating with attached servo drives


  • Identify OPC UA servers
  • Connect to OPC UA servers via default or compromised credentials
  • Reading/Writing tag values for data on OPC UA servers
  • Brute forcing credentials
  • Outputting log files

Currently Known Indicators of Compromise (IOCs)

  • sys (RWEverything)
  • sys (AsrPolychromeRGB)
  • sys (AsrPolychromeRGB)
  • exe


There is currently no evidence of Incontroller/PipeDream being deployed for disruptive or destructive effects. It is known to utilize standard ICS protocols and actions to live off the land natively. Proper monitoring of any suspicious use of the ASRock driver can help mitigate a portion of the toolset seen within Incontroller/PipeDream. It is important to note that utilization of the AsRock Driver exploit requires the attacker to already have administrator level privileges on the host, however, future exploits may have different requirements.


The Cyber Fusion Center recommends the following for mitigation, discovery, and recovery:

  • Appropriate network segmentation, and strong perimeter controls
  • Leverage Secure Remote Access with Multi Factor Authentication and monitored sessions
  • Jump Servers monitored with Endpoint Detection and Response (EDR) technologies
  • Active endpoint monitoring on HMIs, Engineering Workstations, and Historians
  • Strong password policies and management
  • Patch management
  • Only allow connection to ICS/SCADA infrastructure through certain engineer workstations
  • Disable the Schneider NetManage discovery service
  • Monitoring for new outbound connections from PLC’s

Additionally dedicated ICS monitoring can aid in quickly identifying things outside the baseline that could be indicative of movement and attacks within the ICS infrastructure. Examination of non-baseline activity, and restricting access to the following destination ports:

  • TCP 502; Modbus
  • UDP 27127; primarily used for discovery scanning
  • UDP 1740-1743, TCP 1105, and TCP 117470; CODESYS
  • TCP/UDP 9600; default communication port for Omron



What the Cyber Fusion Center is doing

While there are currently no known active deployments of this tooling, the Cyber Fusion Center’s O.T Intrusion Detection System (IDS) partner, Claroty, has developed and published network signatures designed to detect the potential presence of this tooling. All clients of the CFC’s MDR For O.T service have had these new detection signatures deployed on their behalf.


8 Tips for Choosing an MSSP

8 Tips for Choosing an MSSP

Using objective, evidence-based criteria to evaluate vendors is essential.

With hundreds of prospective providers and tons of marketing buzzwords to wade through, choosing the best managed security service providers (MSSPs) to effectively protect both your MSP business and your customers is no easy task. However, as C-suite leaders increasingly push back against security expenditures where there’s little or no proof that they mitigate real-world risks, finding objective, evidence-based criteria to evaluate vendors is essential.

To help navigate the complexities of the market—and better compare providers’ offerings—there are eight key considerations and tips to keep in mind when evaluating the best MSSPs for you and your clients.

1. Understand core objectives
The first issue to consider is the primary objectives for your security stack. Are your clients most concerned with achieving compliance or thwarting attackers? The unfortunate reality of the current threat landscape is that compliance and security are not equivalent concepts. Though most regulatory requirements were enacted in hopes of enhancing security, they’re static, and the audit process captures only a moment-in-time snapshot of your security posture. Meanwhile, attacker tactics and techniques are always changing, as is the technology environment. Simply put, if all your clients want is compliance, choose the cheapest solution for your stack.

If, however, a careful evaluation of your firm’s—and your customers’—business risks reveals that gaining security visibility and responding quickly to attacks is most valuable, look for the provider that can best achieve the objective of detecting and responding to attacks within these various environments.

2. Enhance visibility
An essential truth about today’s computing environments is that infrastructures are more diverse and distributed, systems are increasingly interconnected, and attack surfaces continue to expand. As a result, security visibility is harder than ever to maintain, yet without the correct security logs, data, and visibility, effective threat monitoring and detection is impossible.

Look for a provider that can eliminate blind spots where it matters most to achieve visibility by focusing on your detection objectives. These detection objectives should ideally be the outcome of a threat modeling exercise. Additionally, seek out a provider that offers visibility across multiple environments, including on-premises infrastructures, cloud resources, endpoints, industrial control systems (ICS) / operational technology (OT). You should validate the provider has experience monitoring environments like yours. They should also be able to leverage a formal framework or methodology (such as MITRE ATT&CK(link is external)) to ensure there are no major visibility gaps into attack techniques a lot of adversaries are likely leveraging.

Download our latest research “7 Key Things a Good RFP Should Cover — MSS and MDR” for more insight.

3. Negotiate contract scope and pricing
If a provider is a good fit in all ways but their cost, keep in mind that pricing is almost always negotiable. Don’t settle for a provider that can’t deliver the value and capabilities your MSP needs just because they’re more affordable.

One way to reduce the cost of a provider’s managed detection and response (MDR) services is to reduce the scope of engagement. For example, eliminating lower-level, tactical activities like identity and access management (IAM) services from a contract ensures you’ll get the best an MDR provider must offer: finding threat actors in your environment and responding on your behalf.

It’s also relatively easy to train someone in-house or hire a less-specialized provider to carry out commodity functions. In the current cybersecurity market, it’s more difficult to hire internal detection engineers and response playbook writers.

4. Partner with a single provider for mission-critical work
While removing less-than-essential functions from the scope of a provider’s responsibilities can be an effective cost-limiting measure, it shouldn’t be done in a way that limits visibility.

For example, if you have multiple security service providers with one vendor monitoring your environment, another monitoring your endpoint detection and response (EDR) tool, and another monitoring your security information and event management (SIEM) tool, visibility gaps are all but inevitable for all your providers.

In these “split brain” scenarios, none of your providers will be as effective as they could be. Cyberattacks involve multiple stages and tactics; to fully comprehend a sequence of events, security teams need to be able to understand what happened throughout your customer’s environment—endpoint, network traffic, Azure AD logs, etc.

5. Focus on outcomes
The way to achieve a better overall security posture is by doing the fundamentals consistently, not just relying on flashy new technology. Rather than looking for a provider that can support the trendiest toolsets, concentrate on outcomes. To make fact-based investments, you need to understand where your visibility and detection gaps are so that you can close them effectively.

Also, look for gaps in internal training, policies, and processes. An experienced provider can work closely as a partner and guide you toward greater security maturity by enhancing your fact-based understanding of strengths and weaknesses.

6. Replace legacy technologies if they don’t deliver on necessary outcomes
Although buying the latest and greatest security tools will not improve outcomes on their own, there are times when it makes sense to modernize your security stack. In some cases, you can’t achieve better outcomes just by leveraging technology that’s already in place.

Have an honest conversation with prospective MSSPs about which technologies they support and why.

There’s no way a high-quality MDR provider can be equally effective with every SIEM, EDR, or cloud security platform on the market today.

Technology sprawl affects all information security teams, including MDR providers and MSSPs. Learning each additional tool requires time, money, and training. Like everyone else, security providers must make tradeoffs about which technologies to prioritize. Any MDR provider who says they support every technology is either dishonest or ineffective.

7. Look for meaningful SLAs
Meaningless service-level agreements (SLAs) are all too common today. If your desired outcome is to be able to detect and respond to malicious activities quickly enough to prevent ransomware from spreading across your environment, does the number of “dedicated” resources assigned to your account matter?

I’ve seen organizations request SLAs such as “critical alerts must be triaged within five minutes, and low-criticality alerts within six hours.” How could your provider possibly validate that a new alert is critical without triaging it?

Sure, providers can look at the criticality of the technique detections are trying to find. However, waiting six hours to triage a low-severity detection could be detrimental. A small breadcrumb that triggers a low-severity alert can lead to the discovery of a seasoned and methodical threat actor.

Note that attackers also use MITRE ATT&CK to identify likely gaps in visibility or to build novel techniques not currently included in the knowledge base.

8. Engage key stakeholders
It’s important to manage your customer’s procurement process carefully. Decision makers often seek to achieve business objectives at the lowest cost possible and may not understand the nuanced differences between vendors or the desired security objectives.

Make sure all the key stakeholders thoroughly understand how well the provider can support outcomes that will meaningfully reduce business risk.

The original article was featured in Channel Pro Network.

CredManifest: Azure AD Information Disclosure Leading to Privilege Escalation & Free Tool Released

CredManifest: Azure AD Information Disclosure Leading to Privilege Escalation & Free Tool Released


On November 17th, 2021 Microsoft disclosed the existence of a high severity information disclosure vulnerability impacting Azure Active Directory (Azure AD) that could allow authenticated Azure AD user to escalate their privileges. Azure AD is Microsoft’s Identity and Access Management system used by Azure Cloud and Office 365. The vulnerability, dubbed “CredManifest” (CVE-2021-42306) existed because Azure incorrectly wrote private certificates data in cleartext in Application and Service Principal Manifests. These manifests can be read by any authenticated Azure AD user by default.

Successful exploitation of this vulnerability could have allowed an attacker with access to any account in target’s Azure AD environment to read private certificates from manifests. Attackers could then leverage those certificates to authenticate as the application with the “contributor” role, granting them full access to manage all Azure resources.

Microsoft has since mitigated the vulnerability by restricting access to the “keyCredentials” property in Application and Service Principal manifests as of October 30th, 2021. Restricting access to the property which contains the private certificate data ensures that attackers can no longer access the sensitive data. However, it’s possible that attackers have gathered these credentials prior to Microsoft becoming aware of the issue and thus may still have access to privileged credentials for impacted environments. The Cyber Fusion Center strongly recommends that organizations identify impacted Application registration and Service Principals and rotate those certificates as quickly as possible and investigate Azure AD audit logs for suspicious activity from associated accounts.

For additional details on how to identify impacted App registrations & Service Principals, please review the “solution” section of this advisory.

Affected Azure AD Services

Azure AD Service Impacted Scenarios
Azure AD Automation with “Run As” accounts enabled Any Azure AD automation accounts created with “Run As” accounts generated between 10/15/2020 – 10/15/2021 are impacted.


Automation accounts created with Managed Identities are not impacted.

Azure Migrate service Azure Migrate appliances registered prior to 11/02/2021 or registered with auto-update disabled are impacted.
Azure Site Recovery (ASR) Users who deployed the preview version of VMware to Azure DR with Azure Site Recovery before 11/01/2021 are impacted.
Azure AD Applications and Service Principals Please review the “solution” section of this advisory to identify impacted Azure AD Apps & Service Principals.


Microsoft has update Azure software to mitigate and resolve the issue, however certain Application and Service Principal credentials must be rotated to fully remediate the issue. Please follow the guidance listed in this advisory and Microsoft’s remediation guide to identify credentials that must be rotated.

CFC Releases Free Tool to check for impacted Applications & Accounts

The Cyber Fusion Center has also created a free tool to allow organizations to identify impacted Automation “Run-As” accounts, Application Registrations, and Service Principals. The tool allows Azure AD administrators to easily see impacted credentials that need to be rotated. The free tool is available at the following location:

Once an organizational administrator has granted read-only content to the tool, organizations will be able to see identify impacted Applications:

A listing of applications that are impacted and should have their credentials rotated

Manually Identifying Impacted Applications, Service Principals, and Run-As Accounts

Microsoft has enhanced manifests on impacted objects to return new properties that help identify impacted credentials that must be rotated. Organizations can identify impacted Azure AD Aps and Service Principals by looking a property of “hasExtendedValue” within the “keyCredentials” object being set to true.

Below is an example of an *impacted* credential (notice the hasExtendedValue property set to True):

    "@odata.context": "$metadata#applications(keyCredentials)/$entity",
    "keyCredentials": [
            "customKeyIdentifier": "7A28B6653D0319E69D27E74580E7C91D765AF867",
            "endDateTime": "2021-05-21T03:35:32Z",
            "keyId": "772faab4-9b59-456e-b73e-baadbfa4b92d",
            "startDateTime": "2020-05-21T03:15:32Z",
            "type": "AsymmetricX509Cert",
            "usage": "Verify",
            "key": "MIIDKzCC……",
            "displayName": "CN=MyCert",
            "hasExtendedValue": True

Free Microsoft Scripts to identify impacted Applications, Service Principals, and Run-As Accounts.

Additionally, Microsoft has made several scripts and automation tooling available to identify and remediate impacted Azure AD App Registrations and Service Principals here:

What the Cyber Fusion Center is doing

The Cyber Fusion Center is actively working to develop tooling to help clients identify impacted App registrations and Service Principals. The CFC will engage directly with clients who subscribe to CFC services that required Azure AD App Registrations to support data and alert consumption (such as the CFC’s MDR For Endpoint with Microsoft Defender for Endpoint and MDR for Cloud with Azure / Office 365) to identify if they are impacted, and if necessary, rotate credentials.

The Cyber Fusion Center will engage with clients to directly coordinate the rotation of impacted certificates and credentials and ensure no impact to the delivery of your CFC services. Clients working to mitigate impacted Azure AD App registrations should coordinate with the CFC to ensure we can continue to receive critical data required to deliver your services.

Temporary Workarounds and Mitigations

Microsoft has proactively mitigated the issue by limiting access to private certificate data from manifests. This has prevented attackers from gaining access to private certificates since 10/30/2021. However, impacted credentials must still be rotated to ensure attackers who may have exploited this vulnerability prior to mitigation do not retain privileged access to Azure AD environments.

Organizations who identify impacted App registrations and Service Principals should review Azure AD audit logs for sign of abuse of these credentials as soon as possible.



OT: The Time for Remote Access Security is Now

OT: The Time for Remote Access Security is Now

Critical infrastructure systems are becoming increasingly connected to traditional IT systems, and as a result, are increasingly targeted.

Critical infrastructure systems are becoming increasingly connected to traditional IT systems, and as a result, are being increasingly targeted. A Siemens study found that 56 percent of the world’s gas, wind, water and solar utilities experienced at least one shutdown or operational data loss per year. The potential repercussions of a critical infrastructure breach within an industrial setting go far beyond financial loss or reputational damage.

Attacks in this space have already resulted in large-scale societal consequences. A cyber attack on Colonial Pipeline, the largest pipeline system for refined oil products in the U.S., caused the company to suspend operations and left the East Coast with a temporary gas shortage. In this case, Colonial Pipeline shut down its fuel pipeline operations pre-emptively even though its’ operational technology (OT) systems were not directly impacted. Sources claimed that the shutdown was due to the invoicing and billing systems being encrypted and unavailable, leaving the business with no way to properly track or invoice clients for fuel.

Colonial Pipeline’s hack is an important case study about how critically interdependent IT and OT systems are, even if they’re segregated technically and air gapped appropriately. This incident highlighted the imminent need for cybersecurity and risk management programs for an organization’s operational/industrial control system (ICS) environments, as well as security being at the forefront for all OT engineers and plant managers.

Remote access vulnerabilities

Within the past few years, the convergence of IT and OT systems has expedited the adoption of remote access technologies in critical infrastructure settings. More recently, the COVID-19 pandemic forced organizations to limit the number of people who were physically located within a plant or OT site. This drastically increased the number of ICS management and monitoring systems that are directly connected to the internet, potentially leaving them accessible to remote attackers.

These unprotected remote access systems or solutions essentially act as bait to threat actors wanting to compromise critical infrastructure systems. For example, a security researcher from the University of Tulsa revealed the ability for hackers to control entire networks of U.S. wind farm turbines. The researchers broke into a facility and installed a Raspberry-Pi-based computer through which they were able to access the systems remotely. This experiment shone a light on the simplicity of covertly installing unauthorized remote access systems that provide easy access to OT systems that were through to be fully air gapped from the internet, and the potential damage that can be done.

Understanding OT vulnerabilities to mitigate the risks

Despite these glaring vulnerabilities, there is a widespread lack of knowledge about asset protection across the manufacturing, energy, and oil and gas industries. Many OT operators and engineers, unfortunately, are not yet aware of the severity of the potential risks that insecure remote access points can bring. There is a significant disconnect between risk perception and actively implementing processes and procedures to mitigate those risks, with little incentive to replace or improve equipment that still functions but does not meet security requirements. Industry professionals must be educated on the risks of vulnerable remote access points.

The reality of OT systems is that plants and manufacturing sites are often designed and built to last and to remain “stable” for decades to come. This means that there are often no plans to keep software updated by installing security patches, changing configurations to make the systems more secure, or reducing risk by turning off unnecessary features on Programmable Logic Controllers (PLCs). Consequently, the most common risks in critical infrastructure OT systems include the following: outdated operating systems, unencrypted passwords used to connect to systems over unsecured networks, remotely accessible devices, lack of passive network monitoring, weak access control systems, and the failure to keep antivirus signatures updated to track new malware strains.

It’s not uncommon for security providers to deploy passive network monitoring systems in OT environments and immediately see years old malware running rampant (such as slammer or conflicker) with the OT engineers being none the wiser. The attacks against these systems typically don’t require sophisticated zero-day vulnerabilities in the software used on engineering workstations or in PLCs but instead rely on abusing poor security hygiene and differing priorities.

Preventing future hacks

Poor cyber hygiene remains the top challenge in securing these systems. Thankfully, some steps can be taken to reduce risk. One key priority is to focus on protecting IT / OT network boundaries. More specifically, focus on remote access systems and software that may allow direct access to critical OT networks to enable engineers to monitor systems remotely.

Perhaps most importantly, proper education and increased awareness remains the most effective way to prevent incidents. If detection and risk mitigation is to be a priority, education must come first. Site managers and OT engineers must be aware of these risks and work closely and collaboratively with corporate information security teams to appropriately defend these environments in a non-disruptive way.

One of the simplest ways to deploy risk mitigation measures is deploying an approved set of remote access tools designed specifically for OT environments and ensuring these systems are appropriately configured to record a user’s activity and limit their access based on least privilege.

Implementing security practices and procedures is not a choice for most business-critical OT systems. Security must be at the forefront of all new critical infrastructure systems to protect against a growing number of vulnerabilities due to the convergence of IT and OT systems and the increasing number of access points. Companies must mitigate the risk of OT breaches and ensure their risk management and information security programs also help protect these environments.

This article was originally featured in Industry Today.