【転載】少し前のブログ記事ですが、ここにあるコマンドの実行を検知したりブロックするするだけでも、内部侵入の気づきや阻止に役立ちそうですね…😌

少し前のブログ記事ですが、ここにあるコマンドの実行を検知したりブロックするするだけでも、内部侵入の気づきや阻止に役立ちそうですね…😌 （最近も傾向は変わってないのかな…🤔） blogs.jpcert.or.jp/ja/2015/12/win…: 少し前のブログ記事ですが、ここにあるコマンドの実行を検知したりブロックするするだけでも、内部侵入の気づきや阻止に役立ちそうですね…😌
（最近も傾向は変わってないのかな…🤔）
blogs.jpcert.or.jp/ja/2015/12/win…

ーー

Windows OSには標準で多数のコマンド(以下「Windowsコマンド」といいます。)がインストールされています。しかし、ユーザが実際に利用するのは多くの場合そのうちのごく一部です。一方、侵入した攻撃者も情報を収集し、あるいはネットワーク内で感染を拡大させるためにWindowsコマンドを使っていることをJPCERT/CCの調査で確認しています。ここで注目されるのは、普通の利用者が使うWindowsコマンドの集合と攻撃者が使うWindowsコマンドの集合のずれです。両者が大きく違っていれば、Windowsコマンドの実行状況を監視または管理することで、攻撃者の動きを検知あるいは抑制できることになります。
今回は、攻撃者が侵入したWindows OS上で使用するWindowsコマンドを明らかにし、攻撃者は使うが各ユーザにとっては不要なWindowsコマンドの実行を制限することで、攻撃による影響を低減する方法を示します。

遠隔操作のためのマルウエア(RAT)には、リモートからコマンド・シェルを実行する機能があります。この機能を利用すると、Windowsコマンドをリモートから実行することが可能です。
そのようなマルウエアをネットワーク内に侵入させた攻撃者は、次のような流れで侵入したネットワーク内のシステムを攻略し、機密情報の収集などを試みます。

①　初期調査：感染した端末の情報を収集する
②　探索活動：感染した端末に保存された情報や、ネットワーク内のリモート端末を探索する
③　感染拡大：感染した端末を別のマルウエアにも感染させる、または別の端末にアクセスを試みる

これらのすべての攻撃フェーズでWindowsコマンドが使用されます。以降では、各攻撃フェーズで使用されるWindowsコマンドについて紹介します。

初期調査

攻撃者が感染端末の情報収集によく使用するコマンドは、表1の通りです。なお、実行数は3つの異なる攻撃グループが使用していた各C&Cサーバで入力したWindowsコマンドの集計結果です(詳細は、Appendix A,B,Cをご参照ください)。

表1: 初期調査(上位10コマンド)

順位	コマンド	実行数
1	tasklist	155
2	ver	95
3	ipconfig	76
4	systeminfo	40
5	net time	31
6	netstat	27
7	whoami	22
8	net start	16
9	qprocess	15
10	query	14

攻撃者は、tasklistやver、ipconfig、systeminfoなどのコマンドを使用し、ネットワーク情報やプロセス情報、OS情報などを収集して、どのような端末に感染したのかを調査します。これによって、侵入した端末がマルウエア解析のためのおとり環境でないかなどを確認していると考えられます。

探索活動

機密情報の探索やネットワーク内のリモート端末の探索においては、表2のコマンドがよく使用されます。

表2:探索活動(上位10コマンド)

順位	コマンド	実行数
1	dir	976
2	net view	236
3	ping	200
4	net use	194
5	type	120
6	net user	95
7	net localgroup	39
8	net group	20
9	net config	16
10	net share	11

攻撃者は、ファイルを探索するためにdirおよびtypeを使用します。dirコマンドに適切な引数を指定することで、感染端末内のすべてのドキュメントファイルの一覧を収集することもあります。
ネットワークの探索にはnetコマンドが用いられます。特に次のコマンドが多用されます。

net view: 接続可能なドメインのリソース一覧取得
net user: ローカルおよびドメインのアカウント管理
net localgroup: ローカルのグループに所属するユーザ一覧取得
net group: 特定ドメインのグループに所属するユーザ一覧取得
net use: リソースへのアクセス

さらに、Active Directoryを使用している環境の場合、次のコマンドが利用されることもあります(Appendix A 表5参照)。これらのコマンドは、Windows Serverに搭載されているコマンドで、本来はWindows 7や8.1などのクライアントOSには存在しませんが、攻撃者はこれらのコマンドを外部からダウンロードしインストールした上で実行します。

dsquery: Active Directoryに含まれるアカウントの検索
csvde: Active Directoryに含まれるアカウント情報取得

感染拡大

ネットワーク内のリモート端末への侵入・感染拡大のフェーズでは、表3のコマンドがよく使用されます。

表3:感染拡大

順位	コマンド	実行数
1	at	103
2	reg	31
3	wmic	24
4	wusa	7
5	netsh advfirewall	4
6	sc	4
7	rundll32	2

※wmicは、探索活動などにも用いられます

atやwmicは、リモート端末上でマルウエアを実行するためによく利用されます。
atコマンドにより、次のように接続可能な端末に対してファイルを実行するタスクを登録することで、リモート端末上でコマンドを実行することができます。

at \\[リモートホスト名 or IPアドレス] 12:00 cmd /c "C:\windows\temp\mal.exe"

また、wmicコマンドにより、次のような引数を指定することで、リモート端末上のコマンドを実行することができます。

wmic /node:[IPアドレス] /user:”[ユーザ名]” /password:”[パスワード]” process call create “cmd /c c:\Windows\System32\net.exe user”

必要のないWindowsコマンドを実行制限する

これらの攻撃者が使うWindowsコマンドの中には、ユーザごとに吟味すれば、使用しないコマンドが含まれていると思います。そのようなコマンドを、AppLockerやソフトウエア制限ポリシーを使用して実行を制限することで、攻撃者の活動を抑えることができます。例えば、netコマンドを制限したい場合には、図1のようなルールを設定します。(AppLockerの設定方法について詳しくは、マイクロソフトのWebサイトをご参照ください）[1])

また、AppLockerを有効にすると、設定で指定されたWindowsコマンドが実行された、または実行しようとして拒否された事象がイベントログに記録されるようになり、マルウエア感染後に攻撃者が実行したWindowsコマンドを調査することにも活用できます。

なお、AppLockerではWindowsコマンドの実行を制限せずに監査のみを行うこともできます[2]。監査のみの場合、意図しないWindowsコマンドの実行は防げませんが、イベントログに実行の記録が残ります。攻撃に用いられるWindowsコマンドを利用者自身も使っている場合には、監査のみとするのもよいでしょう。(なお、Windowsコマンドの実行を監視するにはローカルセキュリティポリシーで、「プロセス作成の監査」を有効にすることでも記録することができます。)

おわりに

標的型攻撃においては、攻撃者は、マルウエアに組み込まれた機能だけを使って目的を遂行するわけではなく、Windowsコマンドも多用しています。そうした行為を阻むことができれば、比較的早い段階でインシデントの拡大を抑止することができます。とは言え、すぐにWindowsコマンドの使用を制限するのは難しいと思いますので、まずはAppLockerなどを使用して実行プロセスのログを取得することから始めてみるとよいでしょう。

分析センター朝長秀誠

参考情報
[1] Microsoft - Windows AppLocker
　　https://technet.microsoft.com/ja-jp/library/dd759117.aspx
[2] Microsoft - 監査を使用してどのアプリケーションが使用されているかを追跡する
　　https://technet.microsoft.com/ja-jp/library/dd723693%28v=ws.10%29.aspx

Appendix A 攻撃グループ別の実行コマンド一覧(攻撃グループA)

表4: 初期調査(攻撃グループA)

順位	コマンド	実行数	オプション
1	tasklist	119	/s /v
2	ver	92
3	ipconfig	58	/all
4	net time	30
5	systeminfo	24
6	netstat	22	-ano
7	qprocess	15
8	query	14	user
9	whoami	14	/all
10	net start	10
11	nslookup	4
12	fsutil	3	fsinfo drives
13	time	2	/t
14	set	1

表5:探索活動(攻撃グループA)

順位	コマンド	実行数	オプション
1	dir	903
2	net view	226
3	ping	196
4	net use	193
5	type	118
6	net user	74
7	net localgroup	35
8	net group	19
9	net config	16
10	net share	11
11	dsquery	6
12	csvde	5	/f /q
13	nbtstat	5	-a
14	net session	3
15	nltest	3	/dclist
16	wevtutil	2

表6:感染拡大(攻撃グループA)

順位	コマンド	実行数	オプション
1	at	98
2	reg	29	add export query
3	wmic	24
4	netsh advfirewall	4
5	sc	4	qc query
6	wusa	2

Appendix B 攻撃グループ別の実行コマンド一覧(攻撃グループB)

表7: 初期調査(攻撃グループB)

順位	コマンド	実行数	オプション
1	tasklist	29	/m /svc
2	whoami	6
3	ipconfig	5	/all
4	net start	4
5	netstat	3	-ano
6	nslookup	3
7	ver	2
8	time	1	/t

表8: 探索活動(攻撃グループB)

順位	コマンド	実行数	オプション
1	dir	62
2	net user	21	/domain /add
3	net view	9	/domain
4	ping	4
5	net localgroup	4	/add
6	tree	3	/F
7	type	2
8	net group	1	/domain

表9: 感染拡大(攻撃グループB)

順位	コマンド	実行数	オプション
1	at	5
2	wusa	5
3	reg	2
4	rundll32	2

Appendix C 攻撃グループ別の実行コマンド一覧(攻撃グループC)

表10: 初期調査(攻撃グループC)

順位	コマンド	実行数	オプション
1	systeminfo	16
2	ipconfig	13	/all /?
3	tasklist	7
4	netstat	5	-ano
5	whoami	2
6	net start	2
7	arp	1	-a
8	chcp	1
9	net time	1
10	ver	1

表11: 探索活動(攻撃グループC)

順位	コマンド	実行数	オプション
1	dir	11
2	net user	1	/all /?
3	net view	1
4	qwinsta	1	-ano

※　攻撃グループCは、感染拡大を行わなかったため、感染拡大のコマンドについては省略しています。

【転載】総務省：サイバー攻撃（標的型攻撃）対策防御モデルの解説

（メモ）総務省：サイバー攻撃（標的型攻撃）対策防御モデルの解説 soumu.go.jp/main_content/0…: （メモ）
総務省：サイバー攻撃（標的型攻撃）対策
防御モデルの解説
soumu.go.jp/main_content/0…

バックアップ

派遣エンジニアが起こした事件が理不尽だった件（転載）～いろいろな意味で〇ソだなと思った。派遣もシステムもプロパーも会社も、、、。～

派遣エンジニアが起こした事件が理不尽だった件:

どもども。僕はしがない派遣エンジニアです。

某零細企業から、某大手企業に派遣されています。

派遣先はお堅い職場です。

コロナのご時世ですが、リモートの「リ」も聞いたことありません。

万が一、データー漏洩した場合とんでもないことになりますからね（しらんけど

そんな職場ですが、わたくしは２年ほど勤めています。

お堅い職場ゆえに息苦しさもありますが、それが心地よかったりもします。

というよりも派遣という気軽な身分が合っているのかもしれません。

さて本題に。

こんな職場へ、新しい新人さんが入ってきました。

新人といっても50代のベテランエンジニア、Ａさんです。

もちろん派遣です。

Ａさんはどうにも「優秀ではないエンジニア」のようでした。

かろうじてプログラミングはできるけど、IＤＥの使い方、フレームワーク等はほとんど経験がないご様子。

何でもかんでもプロパーさんに聞いて回るので、「そんなことくらい自分で調べて！」と怒られていました。

確かにネットで調べれば済むことです。

Ａさんはそんな感じの方です。

で、案の定。

着任して3日でドキュメント整理という名の戦力外通告をされていました。

そんな時、事件は起こりました。

会社の役員様から「こんなメールが届いたけど、どうしたらいいの？」とシステム部門に連絡があったのです。

それは決算に関わる重要なメールだけど、身に覚えがないのだそうです。

私のチームがその担当システムだったため、すぐに調査をしました。

その調査中にも、ほかの役員様から「なんだこのメールは？」と問い合わせが入ります。

チームは慌てふためきます。

時間が経つにつれ、経理部のプロパーの方々が駆けつけ、システム部長、経理部長まで駆け付け、一大事になったのは、社内事情に詳しくない僕から見ても明らかでした。

「原因はまだわからんのか！！？」

原因究明は長引きました。

というのも。

その決算プログラムは、15年前に作られたＰＨＰプログラムで、度重なる改修の結果「よくぞここまで！」というくらいのスパゲッティになっていたからです。

社内にシステムの詳細を知る人間はおらず、ドキュメントも歯抜け状態。

プログラムを追うしかない状態でした。

操作ログもほとんどないシステムだったため、難航しました。

チームの派遣３名＋プロパー1名は、徹夜で調査。

その結果、１つの仮説が導き出されました。

「あいつがバッチを起動させたのでは？」

「あいつ」というのは、例のベテラン新人エンジニアＡさんです。

翌日、出勤してきたＡさんは問い詰められました。

もちろんＡさんは否定しました。

「私はまだ着任したばかりで、そんなことできっこない」と。

確かにその通りです。

「これをクリックしただろ？」

と、プロパーさんは画面の秀丸を指さしました。

それはシステムのドキュメントでした。

その中に、１つのＵＲＬが書かれていました。

プロパーさんはそれを指さしました。

「あぁー、押したかもしれませんね・・・」

そのＵＲＬは、決算システムの年次バッチを臨時に走らせる大変恐ろしい物だったのです。

しかも2005年の。

Ａさんはプロパーに激詰され、システム部門の臨時会議で罵倒され、経理部門でも罵倒され、役員の方々への謝罪行脚に出かけていきました（プロパーさん、システム部長、経理部長を伴って

Ａさんはまだ帰ってきません。

僕はＡさんになんて声をかければいいのでしょうか？

そもそもＡさんのどこに非があったのでしょうか？

Ａさんが支給されたパソコンの秀丸は、ワンクリックでUＲＬを開くようになっていました。

問題のバッチＵＲＬは、パスワードも必要なく。

もし誰かに非があるとするならば、秀丸ではないかと思うのです。

■追記

Aさんが罵倒された緊急会議でのこと。

僕はAさんを「凄い人だ・・・」と思いました。

「なんでこんなことしたんだ！」

「どうするつもりだ！」

と、激詰めされているにも関わらず、淡々と回答していたからです。

Aさんはとてつもない強靭な精神力を持つ人でした。

想像してみてください。

コロナにも関わらず、200人以上が常駐している広いフロアの真ん中にあるミーティングスペースで、多くの人がチラ見する中で罵倒される姿を。

会議の出席者の大半が敵であり、仲間であるはずの僕たちは、火の粉が降りかかるのを恐れて何も言えず、たった一人で戦わなくてはいけない状況を。

こんな恐ろしいことはありません。

「どうするんだ！！！？」

「どうやって収めるつもりなんだ！？」

「問題のデータはすでに特定しているので、すぐに修正できるかと・・・・」

「そういうことを聞いてるんじゃない！！！」

システム部長とプロパーさんでそんなやり取りがあった後、

「ご迷惑をおかけした方々に、私が直接謝罪します」と、Aさん。

「えっ・・・、おぅ・・・、それもいいかもな・・・」と、システム部長。

緊急会議はいったん解散し、部長会議が開かれたようで。

その後、Aさんが呼ばれ、謝罪行脚に出かけたのでした。

↓の動画の最後のコメントがすごくイイ

ロシアで宅配便ロッカーを強制解除するサイバー攻撃が発生 / Hacker opens 2,732 PickPoint package lockers across Moscow（転載）

Hacker opens 2,732 PickPoint package lockers across Moscow:

謎のハッカーがサイバー攻撃を利用して、モスクワ中の2,732個の宅配ロッカーのドアを強制的に開けました。

12月4日（金）午後に発生したこの攻撃は、モスクワとサンクトペテルブルク全域で8,000件以上の荷物ロッカーのネットワークを維持している地元の宅配サービス「PickPoint」のネットワークを標的にしています。

ロシア人はオンラインで商品を注文し、注文した商品を自宅の住所ではなく、PickPointのロッカーに届けることを選択できる。

荷物が届くと、ユーザーは電子メールやモバイル通知を受け取り、PickPoint アプリを使って注文を取りに行くことができる。

しかし、ユーザーがロッカーを開けて荷物を受け取ることができる同じシステムが金曜日に攻撃を受けました。

未だ特定されていないエクスプロイトを使って、謎のハッカーが PickPoint のロッカーの 3 分の 1 のドアを強制的に開け、モスクワ全域で数千個の荷物が盗難にさらされました。

攻撃の理由はまだ判明していないが、週末のプレスリリースで、ピックポイントは当局に通知したと述べた。

ロシアの同社は現在、攻撃で被害を受けたネットワークの復旧作業を行っているという。

また、ロッカーから荷物が盗まれたかどうかも不明のままだ。ソーシャルメディアの投稿によると、警備員や家主は金曜日に素早く介入し、明らかに故障しているロッカーへのアクセスを制限した。

同社が土曜日のプレスリリースで強調しているように、これは "ポストゲートウェイネットワークに対する世界初の標的型サイバー攻撃 "であるようです。

【転載】パッチマネジメントとは？方法や必要性、注意点について徹底解説

パッチマネジメントとは？方法や必要性、注意点について徹底解説:

IT企業に限らず、ビジネスでは多くのコンピュータが使われています。そのコンピュータの管理にかかせないのが「セキュリティパッチの更新」です。

セキュリティパッチとはコンピュータに存在する脆弱性を解消するプログラムのことです。マルウェアの感染やセキュリティホールを悪用したサイバー攻撃を防ぐためには、適切なセキュリティパッチの適用が欠かせません。

今回はセキュリティパッチの更新を管理する「パッチマネジメント」について紹介します。

この記事の目次

パッチマネジメントとは

パッチマネジメントとは、システムを構成しているコンピュータを管理して、脆弱性が発見されたときに適切にセキュリティパッチを適用させるための管理活動のことです。

セキュリティパッチはコンピュータに見つかった脆弱性を解消するために使用するプログラムです。ソフトウェアの中には、新しいセキュリティパッチが公開されたとき、ソフトウェアアップデート機能により自動的に更新するものもありますが、一部のコンピュータには、手動によるセキュリティパッチの適用が必要なものもあります。

しかしパッチマネジメントの導入により、セキュリティパッチの適用を効率的に漏れなく実施できます。それにより、コンピュータの脆弱性を確実に解決し、不正アクセスやマルウェアの感染のリスクを低減させられるのです。

セキュリティパッチとは？現状の確認と適用方法について徹底解説

2018.4.21

セキュリティパッチとは、公開されたソフトウェアで発見された問題点や脆弱性に対し、これらの不具合を解決するためのプログラムのことです。 WindowsなどのOSをはじめとした、お使いのソフトウェアおいて、このセキュリティパッチを更新し

パッチマネジメントの方法

パッチマネジメントは具体的には以下の3つの流れで進めます。

検知

脆弱性情報を公開しているWebサイトから、自社のシステムに関係のありそうな脆弱性情報を集めます。脆弱性情報の情報源には、具体的には以下のようなものがあげられます。

業界団体	IPA（情報処理推進機構） JPCERT/CC JVN iPedia NVD
有識者（専門家）	Twitter Facebook ブログその他SNS
ベンダ（製品メーカー）	各ベンダのWebサイト情報配信サービスプレスリリースメールマガジン

情報源としては上記3つがあげられますが、これらの情報を取りまとめているニュースサイトもあります。これらの情報を全て追いかけるのは手間がかかるので、自社で使っているソフトウェアや製品に関連する情報だけでも効率良く収集するように工夫しましょう。

判断

自社に関係のある脆弱性が判明したら、そのリスクの大きさと攻撃を受ける可能性を判断して、対策の緊急度と必要性を決定します。

脆弱性の緊急性の判断には「CVSS」を基準に考えるのが一般的です。

CVSS（Common Vulnerability Scoring System)とは

共通脆弱性評価システムと呼ばれ、下記3つの基準で脆弱性を評価する仕組みのことです。

基本評価基準（Base Metrics）
現状評価基準（Temporal Metrics）
環境評価基準（Environmental Metrics）

システムの種類や開発者、評価者などの違いに影響を受けないような、共通の尺度で深刻度を表す指標です。

自社においても脆弱性の深刻度を決定する基準として、CVSSのような指標を使い、あらかじめレベルごとの対応方針を決めておけば、迅速な対応が可能です。

対応

対策方法と対策時期を決めて、脆弱性を悪用したサイバー攻撃が発生する前に、脆弱性のリスクをできるだけ小さくします。しかし複数のシステムが混在している環境の場合、適切に対応されているのか把握しきれないことがあります。

そうならないためにも、複数のシステムを構築する際に、できるだけ共通の基盤を持つサービスを利用することがおすすめです。クラウドサービスの中には、パッチマネジメントの一連の手順を総合的に管理できるものも登場しています。

パッチマネジメントの必要性

包括的なパッチマネジメントを実施する必要性として、以下の2点があげられます。

脆弱性を悪用した攻撃を防ぐ

適切なパッチマネジメントにより、OSやアプリケーションソフトウェアにセキュリティパッチを適用することで、脆弱性を悪用した攻撃を防げます。

コンプライアンスを確保する

セキュリティパッチを適用しないと、コンピュータがマルウェアの感染するリスクが高まります。さらにマルウェアに感染したコンピュータから機密情報や個人情報が流出することで、社会的信用を失いことにもなりかねません。

パッチマネジメントを含めた情報セキュリティ対策は、コンプライアンスを確保する活動とも言えます。自社内のシステムの危険箇所を特定して、不正アクセスや改ざん、マルウェアの侵入を未然に防ぐことで、顧客情報や機密情報を守りことができます。パッチマネジメントは、情報保護ポリシーの実践や法令順守の活動の一環と言えるでしょう。

パッチマネジメントの注意点

パッチマネジメントの必要性はご理解いただけたかと思いますが、実際にはセキュリティパッチの適用が難しいケースもあります。特に以下のような場合は注意が必要です。

システムが多い場合注意

業務で使用しているシステムの数が多い場合、それら全てに対して適切にパッチマネジメントを行うことは困難でしょう。そもそも大規模なシステムの場合、システムで動作しているコンピュータの数ですら、把握できていないこともしばしばあります。また複数の種類の異なるコンピュータが混在している場合は、適用させるセキュリティパッチも異なるため、パッチマネジメントを効率的に行うことが難しくなります。

レガシーシステムに注意

古いソフトウェアで動作しているレガシーなシステムにも注意が必要です。レガシーシステムでは、アップデートのサポートの期限切れや、アップデートできない可能性があります。レガシーシステムといえ、現役で使われていることもあり、簡単には新しいシステムに代替できないこともあります。

パッチテストが必要

最新のセキュリティパッチでも、実際に適用させる前には十分なパッチテストが必要です。しかしそのパッチテストを実施するコンピュータの選定や、業務に影響が発生しないようにテストの時間帯などの調整も必要です。

組み込みシステムに注意

機能が限定された組み込みシステムは、全体を動作させているシステムの一部として動作していることがあります。そのような組み込みシステムは365日24時間動作させていることもあり、停止させてセキュリティパッチを適用させることが困難です。またそのような長期間動作している組み込みシステムは、古いOSが搭載されている可能性もあります。

未知の脆弱性に注意

セキュリティパッチは既知の脆弱性を解消するプログラムです。そのため未知の脆弱性を解決することはできません。未知の脆弱性が知れ渡り、その脆弱性に対するセキュリティパッチが完成するまでには時間がかかります。

まとめ

脆弱性対策にかかせないセキュリティパッチの適用を効率的に実施する、パッチマネジメントについて紹介してきました。

企業内で稼働しているコンピュータの数が多くなってくると、それらを効率的に管理するにも工夫が必要です。パッチマネジメントのために高いコストを投資して、包括的に管理できるシステムを構築できれば理想的ですが、そうは言っても予算をかけられない企業もあるでしょう。

そのような状況でも、自社にとって重要な情報やデータを把握し、システムのクリティカルな箇所から段階的にでもパッチマネジメントを進めていくことがおすすめです。ベンダが提供しているツールなどを有効に活用して、賢くパッチマネジメントを導入しましょう。

「EXILE TRIBE」の公式通販サイトでクレカ情報流出～想定損害賠償額は11億円程度か～

「EXILE TRIBE」の公式通販サイトでクレカ情報流出 - 一部不正利用も

「EXILE」や「三代目J SOUL BROTHERS」など、LDH JAPANに所属するアーティストのグッズを扱う公式オンライン通信販売サイト「EXILE TRIBE STATION ONLINE SHOP」が不正アクセスを受けたことがわかった。

同サイトを運営するLDH JAPANによると不正アクセスにより、8月18日から10月15日までの約2カ月間、決済処理を行うプログラムが改ざんされたほか、個人情報を含むサーバに対してもアクセスを受けた形跡が見つかったもの。

同サイトではクレジットカード情報を保持していないが、期間中にクレジットカード情報を新規に登録したり、変更を行った場合、第三者に情報を窃取されたおそれがある。

4万4663人分のクレジットカード情報が外部に流出した可能性があり、名義や番号、有効期限、セキュリティコードが含まれる。さらに11月27日の時点で、このうち少なくとも209人分のクレジットカード情報が不正に利用をされた可能性があるとの報告をクレジットカード会社より受けたという。

またログファイルの調査により、クレジットカード情報以外の個人情報が格納されたサーバについても不正アクセスを受けていたことが判明した。流出件数などは特定できなかったとしている。

報告書バックアップ

登録: 投稿 (Atom)