マルウェア
BPFフィルタを不正利用するバックドア型マルウェア「BPFDoor」の亜種を発見
APT（Advanced Persistent Threat：標的型攻撃）グループ「Red Menshen」によるバックドア型マルウェア「BPFDoor」は、2021年の初回報告以来、複数回に渡って進化を遂げてきました。そこで今回、当該バックドアのさまざまな亜種について分析を行いました。
近年におけるAPT（Advanced Persistent Threat：標的型攻撃）グループの動向として、Linuxやクラウドサーバを含むさまざまなシステムを幅広く狙う傾向が見られます。代表例として、VMwareのESXiサーバを狙うランサムウェアグループ、ボットネット「Mirai」の亜種、情報窃取ツールや暗号資産マイニング用マルウェアによってクラウドサーバを狙うグループなどが挙げられます。
このように、APTグループはWindows以外のシステムに対する攻勢を強めてきました。例えば、マルウェア「Sandworm」は、Linuxベースで出荷されるルータを狙って攻撃を行います。一般的なサイバー犯罪組織は、できるだけ多種多様な標的向けにマルウェアを展開して被害を及ぼそうとしますが、一方でAPTグループは、マルウェアの詳細が知られないよう、秘匿性を維持することに注力する傾向があります。中東およびアジア諸国の組織を狙うAPTグループ「Red Menshen（別称：DecisiveArchitectまたはRed Dev 18）」は、2021年に出現して以来、バックドア型マルウェア「BPFDoor」を継続的にアップグレードしてきました。BPFDoorはパケットフィルタ「BPF：Berkeley Packet Filter」を巧みに用いる点で特徴的であり、セキュリティ対策側での検知を困難なものとしています。「BPF」は、プログラムベースでネットワーク・パケットフィルタをオープンソケット内に埋め込む技術です。BPFDoorの背後にいる攻撃グループは、本技術を不正利用し、LinuxやSolaris系システムに設置されたファイアウォールの内向きトラフィックルール、または同種のネットワーク保護ソリューションをすり抜けようと画策しています。トレンドマイクロでは、Linux版のBPFDoorを「Backdoor.Linux.BPFDOOR」として、Solaris版のそれを「Backdoor.Solaris.BPFDOOR.ZAJE」として検知します。なお、トレンド製品の監視、検知機能には、当該マルウェアに関する追加のパターン情報が導入されています。
本稿では、APTグループ「Red Menshen」がBPFフィルタをいかに進化させてきたかについて解説します。2022年当時の検体と比べると、BPFプログラムの命令数（インストラクション数）は約6倍にも増えていることが判明しました。こうした動向より、Red Menshenは現在なおBPFDoorの開発を積極的に推し進め、アップグレードの労力に見合った報酬を、攻撃の成果として獲得し続けているものと考えられます。この他、本稿では、防御側の視点から見たセキュリティ上の知見や、感染システムからBPFDDoorを検知する方法について解説します。
BPFの概要
バックドア「BPFDoor」は、オペレーティングシステム（OS）のカーネル内部にパケットフィルタをロードする機能を備えている点で、他とは一線を画しています。当該機能はしばしば「BPF（Berkely Packet Filter）」と呼ばれますが、特にLinux版で実装したものはLSF（Linux Socket Filtering）と呼ばれることもあります。
BPFやLSFは、「eBPF」と呼ばれる技術の一部と考えられます。eBPFは当初、「extended BPF（拡張型BPF）」の略語として用いられていましたが、現在ではBPF以外にも数多くのタスクをサポートするように進化しています。結果、当初の「extended BPF」としての意味は損なわれながらも、eBPFという呼称自体は残って使用され続けています。BPFがパケットフィルタであるのに対し、eBPFは抽象的な仮想マシン（VM：Virtual Machine）に近い存在であり、ユーザ定義のプログラムをLinuxカーネルのサンドボックス環境内で実行することが可能です。ちょうど、ユーザの制御下に置かれた環境内でアプリケーションやソフトウェアを実行することに相当します。BPFについては、eBPFとの区別を明確にするために「cBPF（classic BPF：クラシックBPF）」と呼ばれる場合もあります。
クラシックBPFでは、パケットフィルタリングのルールをプログラム形式でオープン・ネットワークソケットに追加します。このプログラムはソケット側からデータを読み取り、さらに、追加したルールに合致するパケットが到着した場合は、その通知を受け取ることが可能です。LinuxでBPFを多用したライブラリの一例が「libpcap」であり、パケットキャプチャツール「tcpdump」などに組み込まれています。実際にtcpdumpを「-d」のオプション付きで起動すると、作成されたBPFフィルタの内容をlibpcapのフィルタ表現形式で参照できます。
図1のコードは、「BPFアセンブリ」と見なせます。そして、このコードを解読できる仮想マシンが、カーネル内に組み込まれています。tcpdumpの起動時にオプション「-dd」を指定すると、これらのコードに対応するバイト表現を確認できます。
図2から示唆される通り、クラシックBPFの各命令は、8バイトで構成されます。詳細については、Linuxカーネルに関する公式文書でご確認いただけます。
BPFDoorの仕組み
BPFDoorに組み込まれたBPFフィルタの機能により、攻撃者はただ1個のネットワークパケットを送信するだけで、バックドアを起動することが可能です。ここで送信するパケットは「マジックパケット」と呼ばれるものであり、特殊な数値（マジックナンバー）が埋め込まれています。なお、送信したマジックパケットがファイアウォールによってブロックされるような場合でも、バックドアは起動します。これは、標的OSにおけるBPFの仕組み上、パケットは最初にまずカーネルのBPFエンジン側に到達するためであり、結果、待機状態のバックドアが稼働します。このような手法はルートキットでよく見られますが、バックドアとしては稀なものです。
BPFDoorの検体は、稼働中のカーネル内部にクラシックBPFフィルタをロードします。この際、Linux版の検体ではシステムコール「setsockopt()」のオプション「SO_ATTACH_FILTER」を用いてコンパイル済みフィルタをロードするのに対し、Solaris版ではlibpcapの機能によってフィルタをコンパイルし、実行時にロードを行います。このフィルタは、先述のマジックナンバーを含むパケットを待ち構えます。実際に当該パケットが到着すると、フィルタが反応を示し、それに呼応する形でBPFDoorからパケット送信元に向けてリバース接続が行われます。以上のような仕組み上、マジックナンバーの値自体はバックドアを起動する信号に過ぎず、ソースコード中での意味や役割を示唆するものではありません。
図3のように、リバース接続を元手として、攻撃者は標的システムにパイプ経由でコマンドを送信します。別の言い方をすると、BPFDoorはリバースシェルを開くことで、攻撃者からリモートで送られてくる任意のコマンドを受け付けるようになります。BPFDoorの稼働にはルート権限が要求されるため、それによって開始されるリバースシェルにも高い権限が付与されます。
BPFDoorの各種検体を比較したところ、フィルタの細かな動作や、リバース接続前に待ち受けるマジックナンバーには、一定の差異が見られました。以降、検体別でBPFのコードを解析した結果について解説します。
2023年以前の検体
2018年から2022年に見られた検体の大半は、同一のBPFプログラムを使用し、TCP（Transmission Control Protocol）、UDP（User Datagram Protocol）、ICMP（Internet Control Message Protocol）プロトコルのパケットを対象に、マジックナンバーをチェックします。本稿では、これらに属する検体を「亜種A型」と呼びます。下図に、亜種A型に相当するBPFプログラムの解析結果を示します。
亜種A型が用いるBPFプログラムは、計30個の命令によって構成されています。以降、フィルタの複雑さを表す指標として、BPFの命令数を用いることとします。亜種A型のフィルタをlibpcapの文法に則して記載すると、下記のようになります。
udp[8:2]=0x7255 or (icmp[8:2]=0x7255 and icmp[icmptype] == icmp-echo) or tcp[((tcp[12]&0xf0)>>2):2]=0x5293
上のフィルタ式では、パケット内の「データ部」にアクセスする際、その場所を「オフセット値」によって表します。UDPとICMPの場合、データ部はオフセット8（バイト）から開始します。TCPの場合は少し複雑であり、データ部へのオフセット値自体が、オフセット12から4ビット分の値として格納されています。この4ビット分を抜き出すため、上記のフィルタ式には、0xf0とのビット論理積（「&」で記載）が含まれています。0xf0とのビット論理積は4ビット左にずれた値となっているため、これを「4ビット右にシフト」する必要があります。また、格納されている「オフセット値」はワード単位（4バイト単位）で換算されたものであり、これをバイト単位に戻すためには、さらに「2ビット左にシフト（4倍にする）」する必要があります。以上に挙げた2度に及ぶビットシフト操作は、「2ビット右にシフト」という1度のビットシフト操作に集約できます。式としては、以下のように表されます。
(x >> 4) * 4 == (x >> 4) << 2 == x >> 2
フィルタの内容から示されるように、感染システム上のバックドアを起動させるパケットとして、下記の3種類が存在します。
- データ部にマジックナンバー「0x7255」を持つUDPパケット
- データ部にマジックナンバー「0x7255」を持つICMP ECHO（Ping）パケット
- データ部にマジックナンバー「0x5293」を持つTCPパケット
2023年の検体
マルウェア分類ツール「telfhash」により、TCPパケットに限っては4バイト長のマジックナンバーも受け付けるなどの追加仕様を持つ検体が、新たに4種類発見されました。当該検体の1つである「亜種B型」には、39個の命令からなるBPFプログラムが組み込まれています。下図に、その解析結果を示します。
図中の赤枠は、亜種A型にはなかった9個の追加命令に相当します。その内容としては、TCPパケット上で所定のオフセット位置にマジックナンバー「0x39393939」が存在するかを調べ、存在する場合には、バックドアを起動します。本機能が追加された経緯として、前回の記事でBPFDoorの詳細が明るみに出たことを受け、攻撃者はバックドアを起動する新たな方式を追加したものと推測されます。本フィルタは、下記のように表現できます。
udp[8:2]=0x7255 or (icmp[8:2]=0x7255 and icmp[icmptype] == icmp-echo) or
tcp[((tcp[12]&0xf0)>>2):2]=0x5293 or tcp[((tcp[12]&0xf0)>>2)+26:4]=0x39393939
このフィルタ式から示されるように、新しいマジックナンバーは、TCPパケットのデータ部から26バイト先に位置しています。最初の26バイトは無視される作りであり、攻撃者は検知の難化を狙った可能性があります。また、先述した亜種A型のマジックナンバーも依然として有効であり、古いバージョンとの間で互換性が保たれている点は、注目に値します。
疑わしい機能：MACアドレスのチェック
公開リポジトリにアップロードされたBPFDoorの検体を調査した際に、205個の命令からなるBPFプログラムを用いる「亜種C型」が発見されました。BPFプログラムの命令数としては、先述のA型やB型と比べて数倍の規模を持つことになります。
亜種C型のBPFプログラムはまず、パケット内にある48ビット長（6バイト）の宛先MACアドレスから先頭の4ビットを抽出します。そして、4ビットの値が0x4である場合にのみ、言い方を変えると、宛先MACアドレスが0x4で始まる場合にのみ、バックドアを起動する動きとなっています。本処理に対応するBPFのコードを下記に示します。
l0: ldb [0] # load the first byte of the packet to A register. l1: and A, #0xf0 # A = A & 0xf0 (bitwise AND). l2: jeq #0x40, l3, l33 # if the result is equal to 0x40, jump to location 3 (l3) and continue execution.
上記コード中、「A」で示されるバイトの上位4ビットが0x4であるならば、「A & 0xf0」の値は0x40となります。この後、プログラム上の動作として、下位4ビット分がマジックナンバーのオフセット情報として扱われます。弊社の分析によると、下位4ビットとして最も有りがちな値は0x3となります。この場合、プログラムは、データ部の先頭から6バイト先にマジックナンバーが存在するかをチェックします。
しかし、下位4ビットのこうした用法が本当に意図したものであるかどうかは、定かではありません。可能性として、攻撃者はもともとIPv4パケットとIPv6パケットを区別する意図でコードを作成したつもりが、誤りによって、宛先MACアドレスを見るような動作となったケースが考えられます。別の可能性として、コードの内容は意図した通りであり、実際に0x4で始まるネットワークカードを備えた端末を狙っていたケースも考えられます。この場合、MACアドレスの先頭3バイトはベンダー識別子（OUI：Organisationally Unique Identifier）であるため、端末に装着されたNICの製造元に応じて標的を判別していることになります。しかし、「標的」として判別される製造元は、相当な広範囲に及ぶもの（OUIが0x4から始まる）と考えられます。
一方、マジックナンバー自体については2022年の検体から変わっていません。UDPとICMPは双方とも0x7255、TCPは0x5293または0x39393939となります。なお、コードを解析した際、MACアドレスが0x6で始まるパケット（攻撃者の意図としてIPv6パケットをチェックしている可能性もあり）に対する処理ルートも発見されましたが、到達不可能のように見受けられます。下図の解析結果のうち、有効なパケットに対応する処理ルートを黄色の背景で示します。
2023年の検体中、他の3つについては、上述したBPFプログラムの改良版が使用され、その命令数は229個となっていました。この改良版も、受信したICMPパケットが確実に「ECHOリクエスト（Ping要求）」によるものであることを確認します。本稿ではこれを「亜種D型」と分類します。さらに、2023年におけるもう1つの検体として、マジックナンバー「44 30 CD 9F 5E 14 27 66」を用いるものが、サイバーセキュリティ企業「Deep Instinct」から報告されています。本稿では、これを「亜種E型」と分類します。
被害者分析および検知法
トレンドマイクロのテレメトリ情報によると、今回の攻撃では、特にトルコと香港の電気通信業界が集中的に狙われています。現時点でまだ2023年半ばですが、2022年と比べると、当該の国や業界におけるユニーク検知の頻度が一層高まっています。こうした傾向について、2022年のPwCによる初回報告と比較すると、「行政、教育、流通」以外の業界についてはよく一致していると考えられます。該当する業界に属する防御チームでは、使用中のサーバを入念に検査することを推奨します。例えば、下記パラメータを添えてコマンドライン「ss」を起動することで、Linuxサーバ上で稼働しているプロセスの中から、特にBPFフィルタの追加に関与しているものを抽出することが可能です。
- -0または--packet：ファミリ「PACKET」に相当するソケットを表示
- -pまたは--processes：当該ソケットを使用中のプロセスを表示
- -bまたは --bpf：ソケットに紐づくBPFプログラムをダンプ表示
例として、亜種A型に感染したLinux系端末上での検査結果を下図に示します。
図9では、BPFフィルタを用いるプロセスとして2つが示されています。「dhclient（PID 1893）」は、11個（図中、bpf filter後の括弧内の数値）の命令からなる正規なBPFフィルタを有しています。一方、「hald-addon-acpi（PID 2629）」は、30個の命令からなる不審なBPFフィルタを有しています。図中、黄色で示される数値は、バックドアを起動するためのマジックナンバー（29269は0x7255の十進表記、21139は0x5293の十進表記に相当）と一致します。セキュリティ対策チームでは、不正の判定材料としてファイル名を過信しないことを推奨します。ファイル名は、感染毎に変わる可能性があるためです。代わりに、こうしたマジックナンバーを検査することが有用です。下図に、亜種D型に感染した端末上での検査結果を示します。
まとめ
マルウェアにBPFのコードを埋め込む手口は、セキュリティチーム、特にマルウェア解析者やネットワーク防御者にとっての新たな課題になると予想されます。BPFプログラムの入念な解析は、ファイルやネットワークトラフィックのルールを正確に作成する上での鍵となります。しかし、BPFコードの解析ツールやデバッグツールは限られているため、実際に検体内のBPFプログラムを分析することは容易ではなく、さまざまな苦労に遭遇する可能性があります。BPFフィルタの不正利用は、従来のサイバー犯罪であまり目にすることのなかった手口であり、今後、新たな脅威を形成するものとして十分に警戒していく必要があるでしょう。
BPFDoor以外でBPFフィルタを不正利用するマルウェアとしては、「Symbiote」が挙げられます。BPFフィルタは新しいものではありませんが、マルウェアがこれを多用するケースは稀です。一方、解析ツールについても、BPFプログラムを扱えるものは少数に留まります。IDA Proをはじめとするほとんどのツールが、プラグイン拡張などを行わない限り、デフォルトでは対応できません。例外がオープンソースのフレームワーク「Radare2」であり、解析向けツールキットとして利用できます。LinuxのカーネルチームからはBPFフィルタを扱うコマンドラインツールが数種ほど提供されていますが、解析用にはさらなる機能拡充が望まれます。また、弊社が把握している限り、BPFフィルタに焦点を当てたマルウェア関連トレーニングなどは、行われていないようです。以上を踏まえると、マルウェア解析の観点において、BPFフィルタの不正利用は「新しい」ものと考えられます。そして、マルウェア関連のトレーニングプログラムでBPFフィルタについて取り扱うことは、将来に向けての一助になる可能性があります。
BPFDoorが用いるBPFフィルタの進化を踏まえると、当該の攻撃グループは、バックドアの秘匿性を維持し、活動の痕跡を隠すための手法を模索し続けていると考えられます。ネットワーク防御チームでは、こうした変化に合わせて現存のルールを適宜更新することを推奨します。また、マルウェア解析チームでは、可能な限り早くBPFフィルタの解析法について理解を深めることを推奨します。
BPFDoorによる攻撃では、感染端末への完全なアクセス手段が攻撃者に掌握される可能性があります。防御担当チームの方は、環境内で稼働しているBPFプログラムに対して十分に警戒することを推奨します。
MITRE ATT&CK Techniques
BPFDoorによってロードされるBPFプログラムの内容と、Mitre ATT&CKフレームワークの各種テクニックを比較しました。その結果、唯一合致するものとして、テクニック「T1205：Traffic Signaling（トラフィック・シグナリング）」とそのサブテクニック「T1205-002：Traffic Signaling: Socket Filters（トラフィック・シグナリング：ソケットフィルタ）」のみが確認されました。
侵入の痕跡（Indicators of Compromise、IoC）
侵入の痕跡（IoC）についてはこちらで確認してください。
マジックナンバー
今回取り上げたさまざまなBPFフィルタが受け入れるマジックナンバーを、下表に示します。
上記のマジックナンバーをもとに不審なBPFプログラムを発見する際、防御チームやセキュリティチームでは、下記のLinuxコマンドをご利用いただけます。
ss -0pb | grep -EB1 --colour "$((0x7255))|$((0x5293))|$((0x39393939))"
参考記事：
Detecting BPFDoor Backdoor Variants Abusing BPF Filters
By: Fernando Merces
翻訳：清水 浩平（Core Technology Marketing, Trend Micro™ Research）