Windows事件日志记录主要分为安全、系统和应用程序等类型,在Vista、Win7、Server 2008,以及 Win10 和 Server 2019 扩展了自定义日志的数量,比如, PowerShell、任务计划程序和 Windows 防火墙等专门的事件日志类型。
尽管要审计的日志数量庞大,但这对于事件响应与溯源取证来说是一件非常好的事情。更多扩展的专用日志意味着,系统中程序执行痕迹的重要信息存储时间更长,而不会成为安全日志快速被覆盖。
不同的版本事件日志存储位置和类型有所不同。
Windows NT / 2000 / XP / Server 2003
.evt
%systemroot%\System32\config
SecEvent.evt, AppEvent.evt, SysEvent.evt
Windows Vista / 7 / 8 / 2008 / 2012 / 10 / 2016
.evtx
%systemroot%\System32\winevt\logs
Security.evtx, Application.evtx, System.evtx, etc.
默认的日志记录位置可以通过注册表来修改
HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Application
HKLM\SYSTEM\CurrentControlSet\Services\EventLog\System
HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Security
Event Logs 类型
Security:根据本地或全局组策略提供的审核标准记录事件。
System:记录操作系统或其组件的事件,例如服务启动失败记录。
Application:记录应用程序的事件,例如 MSSQL 访问数据库失败或防病毒告警。
Custom:范围广泛的专用日志,包括那些只能在服务器上看到的日志,如目录服务、DNS 服务器和文件复制服务日志。许多这些日志都组织在应用程序和服务类别下的事件查看器中。
内置帐户
分析师需要识别出特殊的内置帐户在事件日志中。
SYSTEM:在 Windows 2003 之前,这是用于非用户相关操作的主要帐户。这是系统上权限最高的帐户,因此任何在其权限下运行的进程如果被攻击者控制,都会为该攻击者提供绝对的访问权限。因此,作为微软可信计算计划( Microsoft Trustworthy Computing Initiative )的一部分,添加了更多的受限帐户,这更符合最小特权的安全原则。
LOCAL SERVICE:应用于具有有限权限(类似于标准用户帐户)并且不需要网络访问的服务。因此,它无法使用网络资源进行身份验证,只能使用空会话(null session)进行网络通信。
<Hostname>$:每个加入域的 Windows 系统都有一个计算机帐户。该帐户为计算机提供了在与活动目录(Active Directory) 通信以及访问网络和域资源时进行身份验证的方法。账户根据系统名称命名,账户名末尾必须包含美元符号“$”。
DWM、UMFD:微软几乎没有提供有关这类内置帐户的文档。它们显然与 Windows 管理器 (DWM) 和驱动程序活动 (UMFD) 有关,但需要更多信息。
ANONYMOUS LOGON:这个帐户是最常被误解的。此帐户创建的目的最初是作为 Windows 系统在不需要显式凭据的情况下,进行通信的一种实现方式。在较旧的系统中,匿名登录(ANONYMOUS LOGON)或空会话(null session)可用于枚举帐户信息、安全策略、注册表数据和网络共享。在从 XP 和 2003 开始的较新版本的 Windows 中,这些功能已被慢慢删除。但是,Windows 系统仍然普遍使用该帐户来进行文件、打印共享和维护网络等。如果您的环境中存在这些服务,很可能会看到匿名登录(ANONYMOUS LOGON)的使用情况。关键要点是不要自动假设系统已受到某种枚举攻击。通常需要进一步的上下文信息来理解匿名登录(ANONYMOUS LOGON)的含义。
Windows DIFR 最常查看的日志类型
用户认证和登录
用户行为日志
文件/文件目录/共享访问
安全设置修改
成功和失败都被审计
LSASS进程更新Security Log
第三方应用程序不能写入事件日志
Security相关的事件类型:
Account Logon:审计每个用户登录或注销计算机的事件
Account Mgmt:审计帐户管理的事件。例如,包括密码更改、用户帐户和组修改
Directory Service:审计用户访问活动目录对象的事件,该对象具有自己指定的系统访问控制列表 (SACL)。
Logon Events:审计用户登录或注销计算机的事件。注,这与“Account Logon”类别不同。Account Logon 跟踪哪个域控制器对用户进行了身份验证;Logon Events跟踪到特定服务器的登录事件。
Object Access:审计用户访问指定了自己的系统访问控制列表 (SACL) 的对象的事件。对象的示例有文件、文件夹、注册表项、打印机等。
Policy Change:审计用户权限变更、审计策略或可信策略
Privilege Use:审计帐户执行用户权限的各个事件
Process Tracking:审计进程启动、退出、句柄、对象访问等
System Events:审计系统启动和注销
确定哪些帐户在尝试登录
跟踪已知受感染帐户的帐户事件
登录相关的事件ID:
4624: 登录成功
4625: 登录失败
4634 / 4647: 注销成功
4648: 使用显式凭据登录
4672: 具有管理员权限的帐户登录
4720 / 4726: 创建/删除了一个帐户
登录类型的代码
登录会话ID
每个帐户会话在登录时都会分配一个唯一的登录 ID。登录 ID对于跟踪该会话期间的用户活动非常有用,可以将4624登录成功事件和 4647登录注销事件联系在一起,确定用户在此会话期间登录的时间。
注,4634 登录注销事件也被 4647 事件代替。对于确定交互式登录的会话时长最有用(登录类型 2、10、11、12)。其他登录类型,如,批量登录和网络登录(登录类型 3、5)往往连接的时间很短。
如果用户从远程共享打开文档,即使用户仍然打开该文档,也会生成网络登录(登录类型 3 )的登录和注销。如果修改并保存到文档中,将启动另一个网络登录的会话。
本地帐户与在线帐户有着千丝万缕的联系,跨设备共享配置信息(这对于域帐户是不可能的)。在大多数情况下,这些登录为缓存凭证登录(登录类型 12)。
Windows XP/2003中对应的事件ID:528、538、551
一旦攻击者拥有管理员权限,他们就可以轻松创建其他帐户。本地管理员可以创建本地帐户,而域管理员可以创建几乎任何类型的域范围帐户。
虽然由于哈希传递(PtH)和基于票据攻击的流行,如今这种攻击不太常见,但流氓账户仍然是一种非常可行的方式来逃避某些审计并创建攻击者在遇险时可以使用的“潜伏”账户。然而,通过对账户管理事件的适当审计,检测账户创建非常容易。
创建帐户时会记录4720事件。除了创建它的日期和时间以及计算机外,还获得用于授权创建的帐户和详细信息。
4722:启用用户帐户
4724:尝试重置帐户密码
4728:一个成员被添加到启用安全的全局组
4732:一个成员被添加到启用安全的本地组
4735:启用安全的本地组已更改
4738:用户帐户已更改
4756:一个成员被添加到启用安全的通用组
RDP相关的事件ID:
4778: RDP会话重新连接
4779: RDP会话结束
除了标准的登录事件 ID 代码之外,还有一些专门绑定到远程桌面协议 (RDP) 的专用事件 ID,Remote Desktop Services—RDPCoreTS和TerminalServices-RdpClient记录补充信息。
RDP 活动记录在多个位置,了解RDP连接的源地址与目的地址至关重要。
虽然许多日志保留重复信息,但 Microsoft-Windows-TerminalServices RDPClient/Operational 是一个重要RDP日志源。此类型日志中的信息记录在源系统上,对于了解攻击者从该系统RDP登录其他主机非常重要。
帐户登录事件不同于登录事件类别,此类事件记录在验证凭据的系统上,比如:
本地帐户(Local Account)/工作组 = 在工作站上
域(Domain)/活动目录(Active Directory) = 在域控制器上
帐户登录相关的事件ID:
4776:成功/失败帐户认证(NTLM 认证协议)
4768:票证授予票据(TGT)被授予(Kerberos认证协议,登录成功)
4769:请求服务票据(ST)(Kerberos认证协议,访问服务资源)
4771:预认证失败(Kerberos认证协议,登录失败)
Windows XP/2003中对应的事件ID:672, 673, 675, 680
登录事件和帐户登录事件极易混淆,源于糟糕的命名名称。
登录事件是指系统上发生的登录/注销活动。因此,它们本地存储在该系统上。
帐户登录事件是指在该登录会话期间提供的凭据的第三方授权。在 Windows 域环境中,绝大多数用户帐户实际上是域帐户,其凭据存储在域控制器上,而不是本地系统。在该用户可以登录到域环境中的工作站之前,其用户名和密码必须由域控制器使用 NTLM 或 Kerberos 身份认证协议进行验证。
因此,单个用户登录可能导致多个不同的事件分布在工作站(登录事件 4624、4634 等)和域控制器(帐户登录事件 4776 或 4768、4769)上。
特殊情况,如果用户使用本地帐户登录,该帐户仅在工作站而不属于任何域用户,则工作站自身将使用本地 SAM 数据库进行身份验证,因此将在工作站的事件日志中同时看到登录事件和帐户登录事件。这在企业中很少见,有可能被创建的恶意帐户正在登录。
Kerberos身份认证协议
从 Windows 2003 Server开始,Windows 域中的默认是 Kerberos身份认证协议。
Kerberos 的工作原理是用户首先向身份验证服务器(通常是域控制器)提供凭据。凭据经过验证,如果正确,则会向用户颁发一段时间的票证授予票据(TGT)。TGT 然后可以用作一种允许通过其他域控制器进行身份验证的。要访问另一个系统(例如服务器)上的资源,需要单独的票据,称为服务票据(ST)。
如果 Kerberos预认证失败,事件 ID 4771 将写入认证服务器的日志。除了提供有关日期/时间、主机名、客户端 IP 地址和提供的用户名的信息外,还将包含一个错误代码,说明身份验证失败的原因,参考上表。
Windows XP/2003中对应的事件ID:675
NTLM 身份认证协议
NTLM 身份验证在 Windows 企业中仍然存在。例如,本地帐户的身份验证通常会在主机上记录为 NTLM。哈希传递攻击也依赖于 NTLM 身份验证,因此识别这些身份验证可能很有价值。此类认证过程,将记录为事件 ID 4776。
在事件 ID 4771 (Kerberos)、4776 (NTLM) 和 4625(登录失败)的事件描述中超过 40 个错误原因代码,部分错误代码说明如下:
to be continue ……
reference
Special Identities: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn617202(v=ws.11)#BKMK_WindowManager
Securing Critical and Service Accounts: https://learn.microsoft.com/en-us/previous-versions/tn-archive/cc875826(v=technet.10)?redirectedfrom=MSDN