Google Cloud Application Integrationを使用して、noreply-application-integration@google[.]comというgoogleの正規のドメインからフィッシングメール送信をする手法が増えているとのこと。

Google Cloud Application Integrationは、本来GCP上でAPI連携だったり、ワークフローを作成する機能。このうちの「Send Email」機能はワークフロー内で、何かしらの通知を送信するものがある。このメールはgoogleの正規のドメインから送信される。

これが悪用される事例が増えている。

正規のドメインから送信されるけどフィッシングです！

初歩のフィッシングメールの見分け方とかで、変なドメインとか偽物のドメインを見分ける的なものがあるが、今回の事例には効きません。

Google Cloud Application IntegrationのSend Email機能で送信元となるメールアドレス「noreply-application-integration@google[.]com」はgoogleのドメイン。

別にgoogleが乗っ取られたわけでも何でもなく、ただただ正規の機能が悪用されているだけ。

これによって単純なフィッシングメールフィルタリングやフィッシングメール対策の意識を回避してしまう。

さらに、今回の手法ではstorage.cloud.google[.]comやgoogleusercontent[.]com、sites.google[.]com、share[.]googleなどのドメインでホストしたWebコンテンツへのリンクをメールに埋め込むらしい。

これによって、メール送信元だけでなくメールコンテンツ内でも正規のgoogle ドメインが使用される。

最早、変なドメイン、怪しいドメイン、登録されたばかりのドメインという基準ではフィッシングメールは回避できない。

今回の手法では最終的にMicrosoft 365のフィッシングに繋げるようなので、googleからメール来たのに何か変だなと途中で気づけると思っている。

しかし、そのような違和感に気づけなければハマった被害者も多いだろう。

GCPのワークフローのメールでこういうことできるなら、他のサービスでもできるのでは？

って思ったが簡単に調べた限りでは、あんまり無いらしい。

AWS SESは言わずと知れたメール送信機能だが、これは自分たちで登録したドメインを使用する。なので、amazonの正規ドメインを使うようなことは無さそう。

Azureだと、おそらくDirect SendかAzure Communication Services (ACS)がメール送信/配信に使われそう。だが、こちらも自分たちで登録したドメインを使用するので、microsoft正規のドメインを使用したメール送信というのは無さそうだ。

よくあるIaaS関連サービスには無かったが、Salesforceにはあるらしい。
ravenmail.io

noreply@salesforce[.]comのようなsalesforce正規のドメインを使用してメール送信ができるので、こちらもフィッシングメールフィルタリングを回避されやすいと。知らない内に話題になっていたのか。

今回の件でも、salesforceの件の話もRavenMailで見つけたわけだが、どちらも脅威として検出してブロックできると言っている。

「Contextual Mismatch Detection」とか、「Context-Aware Brand Analysis」というようにメールのコンテキストを分析。

メールの内容を評価？

Does this workflow make sense?
Is this URL consistent with legitimate Google Tasks behavior?
Is Cloud Storage a valid endpoint for this action?

URLリダイレクト先も解析しちゃうというアピールをしている!?

本当だったら、凄そう。てか、特定のメールのやりとりの場合には問題が発生しそうな機能のようにも思う。例えば、認証情報や重要ファイル共有のリンクで1回しかアクセスできないURLを送るときとか。

RavenMail、凄そうだけどお高そう。