【転載】マルウェアEmotetの活動再開(2020/07/17-)

マルウェアEmotetの活動再開(2020/07/17-):



2019年より日本に向けても活動を行っているマルウェアEmotet (2020/02/07以降活動休止) が2020/07/17より約5ヶ月ぶりに活動を再開しました。



※Emotetは休止以前と基本的な挙動は変わっていません。以下の記事の内容は有効です。

マルウェアEmotetについて

・Emotet感染時の対応


■活動再開とは

活動再開、というのは何を意味しているかというと「Emotetに感染した端末がEmotetに感染させるようなメールの送信を再開した」ということです。


2020/02/07以降もEmotetは感染した端末上でC2と通信を行い、Emotet自身のバイナリの更新などを行っていました。
しかし、メールの送信活動は2/7以降確認されていませんでした。
今回、メール送信活動が確認されたため、Emotetの活動再開、といわれています。



最初に確認したのはSpamhausです。

EMOTET UPDATE | We are observing more activity coming from the #Emotet #Botnet today. We are seeing email traffic from this botnet again. Both URLs and Attachments are being utilized for distribution. #malspam #threatintel pic.twitter.com/9zrc9fWMlN
— Spamhaus (@spamhaus) 2020年7月17日
国際的なEmotet対策の有志のチームである @Cryptolaemus1 もすぐに確認しています。

#Emotet Quick Recap - E2 start spamming around 1400UTC - shortly there after @nazywam @spamhaus alerted us to this. E2 was confirmed to be spamming attachment docs and links. E3 seemed to fire up next doing both forms of malspam and then E1. All of them were spamming at 1530UTC.
— Cryptolaemus (@Cryptolaemus1) 2020年7月17日
 日本時間2020/7/17 23時(1400 UTC)頃からメール配信が始まったようです。Emotetの3つあるbotグループのうち、メインであるE2からはじまり、その後にE3,E1もメール配信が始まり全てのbotグループでメール配信が始まっています。その後7/18 7時(2200 UTC)頃まで続いたようです。



なお、活動休止中に何をしていたかというと、Emotetのバージョンアップを画策していたのではないか、と言われています。休止の直前にEmotetの実行ファイルの大きなバージョンアップがあり、これが意図した通り動いていないのでは、という憶測もありました。実際、幾つかテスト的な動きや変更は見れたものの、予想されたように大きくバージョンアップされることはなかったようです。



■変更点

2/7以前と比較して、以下の点が変わっています。

  • デコイファイル(docファイル)の見た目
メールの添付ファイルまたはメール内のリンクからダウンロードされるファイルの中身の表示内容が新しくなっています。

f:id:bomccss:20200720163619j:plain

  • 感染ファイルのハッシュのユニーク化
端末がEmotetの実行ファイルに感染後、C2からファイルが更新される際にバイナリの一部が書き換えられ、端末ごとにハッシュが異なるハッシュに書き換えられるような処理が加わっています。
 以前から言われていますが、hashの一致による検出というのはEmotetに対しても無意味です。

  • (正確には2/6からの変更点)Emotetの感染後のファイル名と永続化の設定の変化
Emotetは端末に感染後、ファイル名を変えます。変更後のファイル名は2020/1ではハードコードされたリストの中から選択する形でしたが、現在は端末のC:\Windows\system32\フォルダにあるexeまたはdllのファイル名を選択するようになりました。
 また、以前は変更後のファイル名を特定のレジストリ(HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\配下)に書き込んでおり、これを調査することでEmotet感染有無を調べることが可能でしたが、現在ではこの設定は使われなくなり、感染の度に上記のフォルダ内にあるファイル名から選択され直します。

 これにより、Emotet感染有無を確認可能なツールであったJPCERT/CCの「EmoCheck」はすり抜けられてしまいます。



■変わっていない点

  • 感染手法
メールの添付ファイルまたはメール内のリンクからダウンロードされる.docファイルのマクロを有効化することで感染に至ることは変わりません。
感染しないためにはファイルを開かない、マクロを有効化しないことが重要な対策となります。

  • PoserShellによる実行ファイル取得
docファイルのマクロを有効化するとPowerShellが実行され、外部サイトへアクセスしEmotetの実行ファイルを取得してくることも変わりありません。

f:id:bomccss:20200722014402j:plain

PowerShellの引数から通信先を取得するには以下のツールで可能です。

CyberChef レシピ実装済URL
https://gchq.github.io/CyberChef/#recipe=From_Base64('A-Za-z0-9%2B/%3D',true)Decode_text('UTF-16LE%20(1200)')Split('%5C'','%5C%5Cn')Split('*','%5C%5Cn')Extract_URLs(false)Defang_URL(true,true,false,'Valid%20domains%20and%20full%20URLs') 
 インターネットへのPowerShellによるアクセスをWindowsFirewallなどで制限することでも感染を防ぐことが可能です。

  • 返信型メールとばらまき型メール
メールの本文は幾つかのテンプレートの中から選ばれるばらまき型メールと過去の正規メールの本文を窃取して会話している相手にメールを送る返信型メールがあります。
再開後のメールでも、既に同じようにどちらのパターンも確認されています。

EMOTET UPDATE | We are observing more activity coming from the #Emotet #Botnet today. We are seeing email traffic from this botnet again. Both URLs and Attachments are being utilized for distribution. #malspam #threatintel pic.twitter.com/9zrc9fWMlN
— Spamhaus (@spamhaus) 2020年7月17日


■日本への影響

既に、日本でもEmotetに感染するメールの受信を確認しています。

エモいのきた。 #Emotet https://t.co/2ZXPGRGy6p
— _roku_ (@00001B1A) 2020年7月17日
日本語ではありませんが #Emotet 来ました。
Subject: Estimate R9334
Filename:Estimate.doc
Hash(MD5):a419ea9e968fb2d21f38927014a24210
Anyrun:https://t.co/BFYzqQJAhy pic.twitter.com/nFnbYPcXbY
— さとっぺ (@satontonton) 2020年7月21日
また、国内のメールサーバ/メールアカウントを利用してメールを送信されることも確認しています。以前より国内外のリサーチャーらと協力し、そういったアドレスを収集し可能な範囲で被害者へ連絡を入れています。今回は活動再開後の数時間で20以上のアドレスが共有されました。(被害者には通知済です。)

f:id:bomccss:20200722020048j:plain

これらのアドレスがどうやってEmotetに窃取されてしまったのかというと、2月以降も継続的にEmotetに感染したままだったと考えられます。(Emotetは一度感染した後も定期的に自身を更新し続けるため、アンチウイルスソフトにより検知・駆除することが困難です。)

Emotetは6月以降にメール情報を窃取するモジュールを感染端末で使用し始めていました。その時にメールアカウント情報が盗まれてしまい、メール拡散の基盤として悪用されてしまったのだと考えられます。
観測されている返信型メールでは、6月や7月に送受信したメールを悪用されているケースもあり、これも同じモジュールによるものと考えられます。

Emotetの攻撃者グループも活動再開をする準備を行った上で活動再開しているということが考えられます。


■活動再開後の動き

2020/07/17(金)に活動再開後、翌営業日の2020/07/20(月)の同じく23時頃より、再度Emotetに感染させるメールの送信活動を再開しました。

#emotet C2 binary update ~13:30 UTC 20200720

only E2 changes at the moment, update will follow

spamming on E1/E2 currentlyhttps://t.co/N6Y3ePaTRm
— Cryptolaemus (@Cryptolaemus1) 2020年7月20日
 E1, E2が動いた1時間後からE3も動き出しました。金曜日はテストなのか以前に比べて配信ボリュームも小さかったですが、月曜日はより大きな配信量となっていました。

 また、7/20(月)よりEmotetが他のマルウェアに二次感染させるようになりました。休止以前より活発に感染させていたTrickbotです。
TrickbotはGtagがmor113でした。過去2/7の時点ではmor93であり、休みの5ヶ月の間にも恐らくはEmotetからTrickbotへの二次感染は行われ続けていた(検知回避を目的としてTrickbotもEmotetによって約20回(約週1回)更新されていた)のだと考えられます。

#Trickbot observed on #Emotet, Epoch1. Gtag: mor113.
Stay safe out there guys. I'll see if I can share the sample I have.
— James Quinn (@lazyactivist192) 2020年7月20日
2020-07-20 (Monday) - Data dump: #Emotet infection with #Trickbot - includes an #Emotet only #pcap from Friday 2020-07-17 - and 14 examples of Emotet #malpsam (3 with attachments, 11 with links) from today (Monday) - https://t.co/uij4uSIyyf pic.twitter.com/qHkT2OMS2Q
— Brad (@malware_traffic) 2020年7月21日 
二次感染するマルウェアは7/21 午後にはQbot (Qakbot) に変更されました。

17時頃にEmotetからQbotに二次感染するケースが確認されました。

qbot のsamplehttps://t.co/6H4ZMl7ed7
— bom (@bomccss) 2020年7月21日
 配信手法にも変化があり、docの添付ファイルとメール本文のリンクからのdocファイルだけでなく、7/21には添付したpdfファイルに含まれるリンクからdocファイルへ誘導するタイプが出ました。

Proofpoint researchers have observed a shift in #Emotet payload delivery. Geos include #Argentina #Brazil #Canada #Chile #Ecuador #Mexico #US #UK. Malicious URLs are now being distributed in PDFs, in addition to maldocs & malicious URLs in email body.
— Threat Insight (@threatinsight) 2020年7月21日
メール配信で使用されるテンプレートの言語も、始めは英語だけだったものが、 スペイン語、フランス語、ポルトガル語、と日々増えています。

日本時間 7/21 のEmotetの動きは

感染経路として
・docの添付ファイル
・メール内リンクからdocファイル
・pdfの添付ファイル内のリンクからdocファイル

メールの本文テンプレートは英語以外も出現(4言語)したが、日本語はまだ確認されていない。

しかし、返信型メールは日本にも既に着弾している https://t.co/xmLRDFw28b
— bom (@bomccss) 2020年7月21日
<2020/07/23追記>
2020/07/23 8:30頃より、日本語の件名、本文、添付ファイルのEmotetに感染するメールが確認されました。

2020/07/23 8:30頃より、日本語件名の #Emotet のメールの送信を確認しました。

以前にも来ていた、請求書系の件名です。https://t.co/LexHXzwDZU

ご注意ください。 pic.twitter.com/Ex78DN7PWT
— bom (@bomccss) 2020年7月23日
【注意】#Emotet
日本語の件名、本文、添付ファイル名のメールを観測しました。

件名:請求書の件です。 17447 20200723

sample:https://t.co/bCx6BYdVmj pic.twitter.com/aJAsW2lKLC
— sugimu (@sugimu_sec) 2020年7月22日
幾つかのi日本語パターンを確認しました
送信には窃取されたメールアカウントが使われているため、差し出しメールアドレスが異なる点に注意ください。 pic.twitter.com/cxpgkfwgjW
— moto_sato (@58_158_177_102) 2020年7月23日
今朝届いた #emotet メールです。
件名:請求書の件です (ランダムな数字)_(日付)
File:(件名と同じ).doc pic.twitter.com/itep2hBLAU
— さとっぺ (@satontonton) 2020年7月23日
  休止前に使われていたテンプレートが再度利用されるようになりました。以前の件名と添付ファイル名のパターンはこのようになりますが、今回も同様のものが観測されています。

f:id:bomccss:20200723121306j:plain



■今後の動き

総じて、Emotetは活動を再開した、と言って良いと考えられます。
これは、メール送信を再開した、ということだけではなく、サイバー犯罪グループとして利益を最大限巻き上げるための活動を再開した、という意味です。
そしてそのための攻撃活動は徐々に勢いを増していく、と考えられます。

Emotetは自身に感染させることでメール配信基盤を構築し、更に感染数を増加させます。5ヶ月の休止期間で多少は減ったであろう感染端末を再び取り戻すために感染数を増加させることに力を入れると考えられます。

それと同時に、メールを窃取することで、メールから文書を学習していこうとしているように感じられます。学習が終わった言語から、テンプレートが増えていくのではないかと考えられます。


1つ不思議な点として、活動再開後のメールテンプレートが非常に簡素なことです。返信型であれ、ばらまき型であれ、短くて種類も少ないです。活動休止前にはあんなにも巧妙なメールテンプレートを使っていたにも関わらず、それを再利用している気配がありません。
もしかしたら、EmotetのC2のメール情報を蓄えていたDB(で表現が正しいかは不明ですが)が意図的かは不明ですが初期化されたのかもしれません。それにより、イチからメール情報を学習し直しているのかもしれません。
もしそうであれば、日本語を学習されないためにも感染端末を増やさない、減らしていくことが重要です。



<2020/07/23追記>
Emotetの活動再開後、日本語のメールが使われる前から、感染端末と見られる数は日々増加しています。

そして、日本を明確に標的としたEmotetに感染するメールが確認されました。日本も標的としてますます感染端末数が増えてしまうことが懸念されます。

既に同じ組織内でEmotetに感染するメールを送りあって組織内の感染が増えてしまっているとみられるものも出てきています。

活動休止前に使われていたメールテンプレートの再利用も確認されました。 今後、ますますメールのテンプレートのパターンが増加してくることが予想されます。中にはとても巧妙なもの(件名:会議開催通知)もありましたので、注意が必要です。

■最後に

残念ながら日本国内には既に感染端末は多数存在します。感染による負の連鎖で感染端末が再び日本国内で爆発的に増加しないように、対策を取る必要があります。対策は休止前と何も変わりません。

個人としては、docファイルは開くかどうか特に注意する、マクロの自動実行は許可しない、デコイ文書の画像が見えたらマクロは有効にしない。

組織では、メールセキュリティ製品でマクロ付きdocファイルを規制する、PowerShellによる外部への接続を制限する、URLHausのfeed( https://urlhaus.abuse.ch/api/ )を取得しブロックリストに加える、感染拡大防止のために管理共有を無効化しておく、といった対策が必要です。

少しでも感染する機会が減ることを願っています。

【転載】最新の状況に刷新「TLS暗号設定ガイドライン」など公開(NICT、IPA)

最新の状況に刷新「TLS暗号設定ガイドライン」など公開(NICT、IPA):

国立研究開発法人情報通信研究機構(NICT)と独立行政法人情報処理推進機構(IPA)は7月7日、共同で運営する「暗号技術活用委員会」の2019年度の活動成果として、「TLS暗号設定ガイドライン」第3.0版および「暗号鍵管理システム設計指針 (基本編)」第1版を作成し、公開した。TLS暗号設定ガイドラインは、2020 年 3 月時点における TLS 通信での安全性と相互接続性のバランスを

踏まえた TLS サーバの設定方法を示すもの。



以前の「SSL/TLS 暗号設定ガイドライン(version 1.x/2.x)」発行以降、TLS1.3 発行[RFC8446]や、SSL3.0禁止[RFC7525]、ChaCha20-Poly1305 追加[RFC7905]、RC4 禁止[RFC7465]など、同ガイドラインの記載内容に大きく影響する規格化が相次いで行われており、SSL/TLS の利用環境も大きく変化した。また、推奨セキュリティ型で利用が認められていた TLS1.0 や TLS1.1 は、本ガイドラインではセキュリティ例外型のみで利用可能としている。



具体的には、次のような要求設定となっている。



・高セキュリティ型

TLS 1.2

→TLS 1.3(必須)およびTLS 1.2(オプション)

・推奨セキュリティ型

TLS 1.2~TLS 1.0のいずれか(PFSなしも推奨)

→TLS 1.2(必須)およびTLS 1.3(オプション)、PFSのみ推奨

・セキュリティ例外型

TLS 1.2~SSL 3.0のいずれか

→TLS 1.3~TLS 1.0のいずれか



また、以前のバージョンではすべての設定項目が「要求設定」となっていたが、本バージョンでは設定項目が安全性へ寄与する度合いを考慮し、最低限の安全性を確保するために必ず満たさなければならない「遵守項目」と、当該設定基準としてよりよい安全性を実現するために満たすことが望ましい「推奨項目」に分け、より現実的かつ実効性の高い要求設定としている。



章構成においても、以前のバージョンでは「プロトコルバージョンの設定(4 章)」「サーバ証明書の設定(5 章)」「暗号スイートの設定(6 章)」として、それぞれの章に高セキュリティ型、推奨セキュリティ型、セキュリティ例外型の設定項目を記載していたが、本バージョンでは「推奨セキュリティ型の要求設定(4 章)」「高セキュリティ型の要求設定(5 章)」「セキュリティ例外型の要求設定(6 章)」とし、それぞれの章にプロトコルバージョン、サーバ証明書、暗号スイートの設定項目を記載。参照しやすくしている。



暗号鍵管理システム設計指針 (基本編)は、セキュアな暗号アルゴリズムを利用する上で極めて重要な役割を果たす「暗号鍵」の管理に関する在り方を解説し、暗号鍵管理システム(CKMS:Cryptographic Key Management)を設計・構築・運用する際に参考すべきドキュメントとして作成されたもの。暗号鍵管理の位置づけと検討すべき枠組みや、技術的な内容について解説している。

《吉澤 亨史( Kouji Yoshizawa )》




バックアップ

事業会社におけるセキュリティの位置付け


ガートナーの長谷島さんの本「変革せよ!IT部門」を読んで、事業会社におけるセキュリティの位置づけが少し進んだ。

事業会社におけるセキュリティとは、果たして何なのだろうか。

対策を怠ると機密情報が流出したり、企業のブランドイメージを毀損する等に繋がる一方で、セキュリティに投資をしても売り上げ増には繋がらない。

となると、コストに位置付けられる。

頑張ってもCSR(企業の社会的責任)強化程度の説明にしかならない。

一方で、このセキュリティをITガバナンスの一部としてみると、少し景色が変わってくる。



ITガバナンスとして俯瞰するとセキュリティはJ-SOXやIFRSと同列のものとして出てくる。

J-SOX対応やIFRS対応をコストだからと言ってケチる経営者はいるのだろうか?

セキュリティもJ-SOXやIFRSと同様の統制強化の一環として取り組めば、コスト云々の苦行から脱することができるのではなかろうか?

ただ、J-SOXやIFRSはある程度のゴール設定があるのに対して、セキュリティはDXの一部でもあり、明確なゴールは設定できない(正確には設定しても時間の経過とともに変わってしまう)。

そうなると、アプローチとしては「やるべきこと」をまずは洗い出し、優先順位を立てて絞り込んでいく流れとなる。

絞り込みのアプローチの一つとしては、原資を明確にすることである。

セキュリティの原資はIT予算における比率で計算する。

で、IT予算はどう計算するのかというと、企業の売上高から計算する。

例えば、売上高1,000億円のA社があるとする。

一般社団法人日本情報システム・ユーザ協会(JUAS)の調査によると、金融業界のIT 予算(19年度)はトリム平均で売上高の1.28%となっている。

まず、ここから適切なIT予算を試算する。

1,000億円x1.28%=12.8億円

次に、このIT予算からセキュリティ対策の原資を試算する。

JUASの調査によると、 IT 予算中の情報セキュリティ関連費用割合は、15%以上と 5%未満の高低 2 極に分かれる傾向にあるので、15%のケースと、平均して10%のケースで試算してみる。

15%のケース:12.8億x15%=1.92億円

10%のケース:12.8億x15%=1.3億円

これで、セキュリティ対策の原資が出せたので、「やるべきこと」の優先順位を踏まえて対策の予算化を行う。

これは、IT予算からの算出アプローチだが、同様に売上高に占めるJ-SOX対応やIFRS対応のコストと比較しながらセキュリティ対策の原資試算を行ってみてもいいかもしれない。

【参考】
企業IT動向調査報告書2020一般社団法人日本情報システム・ユーザ協会(JUAS)

セキュリティ対策の基本はシステムの運用管理徹底にアリ!?


2020年7月までに国内外の複数のドメイン名が「Subdomain Takeover」とみられる影響を受け、当該サイトに接続した利用者が詐欺サイトに誘導される事象が発生している。

自分も調べてみたところ、日本〇〇〇産業のサブドメインがことごとく詐欺サイトに転送される様を目の当たりにした。

今回の件、正解かどうかは置いておいて、自分の中では↓の様に一旦理解した。


情報セキュリティには3つの脅威があるといわれている。

■技術的脅威
プログラムが介在するもの。

・マルウェア
・フィッシング詐欺
・標的型メール
・クロスサイトスクリプティング
・バッファオーバーフロー攻撃
・Dos攻撃
・ポートスキャン
・ゼロデイ攻撃
・総当たり攻撃、etc

■人的脅威
直接 人が関わるもの。

・操作ミスによるデータ消失
・外部にパソコンやUSBメモリーを持ち出して紛失
・内部関係者による意図のあるデータ抜き取り
・メール誤送信による情報漏洩
・パソコンや記憶機器などの盗難

■物理的脅威
物理的に破損したり妨害されたりするもの。

・地震
・洪水
・火災、etc

すべての脅威は大体この中に当てはまるという。

で、今回の「Subdomain Takeover」は何に当たるか?

個人的な見解は「人的脅威」である。

今回は役目を終えたDNSのCNAMEレコードを消さずに放置するという、事業会社のITシステムの管理責任の怠慢である。

cloudapp[.]netの名前が出たが、これはあくまで事件の舞台の話であり、最終責任は利用する企業の側にある。

事業会社が契約しているクラウドの設定を誤って自社の機密情報を露出させるのと同じレベルである。

個人的にはこういったITシステムの管理がだらしない会社は実名公表していったほうが、長期的にはIT部門のためになると思うのだが。。。

【参考】
https://piyolog.hatenadiary.jp/entry/2020/07/08/025056
https://blog.shibayan.jp/entry/20200707/1594111967
https://twitter.com/hdais/status/1280355564208353282
https://www.pc-master.jp/security/kyoi.html

【転載】Subdomain Takeoverによる詐欺サイトへの誘導についてまとめてみた

Subdomain Takeoverによる詐欺サイトへの誘導についてまとめてみた:

2020年7月までに国内外の複数のドメイン名が「Subdomain Takeover」とみられる影響を受け、当該サイトに接続した利用者が詐欺サイトに誘導される事象が発生しています。ここではこの事象に関連する情報をまとめます。

何が起きてるの?

f:id:piyokango:20200708011658p:plain誘導される詐欺サイトの一例

  • 大手組織を含む複数のドメイン名において、検索サイトから接続した際に詐欺サイトへ遷移させる事象が発生していた。
  • 各組織管理のサーバーやレジストラ、CDNサービスが直接被害を受けたのではなく、Subdomain Takeoverと呼称される手法により過去使用されていたドメイン名が狙われたとみられる。

どう対応すればよい?


  • 不要なCNAMEレコードを削除する。

影響範囲は?

  • 正確な被害状況は把握していないが、複数の国内外のドメイン名が影響を受けており、検索にかかるものだけでも100件以上をpiyokangoは確認(2020年7月7日時点)。既に対応されたものを含め、日本の上場企業のドメイン名でも今回の被害を確認している。
  • 影響を受けたドメイン名においてサブドメインに使用される文字列から、開発(dev)やテスト(test)、デモ(demo)等の一時的な利用目的だった可能性がある。
f:id:piyokango:20200708012045p:plain影響を受けたドメイン名は「近日公開」とトップページに掲載されていたf:id:piyokango:20200708023525p:plain同じ構成のページが検索に複数表示される状況

自組織が影響を受けた(受ける)か確認するには?

  1. 自組織のドメイン名において、CDN等の外部のサービス(今回のケースではMicrosoft Azureが確認されている)を定義したCNAMEレコードが存在するかを確認する。
  2. 該当のCNAMEレコードが存在する場合、定義されたサービスが正常に稼働しているかを確認する。

Subdomain Takeoverって何?

f:id:piyokango:20200708021053p:plain今回確認されたSubdomain Takeoverのケース

  • Not foundとなったCNAMEレコードを対象に、自組織で管理するサブドメインが被害に遭う攻撃手法。
  • CDN等の外部サービスが定義されたCNAMEレコードにおいて、定義先のサービスを終了したにもかかわらずCNAMEレコードがそのままとなっている、かつ外部サービス側で使用されるドメイン名に第三者が任意のサブドメインを指定でき所有確認等が行われない場合、影響を受ける可能性がある。*1
【Subdomain Takeover】
①Webサイトを立ち上げ(一般的な運用)
- CDNを契約
- CDNへのCNAMEを、自分のドメイン名に設定

②Webサイトを終了
- CDNを終了
(この時点でCNAMEの参照先が削除、Not foundに)
- CDNへのCNAMEはそのまま
(削除の必要があると思ってない or 削除忘れ)

この状態で、
— Yasuhiro Morishita (@OrangeMorishita) 2020年7月7日
(承前)
③悪意を持つ第三者が、この状態のドメイン名を発見
- この状態のドメイン名は、Subdomain Takeoverに対して脆弱
④悪意を持つ第三者が、一般客として同じCDNを契約
- CNAMEの参照先と同じドメイン名のWebサイトを、CDN上に作成

→ Subdomain Takeoverが成立
— Yasuhiro Morishita (@OrangeMorishita) 2020年7月7日

確認されている被害は?

  • 被害を受けたドメイン名の解決先が攻撃者が設置したAzure上のサーバーとなり、検索サイトから接続した場合、このサーバーよりリダイレクトされ最終的に詐欺サイトへ誘導される。
  • 攻撃者のサーバー上には検索サイトに表示されることを目的にしたと推定される無数のランディングページが存在している。トップページにはsitemap.xmlが設置されており、ある被害を受けたドメイン名配下のsitemap.xmlでは3万件以上のURLが掲載されていた。
f:id:piyokango:20200708020807p:plain大量のランディングページが存在か

関連情報

  • Subdomain Takeoverの影響は第三者にWebサイトが設置されるというだけでなく、稼働するサービスに影響が及ぶ可能性もある。最近では2020年4月に修正されたMicrosoft Teamsのアカウントハイジャックの脆弱性が有名。www.cyberark.com
  • 以下の方の情報を参考にさせていただきました。
MS Azure Cloud Services のデフォルトドメイン cloudapp[.]net にCNAMEが向いている大量のWebサイトが改ざんされているようです。
Googleでの検索結果には何れも星評価が付いています。
(1/N) pic.twitter.com/5kDUZTGPg2
— tike (@tiketiketikeke) 2020年7月6日




diary.shift-js.info

更新履歴

  • 2020年7月8日 AM 新規作成