High level overview of Azure Policies/Initiatives

This is a quick introduction and testament to my experience using Azure Policy within the Azure portal.

What problems do Azure Policies solve for our organizations security?

Azure policies allow us to future proof and audit our Azure resources for vulnerable configurations. There are a few parameters/effects that allow us to either “audit”or “deny” configurations we don’t want taking place unknowingly or maliciously. Additionally we can also leave an effect in “disabled” mode.

For instance we can use a “deny” effect with the policy definition called “Storage account public access should be disallowed” and this stops anyone from creating a blob storage account with public access BUT it will not remediate already configured resources, that is another matter.

How/when/where can you apply the policies?

Use Initiatives to group multiple definitions or directly apply a single definition.

Additionally you can apply policies via Defender for Cloud’s “Regulatory Compliance” blade which for the most part are just canned initiatives with various definitions pertaining to a compliance standard ie; SOC2.

My strategy to using the Compliance based standard Initiatives is to deploy those you care about across your subscriptions/Management groups/Tenant since they deploy in an audit mode(Although you should confirm this by checking all the definitions). This will give you an idea about how vulnerable your environment is based on the standard. From this point to deny resources I’ve found the best method is use your own custom initiative via the Azure Policy blade because this will avoid confusing parameters within the standards based initiatives which are set to target on a larger scope. With your custom initiatives you lower the scope to say one test subscription. This will reduce the impact of a policy that could break something unintentionally.

Additionally using your own initiatives can slowly incorporate definitions for controls you’d like to roll out at your convenience and keep things ordered and clutter free.

How can you remediate vulnerable resources?

This is possible with definitions that use that allow for the “DeployifNotExists” effect value. The initiative itself will create a system identity that can be used to apply the changes across resources.

This is just an overview to better understand the options available from a high level perspective. Before deploying any changes as always a test subscription or resource group should be used to verify things will work as expected.

SpringShell Detection/Remediation

How do we best detect the SpringShell vulnerabilty(CVE-2022-22965)?

Microsoft created a nice blog on the vulnerability here listing remediations and detection methods: https://www.microsoft.com/security/blog/2022/04/04/springshell-rce-vulnerability-guidance-for-protecting-against-and-detecting-cve-2022-22965/

Using this information and those of your Vulnerabiilty scanners we can start to discover legitimately vulnerable systems. There’s unfortunately a lot of false positives and so we might employ several tools which I’ll list here.

  1. To scan a suspect server for known suspect files there is this tool from qualys that scans Windows machines https://github.com/Qualys/spring4scanwin
  2. Nmap NSE script https://github.com/gpiechnik2/nmap-spring4shell
  3. Powershell script I created. It takes a csv file with an “Address” field that includes IP addresses to scan, using the known detection method as described in the MS report and others:
curl host:port/path?class.module.classLoader.URLs%5B0%5D=0

I use this scan external hosts for ports 80 and 443. You can modify this for your own use looking for a 400 http response. Also make sure to modify the export path so you can have a nice report of the hosts and their results.

Remediation/Mitigation

If you detect the vulnerable hosts you will need to apply patches for the spring framework or work with vendors to make sure apps are upgraded.

Spring Framework fixed releases:

  • 5.3.18+
  • 5.2.20+

On-Prem AD vs AzureAD Password policy usage

For hybrid environments if you need to find out what password policy is officially being used there are few guidelines to keep abreast of.

If your user accounts are synchronized using Azure AD connect they will be using the on-premises AD policy

Use this command to check the policy from the on-prem AD
Get-ADDefaultDomainPasswordPolicy -Identity <YourDomain.com>

AzureAD policies apply when user accounts that are created and managed directly in Azure AD.

The following information is pulled from this guide directly from MS.

AzureAD Password Policies
PropertyRequirements
Characters allowedA – Z a – z 0 – 9 @ # $ % ^ & * – _ ! + = [ ] { } | \ : ‘ , . ? / ` ~ ” ( ) ; blank space
Characters not allowedUnicode characters.
Password restrictionsA minimum of 8 characters and a maximum of 256 characters. Requires three out of four of the following: Lowercase characters. Uppercase characters. Numbers (0-9). Symbols (see the previous password restrictions).
Password expiry duration (Maximum password age)Default value: 90 days. The value is configurable by using the Set-MsolPasswordPolicy cmdlet from the Azure Active Directory Module for Windows PowerShell.
Password expiry notification (When users are notified of password expiration)Default value: 14 days (before password expires). The value is configurable by using the Set-MsolPasswordPolicy cmdlet.
Password expiry (Let passwords never expire)Default value: false (indicates that password’s have an expiration date). The value can be configured for individual user accounts by using the Set-MsolUser cmdlet.
Password change historyThe last password can’t be used again when the user changes a password.
Password reset historyThe last password can be used again when the user resets a forgotten password.
Account lockoutAfter 10 unsuccessful sign-in attempts with the wrong password, the user is locked out for one minute. Further incorrect sign-in attempts lock out the user for increasing durations of time. Smart lockout [docs.microsoft.com] tracks the last three bad password hashes to avoid incrementing the lockout counter for the same password. If someone enters the same bad password multiple times, this behavior will not cause the account to lock out.

It’s important to note that some settings can’t be modified if your user accounts are exclusively managed within AzureAD.

App-only Authentication for Exchange Online w/Powershell

A modern authentication alternative to using service accounts in your Azure Active directory environment that may otherwise have to bypass basic authentication protections in order to perform unattended scripting operations.

Pros:

  • Not needing to bypass the Modern Authentication enforcement in your Conditional access policies or MS365 settings.

Cons:

  • Anyone with the certificate and application information could possibly authenticate to your exchange environment so the certificate should be highly guarded.

Checking if you have accounts on different Authentication profiles that are bypassing the security defaults. Powershell commands:

# Connect to Exchange 
Import-Module -Name ExchangeOnlineManagement
Connect-ExchangeOnline

# Get all policies
Get-AuthenticationPolicy | Format-Table -Auto Name

# Get a particular users policy
 get-user -Identity service_acct | select AuthenticationPolicy

 # Set a particular users policy
  Set-User -Identity service_acct -AuthenticationPolicy "Block Basic Auth"

DISCLAIMER: Please follow your own security protocols. This is just a demo.

Demo video on setting up an Azure Automation runbook to use a registered application.

This starts from building the automation account to finally executing a script that will connect to Exchange Online and perform commands.

https://youtu.be/AMiVCqUfkb0
  • REF: https://docs.microsoft.com/en-us/powershell/exchange/app-only-auth-powershell-v2?view=exchange-ps#set-up-app-only-authentication
  • REF: https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/disable-basic-authentication-in-exchange-online#create-and-apply-authentication-policies

Finding a Microsoft KB in a Cumulative Update

• Windows patches linked to Knowledge Base articles or MS bulletins roll up and become unavailable as a hot-fix/single update file and go into a cumulative update. This can pose an issue when your Deployment system like SCCM or BigFix no longer have the update to push to machines since they follow Microsoft’s patch catalog for which old updates get rolled up and removed. This can become an issue when your trying to force patch machines that may become vulnerable to malware that the patch can fix and you can’t readily find what patch to use since the KB originally able to fix a vulnerability is now no longer available for single update.
• Although keeping all machines up to date is best practice it can become an issue when legacy applications begin to break and when if settings allow users to delay updates it’s likely a population of un-patched machines will arise.
• Windows 10 patches are normally fixed in new versions so updating works but if you want to see if you can find a KB or MSXX-xxxx bulletin you can search the known cumulative updates
Find your Security Vulnerability Builletin:
MS17-010 – google search and go to the MS site https://docs.microsoft.com/en-us/security-updates/securitybulletins/2017/ms17-010 Follow it to the KB used to install on Win10 1511 x64 machines https://support.microsoft.com/eu-es/help/4013389/title you’ll find the install instructions provide KB4013198 as actual file needed.
Search for this in the MS update catalog. But you’ll have to do it by Cumulative update since this is older and rolled up.
• Go to: http://www.catalog.update.microsoft.com
o Search for “windows 10 version 1511” filter by last updated
o Look for latest cumulative update for the version and arch.
o Search for the KB installer “KB4013198” under the “Update Details” > “Package Details” using ctrl+F for quick finds


Finding the Cumulative update in BigFix so you can install it on machines.
Go to:

https://YourBesServer.domain.com > log in > Apps > Patch > use the KB patch name for the Cumulative update you found “KB4093109”


From here you can see that it is available and you can deploy it to vulnerable machines to patch for the SMB exploits.