アメリカでは、4月15日の税務申告期限が迫っており、その界隈では慌ただしくなっているらしい。
そんな中、税務関連書類を検索する人を騙してRMMをインストールさせて、BYOVDでアンチウイルスをOFFにしてからRMMを通じた遠隔操作や認証情報収集なんてことをやっている攻撃者がいた。
忙しい中で、さらに大変なことになっている。
妙に高度なのが重ねてヤバイ。
- アメリカも今、確定申告シーズンらしい
- SEOスパムからMaaSに成り代わったクローキングサービス
- 2㎇メモリ確保とtimeSetEvent
- HuaweiラップトップPCのオーディオドライバを使用したBYOVD
- 不特定多数を狙ったものでも高度な攻撃になってきた
アメリカも今、確定申告シーズンらしい
今回、攻撃者は「W2 tax form」や「W-9 Tax Forms 2026」といったキーワードのGoogle検索で広告として最初に出てきたページで、税務申告書類テンプレートや簡単に記入できるプログラムとしてRMMツールを配信していたとみられる。
アメリカでは、毎年1月-4月が確定申告シーズンらしく、4月の期限に向けて税金を納める人たちは書類記入を頑張るらしい。
www.irs.gov
確定申告のための制度が日本よりも少ないということなので、源泉徴収(W2)とか自分で頑張らないといけないということ。W9はまた別の税務関連書類を作成するための書類？
www.irs.gov
そんな労働者が大変な時期には、この状況を悪用したフィッシング詐欺が急増する時期というのは通例ということ。
W2記入するっていうことは企業で働いているし、W9ならある程度儲けている副業？の可能性が高い。税務関連書類は会社にいるときに検索している可能性が高いし、それなら企業を的確に狙うことができるという戦略だろう。
ところで、税務関連の作業が多い時期にGoogle Adsで税務関連キーワードを狙うと入札金額高くなりそうだなと思った。
けど、ここら辺は盗んだアカウントでやって安く済ませている可能性が高いと考えている。
あとで、出てくる配信していたRMMツールのScreenConectはトライアル版とのことなので、あんまりお金はかけていないように見える。
Google Adsの登録できるようなフロント企業が用意できるなら、ScreenConectを契約できるような状況を用意できないのは変じゃないか？
人気キーワード何て1クリック1万とか普通に超えるだろうし、検索結果の一番上に沿えちゃったら1日100件とかクリックされちゃうよなぁ。
そんなに費用かかるんだから、盗んだアカウントで支払わせているのではないかと推測。
ちなみに、RMMツールは4syncというファイル共有サービスで配信されていた。
ja.4sync.com
これは初めて聞いた。
何か利点があるのだろうか。分からん。
SEOスパムからMaaSに成り代わったクローキングサービス
個人的にクローキングサービスという概念を始めて知った。
基本的に「広告詐欺（アドフラウド）防止」や「不正トラフィックフィルタリング」を謳ったアフィリエイトマーケティング向けサービスらしい。
やっていることは、自動スキャナーとかBotがスキャンしてきたときのページと人間がブラウザでアクセスしてきたときのページを振り分けるようなこと。
これって怪しいニオイしかしないですね。
Googleの審査担当者、自動スキャナー（Google Safe Browsing等）、サードパーティのセキュリティベンダー（VirusTotal、Kaspersky、GeoEdge、Confiant等）がクロールして、悪意のあるコンテンツがないかチェックする。
ここで「誰が見ているかで切り替える」のがクローキングサービスということ。
もう既に危ないサービスって分かりきっている。
今回事例では、RMMツールの配信ページを広告として審査やスキャンをすり抜けるために2つのクローキングサービスが組み合わせて使用されていた。
JustCloakIt（JCI）
JCIが担うのはサーバレベルでのアクセス者の検証。
PHPで、IPアドレス、User-Agent、Referer、GCLIDパラメータなどをチェックしているらしい。
- IPアドレス: データセンターIP、既知のセキュリティベンダーIP、VPN/Proxy IPをブラックリストと照合
- User-Agent: 自動スキャナー特有のUA文字列を検出
- Referer: Google Adsからの正規遷移かどうかを確認
- GCLIDパラメータ: Google Ads固有のクリックID。正規の広告クリック経由かどうかの判定に使用
こんな感じで、「一般の訪問者」か「Botやクローラー」か「広告審査プラットフォームや有名企業の担当者」かみたいなことを判定して表示されるページを切り替えていると思われる。
Adspect
Adspectが担うのは、クライアントのフィンガープリントレベルでのアクセス者の検証。
サーバレベルのチェックだとそれなりにパラメータ調整すれば、高度なBotやクローラーで対処できるでしょう。
それらに対して、javascriptでさらに詳細な検証をしていく。
- windowオブジェクトのプロパティ完全列挙: Selenium/Puppeteer/Playwright等の自動化フレームワークが注入する余分なプロパティ（cdc_プレフィックス等）を検出。正規Chromeのwindow.chromeオブジェクトの存在・構造も検証
- navigator.webdriverフラグ: 自動化ブラウザの痕跡。パッチ方法自体（Object.definePropertyでのオーバーライド）もフィンガープリンティング対象
- WebGL GPU文字列: VM/サンドボックス環境は「Google SwiftShader」「llvmpipe」「VMware SVGA 3D」等のソフトウェアレンダラを返す。実機なら「NVIDIA GeForce RTX 3080」等が返る
- DevTools検出: console.logにカスタムtoStringオブジェクトを渡し、DevToolsが開いているとtoStringが2回以上呼ばれることを利用
- iframe検出: window.self !== window.top でサンドボックス内のiframe実行を検出
- DOMルート要素の属性列挙: ブラウザ拡張やPlaywrightが注入する非標準属性を検出
収集したフィンガープリントは、Adspectのサーバの機械学習分類器で判定されるらしい。
Botの対処とか全然考えたことなかったけど、色々観点があるんだなぁという浅い感想だけ述べておく。
これらは本来？はSEOスパムとして知られていたが
何がアクセスしてきたかでアクセス先を振り分けるというので、とあるキーワード検索やとある検索傾向に対して無関係の話題とかミスリードを誘うようなことに使用されるイメージが強かったらしい。
それらはフィッシングプラットフォームやマルウェア配信界隈に目を付けられて利用される、そして特にプラットフォーム側で対処されていないような状態になってしまっているようにみえる。
Malvertising Unmasked: The Payroll Pirates Operation
npm Malware Campaign Uses Adspect Cloaking to Deliver Malici...
1Campaign: A New Cloaking Platform Helping Attackers Abuse Google Ads
Ad Security Report 2026: Defending Users and Revenue in the Age of Malvertising
余談 クリアウェブのMaaS経済圏？
Adspectとパートナー企業？らしい企業で、ブラウザフットプリントを好きに切り替えられるAntidetect Browserを提供しているUndetectable.io。
ここがホームページで他のパートナーの一覧を出している。
アンチディテクトブラウザーとの使用に最適なサービス
何とも言えないが、以外と直ぐ傍に奇妙な経済圏があるのだと改めて認識させられた。
2㎇メモリ確保とtimeSetEvent
インストールさせたScreenConnectで攻撃者が攻撃ペイロードを含むローダーを実行するようだが、ここで主に2つのアンチウイルス回避手法が確認された。
2㎇メモリ確保
2GBメモリを確保して、解放する。たったそれだけ。それだけだけど、自動解析を回避できる。
単純にアンチウイルスがファイル生成時のファイルスキャンにエミュレータを使用するが、他のシステムに負荷を与えないように軽量な仮想環境で検査する。
そこに検証中の間、2GBもメモリを割り当て続けることなんてできるかということ。
そりゃできないので、ファイルスキャンを回避できることになってしまう。
以下、コードのイメージ。
Block = VirtualAlloc(NULL, 0x80000000, MEM_COMMIT, PAGE_EXECUTE_READWRITE); // 2GB
if (Block) {
memset(Block, 0, 0x80000000); // 2GB全域をゼロフィル
VirtualFree(Block, 0, MEM_RELEASE);
// ペイロード復号処理
VirtualProtect(shellcode, size, PAGE_EXECUTE_READWRITE, &old);
// ...
}
2GBのメモリ確保のロジックによっては、20億バイト分のメモリ書き込み命令をシミュレートすることになるので、この操作によるタイムアウトでのスキャン打ち切りっていうのもあり得る。
自動マルウェア解析VMのメモリは2~4GBが多いイメージなので、2GBのVirtualAlloc(MEM_COMMIT)はかなりキツイんじゃないか。
そうなると、ペイロードは処理はされずにサンドボックスのレポートには「特に悪意ある挙動なし」となると。
大量のメモリ確保を検知ルールとするなら、AI系とか大規模データ処理アプリケーションやゲームエンジンの大量メモリを確保で誤検知多くなる？
そうなると、良い感じの閾値は難しいか。どうだろうか。
timeSetEvent
よくあるCreateThreadとかを呼ばない系のシェルコード実行テクニックの1つ。
多分こんな感じ。
// シェルコードのアドレスをdwUser（ユーザーデータ）として渡す
timeSetEvent(
100, // 100ms後に発火
0, // 精度
fptc, // コールバック関数（ラッパー）
(DWORD_PTR)shellcode_addr, // dwUser = シェルコードのアドレス
TIME_ONESHOT // 1回だけ発火
);
// コールバックラッパー
void CALLBACK fptc(UINT uTimerID, UINT uMsg, DWORD_PTR dwUser,
DWORD_PTR dw1, DWORD_PTR dw2) {
((void(*)())dwUser)(); // dwUser経由でシェルコードを呼ぶ
}
timeSetEventは内部的にスレッドを使うがスレッドの作成自体はwinmm.dllで行われるので、EDRがCreateThread/NtCreateThreadExをフックして「開始アドレスがRWXメモリを指しているか」を検査しても、スレッドの開始アドレスはwinmm.dll内の正規関数（タイマーディスパッチャ）を指しているためフラグが立ちにくくなる。
コールスタック的にも検知されにくくなる。
CreateThreadpoolWait,EnumWindows,EnumDateFormats
EnumWindows/EnumDateFormats/CertEnumSystemStore, CreateThreadpoolWait/SetTimer/timeSetEvent, QueueUserAPC, CreateFiber/SwitchToFiberとかもスレッド作成系のカーネルテレメトリに痕跡を残しにくくなる。
ただし、そのAPIの使用自体にフラグが立つようになったので効果はまちまち。
HuaweiラップトップPCのオーディオドライバを使用したBYOVD
BYOVDでカーネルレベルから操作っていうのは、EDR回避/キラーでお馴染み。
今回ちょっと異様なのは、ここで取り上げられたHuaweiオーディオドライバ(HWAuidoOs2Ec.sys)は公開された脆弱性情報が無く、MVDB、LOLDriversに無いらしい。
IOCTLコード 0x2248DCで、ターゲットプロセスIDをキルできてしまう。
カーネルレベルでプロセス操作ができてしまえば、ユーザーモードの保護に依存するEDRのプロセスは防御できない。
分かってしまえば単純な話。
PoC作っときました。
zenn.dev
不特定多数を狙ったものでも高度な攻撃になってきた
ClickFixやサポート詐欺も不特定多数を狙ったもの。
これらは、まだまだ粗さが目立ちそれほど全体的には高度化されていない印象(今はまだ)。
でも、こんなよくある感じのMalvertisingがここまで高度になって来ている。
EDRが回避されるのだから、もっと攻撃者の状況を知って身を守れるようにしなければいけんな。
