SynologyにおけるC3RB3Rランサムウェア：起源、復旧、および安全対策

C3RB3R ランサムウェア 2026年10月28日頃からSynology NASユニットで検出され始め、わずか1日足らずでr/synology上の唯一の話題となりました。ファイルは名前が変更され、 L0CK3D 拡張子（文字のOではなく数字のゼロ）が付与され、すべてのフォルダに read-me3.txt という身代金要求テキスト（ランサムノート）が作成され、TorポータルでBitcoinが要求されます。最も迅速で有益な情報は、英語のニュースサイトからではなく、Synologyの巨大なユーザーベースを持つ中国語圏のフォーラムや、実際にデータを復旧できた（あるいは復旧不可能であることを証明した）被害者によって作成された3つのGitHubリポジトリからもたらされました。このガイドでは、C3RB3R ランサムウェアに関してこれまでに確認された情報（発生元、侵入経路、効果のあった唯一の復旧手順、そしてこのような攻撃を受けても身代金ではなく復元だけで済むように私たちが運用しているバックアップ設計）をまとめています。

更新、2026年10月31日： Synologyは侵入経路を特定しました。10月30日付のユーザー宛て電子メールにおいて、C3RB3R ransomwareが悪用しているのは2024年12月に修正されたSynology-SA-24:20の脆弱性のみであり、同月に修正されたPHP2Shell脆弱性とは無関係であることを確認しました。当社は、Synology自身の4ステップのチェックリスト、攻撃がなぜそのタイミングで実行されたかについての当社の見解、そしてほとんどの所有者がすでに費用を支払っている追加の保護機能であるActive Insightのランサムウェア保護機能を追加しました。

SynoPower Clubポイント：中国のNASグループのある被害者は、1台の機器に50 TB以上のデータを保持していましたが、スナップショットを作成していませんでした。暗号化処理が十分に遅かったため被害を受けたのは2024年の写真のみであり、幸いにもそれらはクラウドドライブにコールドコピーが保存されていました。別の被害者は、RAID 6と3つのバックアップがすべて同じ機器上に存在していたため、5年分のプライベートGitLabリポジトリを失いました。C3RB3R ランサムウェアは彼らのストレージを破ったのではなく、彼らのバックアップ設計を破ったのです。私たちは公開サイトをVirtual DSM内のDockerとして実行し、ホストからゲスト全体のスナップショットを取得して2台目のNASに複製し、スケジュールに従ってUSBやクラウドにエクスポートしています。今夜ゲストが暗号化されたとしても、最後のスナップショットにロールバックすれば、攻撃者は何も得られません。

C3RB3R ランサムウェアとは？

C3RB3R ランサムウェアは、2016年から存在し長年にわたりNASデバイスを断続的に標的としてきたCerberファミリーのLinuxビルドです。360は2026年10月のSynologyに対する攻撃の波をこれに起因すると考えています。感染したDSM機器上では、C3RB3R ランサムウェアの暗号化プログラムは、静的リンクされUPXでパックされたx86-64バイナリとして実行され、ファイル名は libgldとなっています。起動後に自らのファイルを削除するため、実行中のプロセスには実行ファイルパスの隣に (削除済み) と表示されます。

C3RB3R ランサムウェアの被害に遭った機器の所有者が目にする症状は、すべての報告で共通しています：

• ファイル名が以下のように変更される： name.ext.L0CK3D（一部の報告では LOCK3Dと表記されていますが、GitHubの解析では数字のゼロが引用されています）。
• 暗号化されたすべてのフォルダ内に read-me3.txt という名前の身代金要求テキストが作成され、見出しには「C3RB3R INSTRUCTIONS」と記載される。
• 「C3rb3r Decryptor」というタイトルのTorページ。ある被害者のスクリーンショットでは、5日以内に支払う場合は0.03696 BTC（約2,952米ドル）、それ以降はカウントダウンタイマーとともに2倍の0.07392 BTC（約5,904米ドル）になると表示されていました。
• 以下に一致するcronエントリによる永続化： /etc/cron.d/synot*（これらは自己再生成され、少なくとも1つの事例ではDSMのアップグレード後も生き残りました）。
• Hyper Backupのターゲットやデータベースダンプを含め、同じボリューム上にあるバックアップファイルが他のすべてとともに暗号化される。

発生源：r/synologyと中国語フォーラム

C3RB3R ランサムウェアが英語圏で最初に表面化したのはr/synologyで、2026年10月28日および29日頃に被害者がほぼ1日差で投稿を行いました。数時間もしないうちに、サブレディットを再読み込みするたびに新しいスレッドが表示されると読者が報告するほどになりました。それらのスレッドのうち、それぞれ異なる情報を提供している3つのスレッドは一読の価値があります：

• フォレンジック分析のレポート。 DSM 7.2.1-69057 Update 5を実行し、Webインターフェースがインターネットからアクセス可能だったDS918+の所有者が、機器をシャットダウンしてProxmoxホスト上でディスクを読み取り専用で検査しました。DSMの認証ログには、アカウントフィールドにインジェクトされた LD_PRELOAD そして LD_DEBUG_OUTPUT の行とエンコードされたシェルコマンド、および /etc/cron.d配下のファイルが含まれるログインリクエストが残っていました。これは公開されているCVE-2024-10441の手法と一致します。3-2-1バックアップを実施していたため、攻撃を受けても身代金ではなく復元だけで済みました。詳しくはこちらをお読みください： ついに起きてしまいました。自身初の本格的なランサムウェア被害です。.
• Photosのみを使用していたユーザー。 この所有者はDSMが最新であると信じ、Synology Photosのみを使用していましたが、ルーターのUPnPが有効になっていました。モード2リセット後、Snapshot Replicationで保護されていたフォルダは復元されました。スナップショットのないフォルダは復元されず、ローカルのHyper Backup用USBドライブもNASとともに暗号化されました。詳しくはこちらをお読みください： 今朝、c3rb3rランサムウェアの被害に遭いました.
• QuickConnectに関する議論。 投稿者はDSMのパフォーマンスが低下し、再インストールを行って暗号化されたファイルが判明して初めて気づきました。返信欄では、強力なパスワード、2要素認証（2FA）、およびQuickConnectを有効にしていた別の読者も被害に遭ったと述べており、アプリのみを使用するユーザーはQuickConnectでのDSMアクセスを完全に無効化できると他のユーザーが指摘していました。詳しくはこちらをお読みください： C3RB3Rランサムウェアの被害に遭いました.

これらを総合すると、パターンは明確です。C3RB3R ランサムウェアに必要なのは、アクセス可能なDSMログインページだけでした。パスワードや2FAは役に立ちませんでした。なぜなら、エクスプロイトは認証の前に実行されるからです。フォレンジックレポートでは端的に説明されています：リクエストは脆弱性のあるアプリケーションに到達したため、さらなるパスワードプロンプトがあっても問題を解決できなかったでしょう。

より詳細な技術的検証は中国語で行われました。WeChat や Xiaohongshu のグループの被害者は身代金要求ノートを投稿し、タイムラインを比較し、以下で説明する GitHub リポジトリを互いに共有し合いました。Facebook 上の台湾の Synology コミュニティは、 地元のユーザー向けに同じ復旧リンクをまとめました。 それも納得がいきます。Synology は台湾の企業であり、最大のユーザーコミュニティは中国語圏にあるため、C3RB3R ランサムウェアの被害件数が最も多く、最も迅速なパターン特定が行われたのもそこでした。

Synology 自体も セキュリティ通知を公開しました 2026年10月29日、同社は、2024年12月に修正された脆弱性を悪用して古いDSMバージョンを攻撃している脅威アクターを特定したと発表し、直ちに更新するよう全員に呼びかけました。

C3RB3Rランサムウェアの侵入経路

最初の2日間は、2つの侵入経路の候補が存在していました。Synologyはその後、旧バージョンの脆弱性であったことを確認しました。10月30日の電子メールによると、攻撃はSynology-SA-24:20で対処された脆弱性のみを悪用しており、C3RB3R ransomwareはPHP2Shellとは何の関係もないとのことです。以下の表には、議論されていた両方の候補を掲載しています。両方の修正を適用する価値が依然としてあるためです。

	Synologyの発表	360 によると
勧告	Synology-SA-24:20 (Pwn2Own 2024)	Synology-SA-26:13
CVE	CVE-2024-10441, CVSS 9.8, システムプラグインデーモンにおける認証なしのリモートコード実行	CVE-2026-13639 (ログインロジック) および CVE-2026-13684 (SCGI)、どちらもCVSS 9.8
修正日	2024年11月〜12月	2026年9月18日
修正済みビルド	DSM 7.2.2-72806 アップデート 1、7.2.1-69057 アップデート 6、7.2-64570 アップデート 4、7.1.1-42962 アップデート 7	DSM 7.4-90075、7.3.2-86009 アップデート 4、7.2.2-72806 アップデート 9、7.2.1-69057 アップデート 12

フォレンジックの証拠は、少なくとも一部の被害者において古いバグを示唆しています。最も詳細なRedditの分析記事では、残されていた自らのログが公開されたCVE-2024-10441エクスプロイトと一致していることを示しつつ、Synologyはそれを確認しておらず、同じマシンがSA-26:13の修正レベル未満であったことにも言及しています。soimyの分析記事によると、感染したゲストのメモリログは、DSMログインプラグインを介した環境変数インジェクションを指し示しており、これはCVE-2024-10441と一致します。また、発生の数日前にログインユーザー名フィールドを悪用する公開概念実証（PoC）がGitHubに登場していました。記録されている3つの救出事例のうち2つは、DS918+ブートローダーを備えた非純正ハードウェア上で動作しており、そのうち1つはDSM 7.2-64570 Update 3で、CVE-2024-10441修正のちょうど1つ前のアップデートでした。クローンハードウェアは公式アップデートを適用しにくいため、このグループの中で最も脆弱な標的となります。

実質的な結論は変わっていません。両方のセキュリティアドバイザリに対応するビルドに更新し、DSMをインターネットに公開するのを停止することです。しかし、1つの疑問が残っていました。もし脆弱性が2024年12月に修正されていたのであれば、なぜ2026年10月の同じ2日間に、最新の状態に保たれていると所有者が信じていた個体を含め、これほど多くの機器でC3RB3R ransomwareが発動したのでしょうか？

早期に仕込まれ、合図とともに起爆

当社の見解（これはSynologyの公式見解ではなく当社の解釈です）は、C3RB3R ransomwareによる侵入と暗号化は2つの別個のイベントであるということです。証拠はそれを指し示しています：

• バックドアが先に来ました。 以下の小紅書（Xiaohongshu）の事例では、単一のファイルが暗号化される前に、バックドアシェルが37日間にわたってNAS上に存在し、root権限でtelnetを有効化していました。
• アップデート後も生き残ります。 以下配下のcronエントリ /etc/cron.d/synot* が自動的に再作成され、少なくとも1件の被害者は、最新のDSMにアップグレードした後もそれらが残っているのを確認しました。アップデートによって脆弱性は塞がれましたが、侵入者は内部に残されたままでした。
• 暗号化の発動は同期されていました。 異なる時期、異なるビルドで侵害されたC3RB3R ransomware被害機器が、お互いにほぼ48時間以内に暗号化を開始しました。

このパターンは、未対策の機器に数ヶ月にわたってC3RB3R ransomwareのインプラントを仕込み、リモートでトリガーを引くタイミングを選択した攻撃者の動きと一致します。彼らが選んだタイミングはPHP2Shellの週であり、すべてのSynology管理者がパッチ適用に追われ、多くの機器がアップデートされたばかりで、所有者が安全だと感じていた時期でした。Synologyは、PHP2Shellが侵入経路ではないことを明確にしています。それはカモフラージュでした。ここから得られる教訓は、未パッチの状態で一度公開された機器は確認されるまで侵害されているとみなす必要があるということであり、これはまさにSynologyのチェックリストのステップ1で求められていることです。

C3RB3Rランサムウェアへの初動対応（4ステップ）

今まさに L0CK3D ファイルを見つけた場合、次の10分間の手順で復旧がそもそも可能かどうか決まります。ファイルの暗号化を解除するライセンスキーは、実行中のC3RB3Rランサムウェアプロセス内にのみ存在します。再起動、 kill -9 またはDSMの再インストールによって、それは破壊されてしまいます。

ステップ2と3のコマンドは次のようになります。バイナリの種類によって詳細が異なるため、何かを実行する前にリポジトリを確認してください。

# Step 2: find the encryptor (its executable shows as deleted)

復号は可能か？GitHubにおける3つの救出事例

汎用的なC3RB3Rランサムウェア復号ツールは存在せず、それを販売している者は単に推測で語っているだけです。実際に存在するのは、どのような場合に復旧が成功するかを正確に示す3つの注意深いケーススタディです。

リポジトリ	マシン	結果	理由
soimy/c3rb3r-rescue	GitLabを実行しているProxmox VE仮想マシン上のDSM	復旧成功	16 GiBのゲストRAMコピーに48バイトのセッションキーが保持されていました。GitLabは80のプロジェクトと9,253のLFSオブジェクトとともに復元されました。
Benjamin-zlt/c3rb3r-baremetal-rescue	ベアメタルのDS918+クローン、DSM 7.2	復旧成功	SIGSTOPで稼働中の暗号化プロセスをフリーズさせ、そのメモリの約2 GBをダンプしました。84,500個のファイル（約940 GB）が2.5時間で復号されました。
lllong1377/c3rb3r-never-rebooted-still-no-key	DS918+クローン、DSM 7.2-64570 Update 3、稼働時間149日	復旧失敗	暗号化プログラムは約30時間前にすでに終了していました。RAMおよびスワップの完全スキャンを行いましたが、キーは見つかりませんでした。

3番目のリポジトリは、そのタイトル自体が教訓となっているため、最も精読すべきものです。「一度も再起動していないからといって復旧可能とは限らない」。重要なのは、C3RB3R ランサムウェアのプロセスがまだ生存しているかどうかです。プロセスが終了すると、キーバッファがゼロ消去され、キーは失われます。また、ある被害者の環境で復元されたキーは、実行ごとに新しいセッションキーが生成されるため、別の被害者の環境では無効です。

なぜキーはメモリ上にしか存在しないのか

Benjamin-zlt による分析では、C3RB3R ランサムウェアのファイルフォーマットが明確に解説されており、なぜこの方法が機能するのか、そしてなぜ通常は機能しないのかの両方が説明されています。

• 各ファイルには独自のランダムな ChaCha8 キーが割り当てられます。 そのキーは AES-256-CBC を使用してセッションマスターキーでラップされ、ファイルの末尾にある 588 バイトのトレーラーに保存されます。
• セッションマスターキーは 48 バイトです： 16 バイトの IV と 32 バイトの AES キーで構成されています。ディスクに書き込まれることは決してありません。実行中のプロセス内にあるグローバルポインタがそれを指し示しています。
• トレーラーには、攻撃者の公開鍵でラップされた blob も含まれています (RSA-2048)。そのため、実行中のプロセスがなければ、攻撃者だけがセッションキーを復元できます。
• すべてのファイルが完全に暗号化されているわけではありません。 400 ファイルのサンプルでは、約 56% がセグメント化モードを使用し、31% は最初の 1 MiB のみが暗号化され、13% は最初から最後まで暗号化されていました。部分的に暗号化されたファイルは依然として読み取れませんが、フッターのトリアージによって何が残っているかが分かります。

したがって、C3RB3R ランサムウェアの弱点は限られており、時間的にも制限されています。暗号化プログラムはセッション全体を通じてマスターキーをメモリ上に保持します。実行中にプロセスをフリーズさせれば、キーを抽出できます。そのタイミングを逃すと、解読不可能な設計になっている公開鍵 blob だけが残されることになります。

被害者のストーリー：50 TB とスナップショットなし

2026年10月29日に Xiaohongshu にユーザー 柯基爱好者 によって投稿された詳細な手記では、NAS グループのメンバーの一人が過ごした一夜を追っています。彼は C3RB3R ランサムウェアの脅迫状に気づき、C3RB3R INSTRUCTIONS ヘッダーを確認して、グループの仲間から GitHub の事例を教えられる直前まで Bitcoin の購入を考えていました。

彼はその後、SSH 経由で AI コーディングアシスタントを使用して調査を行いました。アシスタントは暗号化プログラムを発見してフリーズさせたため、それ以降は新たな暗号化が行われませんでした。また、バックドアシェルと思われるものが 37 日間 NAS 上に潜伏しており、root 権限で telnet を有効にしていたことも判明しました。これは、最初の侵入と暗号化実行が 1 か月以上離れていたことを意味します。アシスタントは証拠収集スクリプトを記述し、正しく root 権限で何かを実行する前に彼の確認を待ちました。

彼の幸運は、C3RB3R ランサムウェアの処理速度が遅かったことです。50 TB 以上のデータを処理する必要があったため、暗号化プログラムは彼の 2024 年の写真にしか到達しておらず、それらはクラウドドライブにコールドコピーが保存されていました。彼は作業データをより小さな NAS に移動し、暗号化されたボリュームを後回しに保留しました。彼自身の総括は率直なものでした。スナップショットをとっておらず、スナップショットがあれば簡単に修復できたはずだというものです。X 上の 2 番目の被害者も、別の角度から同じ教訓をまとめました。RAID 6 に加え、同じ筐体上の 3 つのバックアップセットがすべてまとめて暗号化されてしまったのです。

C3RB3R ランサムウェアをバックアップから遠ざける方法

上記のデータ喪失のストーリーはすべて同じパターンを持っています。侵害されたマシンからバックアップにアクセス可能だったことです。C3RB3R ランサムウェアは、乗っ取られた DSM が書き込み可能なすべてのものを暗号化します。そのため、対策は DSM が一切書き込みできない場所に少なくとも 1 つのコピーを保管することです。これは当社がホストするサイトで実施している方法であり、3-2-1-1-0 ルールに対応しています。

ルール	意味	実施方法
3	データの 3 つのコピー	稼働中の VM、2 台目の NAS 上のレプリカ、および定期的なエクスポート
2	2 種類のメディア	NAS ボリュームに加え、USB ドライブとクラウドドライブ
1	1 つのオフサイトコピー	Cloud Sync を使用して Google Drive に同期されたエクスポート
1	1 つのオフラインまたはイミュータブルコピー	ゲストから操作できないホスト側の VM スナップショット、および未接続の USB エクスポート
0	復元時のエラーゼロ	ホスト間で VM を移動する際、実際にレプリカから復元して起動します

ホスト上ではなく Virtual DSM 内で Docker を実行する

当社の WordPress コンテナは物理 NAS 上では実行されません。これらは Virtual DSM ゲスト内で実行され、そのゲストはホスト上の Virtual Machine Manager によって保護されています。C3RB3R ランサムウェアがゲスト内で root 権限を取得したとしても、制御できるのはそのゲストのみです。ゲストのスナップショットはゲストファイルシステムの外側であるホストストレージ上に存在するため、VM 内のランサムウェアはそれらを認識できず、暗号化や削除はもちろん不可能です。復旧は数分程度で完了するスナップショットロールバックです。

VMM Pro はそれを本物のバックアップに変換する機能を追加します。VM のスナップショットを作成し、クラスタ内の 2 台目の NAS にレプリケートする保護計画により、ホストが停止した場合にも対応できます。当社のクラスタは DS1621xs+ と DS1525+ が相互にレプリケートしています。当社では 定期的なエクスポートおよび Cloud Sync による Google Drive への同期 について別途解説しており、 無料の VMM と VMM Pro の比較 では、どの機能にライセンスが必要かを説明しています。

DSM 上で Docker を直接実行する場合は、不可変（イミュータブル）スナップショットを使用する

すべての人が VM レイヤーを望んでいるわけではありません。コンテナがホスト上で実行されている場合、C3RB3R ランサムウェアに対する防御策は不変スナップショットです。コンテナデータを保持する共有フォルダの Snapshot Replication で有効にしてください。これには DSM 7.2 以降と Btrfs ボリュームが必要であり、ロック期間中は攻撃者に乗っ取られた管理者アカウントであっても削除できません。成否を分ける 2 つの重要なポイントがあります：

• 共有フォルダへのバインドマウントを使用する 例： /volume1/docker/app。Docker の名前付きボリュームは以下に保存されます /volume1/@docker。これは共有フォルダではないため、スナップショットを一切作成できません。
• スナップショットを取得する前に、データベースをファイルにダンプしてください。 稼働中の MariaDB のスナップショットは、突然の電源断時のコピーと同じ状態になります。定期的な mysqldump 同じ共有フォルダーに保存することで、スナップショットによってロックされるクリーンな復元ポイントが作成されます。
• 攻撃者が潜伏できる期間よりも長いロック期間を選択してください。 上記の被害事例では、暗号化が始まる前に37日間にわたってバックドアが存在していました。7日間の不可変スナップショットでは、クリーンな状態まで遡ることはできなかったでしょう。

当社の追加対策：暗号化開始時にActive Insightがスナップショットを撮影

多くのガイドが見落としている対策がここにあります。Synologyのクラウド監視サービスであるActive Insightは、共有フォルダ上のファイルアクティビティを監視でき、ランサムウェアを検出すると自動的に対処します。Synologyはこれを自社の NASセキュリティガイドで説明しています：ランサムウェアイベントが検出されると、Active Insightはイベント通知を送信し、共有フォルダのスナップショットを自動的に撮影します。対応モデルでは、そのスナップショットは変更不可（イミュータブル）になります。

C3RB3R ransomwareにおいて特にこれが重要となる理由：C3RB3R ransomwareの暗号化処理は低速です。50 TB以上のデータを持つ被害者が気づいたとき、まだ2024年の写真の暗号化にとどまっていました。暗号化パターンが最初に検出されたときに撮影されたスナップショットは、まだ変更されていないすべてのデータを保持します。これはボリュームの大部分を保護できる可能性があります。また、C3RB3R ransomwareがどのように侵入したかは関係ありません。ログインページではなくファイルの変更を監視しているためです。当社のDS1621xs+では、ファイルアクティビティページでランサムウェア保護が「保護中」と表示されます。

頼る前に制限事項をご確認ください。これらはSynologyの ファイルアクティビティに関するドキュメント:

• ファイルアクティビティ監視はデフォルトでオフになっています。 コントロールパネルでNASをActive Insightに登録し、Active Insightポータルで各ホストの監視を有効にします。
• Snapshot Replication、 DSM 7.2以降、Active Insight 3.0.2以降、1 GB以上のメモリ、およびそのNASに割り当てられたActive Insightライセンスが必要です。
• 自動スナップショットは共有フォルダーごとに 1 日 1 回まで。 これは検出後に実行されるセーフティネットであり、スケジュールされた変更不可（イミュータブル）スナップショットに代わるものではありません。
• 対象外： Surveillance Station録画フォルダおよび外付けUSBドライブ上の共有フォルダ。
• 変更不可機能（イミュータブル）の利用可否はモデルによって異なります。 変更不可スナップショットをサポートしていないモデルでは、root権限を持つ攻撃者が自動スナップショットを削除できるため、上記の変更不可スケジューリングと組み合わせて使用してください。

同じ環境を構築したいですか？ SynoPower Club では、両方の構成要素の純正ライセンスを販売しています: Virtual DSM (VDSM) ライセンス 隔離されたゲスト環境で Docker サービスを実行するためのライセンスと、 VMM Proライセンス 保護プラン、NAS間レプリケーション、ライブマイグレーション用。ライセンスキーはメールで配信されます。

その他の公式資料の入手先

Synology における C3RB3R ランサムウェアは執筆時点で公表されてから2日しか経っておらず、公式の動画解説もまだないため、このセクションではチュートリアルの代わりに一次情報源を掲載しています。

• Synology セキュリティ通知 2026年10月29日付（古いバージョンのDSMユーザーに対して直ちにアップデートし、自動アップデートを有効にするよう促す内容）、続いて10月30日にはSA-24:20のみが関連する脆弱性であることを確認するカスタマーメールが送信されました。
• Synology-SA-24:20 そして Synology-SA-26:13 はバージョン一覧表です。コントロールパネルの「更新と復元」でビルドを確認し、両方と照合してください。
• lllong1377/c3rb3r-never-rebooted-still-no-key は、ここで扱っていない事例も含め、既知のすべての事例を網羅した最高のインデックスであり、メモリフォレンジックが無意味になるタイミングを最も分かりやすく説明しています。
• 上記でリンクした3つの r/synology スレッド、特に読み取り専用ディスク調査コマンドが順を追って記載されているフォレンジック解説文章: ついに起きてしまった.

Synology独自のチェックリスト（2026年10月30日）

Synologyが顧客に送信したメールは4つの手順で締めくくられています。これらは簡潔ですが、いずれもC3RB3Rランサムウェア対策において極めて重要です。

1. 侵入者の確認。 C3RB3Rランサムウェアは永続化のためのタスクを残すため、Security Advisorのスキャンを実行し、タスク スケジューラーで作成した覚えのないスクリプトがないか、ユーザーとグループで追加した覚えのない管理者アカウントがないか確認してください。異変が見つかった場合は、Synologyサポートにお問い合わせください。
2. すべてを更新する。 コントロール パネルの [更新と復元] で最新のDSMをインストールし、パッケージ センターですべてのパッケージを更新してください。
3. 自動更新を有効にする [更新と復元] で設定することで、今後のセキュリティ修正プログラムがリリース後すぐに適用されるようにします。
4. オフサイトバックアップを保持する。 Hyper BackupとSnapshot Replicationを使用して別の場所にコピーを保持し、バックアップタスクが実際に正常完了しているか定期的に確認してください。

手順1は見落とされがちです。2024年12月の修正前にNASがインターネットからアクセス可能だった場合、C3RB3Rランサムウェアがすでに侵入足がかりを構築している可能性があり、今日アップデートしても誰かがすでに侵入しているかどうかはわかりません。

チェックを代わりに自動実行する無料ツール

ターミナルの操作に慣れている場合、ステップ1は1つのコマンドで完了できます。synology-nas-cli は、個人開発者の Akari Sora 氏が2026年10月30日に公開した MIT ライセンスのオープンソース・コマンドラインツールです。Web API を介して DSM にサインインし、このキャンペーンに対する NAS の状況を監査します。プロジェクトは GitHub で公開されています： akari-sora/synology-nas-cli.

リンクを掲載する前に、コードを一通り確認しました。Python 標準ライブラリのみを使用しており、お使いの NAS、Synology ダウンロードサーバー、PyPI、soimy レスキューツールキット以外とは一切通信しません。テレメトリは送信されず、基本的な監査は読み取りのみを行います。チェック内容は以下の通りです：

• パッチレベル。 Synology-SA-26:13（古い SA-24:20 の修正も含む）に対する DSM のビルド、および SA-26:14 に対するインストール済みパッケージ。
• 露出状況（公開設定）。 QuickConnect、ルーターの UPnP ポート転送、DSM ファイアウォール、自動ブロック、SMB1、および組み込みの admin アカウント。
• C3RB3R ランサムウェアの形跡。 接続ログに挿入されたログイン文字列、 /etc/cron.d/synot* エントリ、 libgld そして qnetd バイナリ、追加された root アカウント、SSH キー、共有フォルダ内の身代金要求メモ（ランサムノート）。
• スナップショット。 正常に機能するスナップショットスケジュールがない共有フォルダ。

検出された問題のほとんどを修復することも可能です。現在ファイルが暗号化されている最中の場合、contain コマンドが SIGSTOP で暗号化プロセスをフリーズさせます。これは当社の初期対応リストのステップ2と同じ手順です。その後、rescue コマンドが soimy ツールキットを実行してメモリをキャプチャし、ライセンスキーを検索します。

nas incident                 # 読み取り専用の監査

nas incident --deep # インプラントの検索も実行（読み取り専用の root スクリプト1つ）

• nas incident fix --dry-run # 変更予定をすべてリスト表示し、実際には変更しない 変更を実行する前に、以下の注意事項をお読みください：
• 公開されたばかりのツールです。 このプロジェクトは公開されて数日しか経っておらず、単一の個人開発者によるもので、Synology とは提携しておらず、外部からのレビューもあまり受けていません。まずは読み取り専用の監査と dry run から始めてください。
• ファイアウォールの修復によりロックアウトされる可能性があります。 DSM ファイアウォールを指定したネットワーク以外すべて拒否に切り替えます。同じ LAN 上のコンピュータから実行し、RESET ボタンの位置を確認しておいてください。
• QuickConnect をオフにします。 これはより安全な設定ですが、ご家族が QuickConnect 経由で Synology Photos や Surveillance Station にアクセスしている場合は、事前に VPN または Tailscale を設定してください。
• ディープスキャン、contain、rescue は root 権限で実行されます。 これらは root 専用ログの読み取りやプロセスのフリーズを行う唯一の方法であるため、一時的なタスク スケジューラのタスクを通じて動作します。
• README では AI エージェントに任せることを提案しています。 その場合は、パスワードをチャット内ではなくパスワードマネージャーで保管し、修復内容をご自身で確認してください。

セキュリティ強化のその他の全体像については、以下のガイドを参照してください: Synology NAS で公開ウェブサイトを運用する方法 および Threat Prevention で検知できるものとできないもの でネットワーク側をカバーしており、 PHP2Shell パッチ適用ガイド で同じ週に発生したもう1つの重大な問題をカバーしています。

C3RB3R ランサムウェアの制限事項とセキュリティ上の注意

アップデートを行っても、既存の感染は削除されません。 少なくとも1名の被害者が、最新の DSM にアップグレードした後も cron の永続化設定が残っていることを確認しました。パッチ未適用の状態で露出していた場合は、以下を確認してください: /etc/cron.d、タスク スケジューラー、スタートアップ スクリプト、および telnet などの有効化されたサービスを確認し、すべての資格情報を変更してください。

最新であることと、クリーンであることは同義ではありません。 Redditの被害者の中にはDSMが最新であると信じていた人や、2要素認証（2FA）と強力なパスワードを設定していたにもかかわらず被害に遭った人もいます。パッチ適用前に侵害された機器は、その後のすべての更新を行ってもインプラントが残り続ける可能性があります。意図的に設定していないUPnPによって公開されたものも含め、インターネットからアクセス可能なすべてのDSMログインページを攻撃目標として扱ってください。リモートアクセスにはVPNまたはTailscaleを使用し、ルーターのUPnPをオフにしてください。

RAID やローカルバックアップは、C3RB3R ランサムウェアに対するバックアップにはなりません。 侵害された DSM が書き込み可能なものは、同一機器内の Hyper Backup のバックアップ先やマウントされたネットワーク共有を含め、すべて暗号化されます。

事例を読む前に身代金を支払わないでください。 C3RB3R ランサムウェアの攻撃者に身代金を支払うことは次の攻撃の資金源となり、何も保証されません。暗号化プログラムがまだ実行中の場合は、メモリ解析（free memory）ルートが最も有効な手立てです。実行されていない場合、現実的な手段は自身で保持している外部のバックアップコピーのみです。

AI アシスタントに貼り付ける内容に注意してください。 ここでは AI ツールが複数の被害者を助けましたが、パスワード、復元されたキー、フルメモリダンプ、ビジネスデータを AI に渡さないでください。コマンドの提案のみを行わせ、root 権限が必要な実行はすべて自分で行ってください。

クローンハードウェアにはさらなるリスクが伴います。 記録された複数の被害者は、公式アップデートの適用が困難または不可能な非純正ハードウェアで DSM を実行していました。そのような環境の場合は、パッチが適用されていないものとみなし、インターネットから完全に切断してください。

参考文献

• DSM ランサムウェア攻撃に関する Synology セキュリティ通知（2026年10月29日）
• Synology-SA-24:20 DSM (Pwn2Own 2024)、CVE-2024-10441 および修正済み DSM ビルド。
• Synology-SA-26:13 DSM、CVE-2026-13639 および CVE-2026-13684（2026年9月18日公開）。
• Benjamin-zlt による C3RB3R ランサムウェアのベアメタルレスキュー、ファイルフォーマット、キーレイアウト、SIGSTOP ワークフロー。
• メモリレスキューは、暗号化プロセスが稼働している間のみ機能します。GitHub の3つの事例と同じルールが適用されます。
• C3RB3R キャンペーンに関する IT-Connect の解説、360 による帰属分析とタイムラインの要約。
• Synology ナレッジセンター：Synology NASのセキュリティを強化する（Active Insightがランサムウェアを検知した際に共有フォルダのスナップショットを取得する方法を含みます）。

よくある質問

次のC3RB3Rランサムウェア攻撃を受けた際の被害を、身代金ではなく「リストア作業」だけで済むようにしましょう。 Virtual DSM内でDockerサービスを実行し、VMM Pro保護プランによってゲスト全体を保護し、2台目のNASへレプリケートします。SynoPower Clubでは両方の正規ライセンスを販売しており、ライセンスキーはメールで納品されます。