この動作を見つけた場合-おめでとうございます、あなたはウィスラーブートキットを手に入れました。 それは今日議論されます。
現時点では、ウイルス対策会社の友人の一部と同様に、このブートキット感染者はいません。 ただし、マルウェアは新しい発明ではなく、Stoned PoCプロジェクトで表現された Peter Kleissnerのアイデアの継続であることは明らかです。 この場合、virmakerはおそらく、コードを追加または変更することさえせずに率直にコードをコピーしたでしょう。 だから物語...
しばらくの間、Peter KleissnerのStonedプロジェクトは、実際にシステムをロードする前に、システムのメモリにコードをロードする能力を示す方法でした。 これにより、OSを完全に制御できるようになりました。任意の権限で任意のプロセスを実行することから、Windowsセキュリティをバイパスし、Vista / Sevenでライセンスキーを制御することができます。 プロジェクトはオープンソースの下で非常に着実に開発されていましたが、カスペルスキーと他のいくつかの組織は、悪意のあるソフトウェアを配布したとされる作者を訴えました。 この行為とそれがいかに合理的かについてはコメントしませんが、昨年末から、著者は新しいバージョンの配布を停止し、利用可能な公開バージョンを大幅に削減しました。 Linuxプラットフォームのサポートも試用版の時点で中断されました。 そして、ウィスラーが登場し......
Peterからの情報によると、ウィスラーに関する最初の「プロモーション」ステップが1月にこのブログに登場したため、リークはおそらく今年の1月まででした。 1か月後、ブロガーは明示的に広告情報、およびブートキットのコストとサポートのコストに関する情報を明示的に破棄することを余儀なくされ、記事は広告の性格ではなく「情報」になりました。 さて、「オフサイト」ブートキットはここにありますが 、ここでは情報は少なくなりますが、もっと率直になりたいです:)
この日付に基づいて、ウィスラーは2009年10月20日付けのStoned v2 Alpha 3に基づいていると想定できます。 感染性および駆除用のコンパイルされたファイルにバンドルされたのはこのバージョンでした。 これを作業上の仮説として、ドロッパーがないため、このバージョンのStonedの作業と機能に基づいて、以下の情報が正確に作成されます。
最初は、USBフラッシュドライブからの自動実行、pdfの悪用（感染したpdfファイルからの感染）、感染者、特別なLiveCD / LiveUFDイメージのロード時の感染など、最も多様な感染方法がよく文書化されていました。 したがって、感染者は何でもかまいません。そのため、ウィスラーがどのように伝播され、どこで感染しているのかを理解することが難しくなります。
感染したOSのリストは印象的です。x64でサポートされている2000、XP、Vista、Seven、Server 2003、Server 2008。 同時に、ハードドライブのコンテンツ全体のハードウェアおよびソフトウェア暗号化で正しく動作します。 BIOSでMBRを変更する機能を無効にしても効果はありません（これはDOSおよびwin95 / 98でのみ機能したため、これは原則としてすでに無関係です）。
感染したシステムでは、MBRのブートローダーがブートキットコードの最初の実行時にパッチを適用し、その後の制御が元のブートローダーに移ります。 元のブートローダー、ブートキットコード、およびそのプラグインは、特別なファイルシステム（RawFS-元のStonedにあった）の物理ディスクの最後の未割り当て領域に保存されます。 この場合、ブートキットコードはこのシステムの最初のファイルであり、その場所は確実にわかっています。 これは重要なポイントです。完全に暗号化されたディスクでも感染することができます。ブートローダーは暗号化されておらず、未割り当て領域の始まりは確実にわかっているため、これで十分です。
ダウンロードが完了すると、ブートキットコードがメモリに配置され、既存のプロセスにプラグインをロードすることでさまざまな機能を実装できます。 ウィスラーの作成者がパブリックバージョンを入手したか、それともクローズドバージョン（NT-AUTHORITY \ SYSTEM権限を持つアプリケーションを起動するための既製のプラグインを含む）を入手したかはわかりませんが、一般的に、プラグインのブートキット実行スキームは次のとおりです。
1. PsGetVersion / RtlGetVersion関数により、オペレーティングシステムのバージョンが決定されます。
2.この情報に基づいて、EPROCESSおよびKTHREAD構造が決定されます。
3.ブートキットは、非同期プロシージャコールを介して、実行可能なユーザーモードプロセスにプラグインコードを挿入します。
段落からわかるように。 1-2、ブートキットコードを使用すると、任意のOSで作業できます。 ただし、プラグインとブートキットを区別する必要があります。後者はOS依存（特にビット深度-x32またはx64）であるため、RawFSシステムにはシステムごとに異なるバージョンを含めることができます。 Whistlerの作成者が昇格した権限でプロセスを実行できるプラグインを作成し、このプラグインがx32で作成されている場合、一般に、Whistlerはx32とx64の両方に感染し、メモリ内にブートキットがあります-しかし、プラグインはx32でのみその可能性を明らかにします別のビット深度では機能しません。
ウィスラーの作者が閉じたバージョンのStonedに出くわした場合、x64でプロセスの権限を実行およびエスカレートする方法はありませんでした（ NB !!! ）
オリジナルのStonedは、その存在とMBRの変更を隠しませんでした（たとえば、Sinowalによって行われたように）。 原則として、これは追加のプラグイン（上記を参照）を使用して実行できますが、エンコードする必要があります。 ウィスラーの著者の精神と能力が十分かどうかは不明です。
ウィスラーを持っている場合はどうしますか？ MBRの可用性に基づいて、標準のfixmbrで十分です。 ただし、このウイルスは「ダークホース」ですが、最初にMBRダンプを削除することを強くお勧めします。 これは、たとえば、コマンドラインで実行することによりMBRWizardを使用して実行できます。
mbrwiz.exe /save=mbr /filename=mbr.bin
アクションとアンチブートを試すことができます。 このユーティリティを少し変更したか、むしろ、隔離の収集を自動化しました。 一番下の行：ジャンクはこのコマンドでアンチブート調査を実施します：
antiboot.exe -l "%cd%\log.txt" -p "%cd%\MBR"
次に、ウイルスパスワードとともにMBRフォルダをquarantine.zip zipアーカイブにパックし、MBRフォルダを削除します。
ユーティリティには直接バグがあります：動作中のブレーキと一部のマシンの凍結。 次のようになります。コンソールでは次のように記述します。
Antibootkt, (c) Kaspersky Lab 2010, version 1.2.1
Log started
Unpacking driver
Starting up driver
その後-沈黙と長い間。 この場合、ユーザーにウィンドウを閉じて、作成したMBRフォルダーを手動で送信するように依頼する必要があります（既にダンプがあります）。
（LCの代表者によると、彼らはこのバグについて知っていますが、さまざまな理由でそれを排除することはできません）。
もちろん、 bootkit eSage Bootkit Removerによく知られている「ユニバーサル」治療法を使用することもできます。 それでも、アクティブなTDL2感染が存在する場合、このツールは「ディスクが見つかりません」という結果になるという証拠があります。 これは、使用する際に留意する必要がありますが、一般的に非常に良いことであり、使用することもお勧めします。 しかし、直接ではなく、少なくともこのスクリプトでは：
start /wait remover.exe dump \\.\PhysicalDrive0 mbr.bin
remover.exe fix \\.\PhysicalDrive0
結果のMBRダンプは、お気に入りのウイルス対策メーカーに送信できます:)これにより、WhistlerとStonedの違いを評価できます。 私はそれを何らかの形で強く疑います:)
PSこの資料の準備と、一般にStonedプロジェクトの一部として行われた作業に提供された支援に対してPeter Kleissnerに感謝します。