几件小事

最近遇到的几件事,记录下,然后,每件事都稍微研究了下,但都没能完全弄清楚。哎,老了老了。没精力折腾了。。。

Windows登陆日志分析

大概是说某公司被入侵了,就过去帮忙看看,拿回系统日志后,看到一堆登陆日志,并且审核失败,然后type3登录进程:NtLmSsp, 身份验证数据包:NTLM,最关键的是,扫描的来源ip和端口都是没有的,只有扫描成功的时候尝试rdp登陆才有ip和端口留在日志中。

Alt text

网上找了找资料,对应登陆类型的解释如下:

登录类型3:网络(Network)
当你从网络的上访问一台计算机时在大多数情况下Windows记为类型3,最常见的情况就是连接到共享文件夹或者共享打印机时。另外大多数情况下通过网络登录IIS时也被记为这种类型,但基本验证方式的IIS登录是个例外,它将被记为类型8。
登录类型10:远程交互(RemoteInteractive)
当你通过终端服务、远程桌面或远程协助访问计算机时,Windows将记为类型10,以便与真正的控制台登录相区别,注意XP之前的版本不支持这种登录类型,比如Windows2000仍然会把终端服务登录记为类型2.

于是引起了强烈的好奇心,想弄清楚是怎样的攻击方式,并且,在渗透过程中怎样的尝试会出现怎样的日志。

为了重现环境,新装一个win7虚拟机,设置好组策略:

Alt text

新建账户tracker,密码:123456,另开一台linux先用hydra来跑SMB

Alt text

上图可见成功跑出tracker的密码,来看下在win7上留下的日志是怎样的,如预期,前8个密码都是错的,后面才是正确的日志:

Alt text

审核失败的日志详情如下:

Alt text
除了我扫描留下了ip和端口外,其余的日志基本与被攻击机器一致。也就是说,这些尝试其实都是在进行smb爆破,而等爆破成功后,才会用rdp尝试连接一次,来看是否有权限登陆。

同时,也尝试了一下,访问共享文件夹:

Alt text
在还未输入密码之前,本机首先会使用自己的NTLM hash去进行验证,若不正确,则再要求输入账号密码,如图:

Alt text

再使用hydra尝试3389爆破:

Alt text
这次耗时显然比刚才的smb爆破长,而且,并未成功爆破出账号密码,但实际在日志里有审核成功的记录的。

Alt text
你会发现使用3389登陆的时候,type的确是10,而且验证方式也不是NTML了。

Alt text

入侵者,怎么去隐藏自己的IP的,这个问题还是没能想清楚,在想是不是外网扫描导致?但讲道理,国内445端口应该都是封闭的,不会对外开放的才对,始终,有点迷。只能知道对方是扫smb弱密码,而后3389进来的。

Netkeeper

大概是去年开始,就有人不断的在git上向我反映重庆方面的netkeeper已经更新,并且Rdial已经无效了,一直没环境也没有时间去折腾,就也没怎么管了。近期又想拿起来看看,然后找学弟要了个安装包,并且让他抓了一批拨号的包过来看,发现,加密算法的确是改了,而且上了vmp3.x,还有双进程反调试,很是蛋疼,当然,也没打算完全逆它,就像通过抓包、内存啊,等通过现有的算法稍微改改猜一下更新后改了哪些地方。

可无奈工作机始终抓不到pppoe拨号的包,关键每次一到拨号就直接:

Alt text

很不解。
再然后,笔记本一直有pppoe-server的一键启动来抓拨号进来的账号密码的,可来这边之后,始终没有成功开启过,随意拨号都是619,而且反应特别迅速的619,也是百思不得解。

然后就开始反思,是不是网络问题,于是把几台机器接入完全干净的网路环境中与公司任何网络都隔离开,发现,还是不行。再然后,直接一条网线连起来,还是不行,感觉有点懵。。。

于是老老实实的去看了看自己的启动脚本,poe-ser.sh,发现,大概为了适配在学校的环境,用ifconfig去取本机外网ip做iptables进行流量转发,然后来这边之后,并没有拨号环节,然后sh里好多变量都为空,命令也执行失败导致的吧。

于是把能注释掉的都注释掉了,基本上就留了关键的一两句,起服务。拨号,发现,还是不行。

再然后想着,去看下pppoe-server的配置文件吧,然后发现我的配置文件已经被破坏了,老老实实对着网上教程修复了一番,这才能够收到拨入的请求了。于是,同一局域网的机器又都能够拨入了,我也能够正常的看到不同时间netkeeper客户端拨入时使用的动态密码了。

才发现,原来619很有可能是pppoe服务器配置出错导致的。

然后~~~被netkeeper坑了整整一天,我还是没搞定它。233333

不过环境好了,以后慢慢较量吧。

但,为啥我的wireshark还是不能在本机抓pppoe拨号的包呢?不懂不懂。。。

有关Tomcat主进程

背景大概是:某天晚上有一条Tomcat.exe拉起了cmd.exe的告警引起了大家的注意。于是有人问:是否是Tomcat爆发什么漏洞了,可以直接rce的那种,当时在想,单纯靠这个进程链关系,应该是看不出来是组件漏洞还是用webshell等起的命令。而后又接着来了一条java.exe拉起cmd.exe的告警。
于是,问题就来了,什么情况下会有这样的区别呢?
然后就搭了个环境,丢了个jspwebshell上去起notepad,来看进程链。
在起tomcat的时候,就注意到,tomcat有两种方式拉起,一是运行startup.bat,另一种是先使用services.bat安装tomcat服务后运行tomcat.exe,可能这就是造成两个进程链不同的原因吧。
分别以两种方式启动tomcat并使用webshell拉起notepad得到的进程关系链如下:
1、运行startup.bat方式:

Alt text

2、使用服务的方式(突然起不来了,用当时的照片吧23333):