by Contributed | Jan 8, 2021 | Technology
This article is contributed. See the original author and article here.
We are actively building out our program by developing resources for both partners and Defense Industrial Base (DIB) companies to leverage in their Cybersecurity Maturity Model Certification (CMMC) journey. These tools cannot guarantee a positive CMMC adjudication, but they may assist candidate organizations by improving their CMMC posture going into a formal CMMC review in accordance with CMMC Accreditation Body (AB) standards. While we plan to release resources and guidance in waves, please keep in mind we are dependent upon the CMMC AB finalizing the CMMC guidance itself.
Here is a summary of current resources to help get you started:
Microsoft Product Placemat for CMMC
The Microsoft Product Placemat for CMMC is an interactive view representing how Microsoft cloud products and services satisfy requirements for CMMC practices. The user interface resembles a periodic table of CMMC Practice Families. The default view illustrates the practices with Microsoft Coverage that are inherited from the underlying cloud platform. It also depicts practices for Shared Coverage where the underlying cloud platform contributes coverage for specific practices but requires additional customer configuration to satisfy requirements for full coverage. For each practice that aligns with Microsoft Coverage or Shared Coverage, verbal customer implementation guidance and practice implementation details are documented. This enables you to drill down into each practice and discover details on inheritance and prescriptive guidance for actions to be taken by the customer to meet practice requirements in the shared scope of responsibility for compliance with CMMC.
In addition to the default view, you may select and include products, features and suite SKUs to adjust how each cloud product is placed with CMMC. For example, you may select the Microsoft 365 E5 SKU for maximum coverage of CMMC where 18 of the CMMC practices are Microsoft Coverage and 74 practices are Shared Coverage. This is extraordinary as nearly 80% of the practices for CMMC Level 3 have coverage leveraging the spectrum of capabilities on the Microsoft cloud with the E5 SKU!
The Microsoft Product Placemat for CMMC is currently in public preview. You may download a copy at:
https://aka.ms/cmmc/productplacemat
Please share feedback at https://aka.ms/cmmc/productplacematfeedback.
Azure Sentinel: Cloud-Native SIEM
See and stop threats before they cause harm, with SIEM reinvented for a modern world. Azure Sentinel is your birds-eye view across the enterprise. Put the cloud and large-scale intelligence from decades of Microsoft security experience to work. Make your threat detection and response smarter and faster with artificial intelligence (AI). Eliminate security infrastructure setup and maintenance, and elastically scale to meet your security needs—while reducing IT costs.
- Collect data at cloud scale—across all users, devices, applications, and infrastructure, both on-premises and in multiple clouds
- Detect previously uncovered threats and minimize false positives using analytics and unparalleled threat intelligence from Microsoft
- Investigate threats with AI and hunt suspicious activities at scale, tapping into decades of cybersecurity work at Microsoft
- Respond to incidents rapidly with built-in orchestration and automation of common tasks
Invest in security, not infrastructure setup and maintenance with the first cloud-native SIEM from a major cloud provider. Never again let a storage limit or a query limit prevent you from protecting your enterprise. Start using Azure Sentinel immediately, automatically scale to meet your organizational needs, and only pay for the resources you need.
For more information, please see https://azure.microsoft.com/en-us/services/azure-sentinel
Collect data at cloud scale—across all users, devices, applications, and infrastructure, both on-premises and in multiple clouds
Azure Sentinel: CMMC Workbook
The Azure Sentinel CMMC Workbook provides a mechanism for viewing log queries aligned to CMMC controls across the Microsoft portfolio including Microsoft security offerings, Office 365, Teams, Intune, Windows Virtual Desktop and many more. This workbook enables Security Architects, Engineers, SecOps Analysts, Managers, and IT Pros to gain situational awareness visibility for the security posture of cloud workloads. There are also recommendations for selecting, designing, deploying, and configuring Microsoft offerings for alignment with respective CMMC requirements and practices.
Note: The Azure Sentinel CMMC Workbook is currently in Private Preview and will release in a Public Preview in early February 2021.
Microsoft Compliance Manager with Assessment Templates
Compliance Manager
Microsoft Compliance Manager is a feature in the Microsoft 365 compliance center that helps you manage your organization’s compliance requirements with greater ease and convenience. Compliance Manager may help you throughout your compliance journey, from taking inventory of your apparent data protection risks to managing the complexities of implementing controls, staying current with regulations and certifications, and reporting to auditors.
Compliance Manager helps simplify compliance and reduces risk by providing:
- Pre-built assessments for common industry and regional standards and regulations, or custom assessments to meet your unique compliance needs.
- The Assessment Templates include NIST SP 800-171 and projected requirements for CMMC Levels 1-5.
- The Assessment Templates that are available to your organization depend on your licensing agreement. Review the details. HINT: You will need an E5 SKU.
- Workflow capabilities to help you efficiently complete your risk assessments through a single tool.
- Detailed step-by-step guidance on suggested improvement actions to help you comply with known CMMC standards and regulations that are most relevant for your organization. For actions that are managed by Microsoft, you’ll see implementation details and audit results.
- A projected risk-based compliance score to help you understand your compliance posture by measuring your progress in completing improvement actions.
Your Compliance Manager dashboard shows your current projected CMMC compliance score, helps you see what needs attention, and guides you to key improvement actions. Below is an example of what your Compliance Manager dashboard will look like:
Please note, the Compliance Manager dashboard is a projection of your organization’s CMMC compliance profile based on all available information to date—Microsoft is not an accrediting body under the CMMC, and thus cannot guarantee any outcome under the formal CMMC review process.
Understanding your compliance score
Compliance Manager awards you points for completing improvement actions taken to comply with a regulation, standard, or policy, and combines those points into an overall compliance score. Each action has a different impact on your score depending on the potential risks involved. Your compliance score helps you prioritize which actions to focus on to improve your overall compliance posture.
Compliance Manager gives you an initial score based on the Microsoft 365 data protection baseline. This baseline is a set of controls that includes key regulations and standards for data protection and general data governance.
Compliance Manager Availability in GCC and GCC High
The Compliance Manager is now available in all Microsoft 365 cloud offerings, including GCC and GCC High!
However, the Secure Score feature is still in preview within Commercial and GCC. Secure Score will not release in GCC High until it becomes Generally Available. As a result, automated testing does not work in GCC High. GCC High customers will need to manually implement and test their improvement actions in the Compliance Manager. For more information, please see Settings for automated testing and user history.
Azure Security Center with Azure Blueprints
Azure Security Center
Microsoft uses a wide variety of physical, infrastructure, and operational controls to help secure Azure, but there are additional actions you need to take to help safeguard your workloads. You may turn on the Azure Security Center to strengthen your cloud security posture:
- Assess and visualize the security state of your resources in Azure, on-premises, and in other clouds with Azure Secure Score;
- Simplify enterprise compliance and view your compliance against regulatory requirements such as NIST SP 800-171 and CMMC;
- Protect all your hybrid cloud workloads with Azure Defender, which is integrated with Security Center; and
- Use AI and automation to cut through false alarms, quickly identify threats, and streamline threat investigation.
You may assess the security state of all your cloud resources, including servers, storage, SQL, networks, applications, and workloads that are running in Azure, on-premises, and in other clouds. This includes the ability to visualize your security state and improve your security posture by using Azure Secure Score recommendations. You may view your compliance against a wide variety of regulatory requirements or company security requirements by centrally managing security policies to perform ongoing assessment and get rich, actionable insights and reports to simplify compliance.
Note: The Azure Security Center is available today in both Commercial and in Azure Government.
Azure Blueprints
Just as a blueprint allows an engineer or an architect to sketch a project’s design parameters, Azure Blueprints enables cloud architects and central information technology groups to define a repeatable set of Azure resources that implements and adheres to an organization’s standards, patterns, and requirements. Azure Blueprints makes it possible for development teams to rapidly build and stand up new environments with trust they’re building within organizational compliance with a set of built-in components, such as networking, to speed up development and delivery.
Blueprints are a declarative way to orchestrate the deployment of various resource templates and other artifacts such as:
- Role Assignments
- Policy Assignments
- Azure Resource Manager templates (ARM templates)
- Resource Groups
The Azure Blueprints service is designed to help with environment setup. This setup often consists of a set of resource groups, policies, role assignments, and ARM template deployments. A blueprint is a package to bring each of these artifact types together and allow you to compose and version that package, including through a continuous integration and continuous delivery (CI/CD) pipeline. Ultimately, each is assigned to a subscription in a single operation that can be audited and tracked.
With Azure Blueprints, the relationship between the blueprint definition (what should be deployed) and the blueprint assignment (what was deployed) is preserved. This connection supports improved tracking and auditing of deployments. Azure Blueprints can also upgrade several subscriptions at once that are governed by the same blueprint.
Azure Policy and Blueprint Sample for CMMC Level 3
An Azure Policy and Blueprint allows organizations to easily establish compliant environments. Azure Policy is implemented via a centrally managed policy initiative that helps ensure cloud compliance, avoid misconfigurations, and practice consistent resource governance. An Azure blueprint simplifies large scale Azure deployments by packaging key artifacts such as policy initiatives, Azure Resource Manager (ARM) templates, and role-based access controls.
A new Azure policy initiative and blueprint sample for CMMC Level 3 are currently in development. The CMMC policy initiative builds upon the existing NIST SP 800-171 policy initiative/blueprint sample with the addition of 110 new policies. Any relevant new policies will be back-ported into the NIST SP 800-171 sample after the CMMC sample is finalized.
The CMMC policy initiative and blueprint sample is currently in Private Preview. It will transition to Public Preview in February 2021 with availability in both Azure Commercial and Government clouds.
Compliance Manager and the Azure Security Center
You may observe there are two different compliance tools depending on the use of Microsoft 365 or Microsoft Azure. While there are currently two different tools, they are not mutually exclusive in use. Holistic compliance with CMMC requires the use of both the Compliance Manager and the Azure Security Center. You deploy the Compliance Manager with the Assessment Template for CMMC for coverage of Microsoft 365 products and features, such as Office 365 and Enterprise Mobility & Security. Generally speaking, this includes coverage for most SaaS offerings. You will also want to deploy the Azure Security Center with the Azure Blueprint sample for CMMC (roadmap) for coverage of Azure IaaS and PaaS offerings. We are working on integration between the two tools along with integration with Azure Sentinel in the future roadmap. In the meantime, you will need to leverage both panes of glass for CMMC compliance.
Zero Trust Architecture with Azure Blueprints
Zero Trust Architecture
Today, many of our customers in regulated industries are adopting a Zero Trust architecture – moving to a security model that more effectively adapts to the complexity of the modern environment, embraces the mobile workforce, and protects people, devices, applications, and data wherever they’re located.
Regardless of where the request originates or what resource it accesses, Zero Trust teaches us to “never trust, always verify.” In a Zero Trust model, every access request is strongly authenticated, authorized within policy constraints, and inspected for anomalies before granting access. This approach aids the process of achieving compliance for industries that use NIST-based controls including the DIB and government.
A Zero Trust approach should extend throughout the entire digital estate and serve as an integrated security philosophy and end-to-end strategy, across three primary principles: (1) verify explicitly, (2) enforce least privilege access, and (3) assume breach.
Azure blueprint for the Azure Security Benchmark Foundation
We have developed a GitHub Repo for an Azure Blueprint sample enabling Configuration-as-Code for Azure subscriptions. The Azure Blueprint for Azure Security Benchmark Foundation (formerly “Zero Trust”) enables application developers and security administrators to more easily create hardened environments for their application workloads. Essentially, the blueprint will help you implement Zero Trust controls across six foundational elements: identities, devices, applications, data, infrastructure, and networks.
Using the Azure Security Center and Azure Blueprints service, the blueprint sample will first configure your VNET to deny all network traffic by default, enabling you to extend it and/or set rules for selective traffic based on your business needs. In addition, the blueprint enforces and maintains Azure resource behaviors and configuration in compliance with specific NIST SP 800-53 security control requirements using Azure Policy.
The blueprint includes Azure Resource Manager templates to deploy and configure Azure resources such as Virtual Network, Network Security Groups, Azure Key Vault, Azure Monitor, Azure Security Center, and more. If you’re working with applications that need to comply with FedRAMP High or DoD Impact Level 4 requirements or just want to improve the security posture of your cloud deployment, the blueprint for Zero Trust is designed to help you get there faster.
The ASBF blueprint is currently in preview with limited support. To learn more and find instructions to deploy into Azure, see the ASBF repo. For more information, questions, and feedback, please contact us at ASBF feedback.
We are also working on updates in support of NIST SP 800-171 and CMMC for availability in the first half of calendar year 2021.
CMMC Documentation
CMMC Compliance Documentation
There are several artifacts we are working on for release this year 2021, to include:
- SSP: System Security Plan with customer scope of responsibility detailed
- CIS: Control Implementation Summary per environment (IaaS, PaaS and SaaS)
- SAR: Security Assessment Report from Microsoft’s C3PAO engagement
- Documented auditor observations based on pre-defined tenant configuration
Microsoft Cybersecurity Reference Architecture
The Microsoft Cybersecurity Reference Architecture (MCRA) describes Microsoft’s cybersecurity capabilities and how they integrate with existing security architectures. We have seen this document used for several purposes by our customers to include:
- Starting template for a security architecture – The most common use case we see is that organizations use the document to help define a target state for cybersecurity capabilities. Organizations find this architecture useful because it covers capabilities across the modern enterprise estate that now spans on-premises, mobile devices, many clouds, and IoT / Operational Technology.
- Comparison reference for security capabilities – We know of several organizations that have marked up a printed copy with what capabilities they already own from various Microsoft license suites (many customers don’t know they own quite a bit of this technology), which ones they already have in place (from Microsoft or partner/3rd party), and which ones are new and could fill a need.
- Learn about Microsoft capabilities – In presentation mode, each capability has a “ScreenTip” with a short description of each capability + a link to documentation on that capability to learn more.
- Learn about Microsoft’s integration investments – The architecture includes visuals of key integration points with partner capabilities (e.g. SIEM/Log integration, Security Appliances in Azure, DLP integration, and more) and within our own product capabilities among (e.g. Advanced Threat Protection, Conditional Access, and more).
- Learn about Cybersecurity – We have also heard reports of folks new to cybersecurity using this as a learning tool as they prepare for their first career or a career change.
The Microsoft Cybersecurity Reference Architecture is available here. Additional training resources are available here.
An update will be released early this year 2021 to include the branding updates announced at Ignite 2020. Most notably, the use of the Microsoft Defender branding will be incorporated in the update to MCRA.
Microsoft Blog Posts on CMMC
Program Scaffolding for Managed Service Providers
Behind the scenes, we are actively working with our partner community, and in particular the Managed Service Providers (MSP), to deliver scaffolding in the construction of CMMC offerings. The CMMC Acceleration Program is comprised of many different components as described above, and several that are yet unannounced. The intent is to provide building blocks, or what we call “scaffolding”, to our partners in support of their CMMC offers. Our partners will be enabled in our partner marketplace with advance specializations for CMMC and their concentration on the Defense Industrial Base. In alignment with the commitments made in our original CMMC Announcement, our MSP partners will implement reference architectures and compliance solutions for CMMC.
Into the Future
Microsoft is actively engaged with customers, partners, the CMMC Accreditation Body, and multiple industry working groups to refine what resources we should develop and make available as part of the CMMC Acceleration Program. We have many grand ideas, and welcome to feedback from the community at large. Please fill out this short survey to join our CMMC feedback loop if you are interested in learning more about the program.
For general comments on the CMMC Acceleration Program: Contact Us
Appendix
Please follow me here and on LinkedIn. Here are my additional blog articles:
by Scott Muniz | Jan 8, 2021 | Security, Technology
This article is contributed. See the original author and article here.
This Advisory uses the MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK®) framework. See the ATT&CK for Enterprise for all referenced threat actor tactics and techniques.
This Alert is a companion alert to AA20-252A: Advanced Persistent Threat Compromise of Government Agencies, Critical Infrastructure, and Private Sector Organizations. AA20-252A primarily focuses on an advanced persistent threat (APT) actor’s compromise of SolarWinds Orion products as an initial access vector into networks of U.S. Government agencies, critical infrastructure entities, and private network organizations. As noted in AA20-252A, the Cybersecurity and Infrastructure Security Agency (CISA) has evidence of initial access vectors in addition to the compromised SolarWinds Orion products.
This Alert also addresses activity—irrespective of the initial access vector leveraged—that CISA attributes to an APT actor. Specifically, CISA has seen an APT actor using compromised applications in a victim’s Microsoft 365 (M365)/Azure environment. CISA has also seen this APT actor utilizing additional credentials and Application Programming Interface (API) access to cloud resources of private and public sector organizations. These tactics, techniques, and procedures (TTPs) feature three key components:
- Compromising or bypassing federated identity solutions;
- Using forged authentication tokens to move laterally to Microsoft cloud environments; and
- Using privileged access to a victim’s cloud environment to establish difficult-to-detect persistence mechanisms for Application Programming Interface (API)-based access.
This Alert describes these TTPs and offers an overview of, and guidance on, available open-source tools—including a CISA-developed tool, Sparrow—for network defenders to analyze their Microsoft Azure Active Directory (AD), Office 365 (O365), and M365 environments to detect potentially malicious activity.
Note: this Alert describes artifacts—presented by these attacks—from which CISA has identified detectable evidence of the threat actor’s initial objectives. CISA continues to analyze the threat actor’s follow-on objectives.
Frequently, CISA has observed the APT actor gaining Initial Access [TA0001] to victims’ enterprise networks via compromised SolarWinds Orion products (e.g., Solorigate, Supernova).[1] However, CISA is investigating instances in which the threat actor may have obtained initial access by Password Guessing [T1110.001], Password Spraying [T1110.003], and/or exploiting inappropriately secured administrative or service credentials (Unsecured Credentials [T1552]) instead of utilizing the compromised SolarWinds Orion products.
CISA observed this threat actor moving from user context to administrator rights for Privilege Escalation [TA0004] within a compromised network and using native Windows tools and techniques, such as Windows Management Instrumentation (WMI), to enumerate the Microsoft Active Directory Federated Services (ADFS) certificate-signing capability. This enumeration allows threat actors to forge authentication tokens (OAuth) to issue claims to service providers—without having those claims checked against the identity provider—and then to move laterally to Microsoft Cloud environments (Lateral Movement [TA0008]).
The threat actor has also used on-premises access to manipulate and bypass identity controls and multi-factor authentication. This activity demonstrates how sophisticated adversaries can use credentials from one portion of an organization to move laterally (Lateral Movement [TA0008]) through trust boundaries, evade defenses and detection (Defense Evasion [TA0005]), and steal sensitive data (Collection [TA0009]).
This level of compromise is challenging to remediate and requires a rigorous multi-disciplinary effort to regain administrative control before recovering.
Detection
Guidance on identifying affected SolarWinds software is well documented.[2] However—once an organization identifies a compromise via SolarWinds Orion products or other threat actor TTPs—identifying follow-on activity for on-premises networks requires fine-tuned network and host-based forensics.
The nature of cloud forensics is unique due to the growing and rapidly evolving technology footprints of major vendors. Microsoft’s O365 and M365 environments have built-in capabilities for detecting unusual activity. Microsoft also provides premium services (Advanced Threat Protection [ATP] and Azure Sentinel), which enable network defenders to investigate TTPs specific to the Solorigate activity.[3]
Detection Tools
CISA is providing examples of detection tools for informational purposes only. CISA does not endorse any commercial product or service, including any subjects of analysis. Any reference to specific commercial products, processes, or services does not constitute or imply their endorsement, recommendation, or favoring by CISA.
There are a number of open-source tools available to investigate adversary activity in Microsoft cloud environments and to detect unusual activity, service principals, and application activity.[4] Publicly available PowerShell tools that network defenders can use to investigate M365 and Microsoft Azure include:
- CISA’s Sparrow,
- Open-source utility Hawk, and
- CrowdStrike’s Azure Reporting Tool (CRT).
Additionally, Microsoft’s Office 365 Management API and Graph API provide an open interface for ingesting telemetry and evaluating service configurations for signs of anomalous activity and intrusion.
Note: these open-source tools are highlighted and explained to assist with on-site investigation and remediation in cloud environments but are not all-encompassing. Open source tools can be complemented by services such as Azure Sentinel, a Microsoft premium service that provides comprehensive analysis tools, including custom detections for the activity indicated.
General Guidance on Using Detection Tools
- Audit the creation and use of service principal credentials. Look for unusual application usage, such as use of dormant applications.
- Audit the assignment of credentials to applications that allow non-interactive sign-in by the application. Look for unexpected trust relationships added to the Azure Active Directory.
- Download the interactive sign-ins from the Azure admin portal or use the Microsoft Sentinel product. Review new token validation time periods with high values and investigate whether it was a legitimate change or an attempt to gain persistence by a threat actor.
Sparrow
CISA created Sparrow to help network defenders detect possible compromised accounts and applications in the Azure/M365 environment. The tool focuses on the narrow scope of user and application activity endemic to identity- and authentication-based attacks seen recently in multiple sectors. It is neither comprehensive nor exhaustive of available data. It is intended to narrow a larger set of available investigation modules and telemetry to those specific to recent attacks on federated identity sources and applications.
CISA advises Sparrow users to take the following actions.
- Use Sparrow to detect any recent domain authentication or federation modifications.
- Domain and federation modification operations are uncommon and should be investigated.
- Examine logs for new and modified credentials applied to applications and service principals; delineate for the credential type. Sparrow can be used to detect the modification of service principals and application credentials.
- Create a timeline for all credential changes, focusing on recent wholesale changes.
- Review the “top actors” for activity in the environment and the number of credential modifications performed.
- Monitor changes in application and service principal credentials.
- Investigate any instances of excessive permissions being granted, including, but not limited to, Exchange Online, Microsoft Graph, and Azure AD Graph.
- Use Sparrow to detect privilege escalation, such as adding a service principal, user, or group to a privileged role.
- Use Sparrow to detect
OAuth consent and users’ consent to applications, which is useful for interpreting changes in adversary TTPs.
- Use Sparrow to identify anomalous Security Assertion Markup Language (SAML) token sign-ins by pivoting on the unified audit log UserAuthenticationValue of 16457, which is an indicator of how a SAML token was built and is a potential indicator for forged SAML tokens.
- Note that this TTP has not been the subject of significant published security research but may indicate an unusual usage of a token, such as guest access for external partners to M365 resources.
- Review the PowerShell logs that Sparrow exports.
- Review PowerShell mailbox sign-ins and validate that the logins are legitimate actions.
- Review PowerShell usage for users with PowerShell in the environment.
- Use Sparrow to check the Graph API application permissions of all service principals and applications in M365/Azure AD.
- Investigate unusual activity regarding Microsoft Graph API permissions (using either the legacy https://graph.windows.net/ or https://graph.microsoft.com). Graph is used frequently as part of these TTPs, often to access and manipulate mailbox resources.
- Review Sparrow’s listed tenant’s Azure AD domains, to see if the domains have been modified.
- For customers with G5 or E5 licensing levels, review MailItemsAccessed for insight into what application identification (ID) was used for accessing users’ mailboxes. Use Sparrow to query for a specific application ID using the app id investigation capability, which will check to see if it is accessing mail or file items.
- The MailItemsAccessed event provides audibility for mailbox data accessed via mail protocols or clients.
- By analyzing the MailItemsAccessed action, incident responders can determine which user mailbox items have been accessed and potentially exfiltrated by a threat actor. This event will be recorded even in some situations where the message was not necessarily read interactively (e.g., bind or sync).[5]
- The resulting suspicious application ID can provide incident responders with a pivot to detect other suspicious applications that require additional analysis.
- Check for changes to applications with regards to the accessing of resources such as mail or file items.
Hawk
Hawk is an open-source, PowerShell-driven, community-developed tool network defenders can use to quickly and easily gather data from O365 and Azure for security investigations. Incident responders and network defenders can investigate specific user principals or the entire tenant. Data it provides include IP addresses and sign-in data. Additionally, Hawk can track IP usage for concurrent login situations.
Hawk users should review login details for administrator accounts and take the following steps.
- Investigate high-value administrative accounts to detect anomalous or unusual activity (Global Admins).
- Enable PowerShell logging, and evaluate PowerShell activity in the environment not used for traditional or expected purposes.
- PowerShell logging does not reveal the exact
cmdlet that was run on the tenant.
- Look for users with unusual sign-in locations, dates, and times.
- Check permissions of service principals and applications in M365/Azure AD.
- Detect the frequency of resource access from unusual places. Use the tool to pivot to a trusted application and see if it is accessing mail or file items.
- Review mailbox rules and recent mailbox rule changes.
CrowdStrike Azure Reporting Tool
CrowdStrike’s Azure Reporting Tool (CRT) can help network defenders analyze their Microsoft Azure AD and M365 environment to help organizations analyze permissions in their AzureAD tenant and service configuration. This tool has minor overlap with Sparrow; it shows unique items, but it does not cover the same areas. CISA is highlighting this tool because it is one of the only free, open-source tools available to investigate this activity and could be used to complement Sparrow.
Detection Tool Distinctions
- Sparrow differs from CRT by looking for specific indicators of compromise associated with the recent attacks.
- CRT focuses on the tenant’s Azure AD permissions and Exchange Online configuration settings instead of the unified audit log, which gives it a different output from Sparrow or Hawk.
- CRT returns the same broad scope of application/delegated permissions for service principals and applications as Hawk.
- As part of its investigation, Sparrow homes in on a narrow set of application permissions given to the Graph API, which is common to the recent attacks.
- CRT looks at Exchange Online federation configuration and federation trust, while Sparrow focuses on listing Azure AD domains.
- Among the items network defenders can use CRT to review are delegated permissions and application permissions, federation configurations, federation trusts, mail forwarding rules, service principals, and objects with KeyCredentials.
Detection Methods
Microsoft breaks the threat actor’s recent activity into four primary stages, which are described below along with associated detection methods. Microsoft describes these stages as beginning with all activity after the compromise of the on-premises identity solution, such as ADFS.[6]
Note: this step provides an entry vector to cloud technology environments, and is unnecessary when the threat actor has compromised an identity solution or credential that allows the APT direct access to the cloud(e.g., without leveraging the SolarWinds Orion vulnerability).
Stage 1: Forging a trusted authentication token used to access resources that trust the on-premises identity provider
These attacks (often referred to as “Golden Security Assertion Markup Language” attacks) can be analyzed using a combination of cloud-based and standard on-premises techniques.[7] For example, network defenders can use OAuth claims for specific principals made at the Azure AD level and compare them to the on-premises identity.
Export sign-in logs from the Azure AD portal and look at the Authentication Method field.
Note: at portal.azure.com, click on a user and review the authentication details (e.g., date, method, result). Without Sentinel, this is the only way to get these logs, which are critical for this effort.
Detection Method 1: Correlating service provider login events with corresponding authentication events in Active Directory Federation Services (ADFS) and Domain Controllers
Using SAML single sign-on, search for any logins to service providers that do not have corresponding event IDs 4769, 1200, and 1202 in the domain.
Detection Method 2: Identifying certificate export events in ADFS
Look for:
- The IP address and Activity_ID in EventCode 410 and the Activity_ID and Instance_ID in EventCode 500.
- Export-PfxCertificate or certutil-exportPFX in Event IDs 4103 and 4104, which may include detection of a certificate extraction technique.
- Deleted certificate extraction with ADFSdump performed using Sysmon Event ID 18 with the pipe name microsoft##widtsqlquery (exclude processes regularly making this pipe connection on the machine).
- Event ID 307 (The Federation Service configuration was changed), which can be correlated to relevant Event ID 510 with the same instance ID for change details (Event ID 510 with the same Instance ID could be more than one event per single Event ID 307 event).
Detection Method 3: Customizing SAML response to identify irregular access
This method serves as prevention for the future (and would only detect future, not past, activity), as it helps identify irregularities from the point of the change forward. Organizations can modify SAML responses to include custom elements for each service provider to monitor and detect any anomalous requests.[8]
Detection Method 4: Detecting malicious ADFS trust modification
A threat actor who gains administrative access to ADFS can add a new, trusted ADFS rather than extracting the certificate and private key as part of a standard Golden SAML attack.[9]
Network defenders should look for:
- Event ID 307 (The Federation Service configuration was changed), which can be correlated to relevant Event ID 510 with the same Instance ID for change details. (Event ID 510 with the same Instance ID could be more than one event per single Event ID 307 event.)
- Review events, particularly searching for Configuration: Type: IssuanceAuthority where Property Value references an unfamiliar domain.
- Possible activity of an interrogating ADFS host by using ADFS PowerShell plugins. Look for changes in the federation trust environment that would indicate new ADFS sources.
Stage 2: Using the forged authentication token to create configuration changes in the Service Provider, such as AzureAD (establishing a foothold)
After the threat actor has compromised the on-premises identity provider, they identify their next series of objectives by reviewing activity in the Microsoft Cloud activity space (Microsoft Azure and M365 tenants).
The threat actor uses the ability to forge authentication tokens to establish a presence in the cloud environment. The actor adds additional credentials to an existing service principal. Once the threat actor has impersonated a privileged AzureAD account, they are likely to further manipulate the Azure/M365 environment (action on objectives in the cloud).
Network defenders should take the following steps.
- Audit the creation and use of service principal and application credentials. Sparrow will detect modifications to these credentials.
- Look for unusual application usage, such as dormant or forgotten applications being used again.
- Audit the assignment of credentials to applications that allow non-interactive sign-in by the application.
- Look for unexpected trust relationships that have been added to AzureAD. (Download the last 30 days of non-interactive sign-ins from the Azure portal or use Azure Sentinel.).[10]
- Use Hawk (and any sub-modules available) to run an investigation on a specific user. Hawk will provide IP addresses, sign-in data, and other data. Hawk can also track IP usage in concurrent login situations.
- Review login details for administrator accounts (e.g., high-value administrative accounts, such as Global Admins). Look for unusual sign-in locations, dates, and times.
- Review new token validation time periods with high values and investigate whether the changes are legitimate or a threat actor’s attempts to gain persistence.
Stage 3: Acquiring an OAuth access token for the application using the forged credentials added to an existing application or service principal and calling APIs with the permissions assigned to that application
In some cases, the threat actor has been observed adding permissions to existing applications or service principals. Additionally the actor has been seen establishing new applications or service principals briefly and using them to add permissions to the existing applications or service principals, possibly to add a layer of indirection (e.g., using it to add a credential to another service principal, and then deleting it).[11]
Network defenders should use Sparrow to:
- Examine highly privileged accounts; specifically using sign-in logs, look for unusual sign-in locations, dates, and times.
- Create a timeline for all credential changes.
- Monitor changes in application credentials (the script will export into csv named AppUpdate_Operations_Export).
- Detect service principal credentials change and service principal change (e.g., if an actor adds new permissions or expands existing permissions).
- Export and view this activity via the ServicePrincipal_Operations_Export.
- Record
OAuth consent and consent to applications
- Export and view this record via the Consent_Operations_Export file.
- Investigate instances of excessive high permissions, including, but not limited to Exchange Online, Microsoft Graph, and Azure AD Graph.
- Review Microsoft Graph API permissions granted to service principals.
- Export and view this activity via the ApplicationGraphPermissions csv file.
- Note: Hawk can also return the full list of service principal permissions for further investigation.
- Review top actors and the amount of credential modifications performed.
- Monitor changes in application credentials.
- Identify manipulation of custom or third-party applications.
- Network defenders should review the catalog of custom or third-party vendors with applications in the Microsoft tenant and perform the above interrogation principles on those applications and trusts.
- Review modifications to federation trust settings.
- Review new token validation time periods with high values and investigate whether this was a legitimate change or an attempt to gain persistence by the threat actor.
- The script detects the escalation of privileges, including the addition of Service Principals (SP) to privileged roles. Export this data into csv called AppRoleAssignment_Operations_Export.
Stage 4: Once access has been established, the threat actor Uses Microsoft Graph API to conduct action on objectives from an external RESTful API (queries impersonating existing applications).
Network defenders should:
- In MailItemsAccessed operations, found within the Unified Audit Log (UAL), review the application ID used (requires G5 or E5 license for this specific detail).
- Query the specific application ID, using the Sparrow script’s app ID investigation capability to interrogate mail and file items accessed for that applicationID (Use the application ID utility for any other suspicious apps that require additional analysis.).
- Check the permissions of an application in M365/AzureAD using Sparrow.
- Hawk will return Azure_Application_Audit, and Sparrow will return ApplicationGraphPermissions.
- Network defenders will see the IP address that Graph API uses.
- Note: the Microsoft IP address may not show up as a virtual private server/anonymized endpoint.
- Investigate a specific service principal, if it is a user-specific user account, in Hawk. This activity is challenging to see without Azure Sentinel or manually downloading and reviewing logs from the sign-in portal.
Microsoft Telemetry Nuances
The existing tools and techniques used to evaluate cloud-based telemetry sources present challenges not represented in traditional forensic techniques. Primarily, the amount of telemetry retention is far less than the traditional logging facilities of on-premises data sources. Threat actor activity that is more than 90 days old is unlikely to have been saved by traditional sources or be visible with the Microsoft M365 Management API or in the UAL.
Service principal logging is available using the Azure Portal via the “Service Principal Sign-ins” feature. Enable settings in the Azure Portal (see “Diagnostic Setting”) to ingest logs into Sentinel or a third-party security information and event management (SIEM) tool. An Azure Premium P1 or Premium P2 license is necessary to access this setting as well as other features, such as a log analytics workspace, storage account, or event hub.[12] These logs must be downloaded manually if not ingested by one of the methods listed in the Detection Methods section.
Global Administrator rights are often required by tools other than Hawk and Sparrow to evaluate M365 cloud security posture. Logging capability and visibility of data varies by licensing models and subscription to premium services, such as Microsoft Defender for O365 and Azure Sentinel. According to CrowdStrike, “There was an inability to audit via API, and there is the requirement for global admin rights to view important information which we found to be excessive. Key information should be easily accessible.”[13]
Documentation for specific event codes, such as UserAuthenticationMethod 16457, which may indicate a suspicious SAML token forgery, is no longer available in the M365 Unified Access Log. Auditing narratives on some events no longer exist as part of core Microsoft documentation sources.
The use of industry-standard SIEMs for log detection is crucial for providing historical context for threat hunting in Microsoft cloud environments. Standard G3/E3 licenses only provide 90 days of auditing; with the advanced auditing license that is provided with a G5/E5 license, audit logs can be extended to retain information for a year. CISA notes that this license change is proactive, rather than reactive: it allows enhanced visibility and features for telemetry from the moment of integration but does not provide retroactive visibility on previous events or historical context.
A properly configured SIEM can provide:
- Longer term storage of log data.
- Cross correlation of log data with endpoint data and network data (such as those produced by ADFS servers), endpoint detection and response data, and identity provider information.
- Ability to query use of application connectors in Azure.
Built-in tools, such as Microsoft Cloud Services and M365 applications, provide much of the same visibility available from custom tools and are mapped to the MITRE ATT&CK framework and easy-to-understand dashboards.[14] However, these tools often do not have the ability to pull historical data older than seven days. Therefore, storage solutions that appropriately meet governance standards and usability metrics for analysts for the SIEM must be carefully planned and arranged.
by Contributed | Jan 8, 2021 | Technology
This article is contributed. See the original author and article here.
Overview
This article details building and deploying a container to an Azure Kubernetes Service(AKS) cluster in Azure Government cloud using Azure DevOps.
Private AKS Clusters has the API Server accessible only within the virtual network. This limits the deployments from Hosted Azure DevOps agents. To overcome this, a self-hosted agent within the same virtual network needs to be deployed.
Access to Azure Container Registry (ACR) can be restricted to the virtual network using Private Endpoints. This will limit ACR exposure to public internet. Since private ACR is available only within the vnet, self-hosted devops agents comes to the rescue.
Lastly, to ensure that Azure Pipelines can deploy to Azure Government Clouds, Azure Resource Manager Service Connection should be created with an Environment parameter.
Setup
The following steps replicates the above setup. The setup has 3 subnets with the following components
- Azure Container Registry Private Endpoint
- Azure DevOps self hosted agent
- Azure Kubernetes Service
Network setup
Create a Virtual Network and add 3 subnets.
Use the below values for reference:
Address Space: 10.0.0.0/16
Subnet name
|
Address Space
|
|---|
acr-snt |
10.0.1.0/24 |
devops-snt |
10.0.2.0/24 |
aks-snt |
10.0.4.0/22 |
az group create --name gov-devops --location usgovtexas
az network vnet create
--name gov-devops-vnet
--resource-group gov-devops
--subnet-name default
az network vnet subnet create
--address-prefixes 10.0.1.0/24
--name acr-snt
--resource-group gov-devops
--vnet-name gov-devops-vnet
az network vnet subnet create
--address-prefixes 10.0.2.0/24
--name devops-snt
--resource-group gov-devops
--vnet-name gov-devops-vnet
az network vnet subnet create
--address-prefixes 10.0.4.0/22
--name aks-snt
--resource-group gov-devops
--vnet-name gov-devops-vnet
Create ACR
Create a Container Registry in the premium tier (required for private link)
az acr create --resource-group gov-devops
--name mygovacr --sku Premium
Create the registry’s private endpoint in the acr-snt subnet
az network vnet subnet update
--name acr-snt
--vnet-name gov-devops-vnet
--resource-group gov-devops
--disable-private-endpoint-network-policies
az network private-dns zone create
--resource-group gov-devops
--name "privatelink.azurecr.io"
az network private-dns link vnet create
--resource-group gov-devops
--zone-name "privatelink.azurecr.io"
--name govdns
--virtual-network gov-devops-vnet
--registration-enabled false
REGISTRY_ID=$(az acr show --name mygovacr
--query 'id' --output tsv)
az network private-endpoint create
--name myPrivateEndpoint
--resource-group gov-devops
--vnet-name gov-devops-vnet
--subnet acr-snt
--private-connection-resource-id $REGISTRY_ID
--group-id registry
--connection-name myConnection
NETWORK_INTERFACE_ID=$(az network private-endpoint show
--name myPrivateEndpoint
--resource-group gov-devops
--query 'networkInterfaces[0].id'
--output tsv)
PRIVATE_IP=$(az resource show
--ids $NETWORK_INTERFACE_ID
--api-version 2019-04-01
--query 'properties.ipConfigurations[1].properties.privateIPAddress'
--output tsv)
DATA_ENDPOINT_PRIVATE_IP=$(az resource show
--ids $NETWORK_INTERFACE_ID
--api-version 2019-04-01
--query 'properties.ipConfigurations[0].properties.privateIPAddress'
--output tsv)
az network private-dns record-set a create
--name mygovacr
--zone-name privatelink.azurecr.io
--resource-group gov-devops
# Specify registry region in data endpoint name
az network private-dns record-set a create
--name mygovacr.usgovtexas.data
--zone-name privatelink.azurecr.io
--resource-group gov-devops
az network private-dns record-set a add-record
--record-set-name mygovacr
--zone-name privatelink.azurecr.io
--resource-group gov-devops
--ipv4-address $PRIVATE_IP
# Specify registry region in data endpoint name
az network private-dns record-set a add-record
--record-set-name mygovacr.usgovtexas.data
--zone-name privatelink.azurecr.io
--resource-group gov-devops
--ipv4-address $DATA_ENDPOINT_PRIVATE_IP
az acr update --name mygovacr --public-network-enabled false
Choose one of the below authentication methods to perform docker login from the DevOps pipelines
az acr update -n mygovacr --admin-enabled true
Note the admin username and password from the ACR Access Keys blade in the portal
Create AKS
Create a private AKS cluster in the aks-snt subnet
Integrate ACR with AKS or create a pull secret
kubectl create secret docker-registry regcred
--docker-server=<your-registry-server>
--docker-username=<your-name>
--docker-password=<your-pword>
--docker-email=<your-email>
Create a VM and deploy DevOps agent
Create a Linux VM in devops-snt subnet to host the DevOps agent.
az vm create
--resource-group gov-devops
--name devopsagent
--image UbuntuLTS
--admin-username azureuser
--generate-ssh-keys
--subnet devops-snt
--vnet-name gov-devops-vnet
Note the publicIpAddress from the output
Deploy the DevOps agent on the VM
- Generate a PAT token
- Create an Agent Pool
- Click Add Pool
- Select New
- Select pool Type as Self-hosted
- Enter a name as govpool
- Select New Agent -> Linux
- Copy the Agent Download link
- Deploy the agent on the VM
ssh azureuser@publicIpAddress
curl -O <<url copied above>
mkdir myagent && cd myagent
tar zxvf ../{tar file name}
./config.sh
sudo ./svc.sh install
sudo ./svc.sh start
Install docker, az cli and kubectl
sudo apt -y update
sudo apt -y install apt-transport-https ca-certificates curl gnupg-agent software-properties-common
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io
sudo usermod -aG docker $USER
newgrp docker
curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash
sudo az aks install-cli
Create the pipeline
Create Service Connections
From Azure DevOps, create a Docker Registry Service Connection
- Navigate to Project Settings
- Click New Service Connection
- Select Docker Registry
- Select Registry Type as Others
- Provide the below details:
- Docker Registry: { ACR url eg: https://mygovacr.azurecr.us }
- Docker ID: { admin username or Service principal App ID }
- Docker Password: { admin password or service principal secret }
- Service Connection name: { Connection name }
To run kubectl task against the AKS cluster, Create Service Principal and grant contributor access to the resource group
From Azure DevOps, create an Azure Resource Manager Service Connection
- Navigate to Project Settings
- Click New Service Connection
- Select Azure Resource Manager
- Select Service Principal (manual)
- Provide the below details:
- Environment: Azure US Government
- Subscription Id: { Gov Subscription ID }
- Subscription Name: { Gov Subscription Name }
- Service Principal Id: { Create Service Principal using Portal or PowerShell }
- Credential: Service Principal key: { Secret of the Service Principal }
- Tenant Id: { Gov Tenant ID }
- Service Connection name: { Connection name }
Create pipeline
- Fork the sample repo
- Copy the contents below to a deploy.yaml file in the repo (Remove imagePullSecrets if ACR integrated with AKS)
apiVersion: v1
kind: Pod
metadata:
name: private-reg
spec:
containers:
- name: private-reg-container
image: mygovacr.azurecr.us/nginx-echo-headers:latest
imagePullSecrets:
- name: regcred
- Navigate to the project in Azure DevOps
- Go to Pipelines, and then select New Pipeline
- Select GitHub as the location of your source code and select your repository
- Select Starter pipeline
- Replace the contents of the yaml in the Review tab
trigger:
- master
pool:
name: 'govpool'
steps:
- task: Docker@2
inputs:
containerRegistry: '{Docker Registry Service Connection Name}'
repository: 'nginx-echo-headers'
command: 'buildAndPush'
Dockerfile: 'Dockerfile'
tags: 'latest'
- task: Kubernetes@1
inputs:
connectionType: 'Azure Resource Manager'
azureSubscriptionEndpoint: '{Azure Resource Manager Service Connection Name}'
azureResourceGroup: 'gov-devops'
kubernetesCluster: '{aks cluster name}'
command: 'apply'
arguments: '-f deploy.yaml'
Summary
The setup facilitates secure deployments to private ACR/AKS on Azure Government Cloud using Pipelines.
Recent Comments