Featured Blog

Remediate Vulnerable Secure Channel Connections with the Insecure Protocols Workbook

Jon_Shectman — Thu, 27 Aug 2020 15:24:21 PDT

This article is written by Jon Shectman and Brian Delaney, Microsoft.

Have you read about the elevation of privilege vulnerability that exists when an attacker establishes a vulnerable Netlogon secure channel connection to a domain controller? An attacker who successfully exploited the vulnerability could run a specially crafted application on a device on the network. If you haven't, you can read about the vulnerability here a and learn how to manage the changes here. Those articles give an excellent overview of the issue, so I won't repeat it in detail here. In short, we are addressing this vulnerability in a two-part rollout by modifying how Netlogon handles the usage of Netlogon secure channels.

Phase one, deployment, began on Aug 11. In this phase, secure Remote ProtoCol (RPC) is enforced for machine, trust and domain controller accounts. This phase also includes a new group policy object (GPO) and a registry key to manage configuration, and five new Event IDs.

These Event IDs are important for auditing and understanding of the issue. They are as follows:

Machine Events

5827 - Connection denied

5829 - Non-compliant (allowed during Deployment phase)

5830 - Allowed by policy

Trust Events

5828 - Connection denied

5831 - Allowed by policy

Phase two, enforcement, is slated to begin Feb 9, 2021. In phase two, non-compliant machine connections will be denied by default and an Event ID 5827 will be logged. It's entirely possible to set the new GPO "Domain controller: Allow vulnerable Netlogon secure channel connections" and to simply allow the vulnerable connections. However, that is not recommended. Rather, you should use the new tab in the Insecure Protocols Workbook to detect and understand the five new Event IDs and take appropriate action to address the vulnerable Netlogon sessions prior to the enforcement phase. If you're new to the Insecure Protocols Workbook, we recommend checking out the getting started guide and then come back here.

To populate the Workbook, take two steps:

1. On your domain controllers, apply the relevant update from CVE-2020-1472.

2. In Azure Sentinel, go to Settings, Workspace Settings, Advanced Settings, Data, Windows Event Logs, and add (or make sure you already have added) Errors and Warnings from the System Log.

Once you have data flowing, it's time to start using the Insecure Protocols Workbook. The first addition you'll notice is a new tab, Vulnerable Secure Channel.

The most efficient way to describe how to use this tab is to simply show it - as in the GIF below.

At the top of the tab is a counter (tile) for each of the five new Event IDs. In our lab, for example, we have eight instances of Event ID 5830. That's the tile I clicked on to filter to that event ID. Next, I "painted" a timebrush slice to filter the queries below to a particular time; then I simply clicked on a Machine Account to show the Machine Account Connections. The result is a highly actionable data set, showing us exactly where we need to research vulnerable secure channel connections.

Once you know where to look, you'll need to upgrade all Netlogon clients. However, there's an additional point to consider. Though we expect it to be a rare finding, vulnerable secure channel connections can come from not only machines, but also from trusts (most likely Realm trusts). This configuration may result in significantly increased exposure (Event ID 5828) and may require more planning to remediate.

In this article, we briefly discussed the exposure in vulnerable secure channel connections, how they are logged during the first phase of CVE-2020-1472, and how to audit them with the Insecure Protocols Workbook.

A brief sidenote: If you ever feel your perspectives don't matter or that your opinions aren't good enough, we urge you to think again. This workbook enhancement came directly from a conversation on Twitter where multiple folks made the case for it. If you have concepts to add, functionality you'd like to see added, or ideas for improvement, please reach out on Twitter (@shectonsecurity), find us on LinkedIn, or use the comments section. We are all ears.

Thanks for reading and, as always, happy auditing. :)

Securing MEM at Microsoft

MikeGriz — Thu, 27 Aug 2020 11:46:50 PDT

The security we have in place for managing MEM happens at several levels. A mantra here at Microsoft is that every security decision should be made under the assumption that all other security measures have failed to keep the "bad people” out. That means there are a lot of levels of security and thought. Being users of MEMCM and MEM Intune just like the rest of the customers out there we won’t try to cover all the product specific security implementations here. Those we will leave to the product documentation itself. Instead we will look at this from the administration process viewpoint.

Read-Only Access

Through normal daily activities we need to see various things in our services. Elevating or going through the steps necessary below to have read-only access granted becomes too complicated for these common access reasons. For that we maintain several different groups which provide access to various resources. Each of those is managed by an internal system where people can request to join a group and that group membership is either approved through a process or auto-approved, depending on what it is focused on. That membership, once granted, has a renewal timeline and will remove membership when someone leaves the group/company.

Multiple Accounts

A basis of what we do is to have two separate accounts. The idea is to have one account for normal operations (email, TEAMS meetings, etc). The other account is used ONLY for administrative activities. We refer to this as our “Alternative Account” or, “ALT account” for short. The ALT account is backed by a smart card and certificate login requirement making the compromise of the account a little more difficult. Both accounts require multi-factor authentication.

Secure Workstations

While much of our read only access can be done from our normal desktops and laptops, anything that requires an admin level of access is locked down to only allow access from Secure Access Workstations (SAW). These are special laptops which work on a basis of whitelisting what they are allowed to access and what apps they can run. We do not have admin rights on these machines like we do on our normal machines, we can’t go off to malicious websites, and we can’t get email on them. Their exposure to risk is more limited. The SAW run a separate VM which some people use for those “normal” activities, while others will remote back to other machines when that “normal” activity is needed.

Azure Portal

Our Microsoft Endpoint Manager Configuration Manager (SMS to you old school folks, SCCM to you “not as old, but not your first rodeo” folks) is Azure hosted, so protecting that Azure access is the first layer we need to keep secure. We do this using normal methods which allow our normal accounts a level of read access, but no standing administrative rights. Admin access requires Azure Privileged Identity Management (PIM). It will elevate our account, on a temporary basis, to have the needed admin permissions in Azure. This is audited, requires a second person approval, and is time limited to reduce the attack concerns.

Server Access

If we need to get into a server for looking at logs or other simple things we have some read-only share access setup for our team. Beyond that we have a system that is similar in concept to PIM that requires that we request the level of access we need and then grants that access for a limited time. We refer to it as “Just in Time” access, or JIT for short. Things like which server, is it OS level or SQL level or SCCM level, etc. are all separated to require different escalations, and it is all audited, of course. This allows us to request the minimal access necessary for the job at hand.

Intune Access

Admin access to Intune is, essentially, through the normal Azure portal like above. There is a separate PIM role for Intune administrative . This is also designed around the “nuclear launch” concept where a second person is required to agree and authorize the rights elevation. For those that need a lower level of rights, but still have the ability to read or interact with the environment in a limited capacity we make use of the RBAC roles within Intune and some self-cleaning security groups to grant that access. We also have a few different Intune environments (we are running beta versions of things) so we have some separation around those things as well.

Configuration Manager Access

Similar to server access we have JIT groups for accessing MEMCM itself. They tie back into the RBAC roles of the product so different people have different groups for different activities, but anything that can make any kind of change is controlled in this fashion. We have also enabled multi-factor authentication (MFA) in the product to help us ensure that people are coming in as securely as we can.

Summary

Anytime we have a new hire we always must go through an orientation of what to use when and how. But, once you do things a few times it gets to be second nature. A few things have some time delays that can be frustrating at times, but overall it seems to work well and we take the security of our operations very seriously. Does it add complexity and occasional frustration... yes. Is it worth it to keep our environment safe... totally.

Hopefully this gives you an idea of how we securely control access to our MEM environments. We have also done work within the features of the products to increase our security stance, such as removing the Network Access Account and using token authentication, getting rid of traditional service accounts where possible, and auditing activity. All that we will save for other blog posts.

Automation to Block Brute-force Attacked IP detected by Azure Security Center

Safeena Begum Lepakshi — Thu, 27 Aug 2020 10:32:39 PDT

According to Microsoft Threat Intelligence Report, one of the most common attacks against IaaS VMs in Azure is the RDP brute-force attack. This attack usually take places for VMs that are exposing the RDP port (TCP 3389). Although RDP is the primary source, there are also brute-force against SSH (TCP 22).. Nowadays with COVID-19, with more employees working from home more often, threat actors are taking advantage of the increase of management ports open, which includes RDP and SSH. Users with weak passwords and without MFA enabled, are more susceptible to be compromised by and RDP brute force attack.. Keep in mind that compromising a server via RDP brute force is just the initial foothold, once the threat actors gain access to target machine, it will continue conducting malicious activities which may include coin mining and even ransomware type of attack.

One way to reduce the likelihood that your machine will be compromised via RDP brute-force is by reducing the exposure, in other words, limiting the amount of time that a port is open by securing your management ports using Just-in-time access, capability available in ASC Standard Tier.

This blog explain how to leverage automation to block traffic of specific IP to a VM in the NSG as a response to a Brute-force alert detected by Azure Security Center.

How does the automation work?

When Azure Security Center detects a Brute-force attack, it triggers an alert to bring you awareness that a brute force attack took place. The automation uses this alert as a trigger to block the traffic of the IP by creating a security rule in the NSG attached to the VM to deny inbound traffic from the IP addresses attached to the alert. In the alerts of this type, you can find the attacking IP address appearing in the 'entities' field of the alert.

The Logic App uses a system-assigned Managed Identity. You need to assign Contributor permissions or Security Reader and Network Contributor permissions to the Logic App's Managed Identity so it is able to create an NSG rule once there is an attack detected. You need to assign these roles on all subscriptions or management groups you want to monitor and manage resources in using this playbook. Note: You can assign permissions only if your account has been assigned Owner or User Access Administrator roles, and make sure all selected subscriptions registered to Azure Security Center.

Refer to the Readme file in our GitHub Repository for detailed procedure.

Deployment process and details

Navigate to Azure Security Center GitHub repository and select “Deploy to Azure” or “Deploy to Azure Gov”, as shown in Image 1:

Image 1: Git Hub repository

Once you have clicked on ‘Deploy’ option in the screen above, you should automatically be redirected to the Azure portal Custom deployment page where you can fill in the details of requirement as shown in Image 2, as shown below:

Image 2: Azure portal, Custom Deployment

The ARM template will create the Logic App Playbook and an API connection to Office 365, and ASCalert.

You need to authorize the Office 365 API connection so it can access the sender mailbox and send the email notification from there.

Once you review and create from Image 2, you would notice below resources created from the ARM template (Refer Image 3)

Image 3: Summary of the resources created from the ARM template

Define when the Logicapp should automatically run:

Workflow automation feature of Azure Security Center can trigger Logic Apps on security alerts and recommendations. For example, you might want Security Center to email a specific user when an alert occurs. When you add the workflow automation and trigger conditions as show in Image 4, the triggers will initiate this automatic workflow. In this example, you want the Logic App to run when a security alert that contains "bruteforce" is generated.

Image 4: Workflow Automation

Note: Read more about workflow automation here

When a Bruteforce attack is detected by Azure Security Center as shown in Image 5, this would automatically apply the automation and blocks the traffic of the IP by creating a security rule in the NSG attached to the VM to deny inbound traffic from the IP addresses attached to the alert as shown in Image 6

Image 5: Brute force attack alert

Image 6: IP blocked by ASC

You would receive an email notification on the alert details as shown in Image 7:

Image 7: Email notification from the logicapp

This logic app as well as many other can be found here:

Direct Link to GitHub sample

Azure Security Center GitHub Repo

Most organizations lack the time and expertise required to respond to these alerts so many go unaddressed. Having this type of automation can address the threat immediately. I hope you enjoy reading this article and implementing, testing it as much as I enjoyed writing it.

Reviewer

Special thanks to:

Yuri Diogenes, @Yuri Diogenes, Senior Program Manager (CxE ASC Team)

Introducing a simpler way to secure your Windows 10 computers with Microsoft 365 Business Premium

Jon Orton — Thu, 27 Aug 2020 10:15:51 PDT

Applying security policies to the computers in your organization is a foundational security practice. It’s especially important now that more employees are using these devices away from the office. To make it easier for you to protect your organization’s devices, we’ve added a new setup experience to the Microsoft 365 admin center that allows you to establish a security baseline for all of the Windows 10 PCs in your organization in just a few clicks.

This new experience is available to customers with Microsoft 365 Business Premium. It has begun rolling out and will reach all eligible customers within the next few months. Let’s take a closer look at what’s new.

To access these new capabilities, in the Microsoft 365 Admin Center, open Setup on the left menu.

In the Sign-up and Security section, find Secure your Windows 10 computers, and click the View button.

On the Secure your Windows 10 computers page, you can read about the streamlined process for securing Windows 10 devices and access relevant documentation. As the page notes, this experience is built with small and medium-sized businesses in mind. It simplifies the process of setting up Intune-powered devices policies. Larger enterprises and advanced users can go to the Endpoint Manager admin center instead. Click the Get Started button to continue.

The pane that appears on the right side shows the five policies recommended for applying a security baseline. The policies that you can enable here are a lightweight set designed to elevate your protection while minimizing user impact and limiting management complexity. They were selected based on input from IT partners who serve small and medium sized businesses, telemetry on the most commonly applied Intune policies, and feedback from customers.

The recommended security settings are:

Help protect PCs from viruses and other threats using Windows Defender Antivirus: Requires that Windows Defender Antivirus is turned on to protect PCs from the dangers of being connected to the internet.
Help protect PCs from web-based threats: Turns on settings in that help protect users from malicious sites and downloads. It also prevents the launching off applications with Microsoft Office.
Prevent network access to potentially malicious content on the Internet: Network protection helps to prevent employees from using any application to access dangerous domains that may host phishing scams, exploits, and other malicious content on the internet.
Help protect files and folders on PCs from unauthorized access with BitLocker: BitLocker Drive Encryption is a data protection feature that integrates with the operating system and addresses the threats of data theft or exposure from lost, stolen, or inappropriately decommissioned computers.
Turn off device screen when idle for this amount of time: Makes sure that company data is protected if a user is idle. A user may be working in a public location, like a coffee shop, and step away or be distracted for just a moment, leaving their device vulnerable to random glances. This setting lets you control how long the user can be idle before the screen shuts off.

When you click Apply Settings, the system will create these policies in Intune. For these policies to actually take effect, the conditions noted in the gray box must be true.

The most important of these is that the user’s computer must be enrolled in Intune. That is how the computer knows to check the cloud to see which settings should be applied. For information about Intune enrollment in an environment where PCs are joined to an on-premises Active Directory domain, see Enable domain-joined Windows 10 devices to be managed by Microsoft 365 Business Premium, an article that we recently improved based on customer feedback.

Note: You typically will not need to change Azure Active Directory settings noted in the gray box unless you have previously customized them.

After the policy setup is complete, you can access and modify the policies at any time by clicking Devices and then Policies.

The policy called “Device Policy for Windows 10” is the one created in the setup experience. You can modify that policy or create additional ones.

When you edit the settings, you’ll notice the original settings plus additional ones you can activate; related to keeping devices up to date, allowing users to download apps from the Microsoft store, and so on.

Advanced users who are familiar with Intune can also edit these policies and create others in the Endpoint Manager admin center, which is accessible in the left navigation.

We’re rolling these capabilities out right now, and are eager for you to put them to work to secure the devices in your organization. If you have questions about the new setup experience, or feedback for the team, let us know here in the Tech Community.

What is Azure SQL Edge | Data Exposed

MarisaBrasile — Thu, 27 Aug 2020 09:43:44 PDT

In part one of this three-part series, Vasiya Krishnan introduces Azure SQL Edge and its features that make it the optimized database engine for IoT Scenarios. In part two, Vasiya will review customer examples and use cases, and in part three, she'll conclude with a demo that demonstrates how to use Azure SQL Edge to build smarter renewable resources.

Watch on Data Exposed

Additional Resources:
Microsoft Industry Solutions
Learn more about Azure SQL Edge
Learn more about the features and building an end to end solution
Azure SQL Edge customer stories
Azure SQL Edge whitepaper

View/share our latest episodes on Channel 9 and YouTube!