クラウドセキュリティの議論では、「アイデンティティは新しい境界である」ということがよく言われますが、それには正当な理由があります。適切な権限があれば、ほとんどすべてのクラウドリソースを API で管理できます。各プロバイダーには、リソースベースのアクセス制御による API アクセスの処理方法が異なります。特定の API 呼び出しに対する適切な権限が ID に付与されていれば、そのアクションを実行できます。
問題は、特定の情報を取得したり、特定のリソースにアクセスしたりするために必要なすべてのAPI呼び出しを覚えておくのは難しいということです。AWS はこの問題を認識し、AWS CloudControl API を作成しました。これは、さまざまなリソースをグループ化し、一括で作成、更新、削除、取得できるようにする統合 API です。これにより、どのサービス、API コール、またはパラメータを使用するかを知る必要がなくなるため、リソースの管理がはるかに簡単になります。
ただし、ここで問題となるのは、正規のユーザーにとっては簡単なことでも、攻撃者にとっても簡単であるということです。AWS CloudControl API を使用してリソース情報を取得するツールはすでにあり、この手法が注目されています。
しかし、それは実際にはステルス列挙を行うのに良い方法なのでしょうか？この記事では、CloudControl API とは何か、リソース管理を簡素化する方法、攻撃者がそれを武器にする方法、制限事項、検出方法について調べます。例を示すために、Exaforce はビルドしました。 クラウド・コンカーラ、ここで説明した攻撃手法と検出手法の両方を自動化するツールです。
AWS クラウドコントロール API とは何ですか?
AWS クラウドコントロール API は、アカウント内のサービスとリソースの管理を容易にするために AWS が提供する API です。API 実行のサービス、API 呼び出し、入力パラメータを知らなくても作成、読み取り、更新、削除、一覧表示 (CRUD-L) 操作をサポートします。
から クラウドコントロール API の AWS API ドキュメント:「AWS Cloud Control API を使用して、AWS とサードパーティの両方の幅広いサービスに属するクラウドリソースの作成、読み取り、更新、削除、一覧表示 (CRUD-L) を行います。Cloud Control API の標準化されたアプリケーションプログラミングインターフェイス (API) セットを使用すると、AWS アカウント内のサポートされているすべてのリソースで CRUD-L 操作を実行できます。Cloud Control API を使用すると、それらのリソースを担当する各サービスに固有のコードやスクリプトを生成する必要がなくなります。」
また、1 つの統合リソースに基づいてリソースをグループ化し、複数のリソースを統合リソースに関連付けることで、リソース管理にも役立ちます。内部では、以下を使用します。 クラウドフォーメーションスキーマ。たとえば、IAM ユーザーの取得をリクエストすると、次のような形式の情報が返されます。
{
"Type" : "AWS::IAM::User",
"Properties" : {
"Groups" : [ String, ... ],
"LoginProfile" : LoginProfile,
"ManagedPolicyArns" : [ String, ... ],
"Path" : String,
"PermissionsBoundary" : String,
"Policies" : [ Policy, ... ],
"Tags" : [ Tag, ... ],
"UserName" : String
}
}AWS CloudControl では 7 つの API 呼び出しが可能です。そのうちの 5 つは標準の CRUD-L オペレーションです。残りの 2 つはリクエストを一覧表示し、作成、更新、削除の操作の状態を確認するために使用されます。
AWSは以下を維持しています マトリックス AWS CloudControl API でサポートされるすべてのリソースタイプが含まれ、各リソースには CRUD-L オペレーションもサポートされています。現在 1,220 種類のリソースタイプがサポートされており、237 のサービスに分かれています。
AWS CloudControl を攻撃ツールとして使用することの良い点、悪い点、および醜い点
良い点:AWS クラウドコントロールを使用してリソースにアクセスする
AWS クラウドコントロール API は次のような用途に使用されています 攻撃ツール 前。API 自体は AWS リソースのインベントリ取得にも使用できるため、主に列挙に使用されます。あまり使われていないのは、AWS CloudControl API がリソースを変更および更新する機能です。
リソースの取得
AWS CloudControl API を使用すると、リソース名とその設定を簡単に取得できます。通常、従来の AWS API を使用する場合、リソースに関するすべての情報を取得するには複数の API 呼び出しが必要になることがあります。
AWS CloudControl API は CloudFormation スキーマを使用しているため、各リソースには複数のリソースが含まれており、すべてが 1 つの統合リソースにグループ化されています。つまり、AWS IAM ユーザーのスキーマには、ユーザー情報 (ユーザー名、パス、権限境界、タグ)、ログインプロファイル、グループ、ポリシー (添付ポリシーとインラインポリシー) が含まれます。
{
"Type" : "AWS::IAM::User",
"Properties" : {
"Groups" : [ String, ... ],
"LoginProfile" : LoginProfile,
"ManagedPolicyArns" : [ String, ... ],
"Path" : String,
"PermissionsBoundary" : String,
"Policies" : [ Policy, ... ],
"Tags" : [ Tag, ... ],
"UserName" : String
}
}2 つの API 呼び出しにより、リソースの一覧表示または取得が可能になります。 クラウドコントロール:リソースのリスト 指定されたタイプの各リソースを一覧表示します。
$ aws cloudcontrol list-resources --type-name AWS::IAM::Userから返された出力 クラウドコントロール:リソースのリスト は、指定されたリソースタイプのリソース識別子の JSON リストです。
{
"ResourceDescriptions": [
{
"Identifier": "someUser",
"Properties": "{\\"UserName\\":\\"someUser\\"}"
}
],
"TypeName": "AWS::IAM::User"
}これらの識別子は後で渡すことができます クラウドコントロール:リソースを取得 リソースに関する情報を取得します。違いはという点です。 クラウドコントロール:リソースを取得 CloudFormation スキーマとしてフォーマットされた情報を取得できます。
$ aws cloudcontrol get-resource --type-name AWS::IAM::User --identifier <identifier>列挙手法としては、以下を使用して、特定のリソースタイプの特定のリージョンのすべてのリソースを一覧表示できるということです。 クラウドコントロール:リソースのリスト 次に、ループを使用して情報を取得します クラウドコントロール:リソースを取得。
ブルートフォースによるリソース名の検索
攻撃者は、権限が制限されているために特定のアクションの実行が許可されない状況に陥ることがよくあります。これにより、名前や ID などのリソースの識別子など、一部の情報の取得に影響が出る可能性があります。つまり、攻撃者は他の情報を要求する前に、この情報を入手するための代替方法を見つける必要があります。
ブルートフォースや推測は、このアプローチの優れた代替手段です。アカウント上に存在する可能性のあるリソースのリストを持っている攻撃者は、それらのリソースにアクセスする可能性があります。 クラウドコントロール:リソースを取得 リソースが存在するかどうかを調べます。攻撃者が実行権限を持っている場合 クラウドコントロール:リソースを取得 リソースが存在する場合、ターゲットに関する情報を受け取ります。API 呼び出しを実行するためのアクセス権がない場合は、次の情報を受け取ります。 アクセス拒否 エラー。また、API 呼び出しを実行するアクセス権はあるが、リソースが存在しない場合は、次のメッセージが返されます。 リソースが見つかりませんでした例外。これを知っておくと、引き受けた役割に適切な権限があるかどうか、またリソースが存在するかどうかが明確になります。
リソースへのアクセスを得るためにリソースを改ざんすること
リソースを一覧表示して情報を取得する以外に、AWS CloudControl API には、アカウントのリソースを作成、更新、削除する API 呼び出しが 3 つあります。
クラウドコントロール:リソースの作成クラウドコントロール:リソースの更新クラウドコントロール:リソースを削除
リソースの作成と更新に必要な入力は タイプ リソースのうち、リソースタイプに基づいてCloudFormaスキーマから取得された入力パラメータ、およびリソースの削除と更新には、識別子も必要です。
CUD (作成、更新、削除) オペレーションのリクエストがCloudControl APIに送信されると、リクエストはCloudControl APIによって記録されます。を使用する クラウドコントロール:リソースリクエストを一覧表示、失敗した場合のエラーコードを含むリクエストとそのステータス（成功または失敗）を一覧表示できます。列挙機能としては、攻撃者が特定の ID へのアクセス権、組織レベルポリシー (SCP)、作成および更新されたリソースの識別子名に関する情報を取得できるようになるため、役立つことがあります。
悪い点：通話を実行する権限がまだ必要です
私たちの質問の 1 つは、AWS CloudControl API がどのように機能し、どのような権限が必要かということでした。API が CloudControl 固有の権限のみを必要とする場合、未チェックのままにしておくのは非常に危険な API になる可能性があります。
IAM ユーザーを取得しようとするリクエストのイベントを見ると、いくつかのイベントが実行されていることがわかりました。いつ クラウドコントロール:リソースを取得 が実行されると、CloudControl はバックエンドでさらに 7 つの API リクエストを行います。
IAM: ユーザーを取得は 2 回実行され、取得する可能性が最も高いユーザー名、パス、および[タグ]1 つのリクエストを使用して権限境界2番目を使う。IAM: ユーザーポリシーのリストユーザーのインラインポリシーを取得するにはIAM: ユーザーポリシーを取得ポリシーの内容を取得します。ユーザーに割り当てられたインラインポリシーの数によっては、これが複数回実行される場合がありますIAM: アタッチされたユーザーポリシーのリストユーザーにアタッチされた AWS とカスタム管理ポリシーを取得するにはIAM: ログインプロファイルの取得ユーザーが持っているかどうかをお知らせしますログインプロフィール割り当て済み。つまり、管理コンソールにアクセスできるIAM: ユーザーのグループを一覧表示ユーザーが所属している IAM グループのリストを取得します。
AWS イベントは常に正しく順序付けられるとは限らないことに注意してください。非常に短い時間枠で複数の API 呼び出しが実行されると、イベント履歴の順序が変わることがあります。
つまり、インベントリに必要な情報を提供するイベントは、情報が存在するかどうかに関係なく実行されます。そのため、ステルス状態のままでいることが問題になります。つまり、ターゲットで API コールを実行しようとする攻撃者が検出されるということです。これは、リソースを作成または更新しようとするとさらに問題になり、検出ツールやチームが潜在的な侵害に気付く可能性があります。
壊れたチェーン
しかし、待ってください。呼び出しの実行に問題がありました。AWS が CloudControl API の背後での API 呼び出しを実行する際、IAM ユーザーの認証情報にアクセスできないようにする必要があります。では、彼らはどのように呼び出しを実行しているのでしょうか。行われているリクエストの 1 つを見ると、次のようないくつかのことがわかります。
- の値
送信元 IP アドレスそしてユーザーエージェントに設定されますcloudformation.amazonaws.comつまり、イベントは AWS CloudControl API によってトリガーされます。 - リクエストは IAM ユーザー (ARN で示されているとおり) によって開始されたものですが、次の文字で始まるアクセスキーがあります。
アジア、AWS の一時的な認証情報を示します。で示されているように、セッションはイベントの直前に実行されているようです。セッションコンテキスト、属性、作成日と比較してイベントタイム。
{
"eventVersion": "1.11",
"userIdentity": {
"type": "IAMUser",
"principalId": "AIDA****************",
"arn": "arn:aws:iam::0123456789012:user/bleonUser",
"accountId": "0123456789012",
"accessKeyId": "ASIA4MTWIL**********",
"userName": "bleonUser",
"sessionContext": {
"attributes": {
"creationDate": "2025-08-15T14:52:54Z",
"mfaAuthenticated": "false"
}
},
"invokedBy": "cloudformation.amazonaws.com"
},
"eventTime": "2025-08-15T14:52:55Z",
"eventSource": "iam.amazonaws.com",
"eventName": "ListAttachedUserPolicies",
"awsRegion": "us-east-1",
"sourceIPAddress": "cloudformation.amazonaws.com",
"userAgent": "cloudformation.amazonaws.com",
"requestParameters": {
"userName": "bleonUser"
},
"responseElements": null,
"requestID": "00bcc3e5-ed84-4cbb-a8ad-61b252e387bb",
"eventID": "ced62c58-a981-40b8-9e7c-3666a310e908",
"readOnly": true,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "851725277864",
"eventCategory": "Management"
}つまり、AWS は ID の一時的な認証情報を生成し、その認証情報を使用して AWS CloudControl API エンドポイントからの残りの呼び出しを実行します。
CloudTrail には、新しい認証情報の生成を示すイベントはありません。実際、AWS CloudControl API に関連するイベントのみを許可するポリシーを作成しても、情報を受け取ろうとする試みが妨げられることはなく、一時的な認証情報を生成したイベントは CloudTrail に表示されません。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Statement3",
"Effect": "Allow",
"Action": [
"iam:GetUser",
"iam:ListUserPolicies",
"iam:GetUserPolicy",
"iam:ListAttachedUserPolicies",
"iam:GetLoginProfile",
"iam:ListGroupsForUser",
"cloudformation:GetResource"
],
"Resource": [
"*"
]
}
]
}醜い：1つの権限でチェーン全体が壊れる
最後の質問は、特定の API 呼び出しが失敗した場合はどうなるかということでした。また、API 呼び出しの 1 つで取得できる特定の設定がリソースに含まれていない場合、リクエストはどうなるのでしょうか。
リクエスト元の ID に必要な API 呼び出しを実行する適切な権限があるが、リソースに一部の情報がない場合、出力にはそれらのフィールドは含まれません。たとえば、以下のケースでは、ユーザーが AWS IAM グループに属している場合とグループに属していない場合では、出力に違いが見られます。
# User is part of bleonTestGroup IAM Group
{
"Path": "/",
"UserName": "bleonUser",
"Groups": [
"bleonTestGroup"
],
"Arn": "arn:aws:iam::0123456789012:user/bleonUser",
"LoginProfile": {
"PasswordResetRequired": false
},
"Tags": [
{
"Value": "Prod",
"Key": "Deployment"
}
]
}
# User is not part of bleonTestGroup IAM Group
{
"Path": "/",
"UserName": "bleonUser",
"Arn": "arn:aws:iam::0123456789012:user/bleonUser",
"LoginProfile": {
"PasswordResetRequired": false
},
"Tags": [
{
"Value": "Prod",
"Key": "Deployment"
}
]
}これは、要求元のユーザーがすべての権限を持っていない場合とは異なります。AWS IAM Cloud Control では、実行中のトランザクション全体で API 呼び出しが失敗すると、リクエスト全体が失敗します。
つまり、攻撃者がユーザーに関する情報を要求したのに、その攻撃者がグループを一覧表示するためのアクセス権を持っていない場合 (IAM: ユーザーのグループを一覧表示) を指定すると、他の情報は攻撃者に返されず、権限がないことを示すエラーコードが返されます。
また、イベントは引き続き実行され、ログに記録されます。つまり、攻撃者は情報を取得したり、必要なタスクを実行したりすることはありませんが、ログに記録されたままになります。
AWS CloudControl API は攻撃ツールとしてどの程度効果的ですか?
AWS CloudControl API には、攻撃者のツールとして多くの制限があります。たとえば、追加の権限が必要なこと、イベントのロギングが必要なこと、なりすましたアイデンティティに適切な権限がないとチェーンが壊れてしまうことです。しかし、これらの制限を適切に使用すれば、高い権限を持つアカウントでもその制限を引き続き利用することができます。以下のポリシーでは、割り当てられた ID のみが CloudControl に関連する API 呼び出しを直接実行できるようにし、それ以外の場合は CloudControl を介してのみ実行されるように制限します (CloudControl API は CloudFormation オペレーションを使用するため、このサービスはCloudControlではなくCloudFormationです)。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowViaCloudFormation",
"Effect": "Allow",
"Action": "*",
"Resource": "*",
"Condition": {
"ForAnyValue:StringEquals": {
"aws:CalledVia": "cloudformation.amazonaws.com"
},
"Bool": {
"aws:ViaAWSService": "true"
}
}
},
{
"Sid": "DenyDirectAccess",
"Effect": "Deny",
"NotAction": [
"cloudformation:GetResource",
"cloudformation:GetResourceRequestStatus",
"cloudformation:ListResourceRequests",
"cloudformation:ListResources",
"cloudformation:UpdateResource",
"cloudformation:DeleteResource",
"cloudformation:CreateResource",
"cloudformation:CancelResourceRequest"
],
"Resource": "*",
"Condition": {
"Bool": {
"aws:ViaAWSService": "false"
}
}
},
{
"Sid": "AllowDirectCloudControlAcccess",
"Effect": "Allow",
"Action": [
"cloudformation:GetResource",
"cloudformation:GetResourceRequestStatus",
"cloudformation:ListResourceRequests",
"cloudformation:ListResources",
"cloudformation:UpdateResource",
"cloudformation:DeleteResource",
"cloudformation:CreateResource",
"cloudformation:CancelResourceRequest"
],
"Resource": "*"
}
]
}ポリシーシミュレーションでは、すべてのイベントが防止対象として一覧表示されるため、永続性がさらに高まります。
CloudControl で許可されているリクエスト以外のリクエストを実行しようとすると、ポリシーの 2 番目のステートメント () が原因で失敗します。直接アクセスを拒否)。
ただし、CloudControl API を使用して API 呼び出し（任意の CRUD-L オペレーション）を実行しようとすることは許可されます。
このポリシーが割り当てられている ID には管理者アクセス権が付与されますが、通常の非管理者 ID のように見えます。
権限超過ポリシーの検出
このポリシーには 1 つの問題があります。それでもサービスへのアクセス許可は許可されており、AWS CloudControl API を介してそれらをプロキシしているだけです。
IAM ポリシーの作成者を見ると、AWS は CloudControl API を除くすべてのサービスを Explicit Deny として一覧表示します。つまり、ID はそれらのアクセス権限を実行できないということです。
ただし、許可されたサービスのセクションを見ると、すべてのサービスが実際には許可済みとしてマークされていることがわかります。これにより、パーシスタンス手法が検出可能になります。
AWS Simulator と実行されたテストの両方で、この ID のアクセスが拒否されたことが引き続き表示されます。
ポリシーに含まれる条件がわかれば、実際に IAM Policy Simulator を使用して、アカウントに管理者権限があることを証明できます。
クラウド・コンカーラ
この研究は、というオープンソースツールで最高潮に達しました。 クラウド・コンカーラ、4つの部分からなるツールで、この研究で特定されたすべての手法をシミュレーションできます。
- リソースリスト 活用することで
クラウドコントロール:リソースのリストそしてクラウドコントロール:リソースを取得 - リソース名ブルートフォース 活用することで
クラウドコントロール:リソースを取得 - IAM ユーザーまたはロールの作成による永続化 CloudControl 経由のアクセスのみを許可するインラインポリシーを使用
- クラウドコントロールのリスト アカウント上のイベント
クラウドコンクラーはPythonで構築されており、 インストールは簡単です、ローカルで、またはDockerを活用します。リポジトリを参照して自分で試してみてください。
ツールのインストール
ローカルインストール
CloudConqueror は Python 3 で構築されており、必要なライブラリ (requirements.txt) を含むファイルがツールのメインフォルダ内にあります。仮想環境 (python-venv) を使用してツールをローカルにインストールするか、ライブラリをシステムに直接インストールする場合、必要なインストールは requirements.txt 内にライブラリをインストールすることだけです。
(venv) ~$ python3 -m pip install -r requirements.txt
Requirement already satisfied: boto3 in ./venv/lib/python3.12/site-packages (from -r requirements.txt (line 1)) (1.40.5)
Requirement already satisfied: termcolor in ./venv/lib/python3.12/site-packages (from -r requirements.txt (line 2)) (3.1.0)
Requirement already satisfied: botocore in ./venv/lib/python3.12/site-packages (from -r requirements.txt (line 3)) (1.40.5)
Requirement already satisfied: tabulate in ./venv/lib/python3.12/site-packages (from -r requirements.txt (line 4)) (0.9.0)
Requirement already satisfied: prettytable in ./venv/lib/python3.12/site-packages (from -r requirements.txt (line 5)) (3.16.0)
Requirement already satisfied: jmespath<2.0.0,>=0.7.1 in ./venv/lib/python3.12/site-packages (from boto3->-r requirements.txt (line 1)) (1.0.1)
Requirement already satisfied: s3transfer<0.14.0,>=0.13.0 in ./venv/lib/python3.12/site-packages (from boto3->-r requirements.txt (line 1)) (0.13.1)
Requirement already satisfied: python-dateutil<3.0.0,>=2.1 in ./venv/lib/python3.12/site-packages (from botocore->-r requirements.txt (line 3)) (2.9.0.post0)
Requirement already satisfied: urllib3!=2.2.0,<3,>=1.25.4 in ./venv/lib/python3.12/site-packages (from botocore->-r requirements.txt (line 3)) (2.5.0)
Requirement already satisfied: wcwidth in ./venv/lib/python3.12/site-packages (from prettytable->-r requirements.txt (line 5)) (0.2.13)
Requirement already satisfied: six>=1.5 in ./venv/lib/python3.12/site-packages (from python-dateutil<3.0.0,>=2.1->botocore->-r requirements.txt (line 3)) (1.17.0)これで、Python を使用してツールを実行できます。
(venv) ~$ python3 CloudConqueror.py -h
---------------------------------------------------------------------------------
_____ _ _ _____
/ ____| | | |/ ____|
| | | | ___ _ _ __| | | ___ _ __ __ _ _ _ ___ _ __ ___ _ __
| | | |/ _ \\| | | |/ _` | | / _ \\| '_ \\ / _` | | | |/ _ \\ '__/ _ \\| '__|
| |____| | (_) | |_| | (_| | |___| (_) | | | | (_| | |_| | __/ | | (_) | |
\\_____|_|\\___/ \\__,_|\\__,_|\\_____\\___/|_| |_|\\__, |\\__,_|\\___|_| \\___/|_|
| |
|_|
---------------------------------------------------------------------------------
by gl4ssesbo1 @ Exaforce
---------------------------------------------------------------------------------
usage: CloudConqueror.py [-h] {LISTRESOURCES,BRUTEFORCERESOURCES,IAMPERSISTENCE,CHECKUSAGE} ...
CloudConqueror
positional arguments:
{LISTRESOURCES,BRUTEFORCERESOURCES,IAMPERSISTENCE,CHECKUSAGE}
Select the attack to execute on the target
LISTRESOURCES Bruteforce AWS Resources by utilizing cloudcontrol:ListResources and cloudcontrol:GetResource
BRUTEFORCERESOURCES
Bruteforce AWS Resources by utilizing cloudcontrol:GetResource
IAMPERSISTENCE Persist on the Account using an IAM User or Role and a Policy which only allows access through CloudControl API.
CHECKUSAGE Search through AWS CloudTrail Logs using cloudtrail:LookupEvents to find occurrences of bruteforce
options:
-h, --help show this help message and exitDocker のインストール
CloudConqueror には Dockerfile が含まれています。これを使用して Docker イメージを作成し、そこからツールを実行することができます。Docker イメージをインストールするには、ツールのディレクトリで docker build を実行するだけです。
~$ docker build -t cloudconqueror .
Sending build context to Docker daemon 99.07MB
Step 1/7 : FROM python:3.10
3.10: Pulling from library/python
80b7316254b3: Pull complete
36e4db86de6e: Pull complete
8ea45766c644: Pull complete
3cb1455cf185: Pull complete
013acb959c95: Pull complete
ee334269ae4f: Pull complete
3eca4263ed42: Pull complete
Digest: sha256:4585309097d523698d382a2de388340896e021319b327e2d9c028f3b4c316138
Status: Downloaded newer image for python:3.10
---> d565b0a5e178
Step 2/7 : WORKDIR /cloudconqueror
---> Running in e2e79b4829a4
---> Removed intermediate container e2e79b4829a4
---> 6f7ef917c82b
Step 3/7 : COPY . .
--snip--
Successfully built 559c27b10eae
Successfully tagged cloudconqueror:latest次に、ツールを実行するには、docker run を使用してコンテナーを実行するだけです。ローカルの AWS プロファイルディレクトリ (~/.aws ディレクトリ) をマウントして、保存されている awscli セッションとツールのベースディレクトリからフォルダ出力をツールが取得できるようにすることをお勧めします。
~$ docker run -v ~/.aws:/root/.aws -v ./output:/cloudconqueor/output -it cloudconqueror -h
---------------------------------------------------------------------------------
_____ _ _ _____
/ ____| | | |/ ____|
| | | | ___ _ _ __| | | ___ _ __ __ _ _ _ ___ _ __ ___ _ __
| | | |/ _ \\| | | |/ _` | | / _ \\| '_ \\ / _` | | | |/ _ \\ '__/ _ \\| '__|
| |____| | (_) | |_| | (_| | |___| (_) | | | | (_| | |_| | __/ | | (_) | |
\\_____|_|\\___/ \\__,_|\\__,_|\\_____\\___/|_| |_|\\__, |\\__,_|\\___|_| \\___/|_|
| |
|_|
---------------------------------------------------------------------------------
by gl4ssesbo1 @ Exaforce
---------------------------------------------------------------------------------
usage: CloudConqueror.py [-h] {LISTRESOURCES,BRUTEFORCERESOURCES,IAMPERSISTENCE,CHECKUSAGE} ...
CloudConqueror
positional arguments:
{LISTRESOURCES,BRUTEFORCERESOURCES,IAMPERSISTENCE,CHECKUSAGE}
Select the attack to execute on the target
LISTRESOURCES Bruteforce AWS Resources by utilizing cloudcontrol:ListResources and cloudcontrol:GetResource
BRUTEFORCERESOURCES
Bruteforce AWS Resources by utilizing cloudcontrol:GetResource
IAMPERSISTENCE Persist on the Account using an IAM User or Role and a Policy which only allows access through CloudControl API.
CHECKUSAGE Search through AWS CloudTrail Logs using cloudtrail:LookupEvents to find occurrences of bruteforce
options:
-h, --help show this help message and exitリスティングリソース
クラウドコンカラーの使用方法 クラウドコントロール:リソースのリスト アカウントの特定のリソースタイプのリソースを一覧表示します。リソースを一覧表示してその ID を取得したら、実行を試みます。 クラウドコントロール:リソースを取得 それぞれの財産を手に入れるためだツールに必要な入力は AWS に保存されているプロファイルだけです アスクリ ディレクトリと一覧表示するリソースのタイプ。
すべてのリソースタイプがツールの選択肢として一覧表示されます --リソースタイプ フラグ。AWS CloudControl API によって管理されていないリソースを除外します。
ブルートフォーシングリソース
この記事で説明した手法の 1 つは、 クラウドコントロール:リソースを取得 潜在的なリソース名のリストをAPIで呼び出して、その中の1つが存在するかどうかを確認します。つまり、基本的には、アカウント上のリソースの認証された名前のファジングです。
ザの ブルートフォース コマンドを実行するには、攻撃者が AWS プロファイル、リソースタイプ、AWS リージョン、およびリソース名のリストを提供し、それぞれを調べて実行する必要があります クラウドコントロール:リソースを取得、リソースとそのプロパティを返します。
AWS アカウントでの保留中
攻撃者は、「AWS CloudControl APIが攻撃ツールとしてどれほど効果的か」のセクションで説明したように、CloudControl APIを介したアクセスのみを許可するIAMポリシーを作成し、それをIAMユーザー、グループ、またはロールにアタッチして、それらを引き続き使用することができます。
クラウド・コンカラーズ 私は粘り強い コマンドはこの手法を使用してユーザーまたはロール（攻撃者が定義していない場合はデフォルトで CCUser または ccRole という名前）を作成し、「攻撃ツールとしての AWS CloudControl API の有効性」セクションと同じポリシー定義を使用して CCInlinePolicy というインラインポリシーを割り当てます。
クラウドコントロールの不正使用の発生箇所の発見
最後に、CloudConquerorは検出の1つのステップを支援することができます。このツールは 使用状況をチェック コマンドの用途 クラウドトレイル:ルックアップイベント アカウントでの CloudControl API の実行を検索し、そこからテーブルと CSV を出力します。
出力 CSV は、<Account ID>ツールのディレクトリのディレクトリパス output/ /cloudcontrol-events.csv に保存されます。
Exaforce がクラウドコントロール API の不正使用の特定にどのように役立つか
Exaforceは、列挙、リソースのなりすまし、異常な使用などによるCloudControl APIの不正使用を特定するための包括的な検出機能を提供します。私たちのアプローチでは、行動ベースラインと異常検出を活用して、CloudFormationの正当なアクティビティを、CloudControlを使用する攻撃者の手法から切り離します。この調査の結果、CloudControl の悪用からお客様を保護するための新しい検出機能を導入しました。
- Exaforce は、リソースの列挙が試みられたことを示す異常な CloudControl API 呼び出しのシーケンスを検出します。
- Exaforceは、CloudControlの悪用を検出してCloudFormationワークフローに組み込んで、標準の監視や検出を迂回するように設計された疑わしいアクティビティにフラグを立てます。
- Exaforceは、攻撃者が通常のプロビジョニングアクティビティをまねて悪意のある変更を隠そうとするなりすましの試みを明らかにしています。
検出概要には、Exabotによるアラートの自動トリアージの要約と結論が記載されており、関連するIDや問題の特定のAPI呼び出しなどの重要な詳細が強調されています。関連するすべての API 呼び出しを 1 つのセッションに接続し、攻撃シーケンスで CloudControl がどのように使用されたか、どのようなリソースが影響を受けたかをアナリストが把握できるようにしています。
さらに、ID調査ではCloudControlを通じて作成されたユーザーとロールが自動的に明らかになり、永続化のために確立された可能性のあるIAMリソースを可視化できます。
クラウドコントロールの維持
AWS CloudControl API は、AWS API が持つ膨大な量の API 呼び出しを AWS ユーザーがクリーンかつ簡単に管理および利用できるようにする強力な機能です。しかし、よくあることですが、ユーザーにとって使いやすいものであれば、攻撃者にとっても悪用されやすくなります。
AWS CloudControl APIを攻撃ツールとして利用することは、制限はありますが、検出チェーンを断ち切る非常に優れた方法であり、攻撃者がアカウントでいたずら好きなタスクを実行している間に侵入する可能性があります。そのため、これは目を離さないといけないエンティティが悪意を持って使用していないことを確認する価値のある機能です。
ExaforceはCloudControl APIの不正使用を検出し、AWSクラウドコントロールAPIの悪用を迅速に特定して迅速に対応できるようにします。
