Az - Storage Accounts & Blobs

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks

• Sprawdź subscription plans!
• Dołącz do 💬 Discord group lub telegram group lub śledź nas na Twitterze 🐦 @hacktricks_live.
• Podziel się hacking tricks, zgłaszając PRy do HackTricks i HackTricks Cloud github repos.

Podstawowe informacje

Azure Storage Accounts to podstawowe usługi w Microsoft Azure, które zapewniają skalowalną, bezpieczną i wysoko dostępną chmurową przestrzeń do przechowywania różnych typów danych, w tym blobów (binary large objects), plików, kolejek i tabel. Służą jako kontenery grupujące te różne usługi storage pod jedną przestrzenią nazw dla ułatwionego zarządzania.

Główne opcje konfiguracji:

• Każdy storage account musi mieć unikalną nazwę w całym Azure.
• Każdy storage account jest wdrażany w określonym regionie lub w rozszerzonej strefie Azure.
• Można wybrać wersję premium storage account dla lepszej wydajności.
• Można wybrać spośród 4 typów redundancji, aby chronić przed awariami rack, dysku i centrum danych.

Opcje konfiguracji bezpieczeństwa:

• Require secure transfer for REST API operations: Wymaga TLS w całej komunikacji ze storage.
• Allows enabling anonymous access on individual containers: Jeśli wyłączone, w przyszłości nie będzie możliwe włączenie anonimowego dostępu.
• Enable storage account key access: Jeśli wyłączone, dostęp przy użyciu Shared Keys będzie zabroniony.
• Minimum TLS version
• Permitted scope for copy operations: Pozwala z dowolnego storage account, z dowolnego storage account z tego samego Entra tenant lub z storage account z private endpoints w tej samej virtual network.

Opcje Blob Storage:

• Allow cross-tenant replication
• Access tier: Hot (często dostępne dane), Cool i Cold (rzadko dostępne dane)

Opcje sieciowe:

• Network access:
• Allow from all networks
• Allow from selected virtual networks and IP addresses
• Disable public access and use private access
• Private endpoints: Pozwala na prywatne połączenie ze storage account z virtual network

Opcje ochrony danych:

• Point-in-time restore for containers: Pozwala przywrócić container do wcześniejszego stanu.
• Wymaga włączenia versioning, change feed i blob soft delete.
• Enable soft delete for blobs: Włącza okres retencji w dniach dla usuniętych blobów (nawet nadpisanych).
• Enable soft delete for containers: Włącza okres retencji w dniach dla usuniętych containers.
• Enable soft delete for file shares: Włącza okres retencji w dniach dla usuniętych file shares.
• Enable versioning for blobs: Zachowuje poprzednie wersje blobów.
• Enable blob change feed: Przechowuje logi tworzenia, modyfikacji i usuwania blobów.
• Enable version-level immutability support: Pozwala ustawić politykę retencji czasowej na poziomie konta, która będzie miała zastosowanie do wszystkich wersji blobów.
• Version-level immutability support i point-in-time restore for containers nie mogą być włączone jednocześnie.

Opcje szyfrowania:

• Encryption type: Można użyć Microsoft-managed keys (MMK) lub Customer-managed keys (CMK).
• Enable infrastructure encryption: Pozwala podwójnie zaszyfrować dane „dla większego bezpieczeństwa”.

Storage endpoints

Publiczna ekspozycja

Jeśli opcja “Allow Blob public access” jest włączona (domyślnie wyłączona), podczas tworzenia container można:

• Nadać public access to read blobs (trzeba znać nazwę).
• List container blobs i je czytać.
• Ustawić go jako całkowicie private.

Statyczna strona ($web) — ekspozycja & leaked secrets

• Static websites są serwowane z specjalnego kontenera $web przez endpoint specyficzny dla regionu, taki jak https://<account>.z13.web.core.windows.net/.
• Kontener $web może raportować publicAccess: null poprzez blob API, ale pliki nadal są dostępne przez static site endpoint, więc umieszczanie artefaktów konfiguracyjnych/IaC tam może spowodować leak of secrets.
• Szybki proces audytu:

# Identify storage accounts with static website hosting enabled
az storage blob service-properties show --account-name <acc-name> --auth-mode login
# Enumerate containers (including $web) and their public flags
az storage container list --account-name <acc-name> --auth-mode login
# List files served by the static site even when publicAccess is null
az storage blob list --container-name '$web' --account-name <acc-name> --auth-mode login
# Pull suspicious files directly (e.g., IaC tfvars containing secrets/SAS)
az storage blob download -c '$web' --name iac/terraform.tfvars --file /dev/stdout --account-name <acc-name> --auth-mode login

Audyt anonimowego dostępu do blobów

• Locate storage accounts które mogą ujawnić dane: az storage account list | jq -r '.[] | select(.properties.allowBlobPublicAccess==true) | .name'. Jeśli allowBlobPublicAccess jest false, nie możesz ustawić kontenerów jako publiczne.
• Inspect risky accounts aby potwierdzić flagę i inne słabe ustawienia: az storage account show --name <acc> --query '{allow:properties.allowBlobPublicAccess, minTls:properties.minimumTlsVersion}'.
• Enumerate container-level exposure gdzie flaga jest włączona:

az storage container list --account-name <acc> \
--query '[].{name:name, access:properties.publicAccess}'

• "Blob": anonimowe odczyty dozwolone tylko gdy nazwa bloba jest znana (brak listowania).
• "Container": anonimowe listowanie + odczyt każdego bloba.
• null: prywatne; wymagana autoryzacja.
• Udowodnij dostęp bez poświadczeń:
• Jeśli publicAccess jest Container, anonimowe listowanie działa: curl "https://<acc>.blob.core.windows.net/<container>?restype=container&comp=list".
• Zarówno dla Blob, jak i Container, anonimowe pobieranie bloba działa, gdy nazwa jest znana:

az storage blob download -c <container> -n <blob> --account-name <acc> --file /dev/stdout
# or via raw HTTP
curl "https://<acc>.blob.core.windows.net/<container>/<blob>"

Połącz się ze Storage

Jeśli znajdziesz jakiekolwiek storage, z którym możesz się połączyć, możesz użyć narzędzia Microsoft Azure Storage Explorer do tego.

Dostęp do Storage

RBAC

Możliwe jest użycie principali Entra ID z rolami RBAC do uzyskania dostępu do storage accounts i jest to zalecany sposób.

Access Keys

Storage accounts mają access keys, które można użyć do uzyskania dostępu. To zapewnia pełny dostęp do storage account.

Shared Keys & Lite Shared Keys

Można generate Shared Keys podpisane access keys, aby autoryzować dostęp do określonych zasobów za pomocą signed URL.

Note

Należy pamiętać, że część CanonicalizedResource reprezentuje zasób usług storage (URI). Jeśli jakaś część w URL jest zakodowana, powinna być również zakodowana wewnątrz CanonicalizedResource.

Note

To jest używane domyślnie przez az cli do uwierzytelniania żądań. Aby sprawić, by używał poświadczeń principala Entra ID, podaj parametr --auth-mode login.

• Możliwe jest wygenerowanie shared key for blob, queue and file services podpisując następujące informacje:

StringToSign = VERB + "\n" +
Content-Encoding + "\n" +
Content-Language + "\n" +
Content-Length + "\n" +
Content-MD5 + "\n" +
Content-Type + "\n" +
Date + "\n" +
If-Modified-Since + "\n" +
If-Match + "\n" +
If-None-Match + "\n" +
If-Unmodified-Since + "\n" +
Range + "\n" +
CanonicalizedHeaders +
CanonicalizedResource;

• Możliwe jest wygenerowanie shared key for table services podpisując następujące informacje:

StringToSign = VERB + "\n" +
Content-MD5 + "\n" +
Content-Type + "\n" +
Date + "\n" +
CanonicalizedResource;

• Można wygenerować lite shared key for blob, queue and file services podpisując następujące informacje:

StringToSign = VERB + "\n" +
Content-MD5 + "\n" +
Content-Type + "\n" +
Date + "\n" +
CanonicalizedHeaders +
CanonicalizedResource;

• Możliwe jest wygenerowanie lite shared key for table services podpisując następujące informacje:

StringToSign = Date + "\n"
CanonicalizedResource

Aby użyć klucza, umieść go w nagłówku Authorization, używając składni:

Authorization="[SharedKey|SharedKeyLite] <AccountName>:<Signature>"
#e.g.
Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

PUT http://myaccount/mycontainer?restype=container&timeout=30 HTTP/1.1
x-ms-version: 2014-02-14
x-ms-date: Fri, 26 Jun 2015 23:39:12 GMT
Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=
Content-Length: 0

Wspólny podpis dostępu (SAS)

Shared Access Signatures (SAS) to bezpieczne, ograniczone czasowo URL-e, które przyznają określone uprawnienia do zasobów w koncie Azure Storage bez ujawniania kluczy dostępowych konta. Podczas gdy access keys dają pełny dostęp administracyjny do wszystkich zasobów, SAS pozwala na precyzyjną kontrolę przez określenie uprawnień (np. read lub write) oraz zdefiniowanie czasu wygaśnięcia.

Typy SAS

• User delegation SAS: Tworzony przez principal z Entra ID, który podpisze SAS i przekaże uprawnienia od użytkownika do SAS. Może być używany tylko z blob and data lake storage (docs). Możliwe jest unieważnienie wszystkich wygenerowanych user delegated SAS.
• Nawet jeśli można wygenerować delegation SAS z “większymi” uprawnieniami niż te, które posiada użytkownik — jeśli principal ich nie ma, to nie zadziała (no privesc).
• Service SAS: Podpisywany przy użyciu jednego z storage account access keys. Może być użyty do przyznania dostępu do konkretnych zasobów w pojedynczej usłudze storage. Jeśli klucz zostanie odnowiony, SAS przestanie działać.
• Account SAS: Również podpisywany jednym z storage account access keys. Przyznaje dostęp do zasobów w różnych usługach konta storage (Blob, Queue, Table, File) i może obejmować operacje na poziomie usługi.

SAS URL podpisany za pomocą access key wygląda tak:

• https://<container_name>.blob.core.windows.net/newcontainer?sp=r&st=2021-09-26T18:15:21Z&se=2021-10-27T02:14:21Z&spr=https&sv=2021-07-08&sr=c&sig=7S%2BZySOgy4aA3Dk0V1cJyTSIf1cW%2Fu3WFkhHV32%2B4PE%3D

SAS URL podpisany jako user delegation wygląda tak:

• https://<container_name>.blob.core.windows.net/testing-container?sp=r&st=2024-11-22T15:07:40Z&se=2024-11-22T23:07:40Z&skoid=d77c71a1-96e7-483d-bd51-bd753aa66e62&sktid=fdd066e1-ee37-49bc-b08f-d0e152119b04&skt=2024-11-22T15:07:40Z&ske=2024-11-22T23:07:40Z&sks=b&skv=2022-11-02&spr=https&sv=2022-11-02&sr=c&sig=7s5dJyeE6klUNRulUj9TNL0tMj2K7mtxyRc97xbYDqs%3D

Zwróć uwagę na niektóre http params:

• Parametr se wskazuje datę wygaśnięcia SAS
• Parametr sp wskazuje uprawnienia SAS
• sig to sygnatura walidująca SAS

Uprawnienia SAS

Podczas generowania SAS należy wskazać uprawnienia, które ma przyznawać. W zależności od obiektu, dla którego generowany jest SAS, mogą być uwzględniane różne uprawnienia. Na przykład:

• (a)dd, (c)reate, (d)elete, (e)xecute, (f)ilter_by_tags, (i)set_immutability_policy, (l)ist, (m)ove, (r)ead, (t)ag, (w)rite, (x)delete_previous_version, (y)permanent_delete

SFTP Support for Azure Blob Storage

Azure Blob Storage teraz obsługuje SSH File Transfer Protocol (SFTP), umożliwiając bezpieczny transfer plików i zarządzanie bezpośrednio w Blob Storage bez konieczności stosowania niestandardowych rozwiązań lub produktów firm trzecich.

Kluczowe cechy

• Protocol Support: SFTP działa z kontami Blob Storage skonfigurowanymi z hierarchical namespace (HNS). Organizuje to blob-y w katalogi i podkatalogi, ułatwiając nawigację.
• Security: SFTP używa lokalnych tożsamości użytkowników do uwierzytelniania i nie integruje się z RBAC ani ABAC. Każdy lokalny użytkownik może uwierzytelniać się poprzez:
• Azure-generated passwords
• Public-private SSH key pairs
• Granular Permissions: Uprawnienia takie jak Read, Write, Delete i List mogą być przypisane lokalnym użytkownikom dla maksymalnie 100 kontenerów.
• Networking Considerations: Połączenia SFTP odbywają się przez port 22. Azure obsługuje konfiguracje sieciowe takie jak firewalle, private endpoints czy virtual networks w celu zabezpieczenia ruchu SFTP.

Wymagania konfiguracji

• Hierarchical Namespace: HNS musi być włączone podczas tworzenia konta storage.
• Supported Encryption: Wymaga kryptograficznych algorytmów zatwierdzonych przez Microsoft Security Development Lifecycle (SDL) (np. rsa-sha2-256, ecdsa-sha2-nistp256).
• SFTP Configuration:
• Włączyć SFTP na koncie storage.
• Utworzyć lokalne tożsamości użytkowników z odpowiednimi uprawnieniami.
• Skonfigurować katalogi domowe dla użytkowników, aby określić ich punkt startowy w kontenerze.

Uprawnienia

Enumeration

</details>

{{#endtab }}

{{#tab name="Az PowerShell" }}

<details>
<summary>Az PowerShell enumeration</summary>
```powershell
# Get storage accounts
Get-AzStorageAccount | fl
# Get rules to access the storage account
Get-AzStorageAccount | select -ExpandProperty NetworkRuleSet
# Get IPs
(Get-AzStorageAccount | select -ExpandProperty NetworkRuleSet).IPRules
# Get containers of a storage account
Get-AzStorageContainer -Context (Get-AzStorageAccount -name <NAME> -ResourceGroupName <NAME>).context
# Get blobs inside container
Get-AzStorageBlob -Container epbackup-planetary -Context (Get-AzStorageAccount -name <name> -ResourceGroupName <name>).context
# Get a blob from a container
Get-AzStorageBlobContent -Container <NAME> -Context (Get-AzStorageAccount -name <NAME> -ResourceGroupName <NAME>).context -Blob <blob_name> -Destination .\Desktop\filename.txt

# Create a Container Policy
New-AzStorageContainerStoredAccessPolicy `
-Context (Get-AzStorageAccount -Name <NAME> -ResourceGroupName <NAME>).Context `
-Container <container-name> `
-Policy <policy-name> `
-Permission racwdl `
-StartTime (Get-Date "2023-11-22T00:00Z") `
-ExpiryTime (Get-Date "2024-11-22T00:00Z")
#Get Container policy
Get-AzStorageContainerStoredAccessPolicy `
-Context (Get-AzStorageAccount -Name <NAME> -ResourceGroupName <NAME>).Context `
-Container "storageaccount1994container"

# Queue Management
Get-AzStorageQueue -Context (Get-AzStorageAccount -Name <NAME> -ResourceGroupName <NAME>).Context
(Get-AzStorageQueue -Name <NAME> -Context (Get-AzStorageAccount -name <NAME> -ResourceGroupName <NAME>).Context).QueueClient.PeekMessage().Value

#Blob Container
Get-AzStorageBlob -Container <container-name> -Context $(Get-AzStorageAccount -name "teststorageaccount1998az" -ResourceGroupName "testStorageGroup").Context
Get-AzStorageBlobContent `
-Container <container-name> `
-Blob <blob-name> `
-Destination <local-path> `
-Context $(Get-AzStorageAccount -name "teststorageaccount1998az" -ResourceGroupName "testStorageGroup").Context

Set-AzStorageBlobContent `
-Container <container-name> `
-File <local-file-path> `
-Blob <blob-name> `
-Context $(Get-AzStorageAccount -name "teststorageaccount1998az" -ResourceGroupName "testStorageGroup").Context

# Shared Access Signatures (SAS)
Get-AzStorageContainerAcl `
-Container <container-name> `
-Context (Get-AzStorageAccount -Name <NAME> -ResourceGroupName <NAME>).Context

New-AzStorageBlobSASToken `
-Context $ctx `
-Container <container-name> `
-Blob <blob-name> `
-Permission racwdl `
-ExpiryTime (Get-Date "2024-12-31T23:59:00Z")

Udostępnianie plików

Az - File Shares

Privilege Escalation

Az - Storage Privesc

Post Exploitation

Az - Blob Storage Post Exploitation

Persistence

Az - Storage Persistence

Źródła

• https://learn.microsoft.com/en-us/azure/storage/blobs/storage-blobs-introduction
• https://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview
• https://learn.microsoft.com/en-us/azure/storage/blobs/secure-file-transfer-protocol-support
• Holiday Hack Challenge 2025 – Spare Key (Azure static website SAS leak)
• Holiday Hack Challenge 2025: Blob Storage (Storage Secrets)
• https://learn.microsoft.com/en-us/cli/azure/storage/account
• https://learn.microsoft.com/en-us/cli/azure/storage/container
• https://learn.microsoft.com/en-us/cli/azure/storage/blob

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks

• Sprawdź subscription plans!
• Dołącz do 💬 Discord group lub telegram group lub śledź nas na Twitterze 🐦 @hacktricks_live.
• Podziel się hacking tricks, zgłaszając PRy do HackTricks i HackTricks Cloud github repos.