Just when we thought we had got our heads around Role Based Access Control (RBAC) along comes Attribute-Based Access Control (ABAC). Great. ABAC is a flexible and granular access control model that evaluates attributes—characteristics associated with users, resources, and the environment—when determining whether access should be granted. Unlike Role-Based Access Control (RBAC), which relies on predefined roles with fixed permissions, ABAC allows organisations to define access policies based on dynamic combinations of attributes.
In the Azure world, ABAC is supported through the use of custom Azure roles combined with resource and request context attributes. For example, you could define a custom role that allows access to storage blobs only when the user’s department attribute matches the resource’s “department” tag. A real-world policy might say: “Grant read access to blobs if user.department equals resource.department.” This allows a single role definition to be reused across departments without hardcoding resource-level access rules.
This model is particularly useful for large-scale environments where traditional RBAC roles become unmanageable due to the explosion of permutations. ABAC helps reduce role sprawl while still enforcing strict, attribute-driven access boundaries.
For years, NTLM has been the go-to protocol for attackers abusing authentication in traditional Active Directory environments. From relay attacks to password cracking and token manipulation, NTLM has seen its fair share of abuse. But as organisations shift to Microsoft’s cloud-first world—namely Azure AD—the battleground is changing.
So, the question being:Are Azure Access and Refresh Tokens becoming the new NTLM for attackers?
Lets take a look:
Access & Refresh Tokens – A Quick Primer
In Azure AD, authentication is no longer just about usernames and passwords. Instead, it’s about tokens. When a user successfully authenticates, Azure issues two important artefacts:
Access Tokens: Short-lived (typically 1 hour) tokens used to authenticate to specific services (e.g., Graph API, Azure Resource Manager).
Refresh Tokens: Longer-lived tokens (typically 90 days with sliding expiration) that can be used to obtain new access tokens without prompting the user to re-authenticate.
This modern authentication model is part of the OAuth2 and OpenID Connect stack and is deeply embedded in Microsoft’s cloud identity framework.
But here’s the catch: these tokens are just bearer tokens. Possess them, and you can use them. No passwords required.
What Makes Them Similar to NTLM?
Just like NTLM hashes, Azure tokens:
Can be stolen and reused.
Are used to authenticate without user interaction.
Can be passed between systems or APIs.
Are vulnerable to similar relay-style attacks in some flows (e.g., Device Code).
They’re not cryptographically bound to the user’s device (unless using newer Proof-of-Possession (PoP) tokens, which aren’t widely enforced, these essentially bind to a client device), which makes access and refresh tokens ripe for abuse in the same way as NTLM hashes once were.
Tooling: Weaponising the Token Landscape
Red Teamers and Pentesters now have a growing arsenal of tools to enumerate, manipulate, and reuse tokens within Azure AD environments. I have been recently using the below coupled with native tooling such as MS Graph and Azure Resource Manager where we can directly pass in the token as authentication:
TokenTactics – A modular toolkit for interacting with and abusing Azure access/refresh tokens. Perfect for token acquisition, manipulation, and reuse.
GraphySpy – Automates post-exploitation enumeration of Azure AD using valid access tokens, mapping out user privileges and group memberships.
Key Attack Vectors in Azure AD
Attackers now have multiple avenues to acquire and exploit tokens:
1. Device Code Phishing
The device code flow is designed for headless devices but has become a phishing vector. The user is tricked into authenticating via https://microsoft.com/devicelogin using a benign-looking code. Once completed, the attacker receives a refresh token linked to the victim’s session.
2. FOCI Tokens and Token Reuse
FOCI (Family of Client IDs) tokens are refresh tokens shared across multiple first-party Microsoft apps. If you obtain one, you can request access tokens for other services (e.g., from Teams to Graph to Azure Resource Manager), enabling lateral movement across cloud services.
3. Token Replay for Lateral Movement
Unlike NTLM relays in on-prem networks, attackers in Azure environments can replay access tokens across APIs, or exfiltrate refresh tokens and generate access to other services. This can be combined with enumeration techniques to identify other service principles and potentially high-privilege accounts with broader access.
4. Misconfigured Conditional Access Policies
Some Conditional Access setups allow token replay from unmanaged or untrusted devices, bypassing traditional device compliance controls. Attackers can replay tokens from their own systems without triggering alerts or prompts.
The Next NTLM?
As defenders harden NTLM usage and shift identity to Azure AD, attackers are following close behind. The abuse of Azure access and refresh tokens is quickly becoming the new frontier of identity-based attacks. We’re already seeing early signs of this trend in red team operations, with tokens increasingly providing the foothold or pivot needed to escalate access within cloud environments.
Final Thoughts
Token-based attacks aren’t theoretical anymore—they’re practical, real-world techniques that work right now in many Azure AD environments. Like NTLM before them, access and refresh tokens are becoming a focal point for both offensive security research and defensive detection engineering.
Expect to see this landscape mature rapidly over the coming months/years. And if your detection stack is still focused on failed logins and brute-force attempts, it’s time to start watching your token grants, consent flows, and refresh token usage instead.
In this post I walk through the PetitPotam and Active Directory Certificate Services NTLM Relay Attack recently announced. My hope is to raise awareness of the attack and offer some practical mitigation for the vulnerability.
Following on from the recent work conducted by SpectorOps where various AD attack path were identified within Active Directory Certificate Services/Certificate Authority (AD CS/CA). ExAndroidDev carried out some further fine work within the ntlmrrelayx.py script to allow targeting of a CA, this was subsequently submitted as pull request into the SecureAuthCorp Impacket master branch. This essentially allows credentials to be relayed to the CA Enrollment Web Services (EWS) resulting in a base64 encoded cert for the template you specify. The certificate can then be imported into Rubeus or kekeo and subsequently used in various pass the ticket type attacks such as dcsync.
The modified version of Impacket’s ntlmrelayx.py is a little different to the master branch, once we get into git cloning the master branch and switching to the specific commit or using ExAndroidDev version we will most likely want to isolate the install as we don’t want to mess with our known good working install within Kali. Therefore it would be wise to install and run the newer version in a python virtual environment. Lets get started:
apt-get install python3-venv #install venv mkdir python-virtual-environments && cd python-virtual-environments # create a directory for your venv's sudo python3 -m venv env1 # create a venv called env1 source env1/bin/activate # activate env1 to use it cd env1 git clone https://github.com/ExAndroidDev/impacket.git cd impacket python setup.py install # installing in the env1 will ensure you don't mess up your original install cd impacket/examples
For my lab I used a similar setup to the below:
Using the new ntlmrelayx.py we can setup the NTLM relay as below:
What this is effectively doing is setting up a relay server ready for credentials to be squirted to the CA. This can be achieved in a number of ways for example using responder, mitm6 as well as the newly released tool/script PetitPotam.
Enter PetitPotam, this new found attack vector allows us to coerce a Windows host to authenticate to other computers (in the form of ntlm) onward to our relay server. This is done by eliciting a response from a machine through SMB port 445 against the Encrypting File System Remote (EFSRPC) Protocol service using a specific named pipe LSARPC with interface c681d488-d850-11d0-8c52-00c04fd90f7e. Looking into the petitpotam py script we can see it try’s to make a binding with the following pipes:
The main requirement to note here is that the ntlm credentials must be sent from from the authenticated position to the relay (dc to relay), this could be from an already phished computer or simply relying on responder, the second main point here is this can now be elicited from an unauthenticated position with PetitPotam.
We will go ahead and git clone the PetitPotam code:
The PetitPotam vulnerability can be identified with a basic unauthenticated Nessus scan (plugin ID 152102, CVSS v3.0 Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)
A vulnerable Certificate Authority will be one that is running HTTP not HTTPS, accepts NTLM authentication and has at least one template published that allows for client authentication like the kerberos Authentication template. The ADCS role is normally (in my experience) installed on a DC in smaller environments or as a standalone member server, this can be verified by accessing port 80 on a DC or suspect CA, authenticating with the basic auth form with a low priv user and verifying its the CA enrolment page.
Back to our exploit:
As PetitPotam does require Impacket we will use our python virtual environment, in a second terminal we run the PetitPotam script like below:
python3 petitpotam.py 10.0.1.153 10.0.1.129
Where the first IP address is the relay server and the second is the AD server (not your AD CS).
As you will see from my lab I received an error message saying ‘something went wrong…’ however this still seemed to work just fine. We know this as we can see the DC sending an authentication request into the ntlmrelayx tool, then onto the AD CS like below:
We can see our authentication as DC1$ machine account against the CA succeeded, a Certificate Signing Request (CSR) is generated and a Base64 certificate received for what appears to be the DC1$ machine account. Oh dear.
Next we’ll take this Base64 cert and use it with Rubeus to request a TicketGrantingTicket (TGT). This needs to be running in a security context associated within the domain, in this case I have used a low privileged domain user account ‘securecorp.uk\ted’ in a ‘runas /netonly’ session from my Windows attack vm:
• Disable incoming NTLM authentication using GPO “Network security: Restrict NTLM: Incoming NTLM traffic”. • Configure IIS to use Kerberos authentication only by removing NTLM authentication, set Windows authentication to Negotiate:Kerberos . • Use HTTPS instead of HTTP for IIS on the CA. • Consider enabling Extended Protection for Authentication (EPA) for clients and server https://msrc-blog.microsoft.com/2009/12/08/extended-protection-for-authentication/.
In this scenario we take a look at GPO Abuse, which sees domain users or a specific compromised user (Jane in this example) having edit permissions to a GPO that affects a large number of machines (ok only one in the lab!). This post is to highlight the dangers of this and walk through a proof of concept to highlight the risk. Clearly this can be deadly, it can be used to spread ransomware, malware, reverse shells and any number of settings we wish to push to computer objects affected by that GPO. As a computer policy the settings are pushed out in the context of NT Authority\ SYSTEM (the highest privilege level on a Windows system). The scenario could also be such that we have control over an Organisation Unit not just a specific GPO (i.e. creating a new GPO and linking it to that OU).
Let’s start by enumerating all the permissions for all GPOs in the current domain with PowerView:
We find that the group ‘Domain Users’ have the ability to modify the ‘Dodgy Policy’ GPO which is linked to the ‘Development’ OU which contains the ‘File1’ computer object. In bloodhound this looks like:
The misconfiguration in Group Policy Management GUI would be similar to this (or a security group or individual) in this case we have used ‘Domain Users’:
We can use the RSAT (Remote Server Administration Tools) GUI and or PowerShell modules to modify or create a new policy:
The actions of this attack can be wide reaching in terms of the number of affected hosts, in such a situation whilst on a penetration test it would be wise to consider limiting the target hosts of a new GPO to a couple of hosts specifically. We can do this in two ways:
1. Object level targeting by applying a WMI Filter: In the GPO setting you can target various AD or WMI objects. For example something similar to the following: MS SELECT * FROM Win32_ComputerSystem WHERE Name IS ‘FILE1’.
2. Security Filtering: Remove the default “authenticated users” and add the computer name/security group with computer objects.
Some versions of PowerView (to the best of my knowledge) contain a ‘New-GPOImmediateTask’ function, which can create a scheduled task which will run once GPO refreshes. We can push any PowerShell or CMD command such as stager, launcher or download cradle.
I wasn’t able to get this working in my labs, however not deterred I looked for an alternative way. Alternatives being standard RSAT GUI (not very red team) and SharpGPOAbuse . SharpGPOAbuse will essentially do a very a similar job to PowerView by modifying the target GPO, which when applied to a machine will create a scheduled task which will instantly run.
First compile SharpGPOAbuse in Visual Studio (needs a write up in its own right).
Next we will use the Assembly Task from within Covenant, with the following parameters:
Great, we see the commands executed successfully in our covenant output and the GPO has been updated, we can see the file that has been updated in sysvol on the DC!
If we look in Group Policy Management console on the DC we can see specifically what has been set:
Once GPO has been refreshed (every 90 mins by default) we can verify our results on the target system ‘File1’, we can see that Task1 has been applied in the Task Scheduler:
The proof is always in the pudding, and we can see a grunt has connected:
Things to consider from a pentesting perspective:
The impact could be significant, so verify how this affects your position. I.e. How many machines will this affect, what sort of machines critical infra?
An alternative route to reach your goal may have less of an impact.
As an alternative approach to highlight this risk to a client might be to simple demonstrate through RSAT by creating a blank GPO and linking it to the OU without creating the task or any actions.
To the best of my knowledge I couldn’t see a ‘remove’ or ‘reverse’ action within SharpGPOAbuse, to revert back/clean up our modifications. As a Pentester/Red Team member you should be mindful of this. Depending on the engagement I would suggest this is run in conjunction with the POC or have the ability to clean this up, both the task its created and the GPO.
This is not OPSEC safe, admins may see the changes in the GPO console.
Always remember to clear up after yourself.
Hopefully this has demonstrated how powerful and dangerous this sort of misconfiguration is in the enterprise can be. For the blue team, check your configuration with bloodhound to understand any weakness you may have.
In this post I am going to highlight the risks of using self signed certificates with Remote Desktop Protocol (RDP). Why its a problem and what we can do to fix it! Hopeful by demonstrating the impact it will raise awareness of how serious an issue this can actually be.
On an internal network the issue stems from you connect to a computer or server that is using a self signed certificate through remote desktop your not able to verify the endpoint for its authenticity. ie it is who it says it is.
Unfortunately we are all too familiar with the classic rdp certificate warning prompt like this and most of the time blindly click on yes I accept. Often with out actually reading what the message is saying.
Ok, lets see what all the fuss is about then. Lets consider the following devices in our LAB
DC16: 192.168.1.10 – Windows Server 2016 Domain Controller
WEB16: 191.168.1.52 – Windows Server 2016 Web Server
W10 192.168.1.51 – Windows 10 Client
Kali 192.168.1.50 – Kali Linux our attacker.
The attacker can essentially sit on the same network and cause a Man In The Middle (MiTM) condition between the windows 10 client and Web Server when using self-signed certificate. If we expand on the scenario slightly. Imagine we have an admin logged in to our windows 10 client, he/she wants to investigate an issue on the web server, so goes to establish a remote desktop session to the server. Lets consider what can happen.
To demonstrate this attack we are going to use ‘Seth’ a tool to perform a MitM attack and extract clear text credentials from RDP connections. Code is located here: https://github.com/SySS-Research/Seth , you can find a more detailed talk about the tool here by its creator Adrian Vollmer https://www.youtube.com/watch?v=wdPkY7gykf4.
On our attacking machine we are going to start Seth:
Mean while our admin is going about his daily tasks on our windows 10 client, he/she then decides to connect to our web server via RDP:
The usual connection sequence takes place, the admin receives the usual all too familiar warning box and continues to establish the connection. In the meanwhile over on our attacking box the connection has been intercepted and the MiTM attack carried out successfully. Seth intercepts the connection and has captured the NTLMv2 hash as well as the clear text credentials. Oh dear.
As you can see this not an optimal configuration, and one which we would very much like to avoid. It can be avoided by using a signed certificate from your internal CA or other trusted certificate authority. Getting certificates installed on your devices isn’t all that too difficult to go through, I actually discuss this further here and linked to how to. In addition to this we can also stop our clients from connecting to anything we don’t trust via GPO. Remember we need to be connecting to our servers via name not IP. As the IP address is not what is on the certificate in the common name field and will therefore be untrusted.
Well I hope this has helped demonstrate the impact of self-signed certificates and why they should be addressed on the inside.
I thought I would walk through the process of generating a certificate for a non-domain joined device using an internal Active Directory Certificate Authority (AD CS). In this example, it is going to be for our web GUI for a pfsense firewall. I’v talked before about the challenges of self signed certificates in this post, so thought this would be useful to further demonstrate how this can be done for other devices that are not joined to a domain. Like most things if you have never experienced setting something like this up, you won’t necessarily know how to go about doing it. This post aims to fill that gap. Hopefully you will see this isn’t as difficult as it sounds.
For our lab we have AD CS setup and pfsense on the same network, its actually acting as the gateway for the network. Its a key piece of equipment on the network that we want technical security assurance around. Including being able to validate that when we connect to the device for management it is who we think it is, and importantly who its saying it is. And that we are not in a position to let ourselves be caught by a man in the middle attack!
Lets start on the pfsense web configurator page:
As we can see this is using a self signed certificate and is therefore untrusted. So we want a certificate on our firewall that is signed by a trusted certificate authority, one that is ideally already in our root certificate store. If you have an internal AD CS, the root CA certificate will most likely be already there.
Typically with a network device such as this we somehow want to first generate a Certificate Signing Request (CSR) to then take to our CA to be signed. You can usually achieve this via a shell session to the device or through the web GUI in most cases. Whilst the steps i’m going through with pfsense are specific to this device, the concept is the same for all devices. With pfsense we are able to do this here:
We can see in the above screen shot the self-signed certificate that comes with the device. To start the process we click on the green button at the bottom Add/Sign. As you can see below the method we want to use is ‘Create a Certificate Signing Request’.
Continue down the page adding all the relevant info. Three key areas to take note are the ‘Common Name’, ‘Alternative Names’ and selecting Server Certificate for the certificate type. These are important as you this is how we will identify the authenticity of the device. The ‘Comman Name’ is effectively its short name, and the ‘Alternative Names’ we will want to add as the Fully-Qualified-Domain-Name (FQDN). In this case I’m naming the firewall FW1, Jango.com is the domain name 🙂 .
Once at the end of the page select save and you should see our certificate request in a pending state, the screen should look like this:
Next export the CSR, download it to your local machine and open it in notepad. Highlight the text and copy it to your clipboard for later. The file should look like this:
Next we are going to find our way to the AD CS certificate enrollment web page. This is commonly the CA name followed by ‘certsrv/default.asp’ so in my lab the CA is held on the DC, so will be http://DC16/certsrv/default.asp, just like below:
Next we select ‘Request a certificate’:
Here we don’t have many options as this is a fairly default install of the certificate services however select ‘Advanced Certificate Request. On the next screen as below, paste in the CSR in the request window, and select the default ‘Web Server’ template from the ‘Certificate Template’ drop down menu and click submit:
Next we have the opportunity to download the signed certificate in various formats.
In this instance we are going to download the certificate in Base 64 encoded format . Open up the certificate file in notepad, highlight the contents and save it to the clipboard, it should look like this:
Next we go back to the pfsense web GUI, and complete the certificate signing request from the certificate page. This is under ‘System’ –> Certificate Manager’ –> ‘Certificates’. We do this by selecting the update CSR button, paste in the contents of the certificate into the ‘Final Certificate data’ like below and select ‘update’:
The certificate will be loaded and will look like this:
As we can see from the above screenshot our subject Alternate Names are listed as FW1 and FW1.jango.com, meaning when we access the page with these names the connection will be validated correctly. As opposed to accessing it via IP address and it will warn us that the browser has not been able to validate the endpoint and is therefore insecure.
Next change how the certificate is used. Essentially we are binding it to port 443, the web GUI itself, we do this in System –> Advanced –> Admin Access, select the descriptive name we gave it earlier and select ‘Save’ at the bottom of the page:
Next reload the web GUI page using your common name or subject alternate name. At this point bear in mind you mostly likely will need a manual DNS entry for FW1. So head over to the DNS console and quickly create one. Once you have done that reload the pfsense web GUI, and hey presto!
and..
Now we have a certificate signed by our internal AD CA and can verify what we are connecting to is actually correct.
I hope this has helped demystify the process of obtaining an internally signed certificate from our AD CA for our weird and wonderful network devices that we have on the network.
I posted recently about implementing Linux password complexity here and wanted to follow it up by posting about account lockout policy. Linux account lockout policy is often overlooked, this post will show you how to implement simple controls to keep you in check. Brute force attacks are trivial to perform, not having a lockout policy (and password policy) could end you up in hot bother. With a lockout time configured this will at least slow down your adversaries and very least annoy the hell out of them. I would always suggest you use a public/private key pair for SSH access and disable password authentication specifically for this service.
Linux account lockout policy is controlled by Pluggable Authentication Modules (PAM) more specifically pam_tally and pam_tally2. These modules can be configured in Debain/Ubuntu in the /etc/pam.d/common-auth, and in RedHat and Centos based distros /etc/pam.d/system-auth. Pam_tally as the name might suggest is a count for logins (ie tallying up logins). The module has various options to configure, it will maintains a count of attempted logins, can reset counts, and deny access based on too many incorrect attempts, set lockout time etc.
Lets look at an example of how we might configure this within Ubuntu 18.04.1.
If we check what PAM modules are installed ‘man -k pam_’ we see that pam_tally and pam_tally2 are already installed.
I have added the highlighted line into the /etc/pam.d/common-auth file:
According to the Ubuntu man pages here normally failed attempts to access the root account will not cause the root account to become blocked, to prevent denial of service, this can be overriden with an optional argument which we will discuss later.
Our settings are:
onerror=fail : Upon an error issue a fail. deny=5 : Deny access if the count for this user exceeds 5 attempts. unlock_time=1200 : This will lock the user out for 1200 seconds (20 mins) if the max allowed attempts is exceeded. audit : This will log the user name into the sys log if the user is not found. even_deny_root : Careful with this one, this will lock the root account out. root_unlock_time=1200 : This will lock the root account out for 1200 seconds (20 mins) if the max allowed attempts is exceeded.
These changes are instant, no need to reboot or restart any service.
All that’s left to do now is to test our configuration on our test server. In the /var/log/auth.d file we can see pam_tally2 is racking up the login attempts and is denying access.
Linux Password Policy is often overlooked. This post is to raise awareness how we can up our game in terms of password complexity for Linux systems. Setting up password complexity in Linux specifically Ubuntu Server more specifically 18.04.1 is achieved through Pluggable Authentication Modules (PAM). To authenticate a user, an application such as ssh hands off the authentication mechanism to PAM to determine if the credentials are correct. There are various modules that can be modified within PAM to set-up aspects like password complexity and account lockout and other restrictions. We can check what modules are installed by issuing:
sudo man -k pam_
By default Ubuntu requires a minimum of 6 characters. In Ubuntu this is controlled by the module pam_unix which is used for traditional password authentication, this is configured in debain/ubuntu systems in the file /etc/pam.d/common-password (RedHat/Centos systems its/etc/pam.d/system-auth). Modules work in a rule/stack manner processing one rule then another depending on the control arguments. An amount of configuration can be done in the pam_unix module, however for more granular control there is another module called pam_cracklib. This allows for all the specific control that one might want for a secure complex password.
A basic set of requirements for password complexity might be:
A minimum of one upper case A minimum of one lower case A minimum of least one digit A minimum of one special character A minimum of 15 characters
Password History 15
Lets work through on a test Ubuntu 18.04.1 server how we would implement this. First install pam_cracklib, this is a ‘pluggable authentication module’ which can be used in the password stack. ‘Pam_cracklib’, will check for specific password criteria, based on default values and what you specify. For example by default it will run through a routine to see if the password is part of a dictionary and then go on to check for your specifics that you may have set like password length.
First lets install the module, it is available in the Ubuntu repository:
sudo apt install libpam-cracklib
The install process will automatically add a line into the /etc/pam.d/common-password file that is used for the additional password control. I’ve highlight it below:
We can then further modify this line for additional complexity. working on the above criteria we would add:
ucredit=-1 : A minimum of one upper case lcredit=-1 : A minimum of one lower case dcredit=-1 : A minimum of least one digit ocredit=-1 : A minimum of one special character minlen=15 : A minimum of 15 characters.
note the -1 number represents a minimum value to subtract from the minlen value. There is nothing to stop you incresing this, for example ocredit=-3 would require the user to add 3 special characters.
Password history is actually controlled by pam_unix so we will touch on this separately.
Default values that get added are:
retry=3 : Prompt user at most 3 times before returning an error. The default is 1. minlen=8 : A minimum of 15 characters. difok=3 : The amount of character changes in the new password that differentiate it from the old password.
For password history first we need to create a new file for pam_unix to store old passwords (hashed of course). Without this password changes will fail.
Add the ‘remeber=15‘ to the end of the pam_unix line and your done, at least for now. Both lines should look like this:
These changes are instant, no need to reboot or restart any service.
Now all that is left to do is test your new password policy. Whilst this does provide good password complexity I would always suggest you use a public/private key pair for SSH access and disable password authentication specifically for this service.
In this post we will walk through how to implement some of the most common security headers that crop up in Microsoft IIS 8.5 web application testing. Typically Burp, zap nikto will highlight missing security headers. I have covered some of these for Apache in earlier posts here. Now its time for the same treatment in IIS. Some of the headers I will look at in this session are:
X-Frame-Options header – This can help prevent the clickjacking vulnerability by instructing the browser not to in bed the page in an iframe. X-XSS-Protection header – This can help prevent some cross site scripting attacks. X-Content-Type-Options header – This will deny content sniffing. Content-Security-Policy – This can help prevent various attacks by telling the browser to only load content from the sources you specify. In this example I will only specify the source, ie my webpage however if you have content being pulled from youtube for example you will want to add this site also. HTTP Strict Transport Security header – This will tell the browser to only ever load https only, once the site has been visited.
Corresponding values for the above headers are described below.
In order to lab this up we will use a vanilla Windows Server 2012 R2 server that has had the IIS role installed and configured and is serving just a simple single page running over HTTPS (only with a self signed cert for testing purposes), which looks like this:
With completely standard configuration output from Nikto would give us the following results:
OWASP Zap would give us similar results (I did this whilst still on http, however you get the idea):
Granted there is next to nothing to actually scan on this pages, however this is really only designed to demonstrate how to implement the security headers.
In the IIS console we will want to select the ‘HTTP Response Headers’, you can do this at the site level as I have done or at the webserver level which will affect all sites.
Next select Add from the left hand side:
First we will add X-XXS-Protection security header, here we can use the value of ‘1;mode=block’, this essentially means we will turn the feature on and if detected block it. Other basic options consist of ‘1’ to enable or ‘0’ to set the header however disable the feature :
Next the X-Frame-Options security header, here we can use the value of ‘DENY’ to prevent any content embedding, however this maybe too strict otherwise there is ‘SAMEORIGIN’ to allow content from your site, another option is to use ‘ALLOW-FROM’ to allow content framing from another site:
Next the X-Content-Type-Options security header, here we can use the value of ‘nosniff’:
The content security policy header, here we are specifying a very basic policy to only load content from the source:
The HTTP Strict Transport Security header, here we are setting the max age the browser should honour the header request, to include all subdomains and the preload essentially means that if HTTP site is available only load via HTTPS so on a second visit load the config first before hitting the site:
Re-running nikto gives us the following output, much better!
Hopefully this has helped harden your IIS web server just that little bit more!
This is just a quick post to raise awareness of one way we can help protect our Domain Admins Group in Active Directory. I have talked previously about privilege separation and the need within the Enterprise to reduce the credential foot print of high privilege accounts. As Microsoft describes in this particular article discussing best practices, Domain Admin accounts should only be used for build and disaster recovery scenarios and should not be used for day to day activities. By following this simple rule you are mitigating against having Domain Admin credentials being cached on workstations or member servers, and therefore less likely to be dumped out of memory should the box become compromised.
We can secure the Domain Admins group for both member workstations and member servers with the following Group Policy Objects from the following user rights policy in Computer Configuration\Policies\Windows Settings\Security Settings\Local Settings\User Rights Assignments:
Deny access to this computer from the network
Deny log on as a batch job
Deny log on as a service
Deny log on locally
Deny log on through Remote Desktop Services user rights
Lets take a closer look and create the policy:
In our Group Policy Management console we will start off with a new policy:
Right click on the policy and click edit. Find the first policy ‘Deny access to this computer from the network’. Open it up and add the Domain Admins group to the list. Click ‘OK’.
Rinse and Repeat for the remaining policies:
Link the policy through to your computers and member workstations. Remember if your using ‘Jump boxes’ to administer your domain controllers you will need to create an exception for these and with a different policy.
