Az - Azure Network

Tip

Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

• Consulta los subscription plans!
• Únete al 💬 Discord group o al telegram group o síguenos en Twitter 🐦 @hacktricks_live.
• Comparte trucos de hacking enviando PRs a los HackTricks y HackTricks Cloud github repos.

Basic Information

Azure proporciona virtual networks (VNet) que permiten a los usuarios crear redes aisladas dentro de la nube de Azure. Dentro de estos VNet, recursos como máquinas virtuales, aplicaciones, bases de datos… pueden alojarse y gestionarse de forma segura. La red en Azure soporta tanto la comunicación dentro de la nube (entre servicios de Azure) como la conexión con redes externas e internet.
Además, es posible conectar VNets con otros VNets y con redes on-premise.

Virtual Network (VNET) & Subnets

Una Azure Virtual Network (VNet) representa tu propia red en la nube, proporcionando aislamiento lógico dentro del entorno de Azure dedicado a tu suscripción. Los VNets permiten aprovisionar y gestionar virtual private networks (VPNs) en Azure, alojando recursos como Virtual Machines (VMs), bases de datos y servicios de aplicaciones. Ofrecen control total sobre la configuración de la red, incluyendo rangos de direcciones IP, creación de subredes, tablas de enrutamiento y gateways de red.

Subnets son subdivisiones dentro de un VNet, definidas por rangos específicos de direcciones IP. Al segmentar un VNet en múltiples subredes, puedes organizar y asegurar los recursos según tu arquitectura de red.
Por defecto, todas las subredes dentro de la misma Azure Virtual Network (VNet) pueden comunicarse entre sí sin restricciones.

Example:

• MyVNet with an IP address range of 10.0.0.0/16.
• Subnet-1: 10.0.0.0/24 para servidores web.
• Subnet-2: 10.0.1.0/24 para servidores de bases de datos.

Enumeration

Para listar todos los VNets y subredes en una cuenta de Azure, puedes usar la Azure Command-Line Interface (CLI). Aquí están los pasos:

# 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

Grupos de seguridad de red (NSG)

Un Grupo de seguridad de red (NSG) filtra el tráfico de red tanto hacia como desde recursos de Azure dentro de una Azure Virtual Network (VNet). Contiene un conjunto de reglas de seguridad que pueden indicar qué puertos abrir para tráfico entrante y saliente según el puerto de origen, la IP de origen, el puerto de destino y es posible asignar una prioridad (cuanto menor sea el número de prioridad, mayor será la prioridad).

Los NSG se pueden asociar a subredes y NICs.

Ejemplos de reglas:

• Una regla entrante que permita tráfico HTTP (port 80) desde cualquier origen hacia tus servidores web.
• Una regla saliente que permita solo tráfico SQL (port 1433) hacia un rango de direcciones IP de destino específico.

Enumeración

# 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 es un firewall gestionado y con estado que filtra tráfico (L3–L7) para flujos este-oeste y norte-sur. Desplegado a nivel de VNet, centraliza la inspección de todas las subredes y se autoescala para garantizar la disponibilidad.

Available SKUs: Basic, Standard, and Premium:

Enumeración

# 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) te permiten sobrescribir el enrutamiento por defecto definiendo prefijos de destino (p. ej., 10.0.0.0/16 o 0.0.0.0/0) y un siguiente salto (Virtual Network, Internet, Virtual Network Gateway, o Virtual Appliance).

Las rutas se aplican a nivel de subred; todas las VMs en esa subred siguen la tabla.

Ejemplo:

• Para tráfico con destino a internet, usa el 0.0.0.0/0 por defecto con Internet como siguiente salto.
• Para inspeccionar tráfico saliente, enruta 0.0.0.0/0 a una IP de Network Virtual Appliance (NVA).

Enumeración

# 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 es un servicio en Azure que habilita el acceso privado a los servicios de Azure asegurando que el tráfico entre tu red virtual de Azure (VNet) y el servicio viaje completamente dentro de la red troncal de Azure de Microsoft. Efectivamente, trae el servicio a tu VNet. Esta configuración mejora la seguridad al no exponer los datos a la Internet pública.

Private Link se puede usar con varios servicios de Azure, como Azure Storage, Azure SQL Database y servicios personalizados compartidos vía Private Link. Proporciona una forma segura de consumir servicios desde dentro de tu propia VNet o incluso desde diferentes suscripciones de Azure.

Caution

Las NSGs no se aplican a los endpoints privados, lo que claramente significa que asociar una NSG con una subred que contiene el Private Link no tendrá ningún efecto.

Ejemplo:

Considera un escenario donde tienes una Azure SQL Database a la que quieres acceder de forma segura desde tu VNet. Normalmente, esto podría implicar atravesar la Internet pública. Con Private Link, puedes crear un endpoint privado en tu VNet que se conecte directamente al servicio Azure SQL Database. Este endpoint hace que la base de datos parezca parte de tu propia VNet, accesible mediante una dirección IP privada, garantizando así un acceso seguro y privado.

Enumeración

# 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 a través de service Private DNS zone links

When a VNet has a Virtual Network Link to a service Private DNS zone (e.g., privatelink.blob.core.windows.net), Azure forces hostname resolution for Private Link registered resources of that service type through the zone. If the zone lacks the required A record for a resource that workloads still access via its public endpoint, DNS resolution returns NXDOMAIN and clients never reach the public IP, causing an availability DoS without touching the resource itself.

Flujo de abuso (control-plane DoS):

1. Obtener RBAC que permita crear Private Endpoints o modificar Private DNS zone links.
2. Crear un Private Endpoint para el mismo tipo de servicio en otra VNet (Azure crea automáticamente la service Private DNS zone y la enlaza a esa VNet).
3. Enlazar esa service Private DNS zone a la VNet víctima.
4. Porque la VNet víctima ahora forza la resolución vía la Private DNS zone y no existe un A record para el recurso objetivo en esa zona, la resolución de nombres falla y la carga de trabajo no puede alcanzar el endpoint (que sigue siendo público). Esto se aplica a cualquier servicio compatible con Private Link (storage, Key Vault, ACR, Cosmos DB, Function Apps, OpenAI, etc.).

Discovery at scale (Azure Resource Graph):

• VNETs enlazadas a la blob Private DNS zone (resolución forzada para 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 accesibles a través de un endpoint público pero sin conexiones Private Endpoint (probablemente se rompa si se añade el enlace anterior):

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 extienden el espacio de direcciones privadas de tu red virtual y la identidad de tu VNet a los servicios de Azure mediante una conexión directa. Al habilitar service endpoints, los recursos en tu VNet pueden conectarse de forma segura a los servicios de Azure, como Azure Storage y Azure SQL Database, a través de la red troncal de Azure. Esto es particularmente útil cuando se combina con Network Security Groups (NSGs) para un control granular del tráfico.

Ejemplo:

• Con una Storage Account y Service Endpoint habilitados en una VNET, es posible permitir tráfico entrante solo desde una VNET en el storage account firewall, forzando una conexión segura sin necesitar acceso por IP pública para el servicio de storage.

Service Endpoints no requieren direcciones IP privadas para los servicios y, en su lugar, dependen de la red troncal de Azure para la conectividad segura. Son más fáciles de configurar en comparación con Private Links, pero no ofrecen el mismo nivel de aislamiento y granularidad que Private Links.

Enumeración

# 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

Diferencias entre Service Endpoints y Private Links

Microsoft recomienda usar Private Links en la docs:

Service Endpoints:

• El tráfico desde tu VNet hacia el servicio de Azure viaja por la red backbone de Microsoft Azure, evitando el internet público.
• El endpoint es una conexión directa al servicio de Azure y no proporciona una IP privada para el servicio dentro de la VNet.
• El servicio en sí sigue siendo accesible a través de su endpoint público desde fuera de tu VNet a menos que configures el firewall del servicio para bloquear ese tráfico.
• Es una relación uno a uno entre la subred y el servicio de Azure.
• Menos costoso que Private Links.

Private Links:

• Private Link mapea los servicios de Azure dentro de tu VNet mediante un private endpoint, que es una interfaz de red con una dirección IP privada dentro de tu VNet.
• El servicio de Azure se accede usando esta dirección IP privada, haciendo que parezca parte de tu red.
• Los servicios conectados mediante Private Link solo pueden ser accedidos desde tu VNet o redes conectadas; no hay acceso desde el internet público al servicio.
• Permite una conexión segura a servicios de Azure o a tus propios servicios alojados en Azure, así como una conexión a servicios compartidos por terceros.
• Proporciona un control de acceso más granular a través de un private endpoint en tu VNet, en contraposición al control de acceso más amplio a nivel de subred con Service Endpoints.

En resumen, aunque tanto Service Endpoints como Private Links ofrecen conectividad segura a servicios de Azure, Private Links ofrecen un mayor nivel de aislamiento y seguridad al garantizar que los servicios se accedan de forma privada sin exponerlos al internet público. Por otro lado, Service Endpoints son más fáciles de configurar para casos generales en los que se requiere un acceso simple y seguro a los servicios de Azure sin la necesidad de una IP privada en la VNet.

Azure Front Door (AFD) & AFD WAF

Azure Front Door es un punto de entrada escalable y seguro para la entrega rápida de tus aplicaciones web globales. Combina varios servicios como aceleración de aplicaciones, terminación de SSL, y seguridad a nivel de aplicación (a través de Web Application Firewall - WAF). Está construido sobre el concepto de ubicaciones edge POP (Point of Presence) alrededor del mundo para acercar tus aplicaciones a tus usuarios.

Azure Front Door proporciona una red de ubicaciones edge distribuida globalmente para encaminar y acelerar el tráfico entrante hacia tus aplicaciones web (en Azure o en otros lugares), mejorar el rendimiento y aumentar la seguridad.

Ejemplo:

• Para una plataforma de comercio electrónico global con usuarios en todo el mundo, Azure Front Door puede almacenar en caché contenido estático en ubicaciones edge y ofrecer terminación de SSL, reduciendo la latencia y proporcionando una experiencia de usuario más rápida. Además, proporciona WAF para proteger tus aplicaciones contra vulnerabilidades web comunes (como SQL injection o XSS).

Azure Front Door también ofrece balanceo de carga inteligente al encaminar el tráfico al backend disponible más cercano basándose en sondas de salud y latencia, asegurando un rendimiento y disponibilidad consistentes. Al integrar WAF, ayuda a proteger contra amenazas web comunes.

Enumeración

# 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 y Azure Application Gateway WAF

Azure Application Gateway es un balanceador de carga de tráfico web que te permite gestionar el tráfico hacia tus aplicaciones web. Ofrece Layer 7 load balancing, SSL termination, and web application firewall (WAF) capabilities en el Application Delivery Controller (ADC) como servicio. Las características clave incluyen enrutamiento basado en URL, afinidad de sesión basada en cookies y offloading de SSL, que son cruciales para aplicaciones que requieren capacidades complejas de balanceo de carga como enrutamiento global y enrutamiento basado en rutas.

Ejemplo:

Considera un escenario donde tienes un sitio de e-commerce que incluye múltiples subdominios para diferentes funciones, como cuentas de usuario y procesamiento de pagos. Azure Application Gateway puede enrutar el tráfico a los servidores web apropiados según la ruta URL. Por ejemplo, el tráfico a example.com/accounts podría dirigirse al servicio de cuentas de usuario, y el tráfico a example.com/pay podría dirigirse al servicio de procesamiento de pagos.
Y protege tu sitio web de ataques usando las capacidades del WAF.

Enumeración

# 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 & topologías Hub and Spoke

VNet Peering

VNet Peering es una característica de Azure que permite que diferentes Virtual Networks (VNets) se conecten de forma directa y transparente. A través de VNet Peering, los recursos en una VNet pueden comunicarse con recursos en otra VNet usando direcciones IP privadas, como si estuvieran en la misma red.
VNet Peering también puede usarse con redes on-prem configurando un site-to-site VPN o Azure ExpressRoute.

Azure Hub and Spoke es una arquitectura de red que aprovecha VNet peering para crear un Hub VNet central que se conecta a múltiples Spoke VNets. El hub típicamente contiene servicios compartidos (como firewalls, DNS o Active Directory) mientras que los spokes alojan cargas de trabajo de aplicaciones. Este diseño simplifica la gestión, mejora la seguridad mediante controles centralizados y reduce la redundancia.

Ejemplo:

Una gran empresa con múltiples departamentos (Finanzas, RRHH, TI) puede crear un Hub VNet con servicios compartidos como firewalls y servidores DNS. Cada departamento puede tener su propio Spoke VNet que se conecta al Hub mediante peering. Esto permite a los departamentos comunicarse de forma segura y usar servicios compartidos sin exponer sus recursos a la internet pública.

Enumeración

# 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

Site-to-Site VPN

Una Site-to-Site VPN en Azure establece una conexión segura y persistente desde su red on-premises a su Azure Virtual Network (VNet), permitiendo que recursos como las VMs dentro de Azure parezcan estar en su red local. Esta conexión se establece a través de una VPN gateway que cifra el tráfico entre las dos redes.

Ejemplo:

Una empresa con su oficina principal ubicada en New York tiene un data center on-premises que necesita conectarse de forma segura a su VNet en Azure, que aloja sus cargas de trabajo virtualizadas. Al configurar una Site-to-Site VPN, la empresa puede asegurar conectividad cifrada entre los servidores on-premises y las VMs en Azure, permitiendo que los recursos se accedan de forma segura en ambos entornos como si estuvieran en la misma red local.

Enumeración

# 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 es un servicio que proporciona una conexión privada, dedicada y de alta velocidad entre tu infraestructura on-premises y los centros de datos de Azure. Esta conexión se realiza a través de un proveedor de conectividad, evitando la internet pública y ofreciendo mayor fiabilidad, velocidades más altas, menores latencias y mayor seguridad que las conexiones a internet típicas.

Ejemplo:

Una corporación multinacional necesita una conexión consistente y fiable a sus servicios de Azure debido al alto volumen de datos y a la necesidad de un alto rendimiento. La empresa opta por Azure ExpressRoute para conectar directamente su centro de datos on-premises a Azure, facilitando transferencias de datos a gran escala, como copias de seguridad diarias y análisis de datos en tiempo real, con mayor privacidad y velocidad.

Enumeración

# 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

Referencias

• DNS OverDoS: ¿Son los Private Endpoints demasiado privados?
• Configuración DNS de Azure Private Endpoint
• Fallback de Private DNS a Internet

Tip

Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

• Consulta los subscription plans!
• Únete al 💬 Discord group o al telegram group o síguenos en Twitter 🐦 @hacktricks_live.
• Comparte trucos de hacking enviando PRs a los HackTricks y HackTricks Cloud github repos.