Don’t try this at home (or how to enable Core Server Remote Management for AD FS GUI)

Posted on by Joosua Santasalo

I’ve been running AD FS on Core servers for some time now, mostly because I like the smaller footprint and centralized management experience.

The smaller footprint also guarantees:

  • That there are less consumed resources
  • That the there is less potential attack surface

But I want my GUI…

ADFSs

The lovely GUI Icon

Sometimes I’ve felt the temptation to just peek into AD FS GUI from remote administration host… only to remember that it’s not possible due to the fact that there is no RSAT for managing AD FS.

Yes this, this is crazy… I am doing it just for the kick of it

CoreSRVR

Scheme

This the part that you definitely shouldn’t do in production, or even in staging if you value your deployment – Nonetheless, I had the temptation to see if I can crack this nut:

  • Install and configure remote management host temporarily as AD FS slave node
  • Disable and stop AD FS service on the remote management node, because you won’t really be needing the service itself, you still need the installation to do management of the primary node

MGMT2

AD FS -> Nobody here, go away!

  • Do a crazy portproxy with NETSH to send port 1500 to primary AD FS node

MGMT3

TCP 1500 has now new destination

  • Enjoy remote management (and maybe some crazy side effects…)

MGMT

Welcome to AD FS management on Core Server!

#Disable and stop the AD FS service on management computer
Get-Service adfssrv | Set-Service -StartupType Disabled; Stop-Service adfssrv
#Do a crazy binding to port 1500
netsh interface portproxy add v4tov4 listenaddress=127.0.0.1 listenport=1500connectaddress=yourremotehost connectport=1500
#End

Speculation if this was really plausible approach:

Q: Would it just be smarter to have the primary node on GUI enabled server?

A: Pretty much yes

(in this crazy demonstrated approach the only difference, is that you don’t have to have AD FS service running on the remote management host)

Br, Joosua!

Advisories 1-2: Azure AD and Common WS-Trust MFA Bypass explained

Posted on by Joosua Santasalo

If there is single post I’ve been delaying for a good while, then it’s gotta be this one. This blog details a common oversight in MFA enforcement regarding federation implementations where MFA is invoked and required in the 3rd party IDP only. This oversight become effective when several by- design features, and implementation decisions align in ”wrong” way

Well how actionable it is? I’ve been exploiting this oversight in Red Teaming assignments, so in my experience its been really popular in deployments where the MFA is not checked on cloud side.

The reason of the delay is advisory 1. I’ve been discussing the ramifications with a major vendor providing Federation solutions about mitigating the configuration risks with WS-Trust when used in conjunction with Azure AD

Advisory 1 is related to how WS-Trust protocol is used in conjunction with Azure AD where clear text username and password are forwarded in TLS protected transport using the active endpoints to provide access for so-called non modern clients (Rich /Active endpoint consuming clients)

The scope is protocol implementation related, not vendor related! List of third 3rd party vendors providing WS-Federation/Trust support for Azure AD is long (some 15 last time I checked), so I am not highlighting any vendors here. I am assuming this affects most of the vendors implementing the WS-Trust with Azure AD without knowledge of the Azure AD OAuth2 Grant Types. Obviously I can’t say anything on any of the vendors behalf.

Microsoft’s AD FS can be also considered applicable in this context. Especially advisory 2

Advisory 2 is already documented, but not well communicated, and the existing documentation is AD FS specific. How is advisory 2 related to advisory 1? The existence of advisory 2 makes advisory 1 possible in the described scope.

Scope

Scope of this advisory are primarily customers who use WS /* -Protocols for federated domains in Azure AD, and utilize access policies to enforce and bypass MFA only in the IDP side. Not checking the status of MFA in Conditional Access, or using the -SupportsMFA option for the Microsoft MFA enabled users.

Its worth noting, that the attack can also pierce cloud MFA requirement if EAS clients can generate known bypass claims. There are unfortunately guides on web that advise doing this. In the latter scenario the attack penetrates two MFA layers, (Becomes even worse)

I won’t be providing any PoC’s, since all of the below advisories rely on by-design implementation, and can be replicated in few minutes, given you have understanding of both sides of the equation (Azure AD and WS-protocols)

Advisory 1 – Pivoting from legacy to modern auth

Background

UserName endpoints on WS-Trust are usually associated with legacy clients, thus they are often excluded from MFA. These endpoints are usually associated with legacy clients requesting access to Azure AD relying Party (Office 365 services often) – This is only true by association, as WS-Specification doesn’t define any difference between the so-called modern and legacy clients, the concept of difference only exists within Azure AD /Office 365 context, which the federation service is not aware of.

Accessing ”modern” API’s unprotected by the IDP

SAML assertion can extracted from the IDP, if the IDP is thinking it’s ActiveSync client. Once the token is received in response, it is then converted to OAuth2 Access Token with “saml1_1-bearer” OAuth2 Grant. This can be done by using many of the existing public clients.

Effectively the SAML token destined to legacy endpoint in Azure AD is converted to “Modern Auth” OAuth2 Access Token, and not being just used for legacy protocols anymore.

Root of this problem is related to the fact, that for SAML response from WS-Trust endpoint there is no ”validFor” context, which would dictate, that this request is valid for only let’s say https://graph.microsoft.com – not entire Azure AD Federation (Conditional Access solves this issue, as it binds access in cloud to different API’s)

In the picture: MFA is enabled for browser clients, and UserNameEndpoint is only allowed for ActiveSync clients without MFA /There lies the problem…

But wait, I have disabled legacy protocols in Office 365?

Disabling legacy protocols doesn’t help in this case, as the attacker is only consuming “modern API’s” (Microsoft OAuth2 parlance).

Attack in practice – On-prem MFA bypass

Example: The deployment only allows native ActiveSync to access WS-Trust’s Username bindings without MFA

What attacker does: Attacker uses ‘X-MS-Application’ header to spoof client to fetch SAML token using WS-Trust’s ’UserNameWSTrustBinding’.

The attacker then exchanges the SAML token in Azure AD to access the OAuth2 SPN (Audience). The exchange of the token is possible due to explicit support of “saml1_1-bearer” oAuth2 Grant Type, which cant be disabled on any of the ServicePrincipals in AzureAD

Documentation regarding the flow type

Link Microsoft identity platform and OAuth 2.0 SAML bearer assertion flow

Advisory 2 – Client Header Based Access Policies (Applies to WS-Federate as well)

This advisory is well documented, and is here only as reminder because it allows the first advisory to exist.

Don’t use user spoof-able headers as an basis for access policies at IDP’s controlling access to Azure AD.

Access Policies

Some vendors might implement additional checks here, but the protocol itself doesn’t dictate those to be done. This is basically where different products provide access policies to be enforced claims pipeline, to produce authorization result.

AD FS roles
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-the-claims-pipeline

Business policy claims?

Some of the claims presented in the following category should be only implemented to support business policies, not security policies, as advised in the Microsoft’s article

Click the text to follow link: Claims from this category should only be used to implement business policies and not as security policies to protect access to your network. It is possible for unauthorized clients to send headers with false information as a way to gain access.

Client Spoof-able headers (Examples from AD FS)

Multiple claims exist which clients can modify, or set. Below are the most common ones. Read the article if you’re curious to see the list of claims in AD FS

  • X-MS-FORWARDED-CLIENT-IP
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/access-control-policies-w2k12#x-ms-forwarded-client-ip
  • X-MS-CLIENT-APPLICATION
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/access-control-policies-w2k12#x-ms-client-application
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/access-control-policies-w2k12#scenario3

The documentation exist for AD FS 2012 R2, but it’s applicable to similar implementations including subsequent AD FS versions at least as up to 2016. Be sure to read the article as it lists very clear reasons,

Mitigations

  • a. Use Conditional Access to check whether MFA was actually performed at the 3rd party IDP for the requested API, or if there is valid reason to explicitly bypass the API
  • b. If you don’t have Conditional Access, don’t allow UserNameMixed to be used with spoof-able headers. Basically you wouldn’t allow native clients anymore for ActiveSync, as there isn’t safe header available for this decision to be made in the authorization pipeline

About spoof-able headers

  • X-MS-ADFS-Proxy-Client-IP seems to be based on the actual client IP with WAP, and should be more reliable, than the client writable header X-MS-FORWARDED-CLIENT-IP, which is advised to be used in many scenarios.
  • X-MS-FORWARDED-CLIENT-IP is often advised to be used in many guides because MS Exchange Online Connections pass multiple IP’s in headers, and thus the actual client IP hitting ADFS includes both Exchange and the Client IP’s in the header
    • as the documentation says, is best effort style header, and shouldn’t be used outside of business logic use scenarios
  • X-MS-CLIENT-APPLICATION here isn’t reliable way to inspect ActiveSync header for a legitimate client at the IDP’s side, The only way to allow it without MFA is Conditional Access

Also its worth noting that Basic Auth for Exchange, which is key reason why MFA bypasses on the WS-Trust endpoint are still used is going to be deprecated very soon

Azure AD – Add Custom claims for WS-Federation applications

Posted on by Joosua Santasalo

Disclaimer: The information in this weblog is provided “AS IS” with no warranties and confers no rights.

Most guides using Azure AD as IDP focus at OAuth and OAuth2/w OIDC flows for API access, and for enterprise SSO SAML. Not much endorsement for WS-Federation, and that’s understandable because the two previous options cover pretty much every scenario you would ideally have. But what if you have a app that is using explicitly WS-Federation? For example Microsoft OWIN based application?

There aren’t good support articles on using WS-Federation and custom claims in Azure AD when Azure AD is IDP, but WS-Federation is definitely supported when Azure AD is acting as IDP .

The only article I found covering custom claims and mentioning WS-Federation was the one I’ve used to write my previous article on preview of custom claims (how to get sAMAccountName into JWT tokens)

Since Azure AD App’s are largely protocol agnostic I figured that maybe the claims mappings are somewhat ambiguous also, just as long you understand how custom claims, and federations work

Guide to testing

The order here is important. While SAML endpoint is enabled by default in any Azure AD App, any specific settings, especially one’s for configuring Service Provider aren’t directly available in the ”non-SAML” app you create – Unless you play around with the App Registration Manifest. But there are other features that require spawning app initially as SAML app (For example using custom token sign-in cert, using token encryption and so on)

  • Configure new SAML federation at Azure AD
  • Add the custom claims for the federation
  • Set Single-Sign On mode to disabled
    • If you’re planning to use this in production, you have get the Metadata from SAML federation settings, I will do some further investigation later to update this blog
  • For metadata replace the metadata URL with tenant and AppID details

Test the federation.

I have handy NodeJS Express App I use pretty much for testing and debugging any authorization related stuff, with very simple purpose of catching different inbound calls.

About the code… The code itself is epitome of laziness, so I am too embarrassed to share it :)…

  • Invoke the call
    • Use AppID or any Identifier you’ve defined in the manifest
    • If you have multiple reply URL’s define the ’wreply’ param
https://login.microsoftonline.com/common/wsfed?
 wtrealm=1de8c976-fe00-4008-91d5-e5a2381d40a6
 &wctx=WSfedState
 &wa=wsignin1.0
  • Confirm the emitted claims
    • In this particular case its user.displayname +(join) user.dnsdomain
Typical WS-Federation body

There are many questions and details that I could add here, but since I am just fooling around with a feature, I am not devoting any more time until there is actual production need for such scenario.

Defender ATP and Live Response

Posted on by markuspitkaranta

I wrote a post earlier about the integration between Microsoft Defender ATP (MDATP), Intune and conditional access. In that post I mentioned some of the investigation capabilities within MDATP, but left one key feature unexplored. So I wanted to dedicate one short post solely on that feature – Live Response.

Live Response is a fairly new feature allowing real-time access to clients managed by MDATP. The feature is not enabled by default, so you’ll have to enable it in the advanced features blade (note, that your clients must also be running Windows 10 version 18323 or later). There is a separate setting also for allowing unsigned scripts to be executed via the console (this relates to the PowerShell script execution capability explored later in the post).

Once you’ve enabled the feature, you can see the Initiate Live Response Session option on the machine page:

Selecting the option launches a command line interface on the browser:

Note, that this console is not a normal Windows command prompt, but you’ll only have a limited number of commands available. You can find the full list of available commands here. There are a number of useful commands to inspect running processes, network connections, registry, etc. You can also inspect files and perform static analysis (in this case, the malicious Word document used in the previous blog post came out clean):

One useful command is getfile which allows you to download individual files from the remote client. If you have an analysis machine with proper tools in place, you can continue investigations there. You can also quarantine the file on the remote client by running remediate.

The quarantine event is logged in the Windows event log of the client:

Gimme PowerShell!

While the set of out-of-the-box commands provided by the Live Response console does provide a useful tool set, it clearly has its limitations. Luckily, it also supports running custom PowerShell scripts on the remote client. Now, this is not an interactive PowerShell session, so it may sound a bit cumbersome. But it does work surprisingly well.

For my testing, I’m just running a couple of commands, but I want it to run for some time so that I can have a look at the process itself.

What I need to do first is to upload the file to the library. I also have the option to add parameters to the script.

I can verify that the file has been added to the library by running library on the console. The same command also allows to remove files from the library.

To run the script, I use the run command:

After a minute or so, I can see the PowerShell process in Process Explorer, and it’s running as a child-process of SenseIR.exe (under local system account).

Once the script execution is finished, the output is printed on the console. It will also pipe the output into a file that you can easily download to your local machine using the getfile command (the output file also contains information about the PowerShell version, the process ID used, etc.).

All the commands executed via Live Response are retained in the command log. This keeps a nice audit trail of the activities performed (although, the commands within the PS scripts are not shown, just the name of the script and the output file):

Summary

This was a quick introduction to the MDATP Live Response feature. Overall, this is a necessary addition to the toolkit. While the commands available at the interactive console is fairly limited, it seems to tackle the most critical use cases. And with the ability to download files and run PS scripts, this can be a powerful tool for the incident response teams.

Azure Log Analytics – Permission Models

Posted on by Sami Lamppu

This blog post is all about Log Analytics workspace (later referred as LA) permission models which changed at May 2019. The options (at time of writing) for granting permissions are:

  • Grant access using Azure role-based access control (RBAC).
  • Grant access to the workspace using workspace permissions.
  • Grant access using a specific table in the workspace using Azure RBAC.

These new options gives more granular controls for granting permission to Log Analytics workspaces instead of old model. Anyway, I see still place for granting workspace permissions. It comes back to Log Analytics’ workspace design and organization needs. How operating teams, development teams, and security organization needs to access the performance and security-related events.

There are basically two approaches for Log Analytics design:

  • Centralized
  • Siloed

If you have chosen the centralized model then more granularity access controls might be needed and you can leverage more about new access control modes table (Resource centric RBAC & Table level RBAC).

Access control mode

The new access model is automatically configured to all workspaces created after March 2019.

How to check which access model is in use?

Navigate to Azure Log Analytics and overview page where you can find ”access control mode” options for the workspace.

  • If you are using legacy model ”Access Control mode = require workspace permissions”
  • If new model is in place ”Access Control mode = Use resource or workspace permissions”

With PowerShell

  • If output is true – Log Analytics is using new access model
  • If output is false or null – Log Analytics is using legacy model
Get-AzResource -ResourceType Microsoft.OperationalInsights/workspaces -ExpandProperties | foreach {$_.Name + ": " + $_.Properties.features.enableLogAccessUsingOnlyResourcePermissions}

How to change access model?

Access model can be changed directory from resource properties and verified from Activity log.

If Powershell is the favorite tool for changes here you go (code from docs.microsoft.com)

$WSName = "my-workspace"
$Workspace = Get-AzResource -Name $WSName -ExpandProperties
if ($Workspace.Properties.features.enableLogAccessUsingOnlyResourcePermissions -eq $null)
    { $Workspace.Properties.features | Add-Member enableLogAccessUsingOnlyResourcePermissions $true -Force }
else
    { $Workspace.Properties.features.enableLogAccessUsingOnlyResourcePermissions = $true }
Set-AzResource -ResourceId $Workspace.ResourceId -Properties $Workspace.Properties -Force

New Model In Action

The scenario

Siloed Log Analytics workspace design is in use and operational team members needs to maintain Virtual Machines. In practical person needs to read Virtual Machine metrics and performance data from LA.

If new access model is in use members of the team can access the needed logs directly from the resource blade. They cannot see the LA at all because they don’t have global read access to the resource. If user browses to Azure Monitor the user can see logs he/she has access to.

When log search is opened from a resource menu, the search is automatically scoped to that resource and resource-centric queries are used. This means that if users have access to a resource, they’ll be able to access their logs.

Built-in Roles (from docs.microsoft.com)

Azure has two built-in user roles for Log Analytics workspaces:

  • Log Analytics Reader
  • Log Analytics Contributor

Members of the Log Analytics Reader role can:

  • View and search all monitoring data
  • View monitoring settings, including viewing the configuration of Azure diagnostics on all Azure resources.

Nothing prevents from using built-in roles but keep in mind that these are top level permissions. If user has Log Analytics reader permission global read permission with the standard Reader or Contributor roles that include the */read action, it will override the per-table access control and give them access to all log data.

Table Level Access

More granular controls can be achieved with Table level access in case its needed. If centralized Log Analytics model is chosen scenario it might be necessary to grant permissions to different teams to read data from LA tables. This can be achieved with Table level RBAC permissions.

With table level RBAC you can grant permissions only to needed LA tables depending on your needs.

Considerations

If a user has global read permission (Reader or Contributor roles) that include the */read action, it will override the per-table access control and give them access to all log data.

If a user has access to specific LA table but no other permissions, they would be able to access log data through the API but not from the Azure portal.

Summary

Most cases I have worked with, multi-homing Log Analytics design has been used and workspace centric model is enough to satisfy the needs. If centralized model (as few LA’s as possible) would be in use new access model gives more granularity.

Identity and Access in Security Center?

Posted on by Joosua Santasalo

For those who are missing the once great Identity and Access solution in ASC, worry no more – It’s available as an Sentinel dashboard, which you can simply add from the dashboards (Given that you’re collecting the data)

HoneyPot and Sentinel is a nice combination
Dashboards in Sentinel
KB https://docs.microsoft.com/en-us/azure/security-center/security-center-features-retirement-july2019#menu_classicidentity 
Whats coming next? https://docs.microsoft.com/en-us/azure/azure-monitor/app/usage-workbooks