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）:

TLS暗号設定ガイドライン

国立研究開発法人情報通信研究機構（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」とみられる影響を受け、当該サイトに接続した利用者が詐欺サイトに誘導される事象が発生しています。ここではこの事象に関連する情報をまとめます。

何が起きてるの？

誘導される詐欺サイトの一例

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

どう対応すればよい？

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

影響範囲は？

正確な被害状況は把握していないが、複数の国内外のドメイン名が影響を受けており、検索にかかるものだけでも100件以上をpiyokangoは確認（2020年7月7日時点）。既に対応されたものを含め、日本の上場企業のドメイン名でも今回の被害を確認している。
影響を受けたドメイン名においてサブドメインに使用される文字列から、開発(dev)やテスト(test)、デモ(demo)等の一時的な利用目的だった可能性がある。

影響を受けたドメイン名は「近日公開」とトップページに掲載されていた f:id:piyokango:20200708023525p:plain

同じ構成のページが検索に複数表示される状況

自組織が影響を受けた（受ける）か確認するには？

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

Subdomain Takeoverって何？

今回確認された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が掲載されていた。

大量のランディングページが存在か

検索結果にも表示されるケースが確認されており、今回の事案の影響を受けたサイトに対してなりすまされた組織側が注意喚起を行っている。

更新履歴

2020年7月8日 AM 新規作成

*1:AWSのCloudfrontではSubdomain Takeover対策とみられる仕組みが導入されているとの情報がある

ノーモア〇〇〇〇

「ノーモア....」と聞いて、後続の言葉として何が思い浮かぶだろうか？

恐らく、圧倒的に多いのは「ノーモア映画泥棒」だと思う。

また、セキュリティ業界の多くの方は「ノーモアランサム」を連想される方もいるかもしれない。

んで、今日のテーマは「ノーモアコンサル」である。

自分は事業会社サイド(=ユーザー企業)のITに長く携わってきたが、ガートナーの長谷島さんの本「変革せよ！IT部門」は結構納得させられることが多い。

ユーザー企業のIT担当の価値とは何だろうか？

それは自社に最適なITシステムを導入し、そのシステムのマネジメントを通じて自社の利益に貢献(又はリスクの最小化に貢献)することである。

当然ITシステムの導入に際しては自社単体では難しいので、ITベンダーを活用する。

ユーザー企業におけるIT担当の価値は、ここでITベンダーの意見を鵜呑みにせず、自分自身の考えるあるべき姿や、自社にとってのベストプラクティスは何かを考え、ITベンダーやコンサルをマネージすることである。

そして導入～運用フェーズに向けてはドキュメント化を進め、内製化を行い、ランニングコストの最適化を図る。

また、自社のIT戦略策定についても最初は自社単体では厳しいため、コンサルを活用する。

しかし、コンサルに丸投げで後はヨロシクでは駄目である。コンサルがまとめたものは所詮はコンサルがまとめたものであり、それを踏まえて、自社のITシステム担当が最後は責任をもって作り上げるのである。

可能であれば、コンサルに任せた戦略策定のプロセスそのものも吸収して内製化し、次回の戦略策定からは自社で実施するというのもありかもしれない。

自分はこれがユーザー企業におけるIT部門の価値だと思う。

これを怠り、ITベンダーやコンサルに丸投げを続けて自身の価値を落としていくと、↓みたいな結果を招く。

ソニー、社内IT業務をアクセンチュアに委託

ITベンダーやコンサルは適材適所で使用するのは全く構わないが、過度に依存しすぎるのはまずい。

長谷島さんも本に書いているが、間違ってもよいので、自分たちで考えることが重要である。

出典：変革せよ！IT部門

【転載】新しい Behave! 拡張機能は、ウェブサイトのポートスキャン、ローカル攻撃について警告します。

新しい振る舞い!拡張は、ウェブサイトのポートスキャン、ローカル攻撃を警告します:

振る舞うという新しいブラウザ拡張機能!Web サイトがスクリプトを使用して、ネットワーク上のローカルおよびプライベート IP アドレスに対してスキャンや攻撃を実行している場合は、警告が表示されます。

Web を参照する際、Web ページに埋め込まれたスクリプトを使用して、訪問者のコンピュータを開いている TCP ポートをポートスキャンするだけでなく、ネットワーク上の他のデバイスへの攻撃を開始することもできます。

5月には、eBay、シティバンク、TDバンクなどの有名なサイトが訪問者のコンピュータをポートスキャンして、その上で実行されているWindowsリモートアクセスプログラムを識別することが判明しました。

eBay ポートスキャンサイト

ソース: ブリーピングコンピュータ

このポートスキャンは、サイトを使用しようとしている潜在的にハッキングされたコンピュータを検出するために使用される詐欺防止スクリプトによって行われました。

正当な理由で行われている間、ポートスキャンされているユーザーは、侵入的でプライバシー侵害を見つけます。

さらに悪いことに、悪意のあるアクターは、Web サイトに埋め込まれた JavaScript を使用して DNS 再バインド攻撃を実行します。

DNS 再バインド攻撃は、DNS 解決が短い TTL を介して操作され、被害者のコンピュータを使用して同じ発信元ポリシー (SOP) をバイパスし、内部ネットワーク上の他のデバイスに対する攻撃を開始する場所です。

これらの攻撃は、ルータ、IoT デバイス、および脆弱なソフトウェアを実行することが知られている他の内部コンピュータに対して使用される一般的なです。

行きの行き見を入力してください!ブラウザ拡張機能

ステファノ・ディ・パオラ、共同創設者、CTO、マインドセキュリティのチーフサイエンティスト、ベベ動作によって作成されました!ブラウザ拡張機能は、訪問者のコンピュータ上でローカル攻撃やスキャンを実行するためにブラウザ機能を悪用するWebサイトのユーザーに警告する実験として生まれました

「振る舞う!これらの機能の一部を乱用する可能性のある Web ページの動作に関する概念的な実験として生まれました。これからも、意識を高めるのに役立つ長期的なプロジェクトになるかもしれない」と語った。

「例えば、ローカルポートスキャン、クロスプロトコル攻撃、DNS再バインドは、Webエコシステムのコア機能を乱用しているため、ブラウザベンダーによってまだ可能であり、完全に「修正」することは困難な非常に古い攻撃です。

インストールすると、振る舞う!次のブロックに属する IP アドレスにアクセスしようとするスクリプトを監視します。

ループバックアドレス IPv4 127.0.0.1/8
ループバックアドレス IPv6 ::1/128
プライベートネットワーク IPv4 10.0.0.0/8 172.16.0.0/12 - 192.168.0.0/16
一意のローカルアドレス IPv6 fc00::/7

検出された場合、拡張機能のアイコンには赤いインジケータが表示され、クリックするとサイトによって実行されたアクティビティが一覧表示されます。

動作！eBay からのポートスキャンの警告

拡張機能は、動作が検出されたときにブラウザー通知を表示するように構成することもできます。

ブラウザ通知

拡張機能のバグが DNS 再バインドアラートで誤検出を引き起こす可能性があり、ディ Paola は修正に取り組んでいます。

行き振る舞い!拡張機能は、クロムとFirefoxの両方のために利用可能であり、ディパオラは、彼がエッジとサファリのためにそれをリリースしたいと私たちに言いました。

将来追加したいと考えている機能には、「ローカル接続を実行すると予想されるホワイトリストのウェブページ/ホスト名」や「不審なアクションを実行するコードを追跡する」機能などがあります。

あなたが訪問するウェブサイトからの潜在的に虐待的な行動について警告されることに興味がある人のために、振る舞ってください!インストールする興味深い拡張機能です。

ー以下原文ー

A new browser extension called Behave! will warn you if a web site is using scripts to perform scans or attacks on local and private IP addresses on your network.

When browsing the web, scripts embedded on web pages can be used to not only port scan a visitor's computer for open TCP ports, but also initiate attacks on other devices on your network.

In May, it was discovered that well-known sites such as eBay, Citibank, TD Bank, and more would port scan a visitor's computer to identify Windows remote access programs running on it.

eBay port scanning a site
Source: BleepingComputer

This port scanning was conducted by the LexisNexis' ThreatMetrix fraud protection script used to detect potentially hacked computers trying to use the site.

While done for good reasons, users who are being port scanned rightfully find them intrusive and a privacy violation.

Even worse, malicious actors will also use JavaScript embedded on web sites to perform DNS Rebinding attacks.

DNS Rebinding attacks are where the DNS resolution is manipulated through short TTLs to use a victims' computer to bypass Same Origin Policy (SOP) and launch attacks against other devices on an internal network.

These attacks are commonly used against routers, IoT devices, and even other internal computers known to run vulnerable software.

Enter the Behave! browser extension

Created by Stefano Di Paola, co-founder, CTO, and Chief Scientist of MindedSecurity, the Behave! browser extension was born as an experiment to warn users of web sites that abuse browser features to perform local attacks or scans on a visitor's computer

"Behave! was born as a conceptual experiment around the behavior of web pages that might abuse some of those features, and if the interest on Behave! keeps raising, it might hopefully be a long lasting project to help raising awareness."

"For example local Port Scan, Cross Protocol attacks, DNS rebinding are very old attacks that are still possible and difficult to completely "fix" by browser vendors because they abuse core features of the Web ecosystem," Di Paola told BleepingComputer via email.

When installed, Behave! will monitor for scripts that attempt to access IP addresses belonging to the following blocks:

Loopback addresses IPv4 127.0.0.1/8
Loopback addresses IPv6 ::1/128
Private Networks IPv4 10.0.0.0/8 - 172.16.0.0/12 - 192.168.0.0/16
Unique Local Addresses IPv6 fc00::/7

If detected, the extension's icon will show a red indicator, and when clicked on, will list the activity conducted by the site.

Behave! warning of port scans from eBay

The extension can also be configured to show browser notifications when concerning behavior is detected.

Browser notification

It should be noted that a bug in the extension may cause false positives on the DNS Rebinding alerts, and Di Paola is working on a fix.

The Behave! extension is available for both Chrome and Firefox, and Di Paola has told us that he hopes to release it for Edge and Safari.

Some features that Di Paola hopes to add in the future include "white listing web pages/hostnames that are expected to perform local connections" and the ability to "track back the code performing the suspicious actions."

For those interested in being warned about potentially abusive behavior from web sites you visit, Behave! is an interesting extension to install.

登録: 投稿 (Atom)

blog.b-son.net