本文の内容は、2023年2月28日にNIGEL DOUGLASが投稿したブログ（https://sysdig.com/blog/falco-cloudtrail-rules-mitre-attck)を元に日本語に翻訳・再構成した内容となっております。 このブログでは、FalcoのCloudtrailプラグインルールをMITRE ATT&CK Framework for Cloudとどのように整合させることができるかを説明します。 重要な注意点として、MITREのチームは、クラウド、コンテナ化されたワークロード、およびモバイルデバイスにおける敵対者に関連する固有のリスクに対処するために、いくつかの異なるマトリックスを開発しました。このブログでは、以下のクラウドマトリクスにのみルールを合わせることにします。
| Initial Access | Execution | Persistence | Privilege Escalation | Defense Evasion | Credential Access | Discovery | Lateral Movement | Collection | Exfiltration | Impact |
| Drive-by compromise | Serverless Execution | Account Manipulation | Domain Policy Modification | Use Alternate Auth Material | Brute Force | Network Sniffing | Internal Spear Phishing | Data from Information Repositories | Transfer Data to Cloud Account | Account Access Removal |
| Exploit Public-Facing Application | User Execution | Office Application Startup | Event Triggered Execution | Modify Cloud Compute Resources | Forge Web Credentials | Cloud Service Discovery | Taint Shared Content | Automated Collection | Data Destruction | |
| Phishing | Create Account | Valid Accounts | Impair Defenses | Modify Auth Process | Network Service Discovery | Use Alternate Auth Material | Data from Cloud Storage | Defacement | ||
| Trusted Relationship | Event Triggered Execution | Indicator Removal | MFA Request Generation | Cloud Infrastructure Discovery | Data Staged | Data Encrypted for Impact | ||||
| Valid Accounts | Valid Accounts | Hide Artifacts | Network Sniffing | Password Policy Discovery | Email Collection | Endpoint Denial of Service | ||||
| Modify Auth Process | Domain Policy Modification | Unsecured Credentials | Resource Hijacking | |||||||
| Implant Internal Image | Unused / Unsupported Cloud Regions | Steal App Access Tokens | Network Denial of Service |
なぜクラウドマトリクスが必要なのか？
MITRE ATT&CK フレームワークのクラウドマトリクスは、クラウドのセキュリティポスチャーを改善しようとする組織にいくつかの利点を提供します。主な利点は以下の通りです。- 脅威の認識：クラウドマトリクスは、敵対者が使用する戦術、テクニック、手順（TTPs）を含む、クラウド環境における脅威の状況において包括的なランドスケープを提供します。これにより、企業は直面する可能性のある攻撃の種類と、それに対する防御方法を理解することができます。
- フォーカス：クラウドマトリクスは、企業が重要度の低いセキュリティ対策に時間とリソースを浪費するのではなく、最も重要なセキュリティ領域に集中できるよう支援します。
- 検出：クラウドマトリクスは、潜在的なセキュリティ脅威を検知するためのガイダンスを提供し、企業がインシデントに迅速に対応できるようにします。
- 継続的な改善：クラウドマトリクスは、最新の脅威状況を反映するために定期的に更新され、企業は常に時代の最先端を行くことができ、セキュリティ体制を継続的に改善することができます。
Falcoはクラウドマトリクスからどのような利益を得ているのでしょうか
オープンソースのFalco侵入検知システムは、いくつかの点でMITRE ATT&CKフレームワーク for Cloudから大きな利益を得ることができます。- 検出の改善：MITRE ATT&CKフレームワークのクラウドマトリクスに記載されている脅威インテリジェンスと戦術、テクニック、および手順（TTPs）を組み込むことにより、Falcoはクラウド環境における潜在的なセキュリティ脅威をより正確に検出することができます。
- 業界標準との整合性 広く認知され、採用されている：MITRE ATT&CKフレームワークを活用することにより、Falcoは、クラウド環境における脅威を検知し対応するための一貫した、信頼できる、そして広く受け入れられた方法を提供することが可能です。
- より良い脅威の優先順位付け： クラウドマトリクスは、異なる攻撃シナリオの潜在的な影響と攻撃の可能性に基づいて、組織がセキュリティの取り組みに優先順位をつけることを支援します。Falcoは、この情報を活用して、最も重要なセキュリティ領域に検知能力を集中させることができます。
- UXの向上：クラウドマトリクスは、脅威の状況を明確かつ簡潔に表現しており、セキュリティチームが潜在的な脅威を理解し、対応することを容易にします。Falcoはこれを利用して、より直感的で合理的なユーザーエクスペリエンスを提供することができます。
どのようにルールを整合させるか？
一言で言えば、私たちはまず、クラウドマトリクスにおける戦術とその関連テクニックを理解する必要があります。 いったんこれができたら、これらのテクニックとサブテクニ ックを検出するための Falco のルールを作成する必要があります。ルールがすでに存在する場合は、そのルール定義に関連する MITRE のテクニックをタグ付けするだけでよいのです。初期アクセス（Initial Access）
初期アクセスは、ネットワーク内で最初の足場を得るために様々なエントリーベクターを使用するテクニックで構成されています。初期アクセスによって得られた足場は、有効なアカウントや外部リモートサービスの使用など、継続的なアクセスを可能にする場合もあれば、パスワードの変更により使用制限される場合もあります。
通常、AWSのAssumeRoleでは、アクセスできないAWSリソースにアクセスするために使用できます。つまり、一時的なセキュリティ認証情報のセットを使用することになります。これらの一時的な資格情報は、アクセスキーID、シークレットアクセスキー、およびセキュリティトークンで構成されています。
AssumeRoleによるコンソールログインはすべて ‘Valid Account’ の侵害と見なされるため、このルールは戦術「初期アクセス」および関連テクニック‘Valid Account’ に関連付けられます。このデフォルトルールを MITRE ATT&CK マトリクス for Cloud と正しく整合させるためには、以下に示すように、Falco のルールに戦術、テクニック、テクニック ID をタグ付けする必要があります（Github リンク）：
- rule: Console Login Through Assume Role
desc: Detect a console login through Assume Role.
condition:
ct.name="ConsoleLogin" and not ct.error exists
and ct.user.identitytype="AssumedRole"
and json.value[/responseElements/ConsoleLogin]="Success"
output:
Detected a console login through Assume Role
(principal=%ct.user.principalid,
assumedRole=%ct.user.arn,
requesting IP=%ct.srcip,
AWS region=%ct.region)
priority: WARNING
tags:
- aws
- T1078
- initial_access
- valid_accounts
source: aws_cloudtrail
実行（Execution）
コードの実行は、ローカルであれリモートであれ、セキュリティの重要な側面であり、しばしば敵対者の目的の成否を決定します。ネットワーク探索やデータ窃盗などの目標を達成するために、攻撃者はこのMITREの戦術の中で様々なテクニックを組み合わせて使用します。
そのような技術の1つが、AWS Lambdaのようなクラウドコンピューティングサービスの台頭で人気を博しているサーバーレス実行です。サーバーレス function は強力なツールになり得ますが、潜在的なセキュリティリスクも存在します。誤検知を減らすためには、実行を許可されたユーザーやリージョンに限定するなど、明確な条件を設定することが重要です。
包括的なセキュリティカバレッジを確保するには、以下のルールスニペット（Github Link）に見られるように、関連するMITRE 戦術、テクニック、識別子をルールにタグ付けすることも有効です。
- rule: Create Lambda Function
desc: Detects the creation of a Lambda function.
condition:
ct.name="CreateFunction20150331" and not ct.error exists
output:
Lambda function has been created.
(requesting user=%ct.user,
requesting IP=%ct.srcip,
AWS region=%ct.region,
lambda function=%ct.request.functionname)
priority: WARNING
tags:
- aws
- T1648
- execution
- serverless_execution
source: aws_cloudtrail
永続化（Persistence）
永続化は、敵対者が足場を維持し、クラウド環境全体へのアクセスを維持するために使用するテクニックで構成されています。攻撃者は、新しい認証情報のセットを使用したり、新しいIAMアカウントを作成したり、バックドアとして使用する新しいイメージを作成したりして、お客様の環境へのアクセスを維持することができます。
永続化に成功すると、彼らは初期アクセスの最初のステップを実行することなく、お客様のクラウド環境にアクセスすることができるようになります。その結果、すべての新規アカウント作成、特に事前の承認なしに作成されたアカウントは疑わしいものとして扱わなければなりません。
クラウドマトリクスでは、このテクニックは単に ‘Create Accounts’ と呼ばれ、テクニックIDはT1136に設定されています。
- rule: Create AWS user
desc: Detect creation of a new AWS user.
condition:
ct.name="CreateUser" and not ct.error exists
output:
A new AWS user has been created
(requesting user=%ct.user,
requesting IP=%ct.srcip,
AWS region=%ct.region,
new user created=%ct.request.username)
priority: INFO
tags:
- aws
- T1136
- persistence
- create_account
source: aws_cloudtrail
Githubリンク
特権エスカレーション（Privilege escalation）
Lambda functionの設定を更新することは、本来は権限昇格の手段ではありません。しかし、攻撃者がLambda functionの設定を更新する能力を有している場合、IAMの設定ミスなどの特定の状況において、それを使用して昇格した特権を得ることができる可能性があります。
例えば、Lambda functionが機密リソースにアクセスする権限を持っている場合、functionの設定を更新できる攻撃者は、functionのコードを変更して機密データを漏洩または変更することができます。同様に、functionの設定を更新できる攻撃者は、functionの権限を変更して追加のリソースにアクセスできるようにし、攻撃者がターゲットシステムに広くアクセスできるようにすることも可能です。
悪意のあるアクターがLambda functionを特権拡大のベクトルとして使用するのを防ぐために、Lambda functionを適切に保護し、その設定と権限へのアクセスを制限することが重要です。これは、適切なアクセス制御を実装し、最小特権の原則などのAWSセキュリティのベストプラクティスに従うことで実現可能です。T1546 (Event-triggered Execution) の詳細については、MITRE ATT&CK の公式ページをご覧ください。
- rule: Update Lambda Function Configuration
desc: Detects updates to a Lambda function configuration.
condition:
ct.name="UpdateFunctionConfiguration20150331v2" and not ct.error exists
output:
The configuration of a Lambda function has been updated.
(requesting user=%ct.user,
requesting IP=%ct.srcip,
AWS region=%ct.region,
lambda function=%ct.request.functionname)
priority: WARNING
tags:
- aws
- T1546
- privilege_escalation
- event_triggered_execution
source: aws_cloudtrail
Githubリンク
防御回避（Defense evasion）
EC2インスタンスを承認されていないリージョンで実行すると、攻撃者が活動を隠して検知を逃れることができるため、防御回避の一形態と見なされることがあります。 EC2インスタンスを承認されたリージョンでのみ実行するポリシーと手順がある場合、そのインスタンスが組織のセキュリティ制御の範囲内にあることを確認し、効果的に監視と監査ができるようにすることができます。EC2インスタンスを承認されていないリージョンで稼働させると、攻撃者は組織のセキュリティ監視・ログ記録システムを回避して、攻撃者の活動の検知と対応を困難にし、検知されずに活動（コマンド＆コントロールサーバーや、クリプトマイニング活動の実行など）を行うことができます。- rule: Run Instances in Non-approved Region
desc: Detects launching of a specified number of instances in a non-approved region.
condition:
ct.name="RunInstances" and not ct.error exists and
not ct.region in (approved_regions)
output:
A number of instances have been launched in a non-approved region.
(requesting user=%ct.user,
requesting IP=%ct.srcip,
AWS region=%ct.region,
availability zone=%ct.request.availabilityzone,
subnet id=%ct.response.subnetid,
reservation id=%ct.response.reservationid,
image id=%json.value[/responseElements/instancesSet/items/0/instanceId])
priority: WARNING
tags:
- aws
- T1535
- defense_evasion
- unused_unsupported_cloud_regions
source: aws_cloudtrail
Githubリンク
認証情報アクセス（Credential access）
AWSの管理者ユーザーの多要素認証（MFA）を無効化すると、機密性の高いリソースや情報への不正アクセスのリスクが高まり、認証情報アクセスに利用される可能性があります。 AWSのルートユーザーは最高レベルのユーザーアカウントであり、すべてのAWSサービスおよびリソースへのフルアクセスを持っています。MFAは、ユーザーにパスワードに加えて第二の認証形式を提供することを要求する、セキュリティの追加レイヤーです。 攻撃者がルートユーザーの認証情報にアクセスすると、その認証情報を使用して、データ、アプリケーション、インフラストラクチャーなどの機密リソースを含むAWS環境全体にアクセスし、操作することができます。また、他のユーザーアカウントにアクセスしたり、侵害したり、自分自身に追加の権限を付与したりすることもできる可能性があります。 強力なセキュリティ体制を維持し、機密情報への不正アクセスを防止するためには、ルートユーザーに対してMFAを有効にしておくことが重要です。さらに、組織は、ロールベースのアクセス制御、ログ記録、および潜在的なセキュリティインシデントを検出して対応するための監視の使用など、AWS環境を保護するためのベストプラクティスに従う必要があります。- rule: Deactivate MFA for Root User
desc: Detect deactivating MFA configuration for root.
condition:
ct.name="DeactivateMFADevice" and not ct.error exists
and ct.user.identitytype="Root"
and ct.request.username="AWS ROOT USER"
output:
Multi Factor Authentication configuration has been disabled for root
(requesting user=%ct.user,
requesting IP=%ct.srcip,
AWS region=%ct.region,
MFA serial number=%ct.request.serialnumber)
priority: CRITICAL
tags:
- aws
- T1556
- credential_access
- modify_authentication_process
source: aws_cloudtrail
Githubリンク
ディスカバリー（Discovery）
Amazon S3バケットをリストアップすることは、対象のクラウド環境の構造と内容に関する情報を提供するため、クラウドインフラストラクチャーの発見の一形態とみなすことができます。 Amazon S3は、組織がクラウド上でデータを保存および取得することを可能にする、一般的なクラウドストレージサービスです。攻撃者が標的の環境におけるS3バケットをリストアップすると、保存されているデータの種類、データのサイズ、データに関連付けられた権限など、標的のクラウドインフラストラクチャーの構造とコンテンツに関する洞察を得ることができます。 この情報は、攻撃者が攻撃を計画し、どのリソースとデータをターゲットにするかを決定する際に、貴重な情報となります。例えば、攻撃者は、S3バケット列挙によって得られた情報を使用して、クラウドに保存されている機密データを特定したり、公開アクセスを可能にする誤ったパーミッションが設定されているS3バケットを特定したりすることができます。 クラウドインフラストラクチャーの発見を防ぐために、組織は、アクセス制御や暗号化などのセキュリティ対策を実施して、S3バケットへの不正アクセスを制限し、S3バケットの権限や設定が適切に保護されていることを定期的に確認・監視する必要があります。さらに、組織は、潜在的なセキュリティインシデントを検出し、対応するために、ログと監視システムを実装し、最小特権の原則などのセキュリティベストプラクティスに従うべきです。- rule: List Buckets
desc: Detects listing of all S3 buckets.
condition:
ct.name="ListBuckets" and not ct.error exists
output:
A list of all S3 buckets has been requested.
(requesting user=%ct.user,
requesting IP=%ct.srcip,
AWS region=%ct.region,
host=%ct.request.host)
priority: WARNING
enabled: false
tags:
- aws
- T1580
- discovery
- cloud_infra_discovery
source: aws_cloudtrail
Githubリンク
注：このルールはデフォルトでは有効ではありません。
このFalcoのルールを利用するためには、設定「enabled」を「true」に変更します。
ラテラルムーブメント（Lateral movement）
ラテラルムーブメントのテクニック「taint shared content」は、組織内の他のシステムへのアクセスを拡大するために、共有リソースを危険にさらす行為を指します。AWS Lambda functionのコンテキストでは、functionのコードを更新することは、コードの更新が悪意があり、組織内の他のシステムにアクセスすることを意図している場合、「taint shared content」の一形態と考えることができます。 例えば、攻撃者がLambda functionにアクセスし、そのコードを更新して悪意のあるペイロードを含めることができた場合、このペイロードは、組織内の他のシステムから機密情報を抽出したりデータを漏洩したりするために使用される可能性があります。また、攻撃者はコードを更新して、後日、侵害されたシステムへのアクセスを回復できるようにするバックドアを含めることも可能です。 AWS Lambda functionのコンテキストにおける「taint shared content」のリスクを軽減するためには、アクセス制御やコード署名などの強力なセキュリティ制御を実施し、権限を持つ個人のみがLambda functionのコードを更新できるようにし、コードの更新はデプロイ前に十分に検証することが重要です。さらに、Lambda functionのコードの変更など、Lambda functionの活動を監視することで、悪意のある活動を適時に検知・防止することができます（Github Link）。- rule: Update Lambda Function Code
desc: Detects updates to a Lambda function code.
condition:
ct.name="UpdateFunctionCode20150331v2" and not ct.error exists
output:
The code of a Lambda function has been updated.
(requesting user=%ct.user,
requesting IP=%ct.srcip,
AWS region=%ct.region,
lambda function=%ct.request.functionname)
priority: WARNING
tags:
- aws
- T1080
- lateral_movement
- taint_shared_content
source: aws_cloudtrail
収集（Collection）
MITREの戦術「収集」は、ターゲットシステムから情報を収集することを指します。「data from cloud storage」というテクニックでは、クラウドベースのストレージシステムに保存されているデータの収集が行われます。
AWS（Amazon Web Services）において、「Put Bucket ACL (Access Control List)」という操作は、S3バケットに保存されているデータへのアクセスを制御できるため、これらの戦術やテクニックと整合性を持たせることができます。バケットにACLを設定することで、そのバケットに保存されているデータへのアクセスや取得を許可するユーザーやシステムを決定することができます。
例えば、攻撃者がS3バケットにアクセスし、「Put Bucket ACL」操作でバケットに保存されているデータへのアクセスを許可するようにACLを変更した場合、「data from cloud storage」のテクニックを使ってターゲットシステムから機密情報を収集することができます。ACLを変更することで、攻撃者はクラウドストレージからデータを収集するために必要な権限を得ることができ、効果的に「収集」作業を行うことができます。
クラウドストレージにおけるさらなる脅威を知りたい方は、クラウドストレージの強奪について調べてみてください。
- rule: Put Bucket ACL
desc: Detect setting the permissions on an existing bucket using access control lists.
condition:
ct.name="PutBucketAcl" and not ct.error exists
output:
The permissions on an existing bucket have been set using access control lists.
(requesting user=%ct.user,
requesting IP=%ct.srcip,
AWS region=%ct.region,
bucket name=%s3.bucket)
priority: WARNING
tags:
- aws
- aws
- collection
- data_from_cloud_storage
source: aws_cloudtrail
Githubリンク
ATT&CKマトリクスに基づくカスタムルールの構築
攻撃者は、典型的なファイル転送/ダウンロードやネットワークベースの漏洩検知を避けるために、クラウド環境のバックアップを含むデータを、同じサービス上でコントロールする別のクラウドアカウントに転送して、データを漏洩させる可能性があります。 通常のファイル転送やコマンド＆コントロール・チャネルを通じて、クラウド環境の外部への大規模な転送を監視している防御者は、同じクラウド・プロバイダー内の別のアカウントへのデータ転送を監視していない可能性があります。このような転送は、既存のクラウドプロバイダーのAPIやクラウドプロバイダーの内部アドレス空間を利用して、通常のトラフィックに紛れ込ませたり、外部ネットワークインターフェイス経由のデータ転送を回避したりすることができます。 しかし、AWS Cloudtrailプラグインには、データ漏洩に関連するデフォルトのルールが用意されていません。デフォルトのルールで提供されていないテクニックに対処するために、独自のカスタムルールを作成することができます。実際、私たちは、MITRE ATT&CK for Cloud Matrixで広範なカバレッジを提供できるように、より多くの読者がFalcoプロジェクトにルールを寄稿することを推奨しています。 以下は、このギャップに対処するために私たちが作成したカスタムルールの例です。- rule: Transfer Data to Cloud Account
desc: Detects outbound connection to another AWS account.
condition: >
aws.eventName="CreateConnection"
and jevt.value[/requestParameters/egress]="true"
and eventName="ConfirmPublicVirtualInterface"
and not aws.errorCode exists
output: Data was transferred to a different AWS account
(requesting user=%aws.user, requesting IP=%aws.sourceIP,
AWS region=%aws.region, arn=%jevt.value[/userIdentity/arn],
network acl id=%jevt.value[/requestParameters/networkAclId])
priority: WARNING
tags: [aws, exfiltration, transfer_data_to_cloud_account, T1537]
source: aws_cloudtrail
このルールは現在、Falcoのコミュニティ・ルール・フィード内には存在しません。
GorillaStackのこの記事を参照することで、AWSのイベント名を簡単に参照することができます。イベント名 ‘ConfirmPublicVirtualInterface’ は、パブリック仮想インターフェースが他のAWSアカウントによって作成され、承認された場合に発生するイベントです。私たちの場合、別のAWSアカウントに接続が確立されたときにアラートを出したいので、接続を受け入れる必要があります。私たちはこれをイベント名 ‘CreateConnection‘ を通して行います。さらに重要なことは、データを別のアカウントに転送する必要があることです。イベント値が egress=true に設定されていれば、異なるAWSアカウントへの外向きの接続であることが分かります。