windows ipc安全依赖配置与权限控制，需显式设置内核对象acl、命名管道身份验证及加密，禁用高危远程注入操作，并通过etw与系统命令审计异常ipc实例。
windows 进程间通信（ipc）本身不自带安全边界，安全性完全依赖于配置方式、权限控制和运行上下文。用错机制或忽略访问控制，轻则导致数据泄露，重则被用于进程注入、提权或横向移动。关键不在“能不能通”，而在“谁可以通、通什么、怎么通”。
内核对象权限必须显式设置
事件（Event）、互斥体（Mutex）、信号量（Semaphore）、文件映射（File Mapping）等内核对象默认创建时使用当前进程的默认安全描述符，通常允许同组用户甚至所有用户访问。攻击者可轻易打开并篡改共享状态。
- 创建对象时务必传入自定义 SECURITY_ATTRIBUTES 结构，明确指定 lpSecurityDescriptor
- 推荐最小权限原则：只授予 SYSTEM、TrustedInstaller 和必要服务账户的 SYNCHRONIZE + READ_CONTROL 权限；写操作（如 EVENT_MODIFY_STATE）应严格限制
- 命名对象尤其危险——名称暴露即等于入口暴露。避免使用固定、可预测的名称（如 "MyAppMutex"），建议加入随机后缀或哈希值
命名管道需启用完整身份验证与消息保护
命名管道（Named Pipe）常被误认为“本地即安全”，但默认创建的管道若未开启 PIPE_ACCESS_DUAL_MODE 或未设置 SECURITY_DESCRIPTOR，远程攻击者可通过 SMB 协议直接连接（尤其在域环境中）。
- 服务端创建管道时，必须调用 CreateNamedPipe 并设置 dwOpenMode 包含 PIPE_ACCESS_DUAL_MODE，再通过 SetSecurityDescriptorDacl 绑定白名单 ACL
- 客户端连接前，应调用 ImpersonateNamedPipeClient 获取对方令牌，并用 GetTokenInformation 校验 SID 是否属于预期组（如 S-1-5-32-573 表示“Logon Services”）
- 敏感通信建议启用 PIPE_TYPE_MESSAGE + PIPE_READMODE_MESSAGE 模式，并配合 EncryptMessage（SSPI）做端到端加密，而非仅依赖传输层
远程线程与内存注入类操作必须受控
像 CreateRemoteThread + VirtualAllocEx + WriteProcessMemory 这类组合，是合法调试器、杀毒软件和恶意软件共用的技术路径。Windows 已通过 PatchGuard、AMSI、ETW 日志和 PPL（Protected Process Light）机制加强防御，但配置疏漏仍会绕过。
- 非系统级工具禁止对 PPL 进程（如 lsass.exe、winlogon.exe）执行远程内存写入；尝试将触发 STATUS_ACCESS_DENIED 或 ETW 事件 ID 10 及以上
- 所有远程代码注入行为应在启动时注册为 Code Integrity Policy 允许的签名模块，否则会被 HVCI（Hypervisor-protected Code Integrity）拦截
- 开发调试场景下，建议改用 DebugActiveProcess 配合 WaitForDebugEvent，比直接远程线程更合规、更易审计
排查高风险 IPC 实例的实用方法
不必依赖第三方工具，Windows 自带命令即可快速定位异常 IPC 资源。
- 列出所有命名管道：cmd /c "for /f %i in ('powershell -c "Get-ChildItem \\?\pipe\ | ? Name -notmatch '^\\?\\pipe\\(srvsvc|wkssvc|NETLOGON)'") do @echo %i"'
- 检查可疑互斥体：handle64.exe -p lsass.exe -a | findstr /i "mutex"（需 Sysinternals 工具集）
- 审计内核对象 DACL：icacls "GlobalMySharedEvent" /save acl_backup.txt /t，比对是否包含 BUILTINUsers 或 Everyone
- 启用 ETW IPC 日志：logman start "IPC-Trace" -p "{9E814AAD-3204-11D2-9A82-006008A86939}" 0x10000000 0xFF -o ipc.etl -ets，之后用 tracerpt ipc.etl 分析
