Az - Azure Network

Tip

Apprenez & pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez & pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez & pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Soutenez HackTricks

• Consultez les subscription plans!
• Rejoignez le 💬 Discord group ou le telegram group ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des hacking tricks en soumettant des PRs aux HackTricks et HackTricks Cloud github repos.

Informations de base

Azure fournit des réseaux virtuels (VNet) qui permettent aux utilisateurs de créer des réseaux isolés au sein du cloud Azure. Dans ces VNets, des ressources telles que des machines virtuelles, des applications, des bases de données… peuvent être hébergées et gérées en toute sécurité. Le réseau dans Azure prend en charge à la fois la communication au sein du cloud (entre les services Azure) et la connexion aux réseaux externes et à Internet.
De plus, il est possible de connecter des VNets entre eux et avec des réseaux on-premise.

Virtual Network (VNet) & Sous-réseaux

Un Azure Virtual Network (VNet) est la représentation de votre propre réseau dans le cloud, offrant une isolation logique au sein de l’environnement Azure dédiée à votre abonnement. Les VNets vous permettent de provisionner et gérer des réseaux privés virtuels (VPN) dans Azure, hébergeant des ressources comme des Virtual Machines (VM), des bases de données et des services d’application. Ils offrent un contrôle total sur les paramètres réseau, y compris les plages d’adresses IP, la création de sous-réseaux, les tables de routage et les gateways réseau.

Les sous-réseaux sont des subdivisions au sein d’un VNet, définies par des plages d’adresses IP spécifiques. En segmentant un VNet en plusieurs sous-réseaux, vous pouvez organiser et sécuriser les ressources selon votre architecture réseau.
Par défaut, tous les sous-réseaux au sein du même Azure Virtual Network (VNet) peuvent communiquer entre eux sans aucune restriction.

Exemple:

• MyVNet with an IP address range of 10.0.0.0/16.
• Subnet-1: 10.0.0.0/24 for web servers.
• Subnet-2: 10.0.1.0/24 for database servers.

Énumération

Pour lister tous les VNets et sous-réseaux dans un compte Azure, vous pouvez utiliser l’Azure Command-Line Interface (CLI). Voici les étapes:

# List VNets
az network vnet list --query "[].{name:name, location:location, addressSpace:addressSpace}"

# List subnets of a VNet
az network vnet subnet list --resource-group <ResourceGroupName> --vnet-name <VNetName> --query "[].{name:name, addressPrefix:addressPrefix}" -o table

# List VNets
Get-AzVirtualNetwork | Select-Object Name, Location, @{Name="AddressSpace"; Expression={$_.AddressSpace.AddressPrefixes}}

# List subnets of a VNet
Get-AzVirtualNetwork -ResourceGroupName <ResourceGroupName> -Name <VNetName> |
Select-Object -ExpandProperty Subnets |
Select-Object Name, AddressPrefix

Groupes de sécurité réseau (NSG)

Un Network Security Group (NSG) filtre le trafic réseau entrant et sortant des ressources Azure au sein d’un Azure Virtual Network (VNet). Il contient un ensemble de règles de sécurité qui peuvent indiquer quels ports ouvrir pour le trafic entrant et sortant selon le port source, l’IP source, le port de destination, et il est possible d’assigner une priorité (plus le numéro de priorité est bas, plus la priorité est élevée).

Les NSG peuvent être associés à des sous-réseaux et des NICs.

Exemples de règles :

• Une règle entrante autorisant le trafic HTTP (port 80) depuis n’importe quelle source vers vos serveurs web.
• Une règle sortante n’autorisant que le trafic SQL (port 1433) vers une plage d’adresses IP de destination spécifique.

Énumération

# List NSGs
az network nsg list --query "[].{name:name, location:location}" -o table
az network nsg show --name <nsg-name>

# Get NSG rules
az network nsg rule list --nsg-name <NSGName> --resource-group <ResourceGroupName> --query "[].{name:name, priority:priority, direction:direction, access:access, protocol:protocol, sourceAddressPrefix:sourceAddressPrefix, destinationAddressPrefix:destinationAddressPrefix, sourcePortRange:sourcePortRange, destinationPortRange:destinationPortRange}" -o table

# Get NICs and subnets using this NSG
az network nsg show --name <NSGName> --resource-group <ResourceGroupName> --query "{subnets: subnets, networkInterfaces: networkInterfaces}"

# List NSGs
Get-AzNetworkSecurityGroup | Select-Object Name, Location
Get-AzNetworkSecurityGroup -Name <NSGName> -ResourceGroupName <ResourceGroupName>

# Get NSG rules
Get-AzNetworkSecurityGroup -Name <NSGName> -ResourceGroupName <ResourceGroupName> |
Select-Object -ExpandProperty SecurityRules |
Select-Object Name, Priority, Direction, Access, Protocol, SourceAddressPrefix, DestinationAddressPrefix, SourcePortRange, DestinationPortRange

# Get NICs and subnets using this NSG
(Get-AzNetworkSecurityGroup -Name <NSGName> -ResourceGroupName <ResourceGroupName>).Subnets
(Get-AzNetworkSecurityGroup -Name <NSGName> -ResourceGroupName <ResourceGroupName>).NetworkInterfaces

Azure Firewall

Azure Firewall est un managed, stateful firewall qui filtre le trafic (L3–L7) pour les flux est-ouest et nord-sud. Déployé au niveau VNet, il centralise l’inspection de tous les sous-réseaux et se met à l’échelle automatiquement pour garantir la disponibilité.

SKUs disponibles : Basic, Standard et Premium :

Énumération

# List Azure Firewalls
az network firewall list --query "[].{name:name, location:location, subnet:subnet, publicIp:publicIp}" -o table

# Get network rules of a firewall
az network firewall network-rule collection list --firewall-name <FirewallName> --resource-group <ResourceGroupName> --query "[].{name:name, rules:rules}" -o table

# Get application rules of a firewall
az network firewall application-rule collection list --firewall-name <FirewallName> --resource-group <ResourceGroupName> --query "[].{name:name, rules:rules}" -o table

# Get nat rules of a firewall
az network firewall nat-rule collection list --firewall-name <FirewallName> --resource-group <ResourceGroupName> --query "[].{name:name, rules:rules}" -o table

# List Azure Firewalls
Get-AzFirewall

# Get network rules of a firewall
(Get-AzFirewall -Name <FirewallName> -ResourceGroupName <ResourceGroupName>).NetworkRuleCollections

# Get application rules of a firewall
(Get-AzFirewall -Name <FirewallName> -ResourceGroupName <ResourceGroupName>).ApplicationRuleCollections

# Get nat rules of a firewall
(Get-AzFirewall -Name <FirewallName> -ResourceGroupName <ResourceGroupName>).NatRuleCollections

Azure Route Tables

Azure Route Tables (UDR) vous permettent de remplacer le routage par défaut en définissant des préfixes de destination (par ex., 10.0.0.0/16 ou 0.0.0.0/0) et un next hop (Virtual Network, Internet, Virtual Network Gateway, or Virtual Appliance).

Les routes s’appliquent au niveau du sous-réseau ; toutes les VMs dans ce sous-réseau suivent la table.

Exemple :

• Pour le trafic destiné à Internet, utilisez le 0.0.0.0/0 par défaut avec Internet comme next hop.
• Pour inspecter le trafic sortant, orientez 0.0.0.0/0 vers l’IP d’un Network Virtual Appliance (NVA).

Énumération

# List Route Tables
az network route-table list --query "[].{name:name, resourceGroup:resourceGroup, location:location}" -o table

# List routes for a table (summary)
az network route-table route list --resource-group <ResourceGroupName> --route-table-name <RouteTableName> --query "[].{name:name, addressPrefix:addressPrefix, nextHopType:nextHopType, nextHopIpAddress:nextHopIpAddress}" -o table

# List routes for a table (full)
az network route-table route list --resource-group <ResourceGroupName> --route-table-name <RouteTableName>

# List Route Tables
Get-AzRouteTable

# List routes for a table
(Get-AzRouteTable -Name <RouteTableName> -ResourceGroupName <ResourceGroupName>).Routes

Azure Private Link

Azure Private Link est un service d’Azure qui permet l’accès privé aux services Azure en garantissant que le trafic entre votre Azure virtual network (VNet) et le service circule entièrement sur le réseau backbone d’Azure de Microsoft. Il intègre effectivement le service dans votre VNet. Cette configuration renforce la sécurité en n’exposant pas les données à l’internet public.

Private Link peut être utilisé avec divers services Azure, comme Azure Storage, Azure SQL Database, et des services personnalisés partagés via Private Link. Il fournit un moyen sécurisé de consommer des services depuis votre propre VNet ou même depuis différents abonnements Azure.

Caution

Les NSGs ne s’appliquent pas aux private endpoints, ce qui signifie clairement que l’association d’un NSG à un subnet contenant le Private Link n’aura aucun effet.

Exemple :

Considérez un scénario où vous avez une Azure SQL Database que vous souhaitez accéder de façon sécurisée depuis votre VNet. Normalement, cela impliquerait de traverser l’internet public. Avec Private Link, vous pouvez créer un private endpoint dans votre VNet qui se connecte directement au service Azure SQL Database. Cet endpoint fait apparaître la base de données comme si elle faisait partie de votre propre VNet, accessible via une adresse IP privée, garantissant ainsi un accès sécurisé et privé.

Enumeration

# List Private Link Services
az network private-link-service list --query "[].{name:name, location:location, resourceGroup:resourceGroup}" -o table

# List Private Endpoints
az network private-endpoint list --query "[].{name:name, location:location, resourceGroup:resourceGroup, privateLinkServiceConnections:privateLinkServiceConnections}" -o table

# List Private Link Services
Get-AzPrivateLinkService | Select-Object Name, Location, ResourceGroupName

# List Private Endpoints
Get-AzPrivateEndpoint | Select-Object Name, Location, ResourceGroupName, PrivateEndpointConnections

DNS OverDoS via service Private DNS zone links

Lorsqu’un VNet a un Virtual Network Link vers une service Private DNS zone (par ex., privatelink.blob.core.windows.net), Azure force la résolution des noms d’hôte pour les ressources enregistrées avec Private Link de ce type de service via la zone. Si la zone ne contient pas le A record requis pour une ressource que les workloads atteignent encore via son endpoint public, la résolution DNS renvoie NXDOMAIN et les clients n’atteignent jamais l’IP publique, provoquant un DoS de disponibilité sans toucher la ressource elle-même.

Flux d’abus (DoS sur le plan de contrôle) :

1. Obtenir des permissions RBAC permettant de créer Private Endpoints ou de modifier des Private DNS zone links.
2. Créer un Private Endpoint pour le même type de service dans un autre VNet (Azure crée automatiquement la service Private DNS zone et la lie à ce VNet).
3. Lier cette service Private DNS zone au VNet victime.
4. Parce que le VNet victime force désormais la résolution via la Private DNS zone et qu’aucun A record n’existe pour la ressource ciblée dans cette zone, la résolution de nom échoue et le workload ne peut pas atteindre l’endpoint (toujours public). Cela s’applique à tout service pris en charge par Private Link (storage, Key Vault, ACR, Cosmos DB, Function Apps, OpenAI, etc.).

Discovery at scale (Azure Resource Graph):

• VNETs linked to the blob Private DNS zone (forced resolution for PL-registered blob endpoints):

resources
| where type == "microsoft.network/privatednszones/virtualnetworklinks"
| extend
zone = tostring(split(id, "/virtualNetworkLinks")[0]),
vnetId = tostring(properties.virtualNetwork.id)
| join kind=inner (
resources
| where type == "microsoft.network/privatednszones"
| where name == "privatelink.blob.core.windows.net"
| project zoneId = id
) on $left.zone == $right.zoneId
| project vnetId

• Storage accounts accessibles via public endpoint mais sans Private Endpoint connections (risque de rupture si le lien ci‑dessus est ajouté) :

Resources
| where type == "microsoft.storage/storageaccounts"
| extend publicNetworkAccess = properties.publicNetworkAccess
| extend defaultAction = properties.networkAcls.defaultAction
| extend vnetRules = properties.networkAcls.virtualNetworkRules
| extend ipRules = properties.networkAcls.ipRules
| extend privateEndpoints = properties.privateEndpointConnections
| where publicNetworkAccess == "Enabled"
| where defaultAction == "Deny"
| where (isnull(privateEndpoints) or array_length(privateEndpoints) == 0)
| extend allowedVnets = iif(isnull(vnetRules), 0, array_length(vnetRules))
| extend allowedIps = iif(isnull(ipRules), 0, array_length(ipRules))
| where allowedVnets > 0 or allowedIps > 0
| project id, name, vnetRules, ipRules

Azure Service Endpoints

Azure Service Endpoints étendent l’espace d’adresses privées de votre virtual network et l’identité de votre VNet aux Azure services via une connexion directe. En activant les Service Endpoints, les ressources dans votre VNet peuvent se connecter de manière sécurisée aux Azure services, comme Azure Storage et Azure SQL Database, via le backbone d’Azure. Ceci est particulièrement utile lorsqu’ils sont combinés avec Network Security Groups (NSGs) pour un contrôle granulaire du trafic.

Exemple :

• Avec un Storage Account et Service Endpoint activés dans un VNET, il est possible d’autoriser le trafic entrant uniquement depuis un VNET dans le storage account firewall, forçant une connexion sécurisée sans nécessiter d’accès par IP publique pour le service de stockage.

Les Service Endpoints ne nécessitent pas d’adresses IP privées pour les services et reposent plutôt sur le backbone d’Azure pour une connectivité sécurisée. Ils sont plus faciles à configurer comparés aux Private Links mais n’offrent pas le même niveau d’isolation et de granularité que les Private Links.

Enumeration

# List Virtual Networks with Service Endpoints
az network vnet list --query "[].{name:name, location:location, serviceEndpoints:serviceEndpoints}" -o table

# List Subnets with Service Endpoints
az network vnet subnet list --resource-group <ResourceGroupName> --vnet-name <VNetName> --query "[].{name:name, serviceEndpoints:serviceEndpoints}"

# List Service Endpoints for a Subnet
az network vnet subnet show --resource-group <ResourceGroupName> --vnet-name <VNetName> --name <SubnetName> --query "serviceEndpoints"

# List Virtual Networks with Service Endpoints
Get-AzVirtualNetwork

# List Subnets with Service Endpoints
(Get-AzVirtualNetwork -ResourceGroupName <ResourceGroupName> -Name <VNetName>).Subnets

Differences Between Service Endpoints and Private Links

Microsoft recommande d’utiliser Private Links dans les docs:

Service Endpoints:

• Le trafic depuis votre VNet vers le service Azure transite par le réseau backbone de Microsoft Azure, en contournant l’internet public.
• L’endpoint est une connexion directe au service Azure et ne fournit pas d’IP privée pour le service au sein du VNet.
• Le service lui‑même reste accessible via son endpoint public depuis l’extérieur de votre VNet à moins que vous ne configuriez le service firewall pour bloquer ce trafic.
• C’est une relation one-to-one entre le subnet et le service Azure.
• Moins coûteux que Private Links.

Private Links:

• Private Link mappe les services Azure dans votre VNet via un private endpoint, qui est une interface réseau avec une adresse IP privée au sein de votre VNet.
• Le service Azure est accédé en utilisant cette adresse IP privée, donnant l’impression qu’il fait partie de votre réseau.
• Les services connectés via Private Link ne sont accessibles que depuis votre VNet ou des réseaux connectés ; il n’y a pas d’accès via l’internet public au service.
• Il permet une connexion sécurisée aux services Azure ou à vos propres services hébergés dans Azure, ainsi qu’une connexion aux services partagés par d’autres.
• Il offre un contrôle d’accès plus granulaire via un private endpoint dans votre VNet, par opposition à un contrôle d’accès plus large au niveau du subnet avec les Service Endpoints.

En résumé, bien que Service Endpoints et Private Links fournissent une connectivité sécurisée aux services Azure, Private Links offrent un niveau d’isolation et de sécurité supérieur en garantissant que les services sont accédés de manière privée sans les exposer à l’internet public. Les Service Endpoints, en revanche, sont plus faciles à configurer pour des cas généraux où un accès simple et sécurisé aux services Azure est requis sans besoin d’une IP privée dans le VNet.

Azure Front Door (AFD) & AFD WAF

Azure Front Door est un point d’entrée scalable et sécurisé pour la livraison rapide de vos applications web globales. Il combine divers services comme application acceleration, SSL offloading, and application layer security (through Web Application Firewall - WAF). It’s built on the concept of edge POP (Point of Presence) locations around the world to bring your applications closer to your users.

Azure Front Door provides a globally distributed network of edge locations to route and accelerate incoming traffic to your web applications (in Azure or elsewhere), improve performance, and enhance security.

Example:

• For a global e-commerce platform with users worldwide, Azure Front Door can cache static content at edge locations and offer SSL offloading, reducing latency and providing a more responsive user experience. Additionally, it provides WAF to protect your applications from common web vulnerabilities (like SQL injection or XSS).

Azure Front Door also offers smart load balancing by routing traffic to the nearest available backend based on health probes and latency, ensuring consistent performance and availability. By integrating WAF, it helps protect against common web threats.

Enumeration

# List Azure Front Door profiles
az afd profile list --query "[].{name:name, location:location, resourceGroup:resourceGroup}" -o table

# List AFD endpoints
az afd endpoint list --profile-name <ProfileName> --resource-group <ResourceGroupName> --query "[].{name:name, hostName:hostName, state:resourceState}" -o table

# Classic Azure Front Door (v1) profiles
az network front-door list --query "[].{name:name, resourceGroup:resourceGroup, location:location}" -o table

# Classic Azure Front Door WAF policies
az network front-door waf-policy list --query "[].{name:name, resourceGroup:resourceGroup, location:location}" -o table

# List Azure Front Door profiles
Get-AzFrontDoorCdnProfile | Select-Object Name, Location, ResourceGroupName

# List AFD endpoints
Get-AzFrontDoorCdnEndpoint -ProfileName <ProfileName> -ResourceGroupName <ResourceGroupName> | Select-Object Name, HostName, ResourceState

# Classic Azure Front Door (v1) profiles
Get-AzFrontDoor

# Classic Azure Front Door WAF policies
Get-AzFrontDoorWafPolicy -Name <policyName> -ResourceGroupName <resourceGroupName>

Azure Application Gateway and Azure Application Gateway WAF

Azure Application Gateway is a équilibreur de charge de trafic web that enables you to manage traffic to your web applications. It offers Layer 7 load balancing, SSL termination, and web application firewall (WAF) capabilities in the Application Delivery Controller (ADC) as a service. Key features include URL-based routing, cookie-based session affinity, and secure sockets layer (SSL) offloading, which are crucial for applications that require complex load-balancing capabilities like global routing and path-based routing.

Exemple :

Considérez un scénario où vous avez un site e-commerce qui comprend plusieurs sous-domaines pour différentes fonctions, comme les comptes utilisateur et le traitement des paiements. Azure Application Gateway can acheminer le trafic vers les serveurs web appropriés en fonction du chemin de l’URL. For example, traffic to example.com/accounts could be directed to the user accounts service, and traffic to example.com/pay could be directed to the payment processing service.
Et protégez votre site web des attaques en utilisant les capacités WAF.

Énumération

# List the Web Application Firewall configurations for your Application Gateways
az network application-gateway waf-config list --gateway-name <AppGatewayName> --resource-group <ResourceGroupName> --query "[].{name:name, firewallMode:firewallMode, ruleSetType:ruleSetType, ruleSetVersion:ruleSetVersion}" -o table

# List the Web Application Firewall configurations for your Application Gateways
(Get-AzApplicationGateway -Name <AppGatewayName> -ResourceGroupName <ResourceGroupName>).WebApplicationFirewallConfiguration

VNet Peering & HUB and Spoke topologies

VNet Peering

VNet Peering est une fonctionnalité d’Azure qui permet à différents Virtual Networks (VNets) d’être connectés directement et de manière transparente. Through VNet peering, resources in one VNet can communicate with resources in another VNet using private IP addresses, as if they were in the same network.
VNet Peering can also used with a on-prem networks by setting up a site-to-site VPN or Azure ExpressRoute.

Azure Hub and Spoke est une architecture réseau qui exploite VNet peering pour créer un Hub VNet central qui se connecte à plusieurs Spoke VNets. Le hub contient typiquement des services partagés (tels que firewalls, DNS, ou Active Directory) tandis que les spokes hébergent les workloads applicatifs. Ce modèle simplifie la gestion, renforce la sécurité via des contrôles centralisés et réduit la redondance.

Exemple :

Une grande entreprise avec plusieurs départements (Finance, HR, IT) peut créer un Hub VNet with shared services comme des firewalls et des serveurs DNS. Chaque département peut avoir son propre Spoke VNet qui se connecte au Hub via peering. Cela permet aux départements de communiquer de manière sécurisée et d’utiliser des services partagés sans exposer leurs ressources à l’internet public.

Enumeration

# List all VNets in your subscription
az network vnet list --query "[].{name:name, location:location, addressSpace:addressSpace}" -o table

# List VNet Peerings
az network vnet peering list --resource-group <ResourceGroupName> --vnet-name <VNetName> --query "[].{name:name, remoteVnetId:remoteVirtualNetwork.id, allowForwardedTraffic:allowForwardedTraffic, allowGatewayTransit:allowGatewayTransit}"

# List Shared Resources (e.g., Azure Firewall) in the Hub
az network firewall list --query "[].{name:name, location:location, resourceGroup:resourceGroup}" -o table

# List all VNets in your subscription
Get-AzVirtualNetwork

# List VNet Peerings
Get-AzVirtualNetworkPeering -ResourceGroupName <ResourceGroupName> -VirtualNetworkName <VNetName>

# List Shared Resources (e.g., Azure Firewall) in the Hub
Get-AzFirewall

VPN Site-à-Site

Un VPN Site-à-Site dans Azure établit une connexion sécurisée et persistante entre votre réseau sur site et votre Azure Virtual Network (VNet), permettant à des ressources telles que les VMs dans Azure d’apparaître comme si elles faisaient partie de votre réseau local. Cette connexion est établie via une passerelle VPN qui chiffre le trafic entre les deux réseaux.

Exemple:

Une entreprise dont le siège est à New York dispose d’un datacenter sur site qui doit se connecter de façon sécurisée à son VNet dans Azure, qui héberge ses workloads virtualisés. En configurant un VPN Site-à-Site, la société peut garantir une connectivité chiffrée entre les serveurs sur site et les VMs Azure, permettant d’accéder aux ressources de manière sécurisée à travers les deux environnements comme si elles étaient sur le même réseau local.

Énumération

# List VPN Gateways
az network vnet-gateway list --query "[].{name:name, location:location, resourceGroup:resourceGroup}" -o table

# List VPN Connections
az network vpn-connection list --gateway-name <VpnGatewayName> --resource-group <ResourceGroupName> --query "[].{name:name, connectionType:connectionType, connectionStatus:connectionStatus}" -o table

# List VPN Gateways
Get-AzVirtualNetworkGateway -ResourceGroupName <ResourceGroupName>

# List VPN Connections
Get-AzVirtualNetworkGatewayConnection -ResourceGroupName <ResourceGroupName>

Azure ExpressRoute

Azure ExpressRoute est un service qui fournit une connexion privée, dédiée et haut débit entre votre infrastructure sur site et les centres de données Azure. Cette connexion est établie via un fournisseur de connectivité, contournant l’internet public et offrant plus de fiabilité, des débits supérieurs, des latences plus faibles et une sécurité renforcée par rapport aux connexions Internet classiques.

Exemple :

Une multinationale nécessite une connexion cohérente et fiable à ses services Azure en raison du volume élevé de données et du besoin d’un débit important. L’entreprise choisit Azure ExpressRoute pour connecter directement son centre de données sur site à Azure, facilitant des transferts de données à grande échelle, tels que des sauvegardes quotidiennes et des analyses de données en temps réel, avec une confidentialité et une rapidité améliorées.

Énumération

# List ExpressRoute Circuits
az network express-route list --query "[].{name:name, location:location, resourceGroup:resourceGroup, serviceProviderName:serviceProviderName, peeringLocation:peeringLocation}" -o table

# List ExpressRoute Circuits
Get-AzExpressRouteCircuit

Références

• DNS OverDoS : Les Private Endpoints sont-ils trop privés ?
• Configuration DNS d’Azure Private Endpoint
• Private DNS : repli vers Internet

Tip

Apprenez & pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez & pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez & pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Soutenez HackTricks

• Consultez les subscription plans!
• Rejoignez le 💬 Discord group ou le telegram group ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des hacking tricks en soumettant des PRs aux HackTricks et HackTricks Cloud github repos.