Archive

Archive for the ‘Integrated Threat Protection’ Category

The evolution of a matrix: How ATT&CK for Containers was built

July 21st, 2021 No comments

Note: The content of this post is being released jointly with the Center for Threat-Informed Defense. It is co-authored with Chris Ante and Matthew Bajzek. The Center post can be found here.

As containers become a major part of many organizations’ IT workloads, it becomes crucial to consider the unique security threats that target such environments when building security solutions. The first step in this process is understanding the relevant attack landscape.

The MITRE ATT&CK® team has received frequent questions from the community about if or when ATT&CK would include coverage for adversary behavior in containers. Previous iterations of ATT&CK have included references to containers (for example, Resource Hijacking) and some clearly container-relevant techniques (for example, Implant Internal Image), but the coverage was insufficient to provide network defenders a holistic view of how containers are being targeted in enterprise environments.

Addressing the need for a common framework for understanding container threats

Given clear community interest, inspiration from Microsoft’s work on the threat matrix for Kubernetes, and the publication of research from other teams, the Center for Threat-Informed Defense launched an investigation (sponsored by several Center members including Microsoft) that examined the viability of adding containers content to ATT&CK. The purpose of the Container Techniques project was to investigate adversarial behavior in containerization technologies and determine whether there was enough open-source intelligence to warrant the creation of an ATT&CK for Containers matrix, resulting in either new ATT&CK content or a report on the state of in-the-wild Container-based tactics, techniques, and procedures (TTPs). The Center’s research team quickly concluded that there was more than enough open-source intelligence to justify technique development, ultimately resulting in the new matrix.

As of the ATT&CK v9 release, the ATT&CK for Containers matrix is officially available. More details about the Containers matrix can be found in MITRE-Engenuity’s announcement blog. Some highlights of the new matrix include related software entries, procedure examples to help network defenders better understand new container-centric techniques, data sources to match the recent ATT&CK data sources refactor, and many others.

A matrix of attack techniques related to containerization technologies, organized by stages of an attack.

Figure 1. ATT&CK for Containers matrix.

Evolving the threat matrix

MITRE ATT&CK has become the common vocabulary for describing real-world adversary behavior. ATT&CK offers organizations a method to measure their defenses against threats that impact their environment and identify possible gaps. With ATT&CK’s approach of methodically outlining the possible threats, Microsoft built the threat matrix for Kubernetes, which was one of the first attempts to systematically map the attack surface of Kubernetes. An updated version of the matrix was released earlier in 2021.

A matrix of attack techniques specific to Kubernetes, organized by stages of an attack.

Figure 2: Threat matrix for Kubernetes.

Microsoft took part in the Center’s project and contributed knowledge that the company gained in the field of container security. Microsoft’s unparalleled visibility into threats helps to identify real-world attacks against containerized workloads and provide information about tactics and techniques used in those attacks. One example of such an attack is a cryptocurrency mining campaign that targeted Kubernetes. In this incident, Microsoft saw evidence of the following techniques from the Microsoft threat matrix:

  • Exposed sensitive interfaces
  • New container
  • Pod/container name similarity
  • List Kubernetes secrets
  • Access Kubernetes API server
  • Resource Hijacking

The techniques that went into ATT&CK for Containers are different from those in the Microsoft threat matrix. As described in a blog post by the Center, it was preferable to use an existing ATT&CK technique rather than create a new one when possible. Therefore, several techniques from the threat matrix were mapped into existing Enterprise ATT&CK techniques. For example, in the techniques listed above, “Exposed sensitive interfaces” from the threat matrix is equivalent to ATT&CK’s “External Remote Services.”

The Center’s process for leveraging Microsoft’s Kubernetes threat matrix was as follows:

  • Cross-referencing threat intelligence with the techniques in the Kubernetes threat matrix.
  • Determining whether techniques with sufficient intelligence backing were already covered by existing Enterprise ATT&CK techniques, or whether they justified the creation of one or more new techniques or sub-techniques.

Considering Microsoft’s tactics mapping for specific techniques and how they fit within ATT&CK’s Enterprise, Cloud, and Containers matrix scoping, as in the case of multiple forms of “lateral movement,” the Center instead identified pivots from one ATT&CK platform matrix to another (for example, Containers to Cloud).

The following are examples of techniques from Microsoft’s matrix that were re-scoped to fit into existing Enterprise ATT&CK techniques:

Microsoft threat matrix   MITRE ATT&CK
Application vulnerability –> Exploit Public-Facing Application
Exposed sensitive interfaces –> External Remote Services
Clear container logs –> Indicator Removal on Host
Pod/container name similarity –> Masquerading: Match Legitimate Name or Location
Access Kubelet API –> Network Service Scanning

Meanwhile, the following are examples of techniques from the Microsoft threat matrix that were re-scoped based on the Center’s platform decisions and additional open-source intelligence, with additional detail on each technique/sub-technique available in its description within ATT&CK for Containers:

Microsoft threat matrix   MITRE ATT&CK
Exec into container + bash/cmd inside container –> Container Administration Command
New container –> Deploy Container
Kubernetes CronJob –> Scheduled Task/Job: Container Orchestration Job
HostPath mount + Writable volume mounts on the host –> Escape to Host

Not all the techniques and tactics that appear in the Microsoft threat matrix went into the new ATT&CK matrix. ATT&CK focuses on real-world techniques that are seen in the wild. In contrast, many of the techniques in the threat matrix were observed during research work and not necessarily as part of an active attack. For example, “CoreDNS poisoning” from the updated matrix is a possible attack vector but hasn’t been seen in the wild yet.

ATT&CK is dynamic

ATT&CK for Containers is by no means finished, and we look forward to future additions based on new intelligence and further community contributions. Before the public release of ATT&CK for Containers, Microsoft released an updated version of the threat matrix for Kubernetes, which speaks to the fast-paced evolution of this technology space and the need to keep up with new adversary behaviors.

The next step for the ATT&CK team is to assess the new content in Microsoft’s matrix and consider it for potential future inclusion in ATT&CK based on the factors described above. Microsoft and the ATT&CK team will continue to collaborate to ensure that container techniques coverage in ATT&CK is up-to-date and can continue to serve the need of the community.

With the completion of this Center project, ATT&CK for Containers will be maintained by the ATT&CK team, who would love your continuous feedback and contribution! Let the team know what you think, what could be improved, and most importantly what you see adversaries doing in the wild related to containers. Feel free to send an email at any time to attack@mitre.org. If you have ideas for other research and development projects that the Center should consider, please send an email to ctid@mitre-engenuity.org.

Learn more

To learn how Microsoft can help you protect containers and relevant technologies today, read about Microsoft Defender for Endpoint and Azure Defender.

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 The evolution of a matrix: How ATT&CK for Containers was built appeared first on Microsoft Security Blog.

Microsoft to acquire RiskIQ to strengthen cybersecurity of digital transformation and hybrid work

July 12th, 2021 No comments

Organizations are increasingly using the cloud to reimagine every facet of their business. Hybrid work has accelerated this digital transformation, and customers are challenged with the increasing sophistication and frequency of cyberattacks. Today, Microsoft is announcing that we have entered into a definitive agreement to acquire RiskIQ, a leader in global threat intelligence and attack surface management, to help our shared customers build a more comprehensive view of the global threats to their businesses, better understand vulnerable internet-facing assets, and build world-class threat intelligence.

As organizations pursue this digital transformation and embrace the concept of Zero Trust, their applications, infrastructure, and even IoT applications are increasingly running across multiple clouds and hybrid cloud environments. Effectively the internet is becoming their new network, and it’s increasingly critical to understand the full scope of their assets to reduce their attack surface.

RiskIQ helps customers discover and assess the security of their entire enterprise attack surface—in the Microsoft cloud, AWS, other clouds, on-premises, and from their supply chain. With more than a decade of experience scanning and analyzing the internet, RiskIQ can help enterprises identify and remediate vulnerable assets before an attacker can capitalize on them.

“The vision and mission of RiskIQ is to provide unmatched internet visibility and insights to better protect and inform our customers and partners’ security programs. We’re thrilled to add RiskIQ’s Attack Surface and Threat Intelligence solutions to the Microsoft Security portfolio, extending and accelerating our impact. Our combined capabilities will enable best-in-class protection, investigations, and response against today’s threats.”—RiskIQ Cofounder and CEO Elias Manousos

In addition, RiskIQ offers global threat intelligence collected from across the internet, crowd-sourced through its PassiveTotal community of security researchers and analyzed using machine learning. Organizations can leverage RiskIQ threat intelligence to gain context into the source of attacks, tools and systems, and indicators of compromise to detect and neutralize attacks quickly.

The combination of RiskIQ’s attack surface management and threat intelligence empowers security teams to assemble, graph, and identify connections between their digital attack surface and attacker infrastructure and activities to help provide increased protection and faster response.

Microsoft has long been a leader in delivering end-to-end cloud-native security with Microsoft 365 Defender, Microsoft Azure Defender, and Microsoft Azure Sentinel that help protect, detect, and respond to threats in multi-cloud and hybrid cloud environments. With the acquisition of RiskIQ, we will continue our mission to help customers defend their growing digital estate against increasing cyber threats.

RiskIQ has built a strong customer base and community of security professionals who we will continue to support, nurture, and grow. RiskIQ’s technology and team will be a powerful addition to our security portfolio to best serve our mutual customers. For more information about RiskIQ check out their website or request a demo.

Learn more

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 Microsoft to acquire RiskIQ to strengthen cybersecurity of digital transformation and hybrid work appeared first on Microsoft Security Blog.

Microsoft named a Visionary in the 2021 Gartner Magic Quadrant for SIEM for Azure Sentinel

July 8th, 2021 No comments

We’re pleased to announce that in its first year of inclusion in the Gartner Magic Quadrant report, Microsoft Azure Sentinel has been named a Visionary, where we were recognized for our completeness of vision for SIEM.1

Gartner has said that “cloud SIEM will be the future of how many organizations consume technology.”2 We wholeheartedly agree! Today, security teams are constantly asked to do more with less. They need to protect expanding digital estates, detect increasingly advanced threats through huge amounts of noise, and keep up with a massive backlog of investigations.

Azure Sentinel is built from the ground up to be completely cloud-native, and it enables security teams to focus on protecting their organizations instead of maintaining infrastructure. It collects, correlates, and analyzes data at cloud scale across the entire organization, resulting in higher efficiency and more effective security analytics.

We released Azure Sentinel in November 2019 as the first cloud-native SIEM on a major public cloud. Since then, we’ve helped more than 9,000 customers across a broad range of verticals modernize their security operations and have received industry recognition for our market-leading approach.

One of the most fulfilling things about working on Azure Sentinel has been seeing our customers realize the value of our vision firsthand. At MVP Healthcare, moving SecOps to the cloud gave the security team unprecedented agility, allowing them to react and scale faster. At ASOS, Azure Sentinel empowered the security team to cut issue resolution times in half. And at LinkedIn, moving to Azure Sentinel allowed them to significantly reduce operational overhead, plus reduce investigation times dramatically.

We’re honored that we have been able to help so many organizations during Azure Sentinel’s short time in market and are thrilled that we were recognized in this Gartner report for our vision for the future of SIEM.

Looking back and looking forward

While we’re excited about how far we’ve come in the last year and a half, we’re just getting started. Every day, we’re learning from customers and partners about how we can improve. And we aren’t slowing down—empowering SecOps with new innovations for Azure Sentinel is one of the highest priorities for our security engineering team.

In 2021, we’ve delivered key innovations across a variety of investment areas, including data collection, AI, machine learning, automation, and much more. A few highlights include:

  • Expanding visibility across all security assets, platforms, and clouds with more than 50 new connectors, including for security solutions like Cisco Umbrella, ITSM solutions like ServiceNow, and other clouds—with many more in development.
  • Enabling efficiency and faster response with automation innovations such as the release of automation rules, a simple framework for leveraging automation that’s highly integrated into the day-to-day SecOps workstream, as well as new automation connectors and playbooks.
  • Helping security teams deploy integrations and use cases faster with solutions, which allow you to deploy connectors, workbooks, playbooks, detections, and all other content related to integration in one package.
  • Empowering SecOps with integrated SIEM and XDR, such as Microsoft 365 Defender incidents integration, allowing users to seamlessly pivot between the breadth of SIEM and the depth of XDR while investigating.
  • Democratizing machine learning with customizable machine learning anomalies, which gives security analysts a code-free experience to customize machine learning to their individual organizations and use them in detections and threat hunting.
  • And much more. We invite you to read more about our recent innovations from Microsoft Ignite 2021 and from the recent RSA Conference 2021.

We have a long and exciting journey ahead and we look forward to helping you further streamline and strengthen your security—and enabling SecOps to be more efficient and effective than ever.

As always, to our customers, thank you for coming with us on this journey. We love working with you and hearing your feedback!

Learn more

If you’re ready to get started with Azure Sentinel, we invite you to sign up for a trial today.

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.

 


Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.

1Gartner, Magic Quadrant for Security Information and Event Management Kelly Kavanagh, Toby Bussa, John Collins, 29 June 2021.

2“Questions to Answer Before Adopting Cloud SIEM Solutions”, Kelly Kavanagh, Gorka Sadowski, Toby Bussa, July 27 2020.

The post Microsoft named a Visionary in the 2021 Gartner Magic Quadrant for SIEM for Azure Sentinel appeared first on Microsoft Security Blog.

Accessibility and usability for all in Azure Sentinel

July 7th, 2021 No comments

As a father of a child on the Autism spectrum who relies completely on digital media for his learning, I fully appreciate the impact that digital accessibility can have on people with disabilities. Designing with accessibility in mind greatly expands the impact of Microsoft solutions. What many don’t realize, however, is that the impact of accessible design is even bigger than that. When we design for accessibility, everyone benefits.

For example, television video captioning was initially designed for the benefit of people who are hard-of-hearing. Today, it’s far more widely used, such as in loud places where people still want to watch TV and follow the context of the images. We at Microsoft and many of our customers make extensive use of video captioning in Microsoft Teams meetings. This makes the meetings not just accessible, but also convenient for people who may need to join meetings in noisy places—a perfect example of the widespread benefits of accessible design. Microsoft’s product design principles are based on a consistent approach: taking a disability-inclusive mindset in all product designs to strive to deliver a better user experience for all.

Consistent with this philosophy, Azure Sentinel already includes accessibility features that conform to the Web Content Accessibility Guidelines (WCAG), among others. We are now taking this commitment a step further by adding another significant useability enhancement delivered through responsive design. Responsive design is a software development approach that optimizes an application’s user interface to adapt to various screen sizes, ranging from small, medium, to large glass. It allows developers to make efficient use of screen space, leverage specific features on a particular device, and optimize for various forms of input with the goal of improving user experience regardless of the choice of form factor. Beyond ease of use, digital accessibility can have far-reaching benefits in broadening opportunities for people of all abilities. To learn more about the role Microsoft is playing, read the blog Doubling down on accessibility: Microsoft’s next steps to expand accessibility in technology, the workforce and workplace.

Responsive design benefits in Azure Sentinel

Without responsive design, security operations center (SOC) analysts trying to use Azure Sentinel would experience difficulty when trying to navigate around the interface, especially if they are using a mobile device. For example, they would need to scroll to the right side in order to visualize pages with large amounts of text, increasing the friction they experience while trying to get their work done. With Azure Sentinel incorporating responsive design in the user interface, users can now expect an enriched experience in the following key areas:

Mobile access

Responsive design now enhances the usability of the Azure Sentinel portal from any device, including browsers on mobile phones. This now greatly improves the convenience of using the products and facilitates the mobility of the experience, allowing users to access the portal from light-weight devices that the users typically carry with them. When it comes to incident response, time is of the essence—the ability to respond from anywhere from a portable device is of great benefit. Below is a screenshot of an incident in Azure Sentinel opened from a mobile phone.

Azure Sentinel incident opened on a mobile device.

Figure 1: Azure Sentinel incident opened on a mobile device.

Enhanced zoom

It is now possible to zoom in to up to 400 percent without distorting user interface elements. This capability makes it possible to move away from the constraints of fixed-width designs to one that adjusts screen elements without distorting them even when a user zooms to such high percentages. As a result, the capability significantly improves the accessibility of the user interface to users with low vision or even to anyone who prefers to read larger text. For users with limited dexterity, the ability to enlarge text makes user interface elements larger, making selections easier.

Azure Sentinel Analytics blade at 400 percent zoom.

Figure 2: Azure Sentinel Analytics blade at 400 percent zoom at 1920×1080 display resolution.

Content reflow

The ability to accommodate different viewport sizes across devices of varying sizes without requiring the user to perform multiple scrolling operations is of significant benefit to anyone with accessibility needs and is a desirable user experience for any other user. With content reflow, the content automatically adjusts to fit the screen size, eliminating the need for horizontal scrolling to view content as depicted below:

Example of how text reflows from a large to small glass device and vice versa.

Figure 3: Example of how text reflows from a large to small glass device and vice versa.

Linear order

Linear order is important for structure as it maintains predictability when navigating through content (like the appearance of columns in the source order determines how screen readers or Windows narrator reads out the content). With reflow, the order of item presentation in the user interface is preserved, which makes for a consistent and accessible experience. For example, users typically expect the flow to be from left to right, top to bottom as depicted in the image below.

Image depicting right to left and up to down order on mobile screen view.

Figure 4. Example of the linear order for mobile screen view.

One billion. This is the number of people with disabilities across the world. Designing software or hardware with this population in mind pushes the limits of creativity to new boundaries, resulting in improved products and user experiences for all. Additionally, it increases the chances for people with disabilities to be gainfully employed with jobs that have been enabled by accessible technology. By proactively building accessibility into product designs right at the onset, we at Microsoft make technology adapt to user preferences as opposed to the other way round. We are excited that the new reflow-powered features in Azure Sentinel will make the product more usable and the experience more portable for our customers. Log in to your Azure Sentinel portal today from a device of any size and respond to incidents from the convenience of your favorite device.

Learn more

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.

Special thanks to Ishan Soni for his input and Menny Mezamar-Tov and the rest of the accessibility engineering team for building the reflow capability into Azure Sentinel.

The post Accessibility and usability for all in Azure Sentinel appeared first on Microsoft Security Blog.

Optimize security with Azure Firewall solution for Azure Sentinel

June 8th, 2021 No comments

Security is a constant balance between proactive and reactive defenses. They are both equally important, and neither can be neglected. Effectively protecting your organization means constantly optimizing both prevention and detection.

That’s why we’re excited to announce a seamless integration between Azure Firewall and Azure Sentinel. Now, you can get both detection and prevention in the form of an easy-to-deploy Azure Firewall solution for Azure Sentinel.

Combining prevention and detection allows you to ensure that you both prevent sophisticated threats when you can, while also maintaining an “assume breach mentality” to detect and quickly respond to cyberattacks.

Azure Sentinel and Azure Firewall: Better together

The seamless integration of Azure Firewall and Azure Sentinel enables security operations with three key capabilities:

  1. Monitoring and visualizing Azure Firewall activities.
  2. Detecting threats and leveraging AI-assisted investigation capabilities.
  3. Automating response and correlation to other sources.

The whole experience is packaged as a solution in the Azure Sentinel marketplace, which means it can be deployed in just a few clicks.

How do you deploy and enable the Azure Firewall solution for Azure Sentinel?

Deploying the solution is simple. You can find it in the “Solutions” blade in your Azure Sentinel workspace, called the “Azure Firewall Solution for Azure Sentinel.”

The Azure Firewall solution as displayed in Azure Sentinel portal UI in the solution section.

Figure 1: Azure Sentinel solutions preview.

Once you open the Azure Firewall solution, simply hit the “create” button, follow all the steps in the wizard, pass validation, and create the solution. With just a few clicks, all content—including connectors, detections, workbooks, and playbooks that we’ll cover below—will be deployed in your Azure Sentinel workspace.

Monitoring and visualizing Azure Firewall activities

The Azure Firewall workbook allows you to visualize Azure Firewall events. With this workbook, you can:

  • Learn about your application and network rules.
  • See statistics for firewall activities across URLs, ports, and addresses.
  • Filter by firewall and resource group.
  • Dynamically filter per category with easy-to-read data sets when investigating an issue in the logs.

The workbook provides a single dashboard for ongoing monitoring of your firewall activity. When it comes to threat detection, investigation, and response, the Azure Firewall solution also provides built-in detection and hunting capabilities.

The Azure Firewall workbook overview screen, which is part of the Azure Firewall solution for Azure Sentinel.

Figure 2. Azure Firewall workbook.

Detecting threats and leveraging AI-assisted investigation capabilities

Built-in Threat Detection—analytics

The solution’s detection rules provide Azure Sentinel a powerful method for analyzing Azure Firewall signals to detect traffic representing malicious activity patterns traversing through the network. This allows rapid response and remediation of the threats.

The attack stages an adversary will pursue within the firewall solution are segmented based on the MITRE ATT&CK framework. The MITRE framework is a series of steps that trace stages of a cyberattack from the early reconnaissance stages to the exfiltration of data. The framework helps defenders understand and combat ransomware, security breaches, and advanced attacks.

The solution includes detections for common scenarios an adversary might use as part of the attack—Spanning from the discovery stage (gaining knowledge about the system and internal network) through the command-and-control (C2) stage (communicating with compromised systems to control them) to the exfiltration stage (adversary trying to steal data from the organization).

Detection rule What does it do? What does it indicate?
Port scan Identifies a source IP scanning multiple open ports on the Azure Firewall. Malicious scanning of ports by an attacker, trying to reveal open ports in the organization that can be compromised for initial access.
Port sweep Identifies a source IP scanning the same open ports on the Azure Firewall different IPs. Malicious scanning of a port by an attacker trying to reveal IPs with specific vulnerable ports open in the organization.
Abnormal deny rate for source IP Identifies an abnormal deny rate for a specific source IP to a destination IP based on machine learning done during a configured period. Potential exfiltration, initial access, or C2, where an attacker tries to exploit the same vulnerability on machines in the organization but is being blocked by the Azure Firewall rules.
Abnormal Port to protocol Identifies communication for a well-known protocol over a non-standard port based on machine learning done during an activity period. Malicious communication (C2) or exfiltration by attackers trying to communicate over known ports (SSH, HTTP) but don’t use the known protocol headers that match the port number.
Multiple sources affected by the same TI destination Identifies multiple machines that are trying to reach out to the same destination blocked by threat intelligence (TI) in the Azure Firewall. An attack on the organization by the same attack group trying to exfiltrate data from the organization.

The Azure Firewall solution detections as they appear in the Azure Sentinel detection section after installing the solution.

Figure 3. Azure Firewall threat detections in Sentinel.

Hunting queries

Hunting queries are a tool for the security researcher to look for threats in the network of an organization, either after an incident has occurred or proactively to discover new or unknown attacks. To do this, security researchers will look at several indicators of compromise (IOCs). The built-in Azure Sentinel hunting queries in the Azure Firewall solution give security researchers the tools they need to find high-impact activities from the firewall logs. Several examples include:

Hunting query What does it do? What is it based on? What does it indicate?
First time a source IP connects to destination port Helps to identify a common indication of an attack (IOA) when a new host or IP tries to communicate with a destination using a specific port. Based on learning the regular traffic during a specified period.
First time source IP connects to a destination Helps to identify an IOA when malicious communication is done for the first time from machines that never accessed the destination before. Based on learning the regular traffic during a specified period.
Source IP abnormally connects to multiple destinations Identifies a source IP that abnormally connects to multiple destinations. Indicates initial access attempts by attackers trying to jump between different machines in the organization, exploiting lateral movement path or the same vulnerability on different machines to find vulnerable machines to access.
Uncommon port for the organization Identifies abnormal ports used in the organization network. An attacker can bypass monitored ports and send data through uncommon ports. This allows the attackers to evade detection from routine detection systems.
Uncommon port connection to destination IP Identifies abnormal ports used by machines to connect to a destination IP. An attacker can bypass monitored ports and send data through uncommon ports. This can also indicate an exfiltration attack from machines in the organization by using a port that has never been used on the machine for communication.

Automating response and correlation to other sources

Lastly, the Azure Firewall also includes Azure Sentinel playbooks, which enable you to automate response to threats. For example, if the firewall logs an event where a particular device on the network is trying to communicate with the internet via HTTP protocol over a non-standard TCP port, this action will trigger a detection in Azure Sentinel. The playbook will automate a notification to the security operations team via Microsoft Teams, and the security analysts can block the source IP of the device with a single click—preventing it from accessing the internet until an investigation can be completed. Playbooks allow this process to be much more efficient and streamlined.

An example of the Azure Firewall automation playbook, which is part of the solution, as it would appear once opening the playbook in Sentinel.

Figure 4. Playbook automation configuration.

Seeing the integrated solution in action: Seamless hunting with pre-configured Azure Firewall hunting queries

Let’s look at what the fully integrated solution looks like in a real-world scenario.

The attack and initial prevention by Azure Firewall

A sales representative in the company has accidentally opened a phishing email and opened a PDF file containing malware. The malware immediately tried to connect to a malicious website but was blocked by the Azure Firewall, which detected the domain due to the Microsoft threat intelligence feed it consumes.

The security analyst response based on the Azure Firewall solution for Azure Sentinel

The connection attempt triggered a detection in Azure Sentinel and started the playbook automation process to notify the security operations team via a Teams channel, where, with a click of a button, the analyst was able to block the computer from communicating with the internet. The security operations team then notified the IT department which removed the malware from the sales representative’s computer. However, taking the proactive approach and looking deeper, the security researcher leveraged the Azure Firewall hunting queries and ran the “Source IP abnormally connects to multiple destinations” query. This reveals that the malware on the infected computer tried to communicate with several other devices on the broader network and tried to access several of them. One of those access attempts succeeded, as there was no proper network segmentation to prevent the lateral movement in the network, and the new device had a known vulnerability the malware exploited to infect it.

The result

The security researcher removed the malware from that new device, completed mitigating the attack, and discovered a network weakness in the process.

Conclusion

Integrating threat prevention and threat detection is key to properly securing your organization and enabling your security operations team to monitor and respond to threats.

Enabling the Azure Firewall solution on your Azure Sentinel workspace is just a few clicks away. Start now.

Learn more

In addition to the Azure Firewall solution, we announced several new Azure Sentinel innovations at the RSA Conference 2021. Learn more about these announcements, including new integrations, machine learning features, collaboration capabilities, and more on the Azure Sentinel announcement blog.

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 Optimize security with Azure Firewall solution for Azure Sentinel appeared first on Microsoft Security.

Optimize security with Azure Firewall solution for Azure Sentinel

June 8th, 2021 No comments

Security is a constant balance between proactive and reactive defenses. They are both equally important, and neither can be neglected. Effectively protecting your organization means constantly optimizing both prevention and detection.

That’s why we’re excited to announce a seamless integration between Azure Firewall and Azure Sentinel. Now, you can get both detection and prevention in the form of an easy-to-deploy Azure Firewall solution for Azure Sentinel.

Combining prevention and detection allows you to ensure that you both prevent sophisticated threats when you can, while also maintaining an “assume breach mentality” to detect and quickly respond to cyberattacks.

Azure Sentinel and Azure Firewall: Better together

The seamless integration of Azure Firewall and Azure Sentinel enables security operations with three key capabilities:

  1. Monitoring and visualizing Azure Firewall activities.
  2. Detecting threats and leveraging AI-assisted investigation capabilities.
  3. Automating response and correlation to other sources.

The whole experience is packaged as a solution in the Azure Sentinel marketplace, which means it can be deployed in just a few clicks.

How do you deploy and enable the Azure Firewall solution for Azure Sentinel?

Deploying the solution is simple. You can find it in the “Solutions” blade in your Azure Sentinel workspace, called the “Azure Firewall Solution for Azure Sentinel.”

The Azure Firewall solution as displayed in Azure Sentinel portal UI in the solution section.

Figure 1: Azure Sentinel solutions preview.

Once you open the Azure Firewall solution, simply hit the “create” button, follow all the steps in the wizard, pass validation, and create the solution. With just a few clicks, all content—including connectors, detections, workbooks, and playbooks that we’ll cover below—will be deployed in your Azure Sentinel workspace.

Monitoring and visualizing Azure Firewall activities

The Azure Firewall workbook allows you to visualize Azure Firewall events. With this workbook, you can:

  • Learn about your application and network rules.
  • See statistics for firewall activities across URLs, ports, and addresses.
  • Filter by firewall and resource group.
  • Dynamically filter per category with easy-to-read data sets when investigating an issue in the logs.

The workbook provides a single dashboard for ongoing monitoring of your firewall activity. When it comes to threat detection, investigation, and response, the Azure Firewall solution also provides built-in detection and hunting capabilities.

The Azure Firewall workbook overview screen, which is part of the Azure Firewall solution for Azure Sentinel.

Figure 2. Azure Firewall workbook.

Detecting threats and leveraging AI-assisted investigation capabilities

Built-in Threat Detection—analytics

The solution’s detection rules provide Azure Sentinel a powerful method for analyzing Azure Firewall signals to detect traffic representing malicious activity patterns traversing through the network. This allows rapid response and remediation of the threats.

The attack stages an adversary will pursue within the firewall solution are segmented based on the MITRE ATT&CK framework. The MITRE framework is a series of steps that trace stages of a cyberattack from the early reconnaissance stages to the exfiltration of data. The framework helps defenders understand and combat ransomware, security breaches, and advanced attacks.

The solution includes detections for common scenarios an adversary might use as part of the attack—Spanning from the discovery stage (gaining knowledge about the system and internal network) through the command-and-control (C2) stage (communicating with compromised systems to control them) to the exfiltration stage (adversary trying to steal data from the organization).

Detection rule What does it do? What does it indicate?
Port scan Identifies a source IP scanning multiple open ports on the Azure Firewall. Malicious scanning of ports by an attacker, trying to reveal open ports in the organization that can be compromised for initial access.
Port sweep Identifies a source IP scanning the same open ports on the Azure Firewall different IPs. Malicious scanning of a port by an attacker trying to reveal IPs with specific vulnerable ports open in the organization.
Abnormal deny rate for source IP Identifies an abnormal deny rate for a specific source IP to a destination IP based on machine learning done during a configured period. Potential exfiltration, initial access, or C2, where an attacker tries to exploit the same vulnerability on machines in the organization but is being blocked by the Azure Firewall rules.
Abnormal Port to protocol Identifies communication for a well-known protocol over a non-standard port based on machine learning done during an activity period. Malicious communication (C2) or exfiltration by attackers trying to communicate over known ports (SSH, HTTP) but don’t use the known protocol headers that match the port number.
Multiple sources affected by the same TI destination Identifies multiple machines that are trying to reach out to the same destination blocked by threat intelligence (TI) in the Azure Firewall. An attack on the organization by the same attack group trying to exfiltrate data from the organization.

The Azure Firewall solution detections as they appear in the Azure Sentinel detection section after installing the solution.

Figure 3. Azure Firewall threat detections in Sentinel.

Hunting queries

Hunting queries are a tool for the security researcher to look for threats in the network of an organization, either after an incident has occurred or proactively to discover new or unknown attacks. To do this, security researchers will look at several indicators of compromise (IOCs). The built-in Azure Sentinel hunting queries in the Azure Firewall solution give security researchers the tools they need to find high-impact activities from the firewall logs. Several examples include:

Hunting query What does it do? What is it based on? What does it indicate?
First time a source IP connects to destination port Helps to identify a common indication of an attack (IOA) when a new host or IP tries to communicate with a destination using a specific port. Based on learning the regular traffic during a specified period.
First time source IP connects to a destination Helps to identify an IOA when malicious communication is done for the first time from machines that never accessed the destination before. Based on learning the regular traffic during a specified period.
Source IP abnormally connects to multiple destinations Identifies a source IP that abnormally connects to multiple destinations. Indicates initial access attempts by attackers trying to jump between different machines in the organization, exploiting lateral movement path or the same vulnerability on different machines to find vulnerable machines to access.
Uncommon port for the organization Identifies abnormal ports used in the organization network. An attacker can bypass monitored ports and send data through uncommon ports. This allows the attackers to evade detection from routine detection systems.
Uncommon port connection to destination IP Identifies abnormal ports used by machines to connect to a destination IP. An attacker can bypass monitored ports and send data through uncommon ports. This can also indicate an exfiltration attack from machines in the organization by using a port that has never been used on the machine for communication.

Automating response and correlation to other sources

Lastly, the Azure Firewall also includes Azure Sentinel playbooks, which enable you to automate response to threats. For example, if the firewall logs an event where a particular device on the network is trying to communicate with the internet via HTTP protocol over a non-standard TCP port, this action will trigger a detection in Azure Sentinel. The playbook will automate a notification to the security operations team via Microsoft Teams, and the security analysts can block the source IP of the device with a single click—preventing it from accessing the internet until an investigation can be completed. Playbooks allow this process to be much more efficient and streamlined.

An example of the Azure Firewall automation playbook, which is part of the solution, as it would appear once opening the playbook in Sentinel.

Figure 4. Playbook automation configuration.

Seeing the integrated solution in action: Seamless hunting with pre-configured Azure Firewall hunting queries

Let’s look at what the fully integrated solution looks like in a real-world scenario.

The attack and initial prevention by Azure Firewall

A sales representative in the company has accidentally opened a phishing email and opened a PDF file containing malware. The malware immediately tried to connect to a malicious website but was blocked by the Azure Firewall, which detected the domain due to the Microsoft threat intelligence feed it consumes.

The security analyst response based on the Azure Firewall solution for Azure Sentinel

The connection attempt triggered a detection in Azure Sentinel and started the playbook automation process to notify the security operations team via a Teams channel, where, with a click of a button, the analyst was able to block the computer from communicating with the internet. The security operations team then notified the IT department which removed the malware from the sales representative’s computer. However, taking the proactive approach and looking deeper, the security researcher leveraged the Azure Firewall hunting queries and ran the “Source IP abnormally connects to multiple destinations” query. This reveals that the malware on the infected computer tried to communicate with several other devices on the broader network and tried to access several of them. One of those access attempts succeeded, as there was no proper network segmentation to prevent the lateral movement in the network, and the new device had a known vulnerability the malware exploited to infect it.

The result

The security researcher removed the malware from that new device, completed mitigating the attack, and discovered a network weakness in the process.

Conclusion

Integrating threat prevention and threat detection is key to properly securing your organization and enabling your security operations team to monitor and respond to threats.

Enabling the Azure Firewall solution on your Azure Sentinel workspace is just a few clicks away. Start now.

Learn more

In addition to the Azure Firewall solution, we announced several new Azure Sentinel innovations at the RSA Conference 2021. Learn more about these announcements, including new integrations, machine learning features, collaboration capabilities, and more on the Azure Sentinel announcement blog.

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 Optimize security with Azure Firewall solution for Azure Sentinel appeared first on Microsoft Security Blog.

SimuLand: Understand adversary tradecraft and improve detection strategies

May 20th, 2021 No comments

At Microsoft, we continuously collaborate with customers and the InfoSec community to learn more about the latest adversary tradecraft so that we can improve our detection strategies across all our security services. Even though those detections are already built into our products, and protecting customers today, we believe it is important for security researchers to go beyond alerts and detections to understand the underlying attack behaviors and technical implementation of adversary techniques. This also empowers others in the InfoSec community to better respond to investigations of related attacks. To help the broader security community with these efforts, we are releasing SimuLand.

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.

Map of threat research methodologies.

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.

Protecting SAP applications with the new Azure Sentinel SAP threat monitoring solution

May 19th, 2021 No comments

As one of the leading solution providers for applications that manage business processes, SAP is the custodian for massive amounts of sensitive data in many of the biggest organizations in the world.

Since these applications are business-critical, an SAP security breach can be catastrophic. Yet, protecting SAP applications is uniquely challenging. These systems are growing in complexity as organizations expand them beyond base capabilities. They are vulnerable not only to outside attacks, but also insider threats. What’s more, their complex nature means that threats can emerge across multiple modules, making cross-correlation especially important.

It has been traditionally very difficult for security operations (SecOps) teams to effectively monitor them due to the unique nature of the SAP ecosystems and the expertise they require. We set out to meet this challenge with the new SAP threat monitoring solution for Azure Sentinel. Now in public preview, the solution provides continuous threat detection and analytics for SAP systems deployed on Azure, in other clouds, or on-premises. Now, SecOps teams can use Azure Sentinel’s visibility, threat detection, and investigation tools to protect their SAP systems and cross-correlate across their entire organization.

Effective SAP threat monitoring

An effective approach to SAP threat monitoring has several key requirements:

  1. Multi-layered coverage: An SAP threat monitoring solution needs to cover both the infrastructure layer (virtual machine, storage, and network) as well as the business and applicative layers since threats traverse every layer of the SAP system.
  2. Rich insight into SAP applicative and transactional data: SAP systems produce viable security data in the form of change documents, audit logging, job execution, data transformation (table data), and more. For a complete picture of potential threats, you need visibility into all this activity.
  3. Correlation across enterprise data sources: SAP systems are complex, and indicators of compromise often aren’t straightforward. To reduce noise, it’s imperative to cross-correlate across additional data sources such as network, storage, or identity data, as well as across other entities, such as systems and users.
  4. Flexible deployment: SAP NetWeaver systems can be deployed on-premises, in the cloud, or hybrid deployments. Any effective SAP monitoring solution needs to offer deployment flexibility and provide visibility into any of these deployment configurations—especially since cloud transformation is often a long, multi-stage process, and organizations may find their SAP deployment method changing over time.
  5. Threat detections specific to SAP: SAP systems are unique environments facing unique threats. An effective monitoring approach needs to include threat detections and analytics tailored to SAP-specific use cases and threats.
  6. Customizability: On the flip side, SAP ABAP platforms inclusive of S/4HANA are also highly custom in nature, which means that you can’t rely solely on out-of-the-box detections. The SAP threat monitoring approach needs to be open to modification and include the ability to build or import your own security content, so you can tailor detection to your specific environment.

Our approach: The SAP threat monitoring solution for Azure Sentinel

We kept these requirements top of mind when developing our approach to SAP threat monitoring. The Azure Sentinel SAP threat monitoring solution can be deployed in one simple package that includes all components. The solution includes:

  • A Rich NetWeaver data connector: The SAP collector is delivered as a Docker container image that can be deployed anywhere in the network and integrate into NetWeaver capable systems. The data connector collects over 10 different log files with SAP NetWeaver enabled systems that allows monitoring business and application layer-related risks within SAP systems. You can view the full list of available log sources in the documentation.
  • SAP underlying Infrastructure data connectors: Existing Azure Sentinel data connectors, such as those for virtual machines, networking, and Azure Active Directory, monitor the underlying infrastructure.
  • Built-in security content: Out-of-the-box detections catch important SAP threats like system configuration changes, execution of sensitive function modules, and suspicious activity by privileged users. Plus, a workbook helps SecOps teams visualize the security health of their SAP systems.

Out-of-the-box detections included in the Azure Sentinel SAP threat monitoring solution.

Figure 1: Out-of-the-box detections included in the Azure Sentinel SAP threat monitoring solution.

An SAP workbook in Azure Sentinel.

Figure 2: SAP workbook helps analyze different security audit log events by severity, in order to keep track of the different events on the SAP ABAP system.

Visualizing and tracking authentication events using a built-in workbook.

Figure 3: Visualizing and tracking authentication events using a built-in workbook.

  • A rich set of configurations is also included in the form of watchlists. These watchlists reduce noise by allowing you to describe your specific SAP environment and the risks you’re most concerned about. For example, specify whether a certain system is a production or test system, and identify any specific SAP transactions that should be especially carefully monitored.

Use case: Monitoring for abuse of privileges with Azure Sentinel

What does this look like in action? One of the most common SAP security risks is the potential misuse of privileges. With the right privileges, SAP users can execute functions and even debug ABAP code running on these systems, which—while necessary—also by nature opens the system up to significant risk. For example, an SAP user with developer privileges could exploit those privileges to view sensitive human resources or financial data by executing a function module to gain elevated access privileges.

Azure Sentinel gives you the ability to quickly detect these threats without drowning in noise. You can monitor function modules executed via SE37, while also targeting your detections by defining a granular set of your most sensitive modules. You can also specify that these detections should only apply to your production systems since these behaviors can be common and harmless in developer or sandbox systems.

The pre-configured functions and detections can monitor for these threats from day one, while still providing the flexibility you need to customize your implementation.

Another common scenario is the use of break-glass users such as DDIC/SAP. While those users are frequently enabled for valid reasons, the usage of these privileges still needs to be very carefully monitored due to the high privileges of the default “superman” users. In Azure Sentinel, you can monitor for these users and use automation to help you manage these risks. For example, monitor for system access from these users, and when it is detected, automatically call a playbook that will send a Teams message to confirm that SAP basis permissions were given to perform the operation.

Learn more

Azure Sentinel threat monitoring for SAP capabilities enables you to protect critical SAP systems more efficiently and effectively and extends Azure Sentinel’s cloud-native security analytics and AI capabilities to the world of SAP. Learn more about the SAP threat monitoring solution in documentation, or join us live on May 26, 2021, at 8 AM Pacific Time to learn more about the SAP threat monitoring solution live in our Azure Sentinel webinar.

In addition to threat monitoring for SAP, we announced several new Azure Sentinel innovations at the RSA Conference 2021. Learn more about these announcements, including new integrations, ML features, collaboration capabilities, and more, on the Azure Sentinel announcement blog.

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 Protecting SAP applications with the new Azure Sentinel SAP threat monitoring solution appeared first on Microsoft Security.

Threat matrix for storage

April 8th, 2021 No comments

The move to cloud is happening faster than ever before and organizations are increasing their dependency on cloud storage services. In fact, Microsoft Azure Storage services are one of the most popular services in the cloud. Companies need effective threat protection and mitigation strategies and tools in place as they manage their access to cloud storage. For example, Azure Defender treats data-centric services as part of the security perimeter and provides prioritization and mitigation of threats for Storage. To help you build a framework, we examined the attack surface of storage services. In this blog, we outline potential risks that you should be aware of when deploying, configuring, or monitoring your storage environment.

Methodology

Within cloud storage services, we witness users sharing various file types, such as Microsoft Office and Adobe files, and attackers taking advantage of this to deliver malware through email. Moreover, use cases of cloud storage go beyond internal interfaces, with business logic being shared with third parties. Therefore, the Azure Defender for Storage security team has mapped the attack surface undertaken by leveraging Storage service.

This post reflects our findings based on the MITRE ATT&CK® framework, which is a knowledge base for tactics and techniques employed in cyberattacks. MITRE matrices have become an industry standard and are embraced by organizations aiming to understand potential attack vectors in their environments and to ensure they have adequate detections and mitigations in place.

While analyzing the security landscape of storage, and applying the same methodology we defined for Kubernetes, we noticed the resemblance and differences across techniques. Whilst Kubernetes underlies an operating system, its threat matrix is structured like MITRE matrices for Linux or Windows. Aiming to address the entire attack surface for storage, from data loss prevention (DLP) and sensitive content exposure to uncovering malicious content distribution over a file share Server Message Block (SMB), we adjusted the enterprise tactics to fit a data service.

The threat matrix stages

We expect this matrix to dynamically evolve as more threats are discovered and exploited, and techniques can also be deprecated as cloud infrastructures constantly progress towards securing their services. Below we will address each of the threat matrix stages in more detail.

The threat matrix for cloud-based Storage services. The matrix consists of the various attack techniques that pose threats to Storage resources.

Figure 1:  Threat matrix for Storage.

Stage 1: Reconnaissance

Adversaries are trying to gather information they can use to plan future operations. Reconnaissance consists of techniques that involve actively or passively gathering information that can be used to support targeting.

  • Storage account discovery: Adversaries may enumerate storage account names (or leverage an existing enumeration process) to find an active storage account. Examples of such methods can vary from search dorks (site:*.blob.core.windows.net) to brute-force account creations. Adversaries can also employ crawler results or leverage public toolkits, such as Microburst and BlobHunter.
  • Public containers discovery: Adversaries may enumerate container names (or leverage an existing enumeration process) for an already known storage account. Adversaries can employ crawler results or leverage public toolkits, such as Microburst and BlobHunter.

Stage 2: Initial access

Adversaries are trying to get into your network. Initial access consists of techniques that use various entry vectors to gain their initial foothold within a network. Footholds gained through initial access may allow for continued access, like valid accounts and use of external remote services, or may be limited use due to changing passwords or keys.

  • Valid SAS URI: A shared access signature (SAS) is a uniform resource identifier (URI) that grants restricted access rights to storage resources. Adversaries may steal a SAS URI using one of the Credential Access techniques or capture a SAS URI earlier in their reconnaissance process through social engineering to gain initial access. Adversaries may also leverage identity and access management (IAM) privileges to generate a valid SAS offline based on a stolen storage account key.
  • Valid access key: Adversaries may steal an access key using one of Credential Access techniques or capture one earlier in their reconnaissance process through social engineering to gain initial access. Adversaries may leverage keys left in source code or configuration files. Sophisticated attackers may also obtain keys from hosts (virtual machines) that have mounted File Share on their system (SMB).
  • Valid Azure Active Directory (Azure AD) principal: Adversaries may steal account credentials using one of the Credential Access techniques or capture an account earlier in their reconnaissance process through social engineering to gain initial access. An authorized Azure AD account/token can result in full control of storage account resources.
  • Use of public access: Adversaries may leverage publicly exposed storage accounts to list containers/blobs and their properties, information that can be beneficial as the attack advances. Adversaries may employ application programming interfaces (APIs), such as the List Blobs This technique is oftentimes reported as the exploitation vector used in targeted campaigns.

Stage 3: Persistence

Adversaries are trying to maintain their foothold. Persistence consists of techniques that adversaries use to keep access to systems across changed credentials and other interruptions that could cut off their access. Techniques used for persistence include any access, action, or configuration changes that let them maintain their foothold on systems.

  • Firewalls and Virtual Networks configuration changes: Storage services offer a set of built-in security features. Administrators can leverage these capabilities to restrict access to storage resources. Restriction rules can operate at the IP level. When network rules are configured, only requests originated from authorized subnets will be served. Adversaries may insert additional rules to ensure persistent access.
  • Role-based access control (RBAC) changes: Storage services offer built-in RBAC roles that encompass sets of permissions used to access different data types. Definition of custom roles is also supported. Upon assignment of an RBAC role to an identity object (like Azure AD security principal) the storage provider grants access to that security principal. Adversaries may leverage the RBAC mechanism to ensure persistent access to their owned identity objects.

Stage 4: Defense evasion

Adversaries are trying to avoid being detected. Defense evasion consists of techniques that adversaries use to avoid detection throughout their compromise. Techniques used for defense evasion include abuse trusted processes to hide and masquerade their malicious intents. Other tactics’ techniques are cross-listed here and include the added benefit of subverting defenses.

  • Firewalls and Virtual Networks configuration changes: Storage services offer a set of built-in security features. Administrators can leverage these capabilities to restrict access to storage resources. Restriction rules can operate at the IP level. When network rules are configured, only requests originated from authorized subnets will be served. Adversaries may insert additional rules to masquerade and/or legitimatize their data exfiltration channel.
  • RBAC changes: Storage services offer built-in RBAC roles that encompass sets of permissions used to access different data types. Definition of custom roles is also supported. Upon assignment of an RBAC role to an identity object (like Azure AD security principal) the storage provider grants access to that security principal. Adversaries may leverage the RBAC mechanism to disguise their activities as typical within a compromised environment.
  • Storage data clone: Storage services offer different types of cloning or backup data stored on them. Adversaries may abuse these built-in capabilities to steal sensitive documents, source code, credentials, and other business crucial information. This technique was employed as part of Capital One data theft.
  • Data transfer size limits: Adversaries may fragment stolen information and exfiltrate it on different size chunks to avoid being detected by triggering potentially predefined transfer threshold alerts.
  • Automated exfiltration: Adversaries may exploit legitimate automation processes, predefined by the compromised organization, with the goal of having their logging traces blend in normally within the company’s typical activities. Assimilating or disguising malicious intentions will keep adversary actions, such as data theft, stealthier.
  • Access control list (ACL) modification: Adversaries may adjust ACL configuration at the granularity of specific a blob or container, to secure a channel to exfiltrate stolen data. These ACL modifications occur at the control-plane level, which is oftentimes overlooked. By narrowing existing exposure restrictions, adversaries may infiltrate an organization’s internal and sensitive resources.

Stage 5: Credential Access

Credential Access consists of techniques for stealing credentials like account names and passwords. Techniques used to get credentials include keylogging or credential dumping. Using legitimate credentials can give adversaries access to systems, make them harder to detect, and provide the opportunity to create more accounts to help achieve their goals.

  • Access query key: Adversaries may leverage subscription/account-level access to gather storage account keys and use these keys to authenticate at the resource level. This technique exhibits cloud resource pivoting in combination with control management and data planes. Adversaries can query management APIs to fetch primary and secondary storage account keys.
  • Access Cloud Shell profiles: Cloud Shell is an interactive, authenticated, browser-accessible shell for managing cloud resources. It provides the flexibility of shell experience, either Bash or PowerShell. To support the Cloud Shell promise of being accessible from everywhere, Cloud Shell profiles and session history are saved on storage account. Adversaries may leverage the legitimate use of Cloud Shell to impersonate account owners and potentially obtain additional secrets logged as part of session history.

Stage 6: Discovery

Adversaries are trying to figure out your environment. Discovery consists of techniques adversaries may use to gain knowledge about the system. These techniques help adversaries observe the environment and orient themselves before deciding how to act. Tools witnesses, at the reconnaissance phase, are often used toward this post-compromise information-gathering objective.

  • Storage service discovery: Adversaries may leverage subscription/account-level access to discover storage properties and stored resources. Tools witnessed, at the reconnaissance phase, are oftentimes used toward this post-compromise information-gathering objective, now with authorization to access storage APIs, such as the List Blobs call.

Stage 7: Lateral movement

Adversaries are trying to move through your environment. Lateral movement consists of techniques that adversaries use to enter and control remote systems on a network. Reaching their objective often involves pivoting through multiple systems and accounts to gain access. Adversaries may install their own remote access tools (RAT) to accomplish lateral movement or use legitimate credentials with native network and operating system tools, which may be stealthier.

  • Malicious content upload: Adversaries may use storage services to store a malicious program or toolset that will be executed at later times during their operation. In addition, adversaries may exploit the trust between users and their organization’s Storage services by storing phishing content. Furthermore, storage services can be leveraged to park gathered intelligence that will be exfiltrated when terms suit the actor group.
  • Malware distribution: Storage services offer different types of mechanisms to support auto-synchronization between various resources and the storage account. Adversaries may leverage access to the storage account to upload malware and benefit from the auto-sync built-in capabilities to have their payload being populated and potentially weaponize multiple systems.
  • Trigger cross-service interaction: Adversaries may manipulate storage services to trigger a compute service (like Azure Functions/AWS Lambda triggers), where an attacker already has a foothold on a storage container and can inject a blob that will initiate a chain of a compute process. This may allow an attacker to infiltrate another resource and cause harm.
  • Data manipulation: Content stored on a storage service may be tainted by adding malicious programs, scripts, or exploit code to otherwise valid files. Upon execution by a legitimate user of tainted content, the malicious portion runs the adversary’s code on a remote system. Adversaries may use tainted shared content to move laterally.
  • Access Cloud Shell profiles: Cloud Shell is an interactive, authenticated, browser-accessible shell for managing cloud resources. It provides the flexibility of shell experience, either Bash or PowerShell. To support the Cloud Shell promise of being accessible from everywhere, Cloud Shell profiles and session history are saved on storage account. Adversaries may leverage the legitimate use of Cloud Shell to impersonate account owners and potentially obtain additional secrets logged as part of session history.

Stage 8: Exfiltration

Adversaries are trying to steal data. Exfiltration consists of techniques that adversaries may use to steal data from your network. Once they’ve collected data, adversaries often package it to avoid detection while removing it. This can include compression and encryption. Techniques for getting data out of a target network typically includes transferring it over their command-and-control channel or an alternative channel and may also include putting size limits on the transmission.

  • Storage data clone: Storage services offer different types of cloning or backup data stored on them. Adversaries may abuse these built-in capabilities to steal sensitive documents, source code, credentials, and other business crucial information. This technique has been employed as part of data theft previously.
  • Data transfer size limits: Adversaries may fragment stolen information and exfiltrate it on different size chunks to avoid being detected by triggering potentially predefined transfer threshold alerts.
  • Automated exfiltration: Adversaries may exploit legitimate automation processes, predefined by the compromised organization, with the goal of having their logging traces blend in normally within the company’s typical activities. Assimilating or disguising malicious intentions will keep adversary actions, such as data theft, stealthier.
  • ACL modification: Adversaries may adjust ACL configuration at the granularity of a specific blob or container, to secure a channel to exfiltrate stolen data. These ACL modifications occur at the control-plane level, which is oftentimes overlooked. By narrowing existing exposure restrictions, adversaries may infiltrate an organization’s internal and sensitive resources.

Stage 9: Impact

Adversaries are trying to manipulate, interrupt, or destroy your systems and data. Impact consists of techniques that adversaries use to disrupt availability or compromise integrity by manipulating business and operational processes. These techniques might be used by adversaries to follow through on their end goal or to provide cover for a confidentiality breach.

  • Data corruption: Adversaries may corrupt data stored on storage services to disrupt the availability of systems or other lines of business.
  • Data encryption for impact (ransomware): Adversaries may encrypt data stored on storage services to disrupt the availability of systems or other lines of business. Making resources inaccessible by encrypting files or blobs and withholding access to a decryption key. This may be done to extract monetary compensation from a victim in exchange for decryption or a decryption key (ransomware).

Get started today

Understanding the attack surface of data-focused services is the first step of building security solutions for these environments. The threat matrix for storage can help organizations identify gaps in their defenses. We encourage you to try Azure Defender for Storage and start protecting against potential threats targeting your blobs, containers, and file shares. Azure Defender for Storage should be enabled on storage accounts storing sensitive information. For a list of the Azure Defender for Storage alerts, see the reference table of alerts.

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 Threat matrix for storage appeared first on Microsoft Security.

Secure containerized environments with updated threat matrix for Kubernetes

March 23rd, 2021 No comments

Last April, we released the first version of the threat matrix for Kubernetes. It was the first attempt to systematically map the threat landscape of Kubernetes. As we described in the previous post, we chose to adapt the structure of MITRE ATT&CK® framework which, became almost an industry standard for describing threats.

Since the publication of the threat matrix last year, things have changed:

  • New threats were discovered as attackers targeted more and more Kubernetes workloads.
  • We were glad to see that the security community adopted the matrix and added more techniques.
  • As Kubernetes evolves, it becomes more secure by default and some techniques are no longer relevant.

Today, we are releasing the second version of the threat matrix for Kubernetes, which considers these changes. The updated matrix adds new techniques that were found by Microsoft researchers, as well as techniques that were suggested by the community. We also deprecate several techniques, which do not apply anymore to newer versions of Kubernetes. In this version, we also add a new tactic taken from MITRE ATT&CK®: collection.

The threat matrix to Kubernetes. The matrix consists of the various attacking techniques that target Kubernetes.

What has deprecated?

Kubernetes evolved and became more secure by default; techniques that appeared in last year’s matrix aren’t relevant to newer environments. Therefore, we decided to deprecate some of the techniques:

Exposed Kubernetes Dashboard

The Kubernetes dashboard’s usage has been in decline for a while now. Cloud-managed clusters, such as Microsoft’s AKS and Google’s GKE, deprecated this service and moved to a centralized interface in their portals. Moreover, the recent versions of the Kubernetes dashboard require authentication and it’s less likely to find exposed dashboards that do not require authentication. Consequently, we also removed the technique, “Access Kubernetes dashboard,” under lateral movement tactic. Older versions of Kubernetes, including newer clusters that have the dashboard manually installed, are still affected by this technique. The concept of this technique was generalized in the new technique: exposed sensitive interfaces (see below).

Access tiller endpoint­

As of version 3, Helm doesn’t use its server-side component, Tiller. This is a major improvement in the security of Helm. Currently, Helm operates (by default) on behalf of the user’s credentials as they appear in the kubeconfig file. Users of older versions of Helm are still affected by this technique.

New techniques for the threat matrix

1. Initial access

Exposed sensitive interfaces

Exposing a sensitive interface to the internet poses a security risk. Some popular frameworks were not intended to be exposed to the internet, and therefore don’t require authentication by default. Thus, exposing them to the internet allows unauthenticated access to a sensitive interface which might enable running code or deploying containers in the cluster by a malicious actor. Examples of such interfaces that were seen exploited include Apache NiFi, Kubeflow, Argo Workflows, Weave Scope, and the Kubernetes dashboard.

2. Execution

Sidecar injection

A Kubernetes Pod is a group of one or more containers with shared storage and network resources. Sidecar container is a term that is used to describe an additional container that resides alongside the main container. For example, service-mesh proxies are operating as sidecars in the applications’ pods. Attackers can run their code and hide their activity by injecting a sidecar container to a legitimate pod in the cluster instead of running their own separated pod in the cluster.

3. Persistence

Malicious admission controller

Admission controller is a Kubernetes component that intercepts, and possibly modifies, requests to the Kubernetes API server. There are two types of admissions controllers: validating and mutating controllers. As the name implies, a mutating admission controller can modify the intercepted request and change its properties. Kubernetes has a built-in generic admission controller named MutatingAdmissionWebhook. The behavior of this admission controller is determined by an admission webhook that the user deploys in the cluster. Attackers can use such webhooks for gaining persistence in the cluster. For example, attackers can intercept and modify the pod creation operations in the cluster and add their malicious container to every created pod.

4. Credential access

Access managed identity credential

Managed identities are identities that are managed by the cloud provider and can be allocated to cloud resources, such as virtual machines. Those identities are used to authenticate with cloud services. The identity’s secret is fully managed by the cloud provider, which eliminates the need to manage the credentials. Applications can obtain the identity’s token by accessing the Instance Metadata Service (IMDS). Attackers who get access to a Kubernetes pod can leverage their access to the IMDS endpoint to get the managed identity’s token. With a token, the attackers can access cloud resources.

Malicious admission controller

In addition to persistency, a malicious admission controller can be used to access credentials. One of the built-in admission controllers in Kubernetes is ValidatingAdmissionWebhook. Like MutatingAdmissionWebhook, this admission controller is also generic, and its behavior is determined by an admission webhook that is deployed in the cluster. Attackers can use this webhook to intercept the requests to the API server, record secrets, and other sensitive information.

5. Lateral movement

CoreDNS poisoning

CoreDNS is a modular Domain Name System (DNS) server written in Go, hosted by Cloud Native Computing Foundation (CNCF). CoreDNS is the main DNS service that is being used in Kubernetes. The configuration of CoreDNS can be modified by a file named corefile. In Kubernetes, this file is stored in a ConfigMap object, located at the kube-system namespace. If attackers have permissions to modify the ConfigMap, for example by using the container’s service account, they can change the behavior of the cluster’s DNS, poison it, and take the network identity of other services.

ARP poisoning and IP spoofing

Kubernetes has numerous network plugins (Container Network Interfaces or CNIs) that can be used in the cluster. Kubenet is the basic, and in many cases the default, network plugin. In this configuration, a bridge is created on each node (cbr0) to which the various pods are connected using veth pairs. The fact that cross-pod traffic is through a bridge, a level-2 component, means that performing ARP poisoning in the cluster is possible. Therefore, if attackers get access to a pod in the cluster, they can perform ARP poisoning, and spoof the traffic of other pods. By using this technique, attackers can perform several attacks at the network-level which can lead to lateral movements, such as DNS spoofing or stealing cloud identities of other pods (CVE-2021-1677).

6. Collection

In this update, we also add a new tactic to the threat matrix: collection. In Kubernetes, collection consists of techniques that are used by attackers to collect data from the cluster or through using the cluster.

Images from private registry

The images that are running in the cluster can be stored in a private registry. For pulling those images, the container runtime engine (such as Docker or containerd) needs to have valid credentials to those registries. If the registry is hosted by the cloud provider, in services like Azure Container Registry (ACR) or Amazon Elastic Container Registry (ECR), cloud credentials are used to authenticate to the registry. If attackers get access to the cluster, in some cases they can obtain access to the private registry and pull its images. For example, attackers can use the managed identity token as described in the “Access managed identity credential” technique. Similarly, in EKS, attackers can use the AmazonEC2ContainerRegistryReadOnly policy that is bound by default to the node’s IAM role.

Protect your containerized environments

Understanding the attack surface of containerized environments is the first step of building security solutions for these environments. The revised threat matrix for Kubernetes can help organizations identify the current gaps in their defenses’ coverage against the different threats that target Kubernetes.

We recommend that you start protecting your containerized environment with Azure Defender today. Learn more about Azure Defender’s support for container security.

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 Secure containerized environments with updated threat matrix for Kubernetes appeared first on Microsoft Security.

Azure LoLBins: Protecting against the dual use of virtual machine extensions

March 9th, 2021 No comments

Azure Defender for Resource Manager offers unique protection by automatically monitoring the resource management operations in your organization, whether they’re performed through the Azure portal, Azure REST APIs, Azure CLI, or other Azure programmatic clients. In this blog, we will look into the threats that are caused by “Living off the land Binaries” (LoLBins).

The term “Living off the land,” or LoL in short, is used to describe attackers leveraging built-in utilities to carry out attacks. LoLBins usually refer to pre-installed Windows or Linux binary tools that are normally used for legitimate purposes, but on compromised resources, can be leveraged by attackers. This tactic challenges defenders aiming to distinguish between the dual uses of these tools.

The usage of LoLBins is frequently seen, mostly combined with fileless attacks, where attacker payloads surreptitiously persist within the memory of compromised processes and perform a wide range of malicious activities. Together with the use of legitimate LoLBins, attackers’ activities are more likely to remain undetected.

Attackers are increasingly employing stealthier methods to avoid detection. Evidence for a variety of campaigns has been witnessed. Please find a detailed overview of how such an attack unfolds, along with recommendations on how to detect malicious LoLBins’ activities on Windows.

Azure LoLBins

The concept of LoLBins is not limited to traditional operation systems. In this post, we explore different types of Azure Compute virtual machine extensions, which are small applications that provide post-deployment configuration and automation tasks on Azure Virtual Machines. For example, if a virtual machine requires software installation, anti-virus protection, or to run a script inside of it, a virtual machine (VM) extension can be used.

Custom Script Extension downloads and executes scripts on Azure Virtual Machines, Anti-Malware extension for Windows warps different configuration types and applies them into Windows Defender, and VMAccess Extension manages administrative users, SSH keys and enables recovery features such as resetting the administrative password of a virtual machine (VM).

All these extensions serve thousands of administrators coming to orchestrate their Azure fleet. But in cases where an attacker assumes certain roles within a subscription, these Azure built-in capabilities will come in handy bypassing any network defense lines. Therefore, we named them Azure LoLBins.

How does it work?

Every image on Azure Marketplace contains an Azure guest agent implanted into it (VM Agent). The guest agent is a secure, lightweight process that manages VM interaction with the Azure Fabric Controller. The VM Agent has a primary role in enabling and executing Azure Virtual Machine extensions. Without the Azure VM Agent, VM extensions cannot be run.

The Guest Agent is responsible for managing VM extension operations such as installing, reporting status, updating individual extensions, and removing them. Extension packages are downloaded from the Azure Storage extension repository by the guest agent through communication with Azure fabric (over channel to 168.63.129.16).

To perform its tasks, the guest agent runs a Local System. Consequently, payloads of extensions, such as Custom Script Extension and Run Command, run on Azure Virtual Machines with extensive privileges on the local computer.

Impact

In this section, we will examine several behaviors we recently witnessed that demonstrate the exceptionality and potential strength of the VM extensions, making the specific Azure IAM roles, containing the rights to call them a lucrative target for attackers.

Case 1: Custom Script Extension

Custom Script Extension downloads and executes scripts on Azure Virtual Machines. This extension is useful for post-deployment configuration, software installation, or any other configuration or management tasks. Scripts can be downloaded from Azure Storage or GitHub, or provided to the Azure portal at extension run time. The Custom Script Extension can be run using the Azure CLI, PowerShell, Azure portal, or the Azure Virtual Machine REST API.

Usage of Custom Script Extension was seen spanning across different customers to fetch an executable from the same GitHub repository. We followed the traces to GitHub, finding the repository in question being publicly accessible allowed us to confirm the suspicion. The code intention within the executed payload (hack1.sh, see snippet below) is to mine cryptocurrency.

Example showing Case 1: Custom Script Extension

This behavior was observed across multiple customers from different countries within a noticeably short timeframe, together with the GitHub repository being inactive increased our suspicion this activity should not be associated with normal pen-test, red-team, or intended activity.

Case 2: VMAccess Extension

VMAccess Extension can create new administrator accounts, reset the password of an existing administrator account, reset the built-in administrator account and or reset the Remote Desktop service Configuration. Moreover, for Linux VMs, the extension can reset SSH public keys. Furthermore, similarly to other extensions, the VMAccess Extension can be executed through the Azure portal, Azure CLI, Powershell, or the Azure Virtual Machine REST API.

VM Access is extremely useful when managing your VMs. As an example, for Linux servers, an alternative would be to connect to the VM and execute the equivalent commands manually. Hence, it is one of the most accessible extensions due to its simplified user interface (UI) which you can access from the Azure Portal.

There is no doubt that the VMAccess Extension is a handy way for an attacker to gain initial access to VMs with elevated privileges. Such notorious usages of the extension may sometimes be difficult to notice. As an example, leveraging VM Access to create a common service user or modifying an existing one.

Example showing Case 2: VMAccess Extension

Case 3: Antimalware Extension

Microsoft Antimalware Extension for Azure is a free real-time protection capability that helps identify and remove viruses, spyware, and other malicious software, with configurable alerts when known malicious or unwanted software attempts to install itself or run on your Azure systems. Microsoft Antimalware for Azure is a single-agent solution designed to run in the background without human intervention.

The Microsoft Antimalware for Azure solution includes the Microsoft Antimalware Client and Service, and when used in Windows environment with Windows Defender enabled, the extension will apply any optional configuration policies to be used by Windows Defender, the extension will not deploy any additional antimalware service.

While experimenting with Microsoft Defender for Endpoint alerts for Windows and usage of the Anti-Malware extension, we noticed a correlation between alerts fired on the node followed by API calls to Azure Resource Manager. This orchestrates VM extensions, with configurations to the Anti-Malware extension that excluded the same alert-triggered payloads from being scanned in the future.

Using the Anti-Malware extension, attackers can potentially also disable the real-time protection before loading suspectable tools into the node or exclude specific files and directories for going unnoticed while conducting their malicious activity. Enjoying the benefit that Azure Resource Manager logs was rarely crossed in correlation to in-node telemetry.

Example showing Case 3: Antimalware Extension

Learn more

Microsoft recommends you implement detection and mitigation strategies to minimize exposure to new threats the Cloud brings. Azure Defender goes deep into dissecting attack techniques in order to define and build a depth protection plan.

Detection

Azure Defender has expanded its threat detection capabilities and recently introduced Azure Defender for Resource Manager, a new coverage for Azure deployment and management service. Every request to the Azure Resource Manager Endpoint on management.azure.com is logged and analyzed to reveal malicious intentions and threats.

Azure Defender for Resource Manager monitors all resource management operations performed in your organization performed through the Azure portal, Azure REST APIs, Azure CLI, or other Azure programmatic clients. Azure Defender runs advanced security analytics to detect threats and alert you when suspicious activity occurs. For a list of the Azure Defender for Resource Manager alerts, see the reference table of alerts.

Mitigation

Least privilege principle is a fundamental concept in Cloud environments. Ensuring that minimum access necessary to perform a legitimate operation would be granted to all identity types (human or non-human). A least privilege model for the cloud relies on the ability to continuously adjust access controls. We recommend monitoring all access events and establish a decision-making framework that distinguishes between legitimate and excessive permissions.

Get started for free today

Protect your entire Azure environment with a few clicks and enable Azure Defender for Resource Manager. This offer is free during the preview period. Turn Azure Defender on now.

To learn more about Microsoft Security solutions and our Integrated Threat protection solution 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 Azure LoLBins: Protecting against the dual use of virtual machine extensions appeared first on Microsoft Security.

Microsoft brings advanced hardware security to Server and Edge with Secured-core

March 2nd, 2021 No comments

A cursory look at recent headlines reveals two clear trends. First, organizations around the world are embracing digital transformation using technologies across cloud and edge computing to better serve their customers and thrive in fast-paced environments. Second, attackers are constantly innovating new attacks as technology changes and targeting these organizations’ high-value infrastructure with advanced technical capabilities connected to both cybercrime and espionage.

The MagBo marketplace, which sells access to more than 43,000 hacked servers, exemplifies the ever-expanding cybercrime threat. Compromised servers are being exploited to mine cryptocurrency and are being hit with ransomware attacks. Meanwhile, IoT vulnerabilities are on the rise, with more than half of IoT devices deemed susceptible to attack. In addition to these risks, companies often struggle with a lack of expertise and familiarity with security standards as well as complex regulations like the IoT Cybersecurity Improvement Act of 2020.

Given these factors, continuing to raise the security bar for critical infrastructure against attackers and also make it easy for organizations to hit that higher bar is a clear priority for both customers and Microsoft. As systems like the Xbox show, successfully protecting systems requires a holistic approach that builds security from the chip to the cloud across hardware, firmware, and the operating system. Using our learnings from the Secured-core PC initiative, Microsoft is collaborating with partners to expand Secured-core to Windows Server, Azure Stack HCI, and Azure-certified IoT devices, as well as bring the Secured-core values of advanced hardware-based protection and simpler security enablement to the server and IoT ecosystem.

Powerful protection with Secured-core Server and Edge Secured-core

Following Secured-core PC, we are introducing Secured-core Server which is built on three key pillars: simplified security, advanced protection, and preventative defense. Secured-core Servers come with the assurance that manufacturing partners have built hardware and firmware that satisfy the requirements of the operating system (OS) security features. Like Secured-core PC and Secured-core Server, Edge Secured-core advances built-in security for IoT devices running a full OS. Edge Secured-core also expands Secured-core coverage to Linux, in addition to Windows platforms.

Simplified security

New functionality in the Windows Admin Center makes it easy for customers to configure the OS security features of Secured-core for Windows Server and Azure Stack HCI systems. The new Windows Admin Center security functionality will allow enabling advanced security with a click of the button from a web browser anywhere in the world. With integrated Azure Stack HCI systems, manufacturing partners can also enable OS features, further simplifying the configuration experience for customers so that Microsoft’s best server security is available right out of the box. For Windows Server and validated Azure Stack HCI solutions, customers can look for Secured-core certified systems to simplify acquiring secure hardware platforms.

The Windows Admin Center will allow easy management of Secured-core functionality from any browser

The Azure Certified Device program already helps customers find the right edge and IoT solutions for their needs. We are adding the Edge Secured-core public preview to the Azure Certified Device program. Edge Secured-core devices meet extra security requirements around device identity, secure boot, OS hardening, device updates, data protection, and vulnerability disclosures, which will be uniquely identifiable on the Azure Certified Device catalog.

Advanced protection

Secured-core Servers maximize hardware, firmware, and OS capabilities to help protect against current and future threats. These safeguards create a platform with added security for critical applications and data used on the server. Secured-core functionality spans the following areas:

  • Hardware root-of-trust: Trusted Platform Module 2.0 (TPM 2.0) comes standard with Secured-core Servers, providing a protected store for sensitive keys and data, such as measurements of the components loaded during boot. Being able to verify that firmware that runs during boot is validly signed by the expected author and not tampered with helps improve supply chain security. This hardware root-of-trust elevates the protection provided by capabilities like BitLocker, which uses the TPM 2.0 and facilitates the creation of attestation-based workflows that can be incorporated into zero-trust security strategies.
  • Firmware protection: In the last few years, there has been a significant uptick in firmware vulnerabilities, in large part due to the higher level of privileges that firmware runs combined with limited visibility into firmware by traditional anti-virus solutions. Using processor support for Dynamic Root of Trust of Measurement (DRTM) technology, Secured-core systems put firmware in a hardware-based sandbox helping to limit the impact of vulnerabilities in millions of lines of highly privileged firmware code.
  • Virtualization-based security (VBS): Secured-core Servers support VBS and hypervisor-based code integrity (HVCI). The cryptocurrency mining attack mentioned earlier leveraged the EternalBlue exploit. VBS and HVCI help protect against this entire class of vulnerabilities by isolating privileged parts of the OS, like the kernel, from the rest of the system. This helps to ensure that servers remain devoted to running critical workloads and helps protect related applications and data from attack and exfiltration.

Edge Secured-core devices come with a built-in security agent, a zero-trust attestation model, and security by default, delivering on the following security features:

  • Hardware-based device identity.
  • Capable of enforcing system integrity.
  • Stays up to date and is remotely manageable.
  • Provides protection for data at rest and data in transit.
  • Built-in security agent and hardening.

Edge secured-core brings security from the edge to the cloud by leveraging devices, platforms and services

Preventative defense

Secured-core Servers and Edge Secured-core have security mitigations built into the hardware and OS platform to help thwart common attack vectors. Secured-core functionality helps proactively close the door on the many paths that attackers may try to exploit, and it allows IT and SecOps teams to optimize their time across other priorities.

Coming soon, with the support of the ecosystem

Secured-core Servers across Windows Server 2022 and Azure Stack HCI will help customers stay ahead of attackers and help protect their infrastructure across hardware, firmware, and operating systems. Supported hardware will be available in future product generations from Intel, AMD, and our vibrant OEM ecosystem.

“Continuing the rich tradition of innovation in hardware security, AMD is excited to partner with Microsoft to enable Secured-core Server with its future EPYC processors”, said Akash Malhotra, AMD director, security product management. “With attacks on firmware increasing, a tight integration between AMD hardware security features and the Windows Server operating system will benefit users across the ecosystem.”

“Today’s distributed world demands a new era of security. Intel and Microsoft are working together to provide innovative levels of security controls that provide customers with unified, integrated protection,” said Jeremy Rader, General Manager, Intel Cloud and Enterprise Group. “We’re combining the power of Secured core server with our 3rd Gen Intel Xeon Scalable processors (code-named Ice Lake) that creates a chain of trust across all layers of compute, from the hardware, to the firmware to the OS. Customers get a seamless root of trust that combines the most advanced security with management ease.”

You can learn more about Secured-core Servers and Windows Server 2022 security in the related blog.

To get started with Edge Secured-core certification, browse the following resources:

To learn more about Secured-core Servers and Edge Secured-core, be sure to join us during Microsoft Ignite from March 2-4, 2021.

The post Microsoft brings advanced hardware security to Server and Edge with Secured-core appeared first on Microsoft Security.

Microsoft unifies SIEM and XDR to help stop advanced attacks

March 2nd, 2021 No comments

For all of us in security, the last twelve months have been an incredible series of challenges—from balancing remote work with family priorities, to helping build resilient businesses, and protecting against the latest attacks. 2020 showed us that while we have made great progress, there is still a lot we can do as individuals, organizations, and as a community to keep secure. Here at Microsoft, we’re committed to applying these learnings to help create a stronger, more unified approach to security for all—no matter what platform you’re on, device you’re trying to protect, or cloud your data is in.

To help protect against advanced attacks, last September at Microsoft Ignite we shared our vision to create the most complete approach to securing your digital landscape, all under a single umbrella. We combined the breadth of Azure Sentinel, our cloud-native SIEM (security information and event management) with the depth of Microsoft 365 Defender and Azure Defender, our XDR (extended detection and response) tools, to help fight against attacks that take advantage of today’s diverse, distributed, and complex environments.

Today we are taking the next step in unifying these experiences and delivering enhanced tools and intelligence to stop modern threats.

Unified experiences

Most SIEMs on the market today simply take logs from multiple sources. Azure Sentinel accepts logs across your environment with many third-party security products and can go a step further with Azure Defender and Microsoft 365 Defender. Starting today, incidents, schema, and alerts are shared between Azure Sentinel and Microsoft 365 Defender. This means you get a unified view in Azure Sentinel, then can seamlessly drill down into an incident for more context in Microsoft 365 Defender.

For example: Start in Azure Sentinel for your bird’s eye view to understand an overarching incident, then move directly into Microsoft 365 Defender to investigate an asset or a user in more detail. You can even remediate and close the incident directly within Microsoft 365 Defender, all while maintaining bi-directional syncing with Azure Sentinel. This is next level SIEM integration you won’t find anywhere else.

On the Microsoft 365 Defender side, we are working to reduce the number of portal experiences. The goal is to have a single unified XDR experience for securing end-user environments, rather than a suite of products. Today marks a significant milestone in that effort as we integrate the capabilities of Microsoft Defender for Endpoint and Defender for Office 365 together into the unified Microsoft 365 Defender portal. These changes simplify tasks that would require multiple experiences across comparable products in the market. We have also taken the opportunity to significantly enhance the email entity page with a new 360-degree view of email alerts with relevant context and email alert capabilities.

Enhanced tools and intelligence to stop advanced attacks

As well as unifying the capabilities of Microsoft Defender for Endpoint and Defender for Office 365 into Microsoft 365 Defender, we have also created new enhanced experiences including:

  • Threat Analytics, now in preview, provides detailed threat intelligence reports from expert Microsoft security researchers that help you understand, prevent, and mitigate active threats.
  • Learning Hub where you can use instructional resources with best practices and how-tos.
  • Attack Simulation Training in Microsoft Defender for Office 365 which helps you detect, prioritize, and remediate phishing risks. It uses neutralized versions of real attacks to simulate the continually changing attacker landscape, enabling highly accurate and up-to-date detection of risky behavior, with rich reporting and analytics to help customers measure their progress.

With Azure Sentinel, we’re focused on giving you a richer organization-wide view with expanded data collection and helping you to respond faster with new incident response and automation capabilities. Today we are announcing more than 30 new connectors to simplify data collection across your entire environment, including multi-cloud environments. These new connectors include Salesforce service cloud, VMWare, Cisco Umbrella, and Microsoft Dynamics.

New automation rules in Azure Sentinel

We’re also expanding Azure Sentinel’s SOAR capabilities. Today we’re introducing automation rules (a new and simple framework for automating common tasks), and new automation connectors with additional built-in SOAR playbooks. These new playbooks enable automation workflows such as blocking a suspicious IP address with Azure Firewall, isolating endpoint devices with Microsoft Intune, or updating the risk state of a user with Azure Active Directory Identity Protection. You can learn more about these Azure Sentinel innovations on the Azure Sentinel Microsoft Ignite 2021 announcement blog.

Finally, Azure Defender now provides improved alerts features, including improved triaging experience with better performance for larger alert lists, alerts from Azure Resource Graph, sample creation feature for Azure Defender alerts, and alignment with Azure Sentinel’s incident experience. To learn more about these and other Azure Security Center announcements, please read the Azure Security Center Microsoft Ignite 2021 announcement blog.

Integrated threat protection from Microsoft comprises Azure Sentinel, a cloud-native SIEM, Microsoft 365 Defender that provides XDR capabilities for end-user environments, and Azure Defender that provides XDR capabilities for infrastructure and cloud platforms.

Looking ahead

We’ve been on a long journey to figure out how to understand and help you protect against advanced attacks. We’re only just getting started on our mission and will continue to unify tools and add intelligence to help keep your environment healthy and secure.

Be sure to check out our Microsoft Ignite session, and learn more about our SIEM + XDR offering.

As always, thank you for your continued partnership on this journey.

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.

-Rob, Eric, and our entire Microsoft Security Team

The post Microsoft unifies SIEM and XDR to help stop advanced attacks appeared first on Microsoft Security.

Protecting multi-cloud environments with Azure Security Center

January 27th, 2021 No comments

We’ve heard from many of you that multi-cloud adoption is becoming a standard operating model for your organization and that it’s challenging to have the right security controls and posture across your environment. Historically, security teams have not had effective tools to secure multi-cloud infrastructure, and often they needed to address the problem by adding more people.

This is why in September we introduced multi-cloud security support in public preview, and today we are excited to announce the general availability of these capabilities. Now you can onboard multi-cloud resources to Azure Security Center, such as Google Cloud Platform (GCP) and Amazon Web Services (AWS), you can protect your servers with Azure Defender for Servers based on Azure Arc, and we’ve added multi-cloud support to Azure Secure Score, making it easier to focus on the most important things to improve your overall security posture.

Thycotic Logo

“Now that Microsoft supports multi-cloud environments—Amazon Web Services and Google Cloud Platform—there’s no reason for us to look at any other vendor. We get everything we need with Azure Defender.”—Terence Jackson, Chief Information Security and Privacy Officer, Thycotic

Learn more about the Thycotic case study.

 

When we started developing Azure Security Center, our charter was clear—be the best solution to protect Azure Resources. As we listened to customers, we clearly heard the need to protect resources in multiple clouds, and the desire to simplify tools to manage multi-cloud. We have grown to support these broader needs. Azure Security Center now protects not only hybrid but also multi-cloud resources, including AWS and GCP. The following functionality is now generally available to our customers:

  • Customers can connect their AWS or GCP accounts to ASC to get a unified multi-cloud view of security posture. Specifically, AWS Security Hub and GCP Security Command Center detected misconfigurations and findings are now included in our Secure Score Model and Regulatory Compliance Experience.
  • Azure Defender for Servers leverages Azure Arc to simplify the on-boarding and security of virtual machines running in AWS, GCP, and hybrid clouds. This includes automatic agent provisioning, policy management, vulnerability management, embedded EDR, and more.
  • These new features complement the multi-cloud support for Azure Defender for SQL that was released in December.

In addition to new multi-cloud support, Azure Security Center continues to be one of the best of breed solutions to protect Azure resources. Today we are improving the richness of security recommendations in Azure by turning on Azure Security Benchmark as the default security policy for Azure Security Center.  As a result, Azure Secure Score now reflects a much broader set of recommendations and spans a broader set of Azure resources.

Also, the full control set layout of the Azure Security Benchmark in the compliance dashboard is now available to all Azure Security Center customers, including Azure Security Center free tier as well as the existing Azure Defender customers. Customers can now view their compliance relative to the benchmark controls in compliance view while viewing the detailed impact on their Secure Score. By prioritizing remediation of security recommendations using Secure Score metrics, customers can achieve a higher Secure Score and attain their compliance goals, all at the same time.

Finally, in response to your feedback, we have added the ability to exempt resources from the Secure Score both at a subscription level and now at a management group level. This is most useful in cases where you have a third-party technology in place to address a recommendation, such as turning on multi-factor authentication (MFA).

Multi-cloud is going to be a big area of focus for you—and for us—going forward. We are committed to supporting your broad security needs, by continuing to expand our multi-cloud and hybrid support, as well as continuing to provide best of breed solutions to secure Azure. For more information, please visit the Azure Security Center and the Azure Security Center documentation. We are here to listen and build great products that help you thrive—keep the feedback coming.

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 Protecting multi-cloud environments with Azure Security Center appeared first on Microsoft Security.