Windows服务器的服务项管理是主机安全中最容易被忽视却最致命的环节。默认安装的Windows Server会启动大量系统服务，其中相当一部分在业务环境中根本用不到，却为攻击者提供了横向移动、权限提升和持久化驻留的现成通道。很多运维人员只关注补丁更新和防火墙策略，却对服务账户的权限范围、服务可执行文件的完整性、服务启动类型是否合理缺乏系统性的管控，导致服务器在遭遇入侵后长期被隐蔽利用。
服务项安全管控的核心逻辑并不复杂：每一个运行中的服务都是一个潜在的攻击面，服务对应的可执行文件、启动账户、权限级别、恢复操作和依赖关系共同决定了风险敞口。管控的目标是压缩攻击面、限制服务账户权限、监控服务状态异常变化，并建立可审计的变更基线。
一、服务账户权限最小化是首要任务Windows服务默认以三种身份运行：Local System、Local Service和Network Service。Local System权限等同于操作系统最高权限，可以加载驱动、访问SAM数据库、注入任意进程。很多第三方应用在安装时默认将服务注册为Local System账户，这是极其危险的。一旦该服务存在漏洞或被恶意替换可执行文件，攻击者直接获得系统级权限。
运维人员应逐一审查每个非微软服务的“登录”选项卡。对于不需要与桌面交互、不需要访问本地高权限资源的服务，应改用Local Service或Network Service账户。如果服务需要访问网络共享或特定目录，应创建专用的最低权限域账户或本地账户，并通过安全描述符精确授予该账户仅访问所需资源。
具体操作可以通过services.msc或PowerShell命令完成。例如使用以下命令修改服务登录账户：
sc.exe config "ServiceName" obj= "DOMAIN\svc_account" password= "Password"
修改后必须重启服务才能生效。同时要在本地安全策略中授予该账户“作为服务登录”的权限。如果使用组策略统一管理，可以在“计算机配置\Windows设置\安全设置\本地策略\用户权限分配”中集中配置。
二、禁用或删除不必要的服务Windows Server默认启用的大量服务并非业务所需。Print Spooler服务是历史漏洞重灾区，从PrintNightmare到后续多个提权漏洞都与该服务相关。如果服务器不承担打印服务器角色，应立即禁用。Remote Registry服务允许远程修改注册表，属于高危服务，非必要必须禁用。Server服务如果服务器不需要对外提供文件共享，也应停止。Secondary Logon服务常被攻击者用于RunAs提权，同样建议禁用。
建议运维人员建立一份服务基线清单，按服务器角色分类。域控、文件服务器、Web服务器、数据库服务器各自需要的服务集合不同。使用以下PowerShell命令可以导出当前所有服务的状态、启动类型和登录账户：
Get-Service | Select-Object Name,DisplayName,Status,StartType | Export-Csv -Path C:\service_baseline.csv -NoTypeInformation
对于已禁用的服务，还要检查是否存在对应的计划任务或注册表启动项会重新拉起该服务。部分恶意软件会通过修改服务配置实现持久化，禁用服务后需要监控服务状态是否被异常恢复。
三、服务可执行文件路径与签名校验每个Windows服务都指向一个可执行文件路径，该路径记录在注册表HKLM\SYSTEM\CurrentControlSet\Services\服务名\ImagePath中。攻击者常用的持久化手法之一就是修改ImagePath，将服务指向恶意程序，或者利用服务可执行文件所在目录权限过大，直接替换原文件。
运维人员应定期检查所有服务的ImagePath值，确认路径指向可信目录。重点检查非System32目录下的服务可执行文件，尤其是Program Files、ProgramData、Temp等目录。对于第三方服务，应验证文件的数字签名是否有效。可以使用PowerShell的Get-AuthenticodeSignature命令批量检查：
Get-Service | ForEach-Object {
$path = (Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\$($_.Name)").ImagePath
if ($path) {
$cleanPath = $path.Trim('"').Split(' ')[0]
if (Test-Path $cleanPath) {
$sig = Get-AuthenticodeSignature $cleanPath
[PSCustomObject]@{
Service = $_.Name
Path = $cleanPath
SignatureStatus = $sig.Status
Signer = $sig.SignerCertificate.Subject
}
}
}
} | Format-Table -AutoSize
同时要检查服务可执行文件所在目录的ACL权限。如果普通用户对服务目录有写入权限，攻击者就可以替换服务文件。应确保服务目录仅允许Administrators和SYSTEM完全控制，其他用户只读或拒绝访问。
四、服务权限与DACL加固Windows服务本身也有安全描述符，决定了哪些用户或组可以启动、停止、暂停或修改该服务。默认情况下，普通用户对大多数服务只有读取权限，但部分第三方服务安装时会错误地授予Everyone完全控制权限。攻击者如果拥有对服务的修改权限，可以直接更改服务配置，将服务指向恶意程序或修改启动账户。
可以使用sc.exe sdshow命令查看服务的安全描述符：
sc.exe sdshow "ServiceName"
输出结果是一串SDDL字符串。需要重点检查其中是否包含允许普通用户或Everyone拥有写入、修改权限的ACE。如果发现异常，可以使用sc.exe sdset命令重新设置安全描述符。更直观的方法是使用Sysinternals的AccessChk工具或PowerShell脚本遍历所有服务权限。
建议对所有关键服务统一设置严格的DACL：SYSTEM和Administrators完全控制，服务账户仅授予启动和停止权限，其他用户仅读取。对于高价值服务如远程桌面服务、Windows Update服务、安全中心服务，应额外限制修改权限。
五、服务失败恢复操作与依赖关系监控服务的“恢复”选项卡定义了服务失败后的操作，包括重启服务、运行程序或重启计算机。攻击者可以利用这一点，将恢复操作指向恶意脚本或程序。当服务崩溃或被攻击者故意终止时，恶意代码就会被执行。运维人员应检查所有服务的失败恢复操作，确保“运行程序”选项没有被设置为可疑路径。
服务依赖关系同样值得关注。攻击者可能注册一个恶意服务，并设置为某个正常服务的前置依赖，导致正常服务无法启动，或者利用依赖关系实现隐蔽加载。可以使用以下命令查看服务依赖：
sc.exe qc "ServiceName"
输出中的DEPENDENCIES字段列出了该服务依赖的其他服务。如果发现某个核心服务依赖了一个不认识的第三方服务，应立即排查该服务的来源和用途。
六、建立服务变更审计与实时监控服务配置变更、服务状态变化、新服务安装等事件都应纳入审计范围。Windows安全日志中，事件ID 7045记录新服务安装，事件ID 7040记录服务启动类型变更，事件ID 7036记录服务状态变化。但默认情况下这些事件不会全部记录，需要启用“审核其他对象访问”策略或使用Sysmon进行更细粒度的监控。
Sysmon是服务监控的最佳工具。通过配置Sysmon规则，可以记录服务创建、服务配置修改、服务可执行文件变更等关键事件。以下Sysmon配置片段可以监控服务相关的注册表键变更：
\Services\
同时建议使用计划任务定期导出服务清单，与基线文件进行比对。任何新增服务、启动类型变更、登录账户变更都应触发告警。对于关键服务器，还可以启用Windows Defender Application Control或AppLocker，限制服务可执行文件的加载，从源头上阻止未授权程序注册为服务。
七、服务账户密码管理与凭据保护使用域账户运行服务时，密码管理是一个长期痛点。很多组织使用永不过期的服务账户密码，或者将密码硬编码在脚本和配置文件中。一旦服务账户密码泄露，攻击者可以远程登录或横向移动。建议使用组管理的服务账户（gMSA），它由Active Directory自动管理密码，定期轮换，且密码无法被直接提取。
对于无法使用gMSA的环境，应建立服务账户密码定期轮换机制，并确保密码强度足够。同时要限制服务账户的登录权限，禁止服务账户交互式登录，禁止其加入本地管理员组。在服务账户的AD属性中，可以设置“该账户仅允许登录到以下计算机”，将账户绑定到指定服务器。
本地服务账户的密码存储在注册表中，使用LSA Secrets加密。攻击者如果获得SYSTEM权限，可以通过Mimikatz等工具提取这些密码。因此保护SYSTEM权限本身的安全至关重要，包括限制本地管理员组成员、启用Credential Guard、定期更新系统补丁。
八、第三方服务与Web应用服务的特殊管控Web服务器上的应用池、数据库服务、中间件服务往往以高权限运行，且与业务代码紧密关联。IIS应用池默认以ApplicationPoolIdentity运行，这是一种动态创建的低权限虚拟账户，安全性较好。但很多运维人员为了方便，将应用池改为LocalSystem或管理员账户，导致Web应用一旦被入侵，攻击者直接获得系统权限。
数据库服务如SQL Server、MySQL同样需要严格管控。SQL Server服务账户不应使用LocalSystem，应使用专用低权限账户，并仅授予数据库文件目录的访问权限。同时要检查数据库服务是否开启了不必要的扩展功能，如xp_cmdshell，这些功能可以被攻击者利用执行系统命令。
对于Java应用服务如Tomcat、WebLogic，服务账户权限管理同样重要。这些服务通常以独立账户运行，需要确保该账户对应用目录只有读取和执行权限，对日志目录有写入权限，对其他系统目录无权限。
Windows服务器服务项安全管控不是一次性工作，而是需要持续投入的运维基线工程。核心在于建立服务清单、明确每个服务的必要性和权限边界、通过技术手段监控变更、定期审计服务配置。当攻击者无法通过服务项实现提权、持久化和横向移动时，整个服务器的安全防护能力将得到显著提升。运维人员应将服务项管控纳入日常安全巡检和应急响应流程，确保每一台Windows服务器都处于最小权限、最小攻击面的运行状态。
