ランサムウェアという言葉を聞くと、多くの人がまず思い浮かべるのは、「ファイルが暗号化された」「身代金を要求された」といった、いわば“結果”の部分だと思います。
ニュースでも、どうしてもその場面が強調されがちです。
ただ、診断やインシデント対応の現場に立っていると、視点は自然と少し違うところに向かいます。
それは、「暗号化されたかどうか」よりも前に、そもそも、どこから中に入られていたのかという点です。
脆弱性以外の感染経路もあります。
実感として言うと、入口はそこまで多くありません。
むしろ、「またここか」と思うほど、パターンは限られています。
攻撃者視点で侵入経路を検証することも大切です。
派手なゼロデイ攻撃や、映画のような高度な侵入手法が使われることは、現実にはそれほど多くありません。
実際に多いのは、
- 以前からインターネットに公開されたままの管理系サービス
- 重要だと分かっていながら、後回しにされてきた既知の脆弱性
こうした、特別ではない場所が、静かに入口になっているケースです。
しかも厄介なのは、侵入された直後に何かが壊れるわけではない、という点です。
ログインされても、設定を少し覗かれても、業務は普通に続きます。
通知が出ることもなく、「問題は起きていないように見える」時間が続きます。
その状態がしばらく続いたあとで、ある日突然、暗号化という形で表に出てくる。
現場で見てきた多くのランサムウェア被害は、だいたいこの流れです。
いま主流になっているランサムウェア攻撃も、決して例外ではありません。
流行っている手口が変わったというより、見落とされやすい入口が、そのまま使われ続けているそう表現したほうが、感覚としては近い気がしています。
https://cyber.spool.co.jp/open-source-intelligence-osint/
現在のランサムウェア攻撃で多い侵入パターン
ランサムウェアグループが使う侵入手法は、ここ数年で少しずつ様子が変わってきました。
以前は、怪しいメールの添付ファイルや、マクロを有効にさせるタイプの攻撃が目立っていましたが、最近の現場では、それだけでは説明がつかないケースが増えています。
いま特に目立つのは、外部に公開された管理系サービスを起点とした侵入です。
しかもそれは、設定ミスや運用上の判断が少し重なっただけで成立してしまう、非常に現実的な入口でもあります。
その中でも、繰り返し名前が挙がるのが RDP（リモートデスクトップ） です。
出典：Coveware「Q1 2020 Ransomware Marketplace Report」より
RDPそのものが危険な仕組み、というわけではありません。
IT管理者にとっては、サーバーや端末を遠隔から操作するための、ごく正当で便利な機能です。
実際、多くの現場で日常的に使われています。
問題になるのは、RDPが次のような状態で運用されているときです。
- インターネットに直接公開されている
- パスワードが他のサービスと使い回されている
- 多要素認証が設定されていない
どれか一つだけであれば、すぐに致命的になるとは限りません。
ただ、これらが重なった瞬間に、RDPは「入口」として非常に分かりやすい存在になります。
実際の侵入も、派手なことはあまり起きません。
総当たりや漏洩済み認証情報を使ってログインされ、気づかれないまま内部の様子を少しずつ確認されていきます。
一度足がかりを得た攻撃者は、すぐにランサムウェアを実行するとは限りません。
内部の構成を把握し、権限を広げ、「いつ、どこまでできるか」を静かに探っていきます。
そして、十分に準備が整った段階で、最後に実行されるのが暗号化です。
現場で見てきた多くのケースでは、暗号化はスタートではなく、ほぼ最終工程でした。
だからこそ、被害が表に出たときには、「もうかなり前から入られていた」という状況になりやすいのだと思います。
ランサムウェア攻撃の入口として悪用された代表的な脆弱性
すべての脆弱性を追いかけ続けることは、正直なところ現実的ではありません。
診断や運用の現場にいる人ほど、そのことはよく分かっていると思います。
日々公開される情報の量は多く、「全部に対応する」という発想自体が負担になりがちです。
ただ一方で、実際のインシデントを振り返ってみると、繰り返し名前が挙がる脆弱性があるのも事実です。
環境や業種が違っても、「またこれか」と感じるポイントは、驚くほど重なります。
それらに共通しているのは、すでに存在が知られており、パッチや回避策も提示されていたにもかかわらず、運用上の理由や優先度の問題で、そのまま使われ続けていた、という点です。
ここでは、そうした中でも、実際にランサムウェアの初期侵入の足がかりとして悪用されてきた脆弱性を、現場での使われ方がイメージできる形で整理していきます。
Pulse Secure VPN（CVE-2019-11510）
VPN機器は、そもそも「社外から社内に入るための正規ルート」です。
だからこそ、一度ここが突破されると、影響はどうしても大きくなります。
ファイアウォールの外側から無理やりこじ開けるのではなく、許可された入口をそのまま使われてしまう、という感覚に近いかもしれません。
この脆弱性では、認証を経ることなく、機器内部のファイルを読み取れる状態が発生していました。
結果として、設定ファイルやログに含まれていたユーザー名や、場合によっては平文のパスワード情報が取得され、そこを起点に社内ネットワークへ横展開されるケースが確認されています。
厄介だったのは、特別な操作をしなくても情報が取れてしまう点でした。
管理画面にログインする必要すらなく、「外から見えてしまっているものを、そのまま読まれる」状態です。
パッチ自体は比較的早い段階で提供されていました。
ただ、実際の攻撃が一気に増えたのは、脆弱性の存在が広く知られ、PoCが公開されたあとです。
現場でも、「情報は知っていたが、まだ大丈夫だと思っていた」という声を何度か聞きました。
VPNはインフラとして安定稼働していることが多く、止める判断や更新のタイミングが後回しになりやすい、という事情もあります。
| 国名 | 台数 |
|---|---|
| 米国 (United States) | 1,316 |
| 日本 (Japan) | 394 |
| 英国 (United Kingdom) | 221 |
| 韓国 (South Korea) | 203 |
| フランス (France) | 186 |
| ドイツ (Germany) | 141 |
| 中国 (China) | 123 |
| 香港 (Hong Kong) | 93 |
| ベルギー (Belgium) | 89 |
| カナダ (Canada) | 74 |
| その他すべて (All others) | 985 |
結果として、「VPNだから安全だろう」という前提が、対応を遅らせてしまったケースも少なくありませんでした。
VPNは守りの要、という認識自体は間違っていません。
ただ、その安心感が強すぎると、いざ問題が見つかったときに、判断が鈍ってしまうことがある。
この脆弱性は、そのことを強く印象づけた事例だったと感じています。
Microsoft SharePoint（CVE-2019-0604）
SharePointは、多くの組織にとって社内情報の集約点です。
ドキュメント管理やワークフロー、部門間の情報共有など、日々の業務に深く入り込んでいるシステムでもあります。
この脆弱性では、細工されたアプリケーションパッケージをアップロードされることで、SharePointサーバー上で任意のコードが実行される可能性がありました。
一見すると操作は限定的に見えますが、実際には、SharePointが動作している権限の範囲で、かなり自由に振る舞える状態になります。
実際の被害事例では、Webシェルとして知られる China Chopper が設置され、そこを足がかりに、サーバー内部の探索や追加の不正操作が行われていました。
いわば、「業務システムの中に、裏口が一つ作られた」ような状態です。
厄介なのは、この段階では、ファイルが壊れるわけでも、サービスが止まるわけでもない、という点です。
管理者の目から見ると、SharePointは普段どおり動いています。
ログインもできるし、業務も進む。
だからこそ、異変に気づくきっかけがほとんどありません。
さらに、SharePointは「業務システム」であるがゆえに、外部に公開されていること自体が、組織内で正確に把握されていないケースも少なくありません。
「社内向けに使っているはず」
「インターネットから直接触られる想定ではない」
そうした認識のまま運用され、結果として、攻撃者から見える場所に置かれていた、という状況を、
診断の現場でも何度か目にしてきました。
この脆弱性は、“業務に欠かせないシステムほど、入口になりやすい”という事実を、あらためて突きつけた例だったように思います。
Microsoft Exchange（CVE-2020-0688）
Exchangeに関しては、「認証が必要な仕組みだから、外部から簡単に悪用されることはない」そう判断されがちなシステムです。
実際、管理者の感覚としても、その認識は理解できます。
ただ、この脆弱性が厄介だったのは、いったん認証を通過してしまえば、その後の権限チェックが意味を持たなくなる点でした。
管理者権限でなくても、メールを読むだけのような権限しか持たないアカウントであっても、SYSTEM権限で任意のコードが実行できる可能性がありました。
つまり、問題は「管理者アカウントが守られているか」ではありません。
内部アカウントが一つでも漏れていれば、そこから一気にサーバー全体を掌握される余地があった、という点です。
現場で対応していると、「まさか一般ユーザーのアカウントが入口になるとは思わなかった」という声を聞くことがあります。
この脆弱性は、その思い込みを突く形で悪用されていました。
もう一つ、背景として見逃せないのが運用上の事情です。
メール基盤は、業務の中核にあたるため、常時稼働が前提になります。
止めること自体が難しく、パッチ適用のタイミングが後回しになりやすいシステムでもあります。
結果として、「重要だと分かっているが、今は手を入れられない」という状態が長く続き、その隙を突かれる形で侵入されるケースを、何度も見てきました。
Exchangeの事例は、“認証がある＝安全”とは限らないという、ごく基本的な事実を、改めて突きつけてきたように感じています。
Exim（CVE-2019-10149）
Eximは、世界中で広く使われているMTA（メール転送エージェント）です。
特にLinux環境では、長年にわたって安定して使われてきた実績があり、「とりあえず動く」「一度入れたらそのまま」という扱いをされやすい存在でもあります。
この脆弱性は、メール配送処理の中にある入力チェックの不備から、条件がそろうとコマンド実行に至る可能性がある、というものでした。
外から見ると、単なるメールのやり取りに見えるため、攻撃が成立していること自体に気づきにくい点が特徴です。
出典：Tenableブログ「CVE-2019-16928: Critical Buffer Overflow Flaw in Exim is Remotely Exploitable」より
調査時点で、脆弱なバージョンが非常に多く稼働していたことも、この事例を象徴しています。
Shodanなどの調査結果を見ると、修正済みの最新バージョンよりも、古いバージョンのほうが圧倒的に多く残っていました。
公開観測された Exim サーバーの分布を見ると、約9割が、当時すでに修正が提供されていた脆弱なバージョンのまま稼働していたことが確認されています。
現場で感じるのは、メールサーバーが「止まらないこと」を最優先に扱われている、という点です。
業務への影響が大きいため、更新や再起動を伴う作業は、どうしても後回しになります。
その結果、「安定して動いている＝安全である」という認識が生まれ、実際には脆弱な状態のまま、長期間運用されてしまう。
Eximの脆弱性は、“動いていること”と“安全であること”は別の話という事実を、あらためて突きつけた例だったように思います。
Citrix ADC（CVE-2019-19781）
Citrix製品は、VPNやリモートアクセス用途として、非常に多くの組織に導入されています。
社外から社内システムへ安全に接続するための基盤として、長年にわたって使われてきた製品群です。
この脆弱性では、ディレクトリトラバーサルを起点に、最終的にリモートコード実行まで到達するケースが確認されました。入口は単純でも、到達点は決して軽いものではありません。
特徴的だったのは、管理画面にログインできるかどうか以前に、外部から見えているだけで悪用の余地が生まれる点でした。
攻撃者にとっては、特別な準備や高度な権限を必要としない分、非常に扱いやすい入口だったと言えます。
この脆弱性のもう一つの特徴は、影響範囲の広さです。
公開されている調査では、特定の国や地域に限らず、世界各国で多数の脆弱な Citrix エンドポイントが確認されていました。
国別の分布を見ると、ITインフラが成熟している国ほど、インターネット上に公開されたままの Citrix 環境が多く存在していたことが分かります。
これは、「特定の業界や地域だけの問題ではない」ことを、静かに示しています。
現場で対応していると、
「重要なシステムだから、止められない」
「止められないから、更新が後回しになる」
という循環を、あらためて感じさせられます。
Citrixの事例は、リモートアクセス基盤そのものが、最大の入口になり得るという現実を、多くの組織に突きつけた出来事だったように思います。
なぜ、これらは見落とされやすいのか
ここまで見てきた事例に共通しているのは、どれも次の条件を満たしている、という点です。
- 管理系システムであること
- 業務上「止められない」存在であること
- すでに導入され、日常的に使われている仕組みであること
どれも、特別なものではありません。
むしろ、多くの組織にとって「当たり前にそこにあるもの」です。
だからこそ、狙われます。
新しい攻撃手法や、未知の技術が使われているわけではありません。
実際に入口になっているのは、以前から存在を知っているはずの仕組みであり、過去に一度は話題になった脆弱性であることがほとんどです。
ただ、それらは「いま問題を起こしていない」という理由で、次第に意識の外へ追いやられていきます。
管理画面にはログインできている。
サービスも止まっていない。
業務は今日も回っている。
そうした状態が続くと、「特に問題は起きていない」という認識が、いつの間にか「安全である」という評価にすり替わっていきます。
その結果、本当は入口になり得る場所が、誰にも注目されないまま残り続ける。
診断やインシデント対応の現場で感じるのは、多くのランサムウェア被害が、何かが起きてから突然始まるのではなく、何も起きていない時間の積み重ねの先で表に出てくるということです。
だからこそ、「何も起きていない今」という状態そのものが、実は一番見直しやすく、一番価値のあるタイミングなのだと思っています。
https://cyber.spool.co.jp/penetration-test-purpose-types/
入口は、いつも静かなところにある
ランサムウェアは、ある日突然、何もないところから現れるものではありません。
多くのケースでは、侵入から暗号化までに、一定の時間があります。
その間、攻撃者は騒ぎを起こさず、目立たない形で内部の様子を見ています。
だからこそ、被害が表に出た瞬間だけを切り取ると、「急に起きた」「防ぎようがなかった」と感じてしまいがちです。
ただ、予防や診断の立場から現場を見ていると、本当に分かれ目になるのは、もっと手前の段階だと感じることが多くあります。
それは、何かが壊れる前、何も起きていないように見える時間の中で、一度だけ立ち止まって環境を見直せていたかどうか、という点です。
例えば、
- 外部に公開されている管理系サービスは、いま何があるのか
- その中で、いつから更新が止まっているものはないか
- 認証情報が前提になり、過信されている仕組みはないか
こうした点を、完璧に洗い出す必要はありません。
すべてを一度に変える必要もありません。
ただ、何も起きていない今の状態で、一度だけ整理してみる。
それができているかどうかで、いざ何かが起きたときの選択肢は、大きく変わります。
診断の現場で感じるのは、「防げたかどうか」よりも、「考える余地があったかどうか」が、その後の対応を左右する、ということです。
ランサムウェア対策は、恐怖を煽るためのものでも、完璧を目指すためのものでもありません。
大きく変える必要はありません。
いまの構成を、いまの視点で見直す。
それだけでも、判断材料は増えていきます。
侵入口となる脆弱性を診断で洗い出すためのおすすめ会社は以下記事を参考になさってください。
https://cyber.spool.co.jp/vulnerability-assessment-company-guide/
脆弱性を突く攻撃を防ぐ対策の記事は以下を参考になさってください。
