Windows日志浅析(五)

Windows日志浅析(五)

(2010-04-12 23:22:17)

转载

标签:

杂谈

分类: MSN搬家

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

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

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

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

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

   

现在来各种进行详细分析,首先是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很重要,因为可以关联用户随后的很多活动如对象访问!)
    
登录类型:    
2     (各种类型含义及数字见后面的表格)
    
登录进程:     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 the
console


3


Network


A user or computer logged on to this computer
from the network


4

Batch

Batch logon type is
used by batch servers, where processes might run on behalf of a
user without the user‘s direct intervention


5


Service

A service was started
by the Service Control Manager

7


Unlock


This workstation was unlocked


8


NetworkCleartext

A user logged on to a network and the
user password was passed to the authentication package in its
unhashed (plain text) form. It is possible that the unhashed
password was passed across the network, for example, when IIS
performed basic authentication


9

NewCredentials A caller (process, thread, or program)
cloned its current token and specified new credentials for outbound
connections. The new logon session has the same local identity, but
it uses different credentials for other network connections.
10 RemoteInteractive A user logged on to this computer
remotely using Terminal Services or a Remote Desktop
connection.
11 CachedInteractive A user logged on to this computer with
network credentials that were stored locally on the computer. The
domain controller was not contacted to verify the credentials

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

描述信息如下:

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

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

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

    

从图中可以看到,登录失败后会有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。截图如下:

       

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

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

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

             

这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事件,截图分别如下:

     

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

另外一种远程访问方式为远程协助,也会产生ID552、528、551和538事件(会伴随用户名为“ANONYMOUS
LOGON”的成对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事件),如下图所示:

     

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

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

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

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

       

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事件产生。中间会有用户名为“ANONYMOUS
LOGON”的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出现,如下图所示:

此时在窗口输入正确的用户名和密码,产生用户名为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类型的登录失败事件。
时间: 2024-10-25 13:27:35

Windows日志浅析(五)的相关文章

渗透技巧——Windows日志的删除与绕过

0x00 前言 在渗透测试过程中,Windows日志往往会记录系统上的敏感操作,如添加用户,远程登录执行等. 对于一次完整的渗透测试,通常会选择对Windows日志进行清除和绕过,而对于防御者来说,了解常用的绕过方法也有助于更好的保护自己的系统. 所以本文将要介绍常见的Windows日志清除与绕过方法,分享经验,帮助大家. 0x01 简介 本文将要介绍以下内容: Windows日志的常用清除方法 Windows日志的两种绕过方法 0x02 Windows日志 Windows日志包括五个类别: 应

c#.NET中日志信息写入Windows日志中解决方案

1. 目的应用系统的开发和维护离不开日志系统,选择一个功能强大的日志系统解决方案是应用系统开发过程中很重要的一部分.在.net环境下的日志系统解决方案有许多种,log4net是其中的佼佼者.在Windows2000及以上操作系统中,有一个Windows日志系统,它包括应用程序(Application)事件日志.系统(System)日志和安全(Security)日志,事件日志也可以是自定义日志.在.net Framework中也提供了相应的类和接口来使用应用程序事件日志或者自定义事件日志.使用Wi

Linux认证用Syslog记录UNIX和Windows日志的方法

Linux认证用Syslog记录UNIX和Windows日志的方法,在网络中安排一台专用的日志服务器来记录系统日志是一个比较理想的方案.本文以FreeBSD下的syslog为例,介绍如何利用freebsd的syslogd来记录来自UNIX和windows的log信息. 在比较大规模的网络应用或者对安全有一定要求的应用中,通常需要对系统的日志进行记录分类并审核,默认情况下,每个系统会在本地硬盘上记录自己的日 志,这样虽然也能有日志记录,但是有很多缺点:首先是管理不便,当服务器数量比较多的时候,登陆

zabbix监控windows日志脚本

zabbix监控windows日志脚本     脚本用于监控windows服务器上日志,查看日志文件的末尾N行,如果N行中包含某字段,则输出0,否则输出1,然后再zabbix的配置文件空定义kye,进行监控. 文本文件的换行符是"\n" 编辑脚本log.py import sys import re def last_lines(filename, lines = 1):     lines = int(lines)     block_size = 1024     block = 

用LogParser分析Windows日志

用LogParser分析Windows日志 实战案例分享 如果你已具有上面的基础知识,那么下面为你准备了更加深入的应用操作视频(从安装到使用的全程记录): http://www.tudou.com/programs/view/SWoIeUkUWWQ/ 用LogParser分析Windows日志

Windows日志筛选

Windows日志筛选 因工作需求开启文件系统审核,因Windows日志管理器并不方便筛选查阅,所以使用powershell方法进行筛选. 一.需求分析 存在问题 日志量巨大(每天约1G) 日志管理器查询日志不便 主要目标 启用文件系统审核 快捷查询用户的删除操作 解决方案 采用轮替方式归档日志(500MB) 日志存放60天(可用脚本删除超过期限日志档案) 使用Get-WinEvent中的FilterXPath过日志进行筛选,格式打印 删除操作码为0x10000,可对其进行筛选 二.文件审核设置

log parser分析windows日志

首先将windows安全日志导出,步骤如下: 运行eventvwr.msc命令,打开windows日志,如下图,将所有事件另存为: 保存完之后是一个.evtx格式的文件,将使用log parser分析这个导出的日志: 分析命令如下: LogParser.exe -i:EVT "SELECT TimeGenerated,EXTRACT_TOKEN(Strings,0,'|') AS USERNAME,EXTRACT_TOKEN(Strings,2,'|') AS SERVICE\_NAME,EXT

用C语言编写Windows服务程序的五个步骤

Windows 服务被设计用于需要在后台运行的应用程序以及实现没有用户交互的任务.为了学习这种控制台应用程序的基础知识,C(不是C++)是最佳选择.本文将建立并实现一个简单的服务程序,其功能是查询系统中可用物理内存数量,然后将结果写入一个文本文件.最后,你可以用所学知识编写自己的Windows 服务. 当初他写第一个NT 服务时,他到 MSDN 上找例子.在那里他找到了一篇 Nigel Thompson 写的文章:“Creating a Simple Win32 Service in C++”,

windows 日志文件查找符合条件的列并统计

因为要将windows每天登陆失败的次数统计, "wevtutil el  "           //列出日志名称 "wevtutil  gl  日志名称" //获取日志配置信息. 你可以使用短(如 ep /uni)或长(如enum-publishers /unicode)形式的命令和选项名称. 命令.选项和选项值不区分大小写. 变量均使用大写形式. wevtutil COMMAND [ARGUMENT [ARGUMENT] ...] [/OPTION:VALUE