ServiceNowは、ITサービス管理、インシデント管理、CMDB、HR、SecOps、GRCなど幅広い業務データを扱うため、侵害された場合の影響が大きいプラットフォームです。管理者情報や業務チケットだけでなく、構成情報、ユーザー情報、添付ファイル、外部システムとの統合情報などが集約されている環境も少なくありません。

一方で、ServiceNowを狙う攻撃は、単純なアカウント乗っ取りだけではありません。未認証でのリモートコード実行、Service PortalやAPI経由の情報露出、Guest権限の設定不備、低権限ユーザーによるデータ列挙、既知脆弱性が残る環境へのスキャンなど、複数の攻撃面があります。

とくに重要なのは、「最新パッチを適用しているから安全」「Portalを非公開にしたから安全」とは限らず、Platform・Exposure・Dataの3層を分けて確認する必要があるという点です。

そこで本記事では、ServiceNowを狙うサイバー攻撃の代表例、未認証RCEやGuest公開のリスク、ACL設計で注意すべきポイント、優先して実施すべき対策、ログから確認すべき侵害兆候について解説します。

ServiceNowを狙う主なサイバー攻撃

未認証RCEを狙う攻撃

ServiceNowでは、認証前の利用者からコード実行につながり得る重大な脆弱性が問題になることがあります。

未認証RCEが成立すると、攻撃者は正規アカウントを持っていなくても、脆弱なインスタンスやコンポーネントへ細工したリクエストを送り、サーバー側で任意コードを実行できる可能性があります。

その後、機微ファイルの取得、データベースアクセス、認証情報窃取、追加の永続化などへ発展するおそれがあります。

既知脆弱性が残る環境へのスキャン

重大脆弱性が公開されると、攻撃者がインターネット上のServiceNow関連環境を探索し、修正されていないインスタンスを狙う可能性があります。

とくに、セルフホスト、特殊なパッチ運用、パートナー管理などの環境では、ベンダー側の自動対応がそのまま適用されるとは限りません。

対象ファミリー、Patch、Hot Fix、ホスト形態を把握し、脆弱性ごとの影響対象と照合する必要があります。

Service Portal・Guest公開面からのデータ列挙

ServiceNowでは、「認証画面を突破されたか」だけを見るのでは不十分です。

Service Portalや検索機能、Guestアクセス、API、Widgetなどが認証なしで利用できる場合、攻撃者が公開面からテーブルやレコードを列挙できる可能性があります。

画面上では情報が表示されなくても、APIレスポンスやバックエンド処理にデータが含まれているケースがあるため、Guestセッションで実際のHTTP応答まで確認することが重要です。

低権限ユーザーによるテーブルアクセス

認証済みユーザーであっても、本来アクセスすべきでないテーブル・レコード・フィールドまで参照できる設定が残っていると、内部者や侵害済みアカウントから情報を列挙される可能性があります。

とくに次のような領域は重点的に確認します。

• CMDB
• インシデント
• リクエスト
• HR
• SecOps
• GRC
• 統合用の中間テーブル
• 添付ファイル

テーブルACLだけでなく、レコードACL、フィールドACL、スクリプト経由の代理アクセスも含めて実効権限を確認する必要があります。

管理者・OAuth・統合資格情報の悪用

ServiceNowは外部システムと連携することが多く、OAuthクライアント、MID Server、APIキー、サービスアカウントなどの資格情報も攻撃対象になります。

攻撃者がこれらを取得すると、通常のUIログインを使わずにデータへアクセスしたり、外部システムへの横展開に利用したりする可能性があります。

ServiceNowで注目すべき主な攻撃事例

これらの事例から分かるのは、ServiceNowのリスクが「ソフトウェア脆弱性」だけに限定されないことです。

最新パッチが適用されていても、Guest公開、検索API、ACL、カスタムWidgetなどが適切に管理されていなければ、情報漏えいの入口が残る可能性があります。

ServiceNowで攻撃者が狙いやすいポイント

未パッチのセルフホスト環境

ServiceNowホスト環境と異なり、セルフホストや特殊な運用環境では、修正適用状況を利用組織側で個別に確認する必要があります。

脆弱性の公表後は、「対象リリースか」「Hot Fixが必要か」「現在のPatchで修正済みか」を明確にしてください。

Service PortalとGuestユーザー

Service Portalでは、ログインなしで利用可能なページやWidgetが存在する場合があります。

問題になるのは、画面上の見え方ではなく、Guestユーザーの実効権限です。

Portal自体を非公開にしていても、バックエンドAPI、検索、Widget処理などを経由してデータへ到達できる可能性を確認する必要があります。

公開API・Scripted REST API

カスタムREST APIやScripted REST APIがインターネットから到達可能な場合、認証設定やレスポンス制御が不十分だとデータ露出につながります。

認証必須であることだけでなく、認証後のロール・データ範囲まで確認してください。

カスタムWidget・UI Page

カスタムWidgetやUI Pageでは、スクリプト内でGlideRecordなどを利用してデータを取得する場合があります。

画面表示側で制限していても、バックエンドロジックが過剰なデータを返していれば、直接リクエストから取得される可能性があります。

テーブル・レコード・フィールドACL

ACLはServiceNowのデータアクセス制御の中心です。

ただし、テーブルレベルだけを確認しても不十分で、レコードやフィールドごとのアクセス、スクリプト条件、継承関係まで確認する必要があります。

MID Server・外部統合

MID Serverは社内システムとの橋渡しになるため、侵害されるとServiceNowだけでなく内部ネットワークへの影響につながる可能性があります。

資格情報、接続先、実行権限、通信元・通信先を定期的に確認してください。

ServiceNowのサイバー攻撃対策で優先すべきこと

重大脆弱性の修正状況を確認する

まず、現在利用しているServiceNowのファミリー、Patch、Hot Fix、ホスト形態を確定します。

そのうえで、CVE-2026-6875、CVE-2026-0542、CVE-2024-4879、CVE-2024-5178、CVE-2024-5217など、利用環境に影響する脆弱性の修正状況を照合します。

外部公開面を棚卸しする

インターネットから到達可能なServiceNow関連資産を洗い出します。

• Service Portal
• カスタムREST API
• Scripted REST API
• UI Page
• Widget
• 外部統合エンドポイント
• MID Server関連の接続点

「公開した覚えがない」ではなく、外部から実際に到達できるかを確認してください。

Guestユーザーの実効権限を検証する

Guest状態でページを開くだけでなく、APIや検索、添付、Widgetバックエンドへのアクセスも確認します。

「ブラウザ画面に見えない」ではなく、「HTTPレスポンスに機微データが含まれていない」ことまで確認するのが重要です。

ACLをデータ単位で再評価する

テーブル、レコード、フィールドの各ACLについて、Guest、一般ユーザー、委託先、低権限ロールなどの実効アクセスを確認します。

カスタムScript Include、Business Rule、Flow、Integration Hubなど、代理でデータアクセスする処理も確認対象です。

管理者認証と統合資格情報を強化する

管理者にはフィッシング耐性の高いMFAを設定し、通常業務アカウントと特権アカウントを分離します。

また、次の認証情報を棚卸しします。

• SSOアカウント
• サービスアカウント
• OAuthトークン
• APIキー
• MID Server資格情報
• Integration Hubの認証情報

ログを侵害仮説でレビューする

単にエラー数を見るのではなく、「攻撃者がデータを列挙した」「管理設定を変更した」という仮説を立ててログを確認します。

ServiceNowで確認すべき不審なログ・兆候

Guest・匿名ユーザーによる大量アクセス

/api/now/sp/、Portal検索、カスタムAPIなどへの高頻度アクセスを確認します。

通常利用では考えにくい短時間の大量リクエストや、連続的な検索があれば要調査です。

大量のsys_id参照やページング

大量のsys_idを順番に参照したり、ページングを繰り返したりしている場合、データ列挙の可能性があります。

不自然なテンプレート・スクリプト入力

エラーを繰り返し発生させる不自然なリクエストや、テンプレート・スクリプト解釈を狙ったような入力がある場合は、RCEやインジェクションを想定して調査します。

ACL・管理権限の変更

ACL、ロール、管理者権限の変更履歴を確認します。

侵害後に攻撃者がアクセス権を広げたり、永続化のために権限を変更したりする可能性があります。

OAuth・統合資格情報の変更

新規OAuthクライアント、トークン発行、統合資格情報の変更がないか確認します。

MID Server・外向き通信の異常

MID Server経由で通常と異なる接続先へ通信している場合や、大量データ転送がある場合は、横展開や情報持ち出しを疑います。

ServiceNowのセキュリティは3層で確認する

Platform層

脆弱性、Patch、Hot Fix、インスタンス構成、AI PlatformやNow Assist関連機能などを確認する層です。

重大CVEへの対応状況が中心になります。

Exposure層

Service Portal、Guest、公開API、Widget、検索機能など、インターネット側からどこまで到達できるかを確認します。

パッチだけでは解決できない公開設定の問題が中心です。

Data層

テーブル、レコード、フィールド、添付、統合処理などについて「誰が何を読めるか」を確認する層です。

ACLやロール設計が中心になります。

ServiceNowでは、この3層のうち1つだけを確認しても十分ではありません。

ServiceNowで最初の48時間に実施すべき確認

とくに、すでに不審アクセスが確認されている場合は、パッチ適用だけで終了せず、過去に侵入されていなかったかを調査する必要があります。

ServiceNowへの侵害が疑われる場合の対処法

セッション・トークンを無効化する

不審な管理者・ユーザーセッションが確認された場合は、現在のアクセスを止めるためにセッションやトークンを失効させます。

認証情報をローテーションする

管理者パスワードだけでなく、OAuth、APIキー、サービスアカウント、MID Server資格情報なども影響範囲に応じて更新します。

ログを保全する

侵害が疑われる場合は、削除・設定変更を急ぐ前に必要なログを保全します。

APIアクセス、Portalアクセス、管理操作、ACL変更、認証、統合ログなどを時系列で確認できる状態にします。

影響テーブルを特定する

「侵入されたか」だけではなく、どのテーブル・レコード・添付が閲覧・取得された可能性があるかを確認します。

管理変更・永続化を確認する

新規ユーザー、管理権限、ACL変更、OAuthクライアント、統合設定など、攻撃者が再アクセスできる仕組みを残していないか確認します。

外部持ち出しの有無を確認する

大量のデータ照会、添付ダウンロード、API経由の抽出、MID Server経由の異常通信などを確認します。

ServiceNowへの不正アクセスや情報漏えいが疑われる場合はフォレンジック調査会社に相談する

重大脆弱性が公表されていても、自社環境が修正済みで、不審アクセスやGuest公開、異常なACLが確認されていない場合は、直ちに侵害されたと判断する必要はありません。

一方で、不審な匿名APIアクセス、Guestによる大量列挙、管理者権限変更、OAuthクライアント追加、MID Server経由の異常通信、添付ファイルの大量取得などが確認された場合は、単なる設定不備ではなく侵害インシデントとして扱う必要があります。

このとき、設定変更やログ削除を先に行うと、攻撃者がいつ侵入し、どのデータへアクセスし、どの範囲まで持ち出した可能性があるのかを確認するための証跡が失われる場合があります。

不審な兆候を確認した場合、フォレンジック調査会社への相談をお勧めします。フォレンジック調査会社では、ServiceNowのアクセスログや認証・管理操作ログに加え、連携する端末、IdP、ネットワーク、クラウド、MID Serverなどの証跡を横断的に確認し、不正アクセスの有無、侵入経路、影響範囲、情報漏えいの可能性を調査できます。

とくに顧客情報、HR情報、SecOps情報、CMDB、認証情報などが含まれる場合は、影響テーブルとアクセス範囲を早期に整理することが重要です。

おすすめのフォレンジック調査会社

公式サイトデジタルデータフォレンジック

編集部が厳選したおすすめのフォレンジック調査会社は、デジタルデータフォレンジックです。

デジタルデータフォレンジックは、累計4万7千件以上の豊富な相談実績を持ち、全国各地の警察・捜査機関からの相談実績も409件以上ある国内有数のフォレンジック調査サービスです。

24時間365日の相談窓口があり、緊急時でも安心です。相談から見積りまで無料で対応してくれるので、フォレンジック調査の依頼が初めてという方もまずは気軽に相談してみることをおすすめします。

【厳格調査】デジタルデータフォレンジックの評判は？口コミや評価、料金体系からサービスを調査

2024.3.5

フォレンジックとは「パソコンやHDD、スマートフォンなどのデジタル端末に残されたログやデータ類を抽出し、サイバーセキュリティ調査や法的紛争支援などを行う」技術です。 その中でも【

【2026年版】ハッキング調査会社を見分けるポイント6選！費用相場や悪徳業者の特徴も解説

2024.3.5

「パソコンが遠隔操作され、詐欺にあったかもしれない…」 「会社のパソコンのログを確認したら、未知のIPアドレスから不正アクセスを受けた痕跡を見

まとめ

ServiceNowを狙うサイバー攻撃では、未認証RCE、未パッチ環境への攻撃、Service Portal・Guest公開面からのデータ列挙、低権限ユーザーによるACL悪用、OAuthや統合資格情報の侵害などに注意が必要です。

ServiceNowの安全性は、脆弱性修正だけでなく、Platform・Exposure・Dataの3層で確認する必要があります。

まず現在のファミリー、Patch、Hot Fix、ホスト形態を確定し、重大脆弱性の修正状況を確認してください。そのうえで、Portal・API・Widgetなどの外部公開面、Guestや低権限ロールの実効権限、ACL、MID Server、OAuth、サービスアカウントを点検します。

また、直近のログからGuestによる大量アクセス、sys_id列挙、不自然なAPIリクエスト、管理者権限変更、OAuth追加、添付大量取得などがないか確認することが重要です。

不審な兆候が見つかった場合は、パッチを当てて終わりにせず、セッション・トークンの無効化、認証情報ローテーション、証跡保全、影響テーブルの特定、情報持ち出し有無の確認まで実施してください。