MemFiles 是一套用于 CobaltStrike 的工具包，它使操作员能够将 Beacon 进程产生的文件写入内存，而不是写入目标系统的磁盘。它已成功在 Windows 7、10 和 11 上测试通过；相应的服务器版本应该也可以正常工作。MemFiles 仅支持 x64 Beacon。
它是通过 Hook NTDLL.dll 中的多个不同 NtAPI，并将对这些 API 的调用重定向到已注入 Beacon 进程内存空间的函数来实现的。
MemFiles 假定 Beacon 进程中有一份干净/未被 Hook 的 NTDLL 副本。如果 Beacon 进程中仍存在 EDR Hook，则不对 MemFiles 的可行性做任何保证。使用 MemFiles 之前，请修复/刷新 NTDLL！
MemFiles 工具包中定义了一个“特殊的”、不存在的目录；任何写入此特殊目录的文件都会被 MemFiles 捕获并写入内存，之后可以下载到 Teamserver。
MemFiles 与大多数（并非全部）在 Beacon 进程内运行、并且可以指定输出目录的工具兼容。它不需要提升权限即可工作。
这包括： -BOF -.NET 程序集（使用类似 inline-executeAssembly 的工具内联运行） -PE（使用类似 Inline-Execute-PE 的工具内联运行）
所有这些工具都是兼容的，因为它们在 Beacon 进程内运行，而相关的 NtAPI 已经被 Hook。
MemFiles 不适用于以下情况： -execute-assembly -shell -run
这些都不兼容，因为它们都会生成其他进程，而这些进程的 NtAPI 没有被 Hook。
当 Rubeus、SharpHound、Procdump 和 Powershell 等工具在 Beacon 进程内运行时，MemFiles 已成功测试通过。
克隆仓库，并可选地修改 /PIC/Source/NtCreateFile.c 和 /PIC/Source/NtOpenFile.c 中第 56 行定义的 hookdir 变量。这个变量是“特殊”目录，用于告诉 MemFiles 应该拦截正在创建的文件。hookdir 变量默认设置为“redteam”。确保该变量不是目标系统上的真实目录，并且在两个文件中保持一致！
运行 'make all' 来编译所需的 BOF 和 PIC 函数。
将 MemFiles.cna 加载到 CobaltStrike 客户端中。确保 CobaltStrike 运行的目录对你的用户可写；MemFiles 会在那里创建一个文本文件（memfiles.txt），以确保 MemFiles 正常运行所需的数据可用。
MemFiles 可以配置为在每个连入 Teamserver 的新 Beacon 中自动安装；这是通过使用 MemFiles->Config 菜单项实现的。默认情况下，MemFiles 不会在新 Beacon 中自动安装。请注意，这是一个全局设置；如果有两个客户端连接到 Teamserver 并且都加载了 MemFiles.cna，那么如果客户端 A 切换了“Install on beacon initial”设置，该更改也会对客户端 B 生效！
MemFiles 由 4 个面向目标的命令（运行 BOF）和 1 个内部命令（操作项目数据结构）组成。
面向目标的命令：
内部数据结构：
meminit 负责在 Beacon 进程中安装 MemFiles。
MemFiles 所 Hook 的 NtAPI 列表如下：
meminit 执行以下主要操作：
memlist 用于显示 MemFiles 在给定 Beacon 中当前存储的所有文件。
显示多个字段，其中与用户最相关、最关心的是文件名和存储数据的长度。
memfetch 用于实际获取 MemFiles 在给定 Beacon 中存储在内存中的文件。
默认情况下，memfetch 会获取 MemFiles 存储的所有“句柄”已被关闭的文件。这个设计选择是为了避免尝试下载程序/应用程序尚未写入完成的文件而出现的问题。
这意味着，如果程序/应用程序没有关闭它打开的文件句柄，memfetch 将不会下载该文件。 可以通过在 memfetch 中使用“force”参数来缓解，即 'memfetch force'，以获取内存中的所有文件，而不管其句柄状态如何。
memfetch 从内存中获取的文件会作为下载项发送回 Teamserver，并可以通过 CobaltStrike 中的 Downloads 选项卡将文件从 Teamserver 同步到客户端。
一旦文件被 Teamserver 下载，它就会从 Beacon 进程的内存中清除，并且其通过 memlist 显示的条目也会被删除。
memclean 负责从 Beacon 进程中清理和移除 MemFiles。
MemFiles 的标准用法是安装它并让它在 Beacon 的整个生命周期内保持安装状态；但是，如果你想将 MemFiles 与某个工具结合使用来捕获和获取文件输出，然后卸载 MemFiles 以便它的产物不留在内存中，可以使用 memclean 将 Beacon 进程恢复到运行 meminit 之前的状态。
这包括：
请注意，在 memclean 执行这些操作之前，它会强制下载 MemFiles 存储在内存中的任何文件。如果你打算将 MemFiles 与单个工具一起使用然后移除它，可以跳过 memfetch，直接使用 memclean 一次性获取文件并从 Beacon 进程中移除 MemFiles。
memtable 用于显示和跟踪当前安装了 MemFiles 的 Beacon 的信息。它还显示全局配置信息。
每个 CobaltStrike 客户端都有自己的 memtable；MemFiles 尽最大努力确保其数据在所有连接的 CobaltStrike 客户端之间保持同步，以便所有操作员可以在所有 Beacon 中使用 MemFiles。更多信息请参阅“Design Considerations and Commentary”。
使用 meminit 命令在 Beacon 中初始化 MemFiles。这可以通过切换 MemFiles->Config 菜单中的选项来配置为自动发生。
初始化 MemFiles 后，你现在可以使用你最喜欢的工具将文件写入内存！具体方式取决于具体工具；有些工具允许你指定一个目录来输出多个文件，而其他工具则允许你为工具创建的单个文件指定绝对路径。下面是一些示例：
这里我们指定 SharpHound 应将所有生成的文件输出到 c:\redteam\ 目录（我们的特殊 MemFiles 目录），并且不要压缩文件；MemFiles 不支持程序从内存读取文件，只支持写入，因此 SharpHound 中的 zip 功能不起作用。
对 Rubeus 使用“dump”命令，并指示它将所有控制台输出发送到一个文件（位于我们的特殊目录中）
在这个例子中，使用 Inline-Execute-PE 将 powershell.exe 加载到 Beacon 进程中，并运行 'Get-ADUser' 来获取域用户列表。通过管道和 'out-file'，数据可以被写入内存，然后被获取。
当你想要获取文件时，运行 memfetch：
当你使用完 MemFiles 和/或不想让它继续安装在 Beacon 进程中时，运行 memclean：
请注意，在上面的示例中，有一个文件尚未下载；memclean 会先下载该文件并将其从内存中清除，然后再卸载 MemFiles。
使用 memtable 查询 MemFiles 的状态和配置。在进行长时间操作时，从 memtable 中清除死/旧 Beacon 的条目，以避免混乱。
正如简介中强调的，MemFiles 需要 Beacon 进程中有一份干净的 NTDLL 副本才能正常工作。这是必要的，因为它会读取 NtFunction 中的原始字节，并将其中一些字节复制到 trampoline，trampoline 之后用于完成 MemFiles 不应干预的 NtFunction 正常调用。这个主题在“Technical Details, Design Considerations, and Commentary”部分中有更详细的讨论。
MemFiles 为每个文件初始分配 1048576 字节；随着数据写入内存，它可以并且将会根据需要扩展此分配以容纳更大的文件。
存储在 MemFiles 结构体中的文件名是从传递给替换后的 NtCreateFile 函数的参数中解析出来的。MemFiles 以一种相当简单的方式做到这一点：在文件路径参数中定位“特殊”目录，将指针移动到其末尾，然后将其递增 1 以考虑分隔“特殊”目录和文件名的 '\' 字符。例如，在路径 'C:\users\tom\redteam\myfile.txt' 中，MemFiles 定位到 'redteam'，考虑反斜杠字符，然后选择 'myfile.txt' 作为文件名。
MemFiles 不关心文件路径中的任何前置目录；就 MemFiles 而言，'C:\redteam\myfile.txt' 和 'c:\users\tom\appdata\local\redteam\myfile.txt' 都是同样有效的路径。
鉴于 MemFiles 从文件路径中解析文件名的方式，应该注意 MemFiles 不支持创建子目录；这意味着 MemFiles 无法与某些工具正常配合，例如试图创建 c:\redteam\mynewdir\file1.txt、c:\redteam\mynewdir\file2.txt、c:\redteam\mysecondir\file3.txt 等的工具。
MemFiles 所 Hook 的 NtAPI 已被确定为各种程序用于 I/O 操作的 API。如前所述，已成功与 MemFiles/这组 Hook 的 NtAPI 一起测试的工具/功能包括：SharpHound、Rubeus、Powershell、Procdump、BOF、执行文件写入操作的通用 C 程序，以及 CobaltStrike 的 bupload_raw 命令（该命令允许操作员指定远程文件位置）。当然还有其他工具可以开箱即用地与 MemFiles 配合使用；其他工具则不兼容。
乍一看，Windows 文件创建过程似乎很简单：NtCreateFile->NtWriteFile->NtClose。但在深入研究这个项目后，我很快就发现还涉及许多其他 API，而且有趣的是，这些其他 API 因程序而异。有些程序在其 I/O 过程中调用 Win32 API SetFilePointerEx，后者又会调用 NtAPI NtSetInformationFile。其他程序，如包括 SharpHound 在内的 .NET 程序，最终会调用 NtFlushBuffersFile。
由于创建和写入文件缺乏单一通用的 API 调用链，因此根据 MemFiles 所使用的工具，存在不兼容的空间。程序可能会调用 MemFiles 尚未 Hook 的另一个 NtAPI，将 MemFiles 在替换的 NtCreateFile 函数中创建的假句柄传递给它，从而导致 "Invalid Handle" 错误并停止执行。其他程序会执行 MemFiles 无法充分伪装/替换的更复杂操作。已经发现的一个此类不兼容性是 ADExplorer.exe。
ADExplorer.exe 是微软签名的二进制文件，用于活动目录枚举。在运行时，ADExplorer 将数据写入指定的输出文件，然后稍后返回并引用它，最后在执行结束时将最终输出写入该文件。因为它将输出文件用作某种缓存，所以它必须能够读取已经写入文件的数据，而它极不可能以任何简单、可预测的方式这样做。
MemFiles 目前不支持程序或应用程序读取内存中的文件，但通过进一步充实自定义 NtReadFile 函数并向 MemFiles 结构体添加一些额外的变量/数据跟踪，这应该是可能的。
ADExplorer 还带来了其生成文件大小的另一个挑战。在大型企业环境中，输出文件可能超过 1GB；虽然 MemFiles 在程序上应该能够处理这个问题，但它肯定不适合这种用例。
