系统权限与信息收集从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还引入了更多安全机制来加固这条边界比如SMEPSupervisor Mode Execution Prevention和SMAPSupervisor Mode Access Prevention。简单说就是让内核不再盲目执行或访问用户态的内存区域。这直接导致了很多老式提权攻击手段失效——攻击者没法在用户态准备好shellcode然后骗内核跳过去执行了。1.2 操作系统权限模型是怎么架在CPU之上的CPU提供硬隔离操作系统在软层面做权限管理。以Linux为例经典的权限模型是“用户-组-其他人”User-Group-Other配合读、写、执行三种权限位。这套模型简单可靠但粒度很粗。你很难做到“这个文件A用户能读B用户能读但不能看内容C用户只能看文件名”这种精细控制。所以就有了更灵活的方案ACLAccess 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/fstabWindows下看注册表或网络驱动器映射历史。第二软件包管理器缓存。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%的情况原因表现排查方法SELinux/AppArmor 拦截明明权限正确仍报 Permission deniedgetenforce/aa-status确认状态挂载选项nosuid/noexecSUID程序无法触发脚本无法执行mount查看挂载参数目录中间层权限不足文件权限是777但当前用户进不了所在目录逐级检查父目录权限目标架构不一致利用工具是编译给不同架构的版本或工具版本不匹配uname -m确认架构内核补丁已到较新日期公开漏洞已被修复或不受影响对比补丁版本确认漏洞影响范围杀毒软件或EDR拦截Exp执行后进程消失或报错动作被静默拦截检查进程是否存活、临时文件是否被清理实际排错时我最常用的一招是开启详细模式重新跑一遍把每个阶段的操作和报错都记下来。很多时候提权工具之所以失败不是那个漏洞失效了而是某个前置条件没有被满足。比如需要某个内核模块加载了或者某个系统调用没有被沙箱拦截。5.2 信息收集不够导致的方向误判我分享一个之前模拟项目里的真实场景匿名化处理一下某次授权测试中我在一台业务服务器上拿到了执行权限当前用户是一个普通应用账号。按照常规思路我先是去试内核漏洞试了两个都没成功浪费了一个多小时。后来停下来仔细看了一遍环境和配置发现这个用户虽然不是管理员但它有机会通过一个运维脚本以更高权限执行部分命令而且这台机器上还挂着另一块数据盘备份目录里放着一个运维账号的密钥文件。方向一变五分钟之内就拿到了完全的控制权。这个案例的教训很典型不是你没有权限而是你没发现自己有权限。信息收集不是流程仪式它是后续所有技术动作的依据。收得越扎实方向越明确成功率越高。还有一个常见的坑是过度依赖自动化扫描工具。工具扫出来的结果和大而全看起来信息量很大但真正有价值的信息往往藏在“工具报错”和“扫描超时”的角落里。我建议把自动化工具当成辅助手段花更多精力在手工查看配置、读日志和梳理服务关系上。5.3 后渗透阶段最容易被发现的动作根据我参与过的多次攻防对抗经验以下动作在目标网络中暴露的风险最高大量端口扫描和全网段扫描。扫得太快、范围太广是最快被暴露的特征。上传大量工具。平均每个权利用具的体积都不小上传和释放时的文件写入行为很容易被文件监控捕捉。频繁的进程创建和可疑命令行。PowerShell执行带有编码参数的命令、创建计划任务、修改注册表自启这些在EDR看来都是高危信号。凭据访问行为。直接读取SAM文件、使用mimikatz这一类动作在较新的防御体系下几乎没有隐藏空间。我的建议是能不扫就不扫能少传工具就少传工具能用系统自带功能就不引额外程序。后渗透阶段的生存法则不是“跑得快”而是“活得久”。你在一台机器上踩点越多、动作越重被发现的概率就越大后面的路就越难走。6. 把整套体系串起来一个完整的实战决策思路讲到这里整套体系的技术面基本铺开了。但我觉得还有必要把这些部件组装成一个可执行的思路因为你真正面对一台机器时需要的不是一个知识点而是一条决策链路。我把这套链路总结成五个环节环环相扣第一步摸清硬件与系统底座的边界确认CPU架构、内核版本、操作系统版本、虚拟化情况。第二步完整梳理当前权限上下文用户在哪儿、组在哪儿、能力边界在哪儿、有哪些通道可借用。第三步做扎实的主机与网络信息收集把所有可能通往下一层的钥匙都翻出来。第四步结合信息收集结果选择提权或横向突破的具体路径走阻力最小、动静最小的路线。第五步达成目标后做好收尾工作确保证据完整痕迹收敛通道可控。这个链条每一步的输入端都是上一步的输出端。你编译一个提权工具前得先知道目标CPU是x86还是ARM你决定横向移动路线前得先知道内网服务靠什么身份认证甚至你决定要不要碰某个服务前都得先预估这个动作在目标安全体系里会不会触发响应的告警。所以我特别不喜欢把“安全”理解成“几个漏洞的组合”。真正的能力是对整套体系的理解——从CPU架构的特权设计到操作系统权限模型再到信息收集、提权、横向移动和后渗透的完整链路。任何一个环节缺失都会成为你实战中的短板。我自己走到现在最大的体会就是技术不是越新奇越好而是在对的时间做出对的选择才最有价值。写到最后分享一个我个人的实操习惯。在每一次进入一台新环境之后我会花大量时间维护一份“信息收集清单”把IP、账号、开放端口、服务名、存在的凭据、可能走得通的路全部做成结构化的笔记。很多人嫌麻烦直接用临时文件对付但等你同时推进三台以上机器的时候就知道清晰的记录有多重要。那些临时的、零散的信息一旦会话变动或者文件被清理全部从头再来那种损失比写笔记多花的时间大得多。另外还有一个细节无论你技术多熟练在你开始在目标机器上做任何动作之前先确认你对此有充分的授权。安全研究这件事本身是有价值的但它的意义建立在合法的边界之内。专业的能力配上专业的操守这条路才能走得更稳、更远。