Microsoft Phishing観察記録_202110

漏らした資格情報へのアクセス試行の情報収集進捗

Microsoftフィッシングサイトへダミーの資格情報を(敢えて)漏えいさせ、ダミーの資格情報に対してアクセス試行を行ったIPアドレスを収集しています。

画像1

件数は111件、順調に増加しています。
(前月比は調べればわかりますが現時点で価値があるとも思えないので次回以降記載することにします)

公開しているIPリストは同IPであってもユーザーエージェントやOSが違う場合は別のインテリジェンス情報として登録していて、2021/10/13時点で113件公開しています。

画像2

同IPで複数件公開しているのは198[.]98[.]54[.]43、199[.]217[.]105[.]246の2つです。
(198[.]98[.]54[.]43のほうはGeo IPのデータベースの変化でアクセス元国が異なるように出力されていそうですが。)

フィッシングサイト自体は変わりない状況なので今月は割愛しますが、少し進捗や考察事項が生まれたので以降に記載します。

フィッシングメールの受信

ダミーで用意しているユーザーのExchangeメールボックスを有効化し、外部からのメール受信が可能なように設定しました。かつ、ダミーのユーザーはカスタムドメイン(=onmicrosoft.comではないドメイン)を別に用意し、カスタムドメイン宛のメールが受信できるようにMXレコード等を設定しています。

初めに届いたのが2021/6/17、以降1ヶ月に1件あるかないかのペースでメールを受信するようになりました。
このことは業界で一般的に言われるように、フィッシングサイトへ漏えいした資格情報は継続して攻撃されうることを示します。
一度でもフィッシングにひっかかった人は今後もかかりやすいだろうと継続して攻撃される、アクター同士で情報共有が行われて異なるアクターから攻撃される、などが考えられます。
一方で、送信されてくるメールヘッダを見ると、オープンリレー化していそうなMTAが踏み台にされているケースが多いのですが、中には侵害済みのメールボックスから送られているケースもあるのではないかと思い、逆に敢えて侵害させることでフィッシングメールを収集できるのではないかと考えました。

侵害させるための準備

フィッシングメールを送信させるための敢えての侵害、ですが、本当に外部宛にフィッシングメールを送信してしまうのは良くありません。
アクターに利する行為を避けるために外部への送信を遮断しつつ、送信したメールの情報は収集する必要があります。
外部宛メールを遮断するため「トランスポートルール」を2つ使用します。

画像3

1つが送信者がダミーユーザーとなる場合、メールが外部宛に送信されずに削除されるルールです。このルールがないと外部宛にフィッシングメールが送信されてしまいます。

画像4

もう1つが送信者がダミーユーザーとなる場合、内部のメールアドレスにBCCで送信するルールです。さらにメール件名接頭に特定文字列を付与して内部のメールアドレスではフォルダを振り分けています。(多くの場合EOPやDefender for Office 365で遮断されメールボックスまで届きませんが念のため)

さらに侵害させるためにパスワードをわかりやすいものに固定、多要素認証設定を外し、Exchange以外にアクセスさせないように条件付きアクセス設定を行いました。

しかし、なかなかExchangeに対してアクセスしてくれませんでした。設定以前からExchange以外(Office 365ポータル)へのアクセス試行は見えていたため、Office 365ポータルに対するアクセスについても条件付きアクセスで許可する(ブロック例外にする)設定を行いました。

侵害された後どうなった?

侵害された後、2021/9/23に2通のメール送信を確認しました。メールはいずれも以下のようなもので、送信者名がFaxからの自動送信メールに見えるように偽装され、HTMLが添付されていました。(内容まで確認できていませんが)恐らくフィッシングメールかと思われます。

画像5

上記にもある通り、外部宛のメールはブロックしていますので、宛先メールアドレス宛には届いていません。
外部宛のメールはブロックしているはずなので、当該宛先からメールが戻ってくることは基本的にあり得ません。
※ブロックしていない場合、宛先がフィッシングメールに反応して返信する可能性があります
ところが、2021/9/28に届くはずのない当該宛先からメールが届きました。

メール件名:test

として。

フィッシングメールの宛先となったアドレスからメール受信?気になる動きが見える

画像6

本記事記載時点でメールヘッダを確認できないため(何故保管しておかなかったorz)、なりすまされていたものか侵害済みのメールボックスだったのかは確認できませんでしたが、2021/9/28(上記ログはJST)は上記以外にも異なるメールアドレスで同じIPアドレスから「件名:test」のメールを受信していたため、おそらくなりすまされていたものと考えられます。

※同じIPアドレスというのはMSのサーバに送信した直前のサーバなので厳密に同じ送信元とは言えませんが、同じIPアドレスの場合は最初の送信元やアクターが同じケースも多い傾向にあります(特にこの環境だと)

2021/9/28は「件名:test」のメールを複数受信していたのですが、そのあと気になるサインインログが確認できています。

画像7

上記はAzure ADサインインログの宛先アプリとアクセス時刻ですが、2021/9/29 18時20分ごろに「Microsoft 365 Security and Compliance Center」へのアクセスが確認できました。
おそらくこちらは受信できていない or 送信できていないメールが、どういった理由で遮断されていたかを確認するためにアクセスしたものと思われます。
EOPやDefender for Office 365のマルウェア検出機能で検疫されたメールであれば一般ユーザーは確認できませんが、スパム検出であれば一般ユーザーであっても検疫されたメールを確認することができます。
また、ダミーユーザーが管理者権限を有していれば検疫ルールや送受信できなかった理由も調査することができます。
同じアクターであるか否かは確認できないため無関係である可能性もありますが、これまでアクセス試行が一切なかった「Microsoft 365 Security and Compliance Center」にアクセスしていることと「件名:test」メールが送られたタイミングを考えると関係しているように見えてきます。

攻撃成否をテストさせてしまう懸念

「件名:test」のメールから上記構成のままでは攻撃(フィッシングメール送信)が成功しているか失敗しているかをアクターにテスト可能な状態にしてしまいます。
Exchangeを利用している以上、EOPやDefender for Office 365を利用している可能性が高く、他ベンダーのセキュリティ製品を利用している可能性があるとしても、Exchange環境に対しての有効な攻撃(検出されないフィッシングメール)を教えてしまうことになります。
これは良くないなと思い、メールに添付ファイルを含む場合やメール本文にURLを含む場合は、マルウェアやフィッシングであるか否かに関わらず遮断するようにしました。

画像8

画像9

そして来る2021/10/6...

画像10

!?!?!?!?

次回に続く。

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