セキュリティ

アンドエスティ不正アクセス：250万件の流出項目と対象確認、ポイントと偽メール

アンドエスティ不正アクセス：250万件の流出項目と対象確認、ポイントと偽メール

アパレルのWEBストアと店舗を展開する株式会社アンドエスティHD（旧アダストリア）は2026年10月23日、業務サーバーが外部から不正アクセスを受け、顧客の個人情報など約250万件が外部に流出した可能性があると公表しました。氏名・生年月日・住所・電話番号・メールアドレス・会員IDが含まれる一方、クレジットカードなどの決済情報と、会員が自分で設定したパスワードは含まれていません。前半では、自分が対象か、パスワードを変えるべきか、ポイントや店舗受取は使えるか、どこに問い合わせるかに公式発表で答えます。後半は、同社が2023年1月にも受けた不正アクセスとの比較と、複数のサーバーへの侵入と持ち出しを通信ログから見つける手順をコードで示します。

まとめ：アンドエスティ不正アクセスで流出の可能性がある情報と、利用者が今確かめること

アンドエスティHDのお知らせによると、10月22日の午前7時30分頃から、外部からの不正アクセスによって同社の複数サーバーに順次ログイン試行・侵入・データ抽出が行われました。午前10時頃に不正な操作を検知してサーバーを隔離し、同日17時までに不正アクセスの経路を遮断して、社内業務システムを停止しています。翌23日には警察へ相談し、個人情報保護委員会へ報告しました。

会員が確かめることとして、次の4つを挙げます。1つ目に、対象者への連絡が順次届く予定なので、届いた連絡が本物かを公式サイトで照らし合わせてください。2つ目として、パスワードは流出していませんが、他のサービスと同じものを使っているなら変えておくと安心です。3つ目は、ポイントの利用が再開した一方で、店舗受取と試着のサービスがまだ止まっている点を押さえることです。4つ目に、カード情報の再登録やパスワードの入力を求めるメールやSMSには応じないことが挙げられます。

項目 公表されている内容（2026年10月28日時点）
公表した会社 株式会社アンドエスティHD
不正アクセスの発生 2026年10月22日 午前7時30分頃
公表日 2026年10月23日
顧客の情報 約250万件（氏名・住所・会員IDなど）
取引先の情報 約1万件（会社名・担当者名など）
従業員の情報 範囲を確認中
含まれない情報 決済情報・会員が設定したパスワード
未公表 侵入経路・原因・ブランド別の内訳

会員が最初に確かめること：対象の連絡、パスワード、ポイント、偽メール

自分が流出対象かどうかを確かめる、会社から順次届く連絡の確認

HDのお知らせは、対象となる顧客と取引先へ順次連絡を始める予定だとしています。10月28日時点で、会員番号やメールアドレスを入れて対象かを照会するページは公開されていません。グループには複数のブランドがありますが、どのブランドの会員が対象なのかという内訳も示されていません。連絡を待つ間にできるのは、届いた案内が本物かどうかを見分ける準備です。

WEBストアの会員だけでなく、店舗で会員登録をした人も対象に含まれる可能性があります。公表文が「業務サーバー」に保存された顧客情報としており、WEBストアの会員に限っていないためです。一方で、WEBストア「アンドエスティ」のシステムサーバーには不正アクセスは確認されていないと、両方のお知らせが明記しています。

パスワードは流出の対象外でも、他サービスと使い回している場合の変更

WEBストアのお知らせは、パスワードの漏えいは発生していないと説明しています。そのうえで、安全のためにマイページからパスワードを再設定し、他のサービスと同じパスワードを使わないよう勧めています。流出した可能性のあるメールアドレスと、別のサービスから漏れたパスワードを組み合わせてログインを試す攻撃があるからです。この攻撃の仕組みと検知の指標はパスワードリスト攻撃の検知の指標と漏えい照合で解説しています。

身に覚えのないログイン通知が届いた場合は、カスタマーサポートへ連絡するよう案内されています。クレジットカードについては、決済に外部のサービスを使っており同社のサーバーにはカード情報を持っていないため、漏えいの事実はないとしています。

ポイントは10月27日までに再開、店舗受取と試着の停止状況の確認

HDの10月23日のお知らせでは、店舗とWEBストアのどちらでも会員ポイントが使えない状態だと書かれていました。その後、WEBストアのお知らせが10月27日18時30分に更新され、ポイントの利用、保有ポイントの表示、dアカウントと楽天IDのID連携は再開しています。HD側のお知らせだけを読むと、ポイントが使えないままだと受け取ってしまう点に注意が要ります。

  • 再開済み：ポイントの利用（店舗・WEBストア）、保有ポイントの表示、ID連携
  • 停止中：店舗受取サービス、試着サービス
  • 遅れあり：注文商品の配送（指定日時に届かない場合がある）

メンテナンスは10月22日17時頃から始まっています。期間中の購入で付くポイントは順次反映され、期間中に期限が切れたポイントは11月上旬頃に補填する予定です。

カード情報の再登録やパスワード入力を求めるメール・SMSへの警戒

WEBストアのお知らせは、同社がメールやSMSでカード情報の再登録・再決済やパスワードの入力を求めることは一切ないと明記しています。届いた連絡のリンクは開かずに削除し、内容を確かめたいときは自分でWEBストアやHDのサイトを開いて照らし合わせてください。氏名・住所・電話番号・メールアドレスがそろって流出した可能性があるため、本物らしく見える偽の連絡が届くおそれがあります。偽の連絡が成立する仕組みはフィッシング詐欺の成立の仕組みと技術的対策で解説しています。

流出の可能性がある情報の内訳：顧客約250万件・取引先約1万件・従業員

顧客情報は7項目、決済情報と会員が設定したパスワードは含まれない

10月23日時点で流出の可能性があるとされた情報は、次のとおりです。件数はその時点の調査結果で、今後変わる可能性があるとしています。

対象 件数 項目
顧客 約250万件 氏名・生年月日・性別・住所・電話・メール・会員ID
取引先 約1万件 会社名・発注先住所・担当者名・電話・メール
従業員 確認中 確認中

取引先の情報には、発注先と返品先の住所も含まれています。取引先を名乗って振込先の変更を求めるような請求の偽装にも注意が要ります。公表文は「流出の可能性」と書いており、流出が確定したとは述べていません。

個人情報保護委員会への報告は発覚の翌日に実施、本人への通知の扱い

同社は不正アクセスの翌日、10月23日に個人情報保護委員会へ報告しました。不正の目的によるおそれがある漏えいは、件数にかかわらず委員会への報告と本人への通知が必要な類型に当たります。報告の流れは個人情報保護委員会の漏えい等の対応ページにまとまっています。速報と確報の期限、通知の書き方は個人情報保護委員会への報告義務の実務で整理しました。

公式発表で追う経過：10月22日7時30分の侵入から17時の遮断まで

2社のお知らせを時系列に並べると、次のとおりです。

  1. 10月22日 午前7時30分頃：複数サーバーへのログイン試行・侵入・データ抽出が始まる
  2. 10月22日 午前10時頃：不正な操作を検知し、当該サーバーを隔離
  3. 10月22日 17時頃：WEBストアがメンテナンスを開始
  4. 10月22日 17時まで：不正アクセスの経路を遮断し、社内業務システムを停止
  5. 10月23日：警察へ相談し、個人情報保護委員会へ報告。HDとWEBストアが公表
  6. 10月27日 18時30分：WEBストアのお知らせを更新し、ポイント利用などの再開を告知

侵入の起点がどこだったのか、どの脆弱性や認証情報が使われたのかは書かれていません。HDのお知らせは、不正アクセスの手段を特定して対応を終えたとするだけです。業績への影響は精査中で、重大な影響が見込まれる場合は速やかに公表するとしています。問い合わせはWEBストアのカスタマーサポートのフォームで受け付けており、10月28日時点で電話窓口の番号は載っていません。問い合わせ窓口は今後設置する予定とされています。

2023年1月の不正アクセスとの比較：旧アダストリア時代の104万件と今回

同じ社内業務システムのサーバーが狙われた2回目の事案と前回との比較

同社は社名がアダストリアだった2023年1月にも、サーバーへの不正アクセスを公表しています。2023年1月24日の第二報によると、1月18日早朝に社内業務システムのサーバー等が不正アクセスを受け、ネットワークの遮断と社内業務システムの停止を行いました。このときもWEBストアのECサーバーは影響を受けていませんでしたが、物流システムを止めたためにWEBストアを休止しています。

比較項目 2023年1月 2026年10月
狙われた先 社内業務システムのサーバー等 業務サーバー（複数）
ECサーバー 影響なし 影響なし
顧客の件数 1,044,175件（第二報） 約250万件（初報）
パスワード 対象外 対象外
決済情報 対象外 対象外
委員会への報告 第二報までに実施 翌日に実施

2023年の第三報で、過去の問い合わせ記録と従業員情報が追加された

2023年3月31日の第三報は、フォレンジック調査を終えて、流出の可能性がある情報を追加しました。2008年〜2013年にカスタマーサービスへ電話で問い合わせた顧客の情報が221,272件、2008年以降に在籍した従業員の情報が94,435件、採用選考の応募者情報が合わせて48,523件、取引先の情報が6,346件です。初報から第三報まで約2か月半かかり、その間に対象の範囲が広がりました。

今回も従業員情報は確認中とされており、調査が進めば対象が加わる可能性があります。2023年の経過を踏まえると、初報の件数だけで自分は関係ないと判断せず、続報を確かめるのが無難です。

開発側の教訓：複数サーバーへの横展開と持ち出しをフローログで検知する手順

侵入から検知まで2時間半、その間に何を見ていれば止められたか

今回の公表で注目したいのは、ログイン試行から侵入、データ抽出までが複数のサーバーに対して順に行われ、検知まで約2時間半かかった点です。1台目に入った攻撃者は、社内の別のサーバーへ管理用の接続を広げ、データのあるサーバーにたどり着いてから外へ送り出します。この流れは、サーバーの中身を見なくても、通信の記録に2つの形で残ります。1つは1台のサーバーが短い時間に何台もの社内サーバーへ管理用のポートで接続すること、もう1つは普段わずかしか外へ送らないサーバーが急に大量のデータを送り出すことです。

同社の業務サーバーがどの環境で動いていたかは公表されていません。ここでは一般論として、AWSのVPCで取れる通信の記録を例に、この2つを拾う手順を示します。VPCフローログの既定形式は、送信元と宛先のアドレス・ポート、転送したバイト数、開始と終了の時刻などを1行に並べたversion 2の形式です。記録をまとめる間隔は既定で最大10分、設定で1分にもできます。フローログの取り方はAWSでのフロー監視とVPC Flow Logsの使い分けで解説しています。

VPCフローログから横展開と外向き転送の急増を拾うPythonスクリプト

# VPCフローログ（既定形式・version 2）から「社内サーバーを順に試す横展開」と「外向き転送の急増」を拾う（Python 3.8以上・標準ライブラリのみ）
# 使い方: python flow_exfil_check.py flow.log   ／  python flow_exfil_check.py --demo（架空ログを作って試す）
import ipaddress, random, statistics, sys
from collections import defaultdict
from datetime import datetime, timedelta, timezone

JST = timezone(timedelta(hours=9))
BUCKET = 600                                   # 10分単位で集計（既定の最大集約間隔に合わせる）
ADMIN_PORTS = {22, 445, 3389, 5985}           # SSH・SMB・RDP・WinRM
FANOUT_MIN = 3                                 # 10分で3台以上へ管理ポート接続したら横展開を疑う
EGRESS_MIN = 50 * 1024 * 1024                  # 外向き50MB未満は対象外（誤検知を減らす下限）

INTERNAL = [ipaddress.ip_network(n) for n in ("10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16")]  # 自社VPCのCIDRに合わせる

def private(ip):
    a = ipaddress.ip_address(ip)
    return any(a in n for n in INTERNAL)       # is_private は文書用アドレスも含むので使わない

def parse(lines):
    for line in lines:
        f = line.split()
        if len(f) != 14 or f[0] != "2" or f[13] != "OK":
            continue                            # 見出し行・NODATA・SKIPDATA は飛ばす
        yield dict(src=f[3], dst=f[4], dport=int(f[6]), bytes=int(f[9]), start=int(f[10]), action=f[12])

def analyze(records, learn_until):
    fanout = defaultdict(set)                  # (送信元, 時間枠) → 管理ポートで触れた社内ホスト
    egress = defaultdict(int)                  # (送信元, 時間枠) → 社外へ送ったバイト数
    for r in records:
        b = r["start"] // BUCKET * BUCKET
        if private(r["src"]) and private(r["dst"]) and r["dport"] in ADMIN_PORTS:
            fanout[(r["src"], b)].add(r["dst"])
        if r["action"] == "ACCEPT" and private(r["src"]) and not private(r["dst"]):
            egress[(r["src"], b)] += r["bytes"]
    base = defaultdict(list)                   # 学習期間の外向き量を送信元ごとに集める
    for (src, b), v in egress.items():
        if b < learn_until:
            base[src].append(v)
    alerts = []
    for (src, b), hosts in fanout.items():
        if b >= learn_until and len(hosts) >= FANOUT_MIN:
            alerts.append((b, "横展開の疑い", src, f"{len(hosts)}台へ管理ポート接続"))
    for (src, b), v in egress.items():
        if b < learn_until or v < EGRESS_MIN:
            continue
        hist = base.get(src, [0])
        med = statistics.median(hist)
        mad = statistics.median([abs(x - med) for x in hist]) or 1
        if v > med + 10 * 1.4826 * mad:        # 中央値＋10×MAD（外れ値に強い基準）を超えたら通知
            alerts.append((b, "外向き転送の急増", src, f"{v / 2**20:.0f}MB（平常の中央値 {med / 2**20:.1f}MB）"))
    for b, kind, src, detail in sorted(alerts):
        print(datetime.fromtimestamp(b, JST).strftime("%m-%d %H:%M"), kind, src, detail)

def demo():
    random.seed(7)
    day = int(datetime(2026, 10, 21, tzinfo=JST).timestamp())
    rows = []
    def rec(src, dst, dport, size, t):
        rows.append(f"2 123456789012 eni-0abc {src} {dst} 49152 {dport} 6 {max(size // 1400, 1)} {size} {t} {t + 50} ACCEPT OK")
    for t in range(day, day + 86400 + 4 * 3600, 60):                # 平常時：業務サーバーが外部APIへ少量送る
        rec("10.0.1.20", "203.0.113.10", 443, random.randint(200_000, 600_000), t)
    t0 = day + 86400 + int(7.5 * 3600)                               # 翌日7:30から侵入を再現
    for i, host in enumerate(["10.0.1.21", "10.0.1.22", "10.0.1.23", "10.0.1.24"]):
        rec("10.0.1.20", host, 3389, 4_000, t0 + i * 90)            # 社内サーバーへ順にRDP
    for m in range(0, 90, 5):                                        # 8:30から5分おきに外部へ持ち出し
        rec("10.0.1.24", "198.51.100.77", 443, 300 * 2**20, t0 + 3600 + m * 60)
    for t in range(day, day + 86400, 600):                           # 10.0.1.24 の平常時の外向き通信
        rec("10.0.1.24", "203.0.113.10", 443, random.randint(1_000_000, 3_000_000), t)
    return rows, day + 86400

if __name__ == "__main__":
    if sys.argv[1:] == ["--demo"]:
        rows, learn_until = demo()
        analyze(parse(rows), learn_until)
    else:
        lines = open(sys.argv[1], encoding="utf-8").read().splitlines()
        recs = list(parse(lines))
        learn_until = max(r["start"] for r in recs) // 86400 * 86400   # 最終日の前日までを平常として学習
        analyze(recs, learn_until)

架空の通信記録を作って試す --demo の実行結果は次のとおりです（Python 3.14.7・Windows）。前日1日分の平常時の通信を学び、翌日の午前7時30分から社内4台への接続、8時30分から外部への送信を再現しています。

$ python flow_exfil_check.py --demo
10-22 07:30 横展開の疑い 10.0.1.20 4台へ管理ポート接続
10-22 08:30 外向き転送の急増 10.0.1.24 600MB（平常の中央値 2.0MB）
10-22 08:40 外向き転送の急増 10.0.1.24 600MB（平常の中央値 2.0MB）
（08:50〜09:40 の6枠も同じ内容のため省略）
10-22 09:50 外向き転送の急増 10.0.1.24 600MB（平常の中央値 2.0MB）

侵入が始まった10分の枠で横展開を、持ち出しが始まった枠で転送の急増を拾えています。平常時の量の基準には平均ではなく中央値と中央絶対偏差を使い、Pythonのstatisticsの median で計算しています。平均だと、一度の大きな転送で基準そのものが引き上げられてしまうためです。社内か社外かの判定は自社のアドレス範囲を明示して行います。Pythonの is_private は文書用のアドレスも社内と判定するため、そのまま使うと試験データの外部送信を見逃しました。

実運用では、フローログがCloudWatch Logsに届くまで通常5分前後かかります。このスクリプトを定期実行するか、同じ条件を監視基盤の検知ルールに置き換えて通知に流すのが現実的です。夜間や早朝に通知を受けて隔離まで動ける体制がなければ、検知しても止められません。監視を誰が担うかの判断はSOCとSIEM・SOARの違いと監視運用の内製判断で扱っています。

事業者の判断：業務サーバーに置く個人情報を減らす設計と、外部診断の使い方

業務サーバーに古い個人情報を残すほど、事故の件数は大きくなる

2023年の第三報で対象に加わった問い合わせ記録は、2008年〜2013年のものでした。10年近く前の記録が業務サーバーに残っていたため、事故の対象が広がった形です。個人情報保護法は、利用する必要がなくなった個人データを遅滞なく消去するよう努めることを求めています。業務サーバーには、業務で今使う項目だけを、決めた期間だけ置く設計にしておくと、侵入されたときに持ち出される量そのものを減らせます。保存期間と削除の決め方は顧客情報管理システムの保存期間・削除の設計で整理しました。

使い続けてよいのは、業務サーバーへの管理用の接続元が限られ、社内での横の通信と外向きの転送量が監視され、古い個人データが定期的に消されている構成です。見直しを急ぐべきなのは、ECサーバーは守っていても、顧客データの写しが業務システム側に長く残っている場合です。同じく業務システムの停止に至った事案として、アスクルのランサムウェア攻撃の経緯と流出件数も参考になります。

ECサイトの外側にある業務システムの管理用接続と、外部診断での点検

今回も2023年も、顧客が触れるECサーバーではなく、社内の業務システムが入口になりました。ECサイトは定期的に点検していても、受注・物流・顧客対応などの業務システムは点検の範囲から抜けがちです。管理用の接続がどこから許されているか、侵入された場合にどこまで横に広がれるかは、外部から試してみないと実際の強さが分かりません。診断の種類と費用の考え方は脆弱性診断の種類・費用相場と外注の判断基準、企業として点検する範囲の全体像は不正アクセス対策の点検手順で解説しています。

ECサイトの裏側にある業務システムやサーバー群を、第三者に確かめてもらいたいなら、脆弱性診断・セキュリティ診断で相談できます。外部に公開しているAPIの対策はAPI不正アクセス対策の実装手順で扱っています。

よくある質問

アンドエスティの不正アクセスについて、会員から出やすい質問をまとめました。

アンドエスティの不正アクセスで自分の情報が流出したか確かめられますか？

10月28日時点で、対象かどうかを照会するページは公開されていません。同社は対象となる顧客へ順次連絡する予定としています。連絡が届いたら、リンクを開く前にWEBストアやHDの公式サイトを自分で開き、同じ案内が出ているかを照らし合わせてください。

アンドエスティのパスワードは変更したほうがいいですか？

公表では、会員が設定したパスワードは流出していません。ただし、WEBストアは安全のためにマイページからの再設定と、他のサービスとの使い回しをやめることを勧めています。同じパスワードを他でも使っているなら、変えておくのが無難です。

アンドエスティのポイントは今使えますか？

使えます。10月27日に更新されたWEBストアのお知らせで、店舗とWEBストアでのポイント利用、保有ポイントの表示、ID連携の再開が告知されました。メンテナンス期間中に期限が切れたポイントは、11月上旬頃に補填される予定です。店舗受取と試着のサービスは止まったままです。

アンドエスティの問い合わせ窓口に電話はありますか？

10月28日時点で、問い合わせはWEBストアのカスタマーサポートのフォームで受け付けており、電話番号は掲載されていません。HDのお知らせは、今後問い合わせ窓口を設置する予定としています。電話番号を名乗る連絡が来た場合は、公式サイトに同じ番号が載っているかを確かめてください。

アンドエスティの不正アクセスでクレジットカードは不正利用されますか？

公表では、クレジットカードなどの決済情報は流出の対象に含まれていません。WEBストアは外部の決済サービスを使っており、同社のサーバーにカード情報を持っていないと説明しています。カード情報の再登録や再決済を求めるメールやSMSは偽物なので、応じないでください。

関連記事

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

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

資料請求

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

  1. 2025.02.27　コラム トラッキングビーコン（Webビーコン）とは？仕組み・用途・確認と対策を徹底解説
  2. 2026.10.27　テックブログ Joshin（ジョーシン）不正アクセス：最大600万件の対象とサブスク初期パスワードの対処
  3. 2026.10.27　テックブログ Brotli 脆弱性：CVE-2026-111497の影響確認とNode.js・Python・.NETの更新手順
  4. 2026.07.09　テックブログ Muse Imageとは？Metaの画像生成AIの使い方・API料金（1枚0.01ドル）と日本での提供状況【2026年10月】
  5. 2026.10.21　テックブログ ユミルリンク不正アクセス第二報で延べ5,162万件：Cuenote FC利用企業と受信者の確認点

RELATED POSTS 関連記事

一覧へ戻る

目次