Continuing from last post with the same topic but now from the negative side of things. What could go wrong if you don’t do it right. This post will assume that you are still having on-premises AD with ADCS and ADFS enabled but you are moving towards the cloud.
Table of Contents
Restrict access to your Tier0
Making walls between the servers should always be the case. In on-premise environment and in the cloud. When you have those users in the cloud, you will probably use Azure AD as your IdP. Azure AD doesn’t have similar DC to protect, so that surface is covered but there is a lot of steps involved on making it secure as possible.
In on-premises by using at least network segmentation and denying services to interact with outside world and in the cloud similar approach by Disabling public access and using Isolation with RBAC-based access controls when possible.
Here is an excellent list of commands and tools to try it out ourself, use them only for learning not harming.
Enable PTA (Pass-Through Authentication)
This could be in both segments, do’s or the don’ts. PTA is an excellent solution for those needing it to establish Seamless SSO or to push authentication from ADFS to Azure. I would advise not to enable it before you made sure that isolation is enforced in your infrastructure, read below article and see for your self.
And how to attack the flaws from Nestori’s own blog
The vulnerabilities discovered by our team allows threat actors to gain persistent and undetected access to the target Azure AD tenant.
In this blog post, I’ll show how the attack…
PTA operates by installing up to 40 agents per tenant on on-premise servers. When a user logs in to a service using the Azure AD identity platform, Azure AD encrypts the user’s credentials and sends an authentication request to one of the agents. The agent then decrypts the credentials, logs in using them, and gives the results to the user.
How PTA authentication works
Example on the attack workflow
More on the findings
Microsoft has also replied to this flaw on 20th of September
Link to hardening instructions
Make your ADCS deployments secure
If you are having Domain controllers and Federation Services, there is a big change you will also have Certificate services to supplement your environment with your own certificates.
In August this year, there was an CVE that had score if 8.8 from 10
Read more about the vulnerability from Semperis.
Do not Install agents on Domain controllers
This should make sense, don’t give possibilities to attack your DC’s. They have all the information from your domain.
Here are some excellent point from Sander Berkouwer on why it isn’t an excellent idea.
Do not Use high-privileged admin credentials on services
This is why there’s the Hybrid Identity Administrator role, switch to it to avoid privilege escalation with any of your services.
For the AD-based services use GMSA accounts when possible.
What could happen if you don’t use them?
Have visibility to your servers
Defender for Servers will give you the visibility that is needed. And you can onboard to your on-premises server in example with Azure ARC
What kind of alerts it gives the visibility?
There is two levels for Defender for Servers, P1 and P2
- Plan 1
- MDE Integration: Plan 1 integrates with Microsoft Defender for Endpoint Plan 2 to provide a full endpoint detection and response (EDR) solution for machines running a range of operating systems. Defender for Endpoint features include:
- Reducing the attack surface for machines.
- Providing antivirus capabilities.
- Threat management, including threat hunting, detection, analytics, and automated investigation and response.
- Provisioning: Automatically provisions the Defender for Endpoint sensor on every supported machine that’s connected to Defender for Cloud.
- Licensing: Charges Defender for Endpoint licenses per hour instead of per seat, lowering costs by protecting virtual machines only when they are in use.
- MDE Integration: Plan 1 integrates with Microsoft Defender for Endpoint Plan 2 to provide a full endpoint detection and response (EDR) solution for machines running a range of operating systems. Defender for Endpoint features include:
- Plan 2
- Plan 1: Includes everything in Defender for Servers Plan 1.
- Additional features: All other enhanced Defender for Servers security features.
And here is the refence table for the alerts it finds
Don’t Store your passwords plain-text
If you need to use password in your service, be sure to keep them safe.
GitHub
How to find exposed GitHub credentials?
Well, it’s easier than you think, there is a lot different solutions for this job, you can use them to understand the risks but so can those attackers.
PowerShell
Instead use System.Management.Automation.PSCredential to store your credentials in a file in PowerShell.
Azure Key vault
In Azure, use key vault
Restrict Storage accounts from public access
Keep using SAS-policies and don’t disable public access, there is a lot storage accounts still open out there.
See more from Cyberark on the exposed accounts
And their BlobHunter to check your Storage accounts.
Finally the recommendations from Microsoft for Blog storages
To make it closed completely, you can use Private Endpoints with Managed Identities and let the services that need access, have access.
Multi-factor authentication scenarios
Don’t have any users with out MFA
To solve, you can enable Nudge for Microsoft authenticator
Or enable MFA with Conditional access policies.
Use complex authentication methods
Always show your users where they login to and from where they are making the login from. Better yet, use Number matching feature when using Microsoft Authenticator.
Why to use them?
Well one reason could be MFA fatigue attacks.
Multi-factor authentication is excellent security feature, in the most simplified scenario you need your Username and Password + some form of proof that you are really doing the sign-in to a service.
But if you go where the fence is the lowest or implemented MFA ages ago and didn’t take care of the methods it’s uses after that. You could be facing the risks of MFA fatigue.
MFA fatigue means that after attacker will phish your credentials and once they do, they will sign-in to a service of their wishing and bombard you with endless swarm of MFA request until you accept the request.
To make the sign-in’s visible for your users please enable these. Then educate your users, it’s makes the deployment a lot longer but it’s worth it, I promise you.
Positive ending
The get a positive ending to this story. You can always rely on Azure Active Directory security operations guide for a helping hand with your secure Identity designs.
Hackers don’t break in – they log in.
RSS - Posts