その“USB–RJ45アダプタ”、ほんとにただのNIC？— 妄想8割・警鐘2割の「偽装MITMデバイス」入門（技術詳説ナシ）

その“USB–RJ45アダプタ”、ほんとにただのNIC？

— 妄想8割・警鐘2割の「偽装MITMデバイス」入門（技術詳説ナシ）

この記事は、

TL;DR

• 見た目はUSB–RJ45アダプタ（または中継コネクタ）。中身は“通信の真ん中に入る”偽装MITMデバイスという妄想。
• サイズ感は既製品＋1〜2割増でも成立“し得る”。見た目での発見は難しいが、完全検知不能ではない。
• 工作手順や攻撃方法は一切記載しません。ここではどう振る舞うように見えるか／どう備えるかだけ。
• マルウェア版の話は本記事から意図的に除外：同等のことを端末内でやる場合は検知可能性が大幅に上がるため、論点を分けます。
• 要するにこんなデバイス見つけられないだろうし、実現されたらアブナイ！という雑談からの発想を記事にしたもの

---

この organization の記事の趣旨

　本organizationの記事は、LINEオープンチャット「フリーランスエンジニア」（参加URL）に集うエンジニアたちの発言やライブトークをもとに構成しています。
　当コミュニティ「Freelance-Engineer.net」は、900人を超えるフリーランス・エンジニアが、技術・働き方・生き方について自由に語り合う場です。
　記事内の意見は、個々のメンバーの実体験から自然発生的に生まれた“生の知見”を整理したものです。

テーマに沿った各メンバーの発言から、にじみ出る思惑を引用し、まとめ記事としています。

---

この記事の趣旨

　フリーランスエンジニア間の、 こんなの作れるんじゃね？ 的な雑談から、じゃ机上検証してみようということになった集約情報を記事にしたものです。
　実証実験はしておらず、あくまで妄想の範囲から外れませんが、実現性の観点から確度の高い情報収集ができたのかなということで、記事にしました。

---

本記事の範囲と用語（重要）

• 本記事で言う偽装MITMデバイス＝見た目は普通のネットワーク小物（USB–RJ45や中継コネクタ）だが、内部で“中継と遠隔成り代わり” として 振る舞う可能性を扱う妄想概念 机上空論 です。
• マルウェアで同等のことをするシナリオは除外します。端末内ふるまい・永続化・外向き通信などでコンシューマでも検知シグナルが増えるため、本稿の「見た目で気づきにくい」という焦点から外れるためです。

---

妄想している偽装MITMデバイスって？

形はUSB–RJ45。中身は“L2レベルデバイスを装いつつ、遠隔PCにルーティングパケットをルーティングするMITMデバイス”。以下は想像の振る舞い（手順化しません）。

• モード0：潜伏（フツーのNIC動作）
  ふつうのUSB有線LANとして100%通常動作。違和感ゼロ。　機械的にも電気通信をまま通過させる。

• モード1：傍受ミラー（見えない分岐）
  PC⇄社内の通信を内部でコピーし、隠しLTE/隠しWi-Fiで外の“観測役PC”へ同時転送。
  表の通信は物理的・電気的に通過するためユーザー体感は変わらず盗聴が可能。
  ※暗号化されていれば内容は守られますが、時刻・量・宛先ヒントなどのメタ情報は観測され得ます。

• モード1.5：影武者の準備（合図待ち）
  通信の**“くせ/名札（識別ヒント）”を学習し、“同じ人のふり”ができそうに見える**準備だけして静かに待機。
  ※実装手順や突破方法は書きません。概念描写です。

  • MACアドレスを偽装するとか、TTLを偽装するなど、でき得る偽装のための情報収集
  • 基本的にデバイス内で行うというより、遠隔攻撃者側のアプリケーションで行う想定
  • モード 1.5 では、遠隔攻撃者側のアプリで構成した情報を、デバイス側のチップに書き込む想定

• モード2：影武者中継（遠隔ルーティングで“成り代わり”）
  合図で裏回線（LTE/Wi-Fi）⇄表回線（LAN）を橋渡しする**“回線代理”に切替え、
  遠隔の操作者が“あなたの席のPC”で通信しているように見せる。
  痕跡はゼロではない**（電波・ネットワーク層に小さな矛盾は残り得る）—ここが警鐘ポイント。

---

デバイスの物理サイズの話（USB–RJ45アダプタ型を主役に）

既製品の一例（実測）：60 × 27 × 16 mm（長×幅×高）

この“ありふれた箱”に無線系（Wi-Fi/LTE）や低消費の補助チップが乗っても、外観差を1〜2割に収める余地は“技術的には”あります（あくまで概念評価）。

• Wi-Fi内蔵
  → 65–70 × 28–30 × 17–20 mm（放熱・アンテナ都合で高さ+1〜4mmの想定）
• LTE内蔵（SIM/アンテナ）
  → 70–82 × 30–32 × 18–22 mm（RFシールド・アンテナ距離確保で長さ/高さやや増）

前提：バッテリ非搭載・USB給電。連続1.8–2.6W級の消費/発熱帯は想定範囲。すこしぬくい程度。
24h単独稼働のバッテリ内蔵は40–60Wh級が要り、このサイズ帯には収まらない＝常時USB給電が現実的。

（参考：中継コネクタ型は純正受動が40 × 23 × 17 mm。無線＋給電リード有りだと68–80 × 23–26 × 17–22 mmと明確に長くなるし、USB給電ケーブルがまずは怪しすぎるが、隠せればあり！）

---

想像しやすい危なさ

机の上の“ただの小物デバイス”。でも中では、LANとは別のもう1本の見えない通信が開いているかもしれません。
その道は隠しLTEや隠しWi-Fiで屋外へ伸び、遠くのPCと通信！？“”。
合図ひとつで、その誰かがあなたの回線“経由”で操作できる――そんな偽装MITMデバイスの妄想です。
※作り方や手口は一切扱いません。振る舞い像と備えにだけ触れます。

---

なぜ見た目で気づきにくい？

• 外装が既製品とほぼ同じ（差分1〜2割）
• 発熱は“ぬくい”程度（そもそも触られない）
• デスク裏のケーブル密集に埋もれる

結論：目視だけではまず無理。**他レイヤの“サイン”**を重ねて拾う体制が必要。

---

それでも露見する“小さなサイン”（4層で拾う）

1. 物理：
   よく見るネットワーク小物／資産ラベル無し
2. 電波：
   “PCでもAPでもない”小電波源が上り中心で喋り続ける（企業ならWIPSで検知）
3. ネットワーク：
   “新しい端末を検出”通知／DHCP予約違反／短時間の接続断の連鎖（Link flap群）
4. 運用：
   “急な再ログイン”や“謎のセッション切れ”などユーザー違和感／SaaSの新端末通知

単独のサインは弱い。**“複数層で小さな違和感が同時に出たら調査”**が現実解。

---

フラッシュQA

• 「触れば温かいでしょ？」 → 触らないでしょ？ “ぬくい”程度 では気にされにくい。
• 「ルータが全部知らせるでしょ？」 → コンシューマ機は通知OFFが初期。同一化パターンは見えにくい。
• 「httpsだから完全安心」 → 盗聴耐性は上がるが、運用・電波・物理のサインは別に拾う必要。そもそも「どこと通信してる」は筒抜け

---

今日からできる（無料〜ローコスト）対策

• ブラウザ：HTTPS-Only（常に安全な接続）をON
• 端末：DoH（DNS over HTTPS）をON／Windows Defenderのクラウド保護・改ざん防止・ASRを有効
• 現場ルール：“見知らぬUSB–RJ45や中継を見つけたら写真→ITへ”（触らない・抜かない）
• 小規模/在宅：ルータの**“新規端末通知”ON**／ファーム自動更新／DHCP予約＋違反通知（できる範囲で）

余力があれば：802.1X（EAP-TLS）を大事な島から段階導入、要所にWIPS、重要回線はMACsecで“中継の価値”自体を下げる。

SaaS側で実装推奨な対策

ねらい： SaaS（自社Webサービス）側で、"見た目で気づきにくい"偽装MITMデバイスのシナリオに対しても、成り代わりっぽさ・場所借りっぽさを“サービス側の文脈”から気づけるようにする。（ちょっとやり過ぎなくらいの議論）

1) 認証まわり（Passkey/WebAuthn を第一選択に）

• **Passkey（FIDO2/WebAuthn）**で“本人の端末・生体”にひも付く認証を標準化。パスワード単独を回避。
• 実装OSS：
• Node.js: @simplewebauthn/server + @simplewebauthn/browser
• Java: webauthn4j, Yubico/webauthn-server
• Python: python-fido2（Yubico）, duo-labs/py_webauthn
• Ruby: cedarcode/webauthn-ruby
• 設計Tips：RPID/Originを厳密化、User Verification=required、Discoverable Credentialを許可、リカバリはTOTP/メールリンクに限定

2) リスク/コンテキストベース制御（軽量でOK）

• 収集する文脈データ：IP/国/地域/ASN、UA/Client Hints、既知デバイス指紋、時刻帯、失敗回数。
• 新規端末/新規場所/不可能移動は**ステップアップ認証（MFA/Passkey再提示）**へ。
• OSS部品：
• Geo/ASN: MaxMind GeoLite2、ipinfo/ipdata API（無料枠あり）
• 指紋: FingerprintJS (OSS)（あくまで補助）、ブラウザ Client Hints
• UA解析: ua-parser-js, device-detector
• ポリシー: Open Policy Agent (OPA), Cerbos（「条件付きアクセス」をコード外へ）

3) セッション/トークン防御（“場所借り”対策）

• DPoP/Proof-of-Possession等でトークンを端末鍵にひも付け（盗んだだけでは使えない）。
• 実装OSS：
• Node.js: openid-client（DPoP対応）, panva/jose（JWS/JWT）, oauth4webapi
• Python: authlib（DPoP対応進展）, pyjwt
• Java: Nimbus JOSE + JWT（DPoPサンプル豊富）
• 併用：リフレッシュトークンのローテーション、短寿命アクセストークン、クッキーに Secure/HttpOnly/SameSite=Strict、重要操作前にセッションID再発行、バックチャネル・グローバルサインアウト。

4) 監査・異常検知（ログで“嘘のない”兆候を拾う）

• 蓄積/検索: OpenSearch/Elasticsearch
• 異常検知: OpenSearch Anomaly Detection
• SIEM: Wazuh（OSS）
• 集約: Fluent Bit/Vector
• 見るべきイベント：
  • 新端末/新場所/不可能移動
  • 深夜の大量DL/エクスポート
  • MFA失敗連発
  • OAuth同意の新規作成

5) ユーザー通知（一次検知者は“本人”）

• 通知必須：新しい端末/場所、全端末サインアウトが実行された、大量DL/転送ルール作成、高リスク国からのアクセス。
• 実装部品：メール（SES/SendGrid）、Slack/Teams Webhook、「これは私/違います」ワンクリックで即セッション無効化。

6) レート制限/自動化兆候ブロック

• OSS：
  • Node.js: rate-limiter-flexible, express-slow-down
  • Python: slowapi, limits
  • Ruby: rack-attack
  • Edge: Nginx/Trafik の rate-limit, bot detection（ヘッドレスUA/window.webdriver 兆候は補助的に）
  • 設計：ステップアップ（CAPTCHA/Passkey再提示）と組み合わせ。

7) ユーザー協力必須観点の機能

• データ最小化・保持期間の明示・利用目的の限定。ユーザーが最近のログイン履歴/端末一覧を見て自発的にセッション無効化できるUIを用意。

8) 最小セット（MVPチェックリスト）

• Passkey対応＋新端末/新場所通知
• セッションIDローテーション＋全端末サインアウトボタン
• ログ集中（OpenSearch等）＋大量DL/同意変更の検知
• Geo/ASNチェック＋不可能移動でステップアップ（本件では副次的対応）

---

まとめ

• 偽装MITMデバイスは見た目ほぼ既製品サイズで“それっぽい振る舞い”を技術的にし得る。
• 完全検知不能ではないが、目視だけでは難しい。
• HTTPS-Only／DoH／Defender強化／SaaS通知／写真報告ルール――低コストでも今日から上げられる防御は多い。
• マルウェア版の議論は本稿では扱わない（検知可能性が爆増し、焦点がズレるため）。

最後に：本記事は妄想8割・警鐘2割。工作手順や攻撃方法は一切記載しません。
不正利用は違法です。私たちがやるべきは、「あり得る」を前提に、備えること。
こんなネットワーク小物を見かけたら――誰かに相談！