
鹅已出笼。
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 概况介绍
运行 Untitled Goose Tool 需要 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
请务必为服务主体启用“允许公共客户端流”。
我们提供了一个 setup powershell script 来创建具有所需权限的服务主体。此外,目前将 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 使用。除非此文件是通过上述参数生成的,否则你应该填写顶部的 [auth] 部分,以便 Untitled Goose Tool 能够正确地向相应资源进行身份验证。不过,如果你不希望将凭据输入到文件中,可以选择删除 .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
[azure]
# Dumps activity log from azure
activity_log=False
# Returns all azure subscriptions
all_azure_subscriptions=False
# Dump insights bastion audit logs
bastion_logs=False
# Dump Azure configuration information
configs=False
# Dump D4IOT portal configs
d4iot_portal_configs=False
# Dump D4IOT portal pcaps from alerts
d4iot_portal_pcap=False
# Dump insights audit events for key_vault
key_vault_log=False
# Dump insights network security group flow events
nsg_flow_logs=False