Microsoft Phishing "非" 観察記録_202107~202109

serasora

前半はほとんど言い訳なのでお忙しい方は「前置きは置いておいて本題」へどうぞ。

まずは言い訳

時がたつのは早いもので前回更新してから2か月と少し経過しているわけですが、本業が忙しかったという言い訳を無しにしても（Blog更新の）モチベーションが落ちていたという事実は変えられません。

現時点でも本業のWBSを作りつつ閑話休題としてBlog更新をしようと思い立っているわけでして、前向きじゃないモチベーションで書くのはどうかとも思いますが書いておきたいことができたので久しぶりに更新します。
※そして↑の記載はこれからまた定期的に書くとは限りませんよ、という意図も含んでいます

実際観察はしていた？

PhishTankに投稿されているものは自動的にAzure Sentinelに取り込まれてアラートを発生させるようになっています。

そのため、観察していないことはないですが、発信していないために私の頭の中にしか観察記録はありません。（さらに記憶とは時間経過で薄れるものです）
また、ダミーの認証情報を入れる部分が現状の実施方法だと非常に手間になっており、フィッシングサイトへのアクセス及び認証情報の提供後にどこからアクセスされているかの情報収集ができておらず、お遊び的にBlogに書いていたフィッシングサイト自体の画面遷移やらも確認できていませんでした。

前置きは置いておいて本題

さて、タイトルを"非"観察記録としているのは、フィッシングサイトへのダミー認証情報提供を半年ほど続けてきた実績をもってすれば、認証情報提供を新たにせずともIOCが勝手に集まってくれるのでは？と期待してログを見ていたからです。

つまり、過去半年提供してきたダミー認証情報が攻撃アクター（と呼ばれるほど洗練されているかは不明ですが）間、或いはコミュニティで共有され、継続した新規IOC獲得を労せず得られるのではないか、という期待です。

結論としては「否、努力は必要、但しサボるための改善はできるかも」です。

具体的にデータを見ましょう

私がフィッシングサイトへの認証情報提供をサボっていたのは7/25~8/17の間です。（正確に言うと8/18以降もですが）

画像1

詳細なクエリの説明は省きますが以下を実行すると8/1~8/17まではIOCとしてIPアドレスが追加されなかったことを示します。

let calendar = datatable (test:string)["test"]
| extend DateTime = range(0,31)
| mv-expand DateTime to typeof(int)
| extend StartMonth = startofmonth(datetime(2021-08-01)), EndMonth = endofmonth(datetime(2021-08-01))
| extend TimeGenerated = datetime_add("day", DateTime, StartMonth)
| where TimeGenerated < EndMonth
| project-away DateTime, StartMonth, EndMonth, test;
ThreatIntelligenceIndicator
| where TimeGenerated > ago(90d)
| where datetime_add("Minute", -30, TimeGenerated) < datetime_add("Year", -2, ExpirationDateTime)
| summarize TimeGenerated = min(TimeGenerated) by NetworkIP
| summarize count(), make_set(NetworkIP) by bin(TimeGenerated, 1d)
| join kind=rightouter calendar on TimeGenerated
| project-away TimeGenerated
| project-rename TimeGenerated = TimeGenerated1
| render columnchart

画像2

この結果に関してはIOCを自動追加しているLogic Appsの履歴からも確認できます。

画像3

いまになって思えば非常に後悔していますがLog Analyticsのリテンション期間を30日に絞っていたため、Blog記載の9/2から30日以上前の記録は上記のLogic Appsの履歴からしか確認できませんでした。

「リテンション期間長くすればよかった、30日経過する前にBlogをいい加減書き始めれば」
などと供述しており()

7/25以降の実行は恐らく7/25に情報提供に対するリアクションと考えられるため、情報提供をサボっていた期間はIOCになるIPアドレスが得られなかったということを示しています。

つまり？

情報提供をサボった場合、新たなIOCの獲得はかなわないために以下が考えられます。
1. 一度提供した認証情報の有効期限は3~5日。その間アクセス試行を受ける可能性がありますが、そこから他の攻撃元IPアドレスに派生してはいなさそう。
2. 1で派生していない（＝他のIPアドレスからアクセス試行されない）理由として、認証成功していないからアクター間やコミュニティ間で共有するに値しないから。認証失敗の情報が長期間共有され続けるとアクター側の効率が落ちることは想像に難くない。

どうすればもっと上手くサボることができるだろうか？改善点は？

1番の問題はダミー認証情報を手っ取り早くフィッシングサイトへ提供できないことです。そして残念ながらここに関してはシステム自動化できそうにありません。

いまの運用フローを見返してみると、
a. Windows Sandboxを開く
b. 録画を有効にする
c. Sandboxでフィッシングサイトにアクセスする
d. SmartScreenに止められるか確認する
e. dで止められない場合はEdgeからフィッシングサイトを報告
f. 認証情報入力
としています。

このうちdとeは被害を防ぐためにできれば対応しておきたい事項です。
（ほとんどのケースでSmartScreenに止められるので対応として頻度は稀なのですが）
つまり代替可能なものはそれ以外となります。
a, b, c, fは私物余剰スマホの用意ができるのでテザリングを介して携帯端末から実施する方法をとることができます。

9月から多少の余裕が生まれるので（ほんとか？WBS書き終わってないのに？）、dとeがスマホから対応可能なものなのかを確認してその内容を報告することを次回までの宿題にしておきます。

また前見出しの中で提供した認証情報に対する有効期限について言及していますが、これは正確ではありません。各フィッシングサイトごとに提供する認証IDを分けているわけではないため、過去に提供したものに時間をおいてからアクセス試行された可能性も否定できません。
そのため今後はフィッシングサイトごとに提供する認証IDを変える施策についても取り組もうと思います。これによって、

どのフィッシングサイトへアクセスするとどのIPアドレスから不正アクセス試行されるのか

を確認できるようになります。
次回アップデートに乞うご期待。（注：コミットはしません）


ちなみにアクセス元の分布は以下でした。

画像4

やることはやってましたよ

フィッシングメールがダミー情報のアドレス宛に届いていたりはしたため、ちょくちょくTwitterとPhishTankには情報を投げていました。

このあたりの話はまたいずれ。

この記事が気に入ったらサポートをしてみませんか？