非推奨機能¶

これらの機能はHayabusaでサポートされていますが、今後ルール内で使用されることはありません。

イベントキー内のキーワードのネスト¶

イベントキーには特定のキーワードをネストすることができます。

detection:
    selection:
        Channel: System
        EventID: 7045
        ServiceName:
            - value: malicious-service
            - regexes: ./rules/config/regex/detectlist_suspicous_services.txt
        ImagePath:
            min_length: 1000
            allowlist: ./rules/config/regex/allowlist_legitimate_services.txt
    condition: selection

非推奨の特殊キーワード¶

value: 文字列によるマッチング (ワイルドカードやパイプも指定可能)。
min_length: 指定された文字数以上の場合にマッチします。
regexes: 指定されたファイルに定義された正規表現に1つ以上に一致する場合、条件にマッチしたものとして扱われます。
allowlist: 指定されたファイルに定義された正規表現に1つ以上に一致する場合、条件にマッチしてないものとして扱われます。

regexesとallowlistキーワード¶

Hayabusaに./rules/hayabusa/default/alerts/System/7045_CreateOrModiftySystemProcess-WindowsService_MaliciousServiceInstalled.ymlのルールのために使う2つの正規表現ファイルが用意されています。

./rules/config/regex/detectlist_suspicous_services.txt: 怪しいサービス名を検知するためのものです。
./rules/config/regex/allowlist_legitimate_services.txt: 正規のサービスを許可するためのものです。

regexes と allowlist で定義されたファイルの正規表現を変更すると、それらを参照するすべてのルールの動作を一度に変更できます。

また、regexes と allowlist にはユーザーが独自で作成したファイルを指定することも可能です。デフォルトの ./rules/config/detectlist_suspicous_services.txt と ./rules/config/allowlist_legitimate_services.txt を参考にして、独自のファイルを作成してください。

非推奨の集計条件（'count'ルール）¶

非推奨の特殊キーワードと count 集計は、Hayabusaではまだサポートされていますが、今後ルール内では使用されません。

基本事項¶

上記の condition キーワードは AND や OR だけでなく、マッチしたイベントの集計も可能です。この機能を利用するにはaggregation conditionを利用します。指定するには条件をパイプでつなぎます。以下のパスワードスプレー攻撃の例では、5分以内に同じ送信元のIpAddressで5個以上の TargetUserNameがあるかどうかを判断します。

detection:
  selection:
    Channel: Security
    EventID: 4648
  condition: selection | count(TargetUserName) by IpAddress > 5
  timeframe: 5m

aggregation conditionは以下の形式で定義します。

count() {operator} {number}: パイプの前の最初の条件にマッチするログイベントに対して、マッチしたログの数が {operator} と {number} で指定した条件式を満たす場合に条件がマッチします。

{operator} は以下のいずれかになります。

==: 指定された値と等しい場合、条件にマッチしたものとして扱われる。
>=: 指定された値以上であれば、条件にマッチしたものとして扱われる。
>: 指定された値以上であれば、条件にマッチしたものとして扱われる。
<=: 指定された値以下の場合、条件にマッチしたものとして扱われる。
<: 指定された値より小さい場合、条件にマッチしたものとして扱われる。

{number} は数値である必要があります。

timeframe は以下のように定義することができます。

15s: 15秒
30m: 30分
12h: 12時間
7d: 7日間
3M: 3ヶ月

countの4パターン¶

countの引数とby キーワード共に指定しないパターン。例: selection | count() > 10

selectionにマッチしたログが10件以上ある場合、このルールは検知します。
countの引数はないが、by キーワードはある。例: selection | count() by date > 10

selectionにマッチするログが10件以上あるかどうか、日付毎にチェックします。
countの引数があるが、by キーワードがない場合。例: selection | count(TargetUserName) > 10

selectionに一致するTargetUserNameが10人以上存在する場合、このルールは検知します。
count 引数と by キーワードの両方が存在する。例: selection | count(TargetUserName) by date > 10

selectionに一致するTargetUserNameが10人以上存在するかどうか、日付毎にチェックします。

パターン1の例¶

これは最も基本的なパターンです：count() {operator} {number}. 以下のルールは、selectionにマッチしたログが3つ以上である場合、このルールが検知されます。

パターン2の例¶

count() by {eventkey} {operator} {number}： selectionにマッチしたログは、{eventkey}の値が同じログ毎にグルーピングされます。各グループにおいて、マッチしたイベントの数が{operator}と{number}で指定した条件を満たした場合、このルールが検知されます。

パターン3の例¶

count({eventkey}) {operator} {number}：selectionにマッチしたログの内、 {eventkey} が異なる値の数をカウントします。そのカウントされた値が{operator}と{number}で指定された条件式を満たす場合、このルールが検知されます。

パターン4の例¶

count({eventkey_1}) by {eventkey_2} {operator} {number}： selectionにマッチしたログは、{eventkey}の値が同じログ毎にグルーピングし、各グループに含まれる{eventkey_1}が異なる値の数をカウントします。各グループでカウントされた値が{operator}と{number}で指定された条件式を満たした場合、このルールが検知されます。

Countルールの出力¶

CountルールのDetails出力は固定で、[condition]にcount条件と[result]に記録されたイベントキーが出力されます。

以下の例では、ブルートフォースされたTargetUserNameのユーザ名のリストと送信元のIpAddressが出力されます：

[condition] count(TargetUserName) by IpAddress >= 5 in timeframe [result] count:41 TargetUserName:jorchilles/jlake/cspizor/lpesce/bgalbraith/jkulikowski/baker/eskoudis/dpendolino/sarmstrong/lschifano/drook/rbowes/ebooth/melliott/econrad/sanson/dmashburn/bking/mdouglas/cragoso/psmith/bhostetler/zmathis/thessman/kperryman/cmoody/cdavis/cfleener/gsalinas/wstrzelec/jwright/edygert/ssims/jleytevidal/celgee/Administrator/mtoussain/smisenar/tbennett/bgreenwood IpAddress:10.10.2.22 timeframe:5m

アラートのタイムスタンプには、timeframe内で最初に検知されたイベントの時間が表示されます。