GITBOOK-705: No subject

pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-artifact-poisoning.md

@@ -0,0 +1,2 @@
+# Gh Actions - Artifact Poisoning
+

pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-cache-poisoning.md

@@ -0,0 +1,2 @@
+# GH Actions - Cache Poisoning
+

pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md

@@ -0,0 +1,2 @@
+# Gh Actions - Context Script Injections
+

pentesting-cloud/azure-security/az-basic-information.md

@@ -88,7 +88,23 @@ Entra Domain Services extends the capabilities of Entra ID by offering **managed
   * Indicate properties
     * Default user type is “**Guest**”
 
-### Users Default permissions
+### Members & Guests Default Permissions
+
+You can check them in [https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions](https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions) but among other actions a member will be able to:
+
+* Read all users, Groups, Applications, Devices, Roles, Subscriptions, and their public properties
+* Invite Guests (_can be turned off_)
+* Create Security groups
+* Read non-hidden Group memberships
+* Add guests to Owned groups
+* Create new application (_can be turned off_)
+* Add up to 50 devices to Azure (_can be turned off_)
+
+{% hint style="info" %}
+Remember that to enumerate Azure resources the user needs an explicit grant of the permission.
+{% endhint %}
+
+### Users Default Configurable Permissions
 
 * **Members (**[**docs**](https://learn.microsoft.com/en-gb/entra/fundamentals/users-default-permissions#restrict-member-users-default-permissions)**)**
   * Register Applications: Default **Yes**
@@ -117,6 +133,19 @@ Entra Domain Services extends the capabilities of Entra ID by offering **managed
 Even if restricted by default, users (members and guests) with granted permissions could perform the previous actions.
 {% endhint %}
 
+### **Groups**
+
+There are **2 types of groups**:
+
+* **Security**: This type of group is used to give members access to aplications, resources and assign licenses. Users, devices, service principals and other groups an be members.
+* **Microsoft 365**: This type of group is used for collaboration, giving members access to a shared mailbox, calendar, files, SharePoint site, and so on. Group members can only be users.
+  * This will have an **email address** with the domain of the EntraID tenant.
+
+There are **2 types of memberships**:
+
+* **Assigned**: Allow to manually add specific members to a group.
+* **Dynamic membership**: Automatically manages membership using rules, updating group inclusion when members attributes change.
+
 ### **Service Principals**
 
 A **Service Principal** is an **identity** created for **use** with **applications**, hosted services, and automated tools to access Azure resources. This access is **restricted by the roles assigned** to the service principal, giving you control over **which resources can be accessed** and at which level. For security reasons, it's always recommended to **use service principals with automated tools** rather than allowing them to log in with a user identity.
@@ -141,23 +170,6 @@ An **App Registration** is a configuration that allows an application to integra
 6. **Service Principal**: A service principal is created when an App is created (if it's done from the web console) or when it's installed in a new tenant.
    1. The **service principal** will get all the requested permissions it was configured with.
 
-### Enterprise Applications
-
-It’s just a **table in Azure to filter service principals** and check the applications that have been assigned to.
-
-**It isn’t another type of “application”,** there isn’t any object in Azure that is an “Enterprise Application”, it’s just an abstraction to check the Service principals, App registrations and managed identities.
-
-### **Managed Identity (Metadata)**
-
-Managed identities in Azure Active Directory offer a solution for **automatically managing the identity** of applications. These identities are used by applications for the purpose of **connecting** to **resources** compatible with Azure Active Directory (**Azure AD**) authentication. This allows to **remove the need of hardcoding cloud credentials** in the code as the application will be able to contact the **metadata** service to get a valid token to **perform actions** as the indicated managed identity in Azure.
-
-There are two types of managed identities:
-
-* **System-assigned**. Some Azure services allow you to **enable a managed identity directly on a service instance**. When you enable a system-assigned managed identity, a **service principal** is created in the Entra ID tenant trusted by the subscription where the resource is located. When the **resource** is **deleted**, Azure automatically **deletes** the **identity** for you.
-* **User-assigned**. It's also possible for users to generate managed identities. These are created inside a resource group inside a subscription and a service principal will be created in the EntraID trusted by the subscription. Then, you can assign the managed identity to one or **more instances** of an Azure service (multiple resources). For user-assigned managed identities, the **identity is managed separately from the resources that use it**.
-
-Managed Identities **don't generate eternal credentials** (like passwords or certificates) to access as the service principal attached to it.
-
 ### Default Consent Permissions
 
 **User consent for applications**
@@ -181,13 +193,46 @@ Managed Identities **don't generate eternal credentials** (like passwords or cer
 * If **Yes**: It’s possible to indicate Users, Groups and Roles that can consent requests
   * Configure also if users will receive email notifications and expiration reminders 
 
+### **Managed Identity (Metadata)**
+
+Managed identities in Azure Active Directory offer a solution for **automatically managing the identity** of applications. These identities are used by applications for the purpose of **connecting** to **resources** compatible with Azure Active Directory (**Azure AD**) authentication. This allows to **remove the need of hardcoding cloud credentials** in the code as the application will be able to contact the **metadata** service to get a valid token to **perform actions** as the indicated managed identity in Azure.
+
+There are two types of managed identities:
+
+* **System-assigned**. Some Azure services allow you to **enable a managed identity directly on a service instance**. When you enable a system-assigned managed identity, a **service principal** is created in the Entra ID tenant trusted by the subscription where the resource is located. When the **resource** is **deleted**, Azure automatically **deletes** the **identity** for you.
+* **User-assigned**. It's also possible for users to generate managed identities. These are created inside a resource group inside a subscription and a service principal will be created in the EntraID trusted by the subscription. Then, you can assign the managed identity to one or **more instances** of an Azure service (multiple resources). For user-assigned managed identities, the **identity is managed separately from the resources that use it**.
+
+Managed Identities **don't generate eternal credentials** (like passwords or certificates) to access as the service principal attached to it.
+
+### Enterprise Applications
+
+It’s just a **table in Azure to filter service principals** and check the applications that have been assigned to.
+
+**It isn’t another type of “application”,** there isn’t any object in Azure that is an “Enterprise Application”, it’s just an abstraction to check the Service principals, App registrations and managed identities.
+
 ### Administrative Units
 
-[From the docs:](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/admin-units-manage) Administrative units let you **subdivide** your organization into **any unit** that you want, and then **assign specific administrators** that can **manage only the members** of that unit. For example, you could use administrative units to delegate permissions to administrators of each school at a large university, so they could control access, manage users, and set policies only in the School of Engineering.
+Administrative units allows to **give permissions from a role over a specific portion of an organization**.
 
-Only **users**, **groups** and **devices** can be **members** of an **administrative unit**.
+Example:
 
-Therefore, an **Administrative unit** will **contain** some **members** and other **principals** will be **assigned permissions over that** administrative **unit** that they can use to **manage the members** of the administrative unit.
+* Scenario: A company wants regional IT admins to manage only the users in their own region.
+* Implementation:
+  * Create Administrative Units for each region (e.g., "North America AU", "Europe AU").
+    * Populate AUs with users from their respective regions.
+      * AUs can **contain users, groups, or devices**
+      * AUs support **dynamic memberships**
+      * AUs **cannot contain AUs**
+    * Assign Admin Roles:
+      * Grant the "User Administrator" role to regional IT staff, scoped to their region's AU.
+* Outcome: Regional IT admins can manage user accounts within their region without affecting other regions.
+
+### Entra ID Roles
+
+* In order to manage Entra ID there are some **built-in roles** that can be assigned to Entra ID principals to manage Entra ID
+  * Check the roles in [https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference)
+* The most privileged role is **Global Administrator**
+* In the Description of the role it’s possible to see its **granular permissions**
 
 ## Roles & Permissions
 
@@ -218,32 +263,84 @@ Depending on the scope the role was assigned to, the **role** cold be **inherite
 This roles can **also be assigned over logic containers** (such as management groups, subscriptions and resource groups) and the principals affected will have them **over the resources inside those containers**.
 
 * Find here a list with [**all the Azure built-in roles**](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles).
-* Find here a list with [**all the Azure AD built-in roles**](https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference).
+* Find here a list with [**all the Entra ID built-in roles**](https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference).
 
 ### Custom Roles
 
-Azure also allow to create [**custom roles**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles) with the permissions the user needs.
-
-### Permission Denied
+* It’s also possible to create [**custom roles**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)
+* They are created inside a scope, although a role can be in several scopes (management groups, subscription and resource groups)
+* It’s possible to configure all the granular permissions the custom role will have
+* It’s possible to exclude permissions
+  * A principal with a excluded permission won’t be able to use it even if the permissions is being granted elsewhere
+* It’s possible to use wildcards
+* The used format is a JSON
+  * `actions` are for control actions over the resource
+  * `dataActions` are permissions over the data within the object
+
+Example of permissions JSON for a custom role:
+
+```json
+{
+    "properties": {
+        "roleName": "",
+        "description": "",
+        "assignableScopes": [
+            "/subscriptions/9291ff6e-6afb-430e-82a4-6f04b2d05c7f"
+        ],
+        "permissions": [
+            {
+                "actions": [
+                    "Microsoft.DigitalTwins/register/action",
+                    "Microsoft.DigitalTwins/unregister/action",
+                    "Microsoft.DigitalTwins/operations/read",
+                    "Microsoft.DigitalTwins/digitalTwinsInstances/read",
+                    "Microsoft.DigitalTwins/digitalTwinsInstances/write",
+                    "Microsoft.CostManagement/exports/*"
+                ],
+                "notActions": [
+                    "Astronomer.Astro/register/action",
+                    "Astronomer.Astro/unregister/action",
+                    "Astronomer.Astro/operations/read",
+                    "Astronomer.Astro/organizations/read"
+                ],
+                "dataActions": [],
+                "notDataActions": []
+            }
+        ]
+    }
+}
+```
+
+### Permissions order
 
 * In order for a **principal to have some access over a resource** he needs an explicit role being granted to him (anyhow) **granting him that permission**.
 * An explicit **deny role assignment takes precedence** over the role granting the permission.
 
-<figure><img src="../../.gitbook/assets/image (191).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (191).png" alt=""><figcaption><p><a href="https://link.springer.com/chapter/10.1007/978-1-4842-7325-8_10">https://link.springer.com/chapter/10.1007/978-1-4842-7325-8_10</a></p></figcaption></figure>
 
 ### Global Administrator
 
-Users with the Global Administrator role has the ability to '**elevate' to User Access Administrator Azure role to the root management group**. This means that a Global Administrator will be able to manage access **all Azure subscriptions and management groups.**\
+Global Administrator is a role from Entra ID that grants **complete control over the Entra ID tenant**. However, it doesn't grant any permissions over Azure resources by default.
+
+Users with the Global Administrator role has the ability to '**elevate' to User Access Administrator Azure role in the Root Management Group**. So Global Administrators can manage access in **all Azure subscriptions and management groups.**\
 This elevation can be done at the end of the page: [https://portal.azure.com/#view/Microsoft\_AAD\_IAM/ActiveDirectoryMenuBlade/\~/Properties](https://portal.azure.com/#view/Microsoft\_AAD\_IAM/ActiveDirectoryMenuBlade/\~/Properties)
 
-<figure><img src="../../.gitbook/assets/image (162).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (349).png" alt=""><figcaption></figcaption></figure>
 
 ### Azure Policies
 
-Azure policies are a set of **rules and regulations in Microsoft Azur**e, a cloud computing service, that help manage and enforce organizational standards and to assess compliance at-scale. These policies enforce different rules over your **Azure resources**, ensuring that those resources stay compliant with corporate standards and service level agreements.
+**Azure Policies** are rules that help organizations ensure their resources meet specific standards and compliance requirements. They allow you to **enforce or audit settings on resources in Azure**. For example, you can prevent the creation of virtual machines in an unauthorized region or ensure that all resources have specific tags for tracking.
 
-Azure policies are crucial for cloud governance and security, helping to ensure that resources are used properly and efficiently, and that they comply with external regulations and internal policies.\
-Som examples:
+Azure Policies are **proactive**: they can stop non-compliant resources from being created or changed. They are also **reactive**, allowing you to find and fix existing non-compliant resources.
+
+#### **Key Concepts**
+
+1. **Policy Definition**: A rule, written in JSON, that specifies what is allowed or required.
+2. **Policy Assignment**: The application of a policy to a specific scope (e.g., subscription, resource group).
+3. **Initiatives**: A collection of policies grouped together for broader enforcement.
+4. **Effect**: Specifies what happens when the policy is triggered (e.g., "Deny," "Audit," or "Append").
+
+**Some examples:**
 
 1. **Ensuring Compliance with Specific Azure Regions**: This policy ensures that all resources are deployed in specific Azure regions. For example, a company might want to ensure all its data is stored in Europe for GDPR compliance.
 2. **Enforcing Naming Standards**: Policies can enforce naming conventions for Azure resources. This helps in organizing and easily identifying resources based on their names, which is helpful in large environments.
@@ -254,7 +351,30 @@ Som examples:
 
 Note that Azure Policies can be attached to any level of the Azure hierarchy, but they are **commonly used in the root management group** or in other management groups.
 
-### Permissions Scope
+Azure policy json example:
+
+```json
+{
+  "policyRule": {
+    "if": {
+      "field": "location",
+      "notIn": [
+        "eastus",
+        "westus"
+      ]
+    },
+    "then": {
+      "effect": "Deny"
+    }
+  },
+  "parameters": {},
+  "displayName": "Allow resources only in East US and West US",
+  "description": "This policy ensures that resources can only be created in East US or West US.",
+  "mode": "All"
+}
+```
+
+### Permissions Inheritance
 
 In Azure **permissions are can be assigned to any part of the hierarchy**. That includes management groups, subscriptions, resource groups, and individual resources. Permissions are **inherited** by contained **resources** of the entity where they were assigned.
 
@@ -270,24 +390,6 @@ However, in some cases you might want to provide **more fined-grained access man
 Azure **ABAC** (attribute-based access control) builds on Azure RBAC by adding **role assignment conditions based on attributes** in the context of specific actions. A _role assignment condition_ is an **additional check that you can optionally add to your role assignment** to provide more fine-grained access control. A condition filters down permissions granted as a part of the role definition and role assignment. For example, you can **add a condition that requires an object to have a specific tag to read the object**.\
 You **cannot** explicitly **deny** **access** to specific resources **using conditions**.
 
-### Default User Permissions
-
-A basic user will have some **default permissions** to enumerate some parts of AzureAD:
-
-* Read all users, Groups, Applications, Devices, Roles, Subscriptions, and their public properties
-* Invite Guests (_can be turned off_)
-* Create Security groups
-* Read non-hidden Group memberships
-* Add guests to Owned groups
-* Create new application (_can be turned off_)
-* Add up to 50 devices to Azure (_can be turned off_)
-
-You can see the full [list of **default permissions of users** in the docs](https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/users-default-permissions). Moreover, note that in that list you can also see the **guests default permissions list**.
-
-{% hint style="info" %}
-Remember that to enumerate Azure resources the user needs an explicit grant of the permission.
-{% endhint %}
-
 ### Privileged Identity Management (PIM)
 
 Privileged Identity Management (PIM) in Azure is a tool that **manages, controls, and monitors privileged access** in Azure Active Directory and Azure. It enhances security by providing **just-in-time and time-limited privileged access**, **enforcing approval workflows, and requiring additional authentication**. This approach minimizes the risk of unauthorized access by ensuring that elevated permissions are granted only when necessary and for a specific duration.