" 野生の"クリプトマイニング攻撃を検出する

本文の内容は、2022年11月18日にNIGEL DOUGLASが投稿したブログ（https://sysdig.com/blog/detecting-cryptomining-attacks-in-the-wild/)を元に日本語に翻訳・再構成した内容となっております。

ブロックチェーンや暗号通貨の台頭に伴い、クリプトマイニング攻撃が目立ってきており、クリプトマイニングの検出は高い優先度を持つようになりました。

セキュリティリサーチャーは、被害者のインフラストラクチャー内で実行されているさまざまなクリプトマイニングバイナリに関連するデータ侵害を発見しています。Kubernetesクラスターはデフォルトでオープンであり、マイニングに必要な広範な計算能力を利用できるため、Kubernetesクラスターはクリプトマイニング攻撃の完璧なターゲットとなります。

そのため、Kubernetesのワークロードレベルの監視を行い、クラスター内で何が起きているのかをよりよく理解することが重要です。この記事では、Falcoなどのオープンソースツールを使用して、環境内のIoC（Indicators of Compromise）を検出する方法と、Prometheusなどのオープンソースメトリクス集約ツールを使用して、クラウドおよびKubernetes環境の健全性とアクティビティをより良く理解する方法について説明します。

クリプトマイナーとは何ですか？

暗号通貨は、ブロックチェーン上で多くの分散型トランザクションを促進するための取引手数料として獲得されます。これらのトランザクションを促進するためには、ユーザーはコンピュートリソースを利用する必要があります。

コンピュータリソースを使用して取引を検証するために暗号通貨を獲得するプロセスはクリプトマイニングと呼ばれ、”クリプトマイナー “と呼ばれるソフトウェアによって実施されます。代表的なものにxmrigがあり、現在はコンテナ化されており、DockerHubからアクセスし、コマンド1つで実行することができます。

Docker pull metal3d/xmrig

Docker Runコマンド：

docker run --name cryptominer --rm -it \
    -e POOL_URL=xmr.metal3d.org:8080 \
    -e POOL_USER="mine" \
    -e POOL_PASS="" \
    -e DONATE_LEVEL="0" \
    metal3d/xmrig

Teslaのクリプトマイニング攻撃の再確認

2018年にTeslaのKubernetesクラスターに対するクリプトマイニング攻撃が発生し、Redlockによって報告されました。

この攻撃は数年前に行われたものですが、この注目の事件から多くのことを学ぶことができます。今後も新たなクリプトマイニング事件が発生するでしょうが、この攻撃のパターンや挙動を解剖することで、今後このような事件を防御することができるのです。

欠陥

ハッカーが侵入したのは、パスワードで保護されていないKubernetesのダッシュボードでした。パスワードで保護されていたかどうかは、注目すべき点です。ローカルのKubernetesクラスターダッシュボードの認証を回避する方法については、多くのブログで文書化されており、Kubernetesダッシュボードを介した権限昇格に関するものもあります。多くの場合、組織はセキュリティの追加レイヤーとしてKubernetesダッシュボードを無効にしています。

今回のケースでは、攻撃者はダッシュボードにアクセスすることができました。いったん侵入すると、AWS S3 Bucketにアクセスするための機密情報など、いくつかの機密情報を流出させることができました。

クリプトマイニングの検出を回避するための回避技術

攻撃者の目標は、クラスター内の検出を回避することです。彼らは、肉眼で検出されないようにするために、次のような行動を取ることができます。

マイニングプロセスの一部として、CPUサイクルをあまり多く使用しないようにする。
- この場合、PodのCPU使用率が高すぎると、リソース使用状況グラフに表示されてしまうので、高すぎないようにします。
よく知られているマイニングプールには接続しないようにする。
- この場合、独自のマイニングサーバーを使用しました。これはCloudflare（CDNサービス）の背後に置かれていました。
プロセス間の通信を暗号化する。
- このケースでは、マイニングプロセスと自社のマイニングサーバー間の通信を暗号化しました。

ネットワークアクティビティを検出するためにFalcoを使用する

Teslaの攻撃に関連するパターンと行動は、一般的なマイナープールのDNSアドレスへの接続を監視するだけであれば、単純なファイアウォールソリューションを回避することができます。

Falcoは、– Detect outbound connections to common miner pool ports – というポリシールールでこの問題に対処しており、暗号化関連の活動を検出するために多層的なアプローチを取っています。これは、一般的に使用されているマイニングプールポートアドレスと、宛先のDNSおよびIPアドレスを検出することによって行います。この方法では、宛先アドレスに直接到達していない場合でも、通常のポートの活動を検出する必要があります。

- rule: Detect outbound connections to common miner pool ports
desc: >-
      Miners typically connect to miner pools on common ports(This rule does not
      work if the outbound connection is made through a proxy!).
  condition: net_miner_pool and not trusted_images_query_miner_domain_dns
      output: >-
      Outbound connection to IP/Port flagged as mining activity (dest=%fd.sip
      proc.cmdline=%proc.cmdline port=%fd.sport domain=%fd.sip.name
      container=%container.info evt.type=%evt.type evt.res=%evt.res
      proc.pid=%proc.pid proc.cwd=%proc.cwd proc.ppid=%proc.ppid
      proc.pcmdline=%proc.pcmdline proc.sid=%proc.sid proc.exepath=%proc.exepath
      user.uid=%user.uid user.loginuid=%user.loginuid
      user.loginname=%user.loginname user.name=%user.name group.gid=%group.gid
      group.name=%group.name container.id=%container.id
      container.name=%container.name image=%container.image.repository)
  priority: critical
  source: syscall
...

ほとんどの場合、一般的な攻撃者やインサイダー脅威は、このような人気のあるマイニングプールを使用します。Teslaスタイルの攻撃を扱っていると仮定して、上記のポリシーのnet_miner_poolセクションをチェックしてみてください。これは、元の条件セットの中に追加の条件セットを含んでいます。

macro: net_miner_pool
condition: (evt.type in (connect) and evt.dir=< and (fd.net != "127.0.0.0/8" and not fd.snet in (rfc_1918_addresses)) and minerpool_other)

minerpool_otherの条件を分解すると、先行するマイナーポートやマイナードメインへのネットワーク接続のための定義済みマクロを見ることができます。

list: miner_ports
items: [25, 80, 443, 3333, 3334, 3335, 3336, 3357, 4444, 5555, 5556, 5588, 5730, 6099, 6666, 7777, 7778, 8000, 8001, 8008, 8080, 8118, 8333, 8888, 8899, 9332, 9999, 14433, 14444, 45560, 45700]

また、当社の脅威リサーチチームが定期的に更新しているminers_ipアドレスも確認できます：

リストに定義されたマイナーのIPアドレスに対して、クリプトマイニングプロセスが実行され通信している場合、アラートが発動されます。

ファイルシステムの変更を監視するためにFalcoを利用する

上記のように、攻撃者は発見されないように最善を尽くします。私たちが悪意のあるC2サーバーやマイニングプールへの接続を検出できなかったと仮定すると – それはまだ私たちの脅威インテリジェンスチームによってフラグが立てられていないか、Cloudflareのようなある種のCDNプロキシの背後に隠れているため – 今度は攻撃者がKubernetesとクラウド環境内で何をしそうかに焦点を当てる必要があります。

CVE-2018-18264では、攻撃者が脆弱なKubernetesダッシュボードを介して特権の昇格を得ることができることを述べました。これは、Kubernetesワークロード内またはLinuxホスト上での目標になるでしょう。環境内で必要な変更を実行するためには、特権昇格が必要になります。攻撃パターンは以下のようなものです。

特権を持つPodの作成
悪意のあるファイルNnmesが書き込まれる
SetuidまたはSetgidビットの設定
tmpから実行
悪意のあるバイナリが実行される
アウトバウンド接続は通常、この段階で一般的なマイナープールポートで実行される

このブログでは、CNCFエコシステム内のいくつかのオープンソースツールを使用して、Kubernetesクラスターにおける実際のクリプトマイニング活動を検出するつもりです。クリプトマイニングのインサイダー脅威の多くに見られる既知のパターンに基づいて、クリプトマイニング活動を検出することができます。

高いCPU使用率
マイニングプールへの通信
マイナーの実行コマンドライン
これらのマイナーバイナリのシグネチャー

個々の対策にはそれぞれ限界があることに注意してください。それらを組み合わせることで、確実に検出効率を向上させることができます。しかし、Teslaを攻撃したような、より高度なクリプトマイニング技術や攻撃もまだ存在します。

あらゆる侵入に対応できるよう、セキュリティチームと連携してKubernetesクラスターやクラウドホストに包括的な検知戦略を適用することが必要です。

悪意のあるファイル名が書き込まれる

マルウェア活動の最も一般的なIoCは、Podまたはホスト上のいずれかに悪意のあるファイルが書き込まれることです。Falcoでは、それらの書き込み操作によってトリガーされるルールを作成することができます。

- rule: Malicious file names written
    desc: >-
        Malicious files written in pod /host. Triggers on write operations
     condition: |
        open_write and fd.filename in (malicious_filenames)
     output: >-
        Malicious files written in the pod or host. proc.cmdline=%proc.cmdline
        evt.type=%evt.type evt.res=%evt.res proc.name=%proc.name
        proc.pname=%proc.pname proc.pid=%proc.pid proc.cwd=%proc.cwd
        proc.ppid=%proc.ppid proc.pcmdline=%proc.pcmdline proc.sid=%proc.sid
        proc.exepath=%proc.exepath user.uid=%user.uid user.loginuid=%user.loginuid
        user.loginname=%user.loginname user.name=%user.name group.gid=%group.gid
        group.name=%group.name container.id=%container.id
        container.name=%container.name %evt.args
  priority: warning
  source: syscall
...

繰り返しますが、ホストやPod上の書き込み操作にフラグを立てているわけではありません。むしろ、書き込み操作に、通常クリプトマイナーやGraboidのようなクリプトワームのマルウェアに関連する疑わしいファイル名がある場合にのみ着目しています。

しかし、ファイルレスアプローチを使用したコンテナの侵害など、上記の「悪意のあるバイナリ検出」ルールを回避できる技術も存在します。そのため、クリプトマイニング攻撃を検知するためには、複数のIoC、脅威フィード、最小権限ポリシーを使用した多層的なアプローチを適用する必要があるのです。

setuidまたはsetgidビットの設定

Unixベースのシステムには、setuid（Set User Identity）とsetgid（Set Group Identity）という2つのアクセス権フラグが存在します。あるシナリオでは、この2つのフラグはクリプトマイニングのIoCと見なすことができます。SetUIDとSetGIDは、ユーザーが実行ファイルの所有者やグループのファイルシステム権限で実行ファイルを実行し、それらのファイルディレクトリの動作を変更することを可能にします。

setuid と setgid フラグは、システムファイルやデータベースの変更、ログインパスワードの変更など、通常ユーザに与えられている権限とは異なる権限を必要とするタスクに必要です。いかなる場合においても、このような「一時的に昇格された特権」が検出されないままであってはならないのです。Falcoを使えば、以下のようなルールを実行することができます。

- rule: Set Setuid or Setgid bit
  desc: >
    When the setuid or setgid bits are set for an application, this means that
    the application will run with the privileges of the owning user or group
    respectively. Detect setuid or setgid bits set via chmod
  condition: >
    consider_all_chmods and chmod and (evt.arg.mode contains "S_ISUID" or
    evt.arg.mode contains "S_ISGID") and not exe_running_docker_save and not
    user_known_set_setuid_or_setgid_bit_conditions and proc_name_exists
  output: >
    Setuid or setgid bit is set via chmod (fd=%evt.arg.fd
    filename=%evt.arg.filename mode=%evt.arg.mode user.name=%user.name
    user.loginuid=%user.loginuid process=%proc.name proc.pname=%proc.pname
    proc.cmdline=%proc.cmdline container.id=%container.id
    container_name=%container.name evt.type=%evt.type evt.res=%evt.res
    proc.pid=%proc.pid proc.cwd=%proc.cwd proc.ppid=%proc.ppid
    proc.pcmdline=%proc.pcmdline proc.sid=%proc.sid proc.exepath=%proc.exepath
    user.uid=%user.uid user.loginname=%user.loginname group.gid=%group.gid
    group.name=%group.name container.name=%container.name
    image=%container.image.repository:%container.image.tag)
  priority: notice
  source: syscall
...

先ほど取り上げたように、ファイルに setuid ビットや setgid ビットが設定されると、そのファイルは所有者の権限で実行されるようになります。これを何としても防御する必要があるのです。setuidビットやsetgidビットが設定されているファイルを追跡下におくことは良い習慣です。

例として、このコマンドでパーミッションを手動でチェックすることができます：

find . -perm /6000

しかし、実行中にファイルのパーミッションが変更された場合はどうでしょうか？このような変更をどのように追跡しているのでしょうか。
Sysdig Secureは、このプロセスを効率化するために、オープンソースのFalcoルールセットで実装された管理する仕組みを提供しています。Sysdig Secureで上記のルールが発生した場合、UIはすべての環境にわたるすべてのインスタンスを集約します。

tmpからの実行

クリプトマイニングを検出する各ツールのデモを行うため、被害者であるnginx Podをシミュレートしてみます。

kubectl create ns nginx-test
kubectl create deployment --namespace=nginx-test nginx --image=nginx
kubectl expose --namespace=nginx-test deployment nginx --port=80

攻撃者は、おそらく/tmpディレクトリにマイナーのバイナリを配置することになるでしょう。
今回は、公式ドキュメントを元にxmrigバイナリを作成します：

kubectl run --namespace=knp-test access --rm -ti --image busybox /bin/sh
cd /tmp
sudo apt-get install git build-essential cmake libuv1-dev libssl-dev libhwloc-dev
git clone https://github.com/xmrig/xmrig.git
mkdir xmrig/build && cd xmrig/build
cmake ..
make -j$(nproc)

xmrigのビルドがマイニングバイナリになる予定です。このバイナリはデプロイイメージ(この場合はNginx)にシードされるか、コマンド＆コントロールサーバーからダウンロードされるかを意識する必要があります。

上記のスクリーンショットから、使用されたプールアドレス、使用されたイメージ、および実行されたxmrig固有のコマンド（これは検出も試みる必要があります）を確認できます。

xmrig -c /root/.xmrig.json

一時ディレクトリでファイルが実行されるのを防ぐために、パラメータ ‘read-only’ を指定してコンテナを実行し、元のデプロイ設計からの不要な変更を防ぐドリフトの防御、および /tmp ディレクトリの変更しようとした場合のアラートを実行することができます：

<code>- rule: Execution from /tmp<br> desc: >-<br> This rule detects file execution from the /tmp directory, a common tactic<br> for threat actors to stash their readable+writable+executable files.<br> condition: >-<br> spawned_process and ((proc.exe startswith "/tmp/" or (proc.cwd startswith<br> "/tmp/" and proc.exe startswith "./" )) or (proc.cwd startswith "/tmp/" and<br> proc.args startswith "./")) and not pip_venv_tmp<br> output: >-<br> File execution detected from /tmp (proc.cmdline=%proc.cmdline<br> connection=%fd.name user.name=%user.name user.loginuid=%user.loginuid<br> container.id=%container.id evt.type=%evt.type evt.res=%evt.res<br> proc.pid=%proc.pid proc.cwd=%proc.cwd proc.ppid=%proc.ppid<br> proc.pcmdline=%proc.pcmdline proc.sid=%proc.sid proc.exepath=%proc.exepath<br> user.uid=%user.uid user.loginname=%user.loginname group.gid=%group.gid<br> group.name=%group.name container.name=%container.name<br> image=%container.image.repository)<br> priority: warning<br> source: syscall<br>...<br></code>

攻撃者はおそらく、/tmpディレクトリにマイナーのバイナリを配置するでしょう。
このケースにおいて、公式ドキュメントに基づき、xmrigバイナリを作成します：

Exceptions:
- name: proc_cmdlines
   Comps:
   - startswith
   Fields:
   - proc.cmdline
   Values:
   - - chromedriver --version
   - - conftest
   - - sh -c LIVENESS_THRESHOLD_SECONDS
   - - bash -c fail=
   - - sh /tmp/apt-key-gpghome
   - - sh -c set -e; TMP=/var/lib/dkms/draios-agent
   - - cat /home/ubuntu/.cache/bazel
   - - touch
   - - 'python -u -c import io,os'
   - - 'python -u -c import io, os'
   - - 'python -c import io,os'
   - - 'python -c import io, os'
   - - python /tmp/tmp
   - - sh ../libtool --silent
   - - sh ../../../libtool --silent
   - - autogen.sh
   - - pip /tmp/venv
   - - docker-bench-security
   - - kubectl apply -f
   - - actions-sync sync
   - - bash ./configure
   - - rustup-init
   - - jq -er
   - - jattach

上記のFalcoのルールは、上記の例外を除き、/tmpディレクトリからのすべてのファイルの実行を検出します。

tmp ディレクトリ内での実行は、読み書き可能なファイルや実行可能なファイルを安全に隠しておきたい脅威行為者の一般的な戦術です。しかし、もし彼らが Falco ルールセットにおける例外を認識していたならば、検知を回避することができます。ブラックベリーは、Falco のルールが時折回避されるシナリオを本当に文書化しており、これらの顕著な例の 1 つが Falco のルールにおける例外を介したものです。Falco のルール内にあまり多くの例外を追加しないようにすることが重要です。

敵対者がファイルを/tmpディレクトリに隠すかどうかが不明で、特にデプロイの一部ではないディレクトリにファイルを書き込まれたくない場合は、Sysdig SecureのDrift Preventionポリシーによってこれを強制することが可能です。

Sysdig Drift Controlを使用すると、コンテナドリフトとして知られる、新しい実行ファイルを実行するために本番環境で変更されたコンテナを簡単に検出、防御し、インシデント対応を迅速化することができます。ドリフトをブロックすることで、攻撃を防ぐことができます。

上記のドリフト防御ポリシーは、コンテナに追加された実行可能なパーミッションを持つ各新規バイナリを評価します。プロファイリングされたイメージからの変更は、意図した設計からの ”ドリフト” とみなされます。コンテナ内のメインプロセスにはSIGKILLシグナルが送信され、攻撃者を早期に防御することができます。

Sysdig Secureのドリフト防御機能を試してみたい場合は、Webユーザーインターフェースからポリシーを有効化するだけです（上図参照）。有効化したら、標準的なNginxのデプロイを作成します。

kubectl create ns nginx-test
kubectl create deployment --namespace=nginx-test nginx --image=nginx

マニフェストファイルを適用し、デフォルトのネットワークネームスペースでPodが稼働していることを確認します。
実行されると、新しく作成されたPodにexecすることができます。

cURLがまだインストールされていない場合は、パッケージマネージャーからインストールするのも1つの方法です(例: apt install curl)。しかし、コンテナを非rootで実行するような実際のシナリオでは、これは複雑です。もう1つの選択肢は、インストールされている可能性が高いwgetを使うことでしょう。

cURL/wgetがインストールされたら、それを使ってxmrigバイナリをダウンロードし、ローカルにインストールすることができます。

どのディレクトリにxmrigをインストールしようとしても、このアクションは失敗します。

ドリフト防御は、意図したアプリケーションの設計が実行時に変わらないようにし、悪意を持ってワークロードが乗っ取られるのを防ぐものです。

シェルから、アクションが ‘KILLED’ であったことがわかります。さらに、Sysdig Secure ユーザーインターフェイスは、「何」が「誰によって」試みられた変更であったかを理解するのに役立つ、さらなるフォレンジックを提供します。

悪意のあるバイナリが実行される

ネットワーク接続を検出できなかったと仮定します。ネットワーク検出ルールに含まれないサーバーとポートを指しているとします。また、高いパーミッションを必要とせず、/tmp ディレクトリで検出されるような異常な書き込みもないと仮定します。また、これが新しいデプロイメントであるため、ドリフト防御では検出できないと仮定します。

最低限、xmrigのようなツールに関連する悪意のあるバイナリを検出できるようにする必要があります。

前述のとおり、これは新しい攻撃なので、検出されない新しいバイナリが野放しになっていると思われます。いずれにせよ、セキュリティに対する多層的なアプローチの一部として、別のルールを構成する必要があります。

<br><code>- rule: Malicious binary detected<br> desc: >-<br> Malicious script or binary detected in pod or host. The rule was triggered<br> by the execve syscall<br> condition: ><br> spawned_process and (in_malicious_binaries or (proc.name in (shell_binaries)<br> and scripts_in_or and not proc.args startswith "-c"))<br> output: >-<br> Malicious binary or script executed in the pod or host.<br> proc.cmdline=%proc.cmdline evt.type=%evt.type evt.res=%evt.res<br> proc.pid=%proc.pid proc.cwd=%proc.cwd proc.ppid=%proc.ppid<br> proc.pcmdline=%proc.pcmdline proc.sid=%proc.sid proc.exepath=%proc.exepath<br> user.uid=%user.uid user.loginuid=%user.loginuid<br> user.loginname=%user.loginname user.name=%user.name group.gid=%group.gid<br> group.name=%group.name container.id=%container.id<br> container.name=%container.name %evt.args<br> priority: warning<br> Tags:<br> - ioc<br> source: syscall<br> append: false<br> exceptions: []</code>

この場合、再びホストからのsyscallに依存することになります。’execve’ システムコールが、悪意のあるバイナリ（既知の不正なMD5ハッシュ）にリストされたプロセスをスポーンするか、プロセス名がシェルバイナリにリストされていた場合、検出を得ることができるはずです。

繰り返しますが、この動作を早期に停止させるために、可能な限りの検出ベクトルを使用する必要があります。この場合、’xmrig’ バイナリはデフォルトで Falco の ‘malicious_binaries’ マクロに追加されます：

-
list: malicious_binaries
Sysdig 0.91.2
items: ["kinsing", "xmrig", "ldapdomaindump", "ldd2bloodhound", "0as1d5asf4as5dm4", "0as1d5asf4as5dm6", "0as1d5asf4as5dm7", "0as1d5asf4as5dx64", "0as1d5asf4as5d86", "0as1d5asf4as5d8k", "0as1d5asf4as5dsl", "0as1d5asf4as5dpc", "0as1d5asf4as5dm5", "0as1d5asf4as5dps", "0as1d5asf4as5dh4", "opa915"]

他のルールがすべて失敗した場合、Sysdig Secureに新たに搭載された高精度な機械学習（ML）ポリシーによるクリプトジャッキングの検知に頼ることができるようになりました。SysdigにMLを活用したポリシーを導入することで、プロセスの活動分析を通じてマイナーの活動を検知できるようになりました。脅威が既知であれ未知であれ、マイニング攻撃のパターンや挙動はある程度一貫しています。このデータをMLアルゴリズムに入力すると、プロセスが実際にクリプトマイニングに関連しているかどうかの信頼度評価が得られます。

今回のケースでは、xmrigプロセスがクリプトマイニングに関連しているとの確信度が96%という結果になりました。

MLベースのポリシーの良さは、エンドユーザが何も設定する必要がないことです。
単にこのcryptomining検出機能を有効にするかどうかを選択するだけです：

MLポリシーは、Sysdig Secure内の既存のイメージプロファイリング機能に依存しています。
フィンガープリントの収集と集約はエージェントから始まり、エージェントはお客様のワークロードの挙動を観察し、定期的にSysdig Secureに送信してプロファイルに集約させます。

この機能を有効にすると、エージェントはコンテナ上で発生したこと（ネットワークアクティビティ、アクセスしたファイルやディレクトリ、実行したプロセス、使用したシステムコール）の ”フィンガープリント” の送信を開始し、Sysdig Secureはイメージごとにこの情報を集約します。したがって、同じイメージをベースにした複数のコンテナが異なるノードで実行されている場合、システムアクティビティが収集され、イメージプロファイルに統合されます。

まとめ

2022版クラウドネイティブな脅威に関するレポートによると、攻撃者が8,100ドルの暗号通貨収入を得るには、43万ドルのクラウド費用とリソースが必要です。

低リスクで高報酬のクリプトジャッキングは、サイバー攻撃者の主要な動機であり続ける一方、サプライチェーン攻撃や地政学的ハクティビズムにおける活動の増加も広まっています。

セキュリティの観点からは、MLはセキュリティチームのツールセットとして素晴らしい追加機能です。しかし、このブログの記事にあるように、MLのポリシーと従来のルールベースのポリシーの比較の問題ではありません。むしろ、クリプトマイニング攻撃に関連するパターンや行動を検出するために作成された多種多様なルールベースのポリシーを補完するために、どのようにMLポリシーを使用できるかが問題なのです。

先のYAMLマニフェストで示したように、オープンソースのFalcoでルールを作成し、クリプトジャッキングに関連する一般的なIoCを検出することが可能です。Kubernetesとクラウドの脅威の状況が複雑化しているため、セキュリティのインシデントとレスポンスチームに負担がかかる可能性があります。だからこそ、Sysdig SecureのCloud Detection & Response（CDR）プラットフォームは、綿密なフォレンジックを備えたマネージドFalcoポリシールールセットを提供し、セキュリティチームの平均応答時間（MTTTR）を改善するのに役立ちます。

” 野生の”クリプトマイニング攻撃を検出する