箱が四つ届いたのに、送り状に差出人がなかった
8月28日、二日間何も捕まらなかったサーバーからファイルが四つ一度に出てきました。合計773,937バイト、送り元はすべて同じ一箇所でした。ところがこのファイルには『どこから来たのか』を書く欄がそもそも存在せず、ブロックリストに載せるアドレスも通報すべき配布元も残りませんでした。

家に帰ると、ドアの前に箱が一つ置かれています。注文した覚えがありません。
それでも普通はすぐに解決します。送り状を見ればいいからです。差出人の欄に店の名前があり、電話番号があり、注文番号があります。誤配なら、そこへ電話して引き取ってもらえばいい。おかしなものが届き続けるなら、その店を通報することもできます。
ところが送り状を見たら、差出人の欄がそもそもなかったらどうなるでしょうか。印字が消えたのではなく、最初からその欄が紙にありません。宛先だけが書かれています。
このとき、できることが一気に減ります。返品もできず、どこに抗議すればいいかも分からず、「この店から来るものは全部止めてください」と管理室に言うこともできません。残るのは箱そのものだけです。重さを量り、写真を撮っておくこと以外には。
2026年8月28日の一日、私たちのサーバーにそんな箱が四つ届きました。
まず、聞き慣れない言葉を一つだけ説明しておきます。ハニーポットとは、わざと隙のある造りにしてインターネット上に置いた囮のサーバーです。実際の業務はしません。誰が入ってきて何をするのかを丸ごと記録するために開けてある機械です。以下の数字はすべて、そこに刻まれたものです。
私たちのサーバーは二台あり、性格が正反対です
事実 一台目(センサー01)は高対話型サーバーです。実際にログインができ、入ってきた者がコマンドを打つことができ、そのコマンドがすべて記録されます。二台目(センサー02)は低対話型サーバーです。ドアの前で挨拶を受けるだけで、決して開けません。
事実 そのため二台目のサーバーには、ログイン成功もコマンドも認証情報もそもそも存在しません。 そこで数えられるのは「何回叩かれたか」と「相手がどんな規格で話しかけてきたか」だけです。そしてごくたまに、今日のように物が残ります。
この記事の箱四つは、すべて二台目のサーバーの話です。
二日間空だった欄が埋まりました
事実 このサーバーで確保された検体は、8月26日0件、8月27日0件でした。8月28日は4件です。
事実 これは単に数字が上がったという話ではありません。8月26日のブリーフに、私たちはこう書き留めていました — 「このチャネルは投入内容が残りうる唯一の経路なのに、詳細が空である。次の収集で確認が必要だ」。8月27日にも同じ文をまた書きました。三日目にして初めて、その欄が埋まりました。
事実 四つのサイズはこうです。46,525バイト・153,208バイト・239,388バイト・334,816バイト。おおよそ45KBから327KBまでです。全部合わせると773,937バイトです。
事実
そして四つとも同じ一箇所から来ました。別名 ATK-F4738A 一つだけです。
送り状に差出人の欄がありません
事実 この四件について私たちのデータが持っているのは二つだけです。sha256(ファイルの指紋)とサイズです。
ここで指紋という言葉を説明しておきます。ファイル全体を計算して取り出した64桁の値です。ファイルの中の文字が一つ変わるだけで値が丸ごと変わります。箱に貼った封印シールのようなもので、二つの箱が同じ物かどうかをこれで判定します。
事実 そしてURLの欄がありません。 値が空なのではなく、データにその項目自体が存在しません。どこからダウンロードされたのか、どのアドレスに置かれていたのかが記録にありません。
推定 なぜないのかは、こう読みます。サーバーが注文して受け取ったファイルなら、注文したアドレスが残ります。ところが相手がただ押し込んだファイルなら、注文自体がなかったのでアドレスがそもそも生まれません。送り状に差出人の欄がないのではなく、送り状を書く必要がなかったのです。
推定 これが実務で意味するのは一つです。ブロックリストに載せるアドレスがなく、通報すべき配布元がありません。 ファイアウォールに書き込む欄が空です。残るのは箱の封印シール、つまりsha256が四つだけです。
事実
同じ問題が今日、別の場所でも引っかかります。私たちが解凍して初めて得られた指標が12件あるのですが(31[.]77[.]227[.]121/bins/ 以下のファイル名)、これらのファイルも外側だけを見てはアドレスが一つも見えません。 圧縮を剥がさなければ出てきません。今日の箱四つは、剥がす外側すらない側です。
反対側のサーバーには送り状が残っていました
同じ日に一台目のサーバーへ降りてきたファイルは性格が違います。データを先に置いてから説明します。
事実 8月28日、一台目のサーバーで確保された検体は8種です。そのうち二件にはアドレスが残っています。
hxxp://185[.]93[.]89[.]72/wget— 306バイトのシェルスクリプトが置かれていた場所hxxp://5[.]182[.]210[.]174/ok— 1,608バイトのbashスクリプトが置かれていた場所
事実
アドレスはわざと壊して書いています(hxxp://、[.])。そのままコピーして貼り付けても接続されません。
事実 今日、通報の対象となる配布元はこの二箇所です。二台目のサーバーの箱四つからは、通報できる指標が一つも出ていません。
推定 この違いが今日の骨組みです。一方はサーバーが外へ出て行って受け取ってきたので、「どの店から来たのか」が残りました。もう一方は相手が持ってきて置いていったので、何も残りませんでした。同じ日、同じ組織の二台のサーバーから、正反対の形が出てきました。
重さを量ってみると、もっとおかしいです
事実 一台目のサーバーの検体8種を全部合わせると2,783バイトです。短いテキストメッセージ十数通ほどの量です。
事実 二台目のサーバーの検体は4種で773,937バイトです。約278倍大きいです。
事実 数字をもう一つ添えると感覚がつかめます。四つの箱のうち一番小さいもの一つ(46,525バイト)だけで、一台目のサーバーの一日分八つを全部合わせたものの約16.7倍です。
事実 そして一台目のサーバーではELF実行ファイルが0件です。ELFはLinuxでそのまま実行されるプログラムのファイル形式です。8月27日に続いて二日連続で0件です。
推定 ウイルス対策ソフトが捕まえそうな「プログラム」は一方で二日目も降りてこないのに、反対側では三日ぶりに初めて大きな箱が四つ入ってきました。二つの観測面を別々に見れば、それぞれ「静かな日」と「おかしな日」ですが、並べて置くと重心が移動した図になります。
事実 ただし、ここできっちり止まらなければなりません。この四つが何のファイルなのか、私たちのデータにはありません。 種類を書く欄もありません。実行ファイルなのか、圧縮ファイルなのか、写真なのか分かりません。「45KBから327KBだから実行ファイルだろう」とは書きません。
どの扉から入ってきたのか
事実 二台目のサーバーが昨日受けた接触は47,815件です。一日をきっちり割ると約1.8秒に一回です。二回まばたきするたびに、どこかからこの機械に話しかけていました。互いに異なる発信元は248箇所です。
事実 一昨日(30,804件)より55.2%増え、8月26日の42,493件も超えました。三日のうち最も混み合った日です。
事実 その47,815件がどの扉の前に集まったのかを見ると、こうなります。
| 扉 | 接触 | 固有発信元 | 割合 |
|---|---|---|---|
| 画面共有 (VNC 5900) | 45,113件 | 50箇所 | 94.35% |
| リモートデスクトップ (RDP 3389) | 2,114件 | 120箇所 | 4.42% |
| データベース (MSSQL 1433) | 200件 | 13箇所 | 0.42% |
| ファイル共有 (SMB 445) | 175件 | 37箇所 | 0.37% |
| アドレス帳 (LDAP 389) | 126件 | 9箇所 | 0.26% |
| 開発者用デバッグ経路 (ADB) | セッション87件 | 記録なし | 0.18% |
事実 表の一番下の行が今日の舞台です。ADBは、Android機器をコンピュータに接続して開発者が中を覗いたりファイルを入れたりするときに使う経路です。もともとケーブルで接続して使うために作られたものですが、インターネット側に開いているとパスワードを尋ねません。 87セッションなら、一日に約16分に一回のペースです。
推定 低対話型サーバーでファイル投入が成立しうる経路はADBだけです。 だから箱四つをこちら側として読みます。データがこれを明示してくれるわけではありません。この判断は末尾の「私たちが分からないこと」で改めて押さえます。
事実 ADBセッション数の三日間の推移は 8/26 86 → 8/27 26 → 8/28 87 です。ところが検体は 0 → 0 → 4 です。セッション数が8月26日とほぼ同じなのに、結果だけが違います。
箱を置いていった場所は名簿にありませんでした
事実 二台目のサーバーを最も多く叩いた九箇所はこうです。
| 別名 | マスキングIP | 接触 |
|---|---|---|
| ATK-943F0E | 129.212.x.x | 5,305件 |
| ATK-43D1F7 | 143.198.x.x | 5,301件 |
| ATK-554563 | 167.99.x.x | 5,269件 |
| ATK-28B422 | 206.81.x.x | 5,073件 |
| ATK-B954FC | 159.203.x.x | 5,065件 |
| ATK-AE6CC0 | 134.122.x.x | 5,023件 |
| ATK-B24952 | 159.223.x.x | 4,683件 |
| ATK-992AD3 | 68.183.x.x | 4,672件 |
| ATK-D9A63B | 159.203.x.x | 4,644件 |
事実 この九箇所が合わせて45,035件、全接触の**94.19%**です。
事実
そして箱を置いていった ATK-F4738A は、この名簿にも、その下の十二箇所のリストにもありません。 接触の順位に名前を載せられなかった場所です。
事実 名簿にないので、マスキングIPも、何回接触したのかも私たちには分かりません。「順位にない」までが事実であり、それ以上は言えません。
推定 宅配便の話に戻すと、こうなります。夜通しインターホンを5,000回ずつ押した九軒は、管理室の記録にくっきり残りました。箱を置いていった者は記録にありません。危険な順に並べた名簿ではなく、うるさい順に並べた名簿だったのです。
一日を時系列で
時系列に並べると、こうなります。ここからは**一台目のサーバー(高対話型)**の記録がほとんどです。三行目と四行目の所要時間に注目してください — 分ではなく秒単位です。
- 事実 ATK-D62131(220.133.x.x) がTelnetログインに成功。コマンド31個、ダウンロード1件。intents はファイルダウンロード → 実行権限付与 → ダウンロード後実行の3種で、偵察・永続化はない。Telnetなので SSH 指紋は存在しない(fingerprint 空文字列)。completeness 16
- 事実 ATK-4F095E(47.82.x.x) がTelnetログインに成功。コマンド17個、intents 5種(偵察 — システム · ファイルダウンロード · 実行権限付与 · ダウンロード後実行 · 永続化 — SSH鍵の埋め込み)。ところが download_count は 0 である。completeness 17
- 事実 ATK-CA5936(130.12.x.x) がSSHログインに成功。コマンドは1個なのに intents が5種付き、ダウンロード2件。クライアント SSH-2.0-Go、指紋 16443846…4397。completeness 19 で今日の最高
- 事実 同じ別名 ATK-CA5936 が83分後に再接続。コマンド1個・intents 5種・ダウンロード2件・指紋同一で、09:20 のセッションと構成が完全に同じである
- 事実 ATK-AE28B3(187.52.x.x) がSSHログインに成功。コマンド18個、intents 4種 — 偵察 — システム · 永続化 — SSH鍵の埋め込み · 永続化 — cron · 痕跡削除。今日唯一の cron セッションである(一日の総計も1回)。ダウンロード1件。クライアント SSH-2.0-libssh_0.11.1、指紋 03a80b21…e6fb。completeness 18
- 事実 検体4件を確保。サイズ 46,525 · 239,388 · 334,816 · 153,208バイト、合計 773,937バイト。delivered_by は4件とも ATK-F4738A 一箇所である。このセンサーのどの項目にもタイムスタンプがなく、一日のうちいつなのか言えない
- 事実 ブリーフ生成。センサー01 の一日の集計はセッション 3,303 · 固有発信元 202 · ログイン試行 3,051 · コマンド 10,940 · TTY録画 2,836 であり、センサー02 は接触 47,815 · 固有発信元 248 である
事実 表で最も目を引くのは三行目・四行目です。4.8秒と3.7秒のセッション二件で、コマンド数・意図の種類・ダウンロード数・接続プログラムの指紋が一つも違わず同じです。 83分間隔です。
推定 同じツールが二度動いた形として読みます。ここまでが言えるすべてです。同じ人物だとか同じ組織だとかは言えません。
事実 そして六行目が今日の主役なのですが、時刻の欄が空です。 二台目のサーバーには時間の記録がそもそもありません。箱がいつ置かれたのか、私たちには分かりません。送り状に差出人の欄がないのと同じように、ここには配達時刻の欄がありません。
その間、一台目のサーバーは方向が裏返りました
事実 昨日、一台目のサーバーで実行されたコマンドは10,940個です。8月27日は2,313個でした。一日で4.7倍になりました。一日をきっちり割ると、約8秒に一回コマンドが入ってきた計算です。
事実 ところが訪れた場所の数は逆に動きました。互いに異なる発信元が202箇所で、8月27日の442箇所から54.3%減りました。
事実 セッション一つあたりのコマンドが、8月27日の0.89個から昨日は3.31個になりました。
推定 一昨日が「多くの場所が広く撫でていった日」だとすれば、この日は**「少ない場所が深く入ってきた日」**です。
事実 接続経路も一日で裏返りました。Telnetセッションが**2,081件で全体の63.0%**です。8月27日には186件、7.1%でした。Telnetは非常に古いリモート接続方式です。インターネットの向こうからその機械のコマンドラインを直接叩けるように開けておく経路ですが、パスワードが暗号化されずそのまま流れていきます。
事実 ところが、コマンドが4.7倍に増えた日に、意図として分類されたコマンドは1,200回(11.0%)だけです。8月27日は2,313個のうち1,970回(85.2%)でした。残りの9,740個がなぜ分類されなかったのか、データが説明しません。 そのため、この日の「偵察995回」をコマンド総計に対する比率として解釈しませんでした。
事実 分類された1,200回の内訳はこうです。
| 意図 | 回数 |
|---|---|
| 偵察 — システム | 995回 |
| 実行権限付与 | 135回 |
| ダウンロード後実行 | 21回 |
| ファイルダウンロード | 21回 |
| 永続化 — SSH鍵の埋め込み | 15回 |
| 痕跡削除 | 12回 |
| 永続化 — cron | 1回 |
ここで二つだけ説明しておきます。SSH鍵の埋め込みとは、Linuxサーバーの authorized_keys(許可された鍵の一覧)というファイルに、他人の公開鍵を一行書き込んでおく行為です。平たく言えば、パスワードなしで入れる鍵を玄関に一つ掛けておくことです。パスワードを変えても、その鍵はそのまま開きます。cron は「何時にこれをやれ」をサーバーに予約しておく機能です。仕掛けておけば再起動しても生き残ります。
事実 「永続化 — cron」は昨日ちょうど1回です。そしてその一件は13:38のATK-AE28B3セッションから出ました。偵察 → 鍵の掛け置き → 予約の仕掛け → 痕跡消しが、27.5秒のうちに一つのセッションで続きました。
事実
そのセッションが使った接続プログラムの指紋は 03a80b21…e6fb(SSH-2.0-libssh_0.11.1)です。昨日の上位11種の指紋リストになく、8月16日から27日までの記録にもこのバージョンは現れたことがありません。
推定 ただし、線を一つ引いておきます。これはビルドの指紋であって、人の指紋ではありません。 同じディストリビューションに入っている既定のクライアントを使う、互いに何の関係もない人でも同じ値を持ちます。しかも昨日のセッションの63%を占めるTelnetには、指紋という概念自体がありません。
事実 そして「防御の無力化」は、昨日は項目自体がありません。
どんなパスワードが試されたのか
事実 昨日のログイン試行は3,051回です。一日をきっちり割ると約28秒に一回のペースで、誰かがドアノブを回してみたことになります。発信元202箇所で割ると、一箇所あたり平均15.1回です。
事実 以下は、そのうち互いに異なるIP3箇所以上で観測された組み合わせだけを抜き出した20種です。一箇所からしか出ていない組み合わせは、流出した本物の認証情報である可能性があるため値を載せません。
| ID | パスワード | 試行した発信元の数 |
|---|---|---|
admin |
admin |
15箇所 |
345gs5662d34 |
345gs5662d34 |
10箇所 |
root |
1234 |
6箇所 |
root |
123456 |
5箇所 |
root |
12345 |
5箇所 |
root |
3245gs5662d34 |
5箇所 |
root |
admin |
4箇所 |
root |
123 |
4箇所 |
root |
54321 |
3箇所 |
support |
support |
3箇所 |
root |
root |
3箇所 |
root |
pass |
3箇所 |
user |
user |
3箇所 |
admin |
(空のパスワード) |
3箇所 |
guest |
guest |
3箇所 |
nobody |
nobody |
3箇所 |
root |
1q2w3e4r |
3箇所 |
root |
123456789 |
3箇所 |
root |
qwerty123 |
3箇所 |
odoo |
odoo |
3箇所 |
事実 この20種のほかに、単一の出所からしか出ていない組み合わせが862種あります。一昨日の757種から105種増えました。個数だけを書き、値は書きません。 公開したものより公開していない側が43倍多いです。
推定
表で注目すべきは二行目です。345gs5662d34 は何の意味もなさそうな文字列で、IDとパスワードが同一です。これを互いに異なる10箇所がちょうど10回、一箇所につき一回ずつ打ちました。人が一つずつ思いついた値ではなく、どこかで出回っているリストをそのまま読んでいるという意味に読みます。
昨日置いていったもの
書き留めるべき値です。値を押すとコピーされます — 読むためにあるのではなく、ブロックリストに入れるためにある値です。アドレスはわざと壊して書いています。一番下の四行のURL欄を見てください — 今日の話はそこにあります。
a8460f446be540410004b1a8db4083773fa46f7fe76fa84219c93daa1669f8f2センサー01。389バイトの OpenSSH RSA 公開鍵。URL 未記録(セッション内で記録された)。出所12箇所・12回であり、リストには10箇所しか表記されていない。8/16 以降13日目の同じハッシュであるhxxp://185[.]93[.]89[.]72/wgetセンサー01。306バイトの POSIX シェルスクリプトが置かれていた場所。今日の通報対象の配布元二箇所のうちの一つa6296a79f44e21b76604d2d2bbf795d2cf380f70e39d45fbf166707ff3b4a6a4センサー01。上記アドレスから取得されたファイル。00:51 のセッション(ATK-D62131)が取得したものと同じハッシュであるhxxp://5[.]182[.]210[.]174/okセンサー01。1,608バイトの bash スクリプトが置かれていた場所。今日の通報対象の配布元二箇所のうちのもう一つbca838fa0f03b6b98ea955c85d0b438ccbc5b1a38d16757971bbeff061e6c8ccセンサー01。上記ファイル。サイズがちょうど1,608バイトのままハッシュだけが変わる形が記録に繰り返される43728fbfb98bb39ff61a2db0fc2905bd6937997062b05b9ab8b186fdee18c09aセンサー01。399バイトの OpenSSH 秘密鍵、2回。ATK-CA5936 一箇所。8/19・8/24・8/25 にも同じハッシュがある00b6f15c2274420217ed3098a9f5f00545bf1793d7a324fd18a7809cbbf5b12bセンサー01。54バイトの ASCII テキスト、2回。ATK-CA5936 一箇所4af5a5c98ad132095c6fbe7b02c242153a190a01cc321e50a916a0ca46fbaa62センサー01。9バイトの ASCII テキスト、3回。ATK-BECAD3 一箇所a9b1c85a7bd78dd1112ecc75c9070ea8c53078831a17aa09ebeb287fe6e21b72センサー01。9バイトの ASCII テキスト。ATK-3E7DA8 一箇所1193dde1c831808bf6f2db6f5b850b846b8a7f870873ec3b8a347f21cc5d96e3センサー01。9バイトの ASCII テキスト。ATK-3E7DA8 一箇所。この8種を全部足しても2,783バイトであり、ELF 実行ファイルは0件、二日目であるa1b6223a3ecb37b9f7e4a52909a08d9fd8f8f80aee46466127ea0f078c7f5437センサー02。334,816バイト、今日確保された検体のうち最大。ATK-F4738A。URL フィールド自体がない76ae6d577ba96b1c3a1de8b21c32a9faf6040f7e78d98269e0469d896c29dc64センサー02。239,388バイト。ATK-F4738A。URL フィールド自体がないd7188b8c575367e10ea8b36ec7cca067ef6ce6d26ffa8c74b3faa0b14ebb8ff0センサー02。153,208バイト。ATK-F4738A。URL フィールド自体がない0d3c687ffc30e185b836b99bd07fa2b0d460a090626f6bbbd40a95b98ea70257センサー02。46,525バイト、2回。ATK-F4738A。この4種の合計773,937バイトはセンサー01 の2,783バイトより約278倍大きい。ファイル種別を書く欄がなく、何であるか分からない事実
上の十行と下の四行の違いが目に見えます。上側には url の行が二つ混ざっています。下側にはありません。下の四つは、ブロックリストに書く欄がsha256一つだけです。
事実 一番上の行も押さえておきます。389バイトの公開鍵は8月16日から13日目、まったく同じハッシュです。テキストメッセージ二、三行ほどのサイズで、昨日は12箇所がこれを埋め込んでいきました。同じ鍵が13日間ずっと掛けられ続けているという意味です。
国際的な分類表に対応させると
攻撃者が使った手口には、世界中で共通に使われる番号が付いています。MITRE ATT&CKというリストです。以下でIDを押すと原文の説明に飛びます — 私たちの言葉を信じずに直接確認してほしくて付けてあります。
- T1110.001Brute Force: Password Guessing — センサー01 のログイン試行3,051回 / 固有発信元202箇所推定
- T1078.001Valid Accounts: Default Accounts — admin/admin(15箇所)など引用可能な組み合わせ20種がすべて既定値・単純な数字列推定
- T1082System Information Discovery — 「偵察 — システム」995回推定
- T1105Ingress Tool Transfer — センサー01 の「ファイルダウンロード」21回 + 検体8種。センサー02 でも検体4件が流入した(経路はデータに明示されていない)推定
- T1222.002File and Directory Permissions Modification: Linux — 「実行権限付与」135回推定
- T1098.004Account Manipulation: SSH Authorized Keys — 「永続化 — SSH鍵の埋め込み」15回推定
- T1053.003Scheduled Task/Job: Cron — 「永続化 — cron」1回。昨日はただ一件であり、ATK-AE28B3 セッションの意図と一致する推定
- T1070Indicator Removal — 「痕跡削除」12回。コマンド原文がなく、ログ・履歴・ファイルのうち何を消したのか区別できないため、下位技法は付けない推定
- T1046Network Service Discovery — センサー02 で5つのサービスポートに248箇所が接触。サービス接触の事実だけでマッピングしており、スキャンツールを特定したわけではない推定
- T1021.005 / T1021.001Remote Services: VNC / RDP — サービス種別だけでマッピングした。低対話型センサーのため、リモートサービスが実際に使用された事実は観測されていない推定
推定 十行すべてが「推定」バッジです。私たちが見たのはコマンドの意図分類と接触回数であって、攻撃者が自ら明かした目的ではないからです。特に一番下の二行は、「このポートに話しかけた」までを観測したものです。実際に破られたという意味ではありません。
昨日一日の全体
事実 一台目のサーバー(センサー01、高対話型)基準です。
| 項目 | 2026-08-28 | 備考 |
|---|---|---|
| セッション | 3,303件 | 8/26 5,488 → 8/27 2,605 → +26.8% |
| コマンド | 10,940個 | 8/27 2,313個 → 4.7倍 |
| 固有発信元 | 202箇所 | 8/27 442箇所 → -54.3% |
| ログイン試行 | 3,051回 | 約28秒に一回のペース · 一箇所あたり平均15.1回 |
| ポート 2223 (Telnet) | 2,081セッション | 全体の63.0%(8/27 は7.1%) |
| ポート 2222 (SSH) | 1,222セッション | 全体の37.0% |
| TTY録画 | 2,836件 | 実際に保管されたものは200件 |
| コマンド意図の合計 | 1,200回 | コマンド総計の11.0%(8/27 は85.2%) |
| セッションあたりコマンド | 3.31個 | 8/27 0.89個 |
| 検体 | 8種 · 合計2,783バイト | ELF 0件、二日目 |
事実 二台目のサーバー(センサー02、低対話型)基準です。セッションの単位が互いに異なるため、二台のサーバーを足しません。
| 項目 | 2026-08-28 | 備考 |
|---|---|---|
| 総接触 | 47,815件 | 8/27 30,804 → +55.2%、三日のうち最大 |
| 固有発信元 | 248箇所 | 上位9箇所が45,035件(94.19%) |
| VNC 5900 | 45,113件 / 50箇所 | 一箇所あたり平均902回 |
| RDP 3389 | 2,114件 / 120箇所 | 一箇所あたり平均17.6回(8/27 1,425件・116箇所) |
| ADB | セッション87件 | 8/26 86 → 8/27 26 → 87 |
| 検体 | 4種 · 合計773,937バイト | 8/26 0件 · 8/27 0件 → 初めて確保 |
事実
話しかけてきた規格も記録に残ります。VNCはバージョンが記録された45,081件のうち45,038件(99.90%)が003.003を提案しました。003.008は43件です。SMBのネゴシエーションで提案された方言は NT LM 0.12 58 · LANMAN1.0 53 · LM1.2X002 53 などですべてSMB1系であり、一昨日1件・その前の日2件あった SMB 2.??? の提案は、この日のリストにはまったくありません。
推定 非常に古い規格ばかりを選んで提案しています。今どきの機械ではなく、古いまま放置された機械を探しているという図として読みます。ただし、ここで観測されたのはネゴシエーションの段階までです。
事実
RDP側には、相手が自分で埋める文字列(クッキー)が残ります。hello 1,586 · <ip> 445 · (空の値)5 · nmap 4 · kset 2 · ZRIlUYMXZ 1 で合計2,043であり、2,114件のうち71件は記録されていません。
推定
nmap 4件は、8月26〜27日のリストにはなかった値です。ただし、クッキーは相手が好きなように埋められる自由文字列です。 実際にそのツールを使ったという証拠ではありません。そこに何と書かれていようと、それは自己紹介にすぎません。
それで何をすべきか
推定 ブリーフが整理した「この統制がなかったら」の六つを、昨日のデータが最も強く裏付ける順に並べます。
1. 使っていない機器の電源を抜く — 昨日、箱四つが入ってきた経路は全接触の0.18%のものでした。標的だから来るのではなく、開いているから来ます。 倉庫に放り込んであるAndroidのセットトップボックスやタブレットがインターネットにつながっていれば、それは施錠されていない裏口です。
2. 管理用ポートをインターネットにそのまま開けておかない — 昨日は202箇所が二つのポートを叩き、隣のサーバーではVNCに50箇所・45,113件、RDPに120箇所・2,114件が付きました。脆弱性がなくても、開いているという理由だけで来ます。
3. 既定のパスワードを使わない — 上の表の20種は、互いに異なるIP3箇所以上が実際に叩いた組み合わせです。このうち一つでも生きていれば、その日のうちに開きます。昨日の完結性上位5セッションは例外なくログインに成功しました。 最も速いものは4.8秒でした。
4. authorized_keys ファイルを一度開いてみる — 昨日は鍵の掛け置きが15回、cronの仕掛けが1回観測されました。埋め込まれた389バイトの公開鍵は13日目の同じファイルです。自分で入れた覚えのない行があれば、それが他人の鍵です。パスワードを変えることでは消えません。
5. 同じ場所が叩き続けるなら遮断する — ただし半分しか止まりません 事実 二台目のサーバーは上位9箇所を止めるだけで、昨日の接触の94%が消えます。止める対象が少ないのです。推定 ところが 345gs5662d34 のような組み合わせは、10箇所がちょうど一回ずつしか試していません。一箇所あたり1回の分散型の試行には、IP単位の遮断が効きません。 二つの形が同じ日に一緒に来ます。
6. サーバーから外へ出て行く接続を制限する — ここで今日の限界が出てきます 事実 昨日のファイルダウンロード21回・ダウンロード後実行21回は、ここで断ち切られます。推定 ところがアウトバウンド遮断は「注文をさせないようにすること」です。 すでにドアの前に置いていかれた箱には何の効果もありません。二台目のサーバーの箱四つにURLがないということは、出て行くトラフィックを全部止めても、その経路はそのまま開いたままだという意味かもしれません。
7. ログをサーバーの外に別途残す — 痕跡を消そうとする意図が12回観測されました(8/25 70回、8/27 36回から減り続けています)。セッション3,303件に対して0.36%と少ない方なので、危険度を「中」に置きました。それでも、ログがサーバーの中にしかなかったなら、そのうちの一部は成功していたでしょう。
以前にもあったこと
推定 ADB.Miner(2018年)。 Androidデバッグブリッジが開いている機器を撫でて、マイニングコードを拡散させたワームです。認証手続きなしに開いているデバッグ経路にファイルを押し込んで広がったという点が、昨日唯一実物の検体が確保されたチャネルがADB系であり、その87セッションが全接触の0.18%にすぎなかったという構図と文脈でつながります。ただし私たちのデータにはファイル種別も挙動もありません。 昨日の検体をこの系統だと特定したわけではなく、感染規模の数値も引用しません。(根拠:セキュリティ企業の公開リサーチチーム報告 — 360 Netlab、2018年2月 — および以後の複数ベンダーによる公開分析)
推定 ADBインターフェースを経由して拡散したMirai派生系統(2019年)。 既定の認証情報の辞書で広がっていた系統が、認証のないデバッグポートという別経路を併用し始めた形です。昨日、一台目のサーバーの認証情報辞書20種と、二台目のサーバーの検体流入が同じ日に一つの組織の異なるサーバーで同時に観測された構図と似ています。ただし、二台のサーバーの発信元の共通部分を私たちのデータで確認できないため、同じキャンペーンだと言う根拠はありません。(根拠:ベンダーの公開脅威分析報告 — Trend Micro、2019 — およびMITRE ATT&CK T1105技法の文書)
私たちが分からないこと
この記事で最も重要な部分です。上に書いたことよりも、書けなかったことの方が多いのです。
- センサー02の検体4件がADBから入ってきたというのは推定です。 データはこの4件がどのサービスを経由したのかを明示せず、サービス一覧にADBの項目がなく、8/26・8/27に続いてこの日も個別のADB詳細ブロックがありません。「低対話型サーバーでファイル投入が成立しうるチャネルはADBだけ」という前提に寄りかかった判断です。
- ADBセッションは 8/26 86 → 8/27 26 → 8/28 87 なのに、検体は 0 · 0 · 4 です。セッション数が8/26とほぼ同じなのに結果が違います。 攻撃の挙動が変わったのか、収集器の状態が変わったのか、データでは区別できません。この記事のタイトルがこの違いに懸かっているので、最も重要な不確実性です。
- センサー02の検体4件にはファイル種別を書く欄がありません。 サイズしかなく、実行ファイルなのか圧縮ファイルなのか画像なのか分かりません。「45KB〜327KBだから実行ファイルだろう」とは書きませんでした。
ATK-F4738Aは上位発信元12箇所のリストにないため、マスキングIPも接触数も分かりません。「接触の順位にない」までが事実であり、この発信元が何回接触したのかは言えません。- センサー02で**「一つの発信元が複数のサービスを撫でたのか」は判定できません。** 発信元別のサービス一覧がなく、サービス別の固有IPの合計(50+120+13+37+9=229)が総固有IP 248より小さいため、重複がまったくなくても数値が成立します。
- 上位9箇所の合計(45,035)がVNCの接触(45,113)とほぼ同じですが、データが発信元とサービスを結び付けてくれません。 これらがVNC側だと確定することはできません。
- センサー01のコマンド10,940個のうち、意図として分類されたものは1,200回(11.0%)だけです。8/27は85.2%でした。残りの9,740個が意図のないコマンドなのか、分類が失敗したのか、データが説明しません。
- 「永続化 — SSH鍵の埋め込み」15回と、389バイトの公開鍵のダウンロード12回(別名12箇所)は結び付きません。 15回すべてがこの鍵を埋め込んだのか確認できず、配送の出所は12箇所のうち10箇所しか表記されていません。
- 05:49のATK-4F095Eセッションは、意図に「ファイルダウンロード」と「ダウンロード後実行」があるのにダウンロード数は0です。失敗したのか、成功したが保存されなかったのか区別できません。
- ATK-CA5936の二つのセッションは、コマンドが1個なのに意図が5種、ダウンロードが2件です。コマンド一行がどうやって五段階に分類されたのか、データが説明しません。8/19にも同じ形がありましたが、コマンド原文がないため確認できません。
- その二つのセッションはコマンド数・意図・ダウンロード数・指紋がすべて同じです。同じツールが二度動いたように見えますが、同じ人物・同じ組織だという根拠はありません。
- 参考指標にDiscordのWebhookアドレスが一件載っているのですが、この日の観測分なのか累積分なのか日付がありません。 この日の検体のどこにも結び付かないため、本文の事実として使いませんでした。8/27の記録にも同じ問題が書かれています。
- 同じ理由で、解凍して初めて得られた12件(
31[.]77[.]227[.]121/bins/以下)も日付の表記がなく、この日のセンサー01にはELFが0件なので、この日の観測とは結び付けませんでした。 - TTY録画の件数は2,836ですが、実際に保管されたものは200件です。14倍の差が保管ポリシーによるものなのか、集計基準の違いなのか分かりません。
- センサー01の固有IP 202箇所のうち、クライアント指紋11種がカバーするのは35箇所だけです。残り167箇所の分布は分からず、この日のセッションの63%を占めるTelnetには指紋自体が存在しません。クラスタの総数は45なのに、データには11種しか載っていません。
- 完結性上位5件のうちTelnet 2件は、指紋とクライアントが空文字列です。値がないのではなく、プロトコルにその概念がないのです。「指紋が消された」と読んではいけません。
- 二台のサーバーを合わせた固有発信元450箇所は、共通部分が分からないために出てきた上限です。二台のサーバーの両方に触れた場所が何箇所あるのかは分かりません。
そして以下は、そもそも確認する手段がないものです。推定しません。
- ASN・ISP — 関連するデータベースがありません。配布元
185[.]93[.]89[.]72・5[.]182[.]210[.]174がどの事業者にあるのか、センサー02の上位9箇所が同じネットワークなのか言えません。 - 地理情報 — 同様にありません。そしてIPの地理情報は、そもそも帰属の根拠になりません。いかなる国・企業・個人も、この日の攻撃者として名指ししません。
- VPN・Tor・クラウドかどうか — 判別する手段がありません。発信元202箇所・248箇所のうち、どれが経由地でどれが原点なのか区別できません。
- VirusTotal — 連携されていません。昨日確保された検体12件(01の8種 + 02の4種)に、外部の多エンジン判定を付けることはできません。特に02の4件はファイル種別すらデータにありません。
- User-Agent — 二つの観測面ともHTTPではありません。01はSSH・Telnet、02はSMB・RDP・VNC・MSSQL・LDAP・ADBです。
- CVEとの結び付け — 昨日、二台のサーバーのどこにも特定の脆弱性を参照した痕跡がありません。背景統計として持っているCVEの数値は、昨日観測されたどのセッション・検体とも結び付きません。
推定 まとめると、昨日はこうです。二日間空だった欄に、箱四つが一度に入ってきました。合わせて773,937バイト、隣のサーバーの一日分八つを全部合わせたものの約278倍です。送り元はすべて同じ一箇所なのに、その一箇所はインターホンをたくさん押した名簿に名前がありませんでした。
そして箱には送り状がありませんでした。私たちが書き留められるのは封印シール四つ、sha256四行だけです。ブロックリストも通報書も**「どこから来たのか」を知らないと使えないものなのに、昨日入ってきたものにはその欄がそもそもありませんでした。**
だから今日やるべきことは、ドアの前を守る側ではなくドアそのものを減らす側にあります。使っていない機器の電源を抜き、使っていないポートを閉じることです。送り状のない箱は、届いてから対処する方法があまりありません。
観測日は2026年8月28日(UTC)の一日です。発信元IPはブリーフのマスキング形式(187.52.x.x)をそのまま移し、復元していません。配布アドレスは接続されないよう変形して書いています(hxxp://、[.])。認証情報は互いに異なるIP3箇所以上で観測された組み合わせ20種のみを引用し、単一の出所からしか出ていない組み合わせ862種は個数だけを明かし、値は載せていません。ASN・国籍・行為者の帰属は確認手段がないため推定しません。
