本文作者： t3st （信安之路作者团队成员 & 信安之路红蓝对抗小组成员）
成员招募：信安之路红蓝对抗小组招募志同道合的朋友
这个系列的文章翻译由信安之路红蓝对抗小组的所有成员共同完成，后续将陆续发布，敬请期待！
Threat Hunting#19. 发现使用 procdump 或者任务管理器转储内存的行为
mimikatz 等获取密码的工具很容易被杀毒软件报毒，有一种更好的解决方案是使用 Procdump 或者任务管理器转储lsass进程的内存至文件，然后将文件下载到本地离线获取凭证。这样做之所以不容易被杀毒软件发现是因为Procdump和任务管理器都是具有微软签名的可信程序。
Procdump 或者任务管理器通过 dbghelp.dll 或者 dbgcore.dll 来调用内存转储写入函数—— MiniDumpWriteDump 。因此我们可以使用 sysmon 监控 ProcessAccess（进程访问）事件，并筛选出 TargetImage 为 lsass.exe （或者其他敏感进程）并且 CallTrace 包含 dbghelp.dll 或者 dbgcore.dll 的日志，从而检测是否发生了内存转储行为。具体操作如下：
1、 如图所示，指定配置文件安装 sysmon，使用“-c”参数可以查看当前的配置情况。加载的配置文件ProcdumporTaskmgr.xml 为：
<Sysmon schemaversion="**4.21**">
<EventFiltering>
<ProcessAccess onmatch="**include**">
<TargetImage condition="**end with**">lsass.exe</TargetImage>
<CallTrace condition="**Contains**">Dbghelp.dll</CallTrace>
<CallTrace condition="**Contains**">Dbgcore.dll</CallTrace>
</ProcessAccess>
</EventFiltering>
</Sysmon>
2、使用任务管理器创建转储文件。
3、 如图所示，使用 procdump 转储内存。
4、打开事件查看器，在 “应用程序和服务日志/Microsoft/Windows/Sysmon/Operational” 中即可查看 sysmon 的监控日志。筛选事件 id 为 10（ProcessAccess）的日志，我们可以看到两次转储操作的日志。sysmon 监控到的任务管理器转储内存的日志，调用了“C:\WINDOWS\SYSTEM32\dbgcore.DLL”:
sysmon 监控到的 procdump 转储进程内存的日志，同样调用了 “C:\WINDOWS\SYSTEM32\dbgcore.DLL” :
至此，我们已经借助 sysmon 分析出当前操作系统中发生过的内存转储行为，当然防御时必须提前配置 sysmon 进行监控。为了使用 sysmon 监控更多行为，也可以在安装 sysmon 时不添加过滤器，分析时使用事件查看器的过滤器进行筛选。
除了 sysmon，我们还可以使用功能比较强大的 SIEM 系统进行实时监控。例如 IBM QRadar 的查询 AQL 语句为：
select "SourceImage", "TargetImage" from events where eventid=10 and utf8(payload) imatches '(?i)((.*dbghelp.*)|(.*dbgcore.*))' and TargetImage imatches '.*lsass.*'
原文地址：
https://blog.menasec.net/2019/02/threat-hunting-21-procdump-or-taskmgr.html
Threat Hunting#20. 使用事件 4985 检测 Process Doppelgänging
Process Doppelgänging 是一种可以绕过杀软的代码注入技术:
Process Doppelgänging meets Process Hollowing in Osiris dropper | Malwarebytes Labs
这种技术会调用几个与 NTFS 事务相关的 API，这些 API 允许在创建进程之前替换 PE 内容。Windows 创建了一个安全事件来记录 NTFS 事务的状态变化（EventID = 4985）。因此，我们可以利用 4985 事件来检测Process Doppelgänging。
我们尝试从十多台服务器中分析事件 4985 的正常值。
我们还观察了其他 4 台使用 Win7/Win10 的计算机。结果为 lsass.exe、svchost.exe 和 TrustedInstaller.exe 也会作为正常的 4985 事件的源进程。
我们在 Windows 7 上测试 Process Doppelgänging，事件 4985 显示的信息如图所示:
结合上面的分析，我们可以通过筛选事件 ID 为 4985 并且 SubjectLogonId 不为“0x3e7”的日志，来检测Process Doppelgänging 技术的使用。具体的筛选规则为:
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">*[System[(EventID=4985)] and EventData[Data[@Name='SubjectLogonId']!='0x3e7']]
</Select>
</Query>
</QueryList>
也可以筛选事件 ID 为 4985 并且进程路径不存在于下列清单中的日志：
c:\windows\system32\svchost.exe
c:\windows\system32\lsass.exe|
c:\windows\servicing\TrustedInstaller.exe
c:\windows\system32\poqexec.exe
c:\windows\winSxS*\TiWorker.exe
原文地址：
https://blog.menasec.net/2019/02/threat-hunting-24-detecting-process.html
Threat Hunting #21 利用真实或伪造的计算机账号进行隐秘控制
我们讨论过检测软件会根据特定事件的来源或者目标帐户名称中是否包含 $ 符号来排除计算机账户，从而减少误报。在这一部分中，我们将演示攻击者如何利用其来躲避检测软件，并给出一些分析人员进行检测时可以参考的信息。
攻击准备：伪造计算机账户
如图所示，在获得域的完整控制权限（我们这里使用的是域管：EXAMPLE\admin01）之后，攻击者可以使用net命令创建一个假的计算机帐户（名为EXAMPLE\SERVER01$），并将其添加到域管理员组。
这一操作将产生一个 4720 事件的安全日志（创建用户帐户），而不是 4741 事件（创建计算机账户）。
方法1：使用 psexec 横向移动
攻击者可以使用 psexe .exe 在 PC01（10.0.2.17）上获取一个域控制器 (10.0.2.15) 的系统权限交互式 shell。
此操作将产生一些与 PsExec 执行相关的日志，我们在之前的文章中已经讨论过。在本例中，我们更感兴趣的是在利用伪造的计算机帐户 (SERVER01$ )时系统产生的日志。
PC01（客户端）系统并没有为 SERVER01$ 创建本地配置文件（因为用户未经过本地身份验证）。
DC（服务器端）系统没有为 SERVER01$ 创建本地配置文件，也没有在注册表中添加 SERVER01$ 用户的信息（因为我们通过 PsExec 创建的 spoolsrv 系统服务的执行命令的）。
有关排查 windows 用户配置文件的更多信息，请参阅:
Troubleshoot user profiles with events - Windows Server | Microsoft Learn
方法2 ：使用 net 命令横向移动
与方法 1 相同，系统并没有为用户创建配置文件(通过查看注册表、文件系统和应用程序日志可知)。由于我们是通过ntlm 进行身份验证的，系统记录到了一些登录信息，这些日志可以帮助分析人员发现不正常的认证活动:
但是，4624 事件并不是总会列出登录来源的计算机名，只有通过 NTLM 进行身份验证时系统日志中才会列出登录来源的计算机名，如果通过 kerberos 进行身份验证，源工作站名通常为空。
方法3：通过 RunAs 利用伪造的账户登录
通过NTLM进行身份认证，系统将产生相同的日志:
小贴士：
1、 系统没有为上述远程访问方法创建本地配置文件(文件系统、注册表)。
2、如果使用 NTLM 作为身份验证方式，则 4624 事件中会包含登录来源的计算机名，如果是 Kerberos，则只记录来源 IP。
3、“net user”或“net user /domain”只返回用户名中没有“$”符号的帐户(账户名中包含“$”不一定是真正的计算机帐户)。
4、测试我们在本文第 1/2 部分中分享的用例。
原文地址：
https://blog.menasec.net/2019/02/threat-hunting-6-hiding-in-plain-sights_8.html