サイバー攻撃は「攻撃名」ではなく「攻撃ライフサイクル」で見る――MFA回避・LOTL・ランサムウェア・DDoS・ゼロデイ・APTの検知と対策【2026年版】

サイバー攻撃を学ぶとき、フィッシング、ランサムウェア、ゼロデイ、DDoS、APTといった「攻撃名」を一つずつ覚えがちです。

しかし、実際のインシデントでは一つの攻撃手法だけが使われるとは限りません。

攻撃者は、

偵察 → 初期侵入 → 実行 → 永続化 → 権限昇格 → 認証情報窃取 → 内部探索 → 横展開 → 情報窃取・暗号化・破壊

という流れの中で、複数の手法を組み合わせます。

2026年のM-Trendsでは、Mandiantが2025年に対応した侵害のうち、脆弱性悪用が初期侵入経路の32%を占めました。一方、対話型の音声フィッシングは11%まで増加しています。また、長寿命OAuthトークンやSession Cookieなど、パスワードそのものではなく「認証済み状態」を狙う攻撃も重要になっています。

この記事では、MITRE ATT&CK、JPCERT/CC、CISA、IPAなどの公開情報を基に、現代的なサイバー攻撃を「攻撃ライフサイクル」として整理します。

結論・要点

この記事の要点

現代のサイバー攻撃は単一の攻撃名ではなく複数のTTPが連結した攻撃ライフサイクルとして検知する必要がある。
Session CookieやOAuth Tokenを盗まれるとパスワードを知らなくても認証済み権限を悪用される場合がある。
MFAを導入するだけではMFA fatigue、AiTM、Session Cookie窃取などへの対策として不十分である。
PowerShellやGitHubなどの正規機能・正規サービスは利用した事実だけでは攻撃と判定できない。
ランサムウェアは暗号化開始後ではなくAD探索、認証情報窃取、横展開、バックアップ妨害の段階から検知する必要がある。
DDoSは通信量だけでなくRPS、接続数、HTTP/2ストリーム、リセット率、CPU、upstream latencyまで監視する必要がある。
脆弱性対応はCVSSだけでなく実悪用、外部公開、認証要否、重要資産への到達可能性を含めて優先順位を決める必要がある。
正規サービスを攻撃インフラとして利用する攻撃ではIPアドレスやドメインだけのIoC検知では不足する。

IPAの「情報セキュリティ10大脅威 2026」でも、組織向けではランサム攻撃が1位、サプライチェーン攻撃が2位、AI関連リスクが3位、脆弱性悪用が4位となっています。DDoSとBECも引き続き上位10項目に含まれています。

この記事で分かること

この記事を読むと、次の内容を理解できます。

攻撃者が侵入後にどのような順序で動くのか
フィッシングからMFA回避へ発展する仕組み
Session CookieとOAuth Tokenが狙われる理由
Fileless攻撃とLiving off the Landの違い
ランサムウェアを暗号化前に検知する考え方
HTTP/2 Rapid Resetを含むDDoS監視
ゼロデイとN-day脆弱性の優先順位
APTによるGitHub・GitLabなど正規サービスの悪用
ログをどのように組み合わせて攻撃チェーンを検知するか
インシデント発生後の対処と再発防止

対象読者・前提環境

主な対象読者は次のとおりです。

サーバー・ネットワーク管理者
Webエンジニア
インフラエンジニア
SOC・CSIRT担当者
Microsoft 365・Entra ID・Google Workspaceなどの管理者
AWS・Azure・Google Cloudなどを管理する担当者
セキュリティを学び始めたエンジニア

特定製品だけを対象とした記事ではありません。

Windows、Linux、Active Directory、SaaS、Cloud、VPN、Firewall、Webサーバーなどを含む一般的な企業システムを想定しています。

用語と全体像

サイバー攻撃は「泥棒が建物の奥へ進む流れ」と考えると分かりやすい

攻撃ライフサイクルは、建物への侵入にたとえると理解しやすくなります。

建物を下見する
      ↓
入口を見つける
      ↓
建物へ入る
      ↓
鍵を盗む
      ↓
内部を調べる
      ↓
重要区画へ移動する
      ↓
金庫・機密資料へ到達する
      ↓
盗難・破壊

サイバー攻撃でも基本構造は同じです。

flowchart TD
    A["偵察<br>公開資産・社員・SaaS"] --> B["初期侵入"]

    B --> B1["フィッシング"]
    B --> B2["盗難認証情報"]
    B --> B3["VPN / Firewall / Web脆弱性"]
    B --> B4["Supply Chain"]

    B1 --> C["コード実行<br>またはSession取得"]
    B2 --> C
    B3 --> C
    B4 --> C

    C --> D["永続化"]
    D --> E["権限昇格"]
    E --> F["認証情報窃取"]
    F --> G["内部探索"]
    G --> H["横展開"]

    H --> I["目的達成"]

    I --> I1["情報窃取"]
    I --> I2["ランサムウェア"]
    I --> I3["破壊"]
    I --> I4["スパイ活動"]
    I --> I5["OT操作"]

    I --> J["痕跡削除<br>再侵入経路維持"]

MITRE ATT&CKは、このような攻撃者の戦術・技法を実際に観測されたTTPとして体系化しています。

重要なのは、一つのイベントではなく前後のイベントをつなげることです。

問題・仕組み・原因

1. フィッシングの次に「認証済み状態」が狙われる

従来の説明では、フィッシング攻撃は次のように理解されていました。

偽サイト
   ↓
ID / Password窃取
   ↓
不正ログイン

MFAが普及すると、攻撃者側も変化します。

Password窃取
   ↓
MFA
   ↓
攻撃失敗

そこで狙われるようになったのが、MFAそのものやMFA通過後に発行される認証情報です。

代表例は次のとおりです。

手法	狙うもの	特徴
MFA fatigue / Push Bombing	MFA承認	通知を大量送信して誤承認を狙う
AiTM	認証通信	偽サイト・Proxyを経由させる
Session Cookie Theft	Session Cookie	認証済みSessionを再利用する
OAuth Token Theft	Access / Refresh Token	SaaS・APIへアクセスする
Consent Phishing	OAuth権限	悪性アプリへ利用者自身に権限を与えさせる
Device-code Phishing	Device Authorization	正規OAuthフローを悪用する

MITRE ATT&CKでは、Session Cookie窃取をT1539として整理しています。盗まれたCookieは、認証済み利用者としてWebサービスへアクセスするために利用される可能性があります。

さらにT1550.004では、盗難Session Cookieを利用すると、一部のMFA方式を回避できる場合があると説明されています。

Session Cookieは「入館証」

パスワードが「建物の入口で本人確認するための情報」だとすれば、Session Cookieは本人確認済みであることを示す入館証のようなものです。

ID + Password + MFA
        ↓
     認証成功
        ↓
 Session Cookie発行
        ↓
以後はCookieで認証状態を維持

攻撃者がCookieを盗めば、

攻撃者
  ↓
盗難Cookie
  ↓
「すでに認証済み」
  ↓
サービス利用

となる場合があります。

そのため、

パスワードが漏れていないから安全

とは限りません。

2. OAuth Tokenは「サービスへ渡した委任状」

OAuth Tokenは、第三者アプリなどが利用者の代わりにAPIへアクセスするための認証材料です。

たとえるなら、

「このアプリには私のメールを読む権限を与えます」

という委任状です。

MITRE ATT&CK T1528では、Access Tokenが盗まれると、SaaS、クラウド、コンテナ、CI/CDなどで、そのTokenに与えられた権限を悪用される可能性があるとされています。Refresh Tokenが盗まれれば、新しいAccess Tokenを取得される場合もあります。

検知では、単純なログイン失敗だけでは足りません。

例えば、

OAuth App登録
      ↓
利用者Consent
      ↓
Token発行
      ↓
数分後
      ↓
通常と異なるIPから大量APIアクセス

という一連の流れを見る必要があります。

MITREの検知戦略でも、新しいOAuthアプリ、直後のToken発行、通常と異なるIP・アプリからのAPIアクセスなどを関連付ける方法が示されています。

3. Device-code Phishingでは偽ログインページすら不要な場合がある

OAuth 2.0のDevice Authorization Flowは、テレビやCLIなど、通常のブラウザ入力を行いにくい機器を認証するためにも使われる仕組みです。

攻撃者は、この正規の仕組みをソーシャルエンジニアリングへ利用する場合があります。

MITRE ATT&CKはT1566.002で、OAuth 2.0 Device Authorization Grant Flowを狙った手法を「device code phishing」として説明しています。

つまり、

偽ログインサイト

だけを探す検知では不足します。

4. MFA fatigueは「通知を承認させる攻撃」

MFA fatigueでは、攻撃者が既にIDとPasswordを持っていることがあります。

攻撃者
  ↓
Login
  ↓
MFA要求
  ↓
利用者「拒否」
  ↓
再Login
  ↓
MFA要求
  ↓
再Login
  ↓
MFA要求
  ↓
利用者「何だろう？」
  ↓
誤って承認

MITRE ATT&CKでは、この動作をMulti-Factor Authentication Request Generation（T1621）として整理しています。

CISAは可能であればFIDO/WebAuthnなどのphishing-resistant MFAへの移行を推奨しています。すぐに移行できない場合には、単純なPush承認よりnumber matchingを利用することも推奨しています。

検知したい流れ

大量MFA要求
     ↓
複数回拒否
     ↓
突然承認
     ↓
新しい端末
     ↓
OAuth変更
     ↓
メール転送設定作成

「MFA成功」という正常イベントだけを見ると、攻撃を見逃す可能性があります。

マルウェア、Fileless、Living off the Land

Filelessは「ファイルを一切使わない」という意味ではない

Fileless攻撃という名前から、

ディスクへファイルを書かない攻撃

だけを想像すると狭すぎます。

実務では、

PowerShell
WMI
rundll32
mshta
regsvr32
PsExec
Windows標準コマンド
正規リモート管理ソフト

などを悪用し、専用の悪性バイナリをできるだけ減らす攻撃も重要です。

MITRE ATT&CKでは、Microsoft署名済みなどの信頼されたバイナリを悪性コードのProxy Executionへ利用するSystem Binary Proxy ExecutionをT1218として整理しています。

PowerShell.exeを起動しただけでは攻撃ではない

PowerShellは管理者も普通に利用します。

そのため、

powershell.exe
      ↓
ALERT

では誤検知が大量に発生します。

見るべきなのは行動の組み合わせです。

Office / Browser / Script
        ↓
PowerShell
        ↓
長いEncoded Command
        ↓
外部通信
        ↓
Credential Access
        ↓
Remote Service

MITRE ATT&CKのPowerShell検知戦略も、Encoded Command、不自然な親プロセス、疑わしいModule、外部通信、子プロセス生成などの組み合わせを重視しています。

JPCERT/CCでもCobalt Strike・PsExec・Plinkを組み合わせた侵害が確認されている

JPCERT/CCは2024年9月から12月にかけて、CrossC2を利用するインシデントを確認しました。

その攻撃では、Cobalt Strike、PsExec、Plinkなどが利用され、Active Directoryへの侵入も試みられていました。

重要なのは、

PsExec = マルウェア

ではないことです。

PsExecにも正規用途があります。

したがって、

普段PsExecを使わない端末
        +
一般ユーザー
        +
深夜
        +
複数サーバーへ接続
        +
直前にCredential Dump

といったコンテキストを組み合わせて判断します。

ランサムウェアは「暗号化プログラム」ではなく侵入活動

現代の侵入型ランサムウェア

ランサムウェア対策を、

怪しいEXE
   ↓
暗号化

だけで考えるのは不十分です。

現代的な侵入型ランサムウェアでは、攻撃者が長時間ネットワーク内部を操作することがあります。

Internet
   ↓
VPN / Firewall / Web / Stolen Credential
   ↓
Initial Host
   ↓
AD Discovery
   ↓
Credential Theft
   ↓
Privilege Escalation
   ↓
SMB / RDP / PsExec / Remote Management
   ↓
Data Exfiltration
   ↓
Backup / VSS妨害
   ↓
Mass Encryption
   ↓
身代金要求 + 情報漏えい脅迫

CISAのStopRansomware Guideでも、侵害済み認証情報、RDP、リモートアクセス、権限管理、バックアップなどを含む多層的な対策が推奨されています。特にメール、VPN、重要システムへのphishing-resistant MFAが推奨されています。

暗号化が始まる前に見つける

ランサムウェア検知で本当に狙いたいのは、

暗号化開始

より前です。

例えば、

VPN Login
   ↓
AD Discovery
   ↓
Credential Dump
   ↓
Domain Admin
   ↓
PsExec
   ↓
Backup操作
   ↓
暗号化

なら、数段階前から異常が存在します。

Windows Event Logにも特徴が残る場合がある

JPCERT/CCは、複数のランサムウェア実行時にWindows Event Logへ特徴的な痕跡が残ることを検証しています。

例えばContiでは、Windows Restart Managerに関連するEvent ID 10000、10001が短時間に大量発生する特徴が確認されています。

同様の特徴はAkira、LockBit 3.0、HelloKittyなどでも確認されています。

ただし、Event ID 10000や10001が存在するだけでランサムウェアと断定してはいけません。

JPCERT/CC自身も、通常運用で記録される可能性があることを説明しています。

DDoSとHTTP/2 Rapid Reset

DDoSをbpsだけで監視してはいけない

DDoSというと、

大量通信
   ↓
帯域枯渇

を想像しがちです。

しかし、Layer 7 DDoSでは、

攻撃者が少ない処理で、サーバーへ大きな処理コストを発生させる

という非対称性が重要になります。

HTTP/2 Rapid Resetの仕組み

HTTP/2では、一つのConnection上で複数のStreamを扱えます。

Rapid Resetでは概念的に、

Stream開始
   ↓
Request送信
   ↓
即座にRST_STREAM
   ↓
次のStream
   ↓
即座にRST_STREAM
   ↓
大量反復

という動作を行います。

クライアントはレスポンス完了まで待ちません。

一方、サーバーではRequest解析やバックエンド処理が開始されている可能性があります。

Googleは2023年のRapid Reset攻撃で、ピーク3億9,800万requests/secを観測したと報告しています。

CISAもCVE-2023-44487を実悪用が確認された脆弱性としてKEVへ追加しています。

DDoSで監視するべき指標

Network
├─ bps
├─ pps
├─ connections/sec
│
HTTP
├─ requests/sec
├─ status code
├─ HTTP/2 streams/sec
├─ RST_STREAM rate
│
Application
├─ CPU
├─ Memory
├─ Worker
├─ Thread Pool
├─ DB Connection
└─ Upstream Latency

例えば通信帯域が十分残っていても、

RPS急増
+
Upstream Latency急増
+
CPU飽和

なら、アプリケーション層で可用性が失われる可能性があります。

脆弱性悪用とゼロデイ

「ゼロデイだから危険」だけでは優先順位を決められない

ゼロデイとは、利用可能な修正が存在しない、または防御側が十分対応できていない段階で悪用される脆弱性を指す文脈で使われます。

しかし実務では、

CVSS

だけでは優先順位を決められません。

見るべき要素は、

実悪用されているか
       +
Internet Facingか
       +
認証不要か
       +
RCE / Auth Bypassか
       +
重要資産へ到達できるか
       +
既存の防御策があるか

です。

CISAは、実際の悪用が確認された脆弱性をKnown Exploited Vulnerabilities Catalog、通称KEVとして管理しています。

MOVEit：CVE-2023-34362

MOVEit TransferのCVE-2023-34362では、SQL Injectionによって認証されていない攻撃者がデータベースへ不正アクセスできる脆弱性が問題となりました。

CISA KEVにも掲載され、ランサムウェアキャンペーンでの利用が確認されています。

Citrix Bleed：CVE-2023-4966

Citrix NetScaler ADC / GatewayのCVE-2023-4966では、盗まれたSession Cookieを利用したSession Hijackingが重要な問題となりました。

CISAのLockBit 3.0関連勧告でも、取得された有効Cookieによって認証済みSessionを確立する攻撃が説明されています。

特に重要なのは、パッチを適用するだけでは既に盗まれたSessionが無効になるとは限らない点です。

CISA KEVでも、対応時にはActive/Persistent Sessionを終了することが案内されています。

Ivanti CVE-2025-22457

CVE-2025-22457はIvanti Connect Secure、Policy Secure、ZTA Gatewayに影響するStack-Based Buffer Overflowです。

CISA KEVでは、認証されていないRemote AttackerがRemote Code Executionへ到達できる脆弱性として掲載されており、実悪用も確認されています。

パッチ適用後も侵害調査が必要な理由

攻撃の流れが、

脆弱性悪用
   ↓
Web Shell
   ↓
新規Account
   ↓
SSH Key追加
   ↓
Token発行

まで進んでいた場合、

Patch適用

で消えるのは最初の入口だけです。

攻撃者が残した永続化は別問題です。

そのため重大な実悪用脆弱性では、

封じ込め
+
パッチ
+
侵害調査
+
Credential / Token失効
+
Persistence確認

を一組として考える必要があります。

APTと正規インフラの悪用

「悪性ドメインを遮断する」だけでは検知できない

2026年のAPT-C-60は、この問題を理解しやすい事例です。

JPCERT/CCによると、APT-C-60は攻撃インフラとして、

GitHub
GitLab
jsDelivr
Codeberg

などの正規サービスを利用しました。

最終的にはSpyGlaceがダウンロード・実行されています。

開発組織ではGitHubやGitLabへの通信を一括禁止できない場合があります。

つまり、

github.com
      ↓
許可

では安全性を判断できません。

通信先ではなく「行動」を見る

従来型：

Bad Domain
    ↓
Block

行動型：

誰が
 ↓
どの端末から
 ↓
どのProcessを使い
 ↓
どのURLへ接続し
 ↓
何をDownloadし
 ↓
何を実行し
 ↓
その後どこへ通信したか

例えば、

Outlook
  ↓
RAR
  ↓
LNK
  ↓
mshta.exe
  ↓
GitHub / jsDelivr
  ↓
Executable
  ↓
未知IPへ通信

という連鎖なら、GitHubそのものを悪性判定しなくても検知できます。

Volt Typhoonとネットワーク機器

Volt TyphoonはLiving off the Landの代表的な事例です。

CISAなどは、正規のネットワーク管理機能・Windows標準機能を利用して通常活動へ紛れ込む手法を報告しています。

これはEDRだけでは防御範囲が不足する理由でもあります。

PC
 ↓
EDRあり

だけでは、

Router
Firewall
VPN
Hypervisor
SaaS
OT

を十分監視できません。

Salt Typhoonとルーター

通信事業者を狙った活動として、Salt Typhoonなどと重なる攻撃活動も重要です。

CISAなどの2025年共同勧告では、大規模通信事業者のBackbone Router、Provider Edge Router、Customer Edge Routerなどが標的になり、侵害済み機器や信頼関係を利用して別NetworkへPivotする活動が報告されています。

つまり、

Endpoint Security

だけでは現代の攻撃面をカバーできません。

確認方法

最低限確認したいログ

攻撃段階	主なログ	見たい異常
Initial Access	VPN / Firewall / WAF	新規IP、脆弱性攻撃、異常Login
Identity	IdP / Entra ID / SaaS	MFA連打、Token利用、OAuth Consent
Endpoint	EDR / Sysmon / Security	Process Tree、Credential Access
Execution	PowerShell	4104、Encoded Command
Discovery	Endpoint / AD	大量Account・Group探索
Lateral Movement	SMB / RDP / WinRM	普段存在しない接続
Cloud	Audit Log	IAM変更、Key作成、Token利用
SaaS	Audit Log	Mail Rule、OAuth App、APIアクセス
Network	DNS / Proxy / Firewall	Beacon、Tunnel、未知Destination
Ransomware	Windows / EDR	VSS、Backup操作、大量File変更
DDoS	CDN / LB / Web	RPS、Stream、Reset、Latency
Recovery	Backup	Delete、Policy変更、Restore失敗

重要なのはログを個別に見るのではなく、

Identity
   +
Endpoint
   +
Network
   +
Cloud / SaaS

を同一Timelineへ並べることです。

WindowsでEvent ID 10000・10001を確認する

目的

直近1時間のApplication Logから、Restart Manager関連のEvent ID 10000・10001が大量発生していないか確認します。

実行場所

Windows PowerShellまたはPowerShellを管理対象Windows端末で実行します。

読み取りのみで、ログを変更するコマンドではありません。

Get-WinEvent -FilterHashtable @{
    LogName   = 'Application'
    Id        = 10000,10001
    StartTime = (Get-Date).AddHours(-1)
} | Select-Object TimeCreated, Id, ProviderName, Message

正常例

数件程度
通常のアプリ更新・再起動処理と時刻が一致

異常例

数分間に10000 / 10001が大量発生
+
同時刻に大量ファイル変更
+
EDR Alert
+
VSS / Backup操作

判断方法

Event IDだけではランサムウェアと断定できません。

JPCERT/CCも通常運用で記録される可能性があるとしています。EDR、File I/O、Process Tree、バックアップ操作などと組み合わせて判断してください。

PowerShell Script Block Logを確認する

目的

PowerShellのScript Block Loggingが取得できているかを確認します。

実行場所

Windows PowerShellまたはPowerShell。

Get-WinEvent `
  -FilterHashtable @{
      LogName='Microsoft-Windows-PowerShell/Operational'
      Id=4104
  } `
  -MaxEvents 20 |
Select-Object TimeCreated, Id, Message

正常例

管理スクリプト
既知の運用処理
既知ユーザー
既知時刻

異常例

不自然に長いEncoded Command
+
Office・Browserなど通常と異なる親Process
+
外部通信
+
Credential Access

判断方法

powershell.exeの存在だけでは攻撃判定しません。

MITRE ATT&CKでも、不自然な親Process、Encoded Command、Network Connectionなどを組み合わせるBehavior Detectionが示されています。

対処方法

インシデントを疑った場合の基本順序

flowchart TD
    A["異常検知"] --> B["証拠保全"]
    B --> C["影響範囲確認"]
    C --> D["Host / Account封じ込め"]
    D --> E["Session / Token失効"]
    E --> F["Credential変更"]
    F --> G["脆弱性・設定修正"]
    G --> H["Persistence除去"]
    H --> I["Clean Recovery"]
    I --> J["監視強化"]

特にIdentity侵害では、

Password Reset

だけでは不足する場合があります。

確認対象には、

Active Session
Session Cookie
Refresh Token
OAuth Consent
Application Credential
API Key
SSH Key
Mail Forwarding Rule
MFA Device
Device Registration

なども含めます。

MITRE ATT&CKがSession CookieやApplication Access Tokenを独立した認証材料として扱っている理由も、この点にあります。

ランサムウェア発生時

優先順位は、

1. 暗号化停止
2. 横展開停止
3. 証拠保全
4. 認証基盤保護
5. Backup保護
6. 情報窃取範囲確認
7. Clean Recovery

です。

バックアップサーバーを慌てて本番Networkへ接続すると、バックアップ側まで侵害される危険があります。

復旧用Credentialが本番Domain Adminと同一でないかも確認します。

脆弱性悪用を疑った場合

単にPatchを適用して終了しません。

最低でも、

Web Server
   ↓
Child Process
   ↓
Shell / PowerShell
   ↓
New File
   ↓
New Account
   ↓
SSH Key / API Key
   ↓
External Communication

を確認します。

特にInternet-facingのVPN、Firewall、ADC、Gateway、管理画面などは高優先度です。

動作確認

対策後は「設定した」ではなく「攻撃経路が閉じた」ことを確認します。

確認対象	正常状態
Password	侵害Credentialが無効
Session	既存Sessionが失効
OAuth	不審Consent・Appが存在しない
MFA	不正Deviceが存在しない
Endpoint	Persistenceなし
AD	不正Admin・Group変更なし
Cloud	不正Key・Roleなし
Network	不審C2通信なし
Backup	攻撃者から分離されRestore成功
Vulnerability	修正版適用済み
Web	Web Shell・不正Fileなし
DDoS	RPS・LatencyがBaselineへ復帰

再発防止

最も効果が高いのは、特定の攻撃名ごとに製品を追加することではありません。

防御を攻撃ライフサイクルへ対応させます。

External Attack Surface
        ↓
Asset Inventory
        ↓
KEV / Patch Management
        ↓
Identity Security
        ↓
Endpoint / Server
        ↓
Segmentation
        ↓
Cloud / SaaS / AD / OT
        ↓
SIEM / NDR / Detection
        ↓
Incident Response
        ↓
Immutable Backup
        ↓
Clean Recovery

IdentityではFIDO/WebAuthnを含むphishing-resistant MFAへの移行が有効です。CISAもFIDO/WebAuthnを強く推奨しています。

正規管理ツールについては全面禁止ではなく、

誰が
どの端末から
いつ
何の目的で
どこへ

をBaseline化します。

注意点・よくある誤解

誤解1：「MFAを入れたから安全」

この考えには反対です。

MFAは非常に重要ですが万能ではありません。

MFA fatigue、AiTM、Session Cookie、OAuth Tokenなど、MFAの前後を狙う攻撃が存在します。

誤解2：「PowerShellを禁止すればLOTLを防げる」

これも単純化しすぎています。

PowerShell以外にも、mshta、rundll32、regsvr32、msiexecなど多数の正規Binaryが悪用対象になります。

重要なのはTool名ではなく利用Contextです。

誤解3：「CVSSが高いCVEから順に直せばよい」

この運用も不十分です。

CVSS 9.8でもInternetへ公開されていないServerと、

Internet Facing
+
認証不要
+
実悪用あり
+
重要Networkへ直結

の脆弱性ではリスクが異なります。

KEV、External Exposure、Asset Criticalityを組み合わせる必要があります。

誤解4：「GitHubへの通信だから安全」

危険な判断です。

APT-C-60のように、GitHub、GitLab、jsDelivr、Codebergなど正規サービスが攻撃インフラへ利用される事例があります。

誤解5：「パッチを当てればインシデント対応完了」

成立しません。

既にWeb Shell、Account、Token、SSH Keyなどが設置されていれば、Patch後も攻撃者は残れます。

Citrix Bleedでも、CISAは修正だけでなく既存Sessionの終了を案内しています。

誤解6：「DDoSはbpsだけ見ればよい」

現在のApplication DDoSには不足します。

Rapid ResetのようにHTTP Request処理そのものへ非対称な負荷を掛ける攻撃では、RPS、HTTP/2 Stream、Reset、CPU、Latencyなども必要です。

まとめ

2026年時点のサイバー攻撃を理解するとき、最も重要なのは攻撃名を暗記することではありません。

攻撃者が、

どこから入り
    ↓
何を実行し
    ↓
どの認証情報を取得し
    ↓
どこを探索し
    ↓
どの権限へ昇格し
    ↓
どの端末へ横展開し
    ↓
何を盗み
    ↓
最終的に何を行ったか

を見ることです。

特に現在は、

Password
↓
Session / Token

Malware
↓
LOTL / 正規管理機能

Bad Domain
↓
GitHub / GitLab / CDNなど正規Service

Endpoint
↓
SaaS / Cloud / Router / VPN / OT

へ攻撃対象が広がっています。

M-Trends 2026では脆弱性悪用が依然として最大の初期侵入経路である一方、対話型vishingが増加し、OAuth TokenやSession CookieなどIdentityを狙う攻撃も重要になっています。

つまり防御側も、

Firewallだけ
Antivirusだけ
EDRだけ
MFAだけ

ではなく、

Identity
+
Endpoint
+
Network
+
Cloud / SaaS
+
Vulnerability
+
Backup
+
Incident Response

を一つの攻撃Timelineとして扱う必要があります。

「侵入されないこと」だけを目標にするのではなく、「侵入されても早期に検知し、横展開を止め、重要資産へ到達させず、確実に復旧できること」まで設計する。

この考え方が、現在のサイバー攻撃へ対応するうえで重要です。

FAQ

Q1. MFAがあればパスワードが漏れても安全ですか？

安全とは断定できません。

MFA fatigueやAiTMだけでなく、認証完了後のSession Cookieが盗まれる可能性があります。

ただしMFAが不要という意味ではありません。

可能であればFIDO/WebAuthnなどphishing-resistant MFAへ移行してください。

Q2. Session Cookieが盗まれたらPassword変更だけでよいですか？

不十分な場合があります。

サービスによってはPassword変更後も既存Sessionが残る場合があります。

Session失効、Token Revoke、OAuth Consent、登録Deviceなども確認します。

Q3. PowerShellを実行したログがあれば侵害確定ですか？

いいえ。

PowerShellは正規管理ツールです。

親Process、User、Command Line、Network、Child Process、後続するCredential Accessなどと組み合わせて判断します。

Q4. CISA KEVに載っていなければ対応しなくてもよいですか？

いいえ。

KEVは実悪用が確認された脆弱性の優先順位付けに非常に有用ですが、KEV未掲載だから安全という意味ではありません。

Internet Exposure、Asset Criticality、Exploit Availability、Vendor Advisoryなども確認してください。

Q5. EDRがあればAPTにも対応できますか？

EDRは重要ですが、それだけでは不足します。

Network Device、VPN、Cloud IAM、SaaS、Router、OTなど、Agentを導入できない領域があります。

Volt TyphoonやSalt Typhoon関連の公表事例は、Endpoint以外も攻撃面として管理する必要性を示しています。

参考情報

MITRE ATT&CK

MITRE ATT&CK – Steal Web Session Cookie T1539
https://attack.mitre.org/techniques/T1539/

MITRE ATT&CK – Web Session Cookie T1550.004
https://attack.mitre.org/techniques/T1550/004/

MITRE ATT&CK – Steal Application Access Token T1528
https://attack.mitre.org/techniques/T1528/

MITRE ATT&CK – Multi-Factor Authentication Request Generation T1621
https://attack.mitre.org/techniques/T1621/

MITRE ATT&CK – Spearphishing Link / Device-code Phishing T1566.002
https://attack.mitre.org/techniques/T1566/002/

MITRE ATT&CK – System Binary Proxy Execution T1218
https://attack.mitre.org/techniques/T1218/

MITRE ATT&CK – PowerShell T1059.001
https://attack.mitre.org/techniques/T1059/001/

JPCERT/CC

APT-C-60による2026年の攻撃
https://blogs.jpcert.or.jp/ja/2026/07/apt-c-60_2026.html

CrossC2を使った攻撃
https://blogs.jpcert.or.jp/ja/2025/08/crossc2.html

侵入型ランサムウェア攻撃発生時に残るWindowsイベントログの調査
https://blogs.jpcert.or.jp/ja/2024/09/windows.html

CISA

#StopRansomware Guide
https://www.cisa.gov/stopransomware/ransomware-guide

Known Exploited Vulnerabilities Catalog
https://www.cisa.gov/known-exploited-vulnerabilities-catalog

HTTP/2 Rapid Reset Vulnerability – CVE-2023-44487
https://www.cisa.gov/news-events/alerts/2023/10/10/http2-rapid-reset-vulnerability-cve-2023-44487

CL0P / MOVEit – CVE-2023-34362
https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-158a

LockBit 3.0 / Citrix Bleed – CVE-2023-4966
https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-325a

Citrix Bleed Guidance
https://www.cisa.gov/guidance-addressing-citrix-netscaler-adc-and-gateway-vulnerability-cve-2023-4966-citrix-bleed

Volt Typhoon – PRC State-Sponsored Actors
https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-038a

Salt Typhoon等と重なるPRC系Network侵害活動 – AA25-239A
https://www.cisa.gov/news-events/cybersecurity-advisories/aa25-239a

CISA – More than a Password
https://www.cisa.gov/more-password

Google / Mandiant

M-Trends 2026
https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026

HTTP/2 Rapid Resetの仕組み
https://cloud.google.com/blog/products/identity-security/how-it-works-the-novel-http2-rapid-reset-ddos-attack

398 million rps Rapid Reset DDoS
https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps/

IPA

情報セキュリティ10大脅威 2026
https://www.ipa.go.jp/security/10threats/10threats2026.html

サイバー攻撃を学ぶとき、フィッシング、ランサムウェア、ゼロデイ、DDoS、APTといった「攻撃名」を一つずつ覚えがちです。

結論・要点

この記事の要点

この記事で分かること

対象読者・前提環境

用語と全体像

サイバー攻撃は「泥棒が建物の奥へ進む流れ」と考えると分かりやすい

問題・仕組み・原因

1. フィッシングの次に「認証済み状態」が狙われる

Session Cookieは「入館証」

2. OAuth Tokenは「サービスへ渡した委任状」

3. Device-code Phishingでは偽ログインページすら不要な場合がある

4. MFA fatigueは「通知を承認させる攻撃」

検知したい流れ

マルウェア、Fileless、Living off the Land

Filelessは「ファイルを一切使わない」という意味ではない

PowerShell.exeを起動しただけでは攻撃ではない

JPCERT/CCでもCobalt Strike・PsExec・Plinkを組み合わせた侵害が確認されている

ランサムウェアは「暗号化プログラム」ではなく侵入活動

現代の侵入型ランサムウェア

暗号化が始まる前に見つける

Windows Event Logにも特徴が残る場合がある

DDoSとHTTP/2 Rapid Reset

DDoSをbpsだけで監視してはいけない

HTTP/2 Rapid Resetの仕組み

DDoSで監視するべき指標

脆弱性悪用とゼロデイ

「ゼロデイだから危険」だけでは優先順位を決められない

MOVEit：CVE-2023-34362

Citrix Bleed：CVE-2023-4966

Ivanti CVE-2025-22457

パッチ適用後も侵害調査が必要な理由

APTと正規インフラの悪用

「悪性ドメインを遮断する」だけでは検知できない

通信先ではなく「行動」を見る

Volt Typhoonとネットワーク機器

Salt Typhoonとルーター

確認方法

最低限確認したいログ

WindowsでEvent ID 10000・10001を確認する

目的

実行場所

正常例

異常例

判断方法

PowerShell Script Block Logを確認する

目的

実行場所

正常例

異常例

判断方法

対処方法

インシデントを疑った場合の基本順序

ランサムウェア発生時

脆弱性悪用を疑った場合

動作確認

再発防止

注意点・よくある誤解

誤解1：「MFAを入れたから安全」

誤解2：「PowerShellを禁止すればLOTLを防げる」

誤解3：「CVSSが高いCVEから順に直せばよい」

誤解4：「GitHubへの通信だから安全」

誤解5：「パッチを当てればインシデント対応完了」

誤解6：「DDoSはbpsだけ見ればよい」

まとめ

FAQ

Q1. MFAがあればパスワードが漏れても安全ですか？

Q2. Session Cookieが盗まれたらPassword変更だけでよいですか？

Q3. PowerShellを実行したログがあれば侵害確定ですか？

Q4. CISA KEVに載っていなければ対応しなくてもよいですか？

Q5. EDRがあればAPTにも対応できますか？

参考情報

MITRE ATT&CK

JPCERT/CC

CISA

Google / Mandiant

IPA

コメント（0件）

コメントを投稿