Az - Azure-Netzwerk

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

• Überprüfen Sie die Abonnementpläne!
• Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @hacktricks_live.
• Teilen Sie Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repos senden.

Grundlegende Informationen

Azure bietet virtual networks (VNet), die es Benutzern ermöglichen, isolierte Netzwerke innerhalb der Azure-Cloud zu erstellen. Innerhalb dieser VNets können Ressourcen wie virtuelle Maschinen, Anwendungen, Datenbanken… sicher gehostet und verwaltet werden. Das Networking in Azure unterstützt sowohl die Kommunikation innerhalb der Cloud (zwischen Azure-Diensten) als auch die Verbindung zu externen Netzwerken und dem Internet.
Außerdem ist es möglich, VNets mit anderen VNets und mit lokalen Netzwerken zu verbinden.

Virtuelles Netzwerk (VNet) & Subnetze

Ein Azure Virtual Network (VNet) ist die Darstellung Ihres eigenen Netzwerks in der Cloud und bietet logische Isolation innerhalb der Azure-Umgebung, die Ihrem Abonnement zugeordnet ist. VNets ermöglichen es Ihnen, virtuelle private Netzwerke (VPNs) in Azure bereitzustellen und zu verwalten sowie Ressourcen wie Virtual Machines (VMs), Datenbanken und Anwendungsdienste zu hosten. Sie bieten volle Kontrolle über Netzwerkeinstellungen, einschließlich IP-Adressbereichen, Erstellung von Subnetzen, Routentabellen und Netzwerkgateways.

Subnetze sind Unterteilungen innerhalb eines VNet, die durch spezifische IP-Adressbereiche definiert werden. Durch die Segmentierung eines VNet in mehrere Subnetze können Sie Ressourcen entsprechend Ihrer Netzwerkarchitektur organisieren und absichern.
Standardmäßig können alle Subnetze innerhalb desselben Azure Virtual Network (VNet) ohne Einschränkungen miteinander kommunizieren.

Beispiel:

• MyVNet mit einem IP-Adressbereich von 10.0.0.0/16.
• Subnet-1: 10.0.0.0/24 für Webserver.
• Subnet-2: 10.0.1.0/24 für Datenbankserver.

Auflistung

Um alle VNets und Subnetze in einem Azure-Konto aufzulisten, können Sie die Azure Command-Line Interface (CLI) verwenden. Hier sind die Schritte:

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

Eine Network Security Group (NSG) filtert den Netzwerkverkehr sowohl zu als auch von Azure-Ressourcen innerhalb eines Azure Virtual Network (VNet). Sie enthält eine Reihe von Sicherheitsregeln, die angeben können, welche Ports für eingehenden und ausgehenden Verkehr nach Quellport, Quell-IP und Zielport zu öffnen sind. Außerdem kann eine Priorität zugewiesen werden (je niedriger die Prioritätsnummer, desto höher die Priorität).

NSGs können mit Subnetzen und NICs verknüpft werden.

Beispielregeln:

• Eine eingehende Regel, die HTTP-Verkehr (Port 80) von jeder Quelle zu Ihren Webservern erlaubt.
• Eine ausgehende Regel, die nur SQL-Verkehr (Port 1433) zu einem bestimmten Ziel-IP-Adressbereich erlaubt.

Aufzählung

# 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 ist eine verwaltete, zustandsbehaftete Firewall, die den Datenverkehr (L3–L7) für Ost-West- und Nord-Süd-Flows filtert. Auf VNet-Ebene bereitgestellt, zentralisiert sie die Inspektion für alle Subnetze und skaliert automatisch für Verfügbarkeit.

Verfügbare SKUs: Basic, Standard, und 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 Routingtabellen

Azure Routingtabellen (UDR) ermöglichen es, das Standard-Routing zu überschreiben, indem Zielpräfixe definiert werden (z. B. 10.0.0.0/16 oder 0.0.0.0/0) und ein nächster Hop festgelegt wird (Virtual Network, Internet, Virtual Network Gateway oder Virtual Appliance).

Routen gelten auf Subnetz-Ebene; alle VMs in diesem Subnetz folgen der Tabelle.

Beispiel:

• Für internet-gebundenen Traffic verwenden Sie das Standard-0.0.0.0/0 mit Internet als nächsten Hop.
• Um ausgehenden Traffic zu inspizieren, routen Sie 0.0.0.0/0 an eine Network Virtual Appliance (NVA)-IP.

Enumeration

# 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 ist ein Service in Azure, der privaten Zugriff auf Azure-Dienste ermöglicht, indem er sicherstellt, dass der Datenverkehr zwischen Ihrem Azure virtual network (VNet) und dem Dienst vollständig innerhalb des Azure-Backbone-Netzwerks von Microsoft verläuft. Er bringt den Dienst effektiv in Ihr VNet. Diese Konfiguration erhöht die Sicherheit, da die Daten nicht dem öffentlichen Internet ausgesetzt werden.

Private Link kann mit verschiedenen Azure-Diensten verwendet werden, wie Azure Storage, Azure SQL Database und benutzerdefinierten Diensten, die über Private Link geteilt werden. Es bietet eine sichere Möglichkeit, Dienste aus Ihrem eigenen VNet oder sogar aus verschiedenen Azure-Subscriptions zu konsumieren.

Caution

NSGs gelten nicht für private endpoints, was eindeutig bedeutet, dass die Zuordnung einer NSG zu einem Subnetz, das das Private Link enthält, keine Wirkung hat.

Beispiel:

Betrachten Sie ein Szenario, in dem Sie eine Azure SQL Database haben, auf die Sie sicher von Ihrem VNet aus zugreifen möchten. Normalerweise würde dies das Durchqueren des öffentlichen Internets erfordern. Mit Private Link können Sie einen private endpoint in Ihrem VNet erstellen, der direkt mit dem Azure SQL Database-Dienst verbunden ist. Dieser Endpoint lässt die Datenbank so erscheinen, als wäre sie Teil Ihres eigenen VNet und über eine private IP-Adresse erreichbar, wodurch sicherer und privater Zugriff gewährleistet wird.

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

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.

Missbrauchsablauf (control-plane DoS):

1. Erlange RBAC-Berechtigungen, die das Erstellen von Private Endpoints oder das Ändern von Private DNS zone links erlauben.
2. Erstelle ein Private Endpoint für denselben Diensttyp in einem anderen VNet (Azure erstellt automatisch die service Private DNS zone und verknüpft sie mit diesem VNet).
3. Verknüpfe diese service Private DNS zone mit dem Ziel-VNet.
4. Weil das Ziel-VNet nun die Auflösung über die Private DNS zone erzwingt und kein A-Record für die Zielressource in dieser Zone existiert, schlägt die Namensauflösung fehl und die Workload kann den (weiterhin public) endpoint nicht erreichen. Dies gilt für jeden Private Link–unterstützten Dienst (storage, Key Vault, ACR, Cosmos DB, Function Apps, OpenAI, etc.).

Erkennung im großen Maßstab (Azure Resource Graph):

• VNETs, die mit der blob Private DNS zone verlinkt sind (erzwingt Auflösung für 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 erreichbar über public endpoint aber ohne Private Endpoint connections (bricht wahrscheinlich, wenn der obige Link hinzugefügt wird):

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 erweitern den privaten Adressraum Ihres virtuellen Netzwerks und die Identität Ihres VNet auf Azure services über eine direkte Verbindung. Durch das Aktivieren von Service Endpoints können Ressourcen in Ihrem VNet sicher mit Azure services wie Azure Storage und Azure SQL Database über das Azure-Backbone-Netzwerk verbunden werden. Dies ist besonders nützlich in Kombination mit Network Security Groups (NSGs) für eine granulare Steuerung des Datenverkehrs.

Beispiel:

• Wenn ein Storage Account und Service Endpoint aktiviert in a VNET sind, ist es möglich, eingehenden Verkehr nur von einem VNET in der storage account firewall zuzulassen, wodurch eine sichere Verbindung erzwungen wird, ohne dass für den Storage-Dienst public IP-Zugriff erforderlich ist.

Service Endpoints require keine privaten IP-Adressen für die Dienste und verlassen sich stattdessen auf das Azure-Backbone für sichere Konnektivität. Sie sind im Vergleich zu Private Links einfacher einzurichten, bieten jedoch nicht dasselbe Maß an Isolation und Granularität wie 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

Unterschiede zwischen Service Endpoints und Private Links

Microsoft empfiehlt die Verwendung von Private Links in den docs:

Service Endpoints:

• Traffic von Ihrem VNet zum Azure-Dienst verläuft über das Microsoft Azure backbone network und umgeht das öffentliche Internet.
• Der Endpoint ist eine direkte Verbindung zum Azure-Dienst und stellt keine private IP für den Dienst innerhalb des VNet bereit.
• Der Dienst selbst ist weiterhin über seinen öffentlichen Endpoint von außerhalb Ihres VNet zugänglich, es sei denn, Sie konfigurieren die Service-Firewall, um solchen Traffic zu blockieren.
• Es besteht eine Eins-zu-eins-Beziehung zwischen dem Subnet und dem Azure-Dienst.
• Günstiger als Private Links.

Private Links:

• Private Link mappt Azure-Dienste in Ihr VNet über einen privaten Endpoint, der ein Network Interface mit einer privaten IP-Adresse innerhalb Ihres VNet ist.
• Auf den Azure-Dienst wird über diese private IP-Adresse zugegriffen, wodurch er so erscheint, als wäre er Teil Ihres Netzwerks.
• Dienste, die über Private Link verbunden sind, können nur von Ihrem VNet oder verbundenen Netzwerken aus erreicht werden; es gibt keinen Zugriff über das öffentliche Internet auf den Dienst.
• Es ermöglicht eine sichere Verbindung zu Azure-Diensten oder Ihren eigenen in Azure gehosteten Diensten sowie eine Verbindung zu von anderen geteilten Diensten.
• Es bietet granulare Zugriffskontrolle über einen privaten Endpoint in Ihrem VNet, im Gegensatz zur breiteren Zugriffskontrolle auf Subnet-Ebene bei Service Endpoints.

Zusammenfassend bieten sowohl Service Endpoints als auch Private Links eine sichere Konnektivität zu Azure-Diensten, jedoch bieten Private Links ein höheres Maß an Isolation und Sicherheit, indem sie sicherstellen, dass Dienste privat erreicht werden, ohne sie dem öffentlichen Internet auszusetzen. Service Endpoints hingegen sind einfacher einzurichten für allgemeine Fälle, in denen ein einfacher, sicherer Zugriff auf Azure-Dienste benötigt wird, ohne dass eine private IP im VNet erforderlich ist.

Azure Front Door (AFD) & AFD WAF

Azure Front Door ist ein skalierbarer und sicherer Einstiegspunkt für die schnelle Bereitstellung Ihrer globalen Webanwendungen. Es kombiniert verschiedene Dienste wie application acceleration, SSL offloading, and application layer security (durch Web Application Firewall - WAF). Es basiert auf dem Konzept von edge POP (Point of Presence)-Standorten rund um die Welt, um Ihre Anwendungen näher zu Ihren Nutzern zu bringen.

Azure Front Door stellt ein global verteiltes Netzwerk von Edge-Standorten bereit, um eingehenden Traffic zu Ihren Webanwendungen (in Azure oder anderswo) zu routen und zu beschleunigen, die Performance zu verbessern und die Sicherheit zu erhöhen.

Beispiel:

• Für eine globale E-Commerce-Plattform mit Nutzern weltweit kann Azure Front Door statische Inhalte an Edge-Standorten cachen und SSL offloading anbieten, wodurch Latenz reduziert und ein reaktionsschnelleres Nutzererlebnis erzielt wird. Zusätzlich bietet es WAF, um Ihre Anwendungen vor gängigen Web-Schwachstellen (wie SQL injection oder XSS) zu schützen.

Azure Front Door bietet außerdem smart load balancing, indem Traffic basierend auf Health-Probes und Latenz an das nächstverfügbare Backend geroutet wird, wodurch eine konsistente Performance und Verfügbarkeit sichergestellt wird. Durch die Integration von WAF hilft es, gegen gängige Web-Bedrohungen zu schützen.

Aufzählung

# 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 ist ein Load Balancer für Web-Traffic, der es Ihnen ermöglicht, den Traffic zu Ihren Web-Anwendungen zu verwalten. Er bietet Layer 7 load balancing, SSL termination und web application firewall (WAF)-Funktionen im Application Delivery Controller (ADC) als Service. Wichtige Merkmale sind URL-basiertes Routing, cookie-basierte Session-Affinität und Secure Sockets Layer (SSL) Offloading, die für Anwendungen, die komplexe Load-Balancing-Funktionen wie globales Routing und pfadbasiertes Routing benötigen, entscheidend sind.

Beispiel:

Betrachten Sie ein Szenario, in dem Sie eine E-Commerce-Website haben, die mehrere Subdomains für verschiedene Funktionen enthält, wie Benutzerkonten und Zahlungsabwicklung. Azure Application Gateway kann den Traffic basierend auf dem URL-Pfad an die entsprechenden Webserver routen. Zum Beispiel könnte Traffic an example.com/accounts an den Service für Benutzerkonten geleitet werden, und Traffic an example.com/pay an den Zahlungsabwicklungsdienst.
Und schützen Sie Ihre Website vor Angriffen mithilfe der WAF-Funktionen.

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 Topologien

VNet Peering

VNet Peering ist eine Funktion in Azure, die ermöglicht, verschiedene Virtual Networks (VNets) direkt und nahtlos zu verbinden. Durch VNet Peering können Ressourcen in einem VNet mit Ressourcen in einem anderen VNet über private IP-Adressen kommunizieren, als wären sie im selben Netzwerk.
VNet Peering kann auch mit On-Prem-Netzwerken verwendet werden, indem ein site-to-site VPN oder Azure ExpressRoute eingerichtet wird.

Azure Hub and Spoke ist eine Netzwerkarchitektur, die VNet Peering nutzt, um ein zentrales Hub VNet zu erstellen, das sich mit mehreren Spoke VNets verbindet. Der Hub enthält typischerweise gemeinsam genutzte Dienste (wie Firewalls, DNS oder Active Directory), während die Spokes Anwendungs-Workloads hosten. Dieses Design vereinfacht die Verwaltung, erhöht die Sicherheit durch zentralisierte Kontrollen und reduziert Redundanzen.

Beispiel:

Ein großes Unternehmen mit mehreren Abteilungen (Finance, HR, IT) kann ein Hub VNet mit gemeinsamen Diensten wie Firewalls und DNS-Servern erstellen. Jede Abteilung kann ihr eigenes Spoke VNet haben, das über Peering mit dem Hub verbunden ist. Dadurch können die Abteilungen sicher kommunizieren und gemeinsam genutzte Dienste nutzen, ohne ihre Ressourcen dem öffentlichen Internet preiszugeben.

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

Ein Site-to-Site VPN in Azure stellt eine sichere und persistente Verbindung von Ihrem On-Premises-Netzwerk zu Ihrem Azure Virtual Network (VNet) her, wodurch Ressourcen wie VMs in Azure so erscheinen, als wären sie in Ihrem lokalen Netzwerk. Diese Verbindung wird über ein VPN-Gateway hergestellt, das den Datenverkehr zwischen den beiden Netzwerken verschlüsselt.

Beispiel:

Ein Unternehmen mit seinem Hauptsitz in New York hat ein lokales Rechenzentrum, das eine sichere Verbindung zu seinem VNet in Azure benötigt, das seine virtualisierten Workloads hostet. Durch die Einrichtung eines Site-to-Site VPN kann das Unternehmen verschlüsselte Konnektivität zwischen den On-Premises-Servern und den Azure VMs sicherstellen, sodass Ressourcen in beiden Umgebungen sicher genutzt werden können, als wären sie im selben lokalen Netzwerk.

Enumeration

# 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 ist ein Dienst, der eine private, dedizierte Hochgeschwindigkeitsverbindung zwischen Ihrer lokalen Infrastruktur und Azure-Rechenzentren bereitstellt. Diese Verbindung wird über einen Konnektivitätsanbieter hergestellt, um das öffentliche Internet zu umgehen, und bietet mehr Zuverlässigkeit, höhere Geschwindigkeiten, niedrigere Latenzen und höhere Sicherheit als typische Internetverbindungen.

Beispiel:

Ein multinationales Unternehmen benötigt aufgrund des hohen Datenvolumens und des Bedarfs an hohem Durchsatz eine konstante und zuverlässige Verbindung zu seinen Azure-Diensten. Das Unternehmen entscheidet sich für Azure ExpressRoute, um sein lokales Rechenzentrum direkt mit Azure zu verbinden und so großflächige Datenübertragungen zu ermöglichen, wie tägliche Backups und Echtzeitdatenanalysen, mit verbesserter Privatsphäre und höherer Geschwindigkeit.

Enumeration

# 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

Referenzen

• DNS OverDoS: Sind Private Endpoints zu privat?
• Azure Private Endpoint DNS-Konfiguration
• Private DNS-Fallback zum Internet

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

• Überprüfen Sie die Abonnementpläne!
• Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @hacktricks_live.
• Teilen Sie Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repos senden.