cisagov/untitledgoosetoolUntitled Goose Toolは、堅牢で柔軟なハントおよびインシデント対応ツールであり、顧客のAzure Active Directory (AzureAD)、Azure、およびM365環境に対して完全な調査を実行するために、新しい認証方法とデータ収集方法を追加します。
ガチョウは解き放たれた。
Untitled Goose Tool は、顧客の Microsoft Entra ID、Azure、M365 環境に対する完全な調査を実行するために、新しい認証方法とデータ収集方法を追加する、堅牢で柔軟なハンティングおよびインシデント対応ツールです。Untitled Goose Tool は、Microsoft Defender for Endpoint（MDE）および Defender for Internet of Things（IoT）（D4IoT）から追加のテレメトリを収集します。
このツールは、ログをセキュリティ情報およびイベント管理（SIEM）やその他の長期ログ保存ソリューションに取り込んでいない環境のために、インシデント後にクラウドアーティファクトをエクスポートすることで、インシデント対応チームを支援するように設計されています。
Untitled Goose Tool の使用方法の詳細については、Untitled Goose Tool Fact Sheet を参照してください。
Untitled Goose Tool を Python で実行するには、Python >= 3.9 が必要です。ログが改善されるため、Python 3.12 を強く推奨します。
Windows マシンでは、ツールを実行する前に Microsoft Visual C++ 再頒布可能パッケージ（14.x）がインストールされていることを確認する必要があります。
また、Untitled Goose Tool は仮想環境内で実行することを推奨します。
pip3 install virtualenv virtualenv -p python3 .venv source .venv/bin/activate
#### Linux```sh
# You may need to run sudo apt-get install python3-venv first
python3 -m venv .venv
source .venv/bin/activate
python -m venv .venv .venv\Scripts\activate
### 要件
Untitled Goose Tool を実行し、テナントへの読み取り専用アクセスを提供するには、以下の EntraID/M365 権限が必要です。
注意: ユーザー アカウントはクラウド専用アカウント（オンプレミス環境に同期されていないアカウント）である必要があります。これにより、ツールのログインプロセスが環境間で常に同じであることが保証されます。
以下の権限を持つクラウド専用ユーザー アカウントと関連付けられた EXO サービス プリンシパル:
Exchange Online Admin Center```
- View-Only Audit Logs
- View-Only Configuration
- View-Only Recipients
- User Options
以下のアクセス許可を持つサービス プリンシパル:
API のアクセス許可``` Log Analytics API
Microsoft Threat Protection:
WindowsDefenderATP:
Microsoft Graph:
Office 365 Exchange Online
Azure サブスクリプション IAM ロール```
- Reader
- Storage Blob Data Reader
- Storage Queue Data Reader
サービスプリンシパルでは、必ず「Allow public client flows」を有効にしてください。
必要なアクセス許可を持つサービスプリンシパルを設定するためのセットアップPowerShellスクリプトがあります。さらに、Azureサービスプリンシパルとm365の関連付けは、現時点ではPowerShellでのみ実行でき、一部のm365ログ収集に必要です。
以下はスクリプトの実行例です。このスクリプトは、適切な情報を含む設定ファイルを構築するために実行する必要がある goosey conf コマンドを出力します。```powershell
PS > Write-Host "Creating a new Goose Application and Users"
PS > ./Create_SP.ps1 -AppName GooseApp -Create
さらに、使い終わったらスクリプトでアプリケーションを削除することもできます。```powershell
PS > Write-Host "Creating a new Goose Application and Users"
PS > ./Create_SP.ps1 -AppName GooseApp -Delete
インストールするには、リポジトリをクローンしてから pip install を実行します:
git clone https://github.com/cisagov/untitledgoosetool.git cd untitledgoosetool python3 -m pip install .
#### Docker```sh
docker build . -t goosey
docker run -it -v $PWD:/workdir goosey goosey honk --debug
Untitled Goose Tool は認証パラメータと設定が必要です。設定ファイルを自動的に作成するには、インストール後に以下を実行してください。```sh $ goosey conf
このコマンドのバージョンは、PowerShell インストール スクリプトを実行してサービス プリンシパルを作成/セットアップするときに生成されます。以下は、ダミーのパラメータ値を使用した例です。```sh
$ goosey conf --config_tenant=5fd146ad-8b31-4afa-a72f-6f71df5c7173 --config_subscriptionid=all --auth_appid=24fd6377-79e0-445d-838b-3eaa60d3ca21
この後、.auth、.conf、.auth_d4iot、.d4iot_conf ファイルを現在のディレクトリに配置する必要があります。これらのファイルは Untitled Goose Tool によって使用されます。これが上記のパラメータで生成されていない場合は、Untitled Goose Tool が適切なリソースに正しく認証できるように、先頭のセクション [auth] を記入する必要があります。ただし、資格情報をファイルに入力することに抵抗がある場合は、.auth および/または .auth_d4iot を削除して、ツールがコンソール経由で資格情報の入力を求めるようにすることもできます。
最小限の auth の例は次のとおりです:``` [auth]
username=
password=
appid=
clientsecret=
最小限の設定は次のようになります:```
[config]
# The tenant ID of your AAD tenant
tenant=
# If you have a GCC High tenant
us_government=False
# If you have a GCC tenant with MDE
mde_gcc=False
# If you have a GCC High tenant with MDE
mde_gcc_high=False
# If your M365 tenant is a government tenant
exo_us_government=False
# If you want to check all of your Azure subscriptions, set this to All, otherwise enter your Azure subscription ID. For multiple IDs, separate it with commas, no spaces
subscriptionid=All
[filters]
# Format should be YYYY-MM-DD. If not set will default to the earliest date for log retention
date_start=
# Format should be YYYY-MM-DD. Will default to the present day
date_end=
[variables]
# Threshold used for ual API requests. Specifies the maximum results pulled per session. Can be between 100 - 50000. The api is optimized to return results faster the larger the threshold, but the whole session has to be repeated if an error occurs as the results are not returned sorted. We recommend 5000 as the threshold, but this can be toggled with
ual_threshold=5000
# Maximum number of ual coroutines/tasks to have running asynchronously. Minimum value is 1.
max_ual_tasks=5
# Start date for an extra time frame for ual to search. Reason for this is because ual takes the longest to pull and while you don't want the oldest data to roll off, you may want to look at another timeframe and do not want to wait for ual to get there and pull the logs. Format should be YYY-MM-DD
ual_extra_start=
# End date for an extra time frame for ual to search. Reason for this is because ual takes the longest to pull and while you don't want the oldest data to roll off, you may want to look at another timeframe and do not want to wait for ual to get there and pull the logs. Format should be YYY-MM-DD
ual_extra_end=
# Threshold for how many logs to pull per query. Usually want to try to max this out as KQL queries are rate limited.
mde_threshold=10000
# can be either 'table' or 'machine'. 'table' will pull directly from the mde tables without filtering. While 'machine' will filter by 'machine' with large tenants 'machine' will likely be prefered as time bounding on the entire table will likely cause issues.
mde_query_mode=table