ケーブル6本、ポーチは1か月前のままだった

友達の家に遊びに行ったら、携帯のバッテリーが5%しか残っていないとしましょう。充電器を借りなければなりません。ところが友達の携帯の充電端子は自分のものと同じでしょうか。Type-Cかもしれないし、8ピンかもしれないし、古い5ピンかもしれません。

そこである人たちは、カバンにケーブルポーチを入れて持ち歩きます。小さな袋ひとつに、端子の形が違うケーブルを種類別に入れておきます。相手の機械が何なのか分からなくてもかまいません。ひとつずつ挿してみれば、どれかは合うのですから。

昨日、私たちのサーバーに誰かがこのポーチを持ってやって来ました。中には6本入っていました。ところがこのポーチは、1か月前に一度見たポーチでした。袋はそのときとまったく同じだったのに、ケーブルは6本すべてが新品でした。

今日はこのポーチの話をします。

まず、私たちのサーバーはわざと開けておいた家です

事実 私たちはハニーポットを運営しています。ハニーポットはわざと隙だらけに開けておき、誰が入ってきて何をするのかを見守るおとりサーバーです。ですから以下の話は本物の被害ではなく観察記録です。サーバーは2台です。1台目（センサー01）は扉が実際に開くサーバーです。2台目（センサー02）は誰が扉を叩いたかだけを記録する浅いサーバーです。

事実 昨日の主役は ATK-DD0862 です。送信元IPは 87.58.x.x と伏せて記します。別名は私たちの記録に初めて出てきた名前です。この訪問者はTelnetで入ってきました。Telnetは遠くにある機械に文字で命令を送る古い遠隔接続方式です。やり取りされる内容は暗号化されません。今日では主にルーターやカメラのような小さな機器に残っています。ポートは2223番で、ログインに成功しました。

19.30秒、ポーチを開けるのにかかった時間

事実 ログインしてから出ていくまで19.30秒かかりました。その間にコマンドを11個打ちました。1.75秒にコマンド1つの割合です。人が手で打つのは難しい速度です。その間にファイルを8個ダウンロードしました。2.4秒に1つずつです。私たちの分類器はこのセッションの行動に3つの名前を付けました。ファイルダウンロード → 実行権限付与 → ダウンロード後実行の順です。

事実 8個のうち先頭は kla.sh というシェルスクリプトです。シェルスクリプトはコマンドを何行かひとつのファイルにまとめておいたものです。実行すると書かれたコマンドが順番に動きます。サイズは3,013バイトです。英語に換算するとA4一枚ほどの文字数です。

推定 この種の攻撃では、先頭のスクリプトはたいていポーチの役割をします。後に続く実行ファイルを取り揃えてきて、順番に挿してみさせる袋です。ただし kla.sh の中に何が書かれていたのかは私たちの材料にありません。これは似た構造に照らした解釈です。

事実 残りのうち6個が実行ファイル、つまりケーブルです。Linuxで使われるELFという形式のプログラムです。6個をすべて合わせると1,092,512バイト、1メガバイトほどです。スマートフォンの写真1枚より小さいです。

なぜ一度に6本なのか

事実 コンピューターの頭脳であるCPUには種類がいくつもあります。充電端子の形が違うように、CPUの種類が違えばプログラムもそれに合わせて別々に作らなければ動きません。昨日降ってきた6個はCPUの種類がそれぞれ違いました。表の真ん中の欄を見てください。

事実 x86、MIPS、ARM。3系統をまとめて取り揃えました。MIPSは2種類です。エンディアンとは、CPUが数字を前から読むか後ろから読むかの違いです。同じMIPSでも向きが違えば別のケーブルが必要です。

事実 右の欄の静的リンクは、必要な部品をファイルの中に全部入れておいた状態です。ケーブル1本で済み、変換アダプターが要りません。6個のうち5個がこれです。parm5 ひとつだけが動的リンクです。対象機器に /lib/ld-uClibc.so.0 という部品があらかじめないと動きません。アダプターを噛ませないと挿さらないケーブルというわけです。6個とも内部の説明メモを削除した状態（stripped）でもあります。

推定 訪問者は私たちのサーバーがどのCPUなのか知らなかったでしょう。だから6本すべてを持ってきたのだと思われます。そしてこの構成は、一般的なサーバーよりもルーターやCCTVのような小さな機器に合う側です。そういう機器をボットネットに引き込もうとする構成と合致します。ボットネットとは、持ち主の知らないうちに遠隔操作される機械の群れです。静的リンクの5個は、CPUさえ合えばどのLinuxでも動きます。

ポーチはそのまま、ケーブルだけ新品

事実 ここからが今日の核心です。これらのファイルはすべて hxxp://176[.]65[.]139[.]196/bins/ から受け取ってきました。このアドレスは私たちの記録に8月21日にちょうど一度だけ出てきた場所です。その日の記事のタイトルが「初めて見るアドレスからファイル3つ」でした。アーカイブ基準で32日ぶりに再び現れました。

事実 ファイルごとにハッシュという値があります。ファイルの内容全体から計算した固有の番号です。一字違うだけでまったく別の値になります。ケーブルごとに刻まれたシリアル番号だと考えればよいです。1か月前と昨日のシリアル番号を並べてみました。いちばん右の欄を見てください。

事実 ポーチ kla.sh は32日間1ビットも変わりませんでした。逆にケーブル6本のシリアル番号はすべて初めて見る値です。アーカイブ29日分（8/16〜9/20）をすべて探してもありません。名前が同じ px86 もサイズが0.1%ほど変わり、シリアル番号は完全に変わりました。8月21日に2本だったポーチが、昨日は6本になりました。

推定 同じ場所でポーチは置いたまま、ケーブルだけ新しく作ってアップロードしている様子です。私たちの記録でこうした姿が出たのはこれが3回目です。8月24日（31[.]77 系）と9月20日（160[.]119[.]66[.]206 の net.x86_64）にもありました。

推定 これがなぜ重要なのでしょうか。8月21日のシリアル番号リストで戸締まりをしたとしましょう。昨日入ってきたケーブル6本はひとつも引っかかりません。ポーチひとつだけが引っかかります。逆に**「この店から来た品物は受け取らない」**というルールだったらどうでしょうか。アドレスが記録されている7個がすべて引っかかります。シリアル番号は1か月あればすべて変わります。ポーチを受け取ってくる店のアドレスはそのままでした。

名札はすでに知っていた

事実 面白い点がもうひとつあります。私たちは以前、UPXで圧縮されたマルウェアを解いてみたことがあります。UPXは実行ファイルをぐるぐる包んでかさを減らすツールです。包んだ状態では外側にアドレスがひとつも見えません。ビニールを破らないと、中に入ったケーブルの規格名札が見えない箱と同じです。そうやって破って初めて得られた名前が12個あります。すべて 31[.]77[.]227[.]121/bins/ 配下のファイルです。

parm · parm5 · parm6 · parm64 · parm7 · pm68k · pmips · pmpsl · pppc · psh4 · pspc · x86_64

事実 昨日の6本のうち5本の名前が、このリストと文字まで同じです。parm · parm5 · parm6 · pmips · pmpsl です。重ならないのは px86 ひとつです。リストには x86_64 があります。8月21日に重なる名前は pmips ひとつだけでした。

推定 外側だけを見て集めた記録だったなら、昨日の6個は「初めて見るファイル6個」としてしか残らなかったでしょう。箱を破って名札の規則をあらかじめ知っておいたから、見分けることができました。店のアドレスが違うのに同じ系統の名前の付け方だということが一目で分かりました。

事実 線を2本引いておきます。第一に、昨日のアドレス7個はセッションでそのまま見えていました。箱を破って得たものではありません。破ってみた経験が与えてくれたのはアドレスではなく名札の規則です。第二に、名前の規則が同じだということは、同じ系統の公開された作成ツールを使ったという意味でしかありません。 同じ人物や同じ組織だという意味ではありません。同じブランドのケーブルを使うからといって同じ人ではないのですから。

時間順に並べると

昨日1台目のサーバーで起きたことを時間順に並べるとこうなります。17:02の2行とその下の検体の行に注目してください。ポーチひとつを開けるのに20秒かかりませんでした。

1. 09:10:42 ~ 09:12:14 KST (00:10:42Z)
   事実 ATK-040C4F(222.86.x.x) Telnetログイン成功。91.94秒 · コマンド31個 · 意図3個（ダウンロード後実行 · 実行権限付与 · ファイルダウンロード）。ダウンロード0件 · 記録の緻密さ13。保存されたファイルがないので今日の主題ではない
2. 15:51:17 ~ 15:51:27 KST (06:51:17Z)
   事実 ATK-DD41EC(116.92.x.x) Telnetログイン成功。9.58秒 · コマンド28個 · ダウンロード11件、11件すべて1バイトの空ファイル(01ba4719…)。意図は「防御無力化」ひとつで、記録の緻密さ42と今日の最高。1日全体の「防御無力化」の集計が1回なので、その1回がこのセッションと見られる（個数が合うことに基づく推定）。9/20にも同じ別名が9.17秒 · コマンド28個だった
3. 17:02:10.87 KST (08:02:10Z)
   事実 今日の主題のセッション開始。ATK-DD0862(87.58.x.x) Telnet（ポート2223）ログイン成功。アーカイブになかった別名。Telnetなので接続プログラムの識別子が空文字列である
4. 17:02:10 ~ 17:02:30 KST (08:02:30Z 終了)
   事実 19.30秒の間にコマンド11個 · ダウンロード8件。意図3個（ファイルダウンロード · 実行権限付与 · ダウンロード後実行）。記録の緻密さ37。画面録画あり（内容は材料にない）。この別名だけが配送したファイルの個数の合計が8なのでダウンロード数と合う
5. (ATK-DD0862 検体 — ローダー)
   事実 hxxp://176[.]65[.]139[.]196/bins/kla.sh · 3,013バイトのBourne-Againシェルスクリプト · bb36568c…。8/21のブリーフに同じURL · 同じサイズ · 同じハッシュがある。8/21から9/22までの32日間変わらなかった
6. (ATK-DD0862 検体 — 実行ファイル6種)
   事実 すべて176[.]65[.]139[.]196/bins/ から受け取った。px86 133,292B ELF32 LSB Intel 80386 静的 · pmips 244,740B ELF32 MSB MIPS-I 静的 · pmpsl 248,836B ELF32 LSB MIPS-I 静的 · parm 182,976B ELF32 LSB ARM 静的 · parm5 83,344B ELF32 LSB ARM 動的(/lib/ld-uClibc.so.0) · parm6 199,324B ELF32 LSB ARM EABI4 静的。6個ともstripped、合計1,092,512バイト
7. (ATK-DD0862 検体 — 8/21 との対照)
   事実 8/21の同じURLのpx86は133,452B(979bd80a…)、pmipsは244,420B(ed6bae21…)。今日のpx86は160バイト小さくなり、pmipsは320バイト大きくなっており、ハッシュは両方とも異なる。8/21に2種類だったアーキテクチャが今日は6種。pmpsl · parm · parm5 · parm6 はこのホストで今日初めて見るファイル名
8. (ATK-DD0862 検体 — その他)
   事実 9バイトのASCIIテキスト1件(0dc95fb4…、URL未記録)。9/17にはATK-A593DF、9/20にはATK-CE432Eが残したものと同じハッシュ。今日はATK-DD0862が残した
9. (推論 — ローダーはそのまま、中身だけ交換)
   推定 同じパスにローダーは置いたまま実行ファイルだけ新しくビルドしてアップロードするパターンは、8/24(31[.]77 系) · 9/20(160[.]119[.]66[.]206 net.x86_64)に続いて3回目。8/21のハッシュで作ったブロックリストは、今日の実行ファイル6個のどれも捕まえられず、kla.shひとつだけを捕まえる。URL · ホスト基準のルールはアドレスが記録されたファイルをすべて捕まえる
10. (推論 — 9/17 の .206 との関係)
    推定 9/17には同じ/24帯域の.206がkworkerd-* という名前体系でファイルを送り出した。今日の.196は8/21の「bins/p+アーキテクチャ」体系で戻ってきた。2つのホストが交互に使われているのか、同時に運用されているのか、関係がないのかは分からない。アーカイブに抜けている日があるので「32日間休んでいた」とも言えない
11. 18:56:18 ~ 18:56:25 KST (09:56:18Z)
    事実 ATK-BDB53E(160.119.x.x) Telnetセッション A: 7.01秒 · コマンド7個 · ダウンロード2件。2.38秒後に開始したセッション B: 4.67秒 · コマンド2個 · ダウンロード2件、Aが終わった0.04秒後に終了。検体 kla.sh(39be6853…, 3,241B) · net.x86_64(2cebccdc…, 192,328B)は両方とも9/20と同じハッシュ。9/15 · 9/17 · 9/20に続いて4回目
12. (1日の集計 · 01)
    事実 セッション829 · ユニーク送信元207 · ログイン試行542 · コマンド790 · 画面録画302。SSH 560（ポート2222） · Telnet 269（ポート2223）。Telnetはセッションの32.4%なのに主要セッション5件はすべてTelnet。意図分類の合計491でコマンド790個と299の差
13. (1日の集計 · 01 — 9/20 との比較)
    事実 389バイトの公開鍵(a8460f44…)を残した送信元41 → 24か所。345gs5662d34の組み合わせ40 → 23か所。libssh_0.9.6識別子(f555226d…) 41 → 24か所。SSH鍵の植え付け意図43 → 24回。9/20に揃って跳ね上がった4つの値が揃って下がった
14. (1日の集計 · 02)
    事実 セッション45,461 · ユニーク送信元461。VNC 33,287(73.2%、送信元214) · RDP 11,698（送信元119） · SMB 250 · MSSQL 61 · LDAP 35 · ADB 130。低インタラクションセンサーなのでログイン成功 · コマンド · 資格情報は存在しない
15. (1日の集計 · 02 — RDP クッキー)
    事実 'Administr' 5,159回 · 'Admin' 5,151回、合わせてRDP接触の88.1%。'Administr' はアーカイブ最大(9/20、94回)の約54.9倍、'Admin' は9/20の66回の約78.1倍。9/10〜9/20に繰り返されていた 'mstsc' は今日のリストにない

事実 記録がもっとも緻密な5つのセッションはすべてTelnetでした。Telnetは昨日のセッションの3分の1（32.4%）にすぎません。ところがファイルを受け取っていった側は全部Telnetでした。ほかのセッションを主題に選ばなかった理由も書いておきます。ATK-DD41EC は記録の緻密さが1位（42）です。しかし1バイトの空ファイル11個を受け取る様子が8月18日から9回繰り返された系統です。ATK-BDB53E は4回目の訪問で、ファイルも9月20日と同じです。ATK-040C4F はコマンドが31個あるのに保存されたファイルがありません。

昨日出てきた値 — 書き取っておくもの

防御に使えるよう、値をそのまま写します。値を押すとコピーされます。 アドレスは誤って接続されないよう変形（デファング）してあります。http の代わりに hxxp、ドットの代わりに [.] を使った形です。そのまま使ってください。2行目から7行目までが昨日初めて見たシリアル番号です。

事実 15行をもう一度見てください。ハッシュの行は8個で、そのうち6個が新品です。アドレスの行7個は、前半部分の hxxp://176[.]65[.]139[.]196/bins/ が全部同じです。シリアル番号は毎回新しく覚え直さなければなりません。店のアドレスは1行で済みます。

このパスワードをお使いですか

事実 昨日の1台目のサーバーへのログイン試行は542回でした。1日で割ると2分40秒に1回の割合で誰かがドアノブを回してみた計算になります。送信元は207か所でした。1か所あたり2.6回の割合です。

事実 試されたID・パスワードの組み合わせのうち、この記事に写すのは13種だけです。異なるIP3か所以上で繰り返された組み合わせだけを原文で記すのが私たちのルールです。この基準に満たない366種は個数だけを数え、値は記しません。 1か所からしか出てこなかった組み合わせは、どこかから漏れ出た誰かの本物のアカウントかもしれないからです。以下の13種は逆に、複数の場所が同じように入れてみた、誰のものでもないありふれた値です。1行目と4行目を見てください。

事実 1行目の奇妙な文字列は、9月20日には40か所だったのが昨日は23か所に減りました。パスワード欄がまるごと空の root は6か所が22回入れてみました。1か所あたり3.7回ずつです。表の中で1か所あたりの繰り返しがもっとも多いです。

昨日1日の全体

事実 扉が実際に開く1台目のサーバーの1日の集計です。右の欄も併せて見てください。 数字ひとつだけでは大きさがつかみにくいです。

事実 サーバー内で打たれたコマンドを種類別に分けるとこうなります。

事実 7行を足すと491です。コマンド790個と299個の差が出ます。その299個が何なのかは材料に説明がありません。「SSH鍵の植え付け」とは、サーバーにパスワードなしで再び入れる鍵をこっそり登録しておくことです。9月20日に43回と跳ね上がったあと、昨日は24回に下がりました。その鍵ファイル（389バイトの公開鍵 a8460f44…）を残した送信元も41か所から24か所に減りました。2日前に揃って跳ね上がった4つの数字が揃って下がりました。

事実 2台目のサーバー（センサー02）は扉を開けず、誰が叩いたかだけを記録します。ですからログイン成功も、コマンドも、資格情報もここにはありません。昨日は45,461件が461か所から来ました。1.9秒に1回です。画面共有（VNC）が33,287件で73.2%です。リモートデスクトップ（RDP）は11,698件です。

事実 リモートデスクトップで接続するとき、相手は自ら名札（クッキー）を書いて送ってきます。昨日は Administr が5,159回、Admin が5,151回でした。2つを合わせるとRDPの88.1%です。Administr は私たちの記録でもっとも多かった9月20日（94回）の約54.9倍です。Admin は9月20日の66回の約78.1倍です。9月10日から20日まで一貫して見られていた mstsc は昨日のリストから消えました。名札は相手が好きなように書く値なので、そのまま信じることはできません。

攻撃者が使った手口を国際分類表に対応させると

MITRE ATT&CK は攻撃手口ごとに番号を付けておいた国際的なリストです。昨日見た行動をその番号に合わせるとこうなります。IDを押すと原文の説明に飛びます。 私たちの言葉をそのまま信じず、ご自身で確認していただくためにリンクを張ります。

• T1110.001Brute Force: Password Guessing — ログイン試行542回、引用可能な組み合わせ13種推定
• T1078.001Valid Accounts: Default Accounts — 主題セッションのログイン成功、引用可能な組み合わせがデフォルト値の系統推定
• T1059.004Command and Scripting Interpreter: Unix Shell — Telnetシェルでコマンド11個、シェルスクリプト kla.sh推定
• T1105Ingress Tool Transfer — 「ファイルダウンロード」の意図、検体8件推定
• T1222.002File and Directory Permissions Modification: Linux and Mac — 「実行権限付与」の意図推定
• T1027.002Obfuscated Files or Information: Software Packing — 以前に解いてみたUPX検体に基づく。今日のELF6種は圧縮の有無が記録にないので、今日のファイルが圧縮されているとは言えない推定
• T1098.004Account Manipulation: SSH Authorized Keys — 1日全体の集計（SSH鍵の植え付け24回、公開鍵24か所）。主題セッションとは関係ない推定
• T1070Indicator Removal — 1日全体の集計で痕跡削除25回。主題セッションとは関係ない推定
• T1562Impair Defenses — 1日全体で1回（ATK-DD41EC と見られる）。コマンドの原文がないので下位技法は付けない推定

事実 9行すべてが**[推定]です。私たちの手元にあるのはコマンドの「意図分類の結果」と回数、ファイルの名前・サイズ・種類までです。コマンドの原文もファイルの内容もありません。分類表に合わせるのは常に解釈です。そして下の3行（T1098.004 · T1070 · T1562）は昨日のポーチとは関係のない**1日全体の話です。

以前にこういう形があった

推定 Mirai ボットネットとその派生系統（2016〜）。 Telnetのデフォルト資格情報で入ったあと、/bins/ のようなウェブパスからCPU種別ごとの実行ファイルを何種類も受け取る構造です。そのうち合うものが実行されるようにします。昨日1つのセッションがx86・MIPS（2方向）・ARMをまとめて受け取った様子と合います。ただしソースコードが2016年に公開されたので、互いに関係のない運用者も同じ名前の規則を使います。(出典の類型: 米国司法省の起訴・有罪答弁記録、複数のセキュリティ企業による公開分析レポート)

Gafgyt(Bashlite) 系統（2014〜）。 シェルスクリプト1つがCPU種別ごとの静的実行ファイルを順番に受け取って実行する構造です。「ポーチ1つ + ケーブル数本」が同じパスから1セッションで降ってきた昨日の様子と見た目が同じです。(出典の類型: 複数のセキュリティ企業による公開分析レポート)

事実 ここで止めます。検体分類サービス（VirusTotal）が連携されていません。昨日のファイルにはMalwareBazaarのタグもありません。ですから昨日のファイルがMirai系統だという判定はしません。 似ているのは構造と名前の付け方までです。

では何をすべきか

ポーチを持ってくる側を私たちは止められません。変えられるのは私たちの機械に挿す穴が開いているか、ケーブルを受け取ってくる道が開いているかです。

事実 1. デフォルトアカウント・簡単なパスワードをそのまま使っている · 可能性が高い 昨日記録された主要セッション5件はすべてログインに成功しました。上の表の admin/admin は13か所が26回、空のパスワードの root は6か所が22回入れてみました。昨日観測された侵入経路はすべて資格情報でした。主題セッションはログイン後19.30秒で実行ファイル6個を手に入れました。

事実 2. 管理ポート、特にTelnetをインターネットに直接開けている · 可能性が高い Telnetはセッションの32.4%ですが、ファイルを受け取っていったセッションは5件すべてTelnetでした。SSH側でファイルを置いていった接続プログラムの識別子は 16443846…（3か所）ひとつだけでした。自宅のルーターやカメラの設定画面でTelnetがオンになっていないか確認してみてください。

推定 昨日降ってきたARM・MIPSの実行ファイルは、Telnetが開いたルーターやCCTVのような機器を狙った構成です。破られれば機器ひとつが丸ごと乗っ取られます。

事実 3. 外へ出ていく接続を止めていない · 可能性が高い 昨日は「ファイルダウンロード」の意図が39回、「ダウンロード後実行」が37回でした。176[.]65[.]139[.]196/bins/ から7件、160[.]119[.]66[.]206/bins/ から2件を受け取っていきました。6本のうち5本が静的リンクなので、CPUさえ合えばどのLinuxでも動きます。サーバーが外へ出ていく道が塞がれていたらどうなっていたでしょうか。昨日のセッションはケーブルを受け取ってくる段階で終わっていたはずです。 これがこの記事の比喩で言えば「店から来る品物を受け取らない」です。シリアル番号が何回変わろうと関係ありません。

推定 4. 接続頻度の制限（fail2ban など）がない · 可能性は中程度 1か所あたりのログイン試行が2.6回の割合です。admin/admin は1か所あたり2回です。「5回間違えたらロック」のようなルールにはほとんど引っかからなかったでしょう。少ない回数で広く叩く方式なので、頻度制限だけでは防ぎにくいです。デフォルトアカウントをなくすことと併せて使ってこそ効果があります。だから「高い」を付けませんでした。

事実 5. パスワードログインを許可していて鍵方式を使っていない · 可能性は低い 昨日ファイルを受け取っていったセッションはすべてTelnetです。Telnetには鍵方式という選択肢がありません。SSHのログイン試行が何回だったかは別に分けられていません。ですから鍵方式で昨日の侵入を防げたと言える根拠がありません。Telnetは切ること以外に答えがありません。

推定 6. ログを集めていない、または異常行動の監視がない · 可能性は中程度 1日全体では痕跡削除25回、防御無力化1回がありました。主題セッションにはどちらもありませんでした。私たちは画面録画が302件あったので、19秒のセッションの流れを組み直すことができました。記録がなかったら、1か月前の店が再び開いたという事実そのものを知らなかったでしょう。

事実 昨日観測した配布元 176[.]65[.]139[.]196 と 160[.]119[.]66[.]206 は、C-TAS（韓国インターネット振興院のサイバー脅威情報共有体系）への申告対象です。ただし私たちが確認できるのは送信が成功したというところまでです。KISA側に実際に登録されたかどうかは別途確認しなければなりません。

私たちが分からないこと

このブログがほかと違う点です。知っていることと同じくらい、分からないことも書きます。

ポーチと店について

• [確認不可] アーカイブに 9/9 · 9/11 · 9/12 · 9/14 · 9/16 · 9/18 · 9/19 · 9/21 のブリーフがありません。「176[.]65[.]139[.]196 が32日ぶりに現れた」というのはアーカイブ29日分を基準にした話です。その間にこの店が休んでいたかどうかは分かりません。
• [確認不可] 176[.]65[.]139[.]196（8/21 · 昨日）、.202（8/23〜25）、.206（9/17）が同じ運用者なのか分かりません。 確認できるのは同じ/24帯域（前の3つの数字が同じアドレス256個のまとまり）だということと、.196 の名前の規則が圧縮を解いて得たリスト（31[.]77[.]227[.]121）と重なるということだけです。公開されたソース系統なので、互いに関係のない運用者も同じ規則を使います。
• [確認不可] px86 · pmips は8/21とアドレス・名前・種類が同じで、サイズだけ −160 / +320バイト違いました。同じプログラムを作り直したのか、別のプログラムに同じ名前を付けたのか、検体の内容がないので判断できません。
• [確認不可] parm5 だけがアダプターの必要な動的リンク（uClibc）である理由が分かりません。 実行するには対象機器に /lib/ld-uClibc.so.0 がなければならない、というところまでしかファイルの種類から読み取れません。
• [確認不可] 6本のうちどれが実際に実行されたのか（あるいは実行を試みたのか）、記録が区別していません。「ダウンロード後実行」の意図はありますが、コマンドの原文と画面録画の内容がありません。
• [確認不可] ATK-DD0862 とファイル8件を結びつける根拠は、配送者の欄と個数の合計（8 = ダウンロード数）が合うということです。セッションとファイルを1:1で結ぶ欄はありません。
• [注意] ブリーフは「アドレス基準のルールなら8個すべてを捕まえる」と書いていました。ところが8件のうち9バイトのテキストはアドレスが記録されていません。 ですからこの記事は「アドレスが記録された7個」と狭めて書きました。
• [確認不可] 9バイトのテキスト（0dc95fb4…）が 9/17 · 9/20 · 昨日、それぞれ別の別名から出てきました。内容がないので何なのか、なぜ同じファイルが複数の送信元から出てくるのか分かりません。

ほかのセッションと集計について

• [確認不可] 2台目のサーバーの上位送信元に 176.65.x.x（ATK-D4B7A8、89件）があります。伏せられたアドレスなので、配布元 176[.]65[.]139[.]196 と同じ機械なのかは分かりません。復元しません。 別名が2台のサーバー間で同じ送信元を指すという保証も文書化されていません。
• [確認不可] ATK-DD41EC が 9/20 と昨日、同じ別名で出てきました。別名を作る方式が文書化されていないので、日付の異なる2つの記録を同じ送信元として結びつける根拠には使いませんでした。
• [確認不可] ATK-040C4F は「ファイルダウンロード」の意図があるのにダウンロード数が0です。受け取ろうとして失敗したのか、受け取ったのに保存されなかったのか区別できません。
• [確認不可] 記録の緻密さ（completeness）の計算式が材料にありません。 意図1個の ATK-DD41EC（42）が、意図3個の ATK-DD0862（37）より高い理由を説明できません。
• [確認不可] コマンド790個と意図分類の合計491の差299個が何なのか、材料が説明していません。
• [確認不可] RDPの名札 Administr · Admin が 9/20 比で数十倍に増えた原因が分かりません。 送信元とサービスを結ぶ欄がないので、1〜2か所が作った数字なのかも確認できません。
• [確認不可] 2台目のサーバーの adb の詳細記録が昨日の材料にありません。ADB（Androidデバッグ接続）の130セッションに何が入ってきたのか、何か所から来たのか分かりません。2台目のサーバーのファイル4件（すべて 8/28 · 8/30 · 9/3 · 9/20 にすでに見たハッシュ）がADBで入ってきたのかも確認できません。
• [確認不可] 接続プログラムの識別子11個が、全47個のまとまりの一部なのか、昨日見たすべてなのか明示されていません。主題セッションはTelnetなので識別子そのものがなく、まとまりの分析を適用しませんでした。 識別子はプログラムの識別子であって人の識別子ではありません。

わざと外したもの、結びつけなかったもの

• [除外] ログイン欄にHTTP・SIPのリクエストが誤って入ってきたと見られる3種は、パスワードではなくノイズと見て引用リストから外しました。そのうちひとつのパスワード欄に入っていたホスト文字列は記しません。
• [除外] 平文の指標として残ったDiscord Webhook 1件は、どのセッション・ファイルと結びつくのか材料にないので、事実関係から外しました。
• [除外] 背景統計（KISAセキュリティ告知のCVE 7,640件 · CISA KEV 404件 · ランサムウェア連携確認100件、EPSS上位 CVE-2018-13379 · CVE-2022-26134 · CVE-2021-44228 · CVE-2023-4966 · CVE-2024-3400）は昨日の観測と直接結びつきません。 昨日の侵入経路はすべて資格情報でした。
• [確認不可] C-TAS への申告は送信成功までしか確認できません。KISA側での取り込み・活用の有無は別途確認しなければなりません。

そもそも判断しないもの

• 通信事業者・組織（ASN・ISP） — 関連データベースがありません。推定しません。 配布元 176[.]65[.]139[.]196 のホスティング業者も分かりません。
• 地理的位置 — 同じ理由で分かりません。IPの地理情報は、そもそも誰がやったのかを示す根拠にはなりません。この記事はいかなる国家・企業・個人も攻撃者として名指ししません。
• VPN・Tor・クラウドかどうか — 判別する手段がありません。
• 検体分類（VirusTotal） — 連携されていません。昨日の新しい実行ファイル6個がどの系統として検出されるのか、この記事では言えません。
• 接続プログラム文字列（User-Agent） — 2台のサーバーとも ウェブ（HTTP）ではありません。1台目はSSH・Telnet、2台目はSMB・RDP・VNC・MSSQL・LDAP・ADBです。ウェブ攻撃は別のソースで扱います。
• 脆弱性番号（CVE）との結びつけ — SSH・Telnet攻撃はほとんどの場合、特定の脆弱性を参照しません。2台目のサーバーも規格を合わせる段階なので同様です。

1か月前に見たポーチが昨日また来ました。袋は1ビットも変わっていませんでした。中に入ったケーブルは2本から6本に増え、シリアル番号はすべて新品でした。1か月前のシリアル番号のリストでは、6本のうちひとつも捕まえられません。代わりにポーチが来る店のアドレスはそのままでした。ケーブルに付いた名札も、私たちが以前に箱を破って見ておいたあの名前でした。

何が変わったのか、誰が持ってきたのかは分かりません。分からないことは分からないままにしておきます。それでもできることははっきりしています。挿す穴（Telnet）を閉じ、ケーブルを受け取ってくる道（外へ出ていく接続）を塞ぎ、店のアドレスを長く覚えておくこと。 シリアル番号は1か月あれば変わりました。店のアドレスは32日経ってもそのままでした。

観測日は2026年9月22日で、この記事は翌日にまとめました。送信元IPはブリーフで伏せ処理された形（87.58.x.x、222.86.x.x、116.92.x.x、160.119.x.x、176.65.x.x）のまま写し、復元していません。配布元アドレスは誤って接続されないよう、デファング（hxxp://、[.]）の状態を本文とIOCブロックの両方で維持しました。資格情報は異なるIP3か所以上で繰り返し観測された組み合わせ13個だけを原文で引用し、残りの366個は個数のみを明かして値は記しませんでした。通信事業者・国籍・VPNの有無のように、私たちに計測手段のない項目は推定せず「分からない」として残しておきました。