--- title: "アンビションDXのランサムウェア被害：58万件の対象確認と窓口、再発防止策の実装手順" url: "https://www.issoh.co.jp/tech/details/18765/" published: 2026-10-22 updated: 2026-10-22 categories: ["セキュリティ"] publisher: "株式会社一創" --- # アンビションDXのランサムウェア被害：58万件の対象確認と窓口、再発防止策の実装手順 不動産事業を営むアンビションDXホールディングス（東証グロース・3300）は、2026年10月20日に、8月に受けたランサムウェア攻撃を含む不正アクセスの最終報を公表しました。攻撃者が持ち出したと確認されたファイルは約14万件、漏えいのおそれがある個人情報は約58万件です。子会社のホープ少額短期保険では、保険金の受取口座を含む情報も特定されました。本記事では第1報から最終報までの4本の適時開示を並べ、入居者や保険契約者が確かめるべき点を先に答えます。後半は、最終報が挙げた再発防止策のうち、ネットワーク機器の管理画面、認証基盤、ログ、共有フォルダの権限を点検する手順をコマンド付きで示します。 ## まとめ：アンビションDX最終報で確定した事実と入居者・保険契約者が今確かめる点 [最終報](https://www2.jpx.co.jp/disc/33000/140120261020553634.pdf)によると、2026年8月6日未明に第三者が社内ネットワークへ侵入し、同社とグループ会社のサーバーや端末に保管された業務文書を持ち出したうえで、ランサムウェアによる攻撃を行ったと推定されています。侵入の経路は同社のネットワーク機器と推定され、攻撃手法の詳細は捜査への影響を考えて公表されていません。 入居者、物件オーナー、保険契約者が今確かめたい点は3つです。まず、同社やグループ会社が電子メールや電話だけで振込先の変更、支払い、IDやパスワード、口座番号の入力を求めることは一切ないと公式に明記されています。次に、問い合わせ先は最終報に記載された個人情報保護管理の窓口（0120-827-826、受付10時〜18時）です。最後に、クレジットカード情報とマイナンバーは精査の範囲で確認されていません。 | 項目 | 内容 | 根拠 | | ---------- | ------------- | ------- | | 侵入と検知 | 2026年8月6日未明 | 第1報・最終報 | | 侵入の経路 | ネットワーク機器経由と推定 | 最終報 | | 持ち出し確認 | ファイル約14万件 | 最終報 | | 漏えいのおそれ | 個人情報約58万件 | 最終報 | | カード・マイナンバー | 確認されていない | 最終報 | | 二次被害 | 10月20日時点で確認なし | 最終報 | ## 第1報から最終報までの時系列｜8月6日未明の侵入検知から10月20日の調査結果 ### ログ消失の確認から「持ち出しの形跡なし」が覆るまでの調査の3週間 同社は4回に分けて公表しています。日付と時点を並べると、調査の進み方と評価の変化が分かります。 | 公表日 | 主な内容 | 出典 | | ------ | -------------- | --- | | 8月6日 | アクセス障害とログ消失を確認 | 第1報 | | 8月7日 | 新ネットワークへ切替完了 | 第2報 | | 8月28日 | 一部の情報資産で漏えい確認 | 第3報 | | 10月20日 | 件数・原因・再発防止策 | 最終報 | [第1報](https://ssl4.eir-parts.net/doc/3300/tdnet/2865813/00.pdf)は、8月6日未明にファイルサーバーでアクセス障害が起き、確認するとログが消されていたと説明しています。同社はすぐにネットワークを外部から遮断し、社長を本部長とする緊急対策本部を設けて外部のフォレンジック専門機関に調査を依頼しました。翌日の[第2報](https://www2.jpx.co.jp/disc/33000/140120260807515802.pdf)では、アクセスを試みた痕跡はあるものの、データが外部へ持ち出された形跡は確認されていないとしていました。 この評価は3週間後に覆ります。[第3報](https://www2.jpx.co.jp/disc/33000/140120260828527812.pdf)は一部の情報資産で漏えいを確認したとし、個人情報保護法第26条第1項に基づいて個人情報保護委員会へ報告したと記しました。初動の「形跡なし」は、ログが消された状態での暫定評価にすぎなかったことになります。報告の期限と対象は[個人情報保護委員会への報告義務](https://www.issoh.co.jp/column/details/17840/)で整理しています。 ### 警察庁の統計と重なる「窃取してから暗号化し痕跡を消す」攻撃の流れ [警察庁の令和8年上半期の報告](https://www.npa.go.jp/publications/statistics/cybersecurity/data/R8kami/R08%5Fkami%5Fcyber%5Fjousei.pdf)は、被害組織へのアンケートで侵入経路の約5割がVPN機器だったとしています。攻撃者は内部を探索してデータを窃取し、その後に暗号化を実行し、最後にログや使用したツールの痕跡を消す、という流れも示されています。 本件の公表内容は、この流れとよく重なります。ネットワーク機器からの侵入、業務文書の持ち出し、ランサムウェアの実行、そしてログの消失です。機器の種類やメーカーは公表されていないため、VPN機器だったとは断定できません。それでも、外部に開いた機器を入口にした典型例として読む価値はあります。 ## 漏えいした情報の中身｜ホープ少額短期保険の口座情報833件と賃貸契約の入居審査資料 ### 区分Aのファイル約14万件と区分Bの個人情報約58万件の違い 最終報は件数を2つの区分で示しています。区分Aは、攻撃者が実際に外部へ持ち出したと確認された情報で、ファイル約14万件です。区分Bは、持ち出された可能性を否定できない範囲に保管されていた情報で、公開の有無にかかわらず漏えいのおそれがあるものとして扱う個人情報約58万件です。 単位が違う点に注意が必要です。14万は「ファイルの数」、58万は「個人情報の件数」で、58万人分が持ち出されたと確定したわけではありません。報道の見出しでは両者が混ざりやすいので、自分が対象かどうかは件数ではなく、同社からの個別の連絡と窓口で確かめるのが確実です。 ### 区分Aの精査で特定された3社分の個人情報と対象者別に含まれる項目 | 会社 | 情報の種類 | 件数 | | -------------- | ---------- | ---- | | ホープ少額短期保険 | 保険金の支払い | 833件 | | ホープ少額短期保険 | 保険契約（顧客管理） | 363件 | | ホープ少額短期保険 | 解約契約 | 465件 | | アンビション・エージェンシー | 契約書・入居審査資料 | 449件 | | アンビションDX | 賃貸借契約 | 2件 | 保険金の支払いに関する833件には、証券番号と契約者氏名に加え、保険金受取人の金融機関名、支店名、口座番号、口座名義が含まれます。保険契約の363件は氏名、住所、電話番号、メールアドレス、生年月日などです。アンビション・エージェンシーの449件は契約者と入居者の氏名、住所、連絡先、勤務先などで、同社本体の2件には年収や転居理由、緊急連絡先まで含まれていました。 ## 届いた連絡が本物か見分ける基準｜振込先変更と口座番号入力を求める連絡は偽物 ### 公式が「一切ない」と明記した4種類の依頼と公式窓口への確認手順 最終報は、同社とグループ会社が電子メールまたは電話だけで次の依頼をすることは一切ないと書いています。賃料や保険料の振込先の変更、金銭の支払い、ID・パスワード・暗証番号の入力、口座番号の入力です。この4つのどれかを求める連絡は、差出人の名前が本物に見えても偽物と判断して構いません。 不審な連絡を受けたら、記載されたURLを開かず、電話番号にも折り返さず、個人情報を入力しないでください。確認は、最終報に載っている個人情報保護管理の窓口（0120-827-826、10時〜18時）へ自分から電話する形で行います。メールや郵便物に書かれた番号ではなく、公式発表の番号を使えば、偽の窓口へ誘導されるのを避けられます。 ### 保険金の受取口座が含まれていた契約者が通帳や取引明細で確かめる点 最終報は、二次被害は10月20日時点で確認していないとしたうえで、金融機関を装った連絡や口座の不正利用が起きる可能性は否定できないと認めています。保険金を受け取ったことがあるホープ少額短期保険の契約者は、通帳や取引明細に心当たりのない入出金がないかを確かめてください。気になる動きがあれば、まず口座のある金融機関に相談します。 口座番号や名義を知っているという事実だけで、連絡の相手を信用しないことも大切です。漏えいした情報を使えば、本物の契約内容を言い当てる偽の電話を作れてしまいます。 ## ネットワーク機器経由の侵入｜管理画面を外部に出していないかnmapで外から確かめる手順 ### 自社のグローバルIPに対し管理用ポートが開いていないか走査するコマンド 最終報の再発防止策の筆頭は「外部接続の見直し」で、機器の更新、接続方式の見直し、管理画面への接続元制限、多要素認証の必須化が並んでいます。まず確かめたいのは、ルーターやファイアウォール、VPN機器の管理画面がインターネットから開ける状態になっていないかです。社内からの点検では見落とすため、社外の回線から自社のグローバルIPに対して走査します。 次は[Nmapのポート指定](https://nmap.org/book/man-port-specification.html)で、管理画面やSSL-VPNでよく使われるポートに絞って確かめる例です。走査してよいのは自社が契約しているIPだけで、クラウドやデータセンターの規約で事前申請が要る場合もあります。 ``` # 社外の回線から実行する。対象は自社のグローバルIPだけに限る # -Pn: ping応答が無くても走査する ／ -p: 確かめるポートを絞る nmap -Pn -p 22,23,80,443,4443,8443,10443 203.0.113.8/29 -oN mgmt_ports.txt # open になったポートは、ブラウザで開いて何の画面が出るかを確かめる grep "open" mgmt_ports.txt ``` 443番が開いていること自体は、SSL-VPNやWebサイトを公開していれば当然です。問題は、そのポートで機器の管理ログイン画面まで表示される場合です。表示されたら、管理画面は社内の管理用セグメントか特定の接続元IPからだけ開けるように機器側で制限します。機器の版を確かめて既知の脆弱性と照合する手順は、[VPN 脆弱性：機器の版確認コマンドとKEV照合スクリプト](https://www.issoh.co.jp/tech/details/18740/)で解説しています。 ## 認証基盤の資格情報リセット｜krbtgtの2回リセットと管理者グループの棚卸し ### krbtgtの最終変更日と管理者グループの実メンバーを一覧にするPowerShell 最終報は認証情報の刷新として、アカウントの再作成、全役職員と管理者のパスワード一斉変更、認証基盤の資格情報のリセットを挙げています。どの製品の認証基盤かは公表されていませんが、Active Directoryを使う組織なら、Kerberosの鍵を握るkrbtgtアカウントのリセットがこれに当たります。まずは最終変更日と管理者の一覧で現状を確かめてください。 ``` # ActiveDirectory モジュールで実行する（読み取りのみ） Import-Module ActiveDirectory # krbtgt の最終変更日。何年も前なら、侵入前の鍵がそのまま残っている Get-ADUser krbtgt -Properties PasswordLastSet, msDS-KeyVersionNumber | Select-Object Name, PasswordLastSet, msDS-KeyVersionNumber # 管理者グループの実メンバー（入れ子のグループも展開）と最終ログオン日 "Domain Admins", "Enterprise Admins", "Administrators" | ForEach-Object { $g = $_ Get-ADGroupMember -Identity $g -Recursive | Where-Object objectClass -eq 'user' | Get-ADUser -Properties Enabled, LastLogonDate, PasswordLastSet | Select-Object @{n='Group'; e={ $g }}, SamAccountName, Enabled, LastLogonDate, PasswordLastSet } | Export-Csv .\admin_members.csv -NoTypeInformation -Encoding UTF8 ``` 一覧に、退職者、委託先の担当者、用途の分からないサービスアカウントが管理者グループに残っていないかを確かめます。最終報の「管理者権限の利用制限」は、この人数を減らすことから始まります。委託先のアカウントをVPNとADから洗い出す例は[両毛システムズのランサムウェア被害](https://www.issoh.co.jp/tech/details/18211/)で示しました。 ### krbtgtは10時間以上空けて2回リセットする理由と実施を見送る場面 [Microsoftの手順書](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-reset-the-krbtgt-password)は、krbtgtのパスワードを2回リセットし、その間を10時間空けるよう求めています。krbtgtはパスワード履歴を2世代持つため、1回だけでは古い鍵が残るからです。10時間はチケットの最大有効期間の既定値で、ポリシーで延ばしている場合はその値より長く空けます。 攻撃者が管理者権限を握った形跡がある、またはその可能性を否定できない場合は、2回のリセットを必ず実施します。一方、侵入した端末がまだネットワークに残っている段階で行っても、攻撃者は新しい鍵を再び盗めます。侵害機器の隔離と再構築を終えてから行うと決めてください。管理者アカウントに多要素認証を必須にする方式の選び方は[多要素認証（MFA）とは](https://www.issoh.co.jp/tech/details/13314/)で比べています。 ## ログ消失への備え｜セキュリティログ消去の検知とイベントログを別サーバーへ転送する設定 ### イベントID 1102と104でログ消去の痕跡を探しログ上限を広げるコマンド 本件は第1報の段階で「ログが消失されている」と報告されていました。痕跡を消されると、調査で侵入の時期や範囲を確定するまでに時間がかかります。Windowsでは、セキュリティログが消去されるとイベントID 1102が、ほかのログの消去では104が記録されます。 ``` # 1. ログ消去（1102）とイベントログサービスの停止（1100）を探す Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 1102, 1100 } -ErrorAction SilentlyContinue | Select-Object TimeCreated, Id, MachineName # 2. セキュリティ以外のログの消去（104）を探す Get-WinEvent -FilterHashtable @{ LogName = 'System'; Id = 104 } -ErrorAction SilentlyContinue | Select-Object TimeCreated, Id, MachineName # 3. セキュリティログの上限を1GBに広げ、上書きで古い記録が消えるまでの期間を延ばす（管理者権限） wevtutil sl Security /ms:1073741824 ``` 1102が見つかっても、管理者が正当な理由で消した場合もあります。日時と実行したアカウントを、作業記録と突き合わせてください。ログの見方そのものは[不正アクセスの調べ方](https://www.issoh.co.jp/tech/details/2788/)でまとめています。 ### 端末内のログは消される前提でWindows Event Forwardingへ送る判断 端末の中にしかないログは、管理者権限を奪われれば消されます。[Windows Event Forwardingの解説](https://learn.microsoft.com/en-us/windows/security/operating-system-security/device-management/use-windows-event-forwarding-to-assist-in-intrusion-detection)によると、WEFは選んだイベントを収集サーバー（WEC）へ転送し、収集サーバーとつながらない間のバッファは端末のログです。配送設定の「Minimize latency」は30秒単位で送るため、消される前に記録を外へ逃がせます。 Microsoftが示す基本の購読には、1102と1100、104がすでに含まれています。サーバーが10台を超える組織、または夜間に監視する人がいない組織は転送を入れるべきです。収集サーバーは同じドメインの管理者が消せない場所に置き、侵害されたときに一緒に消されない構成にします。 ## フォルダ権限の最小化と再発防止策の優先順位｜Everyone共有の洗い出しと着手の順番 ### 誰でも読める共有フォルダをGet-SmbShareAccessで洗い出すコマンド 最終報は、機密情報や個人情報を含むフォルダのアクセス権限を最小化するとしています。業務文書が大量に持ち出されたのは、侵入したアカウントから多くのフォルダが読めたためと考えるのが自然です。[Get-SmbShareAccess](https://learn.microsoft.com/en-us/powershell/module/smbshare/get-smbshareaccess)を使い、ファイルサーバーで全員に開いた共有を探します。 ``` # ファイルサーバー上で実行する（読み取りのみ）。管理用の既定共有（C$ など）は除く Get-SmbShare | Where-Object { -not $_.Special } | ForEach-Object { Get-SmbShareAccess -Name $_.Name } | Where-Object { $_.AccessControlType -eq 'Allow' -and $_.AccountName -match 'Everyone|Authenticated Users|Domain Users' } | Select-Object Name, AccountName, AccessRight | Format-Table -AutoSize ``` ここで出るのは共有のアクセス許可だけで、フォルダごとのNTFSアクセス許可は別に確かめる必要があります。個人情報を含む共有が出てきたら、部署のグループに絞り、閲覧が要らない人を外します。 ### 最終報の8区分の施策から中小規模の組織が先に着手する3つの対策 最終報は外部接続、監視、認証情報、システム再構築、アクセス管理、ネットワーク、管理体制、教育の8区分を挙げています。すべてを同時に進める予算がない組織は、入口、権限、記録の順に着手します。具体的には、管理画面の接続元制限と多要素認証、管理者と共有フォルダの権限の絞り込み、ログの外部転送です。 EDRの導入範囲の拡大やネットワークの分離は効果が大きい反面、設計と運用の両方に人手が必要です。監視する担当者を置けないならEDRは外部の監視サービスと組み合わせ、置けるなら自社で運用すると決めます。EDRの仕組みは[EDRとは](https://www.issoh.co.jp/tech/details/13303/)、暗号化されても戻せるバックアップは[イミュータブルバックアップとは](https://www.issoh.co.jp/tech/details/18742/)、接続ごとに検証する考え方は[ゼロトラストとは](https://www.issoh.co.jp/column/details/13096/)で解説しています。 自社のネットワーク機器や公開サーバーのどこが外から見えているかを社内だけで説明できない場合は、第三者の点検を入れる時期です。[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)では、外部に公開している機器やWebシステムから社内のサーバーに至る経路を含めて確かめられます。 ## よくある質問 アンビションDXホールディングスの不正アクセスについて、入居者、保険契約者、情報システムの担当者から出やすい質問をまとめました。 ### アンビションDXやホープ少額短期保険を名乗る連絡は本物ですか？ 振込先の変更、支払い、ID・パスワード・暗証番号・口座番号の入力を求める連絡であれば、偽物と考えてください。最終報は、同社とグループ会社が電子メールや電話だけでこれらを依頼することは一切ないと明記しています。判断に迷う連絡は、記載のURLや電話番号を使わず、最終報に載っている窓口（0120-827-826、10時〜18時）へ自分から問い合わせて確かめます。 ### 自分の情報が漏えいしたかどうかはどうすれば分かりますか？ 同社は8月28日の第3報で、漏えいした情報の範囲を特定し、確定しだい対象者へ個別に連絡するとしていました。10月20日の最終報も、対象者への対応を続けると書いています。連絡が来ていない場合や内容を確かめたい場合は、個人情報保護管理の窓口に問い合わせてください。報道の58万件は漏えいのおそれがある範囲の件数で、全員分の持ち出しが確定した数字ではありません。 ### 保険金の受取口座が漏えいした場合、口座を変える必要はありますか？ 最終報には、口座の変更を求める記載はありません。ホープ少額短期保険の保険金支払い833件には受取人の金融機関名、支店名、口座番号、口座名義が含まれており、同社は口座の不正利用が起きる可能性は否定できないとしています。通帳や取引明細に心当たりのない動きがないかを確かめ、気になる点があれば口座のある金融機関に相談してください。 ### クレジットカード情報やマイナンバーは漏えいしましたか？ 最終報は、これまでの精査でクレジットカード情報とマイナンバー（個人番号）は確認されていないとしています。特定された情報は、氏名、住所、電話番号、メールアドレス、生年月日、勤務先、証券番号、保険金の受取口座などです。同社本体の賃貸借契約2件には、年収や転居理由、同居人と緊急連絡先の情報も含まれていました。 ### 攻撃者が437GBのデータを盗んだという情報は本当ですか？ 一部の情報サイトが、リークサイト上で攻撃者側が437GBを取得したと主張していると伝えています。ただし同社の公式発表は、件数をファイル約14万件と個人情報約58万件で示しており、データ量や攻撃者の名前は記載していません。2026年10月22日時点で、437GBという数字は公式に確認できない情報として扱うのが妥当です。 ## 関連記事 - [VPN 脆弱性：機器の版確認コマンドとKEV照合スクリプト・パッチと移行の判断【2026年10月】](https://www.issoh.co.jp/tech/details/18740/)：ネットワーク機器の入口を版とKEVで点検する手順 - [両毛システムズのランサムウェア被害：VPNアカウント悪用と委託元に残ったファイルの点検](https://www.issoh.co.jp/tech/details/18211/)：VPNアカウントが悪用された事案 - [大阪公立大学のランサムウェア被害：原因・復旧状況と臨時サイト、仮想化基盤のバックアップを守る設定](https://www.issoh.co.jp/tech/details/18178/)：暗号化からの復旧とバックアップの守り方 - [API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効](https://www.issoh.co.jp/tech/details/18346/)：盗まれた認証情報を失効させる実装 - [個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務](https://www.issoh.co.jp/column/details/17840/)：漏えいのおそれがあるときの報告の期限 --- 出典: [アンビションDXのランサムウェア被害：58万件の対象確認と窓口、再発防止策の実装手順]()（株式会社一創）