采用Sysinternals工具分析stuxnet感染。第一部分(翻译)

虽然我没有意识到我所看到的,Stuxnet病毒第一次引起我的注意是7月5日去年夏天,当我收到一个程序员发来的一封邮件。其中包括一个驱动程序文件:Mrxnet.sys。说他们已经确定为一个rootkit。

实现rootkit功能的驱动程序没有什么特别值得一提,但是是什么让这一个非凡的是,它的版本信息,确定它作为微软的驱动程序,它通过了瑞昱半导体公司,一个合法的PC组件制造商(虽然我很感谢那个程序员发给我有效数字签名rootkit驱动,提交恶意软件微软官方的方式是通过恶意软件防护中心门户网站)。 我转发文件到微软反恶意软件和安全研究团队和我们的内部审查成什么成为了Stuxnet的传奇故事开始上演,迅速使此驱动成了我收到的有史以来最臭名昭著的恶意软件之一。在接下来的几个月的过程中,调查显示,Stuxnet蠕虫利用四种“零日”漏洞的Windows计算机传播(所有这一切都很快在发现后修复)在获得管理员权限,签名证书是从瑞昱JMicron盗取。最有趣的是,分析人士发现,重新编程西门子SCADA(监控和数据采集)在一些离心机使用的系统,怀疑Stuxnet是专门设计用来摧毁用于伊朗核计划的浓缩铀离心机作为目标,伊朗政府报告病毒至少部分地实现。 其结果是,Stuxnet病毒已经被公认为是最先进的恶意软件创造。由于其明显的动机和线索,在代码中发现,一些研究人员认为,它是用于国家支持的网络恶意战软件的第一个已知的例子。讽刺的是,我目前在我最近出版的网络惊悚片零时差,这时候我几年前写的书似乎有点夸张恶意软件瞄准基础设施系统的几个例子。 Stuxnet病毒已经被证明的例子更有可能比我还以为(顺便说一句,如果您已经阅读Zero Day,请留意在Amazon.com上的评论)。 恶意软件和Sysinternals的工具 我最后的几个博客帖子有记载的的Sysinternals工具的情况下被用来帮助清除恶意软件感染,但恶意软件研究人员还经常使用的工具来分析恶意软件。专业的恶意软件分析是需要对恶意软件进行逆向工程的运作严格和繁琐的过程,但像Sysinternals的Process monitor和Process Explorer的系统监控工具可以帮助分析得到的恶意软件操作的总体看法。它们还可以提供深入的恶意软件的目的,并有助于执行和需要较深的检查码块身份分。 因此,我认为这将是有趣的明显的意见,适用于初次感染步骤Stuxnet病毒的机器,采用Sysinternals的工具分析。我将展示在Windows XP系统的完全感染,然后揭开病毒利用零日漏洞之一,从Windows 7的一个非特权帐户中运行时自身提升到管理员权限记住,Stuxnet病毒是一种极其复杂的恶意软件。它传播和通信使用多种方法,并根据感染操作系统的版本执行,并安装在受感染的系统上的软件做不同的操作。这一下Stuxnet的只是皮毛,旨在展示如何没有特殊的逆向工程技术,Sysinternals的工具,可以揭示一个恶意软件感染的系统的影响。参见赛门铁克W32.Stuxnet一个伟大的深入分析Stuxnet蠕虫的文章。 此Stuxnet蠕虫感染方式 Stuxnet病毒主要通过U盘传播,去年夏天,所以我将开始安装在一个关键的病毒感染。该病毒由六个文件:四恶意快捷方式文件与基于关“复制快捷方式to.lnk的”两个文件的名称中让他们看起来像普通的临时文件名。我只是用于该分析的快捷方式文件中的一个,因为他们都达到同样的目的: 在这种感染媒介,Stuxnet病毒开始通过利用在Windows资源管理器外壳(Shell32.dll中)的快捷方式解析代码零日漏洞利用执行,而无需用户交互。所有的用户所要做的就是打开包含在资源管理器中的Stuxnet文件的目录。2783_image_thumb_2BBF20E1
让感染成功,我先卸载了壳牌的缺陷,KB2286198,这是推动通过Windows更新在2010年8月的修正当浏览器打开该快捷方式文件未打补丁的系统上找到快捷方式的目标文件,以便它可以有益显示图标,Stuxnet的感染的系统,并使用rootkit技术来隐藏文件,使它们从视图中消失 这消除了具有微软或Windows数字签名,以便自动运行只显示填充的第三方代码的条目,包括其他出版商签署代码的任何条目。我保存的扫描输出,这样我可以有自动运行反对比较晚,并强调Stuxnet蠕虫添加任何条目。同样,我按下空格键,这将使我在感染后刷新,并导致其显示Stuxnet蠕虫在绿色的背景颜色的Process Explorer启动的任何进程使用新进程暂停的进程资源管理器显示。随着process monitor捕获的注册表,文件系统和DLL活动,我浏览到USB Key的根目录下,观看了临时文件消失,等了一分钟,给病毒的时间来完成它的感染,停止进程监视器,并刷新autorun和process explorer。 我用了比较功能,在文件菜单的更新条目与先前保存的扫描进行比较。自动运行检测到两个新的设备驱动程序注册,Mrxnet.sys和Mrxcls.sys: Mrxnet.sys是程序员最初发过来的driver和实现隐藏文件的rootkit, Mrxcls.sys是启动的恶意软件在系统启动时第二个Stuxnet的驱动程序文件。 Stuxnet蠕虫的作者可以很容易地扩展Mrxnet的斗篷来隐藏并自动运行这些文件,但他们显然十分自信地认为,从一个知名企业的有效数字签名会导致任何人不注意到。原来,autorun已经告诉我们所有我们需要知道感染,这是因为删除或禁用这两个驱动程序项一样简单。 谈到我的注意Process Explorer中,我还看到了两个绿色的条目,本地安全机构子系统(Lsass.exe)进程的两个实例: 这两个额外的Lsass进程显然有可疑目的,但主要的可执行文件和命令行不露任何蛛丝马迹。但是,除了作为运行中的Services.exe孩子,两个多余的流程的另一个可疑特点是事实,他们很少有加载的DLL,如图所示的进程资源管理器DLL的看法: 没有非微软的DLL显示在加载的模块列出的Services.exe,Lsass.exe中的Explorer.exe或,所以他们可能注入托管可执行代码。研究代码需要逆向工程,但那里的代码驻留在这些进程什么地方。使用Sysinternals的VMMap工具,我们也许能够确定。VMMap是可视地显示进程的地址空间使用的处理存储器分析器。代码必须存储在具有执行权限的存储区域,并且由于注入的代码可能会被存储在通常用于数据Data存储部分,因此,通常不执行,有可能找到的代码只是通过寻找存储器未备份由DLL或可执行文件具有执行权限。如果区域具有写权限,这使得它更可疑的,因为注射需要写入权限,可能并不关心去除权限,一旦该代码是到位。果然,合法的Lsass没有可执行数据区域,但两者的新的Lsass进程具有地区执行和写入在其地址空间的权限,在相同的位置和相同的尺寸: VMMap的字符串对话框,您从视图菜单中打开,显示所选区域的任何可打印的字符串。该488K区在其启动,这是存储在每一个Windows可执行文件的标题一个标准的消息“这个程序不能运行在DOS模式”。这意味着,该病毒不只是注入的代码片段,而是整个DLL: 该区域是几乎没有任何其他可识别的文本,因此它可能压缩,但在Windows API串在该区域的末端来自于DLL的导入表: Explorer.exe最初感染的过程中,和Services.exe中启动的Lsass进程,也没有发现可疑的DLL加载,但也有不寻常的可执行数据区域的过程: 两位MRX驱动也加载到驱动程序列表,你可以在Process Explorer中的DLL视图系统进程看可见。他们站出来,在所有的唯一原因是他们的版本信息报告他们是来自微软,但他们的签名是由瑞昱(证书已被吊销,但由于测试系统是从互联网上断开,无法查询证书吊销列表服务器): 更深层次看 在这一点上,我们已经得到病毒细节。只要我们能与autorun和process explorer。迄今为止我们所知道什么是Stuxnet的系统上的两个驱动程序文件,其中登记在系统启动时启动,并启动他们。它们感染Services.exe并创建运行,直到系统关闭2的Lsass.exe过程,其目的无法通过命令线或加载的DLL来确定。然而VMMap给了我们注入代码参考,并自动运行已经给了我们一个简单的方法来清除感染。从process monitor跟踪拥有约30,000事件,将能够进一步了解的感染,其中注入的代码存储在磁盘上的时间会发生什么,以及Stuxnet病毒的激活代码开机时间。详情请阅读第2部分。 标记Russinovich是一个技术研究员在Windows Azure团队在微软您可以在markruss@microsoft.com与他联系。

发表评论