企业官网建设流程全解析

“又是一个Agent Tesla”。每次在样本池里看到这个家族的新变种，我脑子里第一反应不是“又来老熟人”，而是“这回又多了一层什么花活儿”。作为安全圈里资历最老、传播最广的信息窃取木马之一，Agent Tesla从2014年活跃到今天，中间换过几轮作者、用过好几套混淆框架，但它的核心目标始终没变：把受害者机器上的浏览器密码、Cookie、剪贴板、键盘输入以及各种客户端凭据，一个不落全部打包外传。很多刚入门的恶意样本分析师，第一次上手逆向的样本往往就是它，因为代码量不大、逻辑清晰、而且网上分析文章多，拿来练手再合适不过。但真正自己把一整个样本从拿到手到提取出C2地址、还原窃密逻辑、写成IOC跑通检测，中间还是有不少坑。这篇文章就把我近期分析一批Agent Tesla样本的完整思路和实操细节整理出来，该跳过的坑直接指出来，能抄的作业直接给到位。

1. 拿到样本之后，先别急着双击：静态初判的完整思路

1.1 文件识别与元数据提取，几个命令的事

无论样本是邮件附件里解出来的，还是从某个上传检测平台拉下来的，拿到手第一件事都是算哈希。MD5、SHA1、SHA256一个都不能少，sha256是后面关联情报、查VT记录、写IOC的主力ID。这一步别偷懒，直接写个小脚本批量算，或者用PE-bear、HashCalc这类工具都行，但我个人更习惯命令行一把梭，速度快而且可复现。

接着用DIE（Detect It Easy）查一下编译器和壳。Agent Tesla绝大多数是.NET程序，直接能看到"Microsoft Visual C# / Basic .NET"之类的编译信息，如果是被混淆过的版本，DIE会标出".NET Reactor"、"SmartAssembly"、"Confuser"等保护特征。这一步非常关键，因为是不是混淆版本直接影响后面用dnSpy还是de4dot的策略。

再看PE头信息，重点看编译时间戳和入口点。Agent Tesla样本常见的情况是编译时间戳被作者随机改过，但如果是旧版直接打包出来的，时间戳往往能跟该家族某个活跃周期对上。再有就是用CFF Explorer查看程序集版本号、语言类型，顺带看一眼是否有合法的数字签名——很多攻击者会把窃密木马拿过期证书签一下，绕过部分小白用户的安全告警。

到这里，我能初步判断这个样本属于哪一代变形，是否经过特殊保护，以及是不是加载器-载荷分离的结构。有一次我遇到一个只有几KB的.NET加载器，静态一看几乎什么敏感API都没有，结果它运行时从资源里释放出真正的Agent Tesla主体——这就是典型的分离式结构，单看外层根本看不出名堂。

1.2 从字符串和资源里先摸一遍底细

字符串提取要分两个维度做。第一是原始的ASCII/Unicode字符串，第二是经过编码的密文字节。用binwalk或strings工具先跑一遍，主要找下面几类东西：

• 邮件相关关键字：SMTP、MailFrom、MailTo、Password，Agent Tesla从早期版本开始就支持用受害者的SMTP账号外发数据，所以这类配置字符串直接暴露了它的窃密出口。
• 文件路径关键字：AppData、Local、Temp、Roaming，这是它定位浏览器数据库、FTP配置文件的常用路径。
• 互斥体名、管道名和进程名：很多版本会检查进程列表里是否有沙箱软件、分析工具、杀毒进程。
• Base64特征串或hex编码串：配置信息通常藏在资源文件里，用高熵检测能快速定位。

Agent Tesla的配置结构从旧版到新版变化不大，通常是一段XML或键值对结构的密文，里面包含C2地址、外发邮箱账号、键盘记录开关、屏幕截图间隔等。如果你在字符串里直接看到一段很长的Base64，且末尾带着明显的填充符号，那十有八九就是加密后的配置块，先记录下来，后面解密阶段要重点处理。

资源段（.rsrc）也很值得手动翻一遍。用Resource Hacker或者PE-bear查看，常见的Agent Tesla会内嵌一个二进制资源存放加密配置内容。有的变种会把载荷藏到资源节里，运行时反射加载。识别这类行为的快捷方法是看程序里是否调用了Assembly.Load、ResourceManager或DownloadString这类方法，一旦在导入表或IL代码里看到，就要警惕了。

1.3 编译时间线和PDB路径，别忽略的线索

很多人分析样本时不太关注编译时间戳和PDB路径，但这招在溯源和聚类上特别好用。Agent Tesla的代码仓库在圈内流传范围很广，不少小团伙拿着同一套源码各自改造，PDB路径经常能暴露出作者本机的项目目录结构，比如".\Builds\AgentTesla.pdb"或者自定义的文件夹名。同一个作者编译的不同样本，PDB路径往往高度一致，这对于把散落的样本归并到同一攻击者，是很好的旁证。

编译时间戳的聚类价值更大。我遇过一批样本，它们的编译时间全都集中在某几个凌晨时段，说明攻击者在一台固定机器上批量打包。通过聚类时间戳，我能反推活动波次，再结合钓鱼邮件的投递日期，就能画出完整的攻击时间线。

另外提一句，PE头里的"Product Name"和"Company Name"也经常被忽略。这类木马通常会伪装成合法的文档阅读器、PDF转换器、发票工具，文件名也往往跟着伪装走。把这些信息记录好，标题栏、窗口名的伪装手法，后面做告警规则的时候很有用。

2. 动态行为观察：在隔离环境里看它到底干了什么

2.1 准备一个"干净"的分析环境，细节都在这里

动态分析的机器配置和网络环境，直接决定你观察到的行为是否完整。Agent Tesla对沙箱和虚拟机的检测不算最顶级，但也不是完全没有，如果一个样本检测到自己是跑在虚拟机里，它可能不再执行任何窃密动作，直接干净退出。所以分析环境的关键词就是：模拟得像真机、网络受限但不全断。

我常用的方案是VMware虚拟机装好快照，硬件配置贴近主流办公机的水准，关闭不必要的虚拟硬件特征。虚拟机的名称不要叫默认的"Administrator"，因为很多样本会把用户名和已知沙箱用户名做比对，一旦命中就隐藏行为。网络方面，我会用FakeNet-NG或INetSim之类的工具做流量模拟，让样本以为网络可用，实际上所有外联都被劫持到本地。

分析前先把Procmon的监控规则调好，默认全量记录会产生海量日志反而干扰判断，我会预先把进程树、注册表写入、文件创建三类事件设成高亮筛选，同时开好Wireshark抓包。API Monitor和Process Hacker也要挂上，前者记录敏感API调用，后者观察进程线程和句柄变化。

2.2 进程、注册表、文件系统三个维度的行为监控

运行样本后，第一个关注点就是进程树的变化。Agent Tesla导入到系统后，要么直接注入到合法进程，要么自己派生子进程。常见手法是通过CreateProcess创建rundll32.exe，然后自身代码注入进去，目的就是伪装成系统进程降低警惕。Procmon里看到shell -> rundll32或svchost的异常父子关系，基本可以判定注入行为。

注册表维度，它会在HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run下写入自启动项，这是老牌木马的默认持久化姿势。不过新版本的Agent Tesla不一定会写注册表，有些变种直接把自己放到启动文件夹（Startup目录）里，或者利用计划任务创建自启。判断逻辑很简单：一旦发现系统特定位置的文件发生新增，且文件名伪装成正常样式，就要去跟自启项关联。

文件系统维度，重点关注三个方向。第一是浏览器配置文件目录：Chrome的Login Data、Cookies，Firefox的logins.json、cookies.sqlite，这几个文件只要被读取复制，想都不用想，就是在偷密码。第二是FTP客户端的配置文件路径，比如FileZilla的recentservers.xml。第三是临时目录里新生成的自身副本，很多木马会把主程序复制一份放到%TEMP%或%APPDATA%再执行，原文件反而成了诱饵。

2.3 键盘记录、剪贴板窃取与截屏行为的识别特征

键盘记录是Agent Tesla的默认标配，大多数版本会在LWA_INPUT类的钩子上调用SetWindowsHookExW。从行为监控上看，特征是进程加载了user32.dll并且注册了全局消息钩子，随后系统里所有按键消息都会被记录到一块缓冲区，定期由主线程写入本地文件。如果你用API Monitor观察，会看到每几秒就有一批按键数据被写进日志文件，这个节奏跟主程序的数据回传间隔基本一致。

剪贴板窃取更隐蔽，它通过反复调用GetClipboardData来读取剪贴板内容。正常程序不会这么频繁地读剪贴板，所以我判断样本是否在偷剪贴板时，直接看调用的频率和时机：如果样本在运行后的前几秒就开始高频访问剪贴板，且读取类型包含了CF_UNICODETEXT和CF_BITMAP，基本可以确定剪贴板窃取模块已启动。这类行为结合键盘记录一起分析，能还原出攻击者侧重收集的信息类型。

截屏功能则按照配置的时间间隔，周期性调用GDI或DirectX相关的API捕获整个屏幕。动态调试时，看样本是否加载了gdiplus.dll、user32.dll中的GetDC、BitBlt函数，如果这些API搭配出现在样本运行过程中，并且输出目录出现了.png或.jpg文件，截屏模块就跑不掉了。

我在监控环境里遇到过配置里关闭键盘记录、只保留截屏和剪贴板窃取的样本，说明新版Agent Tesla的模块化程度更高，配置开关不再是从前那种全开模式，分析时一定要结合配置内容判断，不能默认所有功能都会执行。

3. 网络通信追踪与配置还原：挖出C2服务器

3.1 用受控网络观察DNS解析与HTTP外联

动态分析过程中，网络行为是最能直观展示木马意图的部分。Agent Tesla新版普遍采用HTTP POST作为数据外传通道，也有一些版本会使用SMTP直接外发邮件。在受控网络里，我会用FakeNet-NG监听所有DNS查询请求和HTTP流量，这样样本发起任何域名解析、任何端口连接，都能第一时间被我截获。

观察的顺序一般是：运行样本，等待几秒到十几秒，看有没有DNS查询动作。Agent Tesla的C2域名普遍不是随机生成的DGA域名，而是攻击者手工注册的固定域名，因此DNS查询记录就相当于直接告诉你C2地址。如果样本从配置里解密出的是IP而非域名，就直接在Wireshark里看到TCP SYN包发往某个外部IP，端口多数是80或443。

我还习惯在FakeNet里模拟一个虚假的C2响应端，返回空内容看样本的反应。很多Agent Tesla样本会把从服务端拉取的数据当作二次加载指令，如果响应内容是空，它可能不会再有任何明显的后续动作；而如果响应内容符合它预期的结构，就能诱导它继续执行后续模块。这类"交互式引导"对分析复杂变种非常有价值。

3.2 从加密字符串里解出C2地址的完整过程

配置解密的经典流程是：定位资源配置段，找到密文块，再从代码中找到AES解密的密钥和IV。Agent Tesla的老版本用固定的硬编码密钥，密钥字符串就明文躺在代码里，用dnSpy打开一眼就能看到。新版本把密钥做了进一步包装，藏在程序集资源里或者经过多层Base64变换，分析时需要先把外层编码剥掉，还原出真实的AES密钥和IV。

我记得有一次遇到的样本，配置块不是直接AES加密，而是先用Base64解码，再经过一个异或变换，最后才交给AES-CBC解密。整个过程如果用dnSpy单步调试就很简单：在解密函数入口下断点，运行到解密完成后直接看返回的明文。这里给新手一个建议：与其在静态上猜来猜去，不如直接在dnSpy里找到调用解密函数的地方，下断点，看内存里解出来的明文，又快又准。

解密之后拿到的配置结构通常长这样：

C2地址（域名或IP:端口） 外发方式：http / smtp 键盘记录开关：on/off 截屏间隔：秒数 剪贴板窃取开关：on/off 被杀软查杀时的退出策略

其中C2地址往往不止一个，有些版本配置了两三个地址轮询使用，分析时要把所有地址都提取出来，一个都不能漏。漏掉一个IP，等于漏掉攻击者的一条退路，写封禁规则就直接不完整了。

3.3 情报落地：IOC提取与检测规则写法

从解密后的配置和行为数据里整理IOC，是样本分析最终要交付的成果之一。我的IOC清单通常分成四类：

• 网络IOC：C2域名、IP、URL路径、请求头中的User-Agent特征
• 文件IOC：样本哈希、释放物文件名、互斥体名、写入的注册表键路径
• 行为IOC：异常进程父子关系、特定目录批量文件读取、高频剪贴板访问
• 战术IOC：窃取数据打包后的压缩格式、外发数据包的结构特征

检测规则的写法取决于你用的平台。写Suricata规则时，重点抓HTTP请求里的特征字段。Agent Tesla的外传流量有一个特点：POST数据体通常是Base64或十六进制编码的压缩数据段，而且User-Agent要么是浏览器的固定字符串，要么是空字符串，跟正常流量一比很突兀。写规则时用content匹配这个长度畸高的POST体，再配合流量方向和时间特性，命中率会比较高。

写YARA规则时，建议不要只匹配一个字符串，要做组合匹配。比如同时匹配Agent Tesla配置加载时使用的资源名、解密后配置结构里的关键字、以及某段通用的解密函数字节码。组合式的YARA规则误报相对低，而且能覆盖同源变种。

4. 逆向调试的实战难点：反混淆、反沙箱、加密流量

4.1 脱壳与反混淆：处理混淆框架的常用打法

Agent Tesla目前能见到的保护框架主要是SmartAssembly、ConfuserEx和.NET Reactor。SmartAssembly是商业混淆器，代码结构相对规整，de4dot脱壳后能还原大部分逻辑；ConfuserEx是开源的，好在分析生态也成熟，de4dot同样能处理绝大多数情况。NET Reactor就麻烦一些，它不只是混淆，还带了反调试和native stub的技术支持，真正需要手动脱壳的情况不少。

de4dot的使用没啥高深技巧，直接把样本拖进去，输出文件，对比脱壳前后的字符串和类名。但要注意，de4dot处理完之后，类名还是会保留一大部分，比如"Form1"、"Settings"这种，需要结合代码逻辑重新命名才能理顺分析路径。你不要指望一次脱壳就能看到所有明文，混淆框架对字符串常量的加密处理是另一层挑战，通常还需要在dnSpy里手动解密并重写字符串。

有一个很管用的办法：在dnSpy里对字符串解密函数做patch，把解密后的明文直接写回去，这样后续反编译出来的代码就全是可读的明文了。操作方法是找到字符串解密函数，打补丁让它直接返回解密结果，再保存修改后的程序集。这个技巧在处理ConfuserEx的字符串加密时百试百灵。

4.2 反沙箱与反调试手法的识别和绕过

Agent Tesla的反沙箱检测逻辑并不复杂，但很有效。最常见的是检查进程列表和窗口标题：它遍历进程名单，一旦发现Wireshark、Procmon、VBoxService、Wireshark等分析工具或虚拟机特征进程，就会直接退出。还通过检查台式机的CPU核心数、内存大小、MAC地址前缀、系统盘容量等硬件指纹做沙箱判断。

绕过的思路有三个方向。第一是提前把分析工具改名，或者干脆用命令行版本替代GUI版本，降低特征命中概率。第二是直接把样本里包含进程黑名单字符串的区域patch掉，让它永远匹配不到黑名单进程。第三是hook进程枚举API，让样本看到的进程列表是伪造的一个正常办公机环境，这种方案对绝大多数反沙箱都通用，复杂度高一些但最稳定。

反调试方面，新版Agent Tesla很少上重型反调试，最多用Environment.IsDebuggerPresent和Debugger.IsAttached做基础检测。遇到这种，直接在dnSpy里把调试器检测函数的返回结果改掉就行。真正麻烦的是加了.NET Reactor保护的版本，它额外塞了一层IsDebuggerPresent的native调用，有时候还有定时器反调试——运行一段时间后如果没有收到特定窗口消息就自杀，这类需要在调试器里提前绕过定时器逻辑。

4.3 解密网络外联数据的实操记录

当样本通过HTTP外传窃取的数据时，流量往往是先压缩再Base64编码，有的变种还会额外做一层AES加密。分析外联流量时，我最常用的方法是在C2响应端做中间人解密：用FakeNet-NG模拟C2服务器，把样本发过来的数据体保存到本地文件，然后写脚本按样本代码里的算法做逆处理。

有一次遇到的样本把数据格式做成类似"id=<机器标识>&d=<加密内容>"的结构，其中加密内容用了样本内置的公钥做RSA加密，那一次就无法直接在本地解密，只能把私钥提取出来再解密。RSA私钥往往藏在样本配置的密钥对里，需要回到静态逆向阶段去把私钥完整取出。这种场景下，动态调试和静态逆向要来回切换，才能把一条流量从密文完全还原成明文。

解密完成后你会看到一个标准的zip压缩包，里面是各个模块收集到的密码和Cookie数据文件。文件名通常跟受害者机器名绑定，比如"passwords_<机器名>.txt"、"cookies_<机器名>.txt"。展开压缩包验收一下每一份文件的结构，这不仅能验证分析结论是否正确，还能反过来校验你前面配置解密是否完整——如果某份文件缺失，那说明对应的窃密模块没启用或者配置解析不完整，需要回头复查。

5. 常见问题与排查技巧实录

5.1 运行时没看到明显行为的排查思路

动态分析最常见的问题是样本运行后什么都没做，几秒钟就退出。遇到这种情况别急着怀疑自己的环境有问题，首先检查样本是否已经针对当前环境做了反沙箱判定。我按照一套固定的排查顺序来：

第一步，看进程是否存续。如果进程秒退，说明前面的反沙箱逻辑直接把它杀掉了。第二步，看Procmon日志里退出前的最后一个操作，往往会停在某个进程枚举或者注册表查询结果上，这个位置往往就是反沙箱判断点。第三步，把样本重新静态分析，搜索进程名和用户名黑名单字符串，如果找到匹配项，直接patch掉，再重新运行。

排除反沙箱因素后，再检查是不是配置解析失败。有些样本的配置被破坏或者缺少关键键值，会导致它初始化到一半就异常退出。这种问题通常可以通过dnSpy调试捕捉异常来定位：在模块初始化处下断点，单步跟进，观察异常抛出的位置和原因。

一个不得不提的细节：有的Agent Tesla变种要求必须在参数里带上某个特定值才执行，比如通过邮件附件双击运行时会带一个随机参数，如果你从命令行直接运行不带参数，它就干瞪眼不动。遇到这种，先检查进程命令行参数，再检查样本对参数的使用逻辑，往往能定位到一个简单的判断分支。

5.2 流量抓不到或域名解析失败的几种原因

受控网络环境下，有时根本看不到样本发起网络请求。首要怀疑对象是配置里的开关：某些版本默认关闭网络外传，只在特定条件下开启。从配置解密结果里检查networkOutgoing开关是true还是false，这个最简单也最容易被忽略。

第二个常见原因是样本的C2域名已经失效。攻击者的域名随时可能被安全厂商或注册商处置，如果样本拿到的C2域名DNS解析不下来，它自然就不会发起后续连接。这种场景下，你需要在配置里找出备用C2地址，或者直接把DNS响应劫持到一个你自己搭建的地址，诱导样本连接。

第三个原因是样本实际上通过其他通道通信。上文提到了基于SMTP的外传方式，很多Agent Tesla变种会优先尝试SMTP外发，如果它的SMTP配置指向某个邮箱服务商，受控网络的流量监控还得覆盖到25、465、587这些邮件端口。如果只盯着HTTP端口，很容易完美错过真正的外传流量。

5.3 一批值得长期保存的检查清单

这些年在分析Agent Tesla样本时，我沉淀了一份速查清单，每次遇到新样本都会按顺序走一遍：

• 文件哈希是否关联到已知样本：先跑VT和本地样本库比对
• 是否加壳：DIE识别保护框架，决定用de4dot还是手动脱壳
• 配置加密方式：定位解密函数，记录密钥和IV
• 窃密模块数量：键盘记录、剪贴板、截屏、浏览器密码，逐项验证
• 数据外传通道：HTTP还是SMTP，配置中的C2地址和邮箱地址全提取
• 持久化方式：注册表Run键、启动文件夹、计划任务，逐一记录
• 反沙箱/反检测逻辑：列出黑名单进程、用户名、硬件特征清单

这份清单我每次分析新样本时都会对照一遍，确保没有遗漏项。你可以在自己日常工作中维护一份类似的清单，把每次踩坑遇到的特殊行为补充进去，逐渐会形成一套属于你自己的分析框架。

写在最后

Agent Tesla作为一个活跃了近十年的窃密木马家族，它的代码逻辑并不算复杂，但正因为代码量小、改造门槛低，它被无数小团伙反复利用和定制。分析它的价值不只是对一个样本给出结论，更重要的是通过配置结构、C2地址、外传通道这些细节，把零散的攻击行为串联成完整的攻击事件。每次分析完一批样本，我会额外把提取出的IOC和同源样本做一次关联比对，往往能发现几个之前没有注意到的攻击基础设施。

最后想分享一个经验：分析这类.NET家族的样本时，别把时间全花在静态逆向上。很多时候，动态环境里看它实际访问了哪些文件、调用了哪些API，比读代码猜逻辑快得多。当然，动态行为观察的前提是你已经把反沙箱逻辑处理干净，否则看到的行为全是假象。先patch、再运行、后验证，这套流程走熟练之后，Agent Tesla这类样本对你来说就基本没什么秘密了。