ブログとストーリー

SpiderLabsブログ

年間50万人以上の読者を魅了しているブログがセキュリティ コミュニティの主要目的地になっているのは、最新の脅威の技術的な分析、重要な脆弱性に関する開示、最先端の研究が掲載されているからです。

すべての Base64 は我々に属する − Web コンテンツに対する動的 vs 静的解析

最近、Trustwave Secure Web Gateway(SWG) によってブロックされたインシデントのテレメトリ ーをレビューしている時に面白いフィッシングの仕組みを見つけました。その仕組みについて の調査は、いくつかの興味深い点を明らかにして、私をこのブログに導きました:

  Fig1

図 1: 67 URL スキャンエンジン中ただ 1 つでのみブロックされたフィッシングコンテンツ

図のように、他のエンジンでは検出が難しかったこのサンプルも Trustwave SWG によってブ ロックされました。このブログでは、その理由を詳細に説明していきます。

動的解析 – 単語の違いを超えて

先に述べた 67 分の 1 の検出に対するシンプルな答えは、リアルタイム動的解析です。革新的 な次世代技術について多くの話がされているのにもかかわらず、不幸な現実は、多くの Web ベースのプロテクションが、依然として URL ブラックリスト、URL レピュテーション、および Web コンテンツの静的解析などの古典的な技術に大きく依存しているということです。

これらのアプローチの問題は、Web コンテンツが動的に常に変化していることです。今閲覧し ている URL のコンテンツは、5 分後に同じ URL にアクセスした場合、あるいは他国からアクセ スした場合には同じではありません。また、今日の埋め込み広告の世界では、ページを更新し ただけでも表示されるコンテンツは変わります。このように非常に動的なコンテンツに対して静 的な技術を適用すると、誤検知(false positive)や検出漏れ(false negative)の余地が非常に大 きくなります。

この問題に対する我々のアプローチは、動的コンテンツに対する動的解析です。ですが、悪意 のあるコンテンツがブロックされ、悪意のないコンテンツがブロックされなければ、エンジンがど の技術を採用しているかは本当に重要なことでしょうか? それでは、より詳しく見てみましょ う。

これは上図からの悪意のあるオリジナルの URL で、少し前に VirusTotal にアップロードされ ました:

  Fig2

図 2: VirusTotal 上でのオリジナル URL のスキャン結果

元々この URL は、67 エンジン中 5 つのエンジンでブロックされていました。一つのフィッシング ページに対して知りたい数字と正確に同じではないかもしれませんが、それは確かです。

我々は、これらのスキャナがブラックリストを使用していることを理解しました。というのは、私 がちょっと URL をちょっと変えて試してみると...

  Fig3

図 3: 別のパスを持つ同じドメインのスキャン結果

ご覧のように、今回は Web コンテンツが悪意のあるものではなかったため、Trustwave SWG はそれをブロックしませんでした。実際、新しい URL は架空のものなので、「404 Not Found」 Trustwave SpiderLabs Blog – April 11, 2018 Copyright © 2018 Trustwave Holdings, Inc. All rights reserved. 3 ページ以外のコンテンツはまったくありませんでした。確かに、そのドメインは最高の評判を持 っていないかもしれませんが、粗探しをするのであれば、これは偽陽性とみなされます。

興味深いことに、この図はブログの最初の図とは対照的です。最初の図で私がしたことは、こ のページからオリジナルコンテンツを取り出し、新しいクリーンなドメインにアップロードしたか らです。Trustwave SWG は、ドメインレピュテーションには関係なく、コンテンツに悪意があるた めブロックしました。そして、これは動的解析を行う上で本当に重要なことです。

動的解析の強みを確立したので、今度はこの素晴らしいフィッシングの仕組みを詳しく見てみ ましょう。

  Fig4

図 4: マイクロソフトのフィッシングページ

Fig5

図 5: フィッシングページのソースコード

すべては、ウィンドウの場所を "data:text/html;base64…" に変更する単純なスクリプトから始ま ります。

ファイルレスの base64フィッシングページの概念は 新しいものではありません。しかし、コンテ ンツの動的解析がなければ、base64 は本質的に悪意のあるものでもクリーンでもありません。 単にエンコードされたコンテンツです。それでは、このページをデコードして詳細を見てみましょ う:

  Fig6

図 6: デコードされたフィッシングページの base64 コード

見てください! それ自身がフィッシング詐欺である完全に新しい HTML ページなのですが、 新しいページには「私の」メールアドレス(”you-cant-hide-from-SWG@Trustwave.com”)が含 まれています。

攻撃者はどのようにこのようなことを実現したのでしょうか? もう一度 Base64! しかし今回は URL そのものです。

図 2 を詳しく見ると、このページの URL は次のようになります: hxxp://office0000.cf/sect/7nyyil7yn459fe1da6d9c2d/5a959dbac0a39/eW91LWNhbnQtaGlkZS1mcm9tLVNXR0BUcnVzdHdhdmUuY29t

URL の最後の部分を base64 でデコードしてみると:
eW91LWNhbnQtaGlkZS1mcm9tLVNXR0BUcnVzdHdhdmUuY29t

得られるものは:
you-cant-hide-from-SWG@Trustwave.com

素晴らしい! 攻撃者は、静的解析を避けるために毎回ページの内容を変更し、レピュテーショ ンベースの検出を避けるためにクリーンなドメインを使用することで、ほとんどすべてのセキュ リティ製品を回避していたのです。

フィッシングメールが送信されるすべてのアドレスには、base64 を使用して生成されたユニーク な URL とコンテンツが含まれています。これだけで、コンテンツに対する静的解析が十分に働 かなくなります。

攻撃者が、静的解析に遭遇した際の主な障害は、ドメインのブラックリスト化です。しかし、冒 頭で述べたように、同じコンテンツを新しいドメインに置くだけで、この問題は解決されます。ま た、実際のフィッシングページは単純な base64 コードなので、新しく作成したクリーンなドメイン から評判の良いサーバーにいたるまで、どこにでも簡単に置くことができます。

Google 検索を何度か実行することで、このフィッシングの仕組みがある期間、進行していたこ とが明らかになりました。攻撃者は、検出を避けるために、実際にドメインを数回変更していま した。

  https://phishcheck.me/14811/details によると、IP 54.243.65.67 と類似の構造を持つ URL が 1 ヶ月以上も前の 2 月 6 日に発見されています。

我々のページを見てみましょう:

  Fig7

図 7: 我々のフィッシングドメインの IP を解決する

完全に一致しました。

  Fig8

図 8: PhishCheck は、URL がおそらくフィッシングであり、 Amazon にホストされていることを示しています

攻撃者が、同一の IP アドレスを使いながらもドメイン名を変更し続けた場合、「次世代」ブラッ クリスト化ソリューションは何をするのでしょうか? ドメインの代わりに IP アドレスをブロックす る...

残念ながら、この IP は Amazon に属しています。Amazon による IP アドレスの割り当て方法 の詳細や、Amazon 上で IP をブロックすることが悪い考えである理由については触れませ ん。その代わりに、この IP アドレスで潜在的にホストされている他のものを見てみましょう。

  Fig9

図 9: IP に対する PassiveDNS の結果

この Amazon の IP アドレスは、アプリケーション開発のための正当なクラウドベースのプラット フォームである Heroku サービスをホストしているように見えます。このため、IP アドレスをブラ ックリストに登録すると誤検知が発生する可能性があります。このようなマルチホーム環境で は、1 つの IP 上にホストされているもののほとんどが完全に正当なものになってしまいます。

これらすべてが、静的解析の限界と動的解析の強さを示しています。動的解析を使用すると、 ドメインや IP などを手動でブラックリストに追加する必要なく、誤検知なしに実際の悪意のある コンテンツを含むページをブロックすることができます。

Base64 に話をもどして

この後、PhishCheck(図 8)の URL が、我々の例の URL よりも少し長くなっていることに気が つくかもしれません。それをブレークダウンしてみましょう:

最初に、いくつかのランダムな意味不明なディレクトリをもつベースドメインがあります: hxxp://strnet24.gq/sect/iv6cwjbhfw59ae2de1846a0/5a79d3864d65f/

これに続いて、base64 でエンコードされた標的電子メールアドレスがあります: cnN0dWNrZXlAdGhlY2FybHlsZWdyb3VwLmNvbQ==

次に、いくつかのパラメータが続きます。最初は
?forced=1
これは、このキャンペーンの背後にいる作者による未知の使用のためのフラグになります。
 
次のパラメータは:
&tg=VVNBMzY1
これは "USA365" の base64 です。 これはなぜ? 作者に聞けるものなら聞いてみたい。

最後のパラメータも base64: &s=ZXlKcGRpSTZJbGg0V2tveFZFUnljME5FVlZWbmRFaGlLM0ZOZFdjOVBTSXNJblpoYkhWbElqb2lhV05qYkZVMU1GQXhWek0yU2t4UGRXRnZXVU5TY205SmFVUlBhSGM1VGpjck0xVnRaVE5pWjJScVZFbzNiRzljTDBSSFUwNVhhekZhVmpGaU5EUkNWa05CTnpSVGNsUnplbXBxU1hGbGFTdFVXV3RXTkdGVGNsQnRZbXRoUTNOYVFscHZRVWhHVjA5M09VdzVUa1F5T0RoVGVtVkdiRTAxV0ZWYWEyZEljazQxVWt3cmVrTjNUMHB3UzNSVE0wcFhRazF6WVRoQ1VUMDlJaXdpYldGaklqb2lNek13WmpCa01ESTVOVEZtWlRBeE1UTTJZak0yWXpNeFltUTFPR1ExWm1Zd056YzBNbU14TlRRME1qYzBNelJqTXpreU9XRmpZVGN5TXpVek4yTTJPQ0o5

しかし、これをデコードすると、別の base64 エンコードの文字列コードが見つかります:

eyJpdiI6Ilh4WkoxVERyc0NEVVVndEhiK3FNdWc9PSIsInZhbHVlIjoiaWNjbFU1MFAxVzM2SkxPdWFvWUNScm9JaURPaHc5TjcrM1VtZTNiZ2RqVEo3bG9cL0RHU05XazFaVjFiNDRCVkNBNzRTclRzempqSXFlaStUWWtWNGFTclBtYmthQ3NaQlpvQUhGV093OUw5TkQyODhTemVGbE01WFVaa2dIck41UkwrekN3T0pwS3RTM0pXQk1zYThCUT09IiwibWFjIjoiMzMwZjBkMDI5NTFmZTAxMTM2YjM2YzMxYmQ1OGQ1ZmYwNzc0MmMxNTQ0Mjc0MzRjMzkyOWFjYTcyMzUzN2M2OCJ9

  Saltbase

図 10: もっと base64

さて、別のデコードサイクルを実行するのは問題ありません。そしてついに以下の JSON を見 つけることができました:

{"iv":"XxZJ1TDrsCDUUgtHb+qMug==","value":"icclU50P1W36JLOuaoYCRroIiDOhw9N7+3Ume3bgdjTJ7lo\/DGSNWk1ZV1b44BVCA74SrTszjjIqei+TYkV4aSrPmbkaCsZBZoAHFWOw9L9ND288SzeFlM5XUZkgHrN5RL+zCwOJpKtS3JWBMsa8BQ==","mac":"330f0d02951fe01136b36c31bd58d5ff07742c154427434c3929aca723537c68"}
 
ここでも、これらの値が何を意味するかを推測することだけができます。おそらくこれらの情報 は、作者にターゲットを特定するための情報を提供するものと思われます。

PSA なりたての方々: base64 は暗号化アルゴリズムではありません。 Trustwave SWG のお 客様はこのような手口から保護されています。