精华内容
下载资源
问答
  • Windows日志

    千次阅读 多人点赞 2019-05-29 16:29:26
    文章目录一,Windows事件日志简介二,打开事件查看器命令:eventvwr三,Windows事件日志共有五种事件级别四,Windows日志文件五,对常用安全事件的分析1.用户登录与注销2.追踪硬件变动3.追踪WiFi信息六,日志获取和...

    学习目标

    1. Windows事件日志简介:存储位置、内容、查看方法。
    2. Windows事件日志分析:开关机、登录、注销、连接网络、插U盘。
    3. 安全审核:TCP、UDP。

    一,Windows事件日志简介

    Windows事件日志记录着Windows系统中发生的各类事件。通过事件日志,可以监控用户对系统的使用情况,掌握计算机在特定时间发生了什么事件,此外也可以了解用户的各种操作行为。因此,它可以为调查提供很多关键信息。

    二,打开事件查看器命令:eventvwr

    在这里插入图片描述
    Windows事件日志文件本质上是数据库,其中包括有关系统、安全、应用程序的记录

    记录的事件包含9个元素:日期/时间、事件级别、用户、计算机、事件ID、来源、任务类别、描述、数据等信息。

    在这里插入图片描述

    三,Windows事件日志共有五种事件级别

    所有的事件必须只能拥有其中的一种事件级别

    1.信息(Information)
    信息事件指应用程序、驱动程序或服务的成功操作的事件。
    2.警告(Warning)
    警告事件指不是直接的、主要的,但是会导致将来问题发生的问题。例如,当磁盘空间不足或未找到打印机时,都会记录一个“警告”事件。
    3.错误(Error)
    错误事件指用户应该知道的重要的问题。错误事件通常指功能和数据的丢失。例如, 如果一个服务不能作为系统引导被加载,那么它会产生一个错误事件。
    4. 成功审核(Success audit)
    成功的审核安全访问尝试,主要是指安全性日志,这里记录着用户登录/注销、对象访问、特权使用、账户管理、策略更改、详细跟踪、目录服务访问、账户登录等事件,例如所有的成功登录系统都会被记录为“成功审核”事件。
    5.失败审核(Failure audit)
    失败的审核安全登录尝试,例如用户试图访问网络驱动器失败,则该尝试会被作为失败审核事件记录下来。

    四,Windows日志文件

    从1993年的Windows NT3.1起,微软就开始使用事件日志来记录各种事件的信息。在NT的进化过程中,事件日志的文件名和文件存放位置一直保持不变,在Windows NT/Win2000/XP/Server 2003中, 日志文件的扩展名一直是evt,存储位置为“%systemroot%\System32\config”。

    从Windows Vista和Server 2008开始,日志文件的文件名、结构和存储位置发生了巨大改变, 文件扩展名改为evtx (XML格式),存储位置改为“%systemroot%\System32\WinEvt\logs”

    ri在这里插入图片描述
    1、系统日志
    记录操作系统组件产生的事件,主要包括驱动程序、系统组件和应用软件的崩溃以及数据。

    默认位置:
    Vista/Win7/Win8//Win10/Server 2008/Server 2012
    C:WINDOWS\system32\winevt\Logs\System.evtx

    2.应用程序日志
    包含由应用程序或系统程序记录的事件,主要记录程序运行方面的事件。

    默认位置:
    Vista/Win7/Win8//Win10/Server 2008/Server 2012
    C:\WINDOWS\system32\winevt\Logs\Application.evtx

    3.安全日志
    记录系统的安全审计事件,包含各种类型的登录日志、对象访问日志、进程追踪日志、特权使用、帐号管理、策略变更、系统事件。安全日志也是调查取证中最常用到的日志。默认安全性日志是关闭的,管理员可以使用组策略来启动安全性日志,或者在注册表中设置审核策略,以便当安全性日志满后使系统停止响应。

    默认位置:
    Vista/Win7/Win8//Win10/Server 2008/Server 2012
    C:\WINDOWS\system32\winevt\Logs\Security.evtx。

    1.安全日志:是渗透测试工作人员关注的重点
    虽然几乎所有事件记录在调查过程中都或多或少带来帮助,但是大多数的调查取证中,安全日志中找到线索的可能性最大。
    2.系统和应用程序日志存:储着故障排除信息,对于系统管理员更为有用。安全日志记录着事件审计信息,包括用户验证(登录、远程访问等)和特定用户在认证后对系统做了什么,对于调查人员而言,更有帮助。
    

    五,对常用安全事件的分析

    1.用户登录与注销

    场景
    .判断哪个用户尝试进行登录
    .分析被控制的用户的使用情况
    事件ID
    .4624登录成功
    .4625登录失败
    .4634/4647 一注销成功
    .4672使用超级用户(如管理员)进行登录

    2.追踪硬件变动

    场景
    .分析哪些硬件设备什么时间安装到系统中
    事件ID
    .20001 -即插即用驱动安装(System日志)
    .20003-即插即用驱动安装(System日志)
    .46636-移动设备访问成功(Securiy日志)
    .4656 -移动设备访问失败(Security日志)

    3.追踪WiFi信息

    场景
    .分析连接到的WiFi属性
    事件ID
    .10000-连接WiFi(networkprofile日志)
    .10001-断开WiFi(networkprofile日志)

    事件id10000

    六,日志获取和分析工具

    除了使用“事件日志查看器”外,我们也可以使用其他日志上具宣
    询事件日志。以下列举了一些我们经常用到的日志获取和分析工具

    .事件日志查看器
    . Microsoft LogParser
    . Log Parser Lizard

    七,分析事件的方法—筛查

    手动/脚本筛查

    1.利用PowerShell 来自动筛选 Windows 事件日志

    ①Get-WinEvent强大但发杂

     Get-WinEvent 超级强大,但使用起来比较麻烦

    Get-WinEvent -FilterHashtable @{Logname='system';Id='6006','6005'}
    

    在这里插入图片描述

    ②Get- EventLog简单但一般

     Get- EventLog 使得起来相当简单,

    Get-EventLog Security  -InstanceId  4624,4625
    

    在这里插入图片描述

    2.在powershell中对筛选出的Windows事件进一步处理

    ①用变量储存方便查看

    $events=Get-EventLog Security  -InstanceId  4624,4625
    

    例如
    在这里插入图片描述
    会发现有…显示不全–>用列表的形式
    ②用列表的形式查看全部信息

    $events[2]|fl *
    

    在这里插入图片描述

    七,分析日志的思路

    1.分析Windows登录类型

    ①登录类型

    登录类型2交互式登录(Interactive): 就是指用户在计算机的控制台上进行的登录,也就是在本地键盘上进行的登录。
    登录类型3:网络(Network): 最常见的是访问网络共享文件夹或打印机。另外大多数情况下通过网络登录IIS时也被记为这种类型,但基本验证方式的IIS登录是个例外,它将被记为类型8。
    登录类型4:批处理(Batch) :当Windows运行一个计划任务时,“计划任务服务”将为这个任务首先创建一个新的登录会话以便它能在此计划任务所配置的用户账户下运行,当这种登录出现时,Windows在日志中记为类型4,对于其它类型的工作任务系统,依赖于它的设计,也可以在开始工作时产生类型4的登录事件,类型4登录通常表明某计划任务启动,但也可能是一个恶意用户通过计划任务来猜测用户密码,这种尝试将产生一个类型4的登录失败事件,但是这种失败登录也可能是由于计划任务的用户密码没能同步更改造成的,比如用户密码更改了,而忘记了在计划任务中进行更改。
    登录类型5:服务(Service) :与计划任务类似,每种服务都被配置在某个特定的用户账户下运行,当一个服务开始时,Windows首先为这个特定的用户创建一个登录会话,这将被记为类型5,失败的类型5通常表明用户的密码已变而这里没得到更新。
    登录类型7:解锁(Unlock) :很多公司都有这样的安全设置:当用户离开屏幕一段时间后,屏保程序会锁定计算机屏幕。解开屏幕锁定需要键入用户名和密码。此时产生的日志类型就是Type 7。
    登录类型8:网络明文(NetworkCleartext) :通常发生在IIS 的 ASP登录。不推荐。
    登录类型9:新凭证(NewCredentials) :通常发生在RunAS方式运行某程序时的登录验证。
    登录类型10:远程交互(RemoteInteractive) :通过终端服务、远程桌面或远程协助访问计算机时,Windows将记为类型10,以便与真正的控制台登录相区别,注意XP之前的版本不支持这种登录类型,比如Windows2000仍然会把终端服务登录记为类型2。
    登录类型11:缓存交互(CachedInteractive) :在自己网络之外以域用户登录而无法登录域控制器时使用缓存登录。默认情况下,Windows缓存了最近10次交互式域登录的凭证HASH,如果以后当你以一个域用户登录而又没有域控制器可用时,Windows将使用这些HASH来验证你的身份。

    ②常见登录类型日志分析

    1、本地交互式登录,也就是我们每天最常使用的登录方式。
    首先是成功的登录,从日志分析来看至少会有2个事件发生,分别为ID4648、 4624。
    审核成功 2016/9/23 10:36:12 Microsoft Windows security auditing. 4648 登录
    审核成功 2016/9/23 10:36:12 Microsoft Windows security auditing. 4624 登录

    失败登录会产生ID为4625的事件日志。
    审核失败 2016/9/23 10:35:13 Microsoft Windows security auditing. 4625 登录

    2、使用RDP协议进行远程登录,这也是日常经常遇到的情况。
    使用mstsc远程登录某个主机时,使用的帐户是管理员帐户的话,成功的情况下会有ID为4648、4624、4672的事件产生。首先是成功登录, ID为4624,审核成功,登录类型为10(远程交互)。并且描述信息中的主机名(源工作站)仍为被尝试登录主机的主机名,而不是源主机名。
    审核成功 2016/9/23 16:57:55 Microsoft Windows security auditing. 4648 登录
    审核成功 2016/9/23 16:57:55 Microsoft Windows security auditing. 4624 登录
    审核成功 2016/9/23 16:57:55 Microsoft Windows security auditing. 4672 特殊登录

    使用不存在的用户名和错误密码分别登录失败,ID为4625,登录类型为10(远程交互)。审核失败,列出了登录失败的账户名和失败原因。

    3、远程访问某台主机的共享资源,如某个共享文件夹。
    首先是使用正确的用户名和密码访问远程共享主机,登录事件ID为4624, 登录类型为3(Network),审核成功。列出了源网络地址和端口。
    审核成功 2016/9/23 16:14:15 Microsoft Windows security auditing. 4624 登录

    如果访问共享资源使用的帐户名、密码正确,但是该用户对指定的共享文件夹没有访问权限时仍然会有ID为4624的认证成功事件产生。
    接下来的是事件ID为5140的文件共享日志,显示了访问的共享文件夹名称。
    审核成功 2016/9/23 16:14:15 Microsoft Windows security auditing. 5140 文件共享

    使用不存在的用户名和错误密码分别登录失败,ID为4625,登录类型为3(网络)。审核失败,列出了登录失败的账户名和失败原因。

    4、解锁登录
    解锁登录和远程登录一样,成功的情况下会有ID为4648、4624、4672的事件产生。首先是成功登录, ID为4624,审核成功,登录类型为7(Unlock)。
    审核成功 2016/9/23 16:28:41 Microsoft Windows security auditing. 4648 登录
    审核成功 2016/9/23 16:28:41 Microsoft Windows security auditing. 4624 登录
    审核成功 2016/9/23 16:28:41 Microsoft Windows security auditing. 4672 特殊登录

    使用不存在的用户名和错误密码分别登录失败,ID为4625,登录类型为7(unlock)。审核失败,列出了登录失败的账户名和失败原因。。

    最后我们总结一下“审计登录”事件:
    · 在进程尝试通过显式指定帐户的凭据来登录该帐户时生成4648事件。
    · 成功的登录通常会有4624事件产生,在创建登录会话后在被访问的计算机上生成此事件。
    · 如果用户有特权会有4672事件产生。
    · 通常情况下只需关注登录类型为2、3、7、10类型的4625登录失败事件。
    

    2.安全审核

    操作系统带有日志功能,系统审核机制可以对系统中的各类事件进行跟踪记录并写入日志文件。企业的网络管理员开启了服务器的部分安全审计功能后,可以根据需要实时地将发生在系统中的事件记录下来。可以通过查看与安全相关的日志文件的内容,来分析、查找系统和应用程序故障以及各类安全事件,发现黑客的入侵和入侵后的行为。

     审核事件ID
    审计目录服务访问
      4934 - Active Directory 对象的属性被复制
      4935 -复制失败开始
      4936 -复制失败结束
      5136 -目录服务对象已修改
      5137 -目录服务对象已创建
      5138 -目录服务对象已删除
      5139 -目录服务对象已经移动
      5141 -目录服务对象已删除
      4932 -命名上下文的AD的副本同步已经开始
      4933 -命名上下文的AD的副本同步已经结束
      审计登录事件
      4634 - 帐户被注销
      4647 - 用户发起注销
      4624 - 帐户已成功登录
      4625 - 帐户登录失败
      4648 - 试图使用明确的凭证登录
      4675 - SID被过滤
      4649 - 发现重放攻击
      4778 -会话被重新连接到Window Station
      4779 -会话断开连接到Window Station
      4800 – 工作站被锁定
      4801 - 工作站被解锁
      4802 - 屏幕保护程序启用
      4803 -屏幕保护程序被禁用
      5378 所要求的凭证代表是政策所不允许的
      5632 要求对无线网络进行验证
      5633 要求对有线网络进行验证
      审计对象访问
      5140 - 网络共享对象被访问
      4664 - 试图创建一个硬链接
      4985 - 交易状态已经改变
      5051 - 文件已被虚拟化
      5031 - Windows防火墙服务阻止一个应用程序接收网络中的入站连接
      4698 -计划任务已创建
      4699 -计划任务已删除
      4700 -计划任务已启用
      4701 -计划任务已停用
      4702 -计划任务已更新
      4657 -注册表值被修改
      5039 -注册表项被虚拟化
      4660 -对象已删除
      4663 -试图访问一个对象
      审计政策变化
      4715 - 对象上的审计政策(SACL)已经更改
      4719 - 系统审计政策已经更改
      4902 - Per-user审核政策表已经创建
      4906 - CrashOnAuditFail值已经变化
      4907 - 对象的审计设置已经更改
      4706 - 创建到域的新信任
      4707 - 到域的信任已经删除
      4713 - Kerberos政策已更改
      4716 - 信任域信息已经修改
      4717 - 系统安全访问授予帐户
      4718 - 系统安全访问从帐户移除
      4864 - 名字空间碰撞被删除
      4865 - 信任森林信息条目已添加
      4866 - 信任森林信息条目已删除
      4867 - 信任森林信息条目已取消
      4704 - 用户权限已分配
      4705 - 用户权限已移除
      4714 - 加密数据复原政策已取消
      4944 - 当开启Windows Firewall时下列政策启用
      4945 - 当开启Windows Firewall时列入一个规则
      4946 - 对Windows防火墙例外列表进行了修改,添加规则
      4947 - 对Windows防火墙例外列表进行了修改,规则已修改
      4948 - 对Windows防火墙例外列表进行了修改,规则已删除
      4949 - Windows防火墙设置已恢复到默认值
      4950 - Windows防火墙设置已更改
      4951 - 因为主要版本号码不被Windows防火墙承认,规则已被忽视
      4952 - 因为主要版本号码不被Windows防火墙承认,部分规则已被忽视,将执行规则的其余部分
      4953 - 因为Windows防火墙不能解析规则,规则被忽略
      4954 - Windows防火墙组政策设置已经更改,将使用新设置
      4956 - Windows防火墙已经更改主动资料
      4957 - Windows防火墙不适用于以下规则
      4958 - 因为该规则涉及的条目没有被配置,Windows防火墙将不适用以下规则:
      6144 - 组策略对象中的安全政策已经成功运用
      6145 - 当处理组策略对象中的安全政策时发生一个或者多个错误
      4670 - 对象的权限已更改
      审计特权使用
      4672 - 给新登录分配特权
      4673 - 要求特权服务
      4674 - 试图对特权对象尝试操作
      审计系统事件
      5024 - Windows防火墙服务已成功启动
      5025 - Windows防火墙服务已经被停止
      5027 - Windows防火墙服务无法从本地存储检索安全政策,该服务将继续执行目前的政策
      5028 - Windows防火墙服务无法解析的新的安全政策,这项服务将继续执行目前的政策
      5029 - Windows防火墙服务无法初始化的驱动程序,这项服务将继续执行目前的政策
      5030 - Windows防火墙服务无法启动
      5032 - Windows防火墙无法通知用户它阻止了接收入站连接的应用程序
      5033 - Windows防火墙驱动程序已成功启动
      5034 - Windows防火墙驱动程序已经停止
      5035 - Windows防火墙驱动程序未能启动
      5037 - Windows防火墙驱动程序检测到关键运行错误,终止。
      4608 -Windows正在启动
      4609 - Windows正在关机
      4616 - 系统时间被改变
      4621 - 管理员从CrashOnAuditFail回收系统,非管理员的用户现在可以登录,有些审计活动可能没有被记录
      4697 - 系统中安装服务器
      4618 - 监测安全事件样式已经发生

    展开全文
  • windows日志和审核

    千次阅读 2019-12-05 23:43:40
    windows事件日志简介 Windows事件日志记录着 Windows系统中发生的各类事件。通过事件日志,可以监控用户对系统的使用情况,掌握计算机在特定时间发生了什么事件,此外也可以了解用户的各种操作行为。因此,它可以为调查...

    windows事件日志简介

    Windows事件日志记录着 Windows系统中发生的各类事件。通过事件日志,可以监控用户对系统的使用情况,掌握计算机在特定时间发生了什么事件,此外也可以了解用户的各种操作行为。因此,它可以为调查提供很多关键信息。

    Windows事件日志文件本质上是数据库,其中包括有关系统、安全、应用程序的记录。记录的事件包含9个元素:日期/时间、事件级别、用户、计算机、事件1D、来源、任务类别、描述、数据等信息。

    Windows事件日志共有五种事件级别,所有的事件必须只能拥有其中的一种事件级别。

    1.信息( Information)

    信息事件指应用程序、驱动程序或服务的成功操作的事件。

    2.警告( Warning)

    警告事件指不是直接的、主要的,但是会导致将来问题发生的问题。例如,当磁盘空间不足或末找到打印机时,都会记录一个“警告”事件。

    3.错误(Error)

    错误事件指用户应该知道的重要的问题。错误事件通常指功能和数据的丢失。例如,如果一个服务不能作为系统引导被加载,那么它会产生一个错误事件。

    4.成功审核( Success audit)

    成功的审核安全访问尝试,主要是指安全性日志,这里记录着用户登录/注销、对象访问、特权使用、账户管理、策略更改、详细跟踪、目录服务访问、账户登录等事件,例如所有的成功登录系统都会被记录为“成功审核”事件。

    5.失败审核( Failure audit)

    失败的审核安全登录尝试,例如用户试图访问网络驱动器失败,则该尝试会被作为失败审核事件记录下来。


    Windows日志文件

    从1993年的 Windows N3.1起,微软就开始使用事件日志来记录各种事件的信息。在N的进化过程中,事件日志的文件名和文件存放位置一直保持不变,在Windows NT/win2000/XP/Server2003中,日志文件的扩展名一直是evt,存储位置为“% systemroot% \System32 config”。从Windows Vista和 Server2008开始,日志文件的文件名、结构和存储位置发生了巨大改变,文件扩展名改为evx(XML格式),存储位置改为“% systemroot% \System32\ WinEt\logs”。

    1.系统日志

    记录操作系统组件产生的事件,主要包括驱动程序、系统组件和应用软件崩溃以及数据。

    默认位置

    NT/Win2000/XP/Server 2003

    C: WINDOWS\system32\config\SysEvent Evt

    Vista/Win7/Win8//Win10/Server 2008/Server 2012

    C: WINDOWS\system32\winet \Logs\ System. evtx

    2.应用程序日志

    包含由应用程序或系统程序记录的事件,主要记录程序运行方面的事件。

    默认位置

    NT/Win2000/XP/Server 2003

    C:\WINDOWS\system32\config \AppEvent Evt

    Vista/Win7/Win8//Win10/Server 2008/Server 2012

    C:\WINDOWS\system32 winet \Logs \ Application. evtx

    3.安全日志

    记录系统的安全审计事件,包含各种类型的登录日志、对象访问日志、进程追踪日志、特权使用、帐号管理、策略变更、系统事件。安全日志也是调查取证中最常用到的日志。默认安全性日志是关闭的,管理员可以使用组策略来启动安全性日志,或者在注册表中设置审核策略,以便当安全性日志满后使系统停止响应。

    默认位置

    NT/Win2000/XP/Server 2003

    C:\ WINDOWS\system32\ config SecEvent Evt

    Vista/Win7/Win8//Win10/Server 2008/Server 2012

    C: WINDOWS\system32\ winet \Logs\ Security. evtx

    虽然几乎所有事件记录在调查过程中都或多或少带来帮助,但是大多数的调查取证中,安全日志中找到线索的可能性最大。

    系统和应用程序日志存储着故障排除信息,对于系统管理员更为有用。安全日志记录着事件审计信息,包括用户验证(登录、远程访问等)和特定用户在认证后对系统做了什么,对于调查人员而言,更有帮助。


    windows事件日志分析

    在 Windows7和 Windows Server2008R2中各种与安全和审核有关事件—用户登录与注销

    ■场景

    判断哪个用户尝试进行登录

    分析被控制的用户的使用情况

    ■事件ID

    4624-登录成功

    4625登录失败

    4634/4647-注销成功

    4672使用超级用户(如管理员)进行登录

    在 Windows7和 Windows Server2008R中的各种与安全和审核有关事件——追踪硬件变动

    ■场景

    分析哪些硬件设备什么时间安装到系统中

    ■事件ID

    20001-即插即用驱动安装( System日志)

    20003-即插即用驱动安装( System日志)

    4663-移动设备访问成功( Security日志)

    4656-移动设备访问失败( Security日志)

    在 Windows7和 Windows Server2008R2中的各种与安全和审核有关事件—无线网络位置

    ■场景

    分析系统访问过哪些关联的无线网络、VPN等

    ■事件ID

    10000-网络已连接

    10001-网络已断开连接

    筛选日志是分析事件日志最常用的功能,可以根据事件1D、事件级别、事件来源、用户、计算机等属性进行搜索和过滤。


    windows安全审计实战

    操作系统带有日志功能,系统审核机制可以对系统中的各类事件进行跟踪记录并写入日志文件。企业的网络管理员开启了服务器的部分安全审计功能后,可以根据需要实时地将发生在系统中的事件记录下来。可以通过查看与安全相关的日志文件的内容,来分析、查找系统和应用程序故障以及各类安全事件,发现黑客的入侵和入侵后的行为。

    配置审计策略

    1.选择【开始】=>【管理工具】→【本地安全策略】菜单,打开“本地安全设置”窗口。

    2.选择【安全设置】-【本地策略】=>【审核策略】,双击右侧的“审核对象访问”,在打对话框中选中“成功”和“失败”。

    3.单击确定按钮关闭窗口,配置结果如所示。

    配置访问文件夹的权限

    1.新建文件夹“C:\test”。

    2.右击文件夹“C:\test”,选择【属性】菜单,在打开的“审计属性”对话框中选择“安全”标签

    注销后,用lisi身份登录,在新建的test文件夹下,创建两个txt文件,并删除其中一个。

    然后注销,以管理员身份登录,在事件查看器,查找lisi,可以看到。

    展开全文
  • Windows日志文件

    千次阅读 2010-07-09 18:52:00
    日志文件,它记录着Windows系统及其各种服务运行的每个细节,对增强Windows的稳定和安全性,起着非常重要的作用。但许多用户不注意对它保 ...Windows日志包括应用程序、安全、系统等几个部分,它的存放

    日志文件,它记录着Windows系统及其各种服务运行的每个细节,对增强Windows的稳定和安全性,起着非常重要的作用。但许多用户不注意对它保 护,一些“不速之客”很轻易就将日志文件清空,给系统带来严重的安全隐患。

      一、什么是日志文件

      日志文件是Windows系统中一个比较特殊的文件,它记录着Windows系统中所发生的一切,如各种系统服务的 启动、运行、关闭等信息。Windows日志包括应用程序、安全、系统等几个部分,它的存放路径是 “%systemroot%system32config”,应用程序日志、安全日志和系统日志对应的文件名为AppEvent.evt、 SecEvent.evt和SysEvent.evt。这些文件受到“Event Log(事件记录)”服务的保护不能被删除,但可以被清空。

      二、如何查看日志文件

      在Windows系统中查看日志文件很简单。点击“开始→设置→控制面板→管理工具→事件查看器”,在事件查看器窗口左栏中列出本机包含的日 志类型,如应用程序、安全、系统等。查看某个日志记录也很简单,在左栏中选中某个类型的日志,如应用程序,接着在右栏中列出该类型日志的所有记录,双击其 中某个记录,弹出“事件属性”对话框,显示出该记录的详细信息,这样我们就能准确的掌握系统中到底发生了什么事情,是否影响Windows的正常运行,一 旦出现问题,即时查找排除。

      三、Windows日志文件的保护

      日志文件对我们如此重要,因此不能忽视对它的保护,防止发生某些“不法之徒”将日志文件清洗一空的情况。

      1. 修改日志文件存放目录

      Windows日志文件默认路径是“%systemroot%system32config”,我们可以通过修改注册表来改变它的存储目录, 来增强对日志的保护。

      点击“开始→运行”,在对话框中输入“Regedit”,回车后弹出注册表编辑器,依次展开 “HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/Eventlog”后,下面的 Application、Security、System几个子项分别对应应用程序日志、安全日志、系统日志。

      笔者以应用程序日志为例,将其转移到“d:/cce”目录下。选中Application子项(如图),在右栏中找到File键,其键值为应 用程序日志文件的路径“%SystemRoot%system32configAppEvent.Evt”,将它修改为 “d:cceAppEvent.Evt”。接着在D盘新建“CCE”目录,将“AppEvent.Evt”拷贝到该目录下,重新启动系统,完成应用程序日 志文件存放目录的修改。其它类型日志文件路径修改方法相同,只是在不同的子项下操作。 
    图片点击可放大

    Windows日志文件完全全解读 2. 设置文件访问权限

      修改了日志文件的存放目录后,日志还是可以被清空的,下面通过修改日志文件访问权限,防止这种事情发生,前提是Windows系统要采用 NTFS文件系统格式。

    右键点击D盘的CCE目录,选择“属性”,切换到“安全”标签页后,首先取消“允许将来自父系的可继承权限传播给该 对象”选项勾选。接着在账号列表框中选中“Everyone”账号,只给它赋予“读取”权限;然后点击“添加”按钮,将“System”账号添加到账号列 表框中,赋予除“完全控制”和“修改”以外的所有权限,最后点击“确定”按钮。这样当用户清除Windows日志时,就会弹出错误对话框。
     四、Windows日志实例分析

      在Windows日志中记录了很多操作事件,为了方便用户对它们的管理,每种类型的事件都赋予了一个惟一的编号,这就是事件ID。

      1. 查看正常开关机记录

      在Windows系统中,我们可以通过事件查看器的系统日志查看计算机的开、关机记录,这是因为日志服务会随计算机一起启动或关闭,并在日志 中留下记录。这里我们要介绍两个事件ID“6006和6005”。6005表示事件日志服务已启动,如果在事件查看器中发现某日的事件ID号为6005的 事件,就说明在这天正常启动了Windows系统。6006表示事件日志服务已停止,如果没有在事件查看器中发现某日的事件ID号为6006的事件,就表 示计算机在这天没有正常关机,可能是因为系统原因或者直接切断电源导致没有执行正常的关机操作。

      2. 查看DHCP配置警告信息

      在规模较大的网络中,一般都是采用DHCP服务器配置客户端IP地址信息,如果客户机无法找到DHCP服务器,就会自动使用一个内部的IP地 址配置客户端,并且在Windows日志中产生一个事件ID号为1007的事件。如果用户在日志中发现该编号事件,说明该机器无法从DHCP服务器获得信 息,就要查看是该机器网络故障还是DHCP服务器问题。进入讨论组讨论。


     

    展开全文
  • Windows日志浅析

    万次阅读 2012-02-01 17:50:47
    从这篇文章开始本人开始结合Windows产品日志分析大神(RANDY FRANKLINSMITH)的电子书,以及自己的实验对Windows操作系统的日志开始分析。... Windows日志从Windows2000版本后共包括9种审计策略,Windo
    从这篇文章开始本人开始结合Windows产品日志分析大神(RANDY FRANKLINSMITH)的电子书,以及自己的实验对Windows操作系统的日志开始分析。也是对自己的一种激励,至少希望自己能坚持下去这个分析。并且希望自己可以通过这个过程对于安全事件管理有更多的认识和理解,好了,废话不多说了,回归正题。 
    

        Windows日志从Windows2000版本后共包括9种审计策略,WindowsNT只有7种(此次没验证,懒得装NT虚拟机了)。共分为:帐户登录、登录、对象访问、目录服务访问、进程追踪、特权使用、帐户管理、策略变更、系统事件9大类。

        其中帐户登录其实是对登录用户的认证事件,据大神Randy自己说,称其为“认证事件“更为合适。登录事件记录的是用户登录到哪台PC的事件。对象访问记录的是用户对Windows对象的访问事件,这里对象包括注册表、服务、打印机、文件/文件夹等。目录服务访问就是对AD中所有对象的访问事件。进程追踪则为主机执行的程序事件,不管是由用户自己执行还是系统自动执行的。特权使用指用户使用分配的特权的事件,这里特权指在本地安全策略中分配给用户的权限。帐户管理则包含了本地帐户、用户组、DC中域用户、域用户组等对象的管理、密码设置等事件。策略变更指本地安全策略或DC上信任关系变化的事件。系统事件则涉及到一些安全事件的杂项,如系统的启动和关闭、系统事件修改等等。

        9类审计策略大概的介绍就到这里,在随后的文章中会分别具体地说明,自己也尽可能在Windows2003操作系统进行验证。


    在正式对每类事件进行分析前,先大概对windows的日志格式进行一个简单的介绍。

    每个windows日志都由两部分组成:头字段和描述字段。

    头字段是相对内容和格式都固定的部分,包括的信息有:事件的id、日期和时间、事件的结果(成功还是失败)、事件的来源和类别。由于安全日志所有的来源都记为“source”,因此意义不大。而类别就是(一)中提到的9种类别。这里的用户字段用处也不是很大,因为很多事件简单地记为“STSTEM”为用户,所以真正要看是什么用户触发了该条日志还是要看描述字段里面是否有相应的实际用户(这些在随后的日志分析中会涉及到)。

    因此很多时候我们需要详细分析描述字段中的信息,这部分出现的信息也会随具体的事件而不同,但是其形式都是为一系列组合信息,每个组合信息是一个内容固定的描述信息(类似占位符的作用),以及后面的动态信息。举个例子来说:ID680事件的描述字段包括:“Logonaccount: Administrator”。这里“Logonaccount:”是固定的前置字段占位符,而后面的“Administrator”则是真实的实例名称,会根据实际的情况而变化。

    我们可以打开本地的一条日志,点击描写字段部分的蓝色链接,联网的情况下可以查看到微软的支持中心中对该条日志的详细说明,其中的Message字段通常为以下的内容,很容易看到ID为567的这条日志的描述字段包括7个字段信息,说明其中有7个变量存在,其内容由实际情况生成。

    Object Access Attempt:
    Object Server: %1
    Handle ID: %2
    Object Type: %3
    Process ID: %4
    Image File Name: %5
    Accesses: %6
    Access Mask: %7

    因此从上面可以看到很多关键的信息其实都隐藏在描述字段信息中,需要进行仔细地分析!

    最后再简单地说下windows自身存储策略的设置:根据Randy大神的经验,最大不要超过199M,200M的话可能会对windows的性能和稳定性有一定影响(这点不好进行实验验证)。此外不论配置最大空间为多少,迟早会有满的时候。所以Randy建议选择“不改写事件(手动地清除)”选项,此时一旦日志大小达到上限,windows会停止记录事件。当选择“改写久于X天的事件“时,如果事件的产生速度很快,在未过期前就达到了上限,windows同样是停止记录日志直到某些日志过期。以下是网上对于这些保存设置的说明和建议,所以如何设置也是在安全性、易维护性等方面权衡了。

    按需要改写事件当日志已满时继续写入新的事件。每个新事件替换日志中时间最旧的事件。该选项对维护要求低的系统是一个不错的选择。
    改写久于 [x]天的事件保留位于指定改写事件的天数之前的日志。默认值为 7天。如果您想每周存档日志文件,该选项是最佳选择。该策略将丢失重要日志项的几率降到最小,同时保持日志的合理大小。
    不改写事件手动而不是自动清除日志。只有在您无法承受丢失事件时才选中该选项(例如,特别强调安全性的站点的安全性日志)。

     

    最后我们还可以把日志事件另存为本地文件查看,其中txt和csv格式可以较为方便地直接查看,而evt格式需要专门的软件来查看,如LogParser。因此在日志量很多的情况下,还是建议由专门的日志管理产品来完成此功能。

    ok,一些情况就简单介绍到这里,下面开始对每类事件进行较为详细的分析,Let’s go!


    ok,从本篇终于要开心对windows日志进行分析了,首先从最基本的登录活动开始。这也是任何日志分析最基础的开始,涉及到对用户活动的分析,总要从登录开始咯。等等,在开始这激动人心的时刻之前,我们还是想讲清楚windows登录活动的一些原理,然后再分析相关的日志也不迟:)

    从windows2000开始,审核策略选项里面涉及到登录的有两项:分别是“审核帐户登录事件”和“审核登录事件”。那么有些人可能不太明白了,为什么用户的登录要有两类事件来记录呢?ok,这里简单的解释一下(来自Randy大神,具体有待考证)。

    在windows2000之前,例如NT的时候windows系统只审核登录事件。这样如果使用域帐户登录某台工作站的话,域控服务器(DC)上是没有该用户的登录记录的,只会记录在被访问的工作站上(当然前提是工作站开启了登录审核)。因此DC不记录域用户的认证活动使得想要对域用户的登录活动进行监控十分困难,得收集整个网络中所有工作站和服务器的安全日志。因此呢,微软从windows2000开始增加了一个新的特色功能,也就是“审核帐户登录事件”。但是这个叫法与原来的“审核登录事件”很像,容易让人产生混淆。因此Randy大神认为称之为“审核认证事件”更为恰当!也就是说在windows中认证和登录活动是相关但是不同的两个活动,特别是在它们发生在不同的系统上时表现更为明显!

    因此想要有效地使用这两个审计策略,需要很好地理解相关的原理,明白在windows系统中认证和登录是如何发生的。另一个容易让人混淆的是登录使用帐户的类型,是本地还是域帐户,因为这会影响到什么事件记录在哪些系统上。接下来就对windows帐户类型简单介绍下。

    windows系统支持两种帐户类型:域帐户(存储在AD中)和本地帐户(存储在本地的SAM文件中)。这样的话也很简单了,使用域帐户登录的话,由DC来完成对用户的认证;如果本地帐户登录的话则由要登录的工作站自己来完成认证。所以需要特别关注使用本地帐户的登录活动,因为攻击者通常会使用本地帐户来进行登录尝试。

    接下来我们看看windows的登录方式都有哪些。

        windows一共支持5种登录会话类型,都分别描述了用户如何登入系统的方式。本地和域帐户都支持这5种类型。每种登录类型有一个对应的登录权限。登录帐户的类型和登录的方式都会影响到审核日志的具体内容和事件ID,每种类型及其权限如下表所示:

    登录类型登录权限典型情况
    本地交互式:使用本地的控制台登录本地登录使用域或者本地帐户登录本地主机
    网络方式:从网络上的某个主机访问windows资源从网络访问主机例如访问一台主机的某个共享文件夹
    远程交换式:通过远程桌面、终端服务或远程帮助登录某个远程主机运行通过终端服务登录使用本地mstsc客户端远程登录某台主机
    批作业:用于作为一个指定的帐户来运行一个计划任务作为批作业登录指定计划任务时指定的以某个具体帐户来运行
    服务方式:用于以指定的帐户来运行某个服务以服务方式登录指在指定服务运行时以本地系统帐户或者是具体某个帐户运行

    当我们尝试网络登录登录时,比如访问某台主机的共享文件夹,工作站默认会再次使用用户登录时输入的凭证。但是用户也可以指定一个不同的本地或者域帐户,例如映射本地磁盘到某个共享文件夹时。

    登录VS认证小结

    因此,在windows中登录和认证是关联但是不同的两个活动。简言之登录活动发生在最终被访问的主机上,认证活动发生在存储用户帐户的主机上。也就是如果使用本地帐户登录某台主机,该主机同时“看到”认证和登录活动。如果是使用域帐户登录,那么DC可以“看到”认证活动,而被访问的真实主机只“看到”登录活动。

    所以“审计帐户登录事件”是主要用于DC上的审计策略,但是在成员工作站上也有用,可以辨识对本地帐户的攻击。

    既然通常DC来完成域帐户的认证,那么就会涉及到windows系统支持的2种认证协议:NTLM和Kerberos。

    NTLM VSKerberos

    当用户使用域帐户登录windows2000及之后版本的操作系统时,工作站首先会尝试通过Kerberos协议联系DC。(如果系统没收到响应的话,会回退使用NTLM)。并且Widows2000及之后的版本使用不同的事件ID记录NTLM和Kerberos活动,所以比较容易区分。由于Kerberos提供了客户端和服务器间的双向认证(NTLM只支持客户端向服务器的认证)。并且NTLM的安全性较Kerberos弱一些,更容易被嗅探数据包进行破解。而且如果外部的攻击者攻击某个域的帐户,通常会看到NTLM认证事件,而不是Kerberos。因为他们不是本域的成员或信任域,登录尝试会使用NTLM。

    NTLM和Kerberos协议的工作机理这里暂时不详细说明了,而且由于自己目前对域这一块不是很熟悉,暂且跳过使用域帐户登录方式的日志分析,先从本地用户方式的认证开始。以后有机会再搭建域的实验环境,然后进行使用域帐户的登录活动分析。


    ok,终于开始要真枪实干地分析日志了,首先我们对“审计帐户登录事件”下手,也就是用户的认证事件。这里暂时只考虑使用本地帐户进行登录,不包括域用户。以后搭建起来实验环境,对域也比较熟悉后再补上这一课。这里为了排除干扰,每次实验前均清除日志,且只开启要分析类别事件的审计功能。

    此次实验均使用windows2003,其它版本的windows系统事件ID和描述可能会有一些出入。

        前面已经说过了,windows有5种帐户登录方式,所以我们一个个来看。

    1、本地交互式登录,也就是我们每天最常使用的登录方式。如果成功登录的话,会产生ID为680的事件,

    2

    如上图所示,我们从中可以获取到的有用信息有:认证事件的时间、结果为成功(审核成功)、登录帐户为“administrator”、(描述中的部分)、被登录的主机名(WIN2003)。接下来看看登录失败是什么记录,这里第1次使用不存在的用户名登录、第2次使用正确的用户名但是错误密码。

         21

    从日志中我们可以很遗憾地看到,虽然是登录失败事件,但是事件ID仍然是680(windows2000失败事件ID为681,Windows2003把成功和失败事件都标识为ID680)。但是类型为“审核失败”,并且头字段中的用户名由原来的“Windows2003\Administrator”变成了“NTAUTHORITY\SYSTEM”。描述信息中的登录帐户记录了尝试登录使用的真实用户名,错误代码也会根据认证失败的原因而变化。据微软的说明,每种错误代码对应的原因如下表格:

    0xC000006AAnincorrect password was supplied
    0xC000006FTheaccount is not allowed to log on at this time
    0xC0000064Theaccount does not exist
    0xC0000070Theaccount is not allowed to log on from this computer
    0xC0000071Thepassword has expired
    0xC0000072Theaccount is disabled

     

    2、使用RDP协议进行远程登录,这也是日常经常遇到的情况。

    首先是成功登录,如下图所示,从中可以看到ID仍为680,并且与本地登录没有任何明显区别。并且描述信息中的主机名(源工作站)仍为被尝试登录主机的主机名,而不是源主机名。然后使用不存在的用户名和错误密码分别登录失败1次,产生的日志与第1种一样,所以不再附图。

    2

    3、远程访问某台主机的共享资源,如某个共享文件夹。

    首先是使用正确的用户名和密码访问远程共享文件夹,如下图所示。从中可以发现头字段和描述字段中的用户名都为访问共享文件夹时使用的用户名,并且描述信息中的源工作站名也为发出访问共享文件夹请求的主机的真实主机名,与头字段中的计算机名字段的主机名不同

    1

    这里说明一下,当访问某个主机的共享资源时,例如在点击“开始—运行”后输入“\\192.168.10.1\share”时,Windows默认使用当前登录的凭证去访问共享资源,如果当前凭证的用户名在被访问主机上不存在或者密码不一致时会产生多条“审核失败”事件,如下图所示。并且会在描述字段中记录真实的用户名和主机名,同样会有错误代码。

    2

    此外,如果访问共享资源使用的帐户名、密码正确,但是该用户对指定的共享文件夹没有访问权限时仍然会有ID为680的认证成功事件产生。

    4、创建任务计划,并指定以某个用户来执行。

    首先使用正确的用户名和密码创建一个任务计划,在该任务计划完成后同样会看到“帐户登录”成功事件,如下图所示。

    1                  2

    从图中可以看到头字段中的用户名和描述字段中的用户名都是创建任务计划时指定的有效用户。

    如果创建任务计划时输入错误密码,则无法创建任务计划,并且会有“帐户登录”失败日志生成,如右图所示,和一般的认证失败事件没有区别。但奇怪的是使用无效的用户名创建任务计划时没有“帐户登录”失败日志生成。

    5、以服务方式运行

    启用某个服务,并指定以某个帐户运行。这里同样先使用正确的用户名和密码设置服务,然后手工方式启动服务。可以看到有“帐户登录”的成功事件,如下图所示。从图中可以看到头字段中的用户名和描述字段中的用户名都是开启服务时指定的特定用户。这里说明一下,实验时以某特定用户启动服务但报错,但是会有成功认证的事件生成。如果指定用户为系统默认的“NTAUTHORITY\NetworkService”或“NTAUTHORITY\LocalService”来运行,则密码随意输入也可正常启动服务。且不会有认证事件的日志生成。

    1

    如果指定以某特定帐户运行时输入的无效密码,则在服务启动时会报错,且会有“帐户登录”的失败事件生成,如下图所示:

    2

    从图中可看到头字段的用户是“SYSTEM”,描述信息中的登录帐户字段才是真正的用户名,并且错误代码指明失败原因是密码错误。

       最后我们总结一下,共有5种方式登录Windows主机进行身份认证,分别是:本地交换、远程访问、资源共享访问、任务计划和服务运行。并且从这些日志中我们也可看到有用的信息并不是很多,所以需要配合“登录/登出“事件来一起分析用户的登录行为。ok,那么在下一篇文章我们开始分析“登录/登出“日志,看看它们能否提供更多的信息给我们。


    上一篇文章简单分析了用户登录时的认证事件,接下来我们再来看看和之紧密关联的登录/登出事件。

    总体来看,登录/登出事件对可以很好地追踪用户在一台主机上完整活动过程的起至点,和登录方式无关。此外可以提供一些“帐户登录”没有的信息,例如登录的类型。此外对终端服务的活动专门用两个事件ID来标识。ok,我们开始分析,同样从5种类型分别进行分析。

    1、本地方式的登录和登出

    Randy大神在书中只提到了Windows使用两个事件ID528和540记录用户成功的登录(后者对应网络类型的登录),登出使用ID530。然而事实上同时发生的事件不只限于这些,那么让我们来看看用户简单的登录和登出活动至少会触发那些事件。

    首先是成功的登录,从日志分析来看至少会有2个事件发生,分别为ID552和528,以下从左到右分别是各自的截图。

    1   2      

    现在来各种进行详细分析,首先是ID552事件,该事件说明有人使用身份凭据在尝试登录,并且头字段中的用户名为SYSTEM。看看描述信息中有什么好东西:

    使用明确凭据的登录尝试:   (说明有人在尝试登录)
    登录的用户:
         用户名:   WIN2003$    (主机名加了$后缀)
        域:       WORKGROUP   (主机的域名,此例中主机在名称为“WORKGROUP”的工作组中)
         登录ID:       (0x0,0x3E7)
         登录 GUID:   -
    凭据被使用的用户:
         目标用户名:   Administrator    (登录使用的用户名)
         目标域:   WIN2003          (要登录的主机名)
         目标登录 GUID:-

    目标服务器名称:   localhost
    目标服务器信息:    localhost
    调用方进程 ID:    1612
    源网络地址:   127.0.0.1       (从IP地址很容易判断是本地登录)
    源端口:    0

    这里有一点要说明一下,Windows对这条日志的解释是“一个已登录的用户尝试使用另外一个用户凭证创建登录会话,例如使用“RUNAS”命令来运行某个可执行文件”。但事实上第1次用户成功登录后也会产生这个事件。

    接着是ID528事件,此时头字段中的用户名也变成真实的用户名,看看描述信息中有什么东西:

    登录成功:       (说明用户已成功登录)
        用户名:    Administrator    (登录使用的用户名)
        域:        WIN2003           (被登录主机所属的域的域名,如果不在域中为主机名)
         登录ID:        (0x0,0x37BF9)    
    (此登录ID在计算机重启前会保持其唯一性,重启后可能会被再次使用。该ID很重要,因为可以关联用户随后的很多活动如对象访问!)
        登录类型:        (各种类型含义及数字见后面的表格)
        登录进程:     User32 
        身份验证数据包:     Negotiate
         工作站名:   WIN2003     (记录发起登录请求的计算机的Netbios名)
         登录 GUID:   -
         调用方用户名:   WIN2003$
         调用方域:   WORKGROUP
         调用方登录ID:    (0x0,0x3E7)   
    注意,此ID和ID552事件描述信息的登录ID是一样的)
        调用方进程 ID: 1612
         传递服务: -
         源网络地址:   127.0.0.1   (同样从IP地址很容易判断是本地登录)
         源端口:   0

       有意思的事情发生了,ID528事件的调用方登录ID和和ID552的登录ID是一样,那么我们能不能做个大胆的猜想呢?在本地登录成功前,系统本身先已创建了登录会话,然后此会话再创建真实的用户会话。呵呵,只是随便猜猜而已。

    登录类型对应含义如下表,上篇文章中常见5种登录方式对应数字分别为2、3、4、5、10。

    登录类型ID

    登录方式

    描述信息

    2

    Interactive

    A user logged on to this computer at theconsole

    3

    Network

    A user or computer logged on to this computerfrom the network

    4

    Batch

     

    Batch logon type isused by batch servers, where processes might run on behalf of auser without the user's direct intervention

     

    5

    Service

    A service was startedby the Service Control Manager

    7

    Unlock

     

    This workstation was unlocked

     

    8

    NetworkCleartext

    A user logged on to a network and theuser password was passed to the authentication package in itsunhashed (plain text) form. It is possible that the unhashedpassword was passed across the network, for example, when IISperformed basic authentication

     

    9

    NewCredentialsA caller (process, thread, or program)cloned its current token and specified new credentials for outboundconnections. The new logon session has the same local identity, butit uses different credentials for other network connections.
    10RemoteInteractiveA user logged on to this computerremotely using Terminal Services or a Remote Desktopconnection.
    11CachedInteractiveA user logged on to this computer withnetwork credentials that were stored locally on the computer. Thedomain controller was not contacted to verify the credentials

     

    此外,如果登录的用户名有某些权限(通过”本地安全策略“分配给该用户),在用户成功登录时还会有ID576事件发生,如下图所示:

    3

    描述信息如下:

    指派给新登录的特殊权限:
         用户名:   Administrator
        域:       WIN2003
         登录ID:       (0x0,0x37BF9)
         特权:   SeSecurityPrivilege
               SeBackupPrivilege
               SeRestorePrivilege
               SeTakeOwnershipPrivilege
               SeDebugPrivilege
               SeSystemEnvironmentPrivilege
               SeLoadDriverPrivilege
               SeImpersonatePrivilege

    从描述信息中我们可以看到名称为“Administrator”的用户所拥有的权限列表。

    接下来看看失败的本地登录,首先是无效用户名、其次是有效用户名但是错误密码。

    1    2

    从图中可以看到,登录失败后会有ID529的事件产生。并且两者头字段的信息没有什么区别,用户名都是“SYSTEM”。那么看看描述信息中有什么信息和区别。

    登录失败:
        原因:       用户名未知或密码错误
         用户名:   test1 
        域:       WIN2003
         登录类型:   2
         登录进程:   User32 
         身份验证数据包:   Negotiate
         工作站名称:   WIN2003
         调用方用户名:   WIN2003$
        调用方域:    WORKGROUP
         调用方登录ID:    (0x0,0x3E7)
         调用方进程ID:     1100
        传递服务:     -
         源网络地址:   127.0.0.1
         源端口:   0

    登录失败:
        原因:       用户名未知或密码错误
         用户名:   administrator
        域:       WIN2003
         登录类型:   2
         登录进程:   User32 
         身份验证数据包:   Negotiate
         工作站名称:   WIN2003
         调用方用户名:  WIN2003$
        调用方域:    WORKGROUP
         调用方登录ID:    (0x0,0x3E7)
         调用方进程ID:     1100
        传递服务:     -
         源网络地址:   127.0.0.1
         源端口:   0

    从描述信息可以看到两者没有什么区别,唯一不同的是用户名,并且登录失败原因都一样。登录类型同样给出了用户登录的方式,为本地登录(数字为2)。有意思的是调用方用户名也是“主机名+$”的形式。

    用户正常注销登出的话,也不是简单的一个事件。事实上会有2个事件产生,ID分别为551和538。截图如下:

    1       2

    看来微软在这点做得够细致了,先会有ID551事件说明有用户要求注销,接着ID538事件说明用户已成功注销。从头字段和描述信息中都可以看到真实的用户名,登录ID,并且ID538事件还包括用户的登录方式。微软的官方解释中有这样的说明:“ID551事件说明用户发起注销请求,因此包含用户的安全信息和允许用户访问对象的主要访问令牌会从内存中擦除。因此在令牌擦除后用户无法访问资源如文件、注册表。当注销过程完成后ID538事件产生。如果ID538事件没有在551事件后出现,一个程序或服务可能没有正确地管理访问令牌。尽管用户无法访问对象,这个程序或服务可能有缓存的访问令牌并保留访问对象的能力”。

    2、远程方式的登录和登出

    使用mstsc远程登录某个主机时,使用的帐户是普通用户的话(没有分配该用户任何权限)成功的情况下会有ID为552、528的事件产生,没有ID576事件。

    1             2

    这2个事件的头字段和本地方式基本没有什么区别,看看描述信息有什么不一样的地方:

    使用明确凭据的登录尝试:
    登录的用户:
         用户名:   WIN2003$
        域:       WORKGROUP
         登录ID:       (0x0,0x3E7)
         登录 GUID:   -
    凭据被使用的用户:
         目标用户名:   rdp
         目标域:   WIN2003
         目标登录 GUID:-

    目标服务器名称:   localhost
    目标服务器信息:    localhost
    调用方进程 ID:    1984
    源网络地址:  192.168.10.2
    源端口:   1035

    登录成功:
        用户名:     rdp
        域:        WIN2003
         登录ID:        (0x0,0x4C715)
         登录类型:   10
        登录进程:     User32 
        身份验证数据包:     Negotiate
         工作站名:   WIN2003
         登录 GUID:   -
         调用方用户名:   WIN2003$
         调用方域:   WORKGROUP
         调用方登录ID:    (0x0,0x3E7)
         调用方进程 ID: 1984
         传递服务: -
         源网络地址:   192.168.10.2
        源端口:  1035

    从这里可以看出至少有3个地方不一样,首先登录类型的ID为10,说明是远程交互式登录,其次是源网络地址和源端口。如果有防火墙的日志的话,可以进行关联分析。

    登录失败同样分别使用无效用户名和有效用户名、无效密码2种方式,结果都是产生ID529事件,与之前也没有什么区别。描述信息如下:

    登录失败:
        原因:       用户名未知或密码错误
         用户名:   rdp
        域:       WIN2003
         登录类型:   10
        登录进程:    User32 
         身份验证数据包:   Negotiate
         工作站名称:   WIN2003
         调用方用户名:   WIN2003$
         调用方域:   WORKGROUP
         调用方登录ID:    (0x0,0x3E7)
         调用方进程ID:     2640
        传递服务:     -
         源网络地址:   192.168.10.2
        源端口:    1040

    从信息中可以看到,唯一不同且有价值的是登录类型的ID、源IP地址和源端口。

    用户注销的话同样会有ID551和538事件产生,与本地登录一样(除了登录类型的数值),因此不再附图说明。但是ID538事件产生时间会比551晚一点,做了几次实验有1分30秒、2分多都有,似乎不是固定的值。

       如果使用RDP远程登录主机后,没有注销而是直接点×关闭窗口,会产生ID683事件,如果再次使用该用户和密码连接时,会产生ID682事件,截图分别如下:

    1     2

    从描述信息中可以很清楚地看到会话中断和重新连接的事件,此时登录ID都一样,但是会话名称已经发生变化。

      另外一种远程访问方式为远程协助,也会产生ID552、528、551和538事件(会伴随用户名为“ANONYMOUSLOGON”的成对ID540和538事件)。只是其中的真实用户名变成“HelpAssistant_abae4f”,其中的“abae4f”不知道是不是随机生成,反正我做了2次实验都是这个。

    3、网络访问的登录和登出

     这里访问共享文件夹的情况根据不同的情况会有几种不同的事件模式产生,分别进行说明。

    这里先假设主机A上C盘目录下有名为“share”的文件夹,开启网络共享并且权限为A主机上的名为“rdp”的用户。架设B主机上也有名为“Administrator”的管理员和名为“rdp”的用户。

    a、没有给A主机上的”rdp“用户赋予任何权限,设置B主机的rdp用户和A主机上的密码一致,以rdp用户登录B主机,然后以在运行中输入“\\192.168.10.1\share”的方式访问A主机的共享文件夹,然后关闭共享文件夹窗口。此时在A主机上会有事件模式为:有用户名为“rdp”的ID为540和538的事件产生(注意:此时登录时没有ID552事件),如下图所示:

    1     2

    这些登录、登出事件的头字段中用户名均为rdp,但是计算机名还是被访问的主机名。现在看看ID540事件的描述信息:

    成功的网络登录:
         用户名:   rdp
        域:       WIN2003
         登录ID:       (0x0,0x75BCF)
         登录类型:   3
         登录过程:   NtLmSsp
         身份验证数据包:   NTLM
        工作站名:   WIN2K3
         登录GUID:    -
         调用方用户名:   -
         调用方域:   -
         调用方登录ID:    -
         调用方进程 ID: -
         传递服务: -
         源网络地址:   192.168.10.2
         源端口:   0

    从中我们可以发现除了登录类型变为“3”以为,身份验证数据包也变为“NTLM”,并且工作站的名称也是发出访问共享文件夹请求的B主机的真实主机名(这里让我很奇怪的是使用RDP方式访问时工作站名仍为被访问主机的主机名)。

    除了上述2个事件外,在用户成功登录同时还会有用户名为“ANONYMOUSLOGON”的2个事件,ID也同样分别为:540和538,并且没有时间间隔,如下图所示:

    1       2

    ID540事件的描述信息如下。

    成功的网络登录:
        用户名:   
        域:       
         登录ID:       (0x0,0x75BE1)
         登录类型:   3
         登录过程:   NtLmSsp
         身份验证数据包:   NTLM
         工作站名:   WIN2K3
         登录 GUID:   -
         调用方用户名:   -
         调用方域:   -
         调用方登录ID:    -
         调用方进程 ID: -
         传递服务: -
         源网络地址:   192.168.10.2
         源端口:   0

    b、没有给A主机上的”rdp“用户赋予任何权限,设置B主机的rdp用户和A主机上的密码一致,以rdp用户登录B主机,然后以在运行中输入“\\192.168.10.1”的方式访问A主机的共享资源。此时在只弹出A主机共享资源窗口的情况下,A主机上会有2组ID540和538事件产生。如果此时双击某个共享文件夹,同样会有2组ID540和538事件产生。中间会有用户名为“ANONYMOUSLOGON”的ID540和538事件。如果A主机共享了多个文件夹,那么在B主机上A主机在不同的文件夹和A主机共享资源窗口之间来回切换的情况下会有大量的ID540和538事件产生!

    c、设置B主机上的rdp用户密码与A主机不一样,然后以用户rdp登录B主机,然后以“\\192.168.10.1\share”的方式访问A主机的共享文件夹,此时会弹出窗口让用户输入A主机上可以访问该文件夹的用户名和密码。此时A主机上会有很多登录失败的ID529事件,以及成对出现的ID540和538出现,如下图所示:

    1

    此时在窗口输入正确的用户名和密码,产生用户名为rdp的ID540事件,同样关闭共享窗口后会有ID538事件。

    如果输入无效的用户名或密码,同样在A机上会产生如上图所示的大量ID529和成对的ID540、538事件。

    最后,如果A主机上的rdp用户有已分配的特权,那么成功访问共享文件夹时同样会有ID576事件产生。

    4、以任务计划的方式登录

     如果使用正确的用户名和密码创建任务计划时,系统会用提供的用户名和密码进行登录尝试。因此至少会有ID552、528和538事件产生(即瞬时的登录并登出),并且528和538事件的登录类型为4。如果指定的用户具有特权还会有ID576事件产生。在该任务计划执行时也会有一系列事件产生。如果使用无效用户名和密码创建任务计划,则会失败并且产生ID529事件。其描述性信息如下:

    登录失败:
        原因:       用户名未知或密码错误
         用户名:   Administrator
        域:       WIN2003
         登录类型:   4
         登录进程:   Advapi
         身份验证数据包:   Negotiate
         工作站名称:   WIN2003
         调用方用户名:   WIN2003$
         调用方域:   WORKGROUP
         调用方登录ID:    (0x0,0x3E7)
         调用方进程ID:     1648
        传递服务:     -
         源网络地址:   -
         源端口:   -

    5、以服务方式运行

       使用有效的用户名和密码指定服务并启动时,也会有ID552、528和538事件(576事件看用户是否有特权)。主要的区别也是登录类型为5,其它基本一致。下面是ID528事件的描述性信息:

    登录成功:
        用户名:     rdp
        域:        WIN2003
         登录ID:        (0x0,0x4E51C)
        登录类型:    5
        登录进程:     Advapi 
        身份验证数据包:     Negotiate
         工作站名:   WIN2003
         登录 GUID:   -
         调用方用户名:   WIN2003$
         调用方域:   WORKGROUP
         调用方登录ID:    (0x0,0x3E7)
         调用方进程 ID: 1224
         传递服务: -
         源网络地址:   -
         源端口:   -

    如果使用无效的用户名或密码指定服务时,在启动服务时会报错并且产生ID529事件。

        最后我们总结一下“审计登录”事件:

    • 成功的登录通常会有528事件产生,如果用户有特权会有576事件产生;如果是访问网络共享资源的方式没有552事件,其它4种类型都有。
    • 比“帐户登录”包含更多的信息,如源IP、端口、登录类型ID,成功登录用户是否有对应的特权等等。
    • 通常情况下只需关注登录类型为2、3、10类型的登录失败事件。
    ok,对用户的认证和登录过程的分析暂以告一段落,现在就开始我们最为关注的部分,用户登录上计算机上后到底做了什么操作?从本节开始我们就开始详细地分析用户的活动,先从“过程追踪”开始,因为这类事件可以和用户的登录活动关联起来(就是之前我们谈到过的登录ID)。过程追踪还能够对服务的安装、移除以及计划任务的维护进行监控。

       首先从进程的追踪开始,Windows提供了2个事件ID来追踪一个进程的开启和结束,分别是592和593。当一个新的进程创建后会有ID592事件产生,当进程退出后会有593事件产生。截图如下:

    1     2

    从中我们可以看到是哪个用户,在什么时间、执行了什么程序,该程序的完整路径名。其中需要我们关注的是登录ID字段,因为可以和用户的登录行为进行关联。同时我们也可以注意到,新创建的进程ID和退出进程ID都为2232,而创建该进程的进程ID为424,当时看了一下任务管理器,为explorer.exe进程。

       接着是服务的安装和任务计划的创建。Windows2003使用ID601事件记录服务安装的活动,无论其成功还是失败。可以用于发现被安装的新服务。但是软件的安装并不产生该事件,而且木马或后门程序也很少以服务方式安装,因此价值不会很大。其截图如下:

    1 

    描述信息为:

    尝试安装服务:
         服务名称:   OpenVPNService
         服务文件名称:   C:\Program Files\OpenVPN\bin\openvpnserv.exe
         服务类型:   16
         服务启动类型:   3
         服务帐户:   LocalSystem
    由:
         用户名称:   Administrator
        域:       WIN2003
         登录ID:       (0x0,0x1CA46)

    从描述信息中可以看到要安装服务的名称(可以在命令行使用“sc qurey服务名称”的方式查询服务当前的状态),该服务对应的可执行文件。

    服务类型的表格如下:

    服务类型名称
    0x2SERVICE_FILE_SYSTEM_DRIVER
    0x4SERVICE_ADAPTER
    0x8SERVICE_RECOGNIZER_DRIVER
    0xBSERVICE_DRIVER
    0x10SERVICE_WIN32_OWN_PROCESS
    0x20SERVICE_WIN32_SHARE_PROCESS
    0x30SERVICE_WIN32
    0x100SERVICE_INTERACTIVE_PROCESS
    0x110SERVICE_INTERACTIVE_OWN_PROCESS
    0x120SERVICE_INTERACTIVE_SHARE_PROCESS

     

    服务启动类型表格如下:

    服务启动类型名称显示类型
    0x1SYSTEM_STARTn/a
    0x2AUTO_STARTAutomatic
    0x3DEMAND_STARTManual
    0x4DISABLEDDisabled

     

    关于服务帐户的详细说明请参见微软官方链接:

    http://technet.microsoft.com/zh-cn/library/aa998749(EXCHG.65).aspx

        创建任务计划或者是修改已有的任务计划时会触发ID602事件,其截图如下:

    1

      描述信息为:

    已创建的计划任务:
         文件名:   C:\WINDOWS\Tasks\屏幕键盘.job
         命令:   C:\WINDOWS\system32\osk.exe
        触发器:       2010-4-14,23:51.
        时间:       1700-1-1 8:00:00
        标记:       0x1C000C0
         目标用户:   WIN2003\Administrator
    由:
        用户:       Administrator
        域:       WIN2003
         登录ID:       (0x0,0x1CA46)

      从中可以看到创建的计划任务名,要执行的程序和什么时间会执行。目标用户说明已哪个用户身份来执行,用户字段说明是谁创建了该计划任务。

        进程追踪类别还提供了3个事件,但是对于常见的监控价值不高,如下表:

    事件ID类型描述
    594SuccessA handle to an object has beenduplicated
    595SuccessIndirect access to an object has beenobtained
    600SuccessA process was assigned a primarytoken

     

       正如我们看到的这样,进程追踪类别提供的事件较少,其中比较有价值的是ID592和593事件,因为它们完整地记录了一个Windows上可执行程序的整个过程。同时也可以记录服务的安装和计划任务的创建、修改。但是对于那些不是可执行文件的执行则无法记录,例如我们执行一个VBS脚本,只会看到cscript.exe或wscript.exe的执行记录。

        要审查对一些对象如文件、文件夹的访问,需要对“对象访问”事件进行审查,我们在下篇文章进行分析。

    ok,上一篇文章我们简单分析了用户登录Windows主机后执行了什么程序。同时我们还可以对用户的资源访问行为进行审计和监控,Windows自身提供对象访问和目录服务访问这两类审计事件监控。对象访问事件可以审计所有尝试访问文件和其它Windows对象的活动,不包括AD对象(专门由目录服务访问类别事件来实现)。这里的Windows对象包括对文件夹、文件、服务、注册表和打印对象。本篇文章主要分析对象访问审核事件,目录服务访问事件以后在做分析。

        要想对Windows对象服务活动进行审计,除了必须的开启该审核策略以为,还需要进一步具体设置。如果Windows对所有的对象访问都进行审计的话,估计会立刻由于资源使用导致系统无法工作正常。也就是说对对象访问进行审计分为2个步骤:第1步是必须的开启对象访问审计类别;第2步是选择具体要监控的对象然后定义想要监控的访问类型。第2步的设置可以在对象的告警安全设置对话框看到,如下图所示:

    1

       从图中我们可以看到审计时可以从名称(是某个用户还是用户组)、访问类型(请求的权限:读、写、修改等)和结果(成功还是失败)进行具体的指定。Windows像评估对象的访问权限一样评估对象访问的审计策略。例如当一个用户尝试访问一个对象时,Windows必须根据审核策略判断是否记录该事件,会分析所有应用于该用户的审核策略。

       假设用户A具有对某文件夹和包含文件的修改权限。当用户A修改文件夹中的某个文件时,如果开启了对该文件写数据的审计并且应用的范围包括该用户,则会记录下来。如果该用户只是打开了文件未做任何修改,那么他只使用了读数据的权限,如果未开启读数据的审计,那么该活动则不会记录下来。假设用户B没有访问该文件夹及其文件的权限,那么如果开启了所有失败的访问类型审计,那么当用户B尝试访问时必然失败,并且会有相关的记录。

    下面的表格列出了访问类型的完整列表,对象访问日志中使用的对应名称和应用于的解释。

    访问权限对象访问事件中的名称文件夹文件
    遍历文件夹/运行文件执行/遍历指浏览文件时的遍历文件夹行为执行脚本或者exe文件
    列出文件夹 /读取数据读数据(列出文件夹)使用explorer进程、dir命令或者其它应用查询子文件夹或者文件的行为读取文件的实际内容
    读取属性读取属性使用explorer进程、attrib命令或者其它应用查询属性(只读、归档、系统、隐藏)的行为同左
    读取扩展属性读取扩展属性使用explorer进程、attrib命令或者其它应用查询扩展属性的行为同左
    创建文件/写入数据写数据(增加文件)创建新文件修改文件的内容
    创建文件夹/附加数据附加数据(添加子目录)创建新的子文件夹在文件结尾附加数据
    写入属性 使用explorer进程、attrib命令或者其它应用修改属性(只读、归档、系统、隐藏)的行为同左
    写入扩展属性 使用explorer进程、attrib命令或者其它应用修改扩展属性的行为同左
    删除子文件夹及文件 删除对象、包括子文件夹和文件同左
    删除 对象删除、会被父文件夹的删除子文件夹及文件的设置覆盖 
    读取权限 查询对象的ACL 
    更改权限 修改对象的ACL 
    取得所有权 对象拥有者的修改 

     

      当指定监控的类型时需要十分小心。很容易创建太多的审计策略并产生许多无关的信息,特别是当开启对“读数据、读属性、读取扩展属性、读权限和执行”的审计,因为这些权限在合法用户日常的工作中会经常使用。

          开启审计时除了上述3个选择:类型、名称、访问以外,在高级设置部分还包括了“应用到”选项。对于包含对象的文件夹可以指定是否Windows传播审计策略到子对象,如下图所示。可以为“该文件夹”“子文件夹”、和“文件”的组合。我们可以根据实际情况来调整我们的审计策略。例如我们只想知道谁访问了某个文件夹内的敏感文件,但是对文件夹级别的访问如文件夹枚举、子文件夹和文件的创建不感兴趣,我们可以开启对应权限的审计但是“应用到”设置为“只有文件”。

    1

      如上图所示,如果我们想限制“应用到”的设置只道子对象的级别,不想再往以下级别传播,可以勾选“将这些审核项目只应用到这个容器中的对象和/或容器上”。

       要正确地使用“应用到”设置,我们必须理解某些权限的双重含义。因为对于文件夹和文件列出的权限有着不同的含义。例如对于文件夹来说“创建文件夹/附加数据”意外着用户可以在该文件夹内创建新的子文件夹;对于文件来说意外着用户可以在文件的结尾附加数据。同样,对于文件夹来说“列出文件夹/读取数据”允许用户列举该文件夹内的文件和子文件夹的名称;但是对于文件来说这个权限允许用户读取数据的实际内容。所以如果我们只想审计这些双重含义权限的一种,只需要设置好“应用到”选项即可。

        从上面我们可以看出Windows对于对象访问的权限和审核都有些复杂,我们在设置这些选项前需要清楚我们到底想要监控哪些活动。下面的表格给出了一些常见的审计目标和对应的设置。

    目标类型访问活动
    审计对文件的修改活动成功写入数据 、附加数据
    某些人试图访问未授权的对象的活动失败所有的权限
    审计对文件夹的访问控制变更活动成功更改权限、取得所有权
    审计对文件夹或者某个文件夹内任意文件的删除活动成功删除子文件夹及文件

     

         对象访问事件追踪

       登录/登出和对象追踪事件都提供了一个初始和终止的事件ID来标识一个登录会话或进程的开始和终结。同样当一个对象被打开时产生ID560事件,当对象关闭时ID562事件产生。并且事件中的句柄ID(HandleID)充当进程ID和登录Id一样的作用。

      这里一个很重要的需要注意的地方是:对象访问事件反映的是Windows和应用间的交互,而不是用户和应用间的交互。

      例如,当我们使用Word打开一个doc文档,编辑内容然后关闭这个文件。我们会发现一组对应的ID560和ID562事件。然而一些事件不会保持很长时间,例如列举文件或删除文件这样的活动是单个原子的活动,但是仍然会产生ID560和562事件。

      ID560和562事件的截图分别如下:

    2     3

       我们首先看看ID560事件都有哪些信息:

       首先在头字段中可以看到是哪个用户的访问,结果是成功还是失败,在描述字段中有着更为详细的信息,如下:

    打开的对象:
         对象服务器:   Security
         对象类型:   File ##说明访问的对象,可以为File、Folder、Service、Printer
         对象名称:   C:\isalog\log\test  ##说明被访问对象的路径名,如果是文件则是文件名
         句柄 ID:   824 ##当程序打开对象时唯一标识该会话的数字,所有随后的访问会使用同样的句柄ID
         操作 ID:   {0,298126}
         进程 ID:   336  ##访问对象的程序的进程ID
         图像文件名:   C:\WINDOWS\explorer.exe  ##尝试打开对象的程序的路径名
         主要用户名:   Administrator  ##开启程序的帐户名
         主要域:   WIN2003  ##开启程序的帐户所在的域
         主要登录 ID:   (0x0,0x20A09)   ##登录ID
         客户端用户名:   Administrator  ##如果有的话,为服务器程序代表的帐户
         客户端域:   WIN2003   ##如果有的话,为服务器程序代表的帐户所在域
         客户端登录ID:    (0x0,0x20A09) ##如果有的话,为服务器程序代表的帐户的登录ID
         访问次数:   (0x0,0x20A09)    ##和登录ID一样,不清楚含义
         特权:   READ_CONTROL   ##用户访问对象时使用的权限
               ACCESS_SYS_SEC
               ReadAttributes

        基于操作的审计

      ID560事件记录了应用访问对象时请求的权限,但是这并不意外着在关闭对象前应用就使用了这些权限。例如用户可能打开对象使用了读和写权限当是没做任何修改就关闭了对象。在Windows2000中无法知道是否使用了这些权限,从Windows2003引入了ID567事件来记录使用权限的事件。任何随后使用同样权限的操作不会再触发ID567事件,Windows在打开和关闭对象间只记录ID567事件当用户第一次行使权限时。截图如下:

    4

        描述字段如下:

    对象访问尝试:
         对象服务器:   Security
         句柄 ID:   1472
         对象类型:   File
         进程 ID:   336
         镜像文件名:   C:\WINDOWS\explorer.exe
         访问:   ReadData (或 ListDirectory)

      可以从中看出,没有记录访问的对象名称和使用的权限,因此我们只能分析那些对象是我们关注的ID560事件,然后寻找同样句柄ID的ID567事件来证实用户行使了权限。

       当删除对象时除了ID560事件外,还会有ID564事件产生,如下图所示:

    5

         从描述字段中可以看出,并没有记录被删除的对象。因此要判断删除了什么文件,需要查找之前的同样句柄ID的ID560事件。

      对象访问类别还有ID561事件,用于标识句柄复制事件。句柄复制事件是应用级别的事件,和安全的相关性很少,因此可以忽略。

     

     小结:我们可以使用对象访问审计事件来追踪谁试图访问什么对象,如何访问以及是否成功。需要注意的是对于ID564和567事件由于没有相关的对象名记录,必须和相关(同一句柄ID)的ID560事件关联。




    看到题目可能会奇怪,为什么没有九直接跳到十了呢,因为由于目前对域的相关知识不熟悉,暂时跳过了“域服务访问”事件的分析,因此做个标记以后再补上缺少的部分。

       本篇文章简单分析Windows用户的“特权使用”事件的审核。默认情况下操作系统为用户创建了6个用户组,每个组拥有不同的权限。分别为管理员组(Administrators)、高权限用户组(PowerUsers)、普通用户组(Users)、备份操作组(BackuOperators)等,截图如下。此外系统同还存在着一些特殊的用户,如“SYSTEM”、“Everyone”、“CREATOROWNER”等,他们不属于任何内置用户组,属于特殊的独立的帐户。

    7

    这里的“特权”特指通过安全设置—>本地策略—>用户权限分配界面授予用户的权限(这些权限具体的含义请参考操作系统的帮助)。如下图所示:

    1

       这里分配给某用户修改系统时间和管理审核日志的权限,然后使用该用户登录系统。当被分配某些权限的用户登录系统时,会生成ID576事件,表明该用户享有这些权限(根据Randy大神说是在Windows2003SP1后添加的此ID)。这里Windows系统很奇怪的一点是在某用户组添加或移除用户时不产生日志。截图如下:

    2

    描述信息字段为:

    指派给新登录的特殊权限:
         用户名:   audit  (被分配权限的用户名)
        域:       WIN2003
         登录ID:       (0x0,0x42DDF)
         特权:   SeSecurityPrivilege  (被分配的特权)

       当用户执行了分配的特权后,如修改系统时间,会有ID577事件产生,截图如下:

    3

        描述信息字段如下:

    调用的特许服务:
        服务器:       Security
        服务:       -
         主要用户名:   audit  
         主要域:   WIN2003
         主要登录 ID:   (0x0,0x42DDF)   
         客户端用户名:   audit  (执行特权的用户)
         客户端域:   WIN2003
         客户端登录ID:    (0x0,0x42DDF) (登录的ID)
         特权:   SeSystemtimePrivilege   (使用的特权,这里可以看到是和系统时间相关)

       当用户删除了日志后,会有ID578事件产生,截图如下:

    4

    描述信息如下:

    特许的对象操作:
         对象服务器:   Eventlog
         对象句柄:   0
         过程标识:   1332
         主要用户名:   WIN2003$
         主要域:   WORKGROUP
         主要登录 ID:   (0x0,0x3E7)
         客户端用户名:   audit   (执行特权的用户)
         客户端域:   WIN2003
         客户端登录ID:    (0x0,0x42DDF) (登录的ID)
         特权:   SeSecurityPrivilege

       这里很奇怪的是无论是578还是577事件,系统都会同时生成2条一模一样的事件。截图如下:

    5

     

      接着我们取消分配给该用户的特权,然后使用该用户登录系统,并尝试改变系统时间,仍然会有ID578事件产生,只是为审核失败。截图如下:

    6

     

       由此可以看出用户使用一些权限时,要么产生ID577或578事件。但是由于许多特权使用事件并不会被记录,据Randy大神认为,此类日志对于安全的分析作用不大,但这并不代表这类事件在其它设备或者应用中不重要。




    展开全文
  • Windows Server 2016-Windows安全日志ID汇总

    千次阅读 2019-03-04 21:39:10
    Windows常见安全事件日志ID汇总,供大家参考,希望可以帮到大家。 ID 安全事件信息 1100 事件记录服务已关闭 1101 审计事件已被运输中断。 1102 审核日志已清除 1104 安全日志现已满 1105...
  • 如何安全管理windows系统日志windows系统日志的报表和告警  无论大小,每个拥有IT基础设施的组织都容易发生内部安全攻击。您的损失等同于黑客的收益:访问机密数据、滥用检索到的信息、系统崩溃,以及其他等等。...
  • Tomcat关闭日志输出

    万次阅读 2018-01-22 08:12:42
    可通过修改conf/logging.properties日志配置文件来屏蔽掉这部分日志信息。那么Tomcat怎么关闭日志输出? 一、 linux 系统 1、直接修改catalina.sh文件的输出语句 在文件中找到以下内容: ...
  • Syslog和Windows事件日志收集

    千次阅读 2018-08-09 15:25:18
    Syslog和Windows事件日志收集EventLog Analyzer从分布式Windows设备收集事件日志,或从分布式Linux和UNIX设备、交换机和路由器(Cisco)收集syslog。事件日志报表为实时生成,以显示整个网络中的重要系统信息。 无需...
  • windows日志查看-非法关机判断方法

    千次阅读 2018-05-31 09:38:00
    日志文件,它记录着Windows系统及其各种服务运行的每个细节,对增强Windows的稳定和安全性,起着非常重要的作用。但许多用户不注意对它保护,一些“不速之客”很轻易就将日志文件清空,给系统带来... Windows日志包...
  • 1、 目的 应用系统的开发和维护离不开日志系统... 在Windows2000及以上操作系统中,有一个Windows日志系统,它包括应用程序(Application)事件日志、系统(System)日志和安全(Security)日志,事件日志也可以是自
  • Windows系统日志文件分析

    千次阅读 2012-09-22 09:44:21
    日志文件,它记录着Windows系统及其各种服务运行的每个细节,对增强Windows的稳定和安全性,起着非常重要的作用。但许多用户不注意对它保护,一些“不速之客”很轻易就将日志文件清空,给系统...Windows日志包括应用
  • Windows 7 装机日志

    千次阅读 2015-04-23 10:34:29
     注1:这是凯旋自己的 Windows 7 装机日志,着重记录怎样优化、精简与净化 Windows 7 SP1 以上版本。有些理念未必符合各人情况,不用每样照搬。  注2:*号开头的段落表示需要重启电脑。  下面立即开始装机...
  • win10系统5小时休眠—windows日志查看 判断非法关机1 分析2 操作3 日志介绍参考 1 分析 自己设置从不休眠模式,还是进入了休眠模式,原因是电源不稳定或者是散热的问题或者是设置不全 2 操作 win快捷键后,输入...
  • Windows日志文件完全全解读

    千次阅读 2009-08-20 16:07:00
    From: http://blog.cfan.com.cn日志文件,它记录着Windows系统及其各种服务运行的每个细节,...一、什么是日志文件 日志文件是Windows系统中一个比较特殊的文件,它记录着Windows系统中所发生的一切,如各种系统服务的
  • 日志文件,它记录着Windows系统及其各种服务运行的每个细节,对增强Windows的稳定和安全性,起着... Windows日志包括应用程序、安全、系统等几个部分,它的存放路径是“%systemroot%system32config”,应用程序日志、
  • flume-ng收集windows日志笔记

    千次阅读 2015-09-06 09:44:24
    flume-ng收集windows下的日志并且使用SPILLABLEMEMORY 方式,日志实时收集使用spoolDirTailFile并且写入到rabbitmq 1.下载spoolDirTailFile 用到的jar 地址https://github.com/ningg/flume-ng-extends-source 2.下载...
  • windows终端事件日志监控指南

    千次阅读 2019-08-22 17:30:29
    windows事件监控指南 推荐收集的活动日志 账户使用情况 收集和审核用户帐户信息。 跟踪本地帐户使用情况有助于安全分析人员检测传递哈希活动和其他未经授权的帐户使用情况。 还可以跟踪其他信息,例如远程桌面登录,...
  • windows 服务器系统日志分析及安全

    千次阅读 2019-10-01 14:01:50
    一、利用Windows自带的防火墙日志检测入侵 下面是一条防火墙日志记录 2005-01-1300:35:04OPENTCP61.145.129.13364.233.189.104495980 2005-01-1300:35:04:表示记录的日期时间 OPEN:表示打开连接;如果此处为Close...
  • 查看windows登陆日志By default, most versions of Windows record an event every time a user tries to log on, whether that log on is successful or not. You can view this information by diving into the ...
  • windows系统审核与日志

    千次阅读 2013-12-11 15:13:56
    所有审核事件都记录在Windows事件查看器中的安全事件日志里。这些事件通常都是无法立即对其采取操作的,实际上它们一般都属于信息性内容。对所发生的每个特定类型的访问,每个事件都记录一个简单的“审核成功”或...
  • 详解Windows Server 2008安全日志

    千次阅读 2014-04-29 22:52:22
    大多数Windows计算机(除了某些域控制器版本系统)默认情况下不会向安全日志(Security Log)启动日志记录信息。这样的设置有利也有弊,弊的方面在于,除非用户强迫计算机开始日志记录安全事件,否则根本无法进行任何...
  • Tomcat关闭日志catalina.out

    万次阅读 2014-05-06 11:14:25
    翻了下收藏夹,顺手整理到这里来。 catalina.out文件会越来越大,对系统的稳定造成了一定的影响。...可通过修改conf/logging.properties日志配置文件来屏蔽掉这部分日志信息。 1
  • Windows下监控mysql正在执行的sql和日志   我们开发的时候大部分是在本机进行,使用本地的数据库, 以本机mysql为例,先查看mysql日志启用情况,默认情况下mysql日志关闭状态,可以通过如下语句 SHOW ...
  • windows下,Kiwi_Syslog日志服务器的搭建

    万次阅读 多人点赞 2017-10-13 14:17:39
    最近在运维项目中遇到了需要用日志服务器来存储防火墙日志,问了好多人都不会搭建,没办法只能自己百度找教程,却没找到比较好的。 下面是我自己总结的比较简单的搭建方法:一、Kiwi_Syslog的安装下载地址:链接:...
  • 一、利用Windows自带的防火墙日志检测入侵 下面是一条防火墙日志记录 2005-01-1300:35:04OPENTCP61.145.129.13364.233.189.104495980 2005-01-1300:35:04:表示记录的日期时间 OPEN:表示打开连接;如果此处为Close...
  • 关闭Windows不必要服务,电脑更安全

    千次阅读 2011-03-16 16:20:00
    关掉大部分没用的服务以后,系统的资源占用率有了大幅度的下降,系统运行当然也就更加顺畅了。 关闭服务的方法:我的电脑-控制面板-管理工具-服务。设定时右击一个服务,可以选择“自动”,“手动”或者“禁止...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 88,444
精华内容 35,377
关键字:

关闭部分windows日志