Design principles of Cloud Katana

Figure 1: Cloud Katana design principles.

Cloud Katana was designed and developed under the following principles:

• A serverless execution model.
• Compute on-demand as a web API.
• YAML-based attack definitions.
• Orchestrated stateful execution.
• Secure authentication and authorization.
• Managed identity integration.
• Granular access control to Azure resources.
• Programming language agnostic clients.
• Cloud and on-premise coverage.

A serverless execution model

Cloud Katana is a cloud-native solution that relies on platform as a service (PaaS) concepts to provide a simplified and scalable event-driven solution without worrying about deploying and maintaining the underlying infrastructure used to execute simulations.

To meet this need, Cloud Katana uses Azure Functions to abstract the operating system layer from the code through a pay-per-execution billing model that automatically scales based on trigger invocations.

Figure 2: A basic definition of a serverless execution model.

Compute on-demand as a web API

Simulation steps are represented as blocks of code called functions and invoked via HTTP requests through a built-in serverless web API.

With this feature, one could simply send an HTTP request with information about the specific simulation and wait for the infrastructure underneath to process the request. Currently, all functions are written in PowerShell (subject to change) and categorized following the MITRE ATT&CK framework.

Figure 3: Compute on demand via a serverless web API and categorized by ATT&CK tactics.

YAML-based attack definitions

Every attack simulation is documented in a YAML-based format to aggregate metadata such as title, description, ATT&CK mappings, expected input and output, and even preconditions to make sure we have the right permissions before running a simulation step. This facilitates the processing of every documented action programmatically and the automatic setup of a few other resources.

Figure 4: YAML-based documentation example.

Orchestrated stateful execution

The project is also designed to handle state and ensure reliability across numerous attack simulations by using an extension of Azure functions named durable functions. This feature allows the orchestration and execution of scenarios where actions could depend on the state and output of other simulation steps. This is good to define specific attack paths as code.

Figure 5: Orchestrated stateful execution to execute chains of events.

Secure authentication and authorization

Cloud Katana also enforces authentication and authorization best practices to secure the application.

Authentication

The project uses the Microsoft Identity Platform (also known as Azure Active Directory or Azure AD) as its identity provider to authenticate clients. This feature requires a registered Azure AD application, which allows users to connect to the Azure Function app using OAuth authentication.

In addition, using an identity provider enables the following features:

• Conditional access policies.
• The use of multifactor authentication.
• Single sign-on (SSO).

Figure 6: OAuth device authorization grant flow used by Cloud Katana.

Authorization

Besides enforcing users to authenticate before executing simulations, the project also implements “Application Role Assignments” to restrict access to selected users. This allows organizations to select who can use the project in their environments.

Managed identities integration

Furthermore, when executing simulations in Azure, Cloud Katana uses a user-assigned managed identity to access Azure AD-protected resources. One of the advantages of managed identities is that it removes the need to provision or rotate any secrets.

Figure 7: A user-assigned managed identity accessing Azure resources.

Granular access control to Azure resources

Access to Azure resources is defined by the permissions assigned to the managed identity. We currently cover Azure-based scenarios. Therefore, we use permissions associated with each major set of Microsoft Graph APIs to control access to specific Azure resources.

For example, if we wanted to use Cloud Katana to add credentials to an application, we would need to grant the following permissions (from least to most privileged) to the managed identity:

• Application.ReadWrite.OwnedBy
• Application.Read.Write.All

Figure 8: Cloud Katana adding credentials to an Azure AD application via Microsoft Graph API.

Programming language agnostic clients

Another feature that makes Cloud Katana a very powerful tool is the flexibility to use any programming language to request simulations. If the client used to interact with Cloud Katana can handle the Azure AD authentication process, it doesn’t matter how the simulation is requested.

Figure 9: Programming language agnostic clients to interact with the serverless web API.

Microsoft Authentication libraries are available via PowerShell as MSAL.PS and Python as MSAL. We could also use other open-source projects, such as Jupyter Notebooks, to create repetitive templates to show the execution of simulations and share the process with other security researchers.

Figure 10: Running a Jupyter Notebook to execute simulations.

Cloud and on-premise simulations

Finally, we are currently experimenting with Azure App Service Hybrid Connections to not only run simulations in the cloud but also on-premises. Hybrid Connections use a relay agent to securely expose services that run on-premises to the public cloud. The relay agent sits in the middle between the on-premise server and the Cloud Katana Azure Function app.

A relay agent—Hybrid Connection Manager (HCM)—is set up on the on-premise server and configured to call out to the Azure Relay over port 443. The Cloud Katana function app then connects to the Azure Relay to interact with the on-premise server and execute simulations locally. The connection uses TLS 1.2 for security and shared access signature (SAS) keys for authentication and authorization.

Figure 11: Running simulations on resources on-premise from Cloud Katana function app.

Deploy Cloud Katana

After learning about Cloud Katana’s design principles, you can check our docs to deploy the project.

Assess security controls

Once the Azure function app is deployed successfully, you can run some of the demos available in our docs. The main idea is not only to write simulation steps as code and execute them on demand but also to assess detections and security controls.

Future work

Besides automating and releasing more simulation steps, we are also going to be working on several features to improve the deployment of the tool and execution scope. The list below shows some of the ideas we currently have (not in a specific order):

• Simulations in other cloud providers.
• On-premise simulations via Azure Hybrid Connection management services.
• A data model to document chains of simulation steps in a more flexible way.
• An Azure DevOps continuous integration and continuous delay (CI/CD) pipeline to deploy and maintain the Azure Function app.
• Integration with SimuLand to give security researchers an option to deploy it all together.
• A way to schedule functions to run periodically as a service in a network environment.
• A way to verify if alerts triggered or data was generated after each simulation.
• Plugin-like capabilities to integrate other projects, such as Atomic Red Team, into the framework.

Community contributions

We look forward to contributions and feedback from the community. If you would like to contribute to specific areas of the project, open an issue in our GitHub repository and share your ideas. Look at the previous “Future Work” section for some ideas.

Learn more

To learn more about this open-source initiative, visit the Cloud Katana GitHub repository.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.

The post Automating security assessments using Cloud Katana appeared first on Microsoft Security Blog.

Today, we are excited to release a dataset generated from the first simulation scenario to provide security researchers with an option to access data mapped to attack behavior without deploying the full environment.

Sharing SimuLand data to expedite research

In our previous blog post, we showed a basic threat research methodology and where the SimuLand project fits. One of the next steps after a simulation is the collection and analysis of the data generated. We believe we can help expedite the research process by sharing the security events generated during testing.

Figure 1: Map of a threat research methodology emphasizing SimuLand and Security Datasets.

What security events?

The data that you could collect from a SimuLand scenario depends on the adversary tradecraft simulated and the security controls in place. Based on the first simulation scenario, these are some of the security events you can collect and map to adversary behavior:

Figure 2: Adversarial techniques mapped to sources of data.

How are security events collected?

Security events generated during a simulation can be collected using the following APIs:

• Microsoft 365 Defender Advanced hunting API
• Azure Log Analytics workspace API

Where can I download the dataset from?

Rather than creating a new GitHub repository and storing all the security events generated, we are contributing every single dataset to the GitHub repository of the Security Datasets project. This is a community-driven effort developed to share pre-recorded datasets with the Information Security (InfoSec) community to expedite data analysis and threat research. This is another open-source initiative created and maintained by the Open Threat Research community.

You can find our first dataset here.

What can you do with the dataset?

Besides empowering security researchers to understand the underlying behavior of attack techniques, sharing a dataset also helps to:

• Expedite the development and validation of detection rules.
• Identify and validate a chain of events to model adversary behavior.
• Facilitate labeled and unlabeled data for initial research and feature development.
• Automate simulation exercises by injecting pre-recorded events into data pipelines.
• Complement training material and expedite the creation of data analysis use cases.
• Expedite the creation of internal or community events, such as capture-the-flag or hackathons, where the data is used to create challenges and encourage collaboration.

What’s next

With this first dataset, we commit ourselves to release the security events we generate in our lab environment along with new lab guides. We also hope you can help us identify new sources of data to improve the project and data collection strategy.

Learn more

To learn more about this open-source initiative, visit the SimuLand GitHub repository.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.

The post Sharing the first SimuLand dataset to expedite research and learn about adversary tradecraft appeared first on Microsoft Security Blog.

What is SimuLand?

SimuLand is an open-source initiative by Microsoft to help security researchers around the world deploy lab environments that reproduce well-known techniques used in real attack scenarios, actively test and verify the effectiveness of related Microsoft 365 Defender, Azure Defender, and Azure Sentinel detections, and extend threat research using telemetry and forensic artifacts generated after each simulation exercise.

These lab environments will provide use cases from a variety of data sources including telemetry from  Microsoft 365 Defender security products, Azure Defender, and other integrated data sources through Azure Sentinel data connectors.

The purpose behind SimuLand

As we build out the SimuLand framework and start populating lab environments, we will be working under the following basic principles:

• Understand the underlying behavior and functionality of adversary tradecraft.
• Identify mitigations and attacker paths by documenting preconditions for each attacker action.
• Expedite the design and deployment of threat research lab environments.
• Stay up to date with the latest techniques and tools used by real threat actors.
• Identify, document, and share relevant data sources to model and detect adversary actions.
• Validate and tune detection capabilities.

Process integration

Our goal is to have SimuLand integrated with threat research methodologies where dynamic analysis is applied to end-to-end simulation scenarios. The image below shows where SimuLand would fit.

Figure 1: Map of threat research methodologies.

The structure

The structure of the project is very simple and broken down in a modular way so that we can re-use and test a few combinations of attacker actions with different lab environment designs. In addition, step-by-step lab guides are provided to aggregate all the required documentation to not only execute the end-to-end simulation exercise but also prepare and deploy the lab environment. This initiative stems from various open-source projects such as Azure Sentinel2Go and Blacksmith from the Open Threat Research (OTR) community.

How to prepare

Almost every environment contributed through this initiative requires at least a Microsoft 365 E5 license (paid or trial) and an Azure tenant. Other deployment requirements are specified in the lab guides.

The deployment process

Depending on the lab guide being worked on, the design of the network environments might change a little. While some labs will replicate a hybrid cross-domain environment (on-premises to cloud), others will focus only on resources in the cloud. Additionally, Azure Resource Manager (ARM) templates are provided to expedite the deployment process and document the infrastructure as code. The image below represents the first environment released today.

Figure 2: Network environment.

Simulate and detect

Every simulation plan provided through this project is research-based and broken down into attacker actions mapped to the MITRE ATT&CK framework. The goal of the simulate and detect component is to also summarize the main steps used by a threat actor to accomplish a specific object and allow security researchers to get familiarized with the attacker behavior at a high level. For example, the image below shows some of the ways one could export the token signing certificate from a federation server.

Figure 3: Example of exporting token signing certificate from federation server.

Organize security alerts

Finally, from a defensive perspective, simulation steps will be mapped to detection queries and alerts from Microsoft 365 Defender security products, Azure Defender, and Azure Sentinel. You can use similar views like the one below from the Microsoft 365 security portal to organize security alerts. We believe this will help guide some of the extended threat research generated from the simulation exercise.

Figure 4: Microsoft 365 Defender security portal.

You can also use the Azure Sentinel investigation experience to aggregate alerts from Microsoft 365 defender and Azure Sentinel to provide additional context.

Figure 5: Azure Sentinel investigation view.

Future work

Besides creating more scenarios, we are also going to be working on several features to improve the project. The list below shows some of the ideas we currently have:

• A data model to document the simulation steps in a more organized and standardized way.
• A CI/CD pipeline with Azure DevOps to deploy and maintain infrastructure.
• Automation of attack actions in the cloud via Azure Functions.
• Capabilities to export and share telemetry generated with the InfoSec community.
• Microsoft Defender evaluation labs integration.

Community contributions

We look forward to contributions and feedback from the community. If you would like to contribute to specific areas of the project, open an issue in our GitHub repository and share your ideas. Take a look at the “Future Work” section for some ideas.

New end-to-end simulation scenarios

If you would like to share a new end-to-end attacker path, let us know by opening an issue in our GitHub repository, and we would be happy to collaborate and provide some resources to make it happen. We would then share the output with the community through this project after the appropriate validation and detection development process. Remember that simulation scenarios are not only based on well-known attack paths, but also the creativity of the researcher.

Additional detection queries

If you build detection rules that can be added to our simulate and detect section, feel free to open an issue and we will help you to contribute to the official Microsoft 365 Defender and Azure Sentinel detection repositories. We use queries directly from those two resources in our documents.

Learn more

To learn more about this open-source initiative, visit the SimuLand GitHub repository.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.

The post SimuLand: Understand adversary tradecraft and improve detection strategies appeared first on Microsoft Security Blog.