当使用windows命令提示符并执行cmd.exe内置命令（如copy、del、echo、start等）时，执行的相应命令行字符串不会填充到Sysmon事件ID 1 -进程创建中。Sysmon事件仅概述cmd.exe映像，命令行值仅为cmd，而不是copy foo bar。
我的理论是，当打开cmd提示符时，只执行cmd.exe进程，并进一步触发Sysmon Event ID 1 - Process Creation的事件，但是，由于我执行的以下命令是cmd.exe内置命令（如上面提到的），因此没有创建实际的新进程，这意味着没有创建新的Sysmon Event ID 1，因此没有捕获命令行值。
如果我在同一命令提示符下运行其他Windows程序（如regedit.exe），我将触发一个新的Sysmon事件ID 1 -进程创建事件，该事件包含执行的命令行字符串，例如regedit foo bar
为了进一步测试这一理论，我启用了Windows安全事件日志-4688（相当于Sysmon事件ID 1 -进程创建）来确定我的Sysmon配置是否是罪魁祸首。
查看我的端点上的Windows安全事件日志- 4688条目，再次测试我的问题后，我发现了相同的行为，Windows事件日志中的命令行字符串值也为空。仅显示来自cmd.exe派生进程的条目，但没有记录后续执行的内置cmd命令。然而，如前所述，如果我执行不同的Windows程序，与上面提到的regedit类似，活动将被捕获为新的4688事件，并执行相应的命令字符串。
有没有人对此问题有任何解决方案？我试图在我的日志（Sysmon或Windows安全事件日志）中捕获cmd提示活动，特别是cmd.exe内置命令。
CMD.exe内置命令：https://renenyffenegger.ch/notes/Windows/dirs/Windows/System32/cmd_exe/commands/index
2条答案
按热度按时间d7v8vwbk1#
我认为你需要的是 * 审计流程创建 * 和 * 命令行流程审计 *。你可能能够审计你想要的一切。
https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/audit-process-creation
参见示例：
https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/component-updates/command-line-process-auditing
8yoxcaq72#
您的理论是正确的。当您在Windows命令提示符中执行内置命令时，操作系统不会将其视为新进程，因此不会触发新的Sysmon事件ID 1 -进程创建事件。
要捕获为内置命令执行的命令行字符串，可以使用PowerShell脚本捕获命令的输出并将其写入日志文件。
下面是一个示例PowerShell脚本，它捕获dir命令的输出并将其写入日志文件：
此脚本捕获dir命令的输出并将其写入位于C：\logs\cmd.log的日志文件。您可以修改此脚本以捕获任何内置命令的输出并将其写入您选择的日志文件。
您可以使用以下命令从Windows命令提示符运行此PowerShell脚本：
将“C：\path\to\script.ps1”替换为要执行的PowerShell脚本的路径。
此方法允许您捕获为日志中的内置命令执行的命令行字符串。