更新 (15/01/23)：1 月 13 日，C事件响应cleCI 发布了他们的事件报告并提供了有关攻击的更多详细信息，包括 IOC。我们添加了一个附录 ，其中包含基于新详细信息的搜索查询，并更新了现有查询的日期范围以扫描从已知的初始妥协日期 12 月 16 日开始的事件

在 2023 年 1 月 4 日星期三的一份声明8中，CircleCI 报告称其开发平台的安全漏洞导致数千个组织的敏感数据和密钥暴露。CircleCI 强烈敦促其用户立即采取行动，通过更换他们存储在平台上的任何密钥来保护他们的信息，例如 API 令牌或环境变量中的凭证。还鼓励 CircleCI 用户在 2022 年 12 月 21 日至 2023 年 1 月 4 日期间查看其内部日志以寻找未经授权访问的证据。

然而，对组织的风险超越了泄露的密钥。在 12 月下旬和 1 月初之间的那个时间窗口内，黑客可以通过云 API 在环境中建立立足点，使他们能够获得持久性，从而经受住密钥更换。

在这篇博客中，我们将在每个主要的 云提供商（AWS、Azure、谷歌云）中展示一些具有高特权的云 API，黑客可能会滥用这些 API，以便使用盗用的密钥访问环境后获得云环境中的持久性。此外，我们将提供搜寻查询，帮助安全和 事件响应团队使用云提供商原生交互式查询服务（AWS Athena、Azure Log Analytics、谷歌云 Logs Explorer）调查是否发生了任何与持久性相关的可疑活动。无论密钥更换如何，团队都应该寻找持久性的迹象。

从泄露的密钥到持续的攻击

即使在云中已更换或删除密钥，如果黑客已获得对环境的初始访问权限并建立立足点以维持访问权限，持久性仍可能对组织构成威胁。例如，恶意行为者可能会使用盗取的凭据或密钥来启动新实例，将它们配置为与 C2 服务器通信，并访问云存储中的数据。黑客还可能利用无服务功能等云原生功能和服务在云环境中建立持久性。

为了持续评估其云环境的安全性，组织应该有一个超越密钥更换/删除的综合战略，包括网络划分和监控。这是至关重要的，因为已经有大量记录在案的 APT 组织在云环境中使用持久性技术的案例。例如，据报道，APT29（又名“Cozy Bear”）已经破坏了 VM 等云基础设施以建立持久性、托管 C2 服务器，并通过为服务主体生成新的凭据来为其创建后门。此外，APT10（又名“Stone Panda”）据称还获得了在云环境中的持久性并随后执行数据泄露。

在 AWS 中寻找持久性迹象

获得了用户AWS密钥和凭据的黑客可能会执行以下任何 API 调用。即使在您的密钥被撤销/更换后，这些调用也可能允许它们在您的云环境中建立持久性，这就是为什么监视活动以判断它们是否隐藏在您的云帐户中至关重要：

• CreateUser ：黑客可能会在帐户中创建新的 AWS 用户并使用它们在环境中获得持久性。

• CreateAccessKey：黑客可能会为现有用户生成新的访问密钥，并使用它们来冒充用户的身份。

• CreateLoginProfile：黑客可以为没有此类配置文件的现有用户创建新的登录配置文件（控制台登录）（例如，仅拥有访问密钥）

• UpdateLoginProfile：黑客可以更新与用户关联的现有登录配置文件并修改其控制台登录密码。

• ImportKeyPair ：黑客可以从他们创建的密钥对中导入公钥，并将其与新的 EC2 实例相关联，从而允许他们通过云工作负载持续存在。

• RunInstances：黑客可能会生成新的 EC2 实例并在其上运行恶意代码（例如反向 shell），使它们能够通过云工作负载持续存在。

• ModifyInstanceAttribute：黑客可以通过将在每次启动期间运行的“UserData”属性将恶意启动脚本注入现有 EC2 实例，从而允许它们通过云工作负载持续存在。

• CreateFunction：黑客可能会创建新的 Lambda 函数，将恶意代码注入其中并调用它们，从而通过无服务函数持久存在。

• UpdateFunctionCode：黑客可能会更新现有 Lambda 函数的代码以包含恶意负载，从而使它们能够通过无服务函数持续存在。

• SendCommandAPI：黑客可以滥用此 API 在 EC2 实例上运行恶意命令并在其上安装后门，从而允许它们通过云工作负载持续存在。

• StartSession：黑客可能通过 IAM 权限连接到 EC2 实例并在其上安装后门，从而允许他们在云工作负载中持续存在。

为了确定是否存在任何持久性迹象，请使用任何可疑的访问密钥 ID 在 AWS Athena 中运行以下 SQL 查询：

查询 #1——AWS 负责人的可疑持久性活动

SELECT * 
FROM "cloudtrail_logs_aws_cloudtrail_logs_********"  
WHERE 
    eventtime >= '2022-12-16T00:00:00Z' AND eventtime < '2023-01-05T00:00:00Z' 
    useridentity.accessKeyId in (<list-of-access-key-ids>) 
    AND eventname in ('CreateUser','CreateAccessKey','CreateLoginProfile','UpdateLoginProfile','ImportKeyPa事件响应','ModifyInstanceAttribute','CreateFunction20150331','UpdateFunctionCode20150331v2','RunInstances','StartSession','SendCommand') 
    AND errorcode is null

整治

如果查询已生成结果，请务必调查每个结果。如果您不熟悉某个发现或认为它可疑，请按照以下补救步骤操作：

• 删除——而不是禁用——任何看起来可疑的新用户或访问密钥。

• 禁用或更改任何更新的登录配置文件的密码；对现有登录配置文件实施严格的身份验证方法，例如 MFA。

• 删除与可疑用户关联的任何 EC2 实例或新密钥。

• 删除可疑用户创建的任何新 EC2 实例。

• 还原可疑用户对现有 EC2 实例属性（例如UserData）的任何修改，并在其上搜索任何潜在的后门。如果可能，请备份所有重要数据并删除实例。

• 恢复可疑用户对现有无服务功能的任何修改源代码，并删除任何新功能。

• 当可疑用户启动SendCommand或StartSession时，搜索驻留在 EC2 实例上的任何潜在后门。如果可能，请备份重要数据并终止实例。

此外，黑客可能会尝试通过枚举您帐户中的角色并不断爆破这些角色来获得持久性。您可以使用您的预选阈值在 AWS Athena 中执行以下 SQL 查询，以搜索多次失败的尝试：

查询#2——滥用不成功的AssumeRole操作

SELECT useridentity.principalId, useridentity.accessKeyId, useridentity.userName, COUNT(distinct resources) as numRoles 
FROM "cloudtrail_logs_aws_cloudtrail_logs_********"  
WHERE 
    eventtime >= '2022-12-16T00:00:00Z' AND eventtime < '2023-01-05T00:00:00Z' 
    AND useridentity.accessKeyId = '<suspected-access-key-id>' 
    AND eventname = 'AssumeRole' 
    AND errorcode is not null 
    GROUP BY useridentity.principalId, useridentity.accessKeyId, useridentity.userName 
    HAVING COUNT(distinct resources) > 5 

如果查询返回结果，这可能表明所选主体的行为可疑。然后，您需要使用可疑的访问密钥 ID 运行查询，以确定主体是否已成功承担任何角色：

查询 #3——AssumeRole高度可疑的委托人成功操作

SELECT distinct resources 
FROM "cloudtrail_logs_aws_cloudtrail_logs_********"  
WHERE 
    eventtime >= '2022-12-16T00:00:00Z' AND eventtime < '2023-01-05T00:00:00Z' 
    AND useridentity.accessKeyId = '<suspected-access-key-id>' 
    AND eventname = 'AssumeRole' 
    AND errorcode is null

整治

如果您注意到任何不熟悉的日志，请撤销该角色的任何会话权限。

在 Azure 中寻找持久性迹象

获得AAD 服务主体密钥的黑客可能会执行以下任何命令以在您的云环境中持久存在，即使在应用程序的凭据已被撤销或更换之后也是如此。确保监控您的审计和活动日志以查找云租户内的隐藏黑客：

• 更新应用程序的证书和密钥管理（审计日志）：黑客可能会通过为租户中盗取的 AAD 应用程序生成新的密钥或证书来坚持下去。

• 添加用户（审计日志）：黑客可能会通过在租户中创建新的 AAD 用户来在环境中持续存在。

• 重置用户密码（审核日志）：黑客可以为租户中的现有 AAD 用户重置密码，并通过模拟他们来建立持久性。

• 创建或更新 Azure Automation Runbook（活动日志）：黑客可能会更新或创建 Automation Runbook 并启动恶意脚本（例如 PowerShell）以生成作为云环境后门的高特权 AAD 身份。

• 为 Azure 自动化 webhook（活动日志）生成 URI：黑客可以通过 webhook 调用自动化 runbook 并持续访问环境，即使 runbook 的高特权 AAD 身份已被删除。

• 创建或更新虚拟机（活动日志）：黑客可能会通过创建或更新 VM 并通过每次启动时运行的“UserData”属性向其中注入恶意启动脚本来持续执行云工作负载。

• 在虚拟机上运行命令（活动日志）：黑客可以通过滥用此 API 在 VM 上运行恶意命令并在其上安装后门来持续工作负载。

• 更新功能代码（活动日志）：黑客可能会更新现有无服务功能的代码以插入恶意负载并通过功能持续存在。

为了确定是否存在任何持久性迹象，请在 Azure Log Analytics 中运行此 KQL 查询并包含任何可疑的服务主体对象 ID：

查询 #4 — AAD 服务主体在 ARM 中的可疑持久性活动

AzureActivity 
| where TimeGenerated >= startofday(datetime(2022-12-16)) and TimeGenerated < startofday(datetime('2023-01-05')) 
| where Caller in ('<list-of-AAD-SP-Obj-IDs>') 
| where OperationNameValue in ("MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/PUBLISH/ACTION","MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/WEBHOOKS/WRITE","MICROSOFT.COMPUTE/V事件响应TUALMACHINES/WRITE","MICROSOFT.COMPUTE/V事件响应TUALMACHINES/RUNCOMMAND/ACTION") 
  or OperationNameValue matches regex @'MICROSOFT.WEB/SITES/HOSTRUNTIME/VFS/.*/WRITE' 
| where ActivityStatusValue == "Success"

整治

如果查询产生了结果，请确保检查每个结果。如果您不熟悉某个发现或认为它可疑，请按照以下补救步骤操作：

• 删除在现有或新的自动化帐户中创建的任何可疑自动化 runbook。

• 删除在现有或新的自动化 runbook 中创建的任何可疑 webhook。

• 恢复由可疑服务主体修改的现有无服务功能的任何源代码，并删除任何新功能。

• 删除由可疑服务主体创建的任何 VM。

• 删除服务主体注入 VM 的任何可疑启动脚本，并在 VM 上搜索任何潜在的后门。如果可能，请备份重要数据并删除机器。

要评估 AAD 中的潜在持久性，请使用审核日志在 Azure Log Analytics 中运行此 KQL 查询，并包括任何可疑的服务主体客户端 ID：

查询 #5 — AAD 服务主体在 AAD 中的可疑持久性活动

AuditLogs 
| where TimeGenerated >= startofday(datetime(2022-12-16)) and TimeGenerated < 
startofday(datetime(2023-01-05)) 
| where InitiatedBy.app.appId in ('<list-of-AAD-SP-IDs>') 
| where ActivityDisplayName in ("Update application – Certificates and secrets 
management","Add user","Reset user password") 
| where Result == "success"

整治

如果查询已生成结果，请调查它们。如果您不熟悉这些发现或认为它们可疑，请按照以下补救步骤操作：

• 删除为现有或新 AAD 服务主体创建的任何可疑密钥或证书。此外，删除与现有或新AAD服务主体关联的任何新的不熟悉的 AAD 应用程序

• 删除由服务主体创建的任何未知的新用户。

• 如果某个特定用户的密码已被重置，请更改它并强制执行 MFA 等严格的身份验证方法。

在 谷歌云 中寻找持久性迹象

获得IAM服务帐户相关的密钥的黑客可以执行以下任何命令以在您的云环境中持久存在，即使在服务帐户的私钥已被撤销或更换之后也是如此。监控隐藏在您的云租户中的潜在黑客的服务帐户活动：

• CreateServiceAccountKey：黑客可能会为环境中的现有服务帐户创建新的私钥，并通过冒充它们来持续存在。

• CreateFunction:黑客可以创建无服务功能，将恶意代码注入其中，然后调用它们以通过无服务功能持久存在。

• UpdateFunction：黑客可能会更新现有无服务函数的代码以插入恶意负载并通过该函数持续存在。

• SSH 到 VM（包括通过 IAP到内部 VM）：黑客可能通过compute ssh API “SSH”到项目中的现有 VM ，并持续执行工作负载。

• 在 VM 上运行启动脚本：黑客可能会将恶意启动脚本注入到现有 VM 中，确保每次启动时运行，从而允许它们通过工作负载持续存在。

• 创建新的计算实例：黑客可以通过创建新的计算实例并在其上运行恶意代码来获得工作负载的持久性。

要在 谷歌云 中筛选持久性，请使用任何可疑服务帐户详细信息在日志资源管理器中执行此日志记录查询：

查询 #6——谷歌云 服务账户的可疑持久性活动

timestamp >= "2022-12-16T00:00:00Z" AND timestamp < "2023-01-05T00:00:00Z" AND 
((resource.type="gce_instance" AND ((jsonPayload.message: "Updating keys for user 
<Service-Account-Name>.") OR 
(protoPayload.authorizationInfo.permission="compute.instances.setMetadata" AND
protoPayload.metadata.instanceMetadataDelta.addedMetadataKeys="startup-script" AND
protoPayload.authenticationInfo.principalEmail = "<Service-Account-Email>"))) OR  
(resource.type="cloud_function" AND protoPayload.authenticationInfo.principalEmail = 
"<Service-Account-Email>" AND 
(protoPayload.methodName="google.cloud.functions.v1.CloudFunctionsService.UpdateFunction" OR 
protoPayload.methodName="google.cloud.functions.v1.CloudFunctionsService.CreateFunction")) OR 
(resource.type="service_account" AND 
protoPayload.methodName="google.iam.admin.v1.CreateServiceAccountKey" AND 
protoPayload.authenticationInfo.principalEmail = "<Service-Account-Email>")) AND 
severity!=ERROR

整治

如果查询产生了结果，请检查它们。如果您不熟悉它们或认为它们可疑，请执行以下补救步骤：

• 删除为现有或新服务帐户创建的所有可疑私钥。

• 恢复可疑服务帐户的现有无服务功能任何修改过的源代码并删除任何新功能。

• 删除由可疑服务帐户创建的任何 VM。

• 使用启动了可疑 SSH 连接的服务帐户登录到 VM，删除其主目录，并在其上搜索任何潜在的后门。如果可能，请备份重要数据并删除机器。

• 删除服务帐户注入到 VM 中的任何可疑启动脚本，并在 VM 上搜索任何潜在的后门。如果可能，请备份重要数据并删除机器。

附录——CircleCI 事件中涉及的恶意 IP 的云活动查询

1 月 13 日，CircleCI 发布了与针对其环境的黑客相关的妥协指标 (IOC)。以下查询可以帮助团队确定他们的云环境是否已被任何已知的恶意 IP 地址访问。

查询 #1——来自 AWS 中已知恶意 IP 的云 API

SELECT * 
FROM "cloudtrail_logs_aws_cloudtrail_logs_*********"  
WHERE 
    eventtime >= '2022-12-16T00:00:00Z' AND eventtime < '2023-01-05T00:00:00Z' 
    AND sourceipaddress in
    ('178.249.214.10','89.36.78.75','89.36.78.109','89.36.78.135',
    '178.249.214.25','72.18.132.58','188.68.229.52','111.90.149.55') 

查询 #2——来自 ARM 中已知恶意 IP 的云 API

AzureActivity 
| where TimeGenerated >= startofday(datetime(2022-12-16)) and TimeGenerated < 
startofday(datetime('2023-01-05')) 
| where CallerIpAddress in 
("178.249.214.10","89.36.78.75","89.36.78.109","89.36.78.135","178.249.214.25","72.18.132.58","188.68.229.52","111.90.149.55") 

查询 #3——来自已知恶意 IP 的 AAD 服务主体登录活动

AADServicePrincipalSignInLogs
| where TimeGenerated >= startofday(datetime(2022-12-16)) and TimeGenerated < 
startofday(datetime(2023-01-05)) 
| where IPAddress in 
("178.249.214.10","89.36.78.75","89.36.78.109","89.36.78.135","178.249.214.25","72.18.132.58","188.68.229.52","111.90.149.55") 

查询 #4——来自 谷歌云 中已知恶意 IP 的云 API

timestamp >= "2022-12-16T00:00:00Z" AND timestamp < "2023-01-05T00:00:00Z" AND 
protoPayload.requestMetadata.callerIp = ("178.249.214.10" OR "89.36.78.75" OR 
"89.36.78.109" OR "89.36.78.135" OR "178.249.214.25" OR "72.18.132.58" OR "188.68.229.52" OR "111.90.149.55") 

整治

如果任何查询生成了结果，请分别调查每个事件。验证与云身份关联的旧密钥 和密钥是否已更换或删除。此外，寻找上面提到的任何持久性迹象，以及数据泄露的迹象。