日本を標的としたAtlas RAT配布事例を追う

CDIのスレットインテリジェンスアナリスト川上です。弊社では、2026年に入り、日本語の業務文書を装うファイル名でAtlas RATへ到達する検体を複数確認しています。

本記事では、確認した検体のうち大きく2つの実行フローを取り上げ、配布からRAT本体起動までの流れと判明点をまとめます。これら以外にも亜種を確認しており、本文中では実装上の差分として触れます。

背景: Atlas RATとSilver Fox／TA4922の接点

本記事で扱うAtlas RATは、Silver Fox／TA4922周辺の活動で観測されているRATです。

Silver Foxは、中国語圏を主な活動基盤とすると見られる攻撃グループで、Void ArachneやSwimSnakeとして報告されることもあります。公開情報では、VPNクライアント、メッセンジャーソフト、リモートデスクトップツール、暗号資産関連ツールなど、中国語圏のユーザーに利用されやすいソフトウェアを偽装してマルウェアを配布する活動が繰り返し報告されています。

また、関連活動ではValleyRAT（WinOS／Winos 4.0）やGh0stRAT系のペイロードに加え、HoldingHands RAT、Sainbox RAT、HiddenGh0st、kkRAT、ABCDoorなど、複数のRATを使うことが報告されています。

我々は以前にもSilver Fox関連活動について調査しており、最終ペイロードが同じValleyRATであっても、MSI、Inno Setup、NSIS、BYOVD、PowerShell／BAT、.NET／Go／Rust製バイナリなど、多様な手法とツールが使われることを確認しています。こうした観測は、攻撃者が複数の配布・実行フローを並行して開発・運用できる体制を有している可能性を示しています。

本記事で扱うAtlas RATの事例も、この見方と整合します。短期間に異なる入口・ローダー・常駐化手法を持つ検体を確認しており、一部のC2では過去にValleyRATがホストされていた形跡もありました。こうした点から、今回のAtlas RAT配布もSilver Fox／TA4922周辺の活動と関連があると考えています。

一方で、このような複数フローの開発・運用がどのような体制で実現されているのかについては、現時点でそれを裏付ける明確な根拠を確認できていません。

Atlas RATに関しては、既に複数の外部報告があります。

• Hexastrikeが2026年3月25日に公開した記事「Trust the Tunnel, Get the Trojan: Silver Fox Delivers Atlas RAT via Weaponized VPN Installers」では、Silver Foxが中国語圏ユーザーに信頼されるアプリケーションを装った偽ダウンロードサイトやタイポスクワッティングドメインを通じて、Atlas RATを配布していた事例が報告されています。
  • 今回確認した事例とは配布経路やローダーの実装などが異なりますが、Atlas RATの挙動や関連する攻撃手法を把握するうえで参考になります。
• Proofpointが2026年6月3日に公開した記事「TA4922: Suspected Chinese Crime Group Going Global」では、中国語話者の脅威アクターTA4922によるAtlas RAT配布キャンペーンが報告されています。
  • ProofpointはTA4922について、Silver Fox／Void Arachneとツール、インフラ、ソーシャルエンジニアリングの面で重なりがある一方、完全に一対一で対応する活動ではなく、別個の脅威クラスタとして追跡していると説明しています。
  • 同記事では、2026年3月から4月にかけて、日本の組織を標的にした人事・給与調整テーマのキャンペーンや、英国・ドイツの組織を標的にしたHR書類テーマのキャンペーン、さらに日本語の電子請求書を装うZIP／IMG経由の配布事例が紹介されています。
  • また、複数のローダーやパッケージングが取り上げられており、配布・実行フローの使い分けという点でも、我々の観測と整合します。
  • Proofpointの観測では、TA4922の標的国の中でも日本での観測件数が多く示されており、日本国内の組織にとっても注視すべき活動であると考えられます。

これらの外部報告では、Atlas RAT本体の機能や配布キャンペーンの全体像が既に詳しく示されています。本記事では、Atlas RAT到達までの実行フローと、観測した前段ローダーの内部実装および亜種間の差分に焦点を当てます。

事例1: ISOからサービス常駐型ローダーへ（2026年2月初旬観測）

日本向けAtlas RAT配布事例1の実行フロー全体像を以下に示します。

メール本文中のリンク先ページに詳しい内容.isoがホストされており、ユーザーがダウンロード後に展開・実行することで最終的にAtlas RATが実行されます。

詳しい内容.isoは詳しい内容.exe、vrfcore.dll、Service.dll、atl.ini、1.ryの5ファイルを含みます。

このうち1.ryは実行フローに関与せず、サイズも100MBを超えることから、ダミーファイルとみられます。ファイルサイズを肥大化させ、サンドボックスや自動解析環境での処理を妨げる目的と考えられます。

入口: 偽vrfcore.dllが環境確認とサービス起動を担う

詳しい内容.exeは、Microsoft署名付きの正規appverif.exeをリネームした実行ファイルで、vrfcore.dllをインポートします。DLLサイドローディングにより、同一ディレクトリに置かれた攻撃者作成の偽vrfcore.dllが、正規DLLより優先して読み込まれます。

以下に、Google Threat Intelligence（GTI）上の詳しい内容.exeの署名情報を示します。表示は「Signed file, valid signature」で、署名者はMicrosoft Corporation、Original Nameはappverif.exe（Application Verifier User Interface Utility）です。攻撃者は、この正規のAppVerifier実行ファイルをリネームし、有効な署名ごと流用していました。

偽vrfcore.dllはVerifier*系エクスポートを多数持ちますが、悪性処理はVerifierOpenLayerPropertiesに集約されています。その役割は、後段ローダーService.dllをサービスとして常駐させることで、永続化と後段実行を担うことです。具体的には次の処理を行います。

• まず実行環境の確認（CExecSvc.exeの探索、vmsmbデバイスのオープン試行、Windows genuine判定など）を行う。
  • ただし判定結果は後続の制御フローに反映されておらず、環境を理由に処理を止める実装にはなっていない。
• 同一ディレクトリのService.dllとatl.iniをC:\Users\Public\Music\へコピーする。
• Wtapise64をsvchostサービスとして作成する。
  • 表示名:Wtapise64 Deployment Service (AppWtsapi32)
  • 実行イメージ:svchost.exe -k "Wtapise64"
  • 説明文:Microsoft Storeアプリを装う中国語文言
• Service.dllをWtapise64サービスとして永続化し、svchost経由で起動する。
  • HKLM\SYSTEM\CurrentControlSet\Services\Wtapise64\Parameters\ServiceDllにC:\Users\Public\Music\Service.dllを設定する。
  • HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost配下にWtapise64値を登録し、StartServiceWでサービスを起動する。

最初に呼ばれる環境確認処理を以下に示します。右側のデコンパイル結果に各種の確認処理が並ぶ一方、左側の逆アセンブル結果では戻り値が評価されておらず、判定結果が後続処理に影響しないことがわかります。

続いて、後段ペイロード（Service.dllやatl.ini）のコピー処理と、Wtapise64サービス登録時に設定される中国語の説明文を以下に示します。

上記の一連の処理により、Service.dllはWtapise64サービスとして常駐します。これにより、システム再起動後も後段処理が起動されます。偽vrfcore.dllの主な役割は、この永続化と後段起動の準備にとどまります。

常駐化: Wtapise64サービスで後段を起動し続ける（Service.dll）

Service.dllは、前段の偽vrfcore.dllによって、Wtapise64サービスのServiceDllとして登録されるサービスDLLです。StartServiceWでWtapise64が起動されると、SCMがsvchost.exe -k "Wtapise64"を起動します。svchostはレジストリのServiceDll値に従って本DLLをロードし、規定のエクスポート関数ServiceMainを呼び出します。

ServiceMainの主な役割は、Wtapise64サービスの状態を監視・維持しながら、後段のatl.iniをログオンユーザーのセッション上で実行することです。まずサービス制御ハンドラを登録し、HKLM\SYSTEM\CurrentControlSet\Services\Wtapise64配下に独自の値ServiceProtectedを作成し、1を設定します。

永続化の監視と維持は、以下の表に示す、3つの監視スレッドと、停止要求に介入するサービス制御ハンドラが担います。

以下に、エクスポート関数ServiceMainのデコンパイル結果を示します。画像下部のCreateThreadで前掲の3スレッドが起動されます。

ServiceMainは、アクティブなコンソールセッションのトークンを複製し、ユーザーデスクトップ（WinSta0\Default）上で後段を起動します。具体的には、カレントディレクトリへコピーしたRundll32.exeからService.dllのMainThreadを、コマンドラインC:\Users\Public\Music\Rundll32.exe "C:\Users\Public\Music\Service.dll",MainThreadで起動します。サービスの非対話セッションを避けることで、ログオンユーザーの環境や対話型デスクトップ上のリソースへアクセスしやすくする狙いがあると考えられます。起動したRundll32.exeが終了した場合は、同じコマンドラインで再起動します。

Service.dllのエクスポート関数MainThreadはC:\Users\Public\Music\atl.iniを読み込み、確保したメモリ上へコピーしてCreateThreadで実行します。リモートプロセスへのインジェクションではなく、同一プロセス内でatl.iniをシェルコードとして実行する処理です。

Service.dllにもvrfcore.dllと同じ環境確認コードが含まれていますが、ここでも結果は後続処理で使用されていません。

以上のとおりService.dllは、Wtapise64サービスを維持しながら、ユーザーセッション上でatl.iniを起動・再実行する役割を担います。

次段取得: atl.iniがC2からStage3を受信する

atl.iniはINI形式のコンフィグファイルではなく、Service.dllのMainThread経由でファイル先頭から実行されるx64シェルコードです。C2へ接続し、後段ペイロードであるStage3を取得・実行するTCPステージャとして動作します。

以下に処理の全体像を示します。

まず、PEB/LDRをたどるROR13ベースのAPI Hashingで必要なAPIを動的解決し、WinSockを用いたTCP通信処理を構築します。

C2コンフィグはシェルコード自身の末尾に埋め込まれています。実行時には、RtlCaptureContextで取得したRIP近傍を走査してマーカーBy@V<を探します。マーカー直後の0x144バイトがコンフィグとして扱われ、C2ホストやポートなどが含まれます。

本検体のコンフィグには、C2ホストgbedn[.]fitとポート9888/TCPが含まれています。本事例の観測時期において、gbedn[.]fitは43[.]207[.]218[.]80に解決されていました。

このコンフィグはC2ホスト、C2ポート、REMARK、GROUPSの4項目で構成され、いずれもAtlas RAT本体へ引き渡されます。このうちREMARKとGROUPSについて、Hexastrike・Proofpointの報告では、それぞれキャンペーン識別子、オペレーターまたはビルド／アフィリエイト識別子にあたるとされます。 事例1で確認したコンフィグを以下に示します。この2項目にいずれも初期値とみられる中国語文字列（GBK/CP936エンコード）が設定されていました。具体的には默认备注（デフォルト備考）と默认分组（デフォルトグループ）です。

コンフィグ構造は次のとおりです。

その後、atl.iniはC2へTCP接続し、固定識別子SFuck\0\0\0（53 46 75 63 6b 00 00 00）を送信し、Stage3を受信します。受信データ内の所定領域へコンフィグをコピーした後、同一プロセスのメモリ上でStage3 Shellcodeを実行します。

このようにatl.iniは、C2からStage3を取得するだけでなく、C2コンフィグをAtlas RAT本体へ引き渡す役割も担っています。

RAT起動準備: Stage3がAtlas RAT本体を手動マップする

ダウンロードされるペイロードは、先頭0x1c04バイトのローダー（Stage3 Shellcode）と、それに続くAtlas RAT本体で構成されます。実行はペイロード先頭のStage3 Shellcodeから始まります。

Stage3 Shellcodeは、前段atl.iniと同じPEB/LDR走査とROR13ベースのAPI Hashingで、必要なAPIを解決します。直後に配置されたAtlas RAT本体を手動マップし、エクスポート関数AtlasInfoを解決します。最後に、前段atl.iniから受け取った0x144バイトのコンフィグを引数として渡し、RAT本体の処理を起動します。

Atlas RAT

AtlasInfo以降がRAT本体、すなわちAtlas RATです。起動直後、前段ローダーから渡された0x144バイトのコンフィグを内部設定へ反映し、C2通信を開始します。

RAT本体の機能は、大枠ではHexastrikeの報告と整合します。本事例で確認した主な機能は次のとおりです。

• C2接続とその再試行処理（TCP keepalive・タイムアウト・バッファ設定を含む）
• 56バイトヘッダ・zlib圧縮・ChaCha20暗号を用いたC2通信
• 初期ホスト情報の収集と送信（OS・CPU・GPU、ユーザー名、コンピュータ名、権限、UAC設定など）
• SIGN・Time・REMARK・GROUPSなどのローカル設定の管理
• heartbeat
• アイドル時間の監視と通知
• QQ、WeChat、360、DingTalk、Telegram、BaiduNetdiskなどのアプリケーション存在確認
• 追加モジュールのメモリロードと実行
• WeChat.exeへのWxfun.dllのインジェクション・アンロード・削除
• 指定プロセス名およびウィンドウタイトルの存在確認
• URLからのファイルダウンロード、Public Downloads配下への保存と実行
• REMARK・GROUPSのリモート更新
• 電源操作
• AtlasPro.ini・MODIf.htmlの削除と自己削除

一方、永続化に関しては、前段のWtapise64サービスが担うためか、RAT本体側には含まれていませんでした。Hexastrikeが報告するPowerChell Frameworkや、セキュリティ製品のTCP接続を切断するTCP Killer相当の処理も確認していません。

設定管理の面では、RAT本体は起動時に読み取ったコンフィグの値を、C:\Users\Public\Documents\AtlasPro.iniにもローカル保存します。このファイルは、atl.iniとは異なり拡張子どおりのINI形式で、[Setting]セクションにLoginAddress、LoginPort、REMARK、GROUPS、Time、SIGNを保持します。自己削除を伴うアンインストール処理では削除対象に含まれます。

Hexastrikeの報告では、同じC:\Users\Public\Documents配下に、AtlasPro.iniに加えてC2ドメイン名を冠した設定ファイルも生成されるとされています。そのため検知やハンティングでは、ファイル名単体に頼るのは有効ではありません。C:\Users\Public\Documents配下に置かれ、かつ[Setting]セクションやLoginAddress・LoginPort・SIGNなどのキーを持つ、という組み合わせを指標とするのが有効です。

ファイル上の特徴としては、Atlas RAT本体のExport DirectoryにDLL名MainDll.dllが記録されている点も挙げられます。これはビルド時に付与された名前とみられ、確認した範囲の検体では一貫して観測されました。起動時に呼び出されるエクスポート関数AtlasInfoとあわせ、Atlas RATを識別する特徴的な痕跡といえます。

事例2: ZIPと偽libcef.dllからStage2へ（2026年3〜4月観測）

事例2は、事例1と同じ時期に日本を標的として観測した別の配布事例です。入口・ローダーの実装には差異があるものの、最終的に到達するのは事例1と同じAtlas RATです。By@V<マーカーやSFuck\0\0\0識別子を持つステージャ、AtlasInfoを入口とする後段の仕組みも共通します。

なお、この電子請求書発行のお知らせ.zipと偽libcef.dllを使う配布自体は、Proofpointが報告したキャンペーンと同系統のものです。そのため本節では、外部報告で詳しく触れられていない前段ローダーの内部実装を中心に述べます。具体的には次の3点です。

• 偽libcef.dllの耐解析・自己再配置処理
• 埋め込みStage2による後段ペイロードのファイバー実行
• 正規DLL領域を上書きするモジュールストンピング型Stage3

事例1と重複するRAT本体やステージャの共通部分は省きます。

事例2の実行フロー全体像を以下に示します。

事例1と同様に、メール本文中のリンク先ページから電子請求書発行のお知らせ.zipが配布されます。

電子請求書発行のお知らせ.zipはwimbrowser.exeとlibcef.dllの2つのファイルを含みます。

入口: 偽libcef.dllが環境確認とStage2起動を担う

libcef.dllはCEF（Chromium Embedded Framework）関連DLLを装う攻撃者作成の偽DLLです。多数のCEF関連名をエクスポートしていますが、その大半は戻り値0のスタブで、悪性処理はエクスポート関数cef_api_hashに集約されています。またDllMainも戻り値1のみの実質的なスタブです。そのため、DLLを単にロードしただけでは悪性処理は始まらず、cef_api_hashが呼び出されて初めて後段処理へ進みます。

cef_api_hashは、サンドボックス判定、自己再配置、環境確認、ダイレクトシステムコールによる埋め込みシェルコード起動を順に行います。

• まずCPU数・Cドライブ容量・Temp配下のファイル数を確認する。CPU数2未満、Cドライブ総容量約60GB未満、Temp配下の非ディレクトリ数が8未満という3条件をすべて満たす場合はExitProcessで終了する。リソースが少なく利用痕跡も乏しい自動解析環境を避けるための判定とみられる。
• 次に、ホストEXE（本事例ではwimbrowser.exe）と同梱*.dllを%LOCALAPPDATA%\Microsoft\へコピーし、CreateProcessWで再実行する自己再配置を行う。
• 再配置後のプロセスで、WDAGUtilityAccount、CExecSvc.exe、mshome.netアダプタ、vmsmbデバイス、Windows genuine判定など、VM・解析環境を意識した確認を行う。ただし、これらの結果は後続の分岐に使われない。
• 最後に、ntdllを解析してシステムコール番号を動的に解決するSysWhispers系のダイレクトシステムコールを用い、埋め込みシェルコードを同一プロセス内に展開・実行する。

この一連の処理により、偽libcef.dllはサンドボックス判定と自己再配置を行った後、埋め込みStage2 Shellcodeを同一プロセス内で起動します。後段の取得処理はStage2以降が担います。偽libcef.dll自体の役割は、この環境判定・自己再配置とStage2の起動にあります。

次段取得: 埋め込みStage2がC2からStage3を受信する

偽libcef.dllに埋め込まれたシェルコードは1597バイトのx64シェルコードで、図中の「Embedded Stage2 Shellcode」に相当します。libcef.dllを読み込んだプロセス内でスレッド実行され、C2へ接続して後段ペイロードを取得・実行します。

この前段シェルコードの役割と基本構造は、事例1のatl.iniとほぼ同じです。API Hashingによる動的API解決、By@V<マーカーでの埋め込みコンフィグ取り出し、SFuck\0\0\0識別子の送信、C2から後段を受信してコンフィグを後段へ引き継ぐ流れは共通します。一方で、次の細部が異なります。

• 平文のコンフィグではなく、XORで復号したコンフィグを使用する。
• 後段の実行方式がCreateThreadではなく、ConvertThreadToFiber・CreateFiber・SwitchToFiberによるファイバー実行。

本Stage2は、マーカー探索後に取り出したコンフィグを独自のXORキーストリームで復号します（詳細は付録A）。復号後のコンフィグにはC2 IP 154[.]211[.]86[.]110とポート886/TCPが含まれます。受信後は、復号済みのC2コンフィグを受信ペイロード内の所定領域（後述のC2コンフィグ領域）へ書き込み、ファイバー実行でStage3へ制御を移します。

RAT起動準備: Stage3が正規DLL領域にAtlas RAT本体を展開する

受信ペイロードは単一PEではなく、先頭の「Stage3 Shellcode」、続く「Atlas RAT本体」、4バイトの「PEサイズフィールド」、末尾の「C2コンフィグ領域」で構成されます。各領域の配置と役割は以下の通りです。

事例1の受信ペイロードでは、Stage3 Shellcodeの直後にAtlas RAT本体が配置され、別途本体長を示すフィールドは確認されませんでした。一方、本事例の受信ペイロードには、0x48004に埋め込みPEの実データ長を示すフィールドがあります。これは、Atlas RAT本体が受信バッファ内の一部として埋め込まれ、かつ暗号化され得るためとみられます。復号前の状態ではPEヘッダを参照できないため、Stage3 Shellcodeはこのサイズ値を使って、0x2004以降のどこまでを復号・マップ対象とするかを決定します。

ローダーの処理は以下の通りです。

• 事例1のStage3 Shellcodeや前段シェルコードと同じAPI Hashingで必要なAPIを解決する。
• Atlas RAT本体がMZで始まらない場合、後述のFeistel風変換で復号する。
• 未ロードかつ十分なサイズを持つ正規DLLを読み込み、その領域を上書きしてAtlas RAT本体のヘッダと各セクションを配置する（モジュールストンピング）。
• 続いて再配置・インポート解決・TLS・例外テーブル登録を行い、マップ後にPEヘッダをゼロクリアする。
• エクスポート関数AtlasInfoを解決し、C2コンフィグ領域の設定を引数に渡して呼び出す。実行後は、必要に応じて上書き先DLL領域のクリアなど後始末を行う。

復号に用いるのは、データを2バイト単位で複数ラウンド撹拌する独自の可逆変換です。2バイトを2分割して交互に処理する点がFeistel構造の暗号に似ているため、本記事では便宜的にFeistel風と呼びます（詳細は付録B）。

基本的な流れは事例1と同じで、API HashingによるAPI解決、Atlas RAT本体の手動マップ、AtlasInfoへのC2コンフィグ引き渡しを行います。一方で本事例では、モジュールストンピングやPEヘッダのゼロクリアが加わっており、事例1よりも検知・解析回避を意識したローダーになっています。

モジュールストンピングの対象になるのは以下に示す7つのDLLです。

Atlas RAT

Stage3 Shellcodeが正規DLL領域へAtlas RATを配置し、エクスポート関数AtlasInfoを呼びます。独自C2プロトコルやホスト情報の送信、WeChat.exeプロセスへのDLLインジェクションとアンロード処理などの機能を確認しています。一方、本事例では永続化と起動維持をRAT本体側が担い、スケジュールタスクとregsvr32スクリプトレットによる永続化を行う点が事例1と異なります。

このほか、同じZIP + 偽libcef.dll系統の亜種として、同一IPの154[.]211[.]86[.]110:886/TCPを使用する事例も確認しました。この亜種では、libcef.dll内に埋め込まれたデータをXORとAESで復号してStage2を組み立て、SysWhispers系のダイレクトシステムコールを用います。

さらに、SubChromProces.exe + 偽libcef.dll系の亜種も観測しました。こちらはSysWhispers系のダイレクトシステムコールでStage2を同一プロセス内へ配置し、EnumFontsWコールバック経由でStage2を呼び出します。いずれも最終的にはBy@V<マーカーを持つStage2、SFuck\0\0\0識別子、AtlasInfoを入口とするRAT本体へ収束することから、同系統ローダーの亜種と見ています。

まとめ

本記事では、日本を標的としたAtlas RAT配布2事例を追いました。入口や永続化の実装は事例ごとに異なります。一方で、マーカー探索でコンフィグを取り出し、識別子を送信するステージャを経てAtlas RATを起動する、という中核の仕組みは共通でした。攻撃者は配布経路や前段ローダーを更新しながら、この中核を使い回しているとみられます。

外部報告との整合も確認できました。RAT本体の挙動・機能はHexastrikeの報告と整合し、事例2のC2はProofpoint報告のIoCと一致します。また、同一C2に対して、異なるポートやパッケージングの事例を確認しています。これらの差分は、Atlas RATの配布に複数のバリエーションが存在しただけでなく、攻撃者が短期間に複数の配布形態やローダーを並行して使い分けていたことを示唆します。

本調査で確認した範囲でも、日本語の業務文書を装う検体を複数観測しており、国内組織にとって継続的な警戒が必要な脅威といえます。

IoC

ネットワークインジケーター

ファイルインジケーター

付録: 復号アルゴリズム

本文では概要にとどめた復号ルーチンを、再現・検証用に擬似コードとして掲載します。いずれも事例2のローダーで確認したものです。

付録A: Stage2のC2コンフィグ復号（XORキーストリーム）

埋め込みStage2 Shellcodeは、By@V<マーカー直後から取り出したコンフィグ（0x144バイト）を、添字に依存する項と固定キー配列を組み合わせたXORキーストリームで復号します。key配列の後半4語（0x67452301〜0x10325476）はMD5/SHA-1の初期化定数として知られる値です。

key = {
  0x2b9e3f7a, 0xc4f856d1, 0xb7428d1e, 0xe90ca365,
  0x67452301, 0xefcdab89, 0x98badcfe, 0x10325476
};
uint8_t *key_bytes = (uint8_t *)key;

for (i = 0; i < 0x144; i++) {
  k = (13 * i + 0x61)
    ^ (i * i)
    ^ key_bytes[(i >> 2) & 0x1f]
    ^ key_bytes[(i >> 3) & 0x1f]
    ^ key_bytes[(i >> 4) & 0x1f]
    ^ (0xdc - 7 * i)
    ^ key_bytes[0x1f - (i & 0x1f)]
    ^ (17 * (i + 4))
    ^ (19 * i);
  decoded_config[i] ^= k;
}

付録B: Atlas RAT本体の復号（Feistel風変換）

Stage3 Shellcodeは、展開対象のAtlas RAT本体がMZで始まらない場合、以下のFeistel風変換で復号します。2バイトを1ブロックとし、片方をラウンド関数（鍵を加えて0xB5倍）で変換してもう片方とXORし、両者を入れ替える操作を、4バイトの固定鍵で4ラウンド繰り返します。データ長が奇数のときは、末尾1バイトをRORとXORで別処理します。本文「Feistel風」の説明に対応する実装です。

key = { 0xae, 0x3f, 0xc2, 0x19 };

for (off = 0; off < inner_pe_size - 1; off += 2) {
  x = buf[off];
  y = buf[off + 1];

  for (round = 3; round >= 0; round--) {
    tmp = x;
    x = y ^ (uint8_t)(0xb5 * (uint8_t)(x + key[round]));
    y = tmp;
  }

  buf[off] = x;
  buf[off + 1] = y;
}

if (inner_pe_size & 1) {
  buf[inner_pe_size - 1] = ror8(buf[inner_pe_size - 1], 3) ^ 0xae;
}