Az - Rede Azure

Tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

• Confira os planos de assinatura!
• Junte-se ao 💬 grupo do Discord ou ao grupo do telegram ou siga-nos no Twitter 🐦 @hacktricks_live.
• Compartilhe truques de hacking enviando PRs para o HackTricks e HackTricks Cloud repositórios do github.

Informações Básicas

Azure fornece virtual networks (VNet) que permitem aos usuários criar redes isoladas dentro da nuvem Azure. Dentro dessas VNets, recursos como máquinas virtuais, aplicações, bancos de dados… podem ser hospedados e gerenciados com segurança. O networking no Azure suporta tanto a comunicação dentro da nuvem (entre serviços Azure) quanto a conexão com redes externas e a internet.
Além disso, é possível conectar VNets com outras VNets e com redes on-premises.

Rede Virtual (VNet) & Sub-redes

Uma Azure Virtual Network (VNet) é a representação da sua própria rede na nuvem, fornecendo isolamento lógico dentro do ambiente Azure dedicado à sua assinatura. VNets permitem provisionar e gerenciar virtual private networks (VPNs) no Azure, hospedando recursos como Virtual Machines (VMs), bancos de dados e application services. Elas oferecem controle total sobre as configurações de rede, incluindo intervalos de endereços IP, criação de subnets, route tables e network gateways.

Subnets são subdivisões dentro de uma VNet, definidas por intervalos de endereços IP específicos. Ao segmentar uma VNet em múltiplas subnets, você pode organizar e proteger recursos de acordo com sua arquitetura de rede.
Por padrão, todas as subnets dentro da mesma Azure Virtual Network (VNet) podem se comunicar entre si sem quaisquer restrições.

Exemplo:

• 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.

Enumeração

Para listar todas as VNets e subnets em uma conta Azure, você pode usar o Azure Command-Line Interface (CLI). Siga estes passos:

# 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

Network Security Groups (NSG)

Um Network Security Group (NSG) filtra o tráfego de rede de entrada e saída dos recursos do Azure dentro de uma Azure Virtual Network (VNet). Ele contém um conjunto de regras de segurança que podem indicar quais portas abrir para tráfego inbound e outbound por porta de origem, IP de origem, porta de destino, e é possível atribuir uma prioridade (quanto menor o número da prioridade, maior a prioridade).

NSGs podem ser associadas a subnets e NICs.

Exemplos de regras:

• Uma regra inbound permitindo tráfego HTTP (porta 80) de qualquer origem para seus servidores web.
• Uma regra outbound permitindo apenas tráfego SQL (porta 1433) para uma faixa específica de endereços IP de destino.

Enumeração

# 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 é um firewall gerenciado e stateful que filtra tráfego (L3–L7) para fluxos leste-oeste e norte-sul. Implantado no nível do VNet, centraliza a inspeção de todas as subnets e autoescala para disponibilidade.

Available SKUs: Basic, Standard, and Premium:

Enumeration

# 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 Tabelas de Rota

Azure Tabelas de Rota (UDR) permitem substituir o roteamento padrão definindo prefixos de destino (por exemplo, 10.0.0.0/16 ou 0.0.0.0/0) e um próximo salto (Virtual Network, Internet, Virtual Network Gateway, or Virtual Appliance).

As rotas são aplicadas no nível da sub-rede; todas as VMs nessa sub-rede seguem a tabela.

Exemplo:

• Para tráfego destinado à Internet, use o padrão 0.0.0.0/0 com Internet como próximo salto.
• Para inspecionar tráfego de saída, roteie 0.0.0.0/0 para um IP de Network Virtual Appliance (NVA).

Enumeração

# 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 é um serviço da Azure que habilita acesso privado a serviços do Azure ao garantir que o tráfego entre sua virtual network (VNet) do Azure e o serviço circule inteiramente pela backbone da Azure da Microsoft. Ele efetivamente traz o serviço para dentro da sua VNet. Essa configuração aumenta a segurança por não expor os dados à internet pública.

Private Link pode ser usado com vários serviços do Azure, como Azure Storage, Azure SQL Database e serviços customizados compartilhados via Private Link. Ele fornece uma maneira segura de consumir serviços a partir da sua própria VNet ou mesmo de diferentes subscriptions do Azure.

Caution

NSGs do not apply to private endpoints, which clearly means that associating an NSG with a subnet that contains the Private Link will have no effect.

Example:

Considere um cenário onde você tem um Azure SQL Database que deseja acessar de forma segura a partir da sua VNet. Normalmente, isso poderia envolver atravessar a internet pública. Com o Private Link, você pode criar um private endpoint na sua VNet que se conecta diretamente ao serviço Azure SQL Database. Esse endpoint faz com que o banco de dados pareça ser parte da sua própria VNet, acessível via um endereço IP privado, garantindo assim acesso seguro e privado.

Enumeração

# 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

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.

Fluxo de abuso (control-plane DoS):

1. Obter RBAC que permita criar Private Endpoints ou modificar Private DNS zone links.
2. Criar um Private Endpoint para o mesmo tipo de serviço em outra VNet (o Azure cria automaticamente a service Private DNS zone e a liga a essa VNet).
3. Vincular essa service Private DNS zone à VNet da vítima.
4. Como a VNet da vítima agora força a resolução via a Private DNS zone e nenhum registro A existe para o recurso alvo nessa zone, a resolução de nomes falha e o workload não consegue alcançar o endpoint (ainda público). Isso se aplica a qualquer serviço suportado por Private Link (storage, Key Vault, ACR, Cosmos DB, Function Apps, OpenAI, etc.).

Descoberta em escala (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 acessíveis por endpoint público mas sem Private Endpoint connections (provavelmente vão quebrar se o link acima for adicionado):

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 estendem o espaço de endereços privados da sua rede virtual e a identidade da sua VNet para Azure services por meio de uma conexão direta. Ao habilitar Service Endpoints, recursos na sua VNet podem conectar-se com segurança a Azure services, como Azure Storage e Azure SQL Database, pela Azure backbone network. Isso é particularmente útil quando combinado com Network Security Groups (NSGs) para controle granular de tráfego.

Exemplo:

• Com uma Storage Account e Service Endpoint habilitados em uma VNet, é possível permitir tráfego de entrada apenas de uma VNet no storage account firewall, forçando uma conexão segura sem precisar de acesso por IP público para o serviço de storage.

Service Endpoints não exigem endereços IP privados para os serviços e, em vez disso, dependem do Azure backbone para conectividade segura. Eles são mais fáceis de configurar em comparação com Private Links, mas não fornecem o mesmo nível de isolamento e granularidade que Private Links.

Enumeração

# 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

Diferenças Entre Service Endpoints e Private Links

Microsoft recomenda o uso de Private Links na docs:

Service Endpoints:

• O tráfego da sua VNet para o serviço Azure trafega pela rede backbone da Microsoft Azure, contornando a internet pública.
• O endpoint é uma conexão direta ao serviço Azure e não fornece um IP privado para o serviço dentro da VNet.
• O próprio serviço ainda é acessível pelo seu endpoint público fora da sua VNet, a menos que você configure o firewall do serviço para bloquear esse tráfego.
• É uma relação um-para-um entre a subnet e o serviço Azure.
• Menos caro do que Private Links.

Private Links:

• Private Link mapeia serviços Azure na sua VNet através de um private endpoint, que é uma interface de rede com um endereço IP privado dentro da sua VNet.
• O serviço Azure é acessado usando esse endereço IP privado, fazendo com que ele pareça parte da sua rede.
• Serviços conectados via Private Link podem ser acessados apenas a partir da sua VNet ou redes conectadas; não há acesso pela internet pública ao serviço.
• Isso possibilita uma conexão segura a serviços Azure ou aos seus próprios serviços hospedados em Azure, assim como conexão a serviços compartilhados por terceiros.
• Fornece um controle de acesso mais granular através de um private endpoint na sua VNet, ao contrário do controle de acesso mais amplo no nível de subnet com service endpoints.

Em resumo, embora tanto Service Endpoints quanto Private Links forneçam conectividade segura aos serviços Azure, Private Links oferecem um nível maior de isolamento e segurança ao garantir que os serviços sejam acessados de forma privada sem expô-los à internet pública. Service Endpoints, por outro lado, são mais fáceis de configurar para casos gerais onde é necessário um acesso simples e seguro aos serviços Azure sem a necessidade de um IP privado na VNet.

Azure Front Door (AFD) & AFD WAF

Azure Front Door é um ponto de entrada escalável e seguro para a entrega rápida das suas aplicações web globais. Ele combina vários serviços como aceleração de aplicações, SSL offloading e segurança na camada de aplicação (por meio do Web Application Firewall - WAF). É construído com base no conceito de edge POP (Point of Presence) ao redor do mundo para aproximar suas aplicações dos seus usuários.

Azure Front Door fornece uma rede globalmente distribuída de edge locations para rotear e acelerar o tráfego de entrada para suas aplicações web (no Azure ou em outros lugares), melhorar o desempenho e aprimorar a segurança.

Exemplo:

• Para uma plataforma de e-commerce global com usuários em todo o mundo, Azure Front Door pode armazenar em cache conteúdo estático em edge locations e oferecer SSL offloading, reduzindo a latência e proporcionando uma experiência de usuário mais responsiva. Além disso, ele fornece WAF para proteger suas aplicações contra vulnerabilidades web comuns (como SQL injection ou XSS).

Azure Front Door também oferece balanceamento de carga inteligente ao rotear o tráfego para o backend disponível mais próximo com base em sondas de integridade e latência, garantindo desempenho e disponibilidade consistentes. Ao integrar o WAF, ajuda a proteger contra ameaças web comuns.

Enumeração

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

Azure Application Gateway é um balanceador de carga de tráfego web que permite gerenciar o tráfego para suas aplicações web. Oferece balanceamento de carga na Camada 7, terminação SSL e capacidades de firewall de aplicações web (WAF) no Application Delivery Controller (ADC) como serviço. Recursos principais incluem roteamento baseado em URL, afinidade de sessão baseada em cookies e offloading de secure sockets layer (SSL), que são cruciais para aplicações que requerem capacidades complexas de balanceamento de carga como roteamento global e roteamento baseado em caminho.

Exemplo:

Considere um cenário em que você tem um site de e-commerce que inclui múltiplos subdomínios para funções diferentes, como contas de usuário e processamento de pagamentos. Azure Application Gateway pode rotear o tráfego para os servidores web apropriados com base no caminho da URL. Por exemplo, o tráfego para example.com/accounts pode ser direcionado para o serviço de contas de usuário, e o tráfego para example.com/pay pode ser direcionado para o serviço de processamento de pagamentos.
E proteja seu site de ataques usando as capacidades do WAF.

Enumeration

# 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 topologias

VNet Peering

VNet Peering é um recurso do Azure que permite que diferentes Redes Virtuais (Virtual Networks, VNets) sejam conectadas direta e de forma transparente. Através do VNet Peering, recursos em um VNet podem se comunicar com recursos em outro VNet usando endereços IP privados, como se estivessem na mesma rede.
VNet Peering também pode ser usado com redes on-prem configurando um site-to-site VPN ou Azure ExpressRoute.

Azure Hub and Spoke é uma arquitetura de rede que utiliza VNet peering para criar um Hub VNet central que se conecta a múltiplos Spoke VNets. O hub normalmente contém serviços compartilhados (como firewalls, DNS ou Active Directory), enquanto os spokes hospedam cargas de trabalho de aplicações. Esse desenho simplifica o gerenciamento, aumenta a segurança por meio de controles centralizados e reduz redundância.

Example:

Uma grande empresa com múltiplos departamentos (Finance, HR, IT) pode criar um Hub VNet com serviços compartilhados como firewalls e servidores DNS. Cada departamento pode ter seu próprio Spoke VNet que se conecta ao Hub via peering. Isso permite que os departamentos se comuniquem de forma segura e utilizem serviços compartilhados sem expor seus recursos à internet pública.

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

Site-to-Site VPN

Uma Site-to-Site VPN no Azure estabelece uma conexão segura e persistente entre sua rede on-premises e sua Azure Virtual Network (VNet), permitindo que recursos como VMs dentro do Azure apareçam como se estivessem na sua rede local. Essa conexão é estabelecida através de um VPN gateway que criptografa o tráfego entre as duas redes.

Exemplo:

Uma empresa com escritório central localizado em Nova York possui um data center on-premises que precisa se conectar de forma segura à sua VNet no Azure, que hospeda suas cargas de trabalho virtualizadas. Ao configurar uma Site-to-Site VPN, a empresa pode garantir conectividade criptografada entre os servidores on-premises e as VMs do Azure, permitindo que os recursos sejam acessados com segurança em ambos os ambientes como se estivessem na mesma rede local.

Enumeração

# 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 é um serviço que fornece uma conexão privada, dedicada e de alta velocidade entre sua infraestrutura on-premises e os data centers do Azure. Essa conexão é feita por meio de um provedor de conectividade, contornando a internet pública e oferecendo mais confiabilidade, velocidades maiores, latências mais baixas e maior segurança do que conexões típicas pela internet.

Exemplo:

Uma corporação multinacional necessita de uma conexão consistente e confiável com seus serviços Azure devido ao alto volume de dados e à necessidade de alta taxa de transferência. A empresa opta pelo Azure ExpressRoute para conectar diretamente seu data center on-premises ao Azure, facilitando transferências de dados em grande escala, como backups diários e análises de dados em tempo real, com maior privacidade e velocidade.

Enumeração

# 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

Referências

• DNS OverDoS: Endpoints privados são privados demais?
• Configuração DNS do Azure Private Endpoint
• Fallback do Private DNS para a internet

Tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

• Confira os planos de assinatura!
• Junte-se ao 💬 grupo do Discord ou ao grupo do telegram ou siga-nos no Twitter 🐦 @hacktricks_live.
• Compartilhe truques de hacking enviando PRs para o HackTricks e HackTricks Cloud repositórios do github.