从CPU特权级到后渗透：系统权限与信息收集完整技术体系

系统权限与信息收集：从CPU架构到后渗透实战的完整技术体系

搞安全这么多年，我一直觉得有个现象挺有意思：很多人一上来就盯着“怎么提权”“怎么拿shell”，但对底层那几个基础概念——比如CPU特权级、内核态和用户态的边界、权限模型到底怎么设计的——往往一知半解。结果就是，渗透测试做到一半，碰到个奇怪的权限报错，或者某个提权手段换了台机器就不灵了，完全摸不着头脑。说白了，系统权限和信息收集这套东西，不是靠背几个漏洞利用命令就能搞定的，它是一套从硬件到操作系统、再到应用层的完整技术链路。这篇文章，我就想把这套体系从头到尾捋一遍，从CPU架构讲起，一路聊到后渗透阶段的实战思路，希望能帮你把技术拼图补完整。

这套体系适合谁？我觉得适合两类人：一类是刚入行的安全从业者，整天跟“权限”打交道但总觉得隔层纱；另一类是做开发或运维的朋友，想搞清楚自己部署的应用为什么老是报权限拒绝，系统被攻破后攻击者到底做了什么。无论你是哪类，读完这篇文章，你对“权限”这个词的理解应该会明显上一个台阶。

1. 先看地基：为什么一切权限问题都要回到CPU架构

1.1 从CPU特权级说起

聊权限，不能只聊Linux的chmod、Windows的ACL，得先看最底层的东西——CPU的特权级（Privilege Level）。

以x86架构为例，CPU设计了4个特权级，编号从0到3。数字越小，权限越高。操作系统内核跑在Ring 0，拥有对硬件资源的完全控制权；普通的应用程序跑在Ring 3，也就是最外层，几乎什么都碰不到。至于Ring 1和Ring 2，在主流操作系统里基本没有实际使用，主要是一些虚拟化或特殊驱动场景才会涉及。

操作系统的整个权限体系设计，核心就是在Ring 0和Ring 3之间划出一条清晰的隔离线。如果你在Linux里执行一条命令，用户态的进程想读一个文件、开一个网络连接、分配一块内存，都必须通过一个中间层——系统调用（System Call），由CPU切换到内核态去执行真正的操作，再把结果返回给用户态。

你可能会问，这不就多了很多开销吗？没错，这就是为什么上下文切换（Context Switch）在高性能服务里是个不能忽视的成本因素。但这套设计带来两个决定性好处：

• 普通程序无法直接访问硬件，更无法篡改内核数据结构。
• 即使某个用户态进程被攻破，攻击者拿到的也只是Ring 3的权限，想触碰内核还得再跨一次门。

实际上，现代CPU还引入了更多安全机制来加固这条边界，比如SMEP（Supervisor Mode Execution Prevention）和SMAP（Supervisor Mode Access Prevention）。简单说，就是让内核不再盲目执行或访问用户态的内存区域。这直接导致了很多老式提权攻击手段失效——攻击者没法在用户态准备好shellcode，然后骗内核跳过去执行了。

1.2 操作系统权限模型是怎么架在CPU之上的

CPU提供硬隔离，操作系统在软层面做权限管理。以Linux为例，经典的权限模型是“用户-组-其他人”（User-Group-Other），配合读、写、执行三种权限位。这套模型简单可靠，但粒度很粗。你很难做到“这个文件A用户能读，B用户能读但不能看内容，C用户只能看文件名”这种精细控制。

所以就有了更灵活的方案：ACL（Access Control List，访问控制列表），它允许你给任意一个用户或组单独指定权限。再往上，还有SELinux、AppArmor这类强制访问控制（MAC）机制，它们跟传统的自主访问控制（DAC）是两套逻辑。DAC是“文件的主人说了算”，MAC是“系统的安全策略说了算”——即使root想把某个进程的权限全部放开，如果SELinux策略不允许，照样被拦截。

我实测过很多次，在启用SELinux的较新版本系统上提权或跨目录读取文件，经常遇到“明明权限是777，为什么还是Permission denied”的诡异情况。新手最容易在这里栽跟头。所以，在排查权限问题时，第一步从来不是去看chmod和chown，而是先确认SELinux或AppArmor是否处于 enforcing 状态。

Windows这边也是类似的思路，但实现不同。Windows用访问令牌（Access Token）来描述一个进程的安全上下文，每个进程启动时都带着一个令牌，令牌里包含了用户SID、组SID、特权列表等信息。你右键“以管理员身份运行”，本质上是触发UAC机制，生成一个拆分令牌（Filtered Token），把管理员权限卸掉一半，只有通过特定方式提升，才能拿到完整的高权令牌。

理解了这层，你再看很多提权漏洞的原理就会顺很多——大多数本地提权漏洞，本质是“一个在Ring 3跑的普通进程，找到了一条路，能够以内核视角（Ring 0）执行代码或读写数据”。CPU架构、操作系统权限模型、应用层配置，这三个层面是互相配合又互相制约的。只看最上层应用配置，很多问题解释不清；只盯内核漏洞，又容易忽略配置类错误。

1.3 权限体系设计里的“最小化原则”到底怎么落地

权限这块有一个绕不开的金标准——最小权限原则（Principle of Least Privilege）。这个概念你肯定听过，但真正落地到系统上，很多人就含糊了。

我见过很多业务系统的部署方案：数据库连接串写在配置里，服务用root跑的，整个目录是777。问运维为什么这么做，答复往往是“这样省事”“之前没那么多讲究”。结果就是：一个最普通的WebShell，就能直接读数据库账号密码、写文件到任意目录，甚至直接落地一个计划任务反弹回来。整套权限体系形同虚设。

最小权限原则的落地，不是一句口号，而是一组具体动作：

• 服务进程用独立低权限用户运行。比如Nginx就用nginx用户，不要用root或www-data一锅炖。
• 目录和文件权限遵循“按需分配”。日志目录需要写，但代码目录只读就好。
• 临时提升权限用sudo或runas，并且白名单化，禁用ALL ALL这种写法。
• Linux下用systemd的CapabilityBoundingSet做能力限制，Windows下用Managed Service Account或组托管服务账号（gMSA）来管理服务凭据。
• 敏感文件（如包含访问密钥的凭据文件或备份文件）的访问权限要单独收紧，敏感目录下避免出现无密码保护的压缩包或明文备份。

这么做，不是为了防住所有攻击，而是为了增加攻击者“从头到尾走通”的成本。安全本来就是层级防御，权限最小化是第一级也是最重要的一层。

2. 信息收集：做不好这一步，后面全是空中楼阁

2.1 主机信息收集到底要收什么

信息收集是整个体系里最容易被低估的环节。很多人拿到一台机器，第一反应就是跑漏洞扫描、试几个公开Exploit，没成功就不知道干什么了。真正专业的做法，是先把这台机器里里外外摸清楚。

主机层面的信息收集，我习惯分成六个维度：

• 系统与内核信息：操作系统版本、内核版本、补丁级别。这一步决定了可以用哪个内核漏洞。
• 用户与权限信息：当前用户、所属组、UID/GID、所有可登录用户、sudo权限配置、Windows下的用户和组成员关系、登录会话、令牌情况。
• 网络信息：所有网卡IP、路由表、ARP缓存、DNS配置、监听端口、现有的TCP/UDP连接、防火墙规则。这能为横向移动和网络拓扑判断提供依据。
• 进程与服务：正在运行的进程、服务列表、计划任务。重点关注杀毒软件、EDR、运维监控Agent等安全产品——这直接决定后面能做什么动作。
• 敏感文件与配置：历史命令记录、bashrc和profile、SSH私钥、配置文件里的数据库账号密码、Windows下的注册表自动启项、桌面和回收站的文件、临时目录里的残留。
• 日志与痕迹：登录日志、sudo记录、系统日志（Windows下是事件日志）。这既是信息收集的一部分，也是后续清理痕迹时的重要参考。

这里我特别想强调一个容易被忽略但极其关键的维度：用户环境变量。我在多次模拟项目中都发现，应用在运行时会往用户环境变量或系统环境变量里塞各种临时凭据，比如云服务商的临时密钥、数据库连接字符串。如果你拿到一个WebShell后，先用env或Get-ChildItem Env:看一眼环境变量，经常能捡到意外的“钥匙”。

2.2 网络与凭据收集：从主机延伸到内网

主机信息摸完之后，就要把视野放到网络上。记住一句话：单台机器只是入口，内网才是目标。

网络信息收集的重点有这么几个：

• 网段和路由的梳理，确定当前机器处于哪个内网区域，能访问哪些网段。常见做法是通过路由表、ARP缓存结合被动流量观察判断。如果能抓包，DHCP请求网关信息也有参考价值。
• 内网其他存活主机的发现。Windows环境下，同一网段内可以通过NetBIOS、LLMNR、mDNS协议探测，也可以通过SMB空会话或MS-SAMR协议枚举用户名。Linux下可以用ARP扫描和ICMP探测。不建议在一开始就上大量高强度的全端口扫描，动作太大会很快触发告警。
• 关键服务的信息收集。比如445端口的SMB服务版本、22端口的SSH版本、3389远程桌面是否开放，以及内网是否存在域环境（通常找LDAP 389、Kerberos 88、SMB 445结合DNS SRV记录三者协同判断）。

我再提一个很多教程不会细讲但实战价值极高的点：凭据信息收集。

很多人以为凭据收集就是翻/etc/shadow或者偷内存里的密码，其实远不止这些。工程上常见的凭据来源包括：

• 浏览器保存的密码和Cookie。很多内部系统的密码都存在浏览器里，而且往往比想象中要多得多。
• 各种客户端的配置文件。邮件客户端、IM工具、SVN/Git客户端、云盘客户端，它们的本地配置经常带有明文或可解密的登录凭据。
• SSH密钥和配置文件~/.ssh/目录。一个无密码保护的私钥文件能带来多大的横向移动便利，不用我多说。
• 临时文件和核心转储（Core Dump）。应用崩溃会产生core文件，里面可能有内存中的敏感数据。
• Windows的SAM文件、LSA Secrets、DPAPI凭据。涉及离线分析和哈希破解，Windows下是另一套完整体系。

2.3 信息收集里最容易漏掉的几个点

做久了你会发现，真正拉开差距的不是“收得多不多”，而是“有没有收到点子上”。以下几个点我几乎每次都会检查，但网上的常规教程很少提：

第一，已断开的网络连接和残留的挂载点。有些系统之前挂载过NFS共享、CIFS共享或者远程FTP目录，虽然现在断开了，但残留的挂载记录和客户端缓存里，往往会留下服务器地址、端口，甚至认证信息。Linux下看/etc/fstab，Windows下看注册表或网络驱动器映射历史。

第二，软件包管理器缓存。APT、YUM、pip、npm 这些包管理器的缓存目录里，可能留着下载过的私有包，或者包里有内网仓库地址和token。我有一次就是从/root/.npmrc里拿到了内网私有npm仓库的访问token，那东西在后续横向移动中帮了大忙。

第三，历史命令里全是“矿”。这条听起来像废话，但我见过很多人只是history扫一眼就完事儿，没有系统性地去翻.bash_history、.zsh_history、.python_history，以及root用户的历史记录。更隐蔽的是，有些应用会在运行脚本里用set -x打印命令执行过程，日志文件里全是数据库连接串。

信息收集这条线，我的经验总结就是一句话：带着目的去收，收完立刻归档整理。看一眼花半小时，后面提权成功率和横向速度翻一倍，这笔账怎么算都不亏。

3. 拿到入口之后：权限识别与提升的思路

3.1 先别急着打，看清手里的牌

拿到一台机器的低权限执行环境（比如WebShell、漏洞利用后的反弹会话），很多人的第一反应是“赶紧提权”。但我建议先做一件事：把现有的权限边界看清楚。

需要考虑的问题很具体：

• 当前进程是以什么用户运行的？该用户属于哪些组？sudo权限如何？
• 是否具备以另一用户身份执行命令的能力？是否具备读取敏感文件的权限？
• 当前内核版本有没有已知漏洞？系统补丁到了什么日期？
• 是否存在高权限的进程、服务或计划任务，且其配置存在可利用的薄弱点？
• 系统的安全机制（SELinux、AppArmor、杀毒软件、EDR）开启到什么程度？

这些问题梳理清楚了，你才知道该走哪个方向。如果当前用户本身就有sudo -l权限，你还在那费劲找内核漏洞，这不是绕远路吗？反过来，如果是一个严格受控的系统中，内核版本非常新，但存在某些历史遗留问题——比如一个以root运行的临时脚本每次启动一个由用户可写的目录里的程序——那方向就完全不同。

3.2 常见提权路径的分类逻辑

提权手段五花八门，我会把它们大致分成四类，每一类的适用场景和成功率差别很大。

第一类：配置类提权。这是最优先看的一类，因为成功率高、动静小、不容易触发告警。典型场景包括：

• sudo权限配置不当：比如某个服务账号能够无密码执行部分命令，而这个命令本身具备写文件的能力，就能组合出提权效果。
• 用户可写的脚本或二进制被高权限执行：看计划任务、服务、启动脚本里有没有指向用户可写目录的情况。
• 文件拥有者不匹配：某些文件或目录被低权用户拥有，但被高权进程读取执行。
• SUID/SGID权限位长期挂着：这类问题在老旧系统里尤其常见，能用find / -perm -4000 2>/dev/null快速排查出来。

第二类：内核漏洞提权。这类大家最熟悉。原理就是我前面讲的——利用内核里的漏洞，把用户态权限提升到内核态。适用场景是“内核版本较老、且存在公开可用的稳定Exp”。但我要提醒一句：在有EDR和杀毒软件的生产环境里，直接丢一个公开Exp上去，大概率会被拦，而且动态检测的响应速度比你想象中快。所以这类手段要用，也一定要先确认目标环境的安全软件情况，尽量选主动防御拦截概率低的思路。

第三类：服务漏洞提权。系统里可能跑着一些以高权限运行的第三方服务。比如某个老版本的Web服务、数据库实例、打印服务、甚至防病毒软件本身，都存在过提权漏洞。这类漏洞利用有个前提——你能访问到那个服务，并触发它的漏洞。在实战环境中，这类场景也经常是“撞运气”，但一旦撞上了，成功率和隐蔽程度通常都不错。

第四类：凭据利用提权。严格来说这不算“提权”，但实战中几乎都是这么干的——通过抓取或读取到高权限用户的凭据，然后正常切换身份。比如拿到root的SSH私钥，直接登录root；在Windows下抓到管理员账户的哈希，用哈希传递（Pass-the-Hash）直接进。这类方法在Windows内网环境中出现的频率比内核提权还要高得多。

3.3 提权成功的关键：不是打，而是选

我见过太多新手在提权阶段硬冲硬打，浪费了一堆时间在成功率极低的漏洞利用上，却放着系统里明摆着的访问密钥和运维脚本不管。提权这件事，方向选择比单点技术更重要。

我的习惯是：5分钟看配置，30分钟看凭据，最后才考虑内核漏洞。先花几分钟把上面那些配置类检查项过一遍，确实没有突破口，再回到凭据收集上深挖一下，看有没有遗漏的备份、可读的初始化脚本、不带密码的私钥。如果都没有，才去查内核与第三方服务的公开漏洞，评估利用难度和风险后再动手。

另外，提权过程中有一个特别容易被忽略的坑：文件系统权限和挂载选项。比如/tmp如果挂载时带了nosuid，那你在 /tmp 里放一个SUID程序是起不到提权作用的。再比如某个目录虽然是777，但父目录带了“仅允许所有者进入”的权限，那你连进去都费劲。Linux的权限判断是沿着路径一级一级查的，每一级都要有足够的权限，缺一环就走不通。

4. 后渗透：从单点突破到内网控制的完整逻辑

4.1 后渗透到底在干什么

“后渗透”这个词听起来挺玄乎，其实说透了就是一句话：拿到立足点之后，怎么巩固、怎么扩展、怎么收尾。它的核心目标不是打更多机器，而是围绕核心价值资产做文章。对内网漫无目的地横冲直撞，只会把动静搞得越来越大。

后渗透阶段我通常分成四个环节：

• 巩固立足点：确保当前会话不被踢出去。比如持久化、隐藏进程、可控通道，但重点是“不被发现”而非“在不在”。
• 横向移动：以当前机器为跳板，逐步扩大控制范围，拿到更多主机、更多凭据，向核心网络区域靠近。
• 目标达成：根据项目目标定位关键资产——数据库、源代码仓库、管理后台、备份文件，或者直接控制域控。
• 收尾与证据保留：取证级证据的完整记录，以及需要时的现场清理与恢复。

4.2 横向移动的几个关键技术点

横向移动是后渗透里最核心的技术环节。它的逻辑基础其实特别简单：内网环境里，多台机器共用同一套身份认证体系（域），或者存在大量重复密码、共享凭据，这就导致你在一台机器上拿到的凭据，很可能在另一台机器上也能用。

具体手法上，Windows环境里常见的是哈希传递、票据传递、远程执行服务（计划任务、WMI、PowerShell远程会话）等；Linux环境里则围绕SSH密钥、共享的NFS目录、自动化运维工具的管理账号做文章。但比手法更重要的是如何发现并利用内网信任关系。

我用一个生活类比解释一下：你把小区里每户人家都看成一台主机，正常情况下你没有钥匙进不了门。但这户人家有个习惯——把备用钥匙放在门口地毯下面（共享账密），而且好几户人家都用同一家物业公司，物业那边的总钥匙（域控权限）能打开所有门。你只要搞到了其中一把钥匙，挨个门试一遍，很快就能找到更多能进的房间。

我实测下来的经验是：横向移动的成败，往往不取决于你掌握了多少高级技术，而取决于你掌握的内网情报有多准。比如知道内网哪台机器是备份服务器、哪台机器是运维跳板机、哪个网段运行着核心业务，都比多一个利用手法有价值得多。

4.3 关于持久化和痕迹清理的几点实在建议

我见过很多教程把持久化讲得天花乱坠——又是注册表自启、又是计划任务、又是WMI事件订阅。这些技术本身没问题，但我想提醒几个更实际的点：

第一，持久化要跟业务结合。你往一台已经被淘汰的临时服务器上种了计划任务，结果这台服务器一周后因为磁盘满了被运维重启清了一遍，任务就没了。真正稳的持久化，是藏在业务的正常行为里的。比如放在应用自身的定时任务、日志轮转脚本、备份机制里，这些东西运行起来不突兀、不容易被当成恶意行为。

第二，优先利用“合法”通道。比如在一台内网机器上留一个带密钥的SSH公钥，或者利用现有运维工具的Agent功能。这些手段都符合系统的正常管理路径，告警体系大概率不会拦。

第三，痕迹清理不是“删日志”，而是“恢复原状”。我见过有新手把/var/log/auth.log整个删掉的，那反而等于告诉管理员“这里出事了”。更稳妥的做法是：在不破坏日志结构的前提下，只删除与你活动相关的行，或者利用日志轮转机制，把你的记录推到正常的轮转周期里自然消失。别小看Windows的事件日志，删除单条事件日志还相对隐蔽，删除整个事件日志文件是要慎重再慎重的。

第四，也是最容易被忽视的——备份文件。我在多次模拟项目中都会刻意检查这一点：攻击者在本地执行过的命令、上传过的权利用具、临时解压过的压缩包，很可能在系统备份或卷影副本里留下痕迹。所以真正的痕迹清理，要从备份存在的角度重新审视。

5. 常见问题与排错实录：我踩过的坑你都别再踩

5.1 权限提升失败的最常见原因

我整理了一个“提权失败排查清单”，按命中率排序，基本能覆盖90%的情况：

实际排错时，我最常用的一招是：开启详细模式重新跑一遍，把每个阶段的操作和报错都记下来。很多时候，提权工具之所以失败，不是那个漏洞失效了，而是某个前置条件没有被满足。比如需要某个内核模块加载了，或者某个系统调用没有被沙箱拦截。

5.2 信息收集不够导致的方向误判

我分享一个之前模拟项目里的真实场景，匿名化处理一下：某次授权测试中，我在一台业务服务器上拿到了执行权限，当前用户是一个普通应用账号。按照常规思路，我先是去试内核漏洞，试了两个都没成功，浪费了一个多小时。后来停下来仔细看了一遍环境和配置，发现这个用户虽然不是管理员，但它有机会通过一个运维脚本以更高权限执行部分命令，而且这台机器上还挂着另一块数据盘，备份目录里放着一个运维账号的密钥文件。方向一变，五分钟之内就拿到了完全的控制权。

这个案例的教训很典型：不是你没有权限，而是你没发现自己有权限。信息收集不是流程仪式，它是后续所有技术动作的依据。收得越扎实，方向越明确，成功率越高。

还有一个常见的坑是过度依赖自动化扫描工具。工具扫出来的结果和大而全，看起来信息量很大，但真正有价值的信息往往藏在“工具报错”和“扫描超时”的角落里。我建议把自动化工具当成辅助手段，花更多精力在手工查看配置、读日志和梳理服务关系上。

5.3 后渗透阶段最容易被发现的动作

根据我参与过的多次攻防对抗经验，以下动作在目标网络中暴露的风险最高：

• 大量端口扫描和全网段扫描。扫得太快、范围太广，是最快被暴露的特征。
• 上传大量工具。平均每个权利用具的体积都不小，上传和释放时的文件写入行为很容易被文件监控捕捉。
• 频繁的进程创建和可疑命令行。PowerShell执行带有编码参数的命令、创建计划任务、修改注册表自启，这些在EDR看来都是高危信号。
• 凭据访问行为。直接读取SAM文件、使用mimikatz这一类动作，在较新的防御体系下几乎没有隐藏空间。

我的建议是：能不扫就不扫，能少传工具就少传工具，能用系统自带功能就不引额外程序。后渗透阶段的生存法则不是“跑得快”，而是“活得久”。你在一台机器上踩点越多、动作越重，被发现的概率就越大，后面的路就越难走。

6. 把整套体系串起来：一个完整的实战决策思路

讲到这里，整套体系的技术面基本铺开了。但我觉得还有必要把这些部件组装成一个可执行的思路，因为你真正面对一台机器时，需要的不是一个知识点，而是一条决策链路。

我把这套链路总结成五个环节，环环相扣：

• 第一步：摸清硬件与系统底座的边界，确认CPU架构、内核版本、操作系统版本、虚拟化情况。
• 第二步：完整梳理当前权限上下文，用户在哪儿、组在哪儿、能力边界在哪儿、有哪些通道可借用。
• 第三步：做扎实的主机与网络信息收集，把所有可能通往下一层的钥匙都翻出来。
• 第四步：结合信息收集结果，选择提权或横向突破的具体路径，走阻力最小、动静最小的路线。
• 第五步：达成目标后，做好收尾工作，确保证据完整，痕迹收敛，通道可控。

这个链条每一步的输入端，都是上一步的输出端。你编译一个提权工具前，得先知道目标CPU是x86还是ARM；你决定横向移动路线前，得先知道内网服务靠什么身份认证；甚至你决定要不要碰某个服务前，都得先预估这个动作在目标安全体系里会不会触发响应的告警。

所以，我特别不喜欢把“安全”理解成“几个漏洞的组合”。真正的能力，是对整套体系的理解——从CPU架构的特权设计到操作系统权限模型，再到信息收集、提权、横向移动和后渗透的完整链路。任何一个环节缺失，都会成为你实战中的短板。

我自己走到现在最大的体会就是：技术不是越新奇越好，而是在对的时间做出对的选择，才最有价值。

写到最后，分享一个我个人的实操习惯。在每一次进入一台新环境之后，我会花大量时间维护一份“信息收集清单”，把IP、账号、开放端口、服务名、存在的凭据、可能走得通的路，全部做成结构化的笔记。很多人嫌麻烦，直接用临时文件对付，但等你同时推进三台以上机器的时候，就知道清晰的记录有多重要。那些临时的、零散的信息，一旦会话变动或者文件被清理，全部从头再来，那种损失比写笔记多花的时间大得多。

另外还有一个细节：无论你技术多熟练，在你开始在目标机器上做任何动作之前，先确认你对此有充分的授权。安全研究这件事本身是有价值的，但它的意义建立在合法的边界之内。专业的能力配上专业的操守，这条路才能走得更稳、更远。