Category: 技术分享

NTLM 降级攻击技巧

本文介绍一种方法,通过 NTLM 降级获取 NetNTLMv1 哈希,再通过破解 NetNTLMv1 到更为通用的 NTLM 哈希。

NTLM / NetNTLMv1 / NetNTLMv2

NTLM(New Technology LAN Manager)是微软提供的一组安全协议,用于认证用户身份。它是一个基于质询响应的协议,在验证用户的过程中不需要传输用户的明文密码。

在质询和响应阶段,客户端会收到来自服务器的质询(Challenge),然后使用用户的密码哈希对质询进行加密,生成响应(Response),这个响应就是 NetNTLM 响应。NetNTLMv2 是 NetNTLM 响应的一个较新的版本,早期版本为 NetNTLMv1。

NetNTLMv2 与 NetNTLMv1 都用于相同的认证过程,但 NetNTLMv2 相对于 NetNTLMv1 提供了更强的安全性,v2 使用了更复杂的加密方法和更长的质询,这使得破解密码变得更加困难。

因此,红队会尝试降级 NTLM 协商过程,转而获得更容易破解的 NetNTLMv1。

NTLM 降级

我们准备一个 Windows Server 2019 测试系统,将登录的账户密码修改为难以破解的超长密码,如下图所示:

编译并以管理员模式运行 Internal-Monologue,这个程序会将 NTLM 降级,并自动获取 NetNTLMv1 哈希:

获取到的 NetNTLMv1 哈希为:480c165778cfecf2a48f9e6f0191369994e8d011e8dc44d5

NetNTLMv1 -> NTLM

接下来,我们使用 ntlmv1.com 网站破解 NetNTLMv1,如下图所示:

破解成功后得到的结果即为常用的 NTLM 哈希:73b636dd3af905cda7c6bcd84a09a278

通过设置的密码生成 NTLM 哈希来校验一下解密结果是否正确:

NTLM 降级的优点

  • 获取 NTLM 哈希无需接触 Lsass 进程
  • 永久削弱目标系统的密码安全级别(在不恢复 NTLM 协商等级之前)

虽然还有其他潜在行为特征可以检出降级攻击,但如果你已经意识到了这一点,那绕过这些也应当非常简单 🙂

参考链接

https://book.hacktricks.xyz/windows-hardening/ntlm
https://github.com/eladshamir/Internal-Monologue
https://www.hackingarticles.in/ntlm-downgrade-attack-internal-monologue/
https://www.freebuf.com/articles/web/350726.html
https://zhuanlan.zhihu.com/p/637258145

微信聊天记录防泄露可行性研究

前言

这篇文章不是介绍数据泄漏保护产品(DLP),也不是为了宣传、对比或突出国内防护软件相关功能的有效性,只是提供了一个保护微信聊天记录的解决方案,它至少可以显著的提高窃密活动可见性。

泄露

对于企业/办公室工作站系统,最重要的数据莫过于即时聊天记录,如微信等,这里面包含了大量的商业机密和办公信息,黑客控制系统的主要活动之一就是窃取这些聊天软件数据,我们也观察到了很多与之相关的自动化工具,它们正广泛流传,如下图所示:

类似的程序多到数不胜数,我们以 PyWxDump 这个项目为例,来看看它的导出效果:

导出的效果与此次上海安洵泄露数据基本一致(甚至更加详细),此类工具完全可被滥用于敏感数据窃取,所能造成的危害不亚于浏览器凭据窃取工具。

值得一提的是,上述数据导出步骤在绝大部分防护软件上是完全无感的(无任何安全警报或风险提示)。

原理

想要搞清楚如何发现这种行为,就要先了解它的工作原理,简单了解即可。

PC 版微信的默认安装路径是:

C:\Program Files (x86)\Tencent\WeChat

这里基本包含了微信正常运行所需的全部程序文件,但不包括用户数据,用户数据默认路径是:

C:\Users\[你的用户名]\Documents\WeChat Files

顾名思义,聊天数据全部放在了上图中的 Msg 文件夹中,PyWxDump 这类工具通过读取并解密 Msg 文件夹里的数据文件实现聊天记录导出。

如果对数据解密感兴趣,请参考该文档(它与防泄漏解决方案无关,对于本文章而言意义不大):wx数据库简述.md

解决方案

Msg 目录下的文件如此重要,理应由微信应用程序独占打开并解密,而不是任由第三方程序打开,若微信可以将该目录下全部文件独占,可以一定程度上缓解数据泄露风险,增大窃取成本。

  • 从这里入手,我们可以通过 Sysmon 监控该目录下的全部文件打开和文件读行为,排除掉微信应用程序本身后,其余产生的行为日志应全部列为可疑事件并进行深度调查。

  • 考虑到黑客可能注入到微信程序本身,通过微信进程自身进行窃取从而绕过行为监控,或通过读取微信程序内存中的数据解密密钥,我们还需要重点关注打开微信进程的行为。

  • 黑客还有可能伪装成微信程序进行数据窃取,我们需要对程序签名进行严格的校验。

无论通过何种方式何种工具,只要能完成上述监控,攻击者几乎无法继续做到无感的窃取微信聊天记录,若再辅以拦截动作,数据防泄露的目的也可以实现。

事已至此,内部泄密?还是国家行为体的网络入侵行径?无论如何都不重要了,etc.

如何检测并阻止基于 Impacket 工具集的 Wmiexec 横向移动

背景

网络攻击者在获取到一个主机系统权限后,往往会尝试渗透并控制网络中的其他主机系统,以获得更多的访问权限和更多的网络活动范围,这被称为横向移动,绝大部分攻击者尝试过使用 Impacket 中的 Wmiexec 进行横向移动。

我们发现,近期有很多基于 Impacket 的图形化网络渗透工具的发布,这说明,这款流行了 8 年之久的工具集终于被脚本小子们关注到,并将更广泛的应用于各种意图的网络攻击中。

Impacket 与 Wmiexec

Impacket 是一个用于操作网络协议的 Python 开源工具集,包含多个用于远程服务执行、Windows 凭据转储、数据包嗅探和 Kerberos 操作的工具。其中,wmiexec.py 经常被应用在各种网络攻击活动中,它可以通过远程系统开放的 Windows Management Instrumentation (WMI) 合法服务,在远程系统上执行任意 cmd 命令。

虽然 WMI 是合法服务,但这不表示所有使用 WMI 的行为者都没有恶意,尤其是使用 wmiexec.py 的行为者,所以我们将重点关注 wmiexec.py 的行为特征,下面我们将通过模拟攻击来重现这些行为。

模拟攻击

我们准备了两台 Windows Server 2019 x64 虚拟机,其中一台用于模拟攻击者(A),在 A 主机中下载并安装脚本小子喜欢使用的 Impacket 图形化操作工具:

另一台模拟被横向移动的目标远程主机(B),部署复杂之眼客户端,并确保 WMI 服务与 DCOM 135 端口和 SMB 445 端口处于可用状态,如下图所示:

在 WMIEXEC 操作页中填写 B 的 IP、管理员用户名、密码(或 NTLM) 和将要执行的 cmd 命令,点击执行,如下图所示:

命令结果框中返回了 wmiexec.py 的运行结果,我们继续通过这种方式执行 ipconfig 与 net user 命令,全部成功。

分析与检测

接下来,在复杂之眼端点检测与响应系统中寻找上述 cmd 命令执行痕迹,如下图所示:

打开这些行为日志,我们发现了有趣的命令行细节:

当我们执行命令时,wmiexec.py 会通过执行附带 /Q 和 /c 参数的 cmd.exe,间接运行我们的命令,如 whoami,然后将全部命令结果通过管道符写入 ADMIN$ 共享目录的随机文件中,我们在 wmiexec.py 源码中可以找到对应部分实现:

接下来我们寻找这些 cmd.exe 的父进程,这样有助于我们了解 wmiexec 横向移动的目标作用主体,如下图所示:

所以,wmiexec.py 在目标主机上进程行为关系链为:wmiprvse.exe->cmd.exe,我们可以结合该进程关系与上述的特殊 cmd.exe 命令行特征制定针对 wmiexec.py 的检测规则。

此时,复杂之眼端点检测与响应系统中已经完成了全部的相关威胁检测与自动关联:

攻击无效化

完全确认当前网络环境中不存在此类行为后,我们可以对 wmiexec.py 进行自动拦截,再次通过 Impacket 图形化工具执行 whoami 命令,已无法获取命令执行结果:

目标主机中弹出复杂之眼端点安全警报,指示了一个被阻止的恶意进程启动:

再次刷新威胁细节页面,可以观察到被阻止的进程与相关警报:

总结

随着 Impacket 图形化工具的流传,从不了解 wmiexec 实现原理的脚本小子也可以快速的进行危险的横向移动操作,通过对实际操作的过程复现与行为分析,我们总结了一个针对 wmiexec 的策略,并通过复杂之眼端点检测与响应系统帮助您预防 wmiexec 横向移动。

您可以在您的网络中自行通过 Impacket 图形化工具,验证您已经部署的其他终端安全软件是否可以抵御这个古老且有效的横向移动操作 :)


复杂之眼 EDR 是新一代 EDR/DLP/XDR 融合解决方案,点击下方链接,申请 14 天免费试用:

https://www.mistiny.com/index.php/trial-submit/

红队技术:对 Sysmon 的可靠对抗技巧-第二部分

在第一部分中,我们介绍了在 Windows 系统中对 Sysmon 的对抗技巧,接下来我们将操作系统更改为 Linux,观察 Sysmon 又有何表现。

部署 SysmonForLinux

本文所使用的 Linux 系统发行版本为 openKylin 1.0(开放麒麟),我们将在该国产系统中进行 Sysmon 部署与测试。

下载 SysinternalsEBPFSysmonForLinux 的 dpkg 软件包,分别进行部署。

部署完毕后,输入 sysmon 命令打印帮助,命令行参数与 Windows 版本没有太大区别。

使用 sysmon -i 命令安装 Sysmon 驱动与服务。

安装完成后,需要准备 SysmonForLinux 配置文件,该配置将监控并记录 Sysmon 在 Linux 系统上支持的所有行为事件,配置内容如下:

<Sysmon schemaversion="4.70">
  <EventFiltering>
    <!-- Event ID 1 == ProcessCreate. Log all newly created processes -->
    <RuleGroup name="" groupRelation="or">
      <ProcessCreate onmatch="exclude"/>
    </RuleGroup>
    <!-- Event ID 3 == NetworkConnect Detected. Log all network connections -->
    <RuleGroup name="" groupRelation="or">
      <NetworkConnect onmatch="exclude"/>
    </RuleGroup>
    <!-- Event ID 5 == ProcessTerminate. Log all processes terminated -->
    <RuleGroup name="" groupRelation="or">
      <ProcessTerminate onmatch="exclude"/>
    </RuleGroup>
    <!-- Event ID 9 == RawAccessRead. Log all raw access read -->
    <RuleGroup name="" groupRelation="or">
      <RawAccessRead onmatch="exclude"/>
    </RuleGroup>
    <!-- Event ID 10 == ProcessAccess. Log all open process operations -->
    <RuleGroup name="" groupRelation="or">
      <ProcessAccess onmatch="exclude"/>
    </RuleGroup>
    <!-- Event ID 11 == FileCreate. Log every file creation -->
    <RuleGroup name="" groupRelation="or">
      <FileCreate onmatch="exclude"/>
    </RuleGroup>
    <!--Event ID 23 == FileDelete. Log all files being deleted -->
    <RuleGroup name="" groupRelation="or">
      <FileDelete onmatch="exclude"/>
    </RuleGroup>
  </EventFiltering>
</Sysmon>

使用 sysmon -c 命令导入配置文件。

现在,SysmonForLinux 开始正常工作,它稳定的记录着一切来自红队的操作痕迹......

配置存储位置

Windows 中的 Sysmon 将导入的配置内容以二进制形式保存在注册表中,但 Linux 系统并没有注册表,它的配置存储位置在哪里?

通过浏览 SysmonForLinux 服务程序源代码,从 这里 开始,Sysmon 将响应 -c 参数输出正在应用的配置。

我们继续审计 DumpConfiguration 函数,发现配置文件位置由 SYSMON_RULES_FILE 宏进行定义。

  • 默认安装路径:/opt/sysmon
  • 配置路径:/opt/sysmon/config.xml
  • 规则路径:/opt/sysmon/rules.bin

在查看 config.xml 的时候,我们惊讶的发现,它的内容居然与我们指定的配置文件一致,而非默认的空配置,再结合前面截图中的正在运行的 sysmon 进程命令行参数......思考。

难道说,SysmonForLinux 不能离开明文配置独立工作?我们尝试重命名 config.xml,重启,观察 Sysmon 的运行状态。

重启后,Sysmon 服务程序已停止工作......

syslog 中也没有继续出现 Sysmon 的日志记录,内核中收集行为日志的机制完全失效。

我们只需要有权限可以访问到 SysmonForLinux 的配置文件,即可了解当前系统中的行为监控情况,不再需要二进制解析过程。

脆弱的 eBPF

SysmonForLinux 没有独立的内核模式程序(驱动程序),它通过 Linux 内核提供的 eBPF 框架实现用户层系统调用跟踪,类似的开源项目还有 traceeHades

实际上,从 此处 审计可发现,在执行 sysmon -i 命令时,SysmonForLinux 只是将所需的配置文件与编译后的 eBPF 对象文件释放,而后通过前面提到的 SysinternalsEBPF 将 eBPF 程序注入进内核 eBPF 框架中,进而实现系统行为监控。

在注入前,SysmonForLinux 会读取 config.xml,将其中的规则保存为二进制的 rules.bin 文件,注入后,二进制会通过 linkTPprogs 修改 eBPF 跟踪点,这使得 eBPF 框架可以依照配置文件对特定系统调用进行跟踪。

但是,这些注入的 eBPF 程序并不能独立运行,它们类似于安插在系统调用中的回调函数,当指定的系统调用发生时,eBPF 会向处于用户态的将 eBPF 代码注入进内核的程序传达这些系统调用的详细信息,而且,这些 eBPF 程序依赖用户态进程,一旦用户态进程未能正常工作,则整个监控记录机制完全无效。

而且,被植入的 eBPF 程序由于 eBPF 框架的安全检查和功能需要,很难被混淆后再进行注入,即使是没有开源的编译后 eBPF 跟踪程序,也可通过 llvm-objdump 进行反编译。参考 此处

总结

Sysmon 作为免费且公开的系统工具,实现了很多细致且开箱即用的系统行为记录功能,是蓝队手中的强大武器,可能出于对工具滥用的担忧,开发者并未设计它的自我保护和数据保护功能,但这并不妨碍它日常的行为记录功能。

在它灵活的监控规则下,红队不太可能在操作时隐藏自身,唯有充分了解 Sysmon 的弱点,在 SIEM 和 SOC 广泛流行的现在,才可以与使用 Sysmon 蓝队继续对抗下去。

红队技术:对 Sysmon 的可靠对抗技巧-第一部分

Sysmon 是什么

Sysmon 是一款可以全面记录系统行为日志的工具,全称为 System Monitor(系统监视),最初由美国 Winternals 软件有限公司的 Mark Russinovich 编写而成,作为 Sysinternals 实用工具套件的一部分,现在的所有者为微软。

截止至本文发布时间,Sysmon 已经更新至 15.0 版本,且已经支持了 Linux 系统,在大多数国产操作系统中也可以正常工作。

在第一部分中,我们只讨论 Sysmon 的 Windows 版本。

保持敬畏

很多从事红队或渗透测试工作的朋友,在进程列表中遭遇 Sysmon 的第一反应可能是:

  • A:它没有任何自身保护功能,Kill 掉它就万事大吉了;
  • B:它又不会阻拦我继续进行渗透测试,是无关紧要的;
  • C:拜托,很弱的啦。

可事实并非如此,在绝大多数已经部署 Sysmon 的企业或机构网络中,Sysmon 往往不是独立存在的。

Sysmon 可以收集的系统行为日志如下:

  • 进程创建
  • 进程退出
  • 文件的创建时间被修改
  • 网络连接
  • Sysmon 服务状态更改
  • Sysmon 配置更改
  • 驱动加载
  • 模块加载
  • DNS 查询
    ...

篇幅有限,详细的事件记录请查阅 官方文档

将各类行为日志提取后,后续的安全日志分析工具就开始发挥作用了,例如全球最流行的开源 SIEM 项目 Wazuh 和全球最大的日志分析商业平台 Splunk,它们采集到 Sysmon 的行为日志后,会通过内置的安全策略对行为日志进行筛选,找出可能对安全存在威胁的系统行为。

这种 日志收集 ->日志筛选 ->安全响应 模式,在安全运维机制良好的网络环境中是长期存在的,入侵者在系统中产生的行为数量,在广泛的行为日志中如沧海一粟。

所以,红队从一开始就处于完全监视之下,对上述模式采取不管不顾甚至是轻视的做法,最终会招致渗透测试完全失败的恶果,这是必然事件。

我们认为,以下做法是完全错误且十分不专业的,且可能会迅速吸引蓝队的注意:

  • 尝试破坏 Sysmon(这是最危险的行为)
  • 无视 Sysmon

从红队角度看,对行为事件采集源头的 Sysmon 保持敬畏之心,是十分有必要的。

定位 Sysmon

在准备应对 Sysmon 之前,红队必须确定当前系统中是否存在它,我们提供了一些方案用于定位 Sysmon。

Sysmon 由以下部分组成:

  • Sysmon 服务程序
  • Sysmon 驱动程序

使用 -i 参数可以将 Sysmon 以默认配置部署至系统中,如下图所示:

我们可以在系统服务和进程列表中观察到 Sysmon64,如下图所示:

该服务进程程序的路径默认为:

  • C:\Windows\Sysmon64.exe

驱动程序为:

  • C:\Windows\SysmonDrv.sys

注册表项路径:

  • 服务:HKLM\SYSTEM\ControlSet001\Services\Sysmon64
  • 驱动:HKLM\SYSTEM\ControlSet001\Services\SysmonDrv

过滤器实例信息:

  • 过滤器名:SysmonDrv
  • 实例名:Sysmon Instance
  • 过滤器高度:385201

想了解更多有关文件系统微型过滤器的知识,请参考微软 官方文档

通过查找以上信息,红队可以发现默认配置下的 Sysmon 部署情况,然而,不知出于有意或无意,Sysmon 允许用户通过改变安装参数和信息,避开上述所有的默认特征。

例如,使用如下安装操作,改变服务与进程名:

效果如下:

更多操作可以参考文章:Sysmon hide and seek

红队怎样才能定位到被彻底隐藏的 Sysmon?Sysmon 行为日志收集功能的核心是它的驱动程序,通过向系统注册上面提到的过滤器实例,Sysmon 才得以正常工作,我们可以先尝试枚举出所有的过滤器,然后找到它们对应的驱动程序路径:

Function Select-Column {
  [cmdletbinding(PositionalBinding = $False)]
  param(
    [Parameter(ValueFromPipeline, Mandatory)]
    $InputObject,

    [Parameter(Mandatory, Position = 0)]
    [int[]] $Index,

    [Parameter(Position = 1)]
    [int] $RequiredCount,

    [Parameter(Position = 2)]
    [string] $OutFieldSeparator = "`t"
  )

  process {
    if (($fields = -split $InputObject) -and ($RequiredCount -eq 0 -or $RequiredCount -eq $fields.Count)) {
      $fields[$Index] -join $OutFieldSeparator
    }
  }
}

$filterList = & "fltMC.exe" filters
$serviceList = Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\*'

$filterList | Select-Column -Index 0 -RequiredCount 4 | Select-Object -Skip 1 | ForEach-Object {
  $__ = $_
  $serviceList | ForEach-Object {if($_.ImagePath -like "*$__.sys") { $_.ImagePath }}
}

遍历得到的驱动程序,获取它们的附加信息,并检索其中是否包含 Sysmon 关键字,随后,我们成功找到被隐藏起来的 Sysmon 驱动程序,如下图所示:

使用以上过程确定原版 Sysmon 是否部署,是非常准确的,因为,如果蓝队尝试修改掉 Sysmon 驱动程序的附加信息,就会使驱动程序二进制签名校验失败;如果蓝队重新对驱动程序进行签名,那就是另一个痛苦的故事了 🙂

* 如果你一定想破坏掉 Sysmon,较安全的办法已经在前面提到了,请仔细阅读并理解所有内容。

规则提取

以上步骤只是确定 Sysmon 是否部署,我们不建议红队对 Sysmon 功能进行任何形式的更改。

Sysmon 提取的特定行为类型,全部由配置文件定义,配置文件可以在 Sysmon 部署时指定并导入,也可以后续导入或更新,以下内容是一个简单的 Sysmon 配置,它允许 Sysmon 记录 cmd.exe 进程创建事件:

<Sysmon schemaversion="4.1">
    <HashAlgorithms>*</HashAlgorithms>
    <CheckRevocation/>
    <EventFiltering>
        <ProcessCreate onmatch="include">
            <Image condition="image">cmd.exe</Image>
        </ProcessCreate>
    </EventFiltering>
</Sysmon>

蓝队通常情况下,会在导入配置文件后,将配置文件删除,这不会影响 Sysmon 的正常工作。Sysmon 配置文件的内容以二进制形式保存在以下注册表值项中:

  • HKLM\SYSTEM\CurrentControlSet\Services\sysmonDrv\Parameters\Rules

正常情况下,蓝队或者管理员通过 -c 参数运行 Sysmon,可以将该二进制形式的配置转换为可读格式并打印,如下图所示:

但从红队角度出发,这是一个不太安全的操作,因为蓝队很可能提前准备了针对该命令执行的检测方案。

红队可以尝试使用注册表相关的 WIN32 API 对配置值项二进制进行转储,例如 RegQueryValueExW,然后将转储后的值项写入红队本地的对应注册表值项中,并通过在本地运行 Sysmon 的 -c 参数得到可读配置内容。

在 2018 年的 Black Hat(黑帽大会)中,Matt Graeber 和 Lee Christensen 分享了针对 Sysmon 的议题,并开源了他们的工作成果,链接如下:

其中我们认为非常有意思的部分,是对 Sysmon 二进制配置内容进行逆向的工作,你可以在 PSSysmonTools 项目中找到它,但是它已经停止维护了,对新版本的 Sysmon 配置无效,感兴趣的朋友可以自行学习。

小结

在本文中,我们简单的介绍了 Sysmon,描述了它在实际场景中的应用和十分有效的防御策略,并从红队角度出发,描述了准确的在 Windows 系统中找到 Sysmon 并获取可读配置内容的方法。

在第二部分中,我们还将会介绍 Sysmon 在 Linux 系统中使用的先进技术和优秀表现,并提出在 Linux 下的可靠对抗技巧,敬请期待。

什么是无文件攻击

背景

无文件攻击是一种通过滥用操作系统内置工具,完全在进程内存中执行恶意代码的技术,攻击者不会向文件系统中写入任何文件。

由于文件系统中没有任何可供检测的文件数据,所以,这种攻击方式在原理上可以完全绕过基于病毒文件特征库、沙箱和使用云查杀的网络安全产品。

无文件攻击场景

1.初始访问

在最初,攻击者可能会使用我们其他文章中介绍过的任何漏洞对目标系统进行攻击,获取系统的初始入口点。漏洞类型包括但不限于文件包含、代码执行和反序列化漏洞。
攻击者在这个阶段可能没有进行任何文件的写入。

2.执行

随后,攻击者会通过入口点进行恶意代码执行,例如:使用 PowerShell 或 Cmd 执行恶意代码、植入无文件内存 WebShell、使用 whoami 或 ipconfig 等命令收集系统信息等。
这些操作同样不会有任何的文件写入行为。

3.持久化

攻击者可能会使用镜像劫持、创建系统启动项、创建系统服务等方式,使得自己的恶意代码可以长期保留在目标系统中,并伺机执行。
大部分持久化技术都不需要写入任何可疑文件,而且他们是正常的系统功能,杀毒软件也无法进行检测。

4.特权提升

当攻击者已经可以在系统中执行恶意代码后,在权限不足的情况下,攻击者也有可能会通过在内存 ShellCode 或内存模块执行特权提升程序,例如 GodPotato 和其他提权技术。
ShellCode 和其他内存模块执行的方式本身就是无文件攻击技术。

5.防御绕过

通过在内存中执行系统功能,破坏或禁用反病毒程序,使其无法正常检测恶意文件。
这样可以更加肆无忌惮的通过无文件攻击在目标系统上活动。

6.凭据窃取

随着攻击技术的普及,在内存中执行 Mimikatz 和其他密码转储程序对攻击者而言,早已成为家常便饭。
在这个过程中,老练的攻击者通常没有任何文件写入操作。

7.横向移动

使用偷来的账号和密码,攻击者通常会使用 SmbExec、WmiExec 和 PsExec 等工具,通过滥用其他系统上运行在 445 或 135 端口上的正常服务,控制更多系统,实现内网横向移动。
这些远程执行方式是 Windows 自带的管理工具接口,不需要向目标系统写入任何文件也可以完全的控制目标系统。

8.重复 1-7

循环上面的这些步骤,
攻击者可以通过无文件攻击技术完全控制内部网络,且不会被反病毒程序发现。

如何检测无文件攻击

对于无文件攻击而言,使用任何反病毒软件都是毫无意义的,我们应该抛弃过时的基于病毒特征库的检测技术,从攻击指标(IOA)中寻找有效方案。

IOA 是一种可以主动对无文件攻击进行防御的方法,IOA 可以通过行为分析,关联行为序列,寻找可疑的无文件攻击行为;IOA 也更加侧重于找出那些 刻意隐藏自己攻击意图 的人,例如添加不必要的代码混淆、执行看似花哨而实则无用的命令。

程序是否有害,是否使用了某种特定的技术甚至是零日漏洞利用,这些都不重要。最重要的是识别出攻击者正在做的事情是什么,意欲何为,只要识别出了有害意图,无论怎样躲避都是徒劳的。

复杂之眼如何防御无文件攻击

通过对超万亿级别的行为分析,复杂之眼建立了针对各种终端场景下的 行为基线,可以识别到与正常操作有细微差别的可疑行为,这也被称为 行为偏差检测

在实战场景中,复杂之眼对于攻击者常用的 WmiExec、SmbExec 和 PsExec 等操作均可以进行灵敏检测,对于这些攻击可能延伸出的异常行为,复杂之眼均可以进行自动阻断,抵御基于无文件攻击的横向移动和内存执行操作。


复杂之眼 EDR 是新一代 EDR/DLP/XDR 融合解决方案,点击下方链接,申请 14 天免费试用:

https://www.mistiny.com/index.php/trial-submit/

如何有效遏制针对通达 OA 的漏洞利用活动

前言

假设你是网络安全建设或防御负责人,相信针对通达 OA 的渗透测试一定是使你提心吊胆、夜不能寐且辗转反侧的原因之一。

在此篇文章中,我们将给出可以遏制针对通达 OA 进行漏洞利用的策略,及时发现并降低它可能给终端安全带来的风险。

关于通达 OA

通达 OA(Office Anywhere),是一款适用于企事业单位的通用型网络办公软件,是北京通达信科科技有限公司旗下产品之一。

北京通达信科科技有限公司隶属于中国兵器工业信息中心,简称通达信科。是一支以协同管理软件研发与实施、服务与咨询为主营业务的高科技团队,是国内协同管理软件行业里一家央企单位,中国协同管理软件的领军企业。

漏洞公开情况

为了更好了解产品的自身安全问题,通过对百度搜索信息的公开检索,我们调查了自 2020 年 1 月到 2023 年 6 月,有关通达 OA 的全部漏洞公开情况:

  • 2020 年 3 月
    1. 未授权文件上传漏洞
    2. 未授权文件包含漏洞
  • 2020 年 4 月
    1. 未授权任意用户伪造漏洞(CNVD-2020-25050)
  • 2020 年 8 月
    1. 未授权 SQL 注入漏洞
    2. 未授权任意文件删除漏洞(CNVD-2021-14827)
  • 2020 年 9 月
    1. 后台任意文件上传漏洞(CNVD-2020-57815)
    2. 后台 SQL 注入漏洞
  • 2021 年 3 月
    1. 任意在线用户登录凭据窃取漏洞
  • 2021 年 7 月
    1. 后台 SSRF 漏洞
  • 2022 年 2 月
    1. 后台 SQL 注入漏洞
  • 2022 年 4 月
    1. 未授权任意文件上传漏洞
  • 2022 年 7 月
    1. 未授权任意文件上传漏洞
    2. 后台任意文件上传漏洞
  • 2022 年 11 月
    1. 任意文件上传漏洞

上述 14 个漏洞均允许攻击者完全的控制受影响目标系统,全部为高危漏洞,影响范围极大。

利用方式分析

通达 OA 安装时,会以 SYSTEM 权限向宿主系统部署并启动以下主要组件:

  • MySQL:提供数据存储功能
  • Redis:提供缓存功能
  • Nginx:提供网站功能
  • PHP-CGI:提供 PHP 代码执行功能

主要组件运行关系如下:

结合历史漏洞类型和组件运行关系,我们总结的攻击者通用操作如下:

  1. 如果可以进行未授权的文件上传,且上传后的文件扩展名可控,则直接部署 PHP WebShell。
  2. 如果可以进行未授权的文件上传,但后缀名被限制且无法绕过,则上传带有后门 PHP 代码的图片或其他文件。
  3. 如果可以进行未授权的文件包含(include),则包含带有后门 PHP 代码的图片或其他文件(如日志文件),继而部署 PHP WebShell。
  4. 如果可以进行未授权的 SQL 注入漏洞利用,则利用 MySQL 在网站目录中部署 PHP WebShell 或执行系统命令。
  5. 如果可以得到认证后相关 API 的调用权限(登陆后),则利用登陆后相关漏洞。
  6. 如果存在后台 SQL 漏洞,利用方式参考 4。
  7. 如果存在后台文件上传类漏洞,利用方式参考 1、2、3。
  8. 如果后台存在 SSRF 漏洞,则利用 redis 在网站目录中部署 PHP WebShell。

由于通达 OA 的主要组件默认以 SYSTEM 权限运行,所以,攻击者在获得 PHP 任意代码执行的方式(如 WebShell)后,目标系统就已经完全沦陷,攻击者可能以 SYSTEM 权限进行任何后续操作,包括但不限于系统命令执行、可疑二进制文件上传/运行、窃取系统敏感凭据、部署勒索病毒、搭建机密网络隧道和任何针对内部网络的恶意活动。

不要过于担心,虽然这些漏洞利用和后续操作看起来很可怕,但它们产生的系统行为特征非常明显,我们可以把所有相关行为抽象成以下几种:

  1. 写入 PHP 脚本文件
  2. 写入可执行文件
  3. 执行了常用黑客命令
  4. 产生了不寻常的网络连接

相关进程包括:php-cgi.exe、mysqld.exe 和 redis-server64.exe。

这些行为看起来似乎与通达 OA 产品没有任何关系,因为它们完全是通用的渗透测试行为。

检测与防御

通过复杂之眼 EDR 提供的 MEQL 语法,根据上述行为,我们编写了以下示例策略:

(EventType IN ("File Data Write", "File Data Modification") AND
FileExt IN ("php", "php5", "phtml")
OR
EventType = "Network Establish" AND NetworkFlow = "OUT" AND
NetworkRemotePort IN ("445", "135", "139", "3389", "22", "88")) AND
ProcessName IN ("php-cgi.exe", "mysqld.exe", "redis-server64.exe")
OR
EventType = "Process Creation" AND
(ProcessName IN ("cmd.exe", "powershell.exe", "pwsh.exe") OR
ProcessName IN ("whoami.exe", "systeminfo.exe", "ipconfig.exe",
"netstat.exe", "certutil.exe")) AND
ProcessParentName IN ("php-cgi.exe", "mysqld.exe", "redis-server64.exe")

为了证实策略的有效性,我们在一台 Windows Server 2019 服务器上部署了通达 OA V11.2 与复杂之眼 EDR 客户端。

部署完成后,使用上述提到的 2020 年 4 月公开的漏洞,模拟攻击者对这个服务器系统进行渗透测试。

  1. 使用公开的利用程序一键上传 PHP WebShell

  2. 通过 PHP WebShell 执行系统命令,如 ipconfig 和 whoami 等。

从漏洞利用的结果来看,名为 test.php 的 PHP WebShell 被成功部署,但没有命令的执行结果,表明系统命令并没有成功执行,这似乎对渗透测试人员来说不是一个好迹象。

回到复杂之眼 EDR 后台,我们可以观察到目标系统产生了警报,并向安全人员发送了邮件提醒。

  • 安全警报邮件

  • 检测仪表盘

  • 威胁细节

  • 事件猎手
    通过前面制定的策略,我们还发现了 PHP WebShell 部署的关键数字证据。

我们并没有针对通达 OA 进行特定的策略指定,而这场游戏却已经结束了。

OA 市场未来会出现新的高危零日漏洞吗?它们可以逃避下一场由我们主导的猎杀游戏吗?

关于复杂之眼

复杂之眼端点检测与响应系统(MultiEye EDR),依托领先的终端安全大数据技术,实现了与传统安全行业完全不同的,基于云的终端安全服务(SaaS EDR),并开展基于云的托管安全服务(MDR),快速地揭露潜藏在客户网络深处的恶意活动者,可以向客户提供网络安全高级威胁狩猎(APT Hunter)、快速应急响应、调查取证与高级别的网络安全咨询服务。


我们可以发现并挫败一切网络攻击,保护您的网络安全。

立刻申请试用:https://www.mistiny.com/index.php/trial-submit/