Active Directory Security Cheat Sheet

Ok you need to do some AD Security Auditing or Security Testing/Exploitation, great. Let’s look at some of the common misconfigurations and some tools to help you, a list of things will obviously not be the answer, you will need a method and process to go through from recon/enumeration through to exploitation and impact (effects), but that’s what google is for (and CTFs/Labs)! This post is just me jotting down some notes, hopefully they help defenders think about improving their posture.

Vulnerabilities

Exchange Emergency Mitigation (EM) service

Yesterday I created a honeypot running Exchange 2019 in the lab. I configured very little and setup a test rule as per the MS blog to stop the SSRF from the “Autodiscover” endpoint to the Powershell function call. I put a custom response with some humour (coz why not!) but I disabled the rule:

This rule was placed in the Autodiscover virtual directory which in Exchange by default is here:

C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\autodiscover\web.config

My custom rule:

<rules>

</conditions>

</rule>

</rules>

</rewrite>

This morning I checked the Honeypot, and I found the following:

Graphical user interface, text, application, email

Description automatically generated

This rule is hosted in:

C:\inetpub\wwwroot\web.config

<rules>

</conditions>

</rule>

</rules>

</rewrite>

As you can see this was modified at 03:21 01/10/2022

Graphical user interface, text, application

Description automatically generated

This comes from:

Exchange Emergency Mitigation Service (Exchange EM Service) | Microsoft Learn

“Exchange Emergency Mitigation (EM) service”

Text

Description automatically generated

You can check if this is enabled by running the following PowerShell:

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn; 

Get-OrganizationConfig | Select-Object MitigationsEnabled

So here we can see that with this enabled, the Exchange server will download and deploy the HTTP re-write rules automatically (if the server has the required version/config etc.)

You can enable or disable it with the following:

Set-OrganizationConfig -MitigationsEnabled $true
Set-OrganizationConfig -MitigationsEnabled $false

You can check this feature works using the following (modify path as required for relevent exchange version)

. "C:\Program Files\Microsoft\Exchange Server\V15\Scripts\Test-MitigationServiceConnectivity.ps1"

Check the MS docs and check your Exchange Server version to see if you have this feature etc.

GCM exsetup |%{$_.Fileversioninfo}

You learn something new everyday!

Vulnerabilities

Exploitation of Microsoft Exchange Servers seen in the wild

LATEST UPDATE (04/10/2022)

The latest guidance from Microsoft (released on the 02/10/2022) says to disable administrators from being able to execute remote PowerShell via the exchange PowerShell web endpoint /PowerShell

Customer Guidance for Reported Zero-day Vulnerabilities in Microsoft Exchange Server – Microsoft Security Response Center

October 2, 2022 updates:

Added to the Mitigations section: we strongly recommend Exchange Server customers to disable remote PowerShell access for non-admin users in your organization. Guidance on how to do this for single user or multiple users is here.
Updated Detection section to refer to Analyzing attacks using the Exchange vulnerabilities CVE-2022-41040 and CVE-2022-41082.

Additional mitigations

Remove exchange web services from the internet (there are reasons to do and not do this)
Restrict hybrid servers to allow OWA to O365 only
Leverage dynamic blocking
Greynoise has a list of IPs known here: https://api.greynoise.io/v3/tags/8bf9b766-bf0f-452f-80bf-1d0903847793/ips?format=txt&token=rYZCpLOTf6UnUbBoUpF3Q

Obviously bear in mind this needs auth! but also auth isn’t always that hard..

Microsoft Research have just released (0825 30/09/2022) this: Customer Guidance for Reported Zero-day Vulnerabilities in Microsoft Exchange Server – Microsoft Security Response Center

Microsoft have released a Exchange Server Emergency Mitigation (EMS) which includes URL re-write rules to HELP mitigate this (but likely don’t eliminate all risks due to potential bypasses)

New security feature in September 2021 Cumulative Update for Exchange Server – Microsoft Tech Community

Current Scenario (Updated 11:27 30/09/2022)

Likely “Zero day” exploit in the wild being used to attack exchange servers via a simmilar endpoint to ProxyShell. A mitigation is to apply URL rewrite rules, or to disconect the service internet from untrsuted networks until a patch is available. The Exploit is reported to required AUTHENTICATION, which may significantly limit the volume of exploitation (however credentials are only a phish away). It’s also reported the exploitation in the wild used /Powershell after exploiting the autodiscover endpoint.

Overview (orginal post area)

Yesterday it was reported there was a “new” zero day vulnerability being exploited in the wild. But there appears to be some confusion and a lack of speciifc evidence to showcase the vulnerability being “new” or simply being a differnt exploit path/approach for an existing CVE (e.g. ProxyShell).

The situation from my pov (at time of writing) is still unclear. It would be odd to not advise people ensure they are running the latest supported Exchange CU and Security update release (check both!) – if the exploits are 0-day (which it looks like they are) you will need to also patch when MS release a patch!

You may also wish to: use a WAF/Web Platform (IIS or reverse proxy) to restrict access to potentially vulnreable strings/endpoints.
You should probably review vendor guidance (Microsoft)
You may want to review your exchange servers for indicators of compromise (IOCs)
Check log files for activity, Check for dropped webshells, Check process logs (if you have them!)
Microsoft Recomends using the URL re-write module see (Customer Guidance for Reported Zero-day Vulnerabilities in Microsoft Exchange Server – Microsoft Security Response Center

New Microsoft Exchange zero-days actively exploited in attacks (bleepingcomputer.com)

Upcoming | Zero Day Initiative

Warning: New attack campaign utilized a new 0-day RCE vulnerability on Microsoft Exchange Server | Blog | GTSC – Cung cấp các dịch vụ bảo mật toàn diện (gteltsc.vn)

https://www.shodan.io/search/report?query=http.title%3Aoutlook+exchange

There are 201,995 Exchange Servers with Outlook Web Access Exposed (According to Shodan)

cve-2021-31206 (19,311)
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-31206

9.5% of the worlds Exchange attack surface is vulnerable to CVE-2021-31206

PROXYSHELL

https://www.cisa.gov/uscert/ncas/current-activity/2021/08/21/urgent-protect-against-active-exploitation-proxyshell

CVE-2021-34473 (4388)
CVE-2021-34523 (4388)
CVE-2021-31207 (4388)

2.1% of the worlds Exchange attack surface is vulnerable to ProxyShell CVEs (above) (based on the shodan data)

https://learn.microsoft.com/en-us/exchange/new-features/updates?view=exchserver-2019

Exchange CU Versions

IMPORTANT: Your NEED the LATEST Cummualative Update (CU) and the LATEST Security Updates (SU) for Exchange (and given this is a likely zero day scenario you will need to patch again when the latest patches are released from MS)

https://learn.microsoft.com/en-us/exchange/new-features/updates?view=exchserver-2019

Exchange 2019 CU12 Aug22SU

https://support.microsoft.com/en-gb/topic/description-of-the-security-update-for-microsoft-exchange-server-2019-and-2016-august-9-2022-kb5015322-86c06afb-97df-4d8f-af88-818419db8481

Exchange 2016 CU 23 Aug22SU

https://learn.microsoft.com/en-gb/Exchange/new-features/build-numbers-and-release-dates?view=exchserver-2019

https://support.microsoft.com/en-gb/topic/description-of-the-security-update-for-microsoft-exchange-server-2019-and-2016-august-9-2022-kb5015322-86c06afb-97df-4d8f-af88-818419db8481

Exchange Server 2013 CU23 Aug22SU

https://support.microsoft.com/en-gb/topic/description-of-the-security-update-for-microsoft-exchange-server-2013-august-9-2022-kb5015321-96a47598-09b7-43eb-98bb-76fdf906f265

https://www.microsoft.com/en-us/download/confirmation.aspx?id=58392

Summary

The situation appears to be evolving, as always security vulnerabilities and in the wild exploitations can be a fast moving landscape, internet facing systems need suitable and adequate protections, that doesn’t include just exposing IIS on TCP 443 and walking away. It requires capabilities such as:

WAF/CDN
DoS/DDoS Defence Considerations
Logging and Alerting
Staff to monitor and respond
Secure Configurations
Antirivurs/Antimalware
Segemntation
Endpoint Detection and Response Capabilities (EDR)
Incident Response Planning
Threat Intelligence

and many more things!

This post is a fast publish and may contain errors and/or the situation may change. I’ll try and keep it updated.

Defense

Exchange Emergency Mitigation Service with new CU Update

This is a big thing in the Exchange world from my POV! I believe this is dropping sometime today (28th September!)

History

Exchange OWA, ECP etc. are exposed online not only for mailbox access, calendar sharing but also are a requirement for hybrid mode sync capabilities.

Vulnerabilities in Exchange this year (ProxyLogon/ProxyShell) have shown how problematic an attack surface this is. The good news is, Microsoft have created a feature for Exchange to help mitigate these attacks in the future via the EM Service!

Defense

Modern Workspace: PowerShell OAuth Error

Create PowerShell Session is failed using OAuth

When connecting to Exchange online (there was a reason I needed to do this) I had the following error:

I did some googling that luckily someone has already posted how to fix this:

https://www.vansurksum.com/2021/03/11/create-powershell-session-is-failed-using-oauth-when-using-the-exchange-online-v2-powershell-module/

It turns out WINRM’s ability to use BASIC client authentication is disabled as part of the standard Windows 10 hardening baseline deployed via Intune.

To fix these we need to re-enable BASIC client side WINRM authentication. Read more “Modern Workspace: PowerShell OAuth Error” →

Defense

Password Spraying/Credential Stuffing OWA with Metasploit Framework

Ok so this is not very ‘1337’ but it will get the job done (and that is what is important, no one cares how they get pw3d they just care they were). If you really wanted, you could hand craft this in python of another language or use another tool (script etc.)

Do start with we are going to need a username list and a password list (as well as a target IP or DNS name). This could be:

Obtained via OSINT
Obtained via stolen/breached credentials
Dictionary Created
Password Lists could be used/generated etc.

We also need to have considerations for account lockouts. If we are doing a penetration test, then we will have to likely avoid DoS. If we are doing a ‘RED TEAM’ or adversary simulation, then we will want to avoid being noisy and getting caught. (If we are doing monitoring and detection testing you probably want to be quiet and noisy ala control testing). Read more “Password Spraying/Credential Stuffing OWA with Metasploit Framework” →

Defense

Thoughts on IOCs for Exchange Hafnium/ProxyLogon

Intro

This isn’t a rant, far from it but I’ve been working on this for over a week now and some major questions are sprining to mind with regard to how the IOCs and detection details released may have hindered response efforts. These vulnerabilities were known about since at least December 2020, there were months to get detection intel and scripts/tools ready for people (that’s if you don’t question why did it take so long). So I’ve put some of my thoughts down here on some of the challenges with the IoCs initially released and the detection tools etc. I’ll probably update this later but wanted to publish it before it becomes virtual dust! Read more “Thoughts on IOCs for Exchange Hafnium/ProxyLogon” →

Defense

Hafnium / Exchange Marauder High Level IR Help

Ok so John and I have been working on this for a while. We have been working with both customers and industry profesionals and there’s a common theme. Understranding the events from this incident are quite challenging because:

We don’t have sample log output for known bad traffic
The vulns can be used for data theft and/or backdoors (and further actions on target)

Getting guidance out so far on this has been challenging becuase:

There is not a public full kill chain POC to do comaprisons to (i’m ok with that)
We don’t have a pw3d server that has all the indicators from all the routes on

So to try and help people we have made a diagram which we will update as we go.

Essentially you need to perform a weighted analysis to understand if:

You had recon only
You had some SSRF
YOu had SSRF that led to data theft
You had a webshell planted

Defense

Checking for Hafnium or other groups impact from Exchange…

Introduction

On March 2^nd, 2021 at ~6pm GMT Microsoft released an out of band update to all version of exchange from 2010 through to 2019. This was in response to a range of vulnerabilities which had been abused (a 0-day) by a threat actor (coined by MS as HAFNIUM).

For more info from MS please see the following:

https://www.microsoft.com/security/blog/2021/03/02/hafnium-targeting-exchange-servers/

Key CVEs

Key CVES include:

CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, and CVE-2021-27065. Read more “Checking for Hafnium or other groups impact from Exchange Abuse” →

Defense

Exchange 2010 Rapid Analysis for IOCs

Purpose

With the Hafnium “incidents” and Exchange vulnerabilities I wanted to help people with ruling in or out compromise of their Exchange 2010 environments. At the time of writing, I don’t believe that Hafnium affected Exchange 2010 via the reported kill chain, I believe that BEC would be required but this is a theory, my general view is Exchange 2010 might be ‘safe’ from this kill chain. This is due to the initial stage leveraging CVE-2021-26855 which is an SSRF vulnerability which only affectes the new architecture (2013+). However, this is an unsupported platform so I wanted to help with some baselines and talk about how I would approach ruling compromise in or out (at least with regards to these vulnerabilities). The key impact area is a web shell. I’ve made some baselines to help people look for abnormalities.

Disclaimer

This document was made with limited time and without full Whitebox access to source code and engineering expertise. The areas we are checking for IOCs appear to make logical sense, but the OS and APP (Exchange 2010) are unsupported, and we are not the vendor. So, I am afraid your hunting responsibility is on you, this is just my opinions and thoughts from a very fast analysis. Use at your own risk. Read more “Exchange 2010 Rapid Analysis for IOCs” →

LATEST UPDATE (04/10/2022)

Additional mitigations

Current Scenario (Updated 11:27 30/09/2022)

Overview (orginal post area)

Global Attack Surface

PROXYSHELL

Exchange CU Versions

IMPORTANT: Your NEED the LATEST Cummualative Update (CU) and the LATEST Security Updates (SU) for Exchange (and given this is a likely zero day scenario you will need to patch again when the latest patches are released from MS)

Exchange 2019 CU12 Aug22SU

Exchange 2016 CU 23 Aug22SU

Exchange Server 2013 CU23 Aug22SU

Summary

History

Create PowerShell Session is failed using OAuth

Intro

Introduction

Key CVEs

Purpose

Disclaimer