EDR 可以挂接正在运行的应用程序。因此，它可以验证所执行的操作。大多数情况下，这发生在ntdll.dll或kernel32.dll。如果它检测到可疑的东西，它可以尝试阻止那些不需要的活动。在真正的损害发生之前。

限制 EDR 挂钩进程的可能性的一种方法是仅允许由 Microsoft 签名的 DLL。这可以通过在可执行文件上设置缓解措施来实现。默认情况下，所有应用程序都有两个缓解措施：DEP 和 ASLR，这在运行我以前博客中的旧 NativeApiWithEvasion 可执行文件时可以看到。

相关视频教程

恶意软件开发（更新到了155节）

简而言之：vData Execution Protection （DEP）是一项安全功能，可帮助防止代码从某些不可执行的内存区域执行。它的工作原理是将指定的内存区域标记为不可执行，从而使攻击者更难从这些区域执行其恶意代码。

地址空间布局随机化（ASLR）是一种安全技术，它涉及随机排列关键数据区域的位置，例如可执行文件的基础以及进程地址空间中堆栈、堆和库的位置。这种随机化使攻击者更难预测内存布局，从而降低了成功利用内存相关漏洞的可能性。

有趣的是，它错过了SEHOP保护。来自 Microsoft：

但是，通过使用_PROCESS_MITIGATION_BINARY_SIGNATURE_POLICY结构，我们可以根据图像的签名定义一些用于加载图像的策略设置。

看结构。看起来我们可以有 3 个真正的缓解选项

 struct {
      DWORD MicrosoftSignedOnly : 1;
      DWORD StoreSignedOnly : 1;
      DWORD MitigationOptIn : 1;
      DWORD AuditMicrosoftSignedOnly : 1;
      DWORD AuditStoreSignedOnly : 1;
      DWORD ReservedFlags : 27;
    } DUMMYSTRUCTNAME;

MicrosoftSignedOnly

阻止进程加载未经 Microsoft 签名的图像;

StoreSignedOnly

阻止进程加载未经 Windows 应用商店签名的图像。

MitigationOptIn

阻止进程加载未经 Microsoft、Windows 应用商店和 Windows 硬件质量实验室（WHQL）签名的图像;

因此，我们可以使用 3 种可能性。有趣的是，我只读过 MicrosoftSignedOnly，而不是 Windows 应用商店。所以这将是最有趣的使用！但是，我无法让它工作。我每次都收到未经授权的异常。

    
    // Enable the Code Integrity check to enforce Microsoft-signed DLLs only
    PROCESS_MITIGATION_BINARY_SIGNATURE_POLICY policy = { 0 };
    policy.StoreSignedOnly = false;
    //when you want to use a MicrosoftSignedOnly it is as easy as just putting this on true.
    policy.MicrosoftSignedOnly = true;

    if (SetProcessMitigationPolicy(ProcessSignaturePolicy, &policy, sizeof(policy))) {
        std::cout << "Successfully set process mitigation policy to require Microsoft-signed DLLs only." << std::endl;
    }
    else {
        std::cerr << "Failed to set process mitigation policy." << std::endl;
    }

在上面的代码中。可以看出，Microsoft 仅签名策略设置设置为 true。运行代码后，我们可以在进程黑客中看到包含缓解措施。

下图对此进行了更详细的解释。正如描述所指示的那样。现在只允许使用 Microsoft 签名！

有趣的是，当尝试使用 Windows 应用商店签名策略构建应用程序集时，我们会收到“拒绝访问”错误消息。即使我在管理员模式下运行应用程序。不知道为什么我不能设置那个值，文档对此不清楚。

使用存储签名缓解选项时出现访问被拒绝错误。

但是，重要的是要知道当前代码存在问题。此时，应用程序已启动并运行，然后设置了签名限制。这当然是防止以后攻击的好方法。但是，EDR 几乎立即注入其 dll，这不是解决方案。

我想到有两种可能性：

1：我可以更改我们的代码，以便它启动一个子进程。对于该子进程，我们将在启动时使用策略限制对其进行初始化。那么 EDR 就不可能介入并执行其挂钩。除非它具有签名的 Microsoft DLL。但是，启动子进程会很嘈杂。

2. 只需在已设置此策略的情况下构建应用程序即可。在 Microsoft Visual Studio 中，可以设置许多配置。这不需要任何代码，我们不必启动子进程，它应该在启动时立即运行！

可悲的是，在尝试和阅读之后，我找不到在 Visual Studio 中实现后者的可能配置。因此，我们需要开始孩子的进步。这真是太可惜了。

您可以添加额外的命令，但是我发现没有一个命令启用此限制 Microsoft 签名 dll 的选项

因此，让我们看看 ired.team 中的一些代码，我们如何启动使用此策略设置的流程。为了澄清，我加入了一些命令。

void CreateChildProcessWithMitigationOption() {
    //initalization of data  is a structure that receives identification information about the created process (handle, process ID, and thread ID).
    PROCESS_INFORMATION pi = {};
    //a structure that contains startup parameters for a new process, extended with attribute
    STARTUPINFOEXA si = {};
    // is initialized to 0; it will be used to determine the size of the attribute list.
    SIZE_T attributeSize = 0;
    //is used to get the required size for the attribute list (attributeSize)
    InitializeProcThreadAttributeList(NULL, 1, 0, &attributeSize);
    //HeapAlloc is used to allocate memory for the attribute list.
    PPROC_THREAD_ATTRIBUTE_LIST attributes = (PPROC_THREAD_ATTRIBUTE_LIST)HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, attributeSize);
    //the second call initializes the attribute list with the correct size.
    InitializeProcThreadAttributeList(attributes, 1, 0, &attributeSize);
    // the policy that we want so set is initialized
    DWORD64 policy = PROCESS_CREATION_MITIGATION_POLICY_BLOCK_NON_MICROSOFT_BINARIES_ALWAYS_ON;
    //This code sets the process creation mitigation policy to block non-Microsoft binaries. 
    //As we used before.
    UpdateProcThreadAttribute(attributes, 0, PROC_THREAD_ATTRIBUTE_MITIGATION_POLICY, &policy, sizeof(DWORD64), NULL, NULL);
    si.lpAttributeList = attributes;
    //CreateProcessA is then called to create a new process. The executable is "NativeApiWithEvasion.exe".
    //It will be executed in the same directory as the currently executed program.
    //Using the attributes that include the policy mitigation!
    CreateProcessA(NULL, (LPSTR)"NativeApiWithEvasion.exe", NULL, NULL, TRUE, EXTENDED_STARTUPINFO_PRESENT, NULL, NULL, &si.StartupInfo, &pi);
    HeapFree(GetProcessHeap(), HEAP_ZERO_MEMORY, attributes);

    return;
}

让我们再放大一下 CreateProcessA Windows API。（当然，我们可以将其重写为原生WindowsApi函数，该函数将是NtCreateUserProcess。但是，这不是本博客的重点，但将来会进行调查。

CreateProcessA(
    NULL,                       // lpApplicationName
    (LPSTR)"NativeApiWithEvasion.exe",  // lpCommandLine
    NULL,                       // lpProcessAttributes
    NULL,                       // lpThreadAttributes
    TRUE,                       // bInheritHandles
    EXTENDED_STARTUPINFO_PRESENT,// dwCreationFlags
    NULL,                       // lpEnvironment
    NULL,                       // lpCurrentDirectory
    &si.StartupInfo,            // lpStartupInfo
    &pi                         // lpProcessInformation
);

lpApplicationName （空）：

此参数指定要执行的模块的名称。在本例中，它设置为，这意味着模块名称取自参数。NULLlpCommandLine

lpCommandLine （（LPSTR）“NativeApiWithEvasion.exe”）：

此参数指定要执行的命令行。在本例中，它设置为字符串“NativeApiWithEvasion.exe”，指示应运行的可执行文件的名称。

lpProcessAttributes （空）：

此参数通常设置为，指示新进程不会继承调用进程的句柄。NULL

lpThreadAttributes （空）：

与一样，此参数设置为，表示新进程的主线程不会继承调用进程主线程的句柄。lpProcessAttributesNULL

bInheritHandles （TRUE）：

此参数确定新进程是否将从调用进程继承句柄。在本例中，它设置为，表示新进程将继承句柄。TRUE

dwCreationFlags （EXTENDED_STARTUPINFO_PRESENT）：

此参数指定控制进程创建的其他标志。是一个标志，指示存在扩展结构，它允许对新进程的创建进行更多控制。EXTENDED_STARTUPINFO_PRESENTSTARTUPINFO

lpEnvironment （空）：

此参数允许您为新进程指定环境块。在本例中，它设置为，表示新进程将继承调用进程的环境。NULL

lpCurrentDirectory （NULL）：

此参数指定新进程的当前工作目录。将其设置为表示新进程将从与调用进程相同的当前目录开始。这很重要，因为我们希望执行相同的可执行文件来启动我们的子进程。NULL

lpStartupInfo （&si.StartupInfo）：

此参数是指向结构的指针，该结构指定新进程的主窗口的显示方式。在本例中，它使用存储在变量中的结构。STARTUPINFOSTARTUPINFOsi

lpProcessInformation （&pi）：

此参数是指向一个结构的指针，该结构接收有关新进程的标识信息，例如其进程句柄和线程句柄。在本例中，它使用存储在变量中的结构。PROCESS_INFORMATIONPROCESS_INFORMATIONpi

我更改了本地缓解策略代码，以确保父进程将创建子进程。进行检查以验证其进程是否启用了策略。如果没有，它将创建一个子进程，并为其进程启用策略（如果确实启用了该策略）。它已经是子进程，它不会生成另一个子进程（否则会发生循环）。

这可能是一个有趣的技巧，可以确保父进程保持活动状态（例如，在一段时间内使用 sleep 1 循环），并且我们现在有一个子进程，该子进程从启动时就启用了策略！

void LocalProcessMitigationOption(){
    // Enable the Code Integrity check to enforce Microsoft - signed DLLs only
    PROCESS_MITIGATION_BINARY_SIGNATURE_POLICY policy = { 0 };
    // Get the policy for the current process. 
     GetProcessMitigationPolicy(GetCurrentProcess(), ProcessSignaturePolicy, &policy, sizeof(policy));
    // if it doesn't have the microsoftSignedOnly Policy.  
    if (!policy.MicrosoftSignedOnly) {
         printf("MicrosoftSignedOnlyn");
          // This indicates this is the parent process
         parentProcess = true;
         policy.MicrosoftSignedOnly = true;
        // create a child process with the mitigation options enabled.
         CreateChildProcessWithMitigationOption();
        //set the policy in the original manor for the parent proces (this proces) as well)
         if (SetProcessMitigationPolicy(ProcessSignaturePolicy, &policy, sizeof(policy))) {
             std::cout << "Successfully set process mitigation policy to require Microsoft-signed DLLs only." << std::endl;
         }
         else {
             // Incase of error log the reason.
             std::cerr << "Failed to set process mitigation policy." + GetLastErrorAsString() << std::endl;
         }
     }

当运行应用程序并通过进程黑客验证它时，我们看到应用程序现在生成了一个子进程，并且两者都启用了策略！

我们还可以看到 1 是从特定路径加载的，而另一个不是。父进程显示一个是从explorer.exe启动的，另一个是父进程本身nativeApiWithEvasion.exe。

如果我们开始挂钩 WinDbg（慢慢地掌握那里也会在未来创建一个博客），我们可以看到两个 dll 仍然注入到两个应用程序中。但是，如果我们看一下，我们会注意到缺少一个dll。在主进程中，我们可以看到sechost.dll是托管的，而子进程中的情况并非如此！

我找不到任何官方文档。但是查看 Windbg 中的函数，我们可以看到加载了一些函数。至少其中一些函数是 wincred.h 标头的一部分，该标头负责安全性和身份性。有趣的是，这个dll不是由Microsoft签名的？

但我需要进一步调查为什么没有加载这个dll。因为看着 sigcheck。两个 Dll 都已签名。它还给出了一些描述。它用于 SCM、SDDL 和 LSA 查找 API

Powershell：列出进程缓解选项

有一个 PowerShell 命令用于验证进程是否具有一些进程缓解措施。按照手册中的指示，如果指定进程名称并包括 -RunningProcesses，则可以列出 processmitigation 选项。

ired.team 的以下单行代码很好地概述了所有流程的流程缓解措施。如果你把它写到一个文件中，你会得到一个很好的概述。

gget-process | select -exp processname -Unique | % { Get-ProcessMitigation -ErrorAction SilentlyContinue -RunningProcesses $_ | select processname, Id, @{l="Block non-MS Binaries"; e={$_.BinarySignature|select -exp MicrosoftSignedOnly} } }

有趣的是，有些进程启用了某些进程，有些进程禁用了此签名。例如，chrome 有一些进程不会强制使用 Microsoft 签名标志。

结论

如果我们看上面的这项工作，我们可以带走一些东西：

此方法对 Microsoft 对其文件进行数字签名的 EDR 无效。（就像我系统上的那个一样）。因为即使启用了块 DLL 策略，也允许注入其 DLL。
我们无法在启用此功能的情况下构建应用程序。我们需要在应用程序启动时运行它。（EDR 可能已经注射的那一刻）或在设置这些设置的情况下开始孩子的进度。
在流程中看到它已经很常见了。因此，在我看来，拥有使用此功能的程序并不是一个即时的危险信号。Microsoft 发现，当我包含代码时，它很可疑。但是，扫描几秒钟后就允许了。

祝您测试愉快！

如果您想讨论与信息安全相关的任何事情，我在 LinkedIn：https://www.linkedin.com/in/bobvanderstaak/