Translated ['', 'src/pentesting-ci-cd/pentesting-ci-cd-methodology.md']

src/pentesting-ci-cd/pentesting-ci-cd-methodology.md

@@ -6,51 +6,51 @@
 
 ## VCS
 
-VCS는 **Version Control System**의 약자로, 이 시스템은 개발자가 **source code를 관리**할 수 있게 해줍니다. 가장 일반적인 것은 **git**이며, 회사들은 보통 다음과 같은 **platforms** 중 하나를 사용합니다:
+VCS는 **Version Control System**의 약자이며, 이 시스템은 개발자가 **소스 코드를 관리**할 수 있게 해줍니다. 가장 일반적인 것은 **git**이며, 보통 다음 **platforms** 중 하나에서 사용하는 회사를 볼 수 있습니다:
 
 - Github
 - Gitlab
 - Bitbucket
 - Gitea
 - Gitblit
-- Cloud providers (they offer their own VCS platforms)
+- Cloud providers (자체 VCS platforms를 제공합니다)
 
 
 ## CI/CD Pipelines
 
-CI/CD pipelines는 개발자가 빌드, 테스트, 배포 등 다양한 목적을 위해 **코드 실행을 자동화**할 수 있게 해줍니다. 이러한 자동화된 워크플로우는 코드 푸시, pull requests, 또는 예약 작업과 같은 **특정 동작에 의해 트리거**됩니다. 이는 개발에서 프로덕션으로 가는 과정을 간소화하는 데 유용합니다.
+CI/CD pipelines는 개발자가 빌드, 테스트, 배포를 포함한 다양한 목적을 위해 **code 실행을 자동화**할 수 있게 해줍니다. 이러한 자동화된 워크플로우는 code pushes, pull requests, 예약 작업 같은 특정 동작에 의해 **triggered**됩니다. 이들은 개발에서 production까지의 과정을 간소화하는 데 유용합니다.
 
-그러나 이러한 시스템은 **어딘가에서 실행되어야** 하고 보통은 **код를 배포하거나 민감한 정보에 접근하기 위한 권한 있는 자격증명**을 필요로 합니다.
+하지만 이러한 시스템은 **어딘가에서 실행**되어야 하며, 보통 code를 배포하거나 민감한 정보에 접근하기 위한 **privileged credentials**가 필요합니다.
 
 ## VCS Pentesting Methodology
 
 > [!NOTE]
-> Even if some VCS platforms allow to create pipelines for this section we are going to analyze only potential attacks to the control of the source code.
+> 일부 VCS platforms에서는 이 섹션의 pipeline 생성을 허용하지만, 여기서는 source code 제어에 대한 잠재적 공격만 분석합니다.
 
-프로젝트의 source code를 포함하는 플랫폼에는 민감한 정보가 들어있으며, 이 플랫폼 내에서 부여되는 권한을 매우 신중하게 관리해야 합니다. 공격자가 악용할 수 있는 VCS 플랫폼 전반의 일반적인 문제는 다음과 같습니다:
+프로젝트의 source code가 들어 있는 platforms에는 민감한 정보가 포함되어 있으며, 사람들은 이 platform 안에서 부여된 권한에 매우 주의해야 합니다. 다음은 attacker가 악용할 수 있는 VCS platforms 전반의 일반적인 문제들입니다:
 
-- **Leaks**: 코드에 commits에 leaks가 포함되어 있고 공격자가 repo에 접근할 수 있다면(공개이거나 접근 권한이 있는 경우) 그 leaks를 발견할 수 있습니다.
-- **Access**: 공격자가 **VCS platform 내의 계정에 접근**할 수 있다면 **더 많은 가시성 및 권한**을 얻을 수 있습니다.
-- **Register**: 일부 플랫폼은 외부 사용자가 계정을 생성하도록 허용합니다.
-- **SSO**: 일부 플랫폼은 사용자가 등록하는 것을 허용하지 않지만 유효한 SSO로 누구나 접근할 수 있게 허용합니다(예: 공격자가 자신의 github 계정으로 접근할 수 있음).
-- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies 등 리포지토리에 접근하기 위해 탈취될 수 있는 여러 종류의 토큰이 있습니다.
-- **Webhooks**: VCS 플랫폼은 webhooks를 생성할 수 있게 합니다. 만약 webhooks가 보이지 않는 비밀로 **보호되고 있지 않다면** **공격자가 악용할 수 있습니다**.
-- If no secret is in place, the attacker could abuse the webhook of the third party platform
-- If the secret is in the URL, the same happens and the attacker also have the secret
-- **Code compromise:** 악의적인 행위자가 리포지토리에 대한 **write** 권한을 가지고 있다면, 그는 **악성 코드 삽입**을 시도할 수 있습니다. 성공하려면 **branch protections을 우회**해야 할 수도 있습니다. 이러한 행위는 다양한 목적을 가질 수 있습니다:
-  - main branch를 손상시켜 **production을 침해**.
-  - main(또는 다른) branch를 손상시켜 **개발자 머신을 침해**(개발자들이 리포에서 테스트, terraform 등 작업을 실행하는 경우).
-- **Compromise the pipeline** (check next section)
+- **Leaks**: code에 commit 안의 leaks가 포함되어 있고 attacker가 repo에 접근할 수 있다면(공개되어 있거나 접근 권한이 있기 때문에), 그는 leaks를 발견할 수 있습니다.
+- **Access**: attacker가 VCS platform 안의 계정에 **access할 수 있다면**, **더 많은 가시성과 권한**을 얻을 수 있습니다.
+- **Register**: 일부 platforms는 외부 사용자가 계정을 만들 수 있게 허용합니다.
+- **SSO**: 일부 platforms는 사용자가 등록하는 것을 허용하지 않지만, 유효한 SSO로는 누구나 access할 수 있게 합니다(예를 들어 attacker가 자신의 github 계정으로 들어갈 수 있음).
+- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... repo에 access하기 위해 사용자가 훔칠 수 있는 토큰에는 여러 종류가 있습니다.
+- **Webhooks**: VCS platforms는 webhooks 생성을 허용합니다. 보이지 않는 secrets로 보호되지 않으면 **attacker could abuse them**.
+- secret이 없으면, attacker는 third party platform의 webhook을 악용할 수 있습니다
+- secret이 URL에 있으면, 같은 일이 발생하고 attacker도 secret을 갖게 됩니다
+- **Code compromise:** 악의적인 행위자가 repos에 대한 어떤 종류의 **write** access를 가지고 있다면, 그는 **malicious code를 주입**하려고 시도할 수 있습니다. 성공하려면 **branch protections를 우회**해야 할 수도 있습니다. 이러한 행동은 여러 목적을 위해 수행될 수 있습니다:
+- main branch를 compromise하여 **production을 compromise**.
+- main(또는 다른 branches)을 compromise하여 **developers machines를 compromise**(보통 그들은 머신에서 repo 내부의 test, terraform 또는 다른 것들을 실행함).
+- **pipeline을 compromise**(다음 섹션 참조)
 
 ## Pipelines Pentesting Methodology
 
-파이프라인을 정의하는 가장 일반적인 방법은 **파이프라인이 빌드하는 리포지토리에 호스팅된 CI 구성 파일**을 사용하는 것입니다. 이 파일은 실행되는 job의 순서, 흐름에 영향을 주는 조건, 빌드 환경 설정 등을 설명합니다.  
-이 파일들은 일반적으로 일관된 이름과 형식을 가집니다. 예를 들어 — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), 그리고 .github/workflows 아래의 GitHub Actions YAML 파일들. 트리거되면 파이프라인 job은 선택된 소스(예: commit / branch)에서 **코드를 pull**하고, CI 구성 파일에 지정된 **명령을 해당 코드에 대해 실행**합니다.
+pipeline을 정의하는 가장 일반적인 방법은, pipeline이 빌드하는 repository에 호스팅된 **CI configuration file**을 사용하는 것입니다. 이 파일은 실행되는 jobs의 순서, flow에 영향을 주는 조건, build environment settings를 설명합니다.\
+이 파일들은 보통 이름과 형식이 일정합니다. 예를 들어 Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), 그리고 .github/workflows 아래에 있는 GitHub Actions YAML files가 있습니다. trigger되면 pipeline job은 선택된 source(예: commit / branch)에서 code를 **pull**하고, CI configuration file에 지정된 commands를 그 code에 대해 **실행**합니다.
 
-따라서 공격자의 궁극적인 목표는 어떻게든 이러한 구성 파일들이나 **실행하는 명령들**을 **compromise**하는 것입니다.
+따라서 attacker의 궁극적인 목표는 어떤 식으로든 이러한 configuration files 또는 그들이 실행하는 commands를 **compromise**하는 것입니다.
 
 > [!TIP]
-> Some hosted builders let contributors choose the Docker build context and Dockerfile path. If the context is attacker-controlled, you may set it outside the repo (e.g., "..") to ingest host files during build and exfiltrate secrets. See:
+> 일부 hosted builders는 contributor가 Docker build context와 Dockerfile path를 선택하게 합니다. context가 attacker-controlled라면, build 중 host files를 읽어들여 secrets를 exfiltrate하기 위해 repo 밖(예: "..")으로 설정할 수 있습니다. 다음을 참조하세요:
 >
 >{{#ref}}
 >docker-build-context-abuse.md
@@ -58,57 +58,78 @@ CI/CD pipelines는 개발자가 빌드, 테스트, 배포 등 다양한 목적
 
 ### PPE - Poisoned Pipeline Execution
 
-The Poisoned Pipeline Execution (PPE) 경로는 SCM 리포지토리의 권한을 악용하여 CI 파이프라인을 조작하고 유해한 명령을 실행하게 합니다. 필요한 권한을 가진 사용자는 CI 구성 파일이나 파이프라인 job에서 사용하는 다른 파일을 수정하여 악성 명령을 포함시킬 수 있습니다. 이렇게 CI 파이프라인을 "poison"하면 이 악성 명령들이 실행됩니다.
+Poisoned Pipeline Execution (PPE) 경로는 SCM repository의 permissions를 악용해 CI pipeline을 조작하고 harmful commands를 실행합니다. 필요한 permissions를 가진 사용자는 CI configuration files 또는 pipeline job이 사용하는 다른 files를 수정해 malicious commands를 포함시킬 수 있습니다. 이렇게 하면 CI pipeline이 "poisoned"되고, 이러한 malicious commands가 실행됩니다.
 
-공격자가 PPE 공격을 성공적으로 수행하려면 다음이 필요합니다:
+악의적인 행위자가 PPE attack을 성공적으로 수행하려면 다음이 가능해야 합니다:
 
-- **VCS platform에 대한 write access**를 가지고 있어야 합니다. 보통 파이프라인은 push나 pull request가 발생하면 트리거되기 때문입니다. (VCS pentesting methodology를 참조하세요.)
-- 외부 PR이 때때로 **"write access"로 간주**되기도 한다는 점에 유의하세요.
-- 설령 write 권한이 있더라도, 그는 **CI config 파일이나 config가 의존하는 다른 파일들을 수정할 수 있는지** 확신해야 합니다.
-- 이를 위해서는 **branch protections을 우회**할 수 있어야 할 수도 있습니다.
+- **VCS platform에 write access**를 가져야 합니다. 보통 pipelines는 push 또는 pull request가 수행될 때 triggered되기 때문입니다. (접근 권한을 얻는 방법의 요약은 VCS pentesting methodology를 확인하세요).
+- 때로는 **external PR이 "write access"로 간주**된다는 점에 주의하세요.
+- write permissions가 있더라도, CI config file 또는 config가 의존하는 다른 files를 **수정할 수 있어야** 합니다.
+- 이를 위해 **branch protections를 우회**해야 할 수도 있습니다.
 
-PPE에는 3가지 변형이 있습니다:
+PPE에는 3가지 유형이 있습니다:
 
-- **D-PPE**: **Direct PPE** 공격은 행위자가 **실행될 CI config** 파일을 직접 **수정**할 때 발생합니다.
-- **I-DDE**: **Indirect PPE** 공격은 행위자가 CI config가 의존하는 **파일**(예: make file이나 terraform 구성)을 **수정**할 때 발생합니다.
-- **Public PPE or 3PE**: 경우에 따라 파이프라인은 repo에 write access가 없는 사용자(조직의 일원이 아닐 수도 있음)가 보낸 PR에 의해 **트리거**될 수 있습니다.
-- **3PE Command Injection**: 일반적으로 CI/CD 파이프라인은 PR에 대한 정보를 **환경 변수**로 설정합니다. 만약 그 값이 공격자에 의해 제어될 수 있고(예: PR 제목) **위험한 위치**(예: sh 명령 실행)에 사용된다면, 공격자는 그 안에 **명령 주입**을 할 수 있습니다.
+- **D-PPE**: actor가 실행될 **CI config** file을 **수정**할 때 발생하는 **Direct PPE** attack입니다.
+- **I-DDE**: actor가 실행될 **CI config file이 의존하는 file**(예: make file 또는 terraform config)을 **수정**할 때 발생하는 **Indirect PPE** attack입니다.
+- **Public PPE or 3PE**: 경우에 따라 pipelines는 repo에 write access가 없는 사용자(심지어 org의 일원이 아닌 사용자)도 PR을 보낼 수 있기 때문에 trigger될 수 있습니다.
+- **3PE Command Injection**: 보통 CI/CD pipelines는 PR에 대한 **information**으로 **environment variables**를 **설정**합니다. 그 값이 attacker가 제어할 수 있고(예: PR의 title), **위험한 위치**(예: **sh commands** 실행)에 **사용**된다면 attacker가 그 안에 commands를 주입할 수 있습니다.
 
 ### Exploitation Benefits
 
-세 가지 PPE 변형을 알았으니, 성공적인 exploitation 후 공격자가 얻을 수 있는 것을 살펴봅시다:
+pipeline을 poison하는 3가지 유형을 알았으니, 성공적인 exploitation 후 attacker가 얻을 수 있는 것을 살펴봅시다:
 
-- **Secrets**: 앞서 언급했듯이 파이프라인은 코드 검색, 빌드, 배포 등을 위해 **privileges**를 필요로 하며 이 권한들은 보통 **secrets**로 부여됩니다. 이러한 secrets는 보통 **env variables**나 시스템 내부의 파일로 접근 가능합니다. 따라서 공격자는 가능한 많은 secrets를 항상 탈취하려고 할 것입니다.
-- 파이프라인 플랫폼에 따라 공격자는 **config에 secrets를 명시해야 하는 경우**가 있습니다. 즉, 공격자가 CI 구성 파이프라인 자체를 수정할 수 없다면(**I-PPE** 같은 경우), 그는 **그 파이프라인이 가진 secrets만** 탈취할 수 있습니다.
-- **Computation**: 코드가 어딘가에서 실행되므로, 실행 위치에 따라 공격자는 추가적인 피벗을 시도할 수 있습니다.
-- **On-Premises**: 파이프라인이 온프레미스에서 실행된다면, 공격자는 **내부 네트워크에 접근**하여 더 많은 자원에 접근할 수 있습니다.
-- **Cloud**: 공격자는 클라우드 내의 다른 머신에 접근하거나 IAM roles/service accounts **tokens**를 탈취하여 클라우드 내부에서 **추가 접근 권한**을 획득할 수 있습니다.
-- **Platforms machine**: 때때로 job은 **pipelines platform machines** 내부에서 실행되며, 이들은 보통 추가 접근 권한이 없는 클라우드 내의 머신일 수 있습니다.
-- **Select it:** 때때로 **pipelines platform은 여러 머신을 구성**해 두고 있으며, CI 구성 파일을 수정할 수 있다면 **악성 코드를 어느 머신에서 실행할지 지정**할 수 있습니다. 이런 경우 공격자는 가능한 각 머신에 대해 리버스 쉘을 실행하여 추가 취약점을 노릴 것입니다.
-- **Compromise production**: 파이프라인 내부에 있고 최종 버전이 거기서 빌드되어 배포된다면, 프로덕션에서 실행될 코드를 **침해**할 수 있습니다.
+- **Secrets**: 앞서 언급했듯이, pipelines는 jobs를 위해 **privileges**(code를 가져오고, 빌드하고, 배포하는 등)를 필요로 하며, 이 privileges는 보통 **secrets**에 들어 있습니다. 이러한 secrets는 보통 **env variables 또는 시스템 내부 파일**을 통해 접근할 수 있습니다. 따라서 attacker는 항상 가능한 한 많은 secrets를 exfiltrate하려고 할 것입니다.
+- pipeline platform에 따라 attacker가 config에 secrets를 **지정해야 할 수도 있습니다**. 이는 attacker가 CI configuration pipeline(**I-PPE** 예시처럼)을 수정할 수 없다면, 그 pipeline이 가진 secrets만 **exfiltrate할 수 있다**는 뜻입니다.
+- **Computation**: code는 어딘가에서 실행되며, 실행 위치에 따라 attacker가 더 깊이 pivot할 수 있을지도 모릅니다.
+- **On-Premises**: pipelines가 on premises에서 실행된다면, attacker는 더 많은 resources에 access할 수 있는 **internal network**에 도달할 수 있습니다.
+- **Cloud**: attacker는 cloud의 **다른 machines**에 access할 수 있을 뿐 아니라, 더 많은 cloud 내부 access를 얻기 위해 그곳의 IAM roles/service accounts **tokens**를 **exfiltrate**할 수도 있습니다.
+- **Platforms machine**: 때때로 jobs는 **pipelines platform machines** 내부에서 실행되며, 이들은 보통 **더 이상의 access가 없는** cloud 안에 있습니다.
+- **Select it:** 때때로 **pipelines platform은 여러 machines를 구성**해두며, CI configuration file을 **수정**할 수 있다면 malicious code를 어디서 실행할지 **지정**할 수 있습니다. 이 상황에서는 attacker가 각 가능한 machine에서 reverse shell을 실행해 추가 exploitation을 시도할 가능성이 큽니다.
+- **Compromise production**: pipeline 내부에 있고 최종 버전이 그곳에서 빌드 및 배포된다면, production에서 실행될 code를 **compromise**할 수 있습니다.
+
+### Dependency & Registry Supply-Chain Abuse
+
+CI/CD pipeline을 compromise하거나 거기서 credentials를 훔치면 attacker는 dependencies나 release tooling을 backdoor하여 **pipeline execution**에서 **ecosystem-wide code execution**으로 이동할 수 있습니다:
+
+- **Install-time code execution via package hooks**: `preinstall`, `postinstall`, `prepare` 같은 hooks를 추가한 package version을 publish하면 dependency installation 중 developer workstations와 CI runners에서 payload가 자동으로 실행됩니다.
+- **Secondary execution paths**: targets가 `--ignore-scripts`로 설치하더라도, malicious package는 `bin` field에 **common CLI name**을 등록할 수 있으며, 그러면 attacker-controlled wrapper가 `PATH`에 symlink되고 나중에 command가 사용될 때 실행됩니다.
+- **Runtime bootstrapping**: 작은 installer가 installation 중에 두 번째 runtime 또는 toolchain을 다운로드한 뒤(예: Bun 또는 packed interpreter), 그것으로 main payload를 실행할 수 있어 local dependency requirements를 피할 수 있습니다.
+- **Credential harvesting from build environments**: code가 CI 내부에서 실행되면 environment variables, `~/.npmrc`, `~/.git-credentials`, SSH keys, cloud CLI configs, 그리고 `gh auth token` 같은 local tooling을 확인하세요. GitHub Actions에서는 runner-specific secrets와 artifacts도 찾으세요.
+- **Workflow injection with stolen GitHub tokens**: **`repo` + `workflow`** permissions가 있는 token이면 branch를 만들고, `.github/workflows/` 안에 malicious file을 commit한 뒤, 이를 trigger하고, 생성된 artifacts/logs를 수집한 후, 흔적을 줄이기 위해 temporary branch/workflow run을 삭제할 수 있습니다.
+- **Wormable registry propagation**: 훔친 npm tokens이 **publish** permissions와 2FA 우회 여부를 갖는지 검증해야 합니다. 그렇다면 writable packages를 열거하고, tarballs를 다운로드한 뒤, `setup.mjs` 같은 loader를 주입하고, `preinstall`이 그것을 실행하도록 설정한 다음, patch version을 올리고 republish하세요. 이렇게 하면 하나의 CI compromise가 다른 environments에서 downstream auto-execution으로 이어집니다.
+
+#### Practical checks during an assessment
+
+- `package.json`에 추가된 package-manager hooks, 예상치 못한 `bin` entries, 또는 release artifact만 수정하는 version bumps를 release automation에서 검토하세요.
+- CI가 short-lived OIDC나 trusted publishing 대신 `~/.npmrc` 같은 plaintext files에 long-lived registry credentials를 저장하는지 확인하세요.
+- CI에서 사용할 수 있는 GitHub tokens가 workflow files를 쓸 수 있는지 또는 branches/tags를 만들 수 있는지 검증하세요.
+- compromised package가 의심되면, Git repository만 보지 말고 published tarball도 확인하세요. malicious loader/runtime가 published artifact에만 존재할 수 있기 때문입니다.
+- CI 내부에서 `npm install` 대신 `npm ci` 사용, 예상치 못한 Bun 다운로드/실행, transient branches에서 생성된 새로운 workflow artifacts 같은 비정상적인 package-manager execution을 찾아보세요.
 
 ## More relevant info
 
 ### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) 는 새로운 [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf)를 기반으로 소프트웨어 공급망 스택의 보안 컴플라이언스를 감사하는 오픈소스 도구입니다. 이 감사는 전체 SDLC 프로세스에 초점을 맞추며, 코드 단계에서 배포 단계까지의 위험을 드러낼 수 있습니다.
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench)는 새로운 [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf)를 기반으로 software supply chain stack의 security compliance를 감사하는 오픈소스 tool입니다. 이 감사는 전체 SDLC process에 초점을 맞추며, code time에서 deploy time까지의 risk를 드러낼 수 있습니다.
 
 ### Top 10 CI/CD Security Risk
 
-Cider에 따른 top 10 CI/CD 위험에 관한 흥미로운 글을 확인하세요: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
+Cider에 따르면 CI/CD top 10 risks에 대한 이 흥미로운 article을 확인하세요: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
 
 ### Labs
 
-- 로컬에서 실행할 수 있는 각 플랫폼에 대해 로컬에서 어떻게 실행하는지 설명되어 있으므로 원하는 대로 구성하여 테스트할 수 있습니다.
+- 로컬에서 실행할 수 있는 각 platform에는 이를 로컬에서 어떻게 시작하는지 설명이 있으며, 원하는 대로 테스트할 수 있도록 구성할 수 있습니다
 - Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
 
 ### Automatic Tools
 
-- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov**는 infrastructure-as-code에 대한 정적 코드 분석 도구입니다.
+- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov**는 infrastructure-as-code를 위한 static code analysis tool입니다.
 
 ## References
 
 - [https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github\&utm_medium=github_page\&utm_campaign=ci%2fcd%20goat_060422](https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422)
+- [The npm Threat Landscape: Attack Surface and Mitigations](https://unit42.paloaltonetworks.com/monitoring-npm-supply-chain-attacks/)
+- [Checkmarx Security Update: April 22, 2026](https://checkmarx.com/blog/checkmarx-security-update-april-22/?p=108469)
 
 
 {{#include ../banners/hacktricks-training.md}}