セキュリティ

LANSCOPE不正アクセス第2報：製品への影響と偽連絡の確認、停止中のライセンス認証の窓口

LANSCOPE不正アクセス第2報：製品への影響と偽連絡の確認、停止中のライセンス認証の窓口

IT資産管理ツール「LANSCOPE」を提供するエムオーテックス（MOTEX）のWebサーバーが不正アクセスを受け、親会社の京セラコミュニケーションシステム（KCCS）が2026年11月6日の第2報で、顧客情報が漏えいした可能性を公表しました。前半では、製品を動かし続けてよいか、ライセンス認証ができないときの窓口、届いた連絡の真偽という管理者の疑問に公式の文言で答えます。後半では、motex.co.jp のメール認証の実測値と、MOTEXを名乗るメールを点検するPython、Webサイトの停止で手続きまで止めないための分離設計を示します。

まとめ：LANSCOPE不正アクセスで管理者が今日確かめる製品の状態と連絡先

結論から言うと、発表どおりならLANSCOPEの端末監視を止める理由はありません。警戒すべきなのは、漏えいの可能性がある担当者の連絡先を使った偽の連絡です。

確かめること 11月9日時点の状況
漏えいの可能性 会社名・氏名・連絡先等
件数 未公表
製品の主要機能 影響なしと発表
停止中のサイト 5サイト・再開未定
オンプレ版の手続き 窓口で個別対応
二次被害 第2報時点で確認なし

管理者が今日やることは2つです。社内の担当者へ偽の連絡に注意するよう伝え、急ぎのライセンス認証やバージョンアップがあればサポートセンター（0120-968-995、携帯電話からは06-6308-8981）へ電話します。受付は9時30分〜12時と13時〜17時30分で、土日祝日と同社の休日は受付対象外です。根拠はKCCSの第2報で確認できます。

LANSCOPE利用企業が確かめる漏えい項目、製品への影響、停止中の手続きと窓口

会社名・氏名・連絡先等が対象、個別連絡の記載がない第2報での確かめ方

第2報が挙げた項目は「会社名・氏名・メールアドレス・電話番号等」です。漏えいの有無と影響範囲は、外部の専門機関と調査を続けている段階にあります。可能性の公表であって、持ち出しが確定したわけではありません。

対象者へ個別に連絡するかどうかは、第2報に書かれていません。自社が対象かを照会するページの案内もなく、現時点で利用企業の側から確定させる手段は見当たりません。「対象の可能性あり」として社内に周知しておくのが現実的です。製品の担当者、販売店との連絡窓口、セミナーや資料請求でMOTEXに連絡先を渡した社員が、周知の相手になります。

ログ取得など主要機能は別環境で稼働、端末監視を止めないと判断する根拠

第2報には「MOTEXが提供する各製品（LANSCOPE等）は、今回不正アクセスを受けたサーバーとは別の環境で運用しており、製品の主要機能（ログ取得等）への影響はございません」とあります。

端末監視を止めると、持ち出しや不正操作の記録が残らなくなります。発表が示す侵害の範囲はWebサーバー側なので、監視を止める損失のほうが大きいと判断します。ただし、この判断は発表の内容を前提にしたものです。原因の調査は続いており、製品側への波及が公表された時点で見直してください。

オンプレミス版のライセンス認証とバージョンアップをサポート窓口へ頼む手順

Webサイトの停止により、「LANSCOPE エンドポイントマネージャー オンプレミス版」のライセンス認証やバージョンアップの手続きができなくなっています。第2報は、急ぐ利用者にはサポート窓口で個別に対応すると案内しました。

  1. 製品名、版数、ライセンスの期限、必要な手続きを手元にまとめる
  2. 社内の台帳や契約書にある番号で、サポートセンターへ電話する
  3. 受けた案内と担当者名を、変更管理の記録に残す

手順2で番号の出どころにこだわるのは、後述する偽の連絡を避けるためです。メールに書かれた番号へ折り返してはいけません。

第1報と第2報の差分、11月9日時点で公表されていない項目と脆弱性との区別

11月2日の確認から11月9日17時の再開未定までの時系列と変化した1点

日付 内容
11月2日 不正アクセスを確認しサイト停止
11月4日 第1報。流出は確認されず
11月6日 第2報。漏えいの可能性が判明
11月9日17時 再開の見通し立たず

変わったのは漏えいの評価です。11月4日の第1報は外部への流出を確認していないとしていました。第1報だけを読んだ社員には、第2報の内容を改めて伝える必要があります。11月9日の行は、MOTEXのサイトに表示された停止案内の文言です。

停止しているのは、MOTEXコーポレートサイト、LANSCOPE製品サイト、サポートサイト「LANSCOPE PORTAL」、ガイドライン対応サポートアカデミーの契約企業専用サイト、販売パートナー専用サイト「MOTEX PARTNER PORTAL」の5つです。

件数・侵入経路・IDとパスワードの扱いなど公表待ちの7項目と続報の見方

次の7項目は第2報に記載がないか、調査中とされています。この記事では推測しません。

  • 漏えいの可能性がある件数
  • 不正アクセスの原因と侵入経路
  • 「等」に含まれる具体的な項目
  • PORTALのログインIDやパスワードの扱い
  • 対象者への個別連絡の有無と方法
  • 各サイトの再開時期
  • クラウド版の手続きへの影響

優先して見るべきは4番目です。PORTALの認証情報が含まれると公表された場合、対応は注意喚起からパスワード変更へ変わります。続報はMOTEXのサイトが止まっている間、KCCSの「重要なお知らせ」に載っています。

CVE-2025-61932と今回の不正アクセスを分ける理由、公告が開けない間の確認先

「LANSCOPE 不正アクセス」で調べると、2025年10月に公表された脆弱性の記事が多く混ざります。CVE-2025-61932は、オンプレミス版のクライアントプログラム（MR）と検知エージェント（DA）のVer.9.4.7.1以前に影響する送信元検証の不備で、IPAの注意喚起はCVSS 9.8としています。

今回の発表文は、この脆弱性に触れていません。原因が未公表である以上、両者を結び付ける根拠はなく、別の事象として扱います。

実務上の影響はあります。開発元の公告ページは、11月9日の時点でサイト停止のため開けませんでした。修正状況を確かめたい場合はJVN#86318557で対象版とワークアラウンドの有無を確かめ、未適用の端末があるならサポート窓口に更新の入手方法を尋ねます。更新の手続きが止まっていることは、古い版を放置してよい理由になりません。

MOTEXを名乗る偽連絡の見分け方、DMARC実測値とメール点検スクリプト

パスワードを聞かれたら偽物と判断する公式の基準と折り返し先の決め方

第2報には「MOTEXからメールやお電話等で、お客様のパスワード情報等をお伺いすることは一切ございません」と明記されています。パスワードを聞かれた時点で、偽物と判断して構いません。

第2報の時点で二次被害は確認されていません。以下は確認された実例ではなく、想定される口実です。サイトが実際に止まっているので、「ライセンス認証の再手続き」「新しいサポートサイトへの移行」「緊急バージョンアップ」といった文面には説得力が出てしまいます。会社名、氏名、担当製品を言い当てられても、本物の証拠にはなりません。漏えいの可能性がある項目そのものだからです。

こうした手口の仕組みはフィッシング詐欺の成立の仕組みと技術的対策で解説しました。不審な連絡は切って、台帳にある番号へかけ直します。製品の更新ファイルをメールのリンクから入手することも避けてください。

motex.co.jpのDMARCはp=none、認証失敗でも届く前提の受信側の設定

メールの差出人を偽装されたとき、ドメインの設定がどう働くかを公開DNSで確かめました。次のURLで、誰でも同じ値を取得できます。

curl -s "https://dns.google/resolve?name=_dmarc.motex.co.jp&type=TXT"

2026年11月9日の取得結果では、_dmarc.motex.co.jp は v=DMARC1; p=none、motex.co.jp のSPFは末尾が ~all でした。p=none は受信側に隔離や拒否を求めない設定です。つまり、差出人に motex.co.jp を騙ったメールでも、受信側の判断次第で受信箱に届きます。

値はいつでも変わるので、対処は受信側に置きます。メールゲートウェイに「差出人ドメインが motex.co.jp か lanscope.jp で、DMARCが fail なら隔離」という規則を期間限定で足す方法が手早いでしょう。SPFにはExchange Online、Salesforce、Amazon SESなど複数の配信基盤が許可されているため、送信元のサービス名では真偽を決められません。SPFの評価の流れはSPFの仕組みとレコードの書き方にまとめています。

差出人・DMARC・リンク先を.emlで点検するPythonスクリプトと実行結果

社員から「これは本物ですか」と転送されたメールを、同じ基準でふるい分けるスクリプトです。差出人のドメイン、自社サーバーが付けたDMARCの結果、本文のリンク先を確かめます。標準ライブラリだけで動き、引数なしなら検証用の3通で実行できます。

# ベンダーを名乗るメールの .eml を点検する（Python 3.9以上・標準ライブラリのみ）
# 要確認の項目が1つでもあれば終了コード1。終了コード0でも本物の証明にはならない
import argparse
import re
import sys
from email import policy
from email.message import EmailMessage
from email.parser import BytesParser
from email.utils import parseaddr
from urllib.parse import urlsplit

AT = chr(64)  # アットマークの文字
OFFICIAL = ("motex.co.jp", "lanscope.jp", "kccs.co.jp")
TRUSTED_AUTHSERV = "mx.example.co.jp"  # 自社の受信サーバーが名乗る authserv-id に替える


def is_official(host):
    host = host.lower().rstrip(".")
    return any(host == d or host.endswith("." + d) for d in OFFICIAL)


def dmarc_result(msg):
    # 上から見て最初の、自社サーバーが付けた結果だけを採用する
    for value in msg.get_all("Authentication-Results", []):
        text = str(value).lower()
        if text.split(";", 1)[0].split()[0] != TRUSTED_AUTHSERV:
            continue
        found = re.findall(r"\bdmarc=(\w+)", text)
        return found[0] if found else "none"
    return "自社サーバーの結果なし"


def review(msg):
    issues = []
    address = parseaddr(str(msg["From"]))[1]
    domain = address.rsplit(AT, 1)[-1]
    if not is_official(domain):
        issues.append(f"差出人ドメインが公式でない: {domain}")
    result = dmarc_result(msg)
    if result != "pass":
        issues.append(f"DMARCがpassでない: {result}")
    part = msg.get_body(preferencelist=("html", "plain"))
    body = part.get_content() if part else ""
    for url in re.findall(r"https?://[^\s\"'<>]+", body):
        host = urlsplit(url).hostname or ""
        if not is_official(host):
            issues.append(f"公式でないリンク先: {host}")
    return issues


def sample(sender, dmarc, url):
    msg = EmailMessage()
    msg["From"] = "MOTEX Support <" + sender + ">"
    msg["Subject"] = "ライセンス認証のお願い"
    msg["Authentication-Results"] = f"{TRUSTED_AUTHSERV}; dmarc={dmarc} header.from=motex.co.jp"
    msg.set_content(f"手続きはこちら {url}\n")
    return msg


def demo():
    return {
        "偽ドメイン": sample(f"support{AT}motex-portal.example", "none", "https://lanscope-portal.example/login"),
        "差出人偽装": sample(f"info{AT}motex.co.jp", "fail", "https://motex.co.jp.evil.example/renew"),
        "公式相当": sample(f"info{AT}motex.co.jp", "pass", "https://www.kccs.co.jp/news/important/2026/1106/"),
    }


def main():
    parser = argparse.ArgumentParser()
    parser.add_argument("eml", nargs="*", help="点検する .eml。省略すると検証用の3通で動く")
    args = parser.parse_args()

    if args.eml:
        targets = {}
        for path in args.eml:
            with open(path, "rb") as f:
                targets[path] = BytesParser(policy=policy.default).parse(f)
    else:
        targets = demo()

    flagged = 0
    for name, msg in targets.items():
        issues = review(msg)
        flagged += 1 if issues else 0
        print(f"[{'要確認' if issues else '指摘なし'}] {name}")
        for issue in issues:
            print(f"  - {issue}")
    sys.exit(1 if flagged else 0)


if __name__ == "__main__":
    main()

Windowsで2026年11月9日に引数なしで実行した結果です。要確認があるので終了コードは1でした。

[要確認] 偽ドメイン
  - 差出人ドメインが公式でない: motex-portal.example
  - DMARCがpassでない: none
  - 公式でないリンク先: lanscope-portal.example
[要確認] 差出人偽装
  - DMARCがpassでない: fail
  - 公式でないリンク先: motex.co.jp.evil.example
[指摘なし] 公式相当

2通目の motex.co.jp.evil.example は、先頭だけを比べると公式に見えるドメインです。末尾とドットの区切りまで比べているので、公式扱いになりません。

Authentication-Results を自社サーバーの分に絞る処理は省かないでください。RFC 8601の1.1節は、このヘッダーがあるだけでは内容の正しさを意味しないと述べています。攻撃者も同じヘッダーを書き込めるからです。TRUSTED_AUTHSERV は自社の値に替え、境界のサーバーが外部から来た同名のヘッダーを消す設定かどうかも確かめます。「指摘なし」は本物の証明ではありません。正規のメールでも、配信サービスの計測用URLが入ると要確認になることがあります。

Webサイトの停止で製品手続きまで止まる構造と、提供側が分けておく4機能

5サイト同時停止が示すコーポレートサイトと顧客手続きの共通依存

第1報は、ライセンス認証などができない理由を「Webサイト停止に伴い」と説明しています。製品本体は動いているのに、手続きだけがWebサイトと一緒に止まったわけです。社内の構成は公表されていないため、MOTEXの設計を評価することはできません。とはいえ、製品を提供する会社なら同じ状況を自社に当てはめて確かめる価値があります。

侵害されたサーバーは、調査と安全確認が済むまで戻せません。公開サイトと顧客向けの手続きが同じ基盤にあれば、停止期間も同じになります。今回の告知が親会社のドメインから出ている点は、告知の経路を別に持つことの効果を示しています。

告知・ライセンス認証・更新配布・問い合わせを別系統に置く設計の比較

機能 置き場所 止まったときの代替
告知 別ドメイン 親会社や状態ページ
ライセンス認証 専用の認証API 署名付きの認証ファイル
更新配布 配布専用の保管先 署名を検証できる複製
問い合わせ 電話とメール サイトに依存しない番号

優先順位をつけるならライセンス認証が先です。認証が通らないと、利用企業は端末の入れ替えも増設もできません。認証ファイルに署名を付けてオフラインで検証できるようにし、一定の猶予期間を持たせれば、サイトが止まっても業務は続きます。

顧客の連絡先を公開サーバーから直接読める構成も見直しの対象です。問い合わせフォームの送信先を別のシステムに分け、公開側には保存しないようにすれば、Webサーバーが破られても持ち出せるデータが減ります。公開側のAPIの点検項目はAPI不正アクセス対策の実装手順で確認できます。

個人情報保護委員会への報告の範囲、製品継続の判断と第三者診断を頼む条件

MOTEXが進める報告と、1,000人超・不正目的の類型に照らす期限

第2報は、個人情報保護委員会への報告と警察への相談を進めると述べています。委員会の案内では、本人の数が1,000人を超える漏えい等や、不正の目的をもって行われたおそれがある行為による漏えい等が報告の対象です。速報は発覚から3〜5日以内、確報は30日以内で、不正の目的によるおそれがある場合は60日以内とされています。

MOTEXが自社の顧客情報として保有していた連絡先であれば、報告の主体は基本的に同社です。利用企業が別の個人データの取り扱いをMOTEXに委託している場合など、個別の事情があれば法務担当者に確認してください。自社が報告する側になったときの流れは個人情報保護委員会への報告義務の実務で扱いました。

製品の入れ替えを今は見送る判断と、再検討に切り替える2つの条件

今の時点で、LANSCOPEの入れ替えは見送るべきです。発表上、侵害はWebサーバーに限られ、乗り換えには端末への再配布と監視の空白が伴います。原因も分からないまま決める話ではありません。

再検討に切り替える条件は2つあります。原因の調査で製品や更新ファイルへの波及が公表されたとき。そして、停止が長引き、適用すべき修正を窓口経由でも入手できないときです。ベンダーの事故を取引先のリスクとして記録する方法は、サプライチェーン攻撃の起点別の類型と委託先管理の監督義務とチェックリストが参考になります。

顧客情報を持つ自社Webサーバーを第三者に診断してもらう判断基準

今回の件を自社に置き換えると、問われるのは製品ではなくWebサーバーの側です。次のいずれかに当てはまるなら、外部の診断を入れる時期といえます。

  • 問い合わせや資料請求の情報を公開サーバーに保存している
  • 公開サイトのCMSやプラグインの更新担当が決まっていない
  • 顧客向けの手続きが公開サイトと同じ基盤で動いている
  • 直近1年、第三者による診断を受けていない

静的なページだけで顧客情報を持たないサイトなら、診断より更新の自動化とアクセス権の棚卸しを先に進めれば足ります。顧客情報を扱うサイトを第三者の目で確かめたい場合は、脆弱性診断・セキュリティ診断でご相談いただけます。

よくある質問

LANSCOPEの管理者から出やすい質問をまとめました。内容は2026年11月6日の第2報と、11月9日に確認した停止案内に基づきます。

LANSCOPEの端末監視は止めたほうがよいですか？

発表の内容を前提にすれば、止める必要はありません。第2報は、製品が不正アクセスを受けたサーバーとは別の環境で運用されており、ログ取得などの主要機能に影響はないと説明しています。監視を止めると、その間の操作記録が残らなくなります。原因の調査は続いているので、製品や更新ファイルへの波及が公表された場合は、その内容に合わせて判断を見直してください。

自社の情報が漏えいしたかどうかはどう確認できますか？

現時点で、利用企業が自分で照会できるページの案内はありません。第2報は件数を明らかにしておらず、対象者への個別連絡についても書いていません。漏えいの有無と範囲は調査中とされています。製品の利用に関する問い合わせはサポートセンターで受け付けているので、確認したい場合は台帳や契約書にある番号へ連絡し、続報が出るまでは対象の可能性がある前提で社内に周知してください。

ライセンス認証ができないとLANSCOPEは使えなくなりますか？

発表文には、認証できない状態が続いた場合の動作は書かれていません。書かれているのは、ログ取得などの主要機能に影響がないことと、オンプレミス版のライセンス認証やバージョンアップの手続きができないことです。端末の増設や入れ替え、期限の更新を控えているなら、影響が出る前にサポート窓口へ連絡し、個別の対応を受けてください。受けた案内は記録に残しておくと、後から確認できます。

LANSCOPE PORTALはいつ再開しますか？

再開の時期は未定です。MOTEXのサイトに表示された停止案内には、11月9日17時の時点で再開の見通しは立っていないとあります。KCCSは、安全の確認ができ次第、改めて案内するとしています。「新しいサポートサイトができた」「移行先はこちら」といった連絡がメールで届いたら、すぐには開かず、KCCSの発表かサポートセンターの電話で裏を取ってからにしてください。

LANSCOPE PORTALのパスワードは変更すべきですか？

第2報が挙げた項目にパスワードは含まれていません。ただ、項目の末尾は「等」で、詳細は調査中です。PORTALは停止中で変更自体ができないため、同じパスワードを他のサービスで使い回している場合に、そちらを先に別の文字列へ変えておくと安全です。PORTALが再開したときに、変更を求める公式の案内があるかを確かめてください。メールのリンクからパスワードを入力することは避けます。

関連記事

お気に入りに入れた記事の一覧

一創の公式 SNS

X では毎朝の新着記事と IT ニュースの速報を、YouTube・TikTok・Instagram・LinkedIn・Facebook では記事の解説動画を配信しています。

この記事に関連するサービス

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.11.07　コラム サイバーセキュリティ緊急対策パッケージとは？4本柱の施策と期限、企業と委託先が今やること
  2. 2026.11.06　テックブログ ドコモ不正アクセスの見舞金・対象確認とMy docomo再開状況：最大29.5万件の流出項目【11月9日第四報】
  3. 2025.04.30　テックブログ IMSIキャッチャー（偽基地局）とは？2Gフォールバックの手口と日本での対策
  4. 2026.11.03　テックブログ ネットマイル不正アクセスで最大約549万人に漏えいの可能性：ログイン・マイル・退会・登録した覚えがない場合
  5. 2026.11.06　テックブログ あいおいニッセイ同和の不正アクセス：44.4万件の漏えい項目と窓口、止まった手続きの代わり

RELATED POSTS 関連記事

一覧へ戻る

目次