こんにちは。プロダクト開発部の髙木です。 今回はAIコーディングエージェント向けのコードエディタである Superset の紹介になります。公式では『The Code Editor for AI Agents』と紹介されており、Claude CodeなどのコーディングエージェントをGUIから扱えるデスクトップアプリです。現時点ではmacOSのみの提供ですが、公式ドキュメントではWindows・Linuxも近日対応予定とされています。 僕はマウス操作によるGUIに慣れているため、自分にあっているツールを探そうとしたときにフィットするツールが見つけられませんでした。同じような悩みを持つ方の参考になればと思います。 これまでの自分の開発 これまでの開発では主にVisual Studio Code（VSCode）を使用しておりました。開発する言語にもよりますが、VSCodeは開発に必要なベースが整っており、足りないものについてはプラグインによって拡張できる優れた統合環境です。基本的にはVSCodeで完結できるため、VSCodeで開発できるように環境を整えていました。 現在の自分の開発 もう自分でコードを書く頻度は激減しClaude Codeと対話してコードを出力する毎日です。個人的にはこの開発方法は肌にあっています。コードの設計方針などを対話をしつつ進められるため、具体的な実装をClaude Codeに移譲できることで、その方向性が正しいかを常に考えながら成果物を見ることができます。自分で考えながら作っていると検討漏れが起きやすかったのですが、ドライな目で実装を眺められるので成果物の質は上がったように思います。 つまり現在は、もともと開発環境に求められていたエディタに入力するための思考や入力のしやすさではなく、出力されたものを確認したり修正を依頼するレビューベースの開発を行っている状況です。さらに複数のリポジトリを並行で作業できるような作業的な余裕も生まれ、加えて同一リポジトリ内で並行して作業するケースも増えてきました。そうなってくると1ブランチ1画面のVSCodeでは、作業したいリポジトリに対して行き来する画面が多すぎて本来の作業以外に画面の整理のような雑務が発生する状況になっていました。もしかしたらVSCodeにそういった拡張機能があるかもしれませんが、ちゃんと調査までは行えていません。 こういうときにキーボードベースの開発に慣れていればtmuxで画面分割をしつつタブで画面を変えるなどの作業ができたのかもしれません。そういう意味で cmux はそういう人には向いているツールだと思います。 cmux自体は『AIコーディングエージェント向けの縦タブと通知機能を備えたGhosttyベースのmacOSターミナル』と説明されており、CUIベースでの開発が好きな人には合うと思います。 AIによる開発で求めていた機能 GUIで操作できる 複数のリポジトリを行き来できる 同一リポジトリの複数ブランチで並行作業ができる コードのdiffが確認しやすい コードを確認できる これらができるツールを探しており、たどり着いたのがSupersetでした。 GUIで操作できる 基本的な操作はGUIをベースで実行できます。ここはあまり掘り下げるポイントがないので割愛します。 複数のリポジトリを行き来できる リポジトリを追加することができ、左側のタスクバーに追加したリポジトリが表示されます。クリックすることで簡単に切り替えることができます。これも複雑な機能ではないため割愛します。 同一リポジトリの複数ブランチで並行作業ができる 各ブランチをワークスペースという概念で扱っています。公式では、 Each workspace = one git branch. と表現しています。左側にタスクバーが表示されており、そこからマウスクリックでリポジトリやワークスペースを切り替えることができます。 公式トップの画像を引用 良きポイントとして各ワークスペースが独立しているため、AIエージェントのコンテキストが混ざらずに使用することができます。Workspace自体はGit Worktreeで管理されていますが、利用者がそれを意識する必要はなく+ボタンを押すことで追加することができます。追加時にブランチ名やプロンプトを入力することでそのまま作業を開始してくれます。 コードのdiffが確認しやすい VSCodeを使用していたこともあり、ツール内でdiffを確認したいと思っていました。 difit を使うことも考えていましたが、スキルを使ったりアプリケーションを立ち上げることに手間を感じていたのでできれば内蔵が良いと思っていました。リッチなものではありませんが、必要十分な機能だと思いました。 コードを確認できる エージェントが作ったコードを見る際に、簡素なコードをシンタックスハイライトつきで見られれば良いと思っていました。Claude Codeが表示したファイルパスをCmd+クリックで表示することができるので、簡単な確認であれば十分です。このあたりの機能はVSCodeと同様でした。 使ってみて気づいた利点 ソフトウェアのアップデートでも作業が中断しない ソフトウェアアップデートをすると大体のツールが再起動となり、これまでのコンテキストが失われます。もちろん --continue などのパラメータをつければコンテキストを復活できますが、バックグラウンドで起動していたアプリケーションなどの接続は失われるため、作業していたものを復旧することができません。しかしこのツールはアップデートをしたとしても作業を自動で復旧してくれます。具体的にどのような仕組みなのかまでは追っていませんが、アップデートが億劫にならないというのは他のツールではあまり感じたことがありませんでした。 作業のスピードが上がった 1つのリポジトリにおいて並列で調査をしたりすることが増えたことで、こなせる作業量が増えたように感じます。これまではブランチの切り替えにおいて自分で管理していたこともあり、簡単にGUIで作業できるようになったことは別ブランチでの作業の億劫さを軽減してくれました。これまではstashしたものがどこにいったかわからなかったり、作業に戻ろうと思ったときに戻れない事が多かったので、ズボラな自分にあった作業のしやすさだと思います。 Supersetだけで完結しない部分とその割り切り コードをちゃんと読もうとしたとき、僕としてはコードジャンプが必須です。VSCodeでできていたコードジャンプが、Supersetでは（おそらく）できませんでした。ちゃんと調査はしていないのでもしかしたらできるかもしれません。 困っていない理由としては、コードジャンプでコードを確認するためだけにVSCodeを開くからです。SupersetにはIDEなどで開くためのリンクが設置されているため、機能不足は普段使っているツールで解消することができます。足りない機能をいつも使っているツールに流せるため、思っていたよりもストレスも低く移行できました。最初は全てのツールをこなせるものを考えていましたが、得意なことを得意なツールにやらせたほうがストレスもたまらないと思いました。 まとめ 簡単にですがSupersetについて書きました。これまで開発に求められていた機能とは異なり、並列性や切り替えのしやすさなどが求められる時代になったと思います。作業の仕方を変える必要はありませんが、自分にあったツールを使っていくことで作業のやりやすさも変わると思いました。 個人的にはSupersetで得られた体験が非常に心地よかったので、皆さんにも一度試してもらいたいです。

「カードリーダーを接続したのにドライブが表示されない」という問い合わせは、Windowsの「空のドライブは表示しない」設定が原因かもしれません。本記事では、SKYSEA Client View導入時にお客様から寄せられたこの事例をもとに、フォルダオプションから設定を変更し、媒体が挿入されていなくてもドライブアイコンを常に表示させる方法をスクリーンショット付きで解説します。Windowsの仕様による挙動と、その確認・変更手順を紹介します。

想定読者：SOC アナリスト、脅威ハンター、検知エンジニア。SIEM の経験はあるが Elastic / EQL は初めて、あるいは復習したい方。 読了時間：約 15 分 セキュリティ運用の現場では、毎日とんでもない量のログを見ます。Elasticsearch は「ログを保存して検索する」のはとても得意です。でも、 脅威の検出 となると話が一段難しくなります。 なぜか。攻撃は単独のイベントではなく、 複数のステップが時間軸の上で連なる流れ だからです。 たとえば、次のような流れを「ひとかたまり」として検出したいとします。 ファイルが Temp フォルダに作成された その直後にそのファイルが実行された さらにそのプロセスが外部に通信した 普通のクエリでは、これを 3 回別々に検索して、ID やタイムスタンプで突き合わせる必要があります。これがしんどい。 EQL（Event Query Language）は、この「流れ全体」を一度のクエリで捕まえるために作られた言語 です。本記事では、セキュリティエンジニアが EQL を実務で使えるようになるための最短ルートを紹介します。 目次 EQL とは何か EQL を動かすための前提 通常の検索クエリ（KQL/Lucene）と何が違うか Splunk SPL を使っている人へ：EQL との対応表 同じ検出を SPL と EQL で書き比べる EQL の SPL に対する優位点 EQL の基本構文 最小単位の形 例 1：PowerShell 実行の検出 例 2：複数条件の組み合わせ EQL の演算子チートシート == と : の使い分け（ハマりやすい） ECS：Elastic Common Schema を理解する ECS とは何か セキュリティで頻出する ECS フィールド タスク文を EQL に変換するフレームワーク 5 ステップ翻訳法 実演：タスク文を 5 ステップで翻訳する キーワード → ECS フィールドの早見表 sequence と時間制約：流れの検出 構文 by の力：複数フィールドで相関 イベント間で値を引き継ぐ：per-event by maxspan の選び方 実例：セキュリティ検出パターン 5 選 パターン 1：暗号化されていない通信の検出（コンプライアンス） パターン 2：PowerShell ダウンロードからの C2 接続 パターン 3：Office アプリからのプロセス起動（Living off the Land） パターン 4：マルウェア配置 → 実行 → C2 通信 パターン 5：横展開の検出（ラテラルムーブメント） よくあるミス と正しい書き方 ミス 1：ECS でないフィールド名を使う ミス 2：大文字小文字の罠 ミス 3：event.action と event.type の混同 ミス ４：sequence の順序逆転 ミス ５：maxspan の単位忘れ ミス ６：EQL 関数の大文字小文字を間違える ミス ７：関数の引数の大文字小文字でヒットしない 実際に動かす方法 方法 1：Kibana の Dev Tools で試す 方法 2：Elastic Security の Timeline 方法 3：Detection Rule として登録 まとめ 参考資料 EQL とは何か EQL は Elastic が開発した、 イベントベースのクエリ言語 です。SQL や KQL に少し似ていますが、決定的に違うのは「 複数のイベントの順序と関係性を表現できる 」点です。 ひとことで言うと: EQL は「A が起きて、その後に B が起きて、さらに C が起きた」を 1 つのクエリで書ける言語。 これは脅威検出と相性が抜群です。なぜなら、攻撃チェーン（MITRE ATT&CK で言うところの Tactics の連鎖）は、まさにそういう構造をしているからです。 EQL を動かすための前提 ここで先に伝えておきたいことがあります。EQL は ECS（Elastic Common Schema）を前提に設計されているため、 検索対象のデータには @timestamp と event.category フィールドが必要 です。Elastic 公式ドキュメントにも、EQL はデフォルトでこの 2 つのフィールドを使うと明記されています。 つまり、 process where process.name == "powershell.exe" の process は、実際には「event.category が process のイベント」を意味します。 Elastic Agent や Elastic Defend、Beats から取り込んだデータは ECS に準拠しているのでそのまま EQL が動きます。独自データの場合は、最低限この 2 フィールドをマッピングしておく必要があります。 通常の検索クエリ（KQL/Lucene）と何が違うか 特性 通常のクエリ (KQL) EQL 1 つのイベント検索 ✅ 得意 ✅ 得意 集計・統計 ✅ 得意 ⚠️ 限定的 複数イベントの順序関係 ❌ 自前で組み立て ✅ ネイティブ対応 時間窓での相関 ❌ 困難 ✅ maxspan で簡単 ECS フィールドの活用 ✅ ✅ 「単一イベントを検索したい」なら KQL でも十分です。 「攻撃の流れを検出したい」なら EQL です。 Splunk SPL を使っている人へ：EQL との対応表 SOC 経験者の多くは Splunk SPL の知識があるはずです。両者の対応関係を理解しておくと、EQL の学習速度が一気に上がります。 やりたいこと Splunk SPL Elastic EQL 単一イベント検索 search index=… process=”…” process where process.name == “…” 複数イベントの相関 transaction host maxspan=30s sequence by host.name with maxspan=30s ストリーミング相関 streamstats sequence データモデル / 正規化 CIM (Common Information Model) ECS (Elastic Common Schema) フィールド指定 process_name（CIM） process.name（ECS） 否定 NOT not / != ワイルドカード * * (: または like 演算子) ⚠️ これは厳密な機能対応ではなく、考え方を理解するための対応表です。 Splunk の transaction はイベントをまとめて後処理するイメージが強く、EQL の sequence は「順序あるイベント列」をネイティブに表現する処理です。考え方として近い、というレベルで捉えてください。 同じ検出を SPL と EQL で書き比べる シナリオ： PowerShell が実行され、30 秒以内に外部 HTTPS 接続が発生 Splunk SPL: (index=endpoint sourcetype=process process_name="powershell.exe")   OR (index=endpoint sourcetype=network dest_port=443) | transaction host maxspan=30s | where mvcount(sourcetype)>1 Elastic EQL: sequence by process.entity_id with maxspan=30s   [process where process.name == "powershell.exe"]   [network where destination.port == 443] EQL の方が「 意図がそのまま構文になっている 」のがわかります。「これが起きて、次にこれが起きる」と読める。（process.entityの代わりに広域な相関で host.name を使う事も可能です） EQL の SPL に対する優位点 実務でメリットになるのは、おおむね以下の点です。 構文が攻撃チェーンのメンタルモデルと一致 — sequence … [event A] [event B] という形が、そのままアナリストの思考順序になる 時間ウィンドウの指定が一行 — with maxspan=30s を足すだけ ECS により書いたクエリの再利用性が高い — process.name を含むデータであれば、Windows、Linux、各種 EDR を横断して同じクエリが使える 検知ルールにそのまま流用可能 — Elastic Security の Detection Engine が EQL をネイティブサポート オープンスタンダードに沿った設計 — ECS は OpenTelemetry の Semantic Conventions に統合される方向で進化している 逆に EQL が苦手なこと も正直に書いておきます。 大規模な統計集計（カウント、平均、グルーピング）→ ES|QL や Lens の方が向いている 複雑な条件分岐や後処理 → ES|QL を併用するのが現実的 フィールド同士の比較（例：「1 回目の host.name と 2 回目の host.name が違う」）→ EQL 単独では難しい。ES|QL での後続分析と組み合わせる EQL は「 順序ある脅威検出 」のためのツール。集計や複雑な比較が必要なら別のツールと組み合わせるのが Elastic 流です。 EQL の基本構文 ここから手を動かす段階に入ります。 最小単位の形 event_category where condition たったこれだけ。読むと: event_category：何のイベントを見るか（process、file、network、authentication、registry など。内部的には event.category の値） where：条件を続けますよ、という宣言 condition：実際の条件 例 1：PowerShell 実行の検出 process where process.name == "powershell.exe" 例 2：複数条件の組み合わせ process where process.name == "powershell.exe"   and process.command_line : "*DownloadString*" ここで重要な演算子を整理しておきます。 EQL の演算子チートシート 演算子 意味 使いどころ == 厳密一致（大文字小文字を区別） プロセス名、ポート番号など正確に一致させたい時 != 一致しない 除外条件 : 大文字小文字を区別しない文字列一致 （ワイルドカード *、? 対応） パス、コマンドライン、拡張子（実体は like~ と等価） like ワイルドカード一致（大文字小文字を 区別する ） パターンマッチ like~ ワイルドカード一致（大文字小文字を 区別しない ） : と同じ in リストのいずれか（区別あり） process.name in (“cmd.exe”, “powershell.exe”) in~ リストのいずれか（区別なし） 大文字小文字が揺れるデータに not 否定 not process.name == “explorer.exe” and / or 論理演算子 条件の組み合わせ 💡 メモ： : は「ワイルドカードが使える ==」と覚えると間違いません。文字列の比較で、== より柔軟（大文字小文字も吸収、* ? も使える）。 == と : の使い分け（ハマりやすい） # ❌ ハマるパターン：ファイル拡張子に == を使うと小文字限定 file where file.extension == "exe"   # .EXE は引っかからない # ✅ : を使えば大文字小文字の揺れを吸収 file where file.extension : "exe"    # .exe も .EXE もマッチ Windows の拡張子は大文字小文字が混在することがよくあります。ファイルパスや拡張子は基本的に : を使う方が安全です。 ECS：Elastic Common Schema を理解する EQL を本気で使うには、 ECS の理解が欠かせません。これは Splunk の CIM に相当する概念です。 ECS とは何か ECS は「 Elasticsearch にイベントデータを保存するときの共通フィールド仕様 」です。 セキュリティログは多種多様なソースから来ます。 Windows Sysmon Linux Auditd ファイアウォール EDR クラウドサービスの監査ログ これらが全部バラバラのフィールド名（proc_name、process_name、pname、Image…）だと、検索のたびにスキーマを覚え直す羽目になります。 ECS はこれを process.name のような共通名に統一する仕様です。 ECS 対応のデータであれば、同じ意味の情報を同じフィールド名で扱える ようになります。 ⚠️ 注意： ECS は「共通化のルール」であって「すべてのデータソースが必ず全フィールドを持つ」保証ではありません。たとえばネットワーク機器のログには通常 process.name がありません。実際にどのフィールドが入っているかは、データソースやインテグレーションによって異なるため、Kibana の Discover や Data Views で確認してから書く習慣をつけましょう。 セキュリティで頻出する ECS フィールド 実務でほぼ毎日使うフィールドを覚えておきましょう。 プロセス フィールド 内容 process.name プロセス名（例：powershell.exe） process.executable フルパス（例：C:\Windows\System32\powershell.exe） process.command_line コマンドライン全文 process.pid プロセス ID（OS が割り当てる数値） process.entity_id プロセスの一意識別子（Elastic Defend などが付与。 推奨 ） process.parent.name 親プロセス名 process.parent.entity_id 親プロセスの entity_id 💡 process.pid と process.entity_id の違い： PID は OS のプロセス識別子ですが、プロセス終了後に 再利用される ため、長い時間ウィンドウのクエリでは別プロセスのイベントが混ざる可能性があります。Elastic Defend や Sysmon が付与する process.entity_id はプロセスごとに一意な値なので、sequence の by 句では process.entity_id を優先 します。 ファイル フィールド 内容 file.path フルパス file.name ファイル名 file.extension 拡張子（. なし） file.size バイト数 file.hash.sha256 SHA256 ハッシュ ネットワーク フィールド 内容 destination.ip 接続先 IP destination.port 接続先ポート source.ip 送信元 IP network.protocol プロトコル network.direction 通信の向き。 ホスト視点 なら ingress / egress 、 ネットワーク観測点視点 なら inbound / outbound / internal / external 💡 network.direction の値はデータソースによって違う： Elastic Defend や endpoint 系（Auditbeat、Sysmon 経由）は ingress / egress を使う傾向、Packetbeat や Zeek のような observer 系（ネットワーク監視目線）は inbound / outbound を使う傾向です。クエリを書く前に Discover で実際の値を確認しましょう。 イベント / 主体 フィールド 内容 event.category イベント大分類（process、file、network 等）。 EQL の必須フィールド event.type ECS 標準のサブタイプ（creation、start、end、connection 等） event.action データソース固有のアクション名（ソースによって値が異なる） event.outcome success / failure user.name ユーザー名 host.name ホスト名 @timestamp イベント時刻。 EQL の必須フィールド 💡 event.type と event.action の違い： event.type は ECS が定義する 標準化されたサブタイプ （creation、deletion、start、connection など決められた値）。event.action は データソース固有のアクション名 （Windows なら file-created、Sysmon なら FileCreated など値がバラバラ）。 ポータブルなクエリを書くなら event.type を使うのが基本 です。 タスク文を EQL に変換するフレームワーク 検知エンジニアリングで一番難しいのは、「日本語の脅威シナリオを、ECS フィールドと EQL に翻訳すること」です。これさえ身につければ、新しい脅威ハンティングのアイデアをすぐクエリにできるようになります。 5 ステップ翻訳法 どんな日本語のシナリオも、次の 5 つの問いに答えれば EQL になります。 Step 1. 何のイベント?     → event.category     (process / file / network …) Step 2. どんなアクション?  → event.type        (creation / start / connection …) Step 3. 何に対して?       → file.* / process.* (オブジェクト) Step 4. 誰が引き起こした?  → process.* / user.* (主体) Step 5. 順序や時間制約?    → sequence / maxspan (流れ) 実演：タスク文を 5 ステップで翻訳する タスク： 「 実行ファイル が Word ドキュメント を 作成し 、30 秒以内に大量のデータ送信が起きたケースを検出したい」 誰が？ → 実行ファイル 何を？ → Word ドキュメント どうした？ → 作成した EQL では、この「誰が・何を・どうした」を ECS フィールドに置き換えていきます。 誰が？ → process.executable 何を？ → file.extension どうした？ → event.type つまり、今回の前半部分はこういう考え方になります。 .exe の実行ファイルが .doc / .docx の Word ドキュメントを 作成した file where event.type == "creation" and process.executable : "*.exe" and file.extension : ("doc", "docx") ここで大事なのは、 file.*  と  process.*  の見方です。 file.*  は、 作られたもの の情報です。 今回であれば、作られたものは Word ドキュメントなので、 file.extension : ("doc", "docx")  になります。 一方で、 process.*  は、 そのイベントを起こしたプログラム の情報です。 今回であれば、Word ドキュメントを作ったのは実行ファイルなので、 process.executable : "*.exe"  になります。 つまり、ファイル作成イベントでは、次のように考えるとわかりやすいです。 process が file を event.type した 今回なら、こうです。 .exe が .doc/.docx を creation した 次に、後半の条件「30 秒以内に大量のデータ送信が起きた」を見ます。 これはネットワークイベントです。大量のデータ送信は、たとえば  source.bytes  で表現できます。 「作成」→ 「30 秒以内」→ 「大量送信」、流れの検出 → sequence + maxspan sequence with maxspan=30s   [file where event.type == "creation"     and process.executable : "*.exe"     and file.extension : ("doc", "docx")]   [network where source.bytes > 1000000] 完成です。日本語から EQL までの距離が、思ったより近いのが伝わったでしょうか。 キーワード → ECS フィールドの早見表 翻訳作業でつまずきやすい「日本語キーワード」と「対応する ECS フィールド」の対応表です。 日本語キーワード 条件フィルター よく組み合わせるフィールド 実行された / 起動された event.type == "start" process.name 、 process.executable 作成された / 保存された event.type == "creation" file.name 、 file.path 、 file.extension 削除された event.type == "deletion" file.* 変更された event.type == "change" file.* 、 registry.* 外部に通信 / 接続 event.type == "connection" destination.ip 、 destination.port ログインした event.category == "authentication" event.outcome 、 user.name 、 source.ip sequence と時間制約：流れの検出 EQL の真骨頂は sequence です。詳しく見ていきます。 構文 sequence [by FIELD] [with maxspan=TIME]   [event_category where condition_1]   [event_category where condition_2]   [event_category where condition_3] by FIELD：イベント間を「何でつなぐか」（join key）。host.name、process.entity_id、user.name など with maxspan=TIME：「全体が何秒以内に起きたら検出するか」（s / m / h / d） […]：各ステップのイベント条件 by の力：複数フィールドで相関 sequence by host.name, user.name with maxspan=5m   [authentication where event.outcome == "failure"]   [authentication where event.outcome == "success"] 「同じホスト、同じユーザーで、ログイン失敗の後に成功」を 5 分以内で検出。 ブルートフォースの成功 を捕まえる典型パターンです。 イベント間で値を引き継ぐ：per-event by ここが少しトリッキーで、よく間違えるところです。 やりたいこと： ファイルが作られて、その 同じファイル名 のプロセスが起動した sequence by host.name with maxspan=1m   [file where event.type == "creation" and file.extension : "exe"] by file.name   [process where event.type == "start"] by process.name sequence by host.name で ホスト全体の相関 、各 […] の後の by file.name / by process.name で 値を引き継ぎ ます。これにより「file.name == process.name」という相関が成立。 ⚠️ 重要： by のキー数は 全イベントで揃える必要があります 。[eventA] には by を付けて [eventB] に付けない、という書き方はできません。全イベントに付けるか、付けないかのどちらかです。 maxspan の選び方 シナリオ 推奨 maxspan プロセス起動 → 即時通信 30s 〜 1m マルウェア配置 → 実行 1m 〜 5m ログイン → 横展開 5m 〜 30m 内部偵察 → 権限昇格 1h 〜 4h 持続化 → 後日の C2 1d 以上（要注意：誤検知も増える） 短すぎると正規の動作も誤検知、長すぎると無関係なイベントが混ざる。 ここは仮説に基づいてチューニングする 領域です。 実例：セキュリティ検出パターン 5 選 そのままルールとして登録できる形にしてあります。 パターン 1：暗号化されていない通信の検出（コンプライアンス） network where event.type == "connection"   and (     (destination.port == 80 and network.protocol == "http") or     (destination.port == 21 and network.protocol == "ftp")   )   and network.direction in ("egress", "outbound") 社内から外向きの HTTP/FTP を可視化。PCI-DSS や社内ポリシー違反の検出に使えます。 パターン 2：PowerShell ダウンロードからの C2 接続 sequence by process.entity_id with maxspan=30s /* * Step 1: * PowerShell が起動されたイベントを探す。 * process.entity_id で後続の network イベントと同じプロセスに紐づける。 */ [process where event.type == "start" and process.name : "powershell.exe" /* * PowerShell のコマンドラインに、 * ダウンロードやコード実行でよく使われる文字列が含まれているかを見る。 * IEX / Invoke-Expression は、文字列として取得したコードを実行する時によく使われる。 * DownloadString / Net.WebClient は、外部からスクリプトやペイロードを取得する時によく使われる。 */ and ( process.command_line : "*IEX*" or process.command_line : "*DownloadString*" or process.command_line : "*Invoke-Expression*" or process.command_line : "*Net.WebClient*" ) ] /* * Step 2: * 同じプロセスが 30 秒以内に HTTPS 通信しているかを見る。 * destination.port == 443 は HTTPS 通信の代表的なポート。 */ [network where event.type == "connection" and destination.port == 443 /* * 接続先がプライベート IP ではないことを確認する。 * つまり、社内ネットワークではなく外部サーバーへ通信している可能性を見る。 */ and not cidrmatch( destination.ip, "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16" ) ] PowerShell が「ダウンロード系」のコマンドを実行して、直後にプライベート IP 以外 へ HTTPS 接続したケース。C2 ビーコンの典型形です。 ✅ ポイント： by process.entity_id で 同一プロセス内の流れ に限定しています。process.pid は再利用されるため誤検知の原因になりますが、process.entity_id は一意なので安全。 パターン 3：Office アプリからのプロセス起動（Living off the Land） process where event.type == "start"   and process.parent.name : ("winword.exe", "excel.exe", "powerpnt.exe", "outlook.exe")   and process.name : ("cmd.exe", "powershell.exe", "wscript.exe", "cscript.exe", "mshta.exe", "rundll32.exe") Office アプリがシェル系プロセスを起動するのは、ほぼマクロ起点の攻撃。 現代の標的型攻撃で最頻出のパターン で、誤検知も少なめ。検知ルールとしてまず入れたい一本です。 パターン 4：マルウェア配置 → 実行 → C2 通信 sequence by host.name with maxspan=2m /* * Step 1: * 同じホスト上で、Temp フォルダに実行可能ファイルが作成されたイベントを探す。 * Temp フォルダは、マルウェアやドロッパーが一時的にファイルを置く場所としてよく使われる。 */ [file where event.type == "creation" and file.path : "*\\Temp\\*" /* * exe / dll / scr は、攻撃で使われやすい実行可能ファイルの拡張子。 * exe は通常の実行ファイル、dll はライブラリ、scr はスクリーンセーバー形式だが実行可能。 */ and file.extension : ("exe", "dll", "scr") ] by file.name /* * Step 2: * 直後に、作成されたファイルと同じ名前のプロセスが起動されたかを見る。 * ここでは by file.name と by process.name を使い、 * 「作られたファイル名」と「起動したプロセス名」を結びつけている。 */ [process where event.type == "start"] by process.name /* * Step 3: * さらに、そのプロセスが外部通信でよく使われるポートへ接続したかを見る。 * 80 / 443 は HTTP / HTTPS、 * 8080 は代替 HTTP、 * 4444 は攻撃ツールやリバースシェルで使われることがある代表的なポート。 */ [network where event.type == "connection" and destination.port in (80, 443, 8080, 4444) ] by process.name Temp に実行ファイルが落ちて → そのファイルが起動して → 外部通信、までを 2 分以内に検出。 ドロッパー型マルウェアの典型挙動 です。 パターン 5：横展開の検出（ラテラルムーブメント） sequence by user.name with maxspan=30m /* * Step 1: * あるユーザーでログイン成功イベントが発生したかを見る。 * 横展開では、攻撃者が盗んだ認証情報を使って、 * まずどこかの端末やサーバーへログインすることがある。 */ [authentication where event.outcome == "success"] /* * Step 2: * 同じユーザーの操作として、横展開で使われやすいツールが起動されたかを見る。 * * psexec.exe: * Windows 環境でリモート端末上にコマンドを実行するためによく使われる。 * * wmic.exe: * WMI を使って、リモート端末の情報取得やコマンド実行に使われることがある。 * * winrm.exe: * Windows Remote Management を使ったリモート操作に関係する。 */ [process where event.type == "start" and process.name : ("psexec.exe", "wmic.exe", "winrm.exe")] /* * Step 3: * その後、同じユーザーで再びログイン成功イベントが発生したかを見る。 * これは、別の端末やサーバーへ移動した可能性を確認するためのステップ。 */ [authentication where event.outcome == "success"] 「同じユーザーで、ログイン成功 → 横展開系ツール実行 → ログイン成功」という流れを 30 分以内で検出。 侵入後の活動段階 を捕まえます。 ⚠️ EQL の限界： 「 別ホスト へのログイン」まで厳密に判定したい（1 回目と 2 回目の host.name が違う、という条件）場合、EQL の by 句では「値が等しい」しか表現できないため、これだけでは難しいです。実務では次のどちらかで対応します。 EQL でこのクエリを実行して候補を絞り、Detection Rule の Investigation Guide で host.name の違いを確認する ES|QL で後続分析する（同じユーザーが複数ホストにログインしているかを集計） よくあるミス と正しい書き方 実務でハマる典型パターンです。 ミス 1：ECS でないフィールド名を使う # ❌ process where proc_name == "powershell.exe" # ✅ process where process.name == "powershell.exe" 対策： Kibana の Data Views でフィールド名を確認するクセをつける。SPL からの移行者がいちばんやりがちなミス。 ミス 2：大文字小文字の罠 # ❌ 大文字の .EXE は引っかからない file where file.extension == "exe" # ✅ file where file.extension : "exe" ミス 3：event.action と event.type の混同 # ⚠️ 動くかもしれないが、データソース依存（値が "file-created" や "FileCreated" など揺れる） file where event.action == "creation" # ✅ ECS 標準化された値を使う file where event.type == "creation" ミス ４：sequence の順序逆転 sequence は 書いた順 = 起きた順 です。 # ❌ 通信が先、プロセス起動が後…と書いている sequence by process.entity_id   [network where destination.port == 443]   [process where process.name : "powershell.exe"] # ✅ 「PowerShell 起動 → 通信」のシナリオなら sequence by process.entity_id   [process where process.name : "powershell.exe"]   [network where destination.port == 443] シナリオを先に 日本語で書き下す と、順序ミスが減ります。 ミス ５：maxspan の単位忘れ # ❌ 単位なしはエラー with maxspan=30 # ✅ with maxspan=30s s（秒）/ m（分）/ h（時間）/ d（日）を必ずつける。 ミス ６：EQL 関数の大文字小文字を間違える EQL の 関数名は大文字小文字を区別 します。これでハマる人は多いです。 # ❌ Unknown function エラーになる not cidrmatch(destination.ip, "10.0.0.0/8") # ✅ camelCase が正解 not cidrMatch(destination.ip, "10.0.0.0/8") よく使う関数の正しいスペル: cidrMatch 、 startsWith 、 endsWith 、 stringContains 、 indexOf 、 concat 。関数を大文字小文字を無視させたいときは ~ を付けます（例: endsWith~(file.path, ".exe") ）。 ミス ７：関数の引数の大文字小文字でヒットしない 関数名そのものに加えて、 関数の引数（比較対象の文字列）もデフォルトで大文字小文字を区別 します。Windows のファイルパスのように大文字小文字が揺れるデータでは、これで取りこぼします。 # ❌ .EXE や .Exe は引っかからない（小文字 .exe のみマッチ） file where endsWith(file.path, ".exe") or endsWith(file.path, ".dll") # ✅ ~ を付けると大文字小文字を吸収 file where endsWith~(file.path, ".exe") or endsWith~(file.path, ".dll") ルール： 関数を大文字小文字を無視させたいときは、関数名の末尾に ~ を付けます。 endsWith~ 、 startsWith~ 、 stringContains~ 、 indexOf~ などすべての文字列関数で使えます。 💡 : と endsWith~ の使い分け： 単純な拡張子チェックなら file.extension : "exe" で十分。 endsWith~ はパス末尾や任意の文字列末尾を見たいとき（例: process.command_line の末尾）に便利です。 実際に動かす方法 方法 1：Kibana の Dev Tools で試す 最も手軽な方法。 POST logs-endpoint.*/_eql/search {   "query": """     sequence by process.entity_id with maxspan=30s       [process where process.name : "powershell.exe"]       [network where destination.port == 443]   """ } POST logs-endpoint.*/_eql/search 方法 2：Elastic Security の Timeline Elastic Security の「Timeline」では、UI から直接 EQL クエリを実行できます。脅威ハンティングのインタラクティブな探索に向いています。 方法 3：Detection Rule として登録 Elastic Security → Manage → Rules → Create new rule Rule type で「 Event Correlation 」を選択（これが EQL） クエリを貼り付け 重要度、MITRE ATT&CK タグ、Investigation Guide を設定 Save & enable 検証用のテストを必ず通してから本番有効化することをおすすめします。 まとめ EQL は「 順序ある脅威検出 」のために作られたクエリ言語 EQL を動かす前提は @timestamp と event.category の 2 フィールド Splunk SPL の transaction に近い考え方だが、構文が 攻撃チェーンのメンタルモデルに直結 している ECS は『同じ意味のデータには同じフィールド名を使う』というルール。だから 1 つのクエリで複数データソースに対応できる。ただし、すべてのデータソースが ECS の全フィールドを持っているわけではないので、Discover で実際の中身は必ず確認。 5 ステップ翻訳法（What → Action → Object → Actor → Sequence）で、日本語の脅威シナリオを EQL に変換できる sequence + maxspan + by が真骨頂。順序と時間ウィンドウを 1 つのクエリで表現 セキュリティ運用の効率は、「使えるクエリ言語」と「使える脅威モデル」の組み合わせで決まります。EQL は前者の強力な武器です。 Elastic 公式の Detection Rules リポジトリ をフォローして、新ルールをキャッチアップ 参考資料 EQL Syntax Reference (Elastic 公式) Event Query Language Overview Event correlation (EQL) r ules | Elastic Security Elastic Common Schema (ECS) Reference ECS Categorization Field: event.type ECS File Fields ECS Process Fields Elastic Security Detection Rules（GitHub） MITRE ATT&CK Framework ElasticsearchのためのLuceneクエリ入門ガイド The post セキュリティエンジニアのための EQL 入門：Elastic で脅威を見つけるクエリ言語 first appeared on Elastic Portal .