Create Azure Alert Using KQL Custom Search

In this post we will be going through creating an alert rule using Azure monitor and custom log search.

This can be setup for for most services in Azure that are set to use Azure log work space or have activity logs but we will be setting up for a Azure VM in this post.

We needed to create an alert for a specific server that we have powered off and wanted to be alerted when it was powered on.

There is no out of the box alerting for this, we end up deciding to use an alert rule with a KQL query.

First we need to logon to the Azure portal and go to the VM we wanted to alert on.

Select Alerts blade and create custom alert rule.

Select custom log search from the drop down signal name.

Add the search query. I used the AzureAcitivty table and search for the operation value name for virtual machine start action.

AzureActivity
| where OperationNameValue == 'MICROSOFT.COMPUTE/VIRTUALMACHINES/START/ACTION' and ActivityStatusValue == 'Success'
| where EventSubmissionTimestamp >= (ago(2h))

We will also need to set the required measurement type, aggregation type and aggregation.

I used count as I want to alert when there is a count greater than 1, as this will mean the VM has been booted up.

Next we need to set the alert logic.

Set the operator, threshold value and frequency check for the alert. I set the threshold to greater than one alert and evaluate the logs every 2 hours.

We can change the preview to view the current aggregate, which is one for me as I started the VM earlier in the day.

Next we need to either create a new action group or use a pre existing one. I will be creating a new group.

This can be set to send email, SMS message, push notification or voice message.

Next we need to set the subscription and resource group for the alert. We will also set the alert rule severity, name, description and region.

We can also set advanced option like automatically resolving alerts.

Next we set the tags to be used, if required.

Last step is to review and confirm all the settings.

To test we can Power on the VM and check if the alert fires in the Azure portal and we received the email alert.

Setting up alerts using custom log search’s can be very usefully especially if there is no out of the box report.

Windows Defender Install – ERROR_SXS_ASSEMBLY_MISSING

During a recent Windows Defender deployment we ran in to an issue with the onboarding script where the Windows Defender feature would fail to install with Enable-WindowsOptionalFeature : The referenced assembly could not be found.

When checking the the CBS log under C:\Windows\Logs\CBS\CBS.log we found that the issue was related to a missing package for a previously installed update.

CBS Failed to pin deployment while resolving Update: Package_8092_for_KB5005043~31bf3856ad364e35~amd64~~10.0.1.3.5005043-16635_neutral from file: (null) [HRESULT = 0x80073701 – ERROR_SXS_ASSEMBLY_MISSING]

After a bit of troubleshooting there where two fixes to this issues, if the update that is missing is available, we can download the update MSU / CAB file from the Microsoft update catalog using the KB ID. I have covered this in a previous blog post so wont go over that fix on this post use the below link to view that post.

Windows Updates Fail Error Code 0x800F0831 Server 2012 R2

In some of our cases the update file was not available to download anymore, in this case we need to modify the registry to set the package values that are corrupted to be ignored.

Doing any modification of the registry comes with risk and this should only be done when all other solution have been attempted. Make sure there is a valid a backup before attempting this fix.

First we need to get the list of packages that are showing in the CBS logs as corrupted. The below script will go through the CBS log and get the packages and format the results.

$cbsLog = "c:\windows\logs\cbs\cbs.log"
$results = @()

Write-Host "Checking CBS logs for SXS Assembly Errors" -ForegroundColor Green
$checkingfailure = Get-Content $cbsLog | Select-String "ERROR_SXS_ASSEMBLY_MISSING"

$cbsresults = Get-Content $cbsLog  | Select-String "Resolving Package:"

      

if ($cbsresults) {

    foreach ($cbsresult in $cbsresults) {

        $packageresult = ($cbsresult | Out-String).Split(":").trim().Split(',')| Select-String "Package_"

        $results += $packageresult
    }
}

$results | Select-Object -Unique

Now that we have the list we need to set the local administrators group as the owner of the component registry key in order to be able to update the effect packages current state so they wont be checked.

Open regedit and go to

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing

Select Administrators as the owner and replace owner on subcontainters and objects.

Last step is to set the local administrators with full control of the registry key.

Now that we have the permissions set we can modify the registry values. This can be either scripted or manually done.

The current value needs to be change to 0 to set.

Set each of the corrupted package to 0

Then revert the permission back so Administrators have read access and trusted installer (NT Service\TrustedInstaller) is the owner of the components registry key and subkeys.

Now when we try and run the onboarding script again the Windows Defender feature enables without issue.

Azure Key Vault: Access With PowerShell

Azure Key Vault is a cloud-based service provided by Microsoft Azure that allows users to securely store and manage keys, secrets, and certificates used in their applications and services.

It acts as a repository for sensitive information and provides a secure way to access and manage sensitive data. Key Vault offers features such as key and secret rotation, access policies, and auditing capabilities, ensuring that sensitive data remains protected at all times.

It integrates with other Azure services and provides encryption and access control, making it a reliable solution for safeguarding critical data.

In this post we will be going through configuring Azure Key Vault, adding some secrets and calling these secrets using PowerShell.

Before using Azure Key Vault, there are a few prerequisites that need to be in place:

Azure Subscription: You will need an active Azure subscription to create and manage Azure Key Vaults.
Resource Group: Create a resource group in Azure
Access Control: Ensure that you have the necessary permissions and role-based access control (RBAC) rights to create and manage Azure Key Vaults. The required roles typically include Owner, Contributor, or Key Vault Contributor.
Network Configuration: Configure your virtual network and firewall rules to allow access to the Azure Key Vault. You can limit access to specific IP addresses or Azure services based on your security requirements.

I will be using a pre-existing resource group and VNET and we wont be covering those in this post.

Azure Key Vault and secrets can be created either using AZ CLI, AZ PowerShell and the Azure portal. In this post we will be using the Azure portal and will create a new secret using AZ PowerShell.

First step is to create a new key vault in the Azure admin portal search for key vault and open the blade.

Click create

Select the resource group

give the vault a name
set the region
set the pricing tier
set soft delete

Set the permission model and resource access.

I will be leaving public access open but in production I would limit this and create a private endpoint.

Review the setting and create the key vault.

The deployment will take a minute to complete.

Before we can being using the key vault we need to give permission.

Go to the key vault, select IAM and click add.

Next select the role to assign. In this case I am using Key Vault Administator.

Select the member, I am using a group, this could also be a managed Identity incase we need to allow Azure function or automation account to connect.

Review and assign the permissions.

Now that we have the key vault and permission set we can add some secrets.

Go to objects and secrets. Click on generate/import

Give the secret a name and a value, we can also set activation / expiration dates and tags.

Click create to add the secret.

Now we should see the secret in the secrets blade.

We can view the value directly in the Azure console be clicking on the secret and view the secret value.

The last step is to test that we can call the value using PowerShell. To run these command we first have to install the AZ PowerShell module.

Connect using AZ PowerShell

Connect-AzAccount

If there are multiple subscriptions we need to set using Set-AzContext

Set-AzContext -Subscription "Subscription name"

Use the Get-AzKeyVaultSecret command to to view the secret

Get-AzKeyVaultSecret -VaultName "vault name"

To retrieve the value as plain text use

Get-AzKeyVaultSecret -VaultName "vault name" -Name "secretvalue" -AsPlainText

To create a new secret using AZ PowerShell

$setsecretvalue = ConvertTo-SecureString "This is another secret value" -AsPlainText

Set-AzKeyVaultSecret -VaultName "vault name" -Name "secret name" -SecretValue $setsecretvalue

Now we can call the secret to view that the value has been set.

This was quick run through of calling secrets using Azure Key Vault and PowerShell, this can be use full when a scripts that need to authenticate and can be used to remove any hard coded passwords or strings from scripts.

Microsoft Graph: Restrict Access Using Conditional Access Policy

In this post we will be going through setting up a conditional access policy to allow connection’s to a Microsoft App Registration that will be used for calling Microsoft GraphAPI from only certain countries / public IP’s.

Microsoft has a preview feature in Conditional Access for workload identities. A workload identity is an identity which allows an application or service principal access to resources.

When an App Registration is created, it will create a service principal. This service principal is what we will use in the conditional access policy.

First we need to create the named location to define where we want to allow the access from.

To create a named location go to endpoint management admin page.

https://endpoint.microsoft.com/

Go to Endpoint security > Conditional access.

Once in Conditional access, go to Named location and add the required countries locations and or IP ranges.

To add as single IP use /32 bit subnet mask.

Once we have the named locations we can create the Conditional access policy.

Go to the policies tab and click on new policy.

Give the policy a name and set the assignment to workload identities.

Next select the service principal for the Graph App registration.

Next on Cloud apps or actions select, All cloud apps

Next we need to specify which location will be included, which we set to any location as we will use the exclude to allow access from the named location we will connect from.

Next select the location that will be excluded from the policy in my case it will be the public IP we added earlier to the named location.

Next we set the access, I will be blocking access as I only want to allow access from the one public IP we specified in the excluded location.

With any conditional access policy I would recommend setting the policy to Report-only to confirm that only the access that we excepted to be blocked is.

To check if the policy is applying correctly against the service principal we can check the sign-in logs.

First connect using Graph query and then go to sign-in logs.

Select service principal sign-ins.

Click on the request ID and look at the Report-only tab to see if the access would have been blocked or allowed.

Once we confirm that the policy is applying the correct access, the conditional access can be set to on.

Now once we try to connect from an IP or location not on the excluded list, it will be blocked from accessing.

When we connect from an allowed location, we will get back the access token and be allowed to connect.

When creating App registration we should look at access controls for these as this can be over looked and lead to a security risk, most application do not need access from any location and should be limited to only the require location or IP address to give greater access control.

Create Azure conditional access policy with named location

In this post we will be going through creating an Azure conditional access policy to restrict logging on to Azure / Office 365 from specific locations.

Conditional access policies are used to set requirements for accessing Azure or Office 365 resource, when using Named locations we can then set based on IP range, Trusted locations or Countries and regions.

Below diagram is from Microsoft on how conditionals access works.

What is Conditional Access in Azure Active Directory? | Microsoft Docs

Conceptual Conditional Access process flow

First step is to logon to Azure and go to Azure AD conditional access

Create a named location that will be used to restrict access.

Once in named location we can either create a location based on IP range or countries / regions. In this case we will be using a country.

Next we will create the conditional policy

Give the policy a name, we will be using a group to apply the policy but this could be change to all users or by directory role. (We can use select users or groups to apply the policy to a specific group as if applied to all users there could be a risk of locking yourself out of Azure portal)

Next we can apply the policy to specific apps or all apps. (If applying to all apps there will be a warning to not lock yourself out)

Next we set the conditions in this case we will be using location, I will be applying the policy to any location.

We can then set the named location as excluded in the policy so that it wont be applied if the access is coming from a country that is on the allowed named location.

This image has an empty alt attribute; its file name is image-26.png

Next we can set the access control settings, in this case we will block access but this could be changed to require MFA or other settings below.

Last step is to set session options to use conditional access app control, force sign-in frequency, Persistent browser session. We wont be setting any of the session settings as this policy is to block access.

There are three options report-only, on or off. To test the policy and check what will be blocked without running the risk of blocking real users set to report-only (This would be recommend for testing policy before rolling out to all users.)

Click create and the policy should now show and the state should be report-only.

To test if the policy is going to be applied we can check a users sign-ins, click on a signing log and go to Report-only, click on the three dots and show details.

This will show what part of the policy has been satisfied and not satisfied. Since the location has not been satisfied (as we are connecting from a excluded location) and the policy is not applied.

This image has an empty alt attribute; its file name is image-31.png

When the users tries to access from a country that is not in the allowed location, the result will be a failure and the users would be blocked from accessing.

Once testing has been completed and there are no unexpected blocks we can then go back to the conditional access policy and change the state to on, to apply the policy to users.

Now when a restricted user try’s to access an Azure / Office 365 resource from country not in the named location they will receive a message like the below.

Configure Azure ATP

In this post we are going to go through configuring Azure Advanced Threat Protection (Azure ATP), ATP is a cloud tool that can be used to detect security issue with on-premises active directory.

https://azure.microsoft.com/en-us/features/azure-advanced-threat-protection/#security

Azure ATP is available as part of Enterprise Mobility + Security 5 suite (EMS E5), and as a standalone license. You can acquire a license directly from the Microsoft 365 portal or through the Cloud Solution Partner (CSP) licensing model.

Azure ATP uses agent sensor installed on domain controllers or as standalone deployment that used port mirroring to monitor and analyzes user activities and information across your network.

We will be using the agents in this post since I can installing software on my DC if you have a policy that restrict agents installed on DC then you can use standalone deployment.

To configure Azure ATP first step it to setup an ATP workspace.

Go to https://portal.atp.azure.com/ and use your Azure AD logon ATP0 Once the workspace has been created we need to configure the on-premises connection account. ATP1 Put in details for the domain account, I used a service account that has read access to AD so that I could restricted the logon to the account to only be used for ATP ATP2 Once AD details are added next step is to download and install the sensor agent. Go to sensors and download the setup exe and copy the access key as this will be required during the install. ATP3 Copy the installer to the DC and run. ATP4 Select required language. ATP5 Deployment type will be sensor I am running on VMware and this will generate the below warning which will redirect to a guide to disable IPv4 TSO Offload. ATP6 This is where we need to put in the access key so that the sensor is associated to the correct workspace. ATP7 The agent should now start to install. ATP8 ATP9 Once the agent has install it can take some time for it to respond in Azure ATP. ATP10 Now the agent should start to notify of any suspicious activity that run’s like reconnaissance on SMB, DNS and other malicious reconnaissance.

We can also create HoneyToken account that will be dummy account that can be used to attracted attackers and will automatically generated an alert as they should never be used.

Go to Entity tags >Honeytoken and select the account that will be used as the Honeytoken ATP13 We can also add sensitive account and group, there are default groups/ accounts that are considered sensitive by default like Administrators, Domain admins, Enterprise admins…, a full list of these can be found in the below link.

https://docs.microsoft.com/en-us/azure-advanced-threat-protection/sensitive-accounts ATP14 If we now logon with the HoneyToken account it will then alert the activity by this account. ATP15 We can also run reports or schedule reports for schedule reports. To run a report go to the reporting blade and change the date to the range you want and click download. ATP16 Below is an example of the modification to sensitive groups. ATP17 To scheduled reports go to configuration and scheduled reports. ATP18 ATP19

Configure MFA For Azure Application Proxy

On the last post we setup Azure Application Proxy to allow internal application’s to be made available externally using AAD integration.

To add additional security to the setup we can enable MFA for the group or users that will be allowed access.

To enable MFA we need to create a conditional access policy and enable on the application proxy.

First step Login to Azure

Go to Azure Active Directory (AAD) AZ1

Go to Enterprise applications

AZ3

Select the Application proxy that will require MFA to be enabled

Once in the Application proxy go to Conditional Access and select New policy MFA1

Give the policy a meaningful name as it will appear in the overall Conditional Access policy’s aswell as on the Application. This will make it easier to manage if there are multiple policy’s.

Then select Users and groups and select the required users or group MFA2

Next select the cloud apps that will require MFA in this case it is the Exchange ECP application that was configured previously MFA3

We will not setup conditions but if this is required it can be set to only allow access from certain devices types, location & sign-in risk level.

Next go to Access controls and then Grant tab. Select Grant access, tick Require multi-factor authentication and Requires one of the selected controls MFA4

Last step is to Enable the policy

MFA7

Click create at the bottom of the policy

The policy should now show and have tick under Enabled MFA5

Now when we try to access the ECP Application proxy URL,

we should be prompted for MFA MFA8

and asked to register and verify a device to be use for MFA MFA9

It is a good idea to enable MFA for application as it gives an additional layer of security.

Azure Network Security Groups (NSG) to Restrict Management Access

For security reasons it is good practice to lock down access to Azure resources and not leave management ports open to the internet.

One way to restrict access to remote access protocols like RDS / SSH is to create a Network Security Groups (NSG) and apply this to either virtual machines or virtual network subnets.

To create a NSG

Logon on to the Azure portal: https://portal.azure.com

Once logged on go to All Services > Network security groups

If you have created VM’s or other resources there might already be some pre-existing NSG’s. NSG1

To create a new NSG click on Add

Give the NSG a name, assign subscription, resource group and location NSG2

Once the deployment has completed, click on the NSG this will bring up the configuration page.

First part is to configure the inbound security rules. NSG4

Go to settings > Inbound security rules

Once in Inbound security rules. To add a rule click add.

I want to restrict access to a specific Public IP for RDP access. Set the source as IP Addresses and add in the IP that will be allowed this can be a full range or a single IP depending on network subnet bit. I am only going to add one address so I used /32 below is an example 10.10.10.92/32.

I left source port ranges and destination as default as I don’t want to restrict these. Choose the required port in this case its 3389, set protocol to Any if you require both TCP/UDP I only need TCP. Set action to allow, set priority value and last step is give the port a name / description. NSG5

Below is the updated rule I have marked out my public IP NSG6

The outbound rule is set to allow any/any by default so if there is a requirement to lock down certain ports then create a new rule here to block the required ports.

Last step once all rule have been configured is to apply the NSG against resources. I am going to apply the policy to both my subnet and NIC’s assigned to both my test VM’s.

The policy should only need to be applied to either the subnet or VM’s, I just want to show how to apply to both. If you apply a rule to both VM and subnet they need to match or any port that is not allowed on both wont be work.

To assign to subnet: go to settings > Subnets NSG7

Select virtual network and subnet. NSG8 NSG9

To apply to each VM Nic: Go to settings > network interfaces

As I already had NSG’s associated from the VM deployments I need to re-associate to the new NSG.

Select the NSG of the VM you want to move and go to network interfaces NSG10 NSG11

Chose the required NSG

NSG12

Once applied I can now only access the VM’s from my own network.