GuardDutyの新機能「SensitiveFileModified検出」をECS Express Modeで試してみた

2026年7月リリースのGuardDuty SensitiveFileModified検出を、同時期にサイドカー対応したECS Express Mode環境で検証しました。Runtime Monitoringの有効化からAgent自動注入の確認、Finding構造の確認までの手順を紹介します。

suzuki.ryo

2026.07.02

はじめに

2026年7月1日、AWSから2つのアップデートが同時にリリースされました。

Amazon GuardDuty Runtime Monitoring に SensitiveFileModified 検出タイプが追加 — EC2/EKS/ECS上で /etc/passwd や /etc/shadow などの機密ファイルが変更された際に検知する
Amazon ECS Express Mode がカスタムタスク定義とサイドカーに対応 — Express Modeでもサイドカーコンテナを含むカスタムタスク定義が使用可能に

この2つのアップデートを組み合わせることで、Express ModeでもGuardDuty Runtime Monitoringを利用できるようになりました。従来のExpress Modeはサイドカー非対応だったため、GuardDutyのSecurity Agentを注入できず、Runtime Monitoringを利用しづらい状況でした。今回のサイドカー対応により、Express Mode環境でもAgent注入が可能になりました。

項目	従来の Express Mode	サイドカー対応後の Express Mode
GuardDuty Runtime Monitoring	利用不可（Agent 注入不可）	利用可能（設定有効化後、新規タスクに自動注入）
SensitiveFileModified 検出	対象外	対象
セキュリティサイドカー	不可	可能
検出可能な脅威	ランタイム内のプロセス・ファイル操作は対象外	ランタイムレベルの脅威も検出

本記事では、Express Mode環境でGuardDuty Runtime Monitoringを有効化し、Security Agentが自動注入されることを確認します。あわせて、SensitiveFileModified Findingの構造をサンプルで確認します。

GuardDuty Runtime Monitoring の有効化

現状確認と有効化

まずGuardDutyのDetectorが存在し、Runtime Monitoringの状態を確認します。

aws guardduty list-detectors

{
    "DetectorIds": [
        "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
    ]
}

DetectorのRuntime Monitoring状態を確認します。

aws guardduty get-detector --detector-id <detector-id>

RUNTIME_MONITORING と ECS_FARGATE_AGENT_MANAGEMENT がDISABLEDだったため、有効化します。

aws guardduty update-detector \
  --detector-id <detector-id> \
  --features '[{"Name":"RUNTIME_MONITORING","Status":"ENABLED","AdditionalConfiguration":[{"Name":"ECS_FARGATE_AGENT_MANAGEMENT","Status":"ENABLED"}]}]'

有効化後の状態です。

aws guardduty get-detector --detector-id <detector-id> \
  | jq '.Features[] | select(.Name == "RUNTIME_MONITORING")'

{
    "Name": "RUNTIME_MONITORING",
    "Status": "ENABLED",
    "UpdatedAt": "2026-07-02T09:45:04+09:00",
    "AdditionalConfiguration": [
        {
            "Name": "EKS_ADDON_MANAGEMENT",
            "Status": "DISABLED",
            "UpdatedAt": "2026-07-02T09:45:09+09:00"
        },
        {
            "Name": "ECS_FARGATE_AGENT_MANAGEMENT",
            "Status": "ENABLED",
            "UpdatedAt": "2026-07-02T09:45:04+09:00"
        },
        {
            "Name": "EC2_AGENT_MANAGEMENT",
            "Status": "DISABLED",
            "UpdatedAt": "2026-07-02T09:45:09+09:00"
        }
    ]
}

RUNTIME_MONITORING: ENABLED、ECS_FARGATE_AGENT_MANAGEMENT: ENABLED を確認できました。

Express Mode サービスへの GuardDuty Agent 注入確認

重要: 有効化後の再デプロイが必要

Runtime Monitoringを有効化しただけでは、既に動いているタスクにAgentは注入されません。新しいタスクが起動するタイミングでAgentが自動注入されます。

Express Modeサービスに対して force-new-deployment を実行し、新しいタスクを起動しました。後続の検出テストでECS Execを使用するため --enable-execute-command もあわせて指定しています。

aws ecs update-service \
  --cluster default \
  --service nginx-1bf2 \
  --enable-execute-command \
  --force-new-deployment

Agent 注入の確認

aws ecs describe-tasks \
  --cluster default \
  --tasks <task-id>

コンテナ一覧にGuardDuty Agentサイドカーが含まれていました。

{
    "containers": [
        {
            "name": "Main",
            "image": "public.ecr.aws/nginx/nginx:latest",
            "lastStatus": "RUNNING",
            "healthStatus": "HEALTHY"
        },
        {
            "name": "aws-guardduty-agent-zrVxJi2",
            "lastStatus": "RUNNING"
        }
    ]
}

タスク定義には Main コンテナしか定義していませんが、GuardDutyが aws-guardduty-agent-<ランダム文字列> という名前のサイドカーコンテナを自動で注入しています。

Agentコンテナのoverridesから、注入された環境変数も確認できます。

{
    "containerOverrides": [
        {
            "name": "aws-guardduty-agent-zrVxJi2",
            "environment": [
                {"name": "CLUSTER_NAME", "value": "default"},
                {"name": "REGION", "value": "ap-northeast-1"},
                {"name": "HOST_PROC", "value": "/host_proc"},
                {"name": "AGENT_RUNTIME_ENVIRONMENT", "value": "ecsfargate"},
                {"name": "STAGE", "value": "prod"}
            ],
            "memory": 128
        }
    ]
}

Agentには128MBのメモリが割り当てられ、AGENT_RUNTIME_ENVIRONMENT=ecsfargate としてECS Fargate環境向けの動作モードで稼働しています。

SensitiveFileModified 検出のトリガー

以下の操作を実施しましたが、検証時点ではFindingは生成されませんでした。検出条件や反映遅延など複数の要因が考えられますが、理由は特定できていません。Findingの構造確認は create-sample-findings で生成したサンプルで行います（次セクション）。

ECS Exec での機密ファイル操作

ECS Execでコンテナに接続し、機密ファイルを操作しました。

aws ecs execute-command \
  --cluster default \
  --task <task-id> \
  --container Main \
  --interactive \
  --command "bash"

接続後、以下の操作を実行しました。

# Persistence: /etc/passwd にUID 0のユーザーを追加
echo "malicious:x:0:0::/root:/bin/bash" >> /etc/passwd

# PrivilegeEscalation: /etc/shadow にパスワードなしエントリを追加
echo "malicious::0:0:99999:7:::" >> /etc/shadow

# DefenseEvasion: ログファイルの削除
rm -f /var/log/dpkg.log
rm -f /var/log/alternatives.log

# 追加: /etc/group, /etc/crontab への変更
echo "root2:x:0:malicious" >> /etc/group
echo "* * * * * root /tmp/backdoor.sh" >> /etc/crontab

操作の詳細についてはGuardDuty公式ドキュメントを参照してください。

SensitiveFileModified Finding の構造

実環境ではFindingが生成されなかったため、create-sample-findings で生成したサンプルを基に構造を確認します。

aws guardduty create-sample-findings \
  --detector-id <detector-id> \
  --finding-types \
    "Persistence:Runtime/SensitiveFileModified" \
    "PrivilegeEscalation:Runtime/SensitiveFileModified" \
    "DefenseEvasion:Runtime/SensitiveFileModified"

SensitiveFileModifiedには3つのタイプがあります。

Finding タイプ	MITRE ATT&CK® タクティクス	想定される攻撃
Persistence:Runtime/SensitiveFileModified	Persistence（永続化）	不正ユーザーの追加、バックドアの設置
PrivilegeEscalation:Runtime/SensitiveFileModified	Privilege Escalation（権限昇格）	sudoers変更、SUID設定変更
DefenseEvasion:Runtime/SensitiveFileModified	Defense Evasion（防御回避）	ログ削除、監査設定の無効化

Finding の詳細

以下はDefenseEvasionタイプの抜粋です。create-sample-findings で生成したサンプル上では、主に以下のフィールドに差分が見られました。

フィールド	Persistence	PrivilegeEscalation	DefenseEvasion
Type	Persistence:Runtime/...	PrivilegeEscalation:Runtime/...	DefenseEvasion:Runtime/...
Description	...for the purpose of persistence	...for the purpose of privilege escalation	...for the purpose of defense evasion
Context.FilePath	/etc/passwd	/etc/sudoers	/etc/shadow

代表としてDefenseEvasionの主要フィールドを示します。

{
    "Type": "DefenseEvasion:Runtime/SensitiveFileModified",
    "Severity": 5.0,
    "Title": "Security-sensitive file modification is detected in a resource of type ECSCluster.",
    "Resource": {
        "ResourceType": "ECSCluster",
        "EcsClusterDetails": {
            "Arn": "arn:aws:ecs:ap-northeast-1:xxxxxxxxxxxx:cluster/default",
            "TaskDetails": {
                "Arn": "arn:aws:ecs:ap-northeast-1:xxxxxxxxxxxx:task/default/xxxx",
                "Containers": [
                    {
                        "Name": "Main",
                        "Image": "public.ecr.aws/nginx/nginx:latest"
                    }
                ]
            }
        }
    },
    "Service": {
        "FeatureName": "RuntimeMonitoring",
        "RuntimeDetails": {
            "Process": {
                "Name": "bash",
                "ExecutablePath": "/usr/bin/bash",
                "Pid": 1234,
                "Lineage": [...]
            },
            "Context": {
                "FileOperation": "open-for-write",
                "FilePath": "/etc/shadow",
                "RelatedFilePaths": [
                    "/etc/passwd",
                    "/etc/group"
                ]
            }
        }
    }
}

上記は主要フィールドの抜粋です。全フィールドを含むJSON全文は以下を参照してください。

Finding JSON全文（DefenseEvasion:Runtime/SensitiveFileModified）

※ create-sample-findings で生成したサンプルです。クラスター名・リージョン・タスク定義ARN等は検証環境の値に置き換えて掲載しています。

{
    "AccountId": "xxxxxxxxxxxx",
    "Region": "ap-northeast-1",
    "Type": "DefenseEvasion:Runtime/SensitiveFileModified",
    "Severity": 5.0,
    "Title": "Security-sensitive file modification is detected in a resource of type ECSCluster.",
    "Description": "Process bash in a resource of type ECSCluster has modified a security-sensitive file /etc/shadow through open-for-write file operation for the purpose of defense evasion.",
    "Resource": {
        "ResourceType": "ECSCluster",
        "EcsClusterDetails": {
            "Name": "default",
            "Arn": "arn:aws:ecs:ap-northeast-1:xxxxxxxxxxxx:cluster/default",
            "Status": "ACTIVE",
            "TaskDetails": {
                "Arn": "arn:aws:ecs:ap-northeast-1:xxxxxxxxxxxx:task/default/xxxx",
                "DefinitionArn": "arn:aws:ecs:ap-northeast-1:xxxxxxxxxxxx:task-definition/guardduty-express-mode-test:1",
                "Containers": [
                    {
                        "ContainerRuntime": "containerd",
                        "Name": "Main",
                        "Image": "public.ecr.aws/nginx/nginx:latest"
                    }
                ],
                "LaunchType": "FARGATE"
            }
        }
    },
    "Service": {
        "FeatureName": "RuntimeMonitoring",
        "RuntimeDetails": {
            "Process": {
                "Name": "bash",
                "ExecutablePath": "/usr/bin/bash",
                "Pid": 1234,
                "User": "root",
                "UserId": 0,
                "Lineage": [
                    {
                        "Name": "ssm-agent-worker",
                        "Pid": 1233,
                        "ExecutablePath": "/usr/bin/ssm-agent-worker"
                    }
                ]
            },
            "Context": {
                "FileOperation": "open-for-write",
                "FilePath": "/etc/shadow",
                "RelatedFilePaths": [
                    "/etc/passwd",
                    "/etc/group"
                ]
            }
        }
    }
}

Severity 5.0（Medium） — 緊急ではないが対応が必要なレベル
ResourceType: ECSCluster — ECS環境での検出であることが明示される
RuntimeDetails.Context — FileOperation（操作種別）、FilePath（対象ファイル）、RelatedFilePaths（同一セッションで操作された関連ファイル）が含まれる
RuntimeDetails.Process — 操作を行ったプロセスの情報と Lineage（プロセスツリー）が記録される
FeatureName: RuntimeMonitoring — Runtime Monitoring機能による検出であることを示す

まとめ

ECS Express Modeがカスタムタスク定義とサイドカーに対応したことで、Runtime Monitoring有効化済みのExpress Mode環境でもGuardDuty Security Agentの自動注入を確認できました。今回の検証環境では、アプリケーション側のタスク定義を変更せず、Runtime Monitoring有効化とサービスの再デプロイだけでAgentサイドカーが追加されました。

実操作によるSensitiveFileModified Findingの生成までは確認できませんでしたが、サンプルFindingからは、プロセス情報や対象ファイルパスなどが記録されることを確認できました。機密ファイル変更の調査に役立つ情報が含まれる検出タイプといえそうです。

GuardDutyの新機能「SensitiveFileModified検出」をECS Express Modeで試してみた

はじめに

GuardDuty Runtime Monitoring の有効化

現状確認と有効化

Express Mode サービスへの GuardDuty Agent 注入確認

重要: 有効化後の再デプロイが必要

Agent 注入の確認

SensitiveFileModified 検出のトリガー

ECS Exec での機密ファイル操作

SensitiveFileModified Finding の構造

Finding の詳細

まとめ

参考リンク

関連記事

AWSで探す

注目のテーマ

プロダクトやサービスで探す

特集やシリーズから探す

EVENTS