内网渗透(2)：端口探测与权限提升

上次那篇总结的是通道构建和主机发现部分，但是在稳定连上一台机器，并且知道了一批IP后，要怎么往下走。

因此，这一篇主要是两个问题

1. 目标主机开放了哪些端口，对应什么服务
2. 当前跳板机上的权限够不够，是否存在本地提权风险

端口识别主要是为了确定后续的测试方向，比如一些固定的端口对应的服务可能会有特定手法或者漏洞可以利用。权限提升顾名思义，我们肯定希望在当前拿到shell的主机上的权限是越高越好的，因此在当前用户权限不足时，就需要找办法把当前用户变成root或者admin。

1. 端口探测

1.1 常见服务端口

端口识别不是为了把所有端口都扫一遍，而是通过开放端口判断资产类型、业务角色和后续测试优先级。实际内网环境中，可以优先关注下面几类端口。

远程管理类

端口	服务	关注点
22	SSH	Linux 服务器、网络设备、跳板机，关注弱口令、密钥复用和登录来源
23	Telnet	老旧设备或网络设备，明文传输，优先级较高
3389	RDP	Windows 远程桌面，关注暴露范围、登录来源和账号复用
5985/5986	WinRM	Windows 远程管理，常见于远程运维和横向移动场景
623	IPMI	服务器带外管理接口，若暴露范围过大或存在弱口令，风险较高

Windows 域与文件共享类

端口	服务	关注点
53	DNS	域环境中常用于定位域控和内部系统
88	Kerberos	域认证核心端口
135	RPC	Windows 远程管理、WMI、DCOM 等相关
389/636	LDAP/LDAPS	域信息查询，关注异常枚举行为
445	SMB	文件共享、远程管理和横向移动相关，内网重点端口
464	Kerberos 改密	常见于域控
3268/3269	Global Catalog	域控全局编录服务

如果一台主机同时开放 53、88、389、445、464，通常可以高度怀疑它是域控或域核心服务器，但仍需要结合主机名、DNS SRV 记录、LDAP 信息和资产台账确认。

数据库与缓存类

端口	服务	关注点
1433	Microsoft SQL Server / MSSQL	SQL Server 默认端口，关注弱口令、账号权限、xp_cmdshell、SQL Agent、链接服务器等风险
1521	Oracle	关注弱口令、历史漏洞、TNS 配置和权限边界
3306	MySQL	常与 Web 应用强相关，重点关注配置文件、访问来源和账号权限
5432	PostgreSQL	关注账号权限、危险扩展、COPY PROGRAM 等命令执行面
6379	Redis	关注是否绑定公网/内网、是否开启认证、是否允许危险写入
27017	MongoDB	关注认证配置、暴露范围和敏感数据泄露
9200	Elasticsearch	关注未授权访问、敏感索引和历史漏洞

Web、中间件与 Agent 服务

端口	服务	关注点
80/443	HTTP/HTTPS	Web 系统、管理后台、API 服务
8080/8081/8888	HTTP 备用端口	常见于测试系统、后台服务、代理服务
8443	HTTPS 备用端口	常见于管理后台或自建服务
7001/7002	WebLogic	Java 中间件，历史漏洞较多
8090	Confluence	协作系统，需关注版本和补丁情况
8089	Splunk	管理 API，关注认证和访问控制
8161	ActiveMQ Web	管理控制台，关注弱口令和历史漏洞
4040/8088	Spark/YARN	大数据组件，关注是否存在未授权访问
50070/9870	HDFS	Hadoop 文件系统 Web 入口

容器、编排与云原生组件

端口	服务	关注点
2375	Docker Remote API HTTP	若未授权暴露，通常可进一步影响容器甚至宿主机
2376	Docker Remote API HTTPS	关注证书、认证和访问控制
6443	Kubernetes API Server	集群控制面入口，认证或 RBAC 配置不当时风险极高
10250/10255	Kubelet	关注匿名访问、证书认证和老版本配置问题
5000	Docker Registry	镜像仓库，可能泄露代码、配置和密钥
8500	Consul	服务发现组件，关注访问控制和历史漏洞
8200	Vault	密钥管理服务，关注认证、Token 和访问策略
9000	Portainer	Docker 管理面板，关注弱口令和暴露范围

文件传输与内部共享

端口	服务	关注点
20/21	FTP	关注匿名登录、明文传输和敏感文件
69	TFTP	常见于网络设备或自动化部署，关注配置文件泄露
873	rsync	关注未授权读取和写入
2049	NFS	关注导出目录、访问控制和可写权限

异常代理与 C2 特征端口

端口	服务	关注点
1080	Socks 代理	若普通业务主机监听该端口或长期建立代理类连接，需要重点排查
8388	Shadowsocks	关注是否为异常代理通道
4444	Metasploit/RAT 常见默认端口	只能作为辅助特征，不能单独定性
50050	Cobalt Strike Teamserver 历史默认端口	实战中常被修改，不能单独作为判断依据

1.2 全端口 vs 常用端口的取舍

渗透的前期工作中，会习惯性的直接对单个目标做全端口扫描，但在内网里，如果直接上来就对整个网段进行全端口扫描的话，还有一些问题：

1. 内网资产数量多，全端口扫描会产生大量连接
2. 很多扫描流量需要经过代理，速度慢、结果也不稳定
3. 容易触发 IDS、IPS、EDR、流量探针
4. 对一些老旧业务服务可能造成压力
5. 扫描结果太多，反而不利于快速判断重点目标

通常比较稳的方式是

• 第一轮：扫常用端口，判断主机大概角色
• 第二轮：对重点主机补充端口范围
• 第三轮：对高价值主机做服务版本识别
• 第四轮：针对具体服务做漏洞或弱配置验证

在第一轮里，一般扫描一些高价值端口，例如：

nmap -Pn -n --open -p 21,22,23,25,53,80,81,88,110,135,139,143,389,443,445,465,587,993,995,1433,1521,2049,2375,3306,3389,5432,5900,5985,5986,6379,7001,7002,8000,8009,8080,8090,8161,8443,8888,9000,9200,9300,11211,27017 10.10.5.0/24

# -Pn      不做 ICMP 存活判断，直接认为主机在线
# -n       不做 DNS 解析，减少额外请求
# --open   只显示开放端口
# -p       指定端口范围

因为通常在内网里会遇到ICMP被禁的情况，如果不加-Pn，那nmap可能会因为ping不到目标主机就认为该主机不在线，导致漏掉一些实际开放了服务的主机。

如果第一轮扫到某台机器开放了多个敏感端口，再对这台机器做进一步补充扫描。例如：

nmap -Pn -n --open -p- 10.10.5.30

这种方式比直接对整个网段全端口扫描更可控。

1.3 走代理的端口扫描注意事项

上一篇里已经讲过 Socks 代理。到了端口探测阶段，很多扫描可能会需要通过 Socks 代理进行。但其实 Socks 代理并不适合 nmap 的 SYN 半连接扫描，也就是不要通过 proxychains4 nmap -sS -p 80,445,3389 10.10.5.0/24 这样的形式去进行扫描。

原因在于 SYN 扫描和 Socks 代理工作的层次不一样，-sS 只发一个带 SYN flag 的 TCP 包就判断端口状态，不完成完整握手，这种操作绕过了系统的 TCP 协议栈，需要用原始套接字自己拼数据包。而 Socks 代理工作在 TCP 连接级别，只接受类似”帮我连到 X:Y”这种指令,代理自己去完成完整握手，它没法转发只发一个 SYN 包这种原始包级别的请求，所以走 Socks 时只能用 -sT(TCP connect 扫描)。

proxychains4 nmap -sT -Pn -n --open -p 80,445,3389,3306,6379 10.10.5.0/24

但是用TCP connect扫描的时候，如果用大范围端口扫描的话，也会有一些问题：

1. 速度慢，因为TCP需要完整的完成三次握手
2. 超时多，容易漏报
3. 代理链不稳定的时候，结果不可靠
4. 跳板机会产生大量链接
5. 容易暴露通道行为

通常如果是在跳板机本机上使用nmap，最好也是适当的降低扫描速度，例如：

nmap -T2 -Pn -n --open -p 22,80,445,3389 10.10.5.0/24
nmap -T3 -Pn -n --open -p 22,80,445,3389 10.10.5.0/24

如果过快有时候会导致在日志里过于明显

1.4 常用端口扫描方式

1.4.1 nmap走代理扫描

前面也一直是用nmap做的示例，此处也还是总结一下：

扫几个高价值端口：

proxychains4 nmap -sT -Pn -n --open -p 22,80,135,139,445,3389,3306,6379,8080,8090,9200 10.10.5.0/24

如果只验证单个目标：

proxychains4 nmap -sT -Pn -n -sV -p 80,443,7001,8090 10.10.5.50

此处用到的-sV，会对服务版本进行识别，但是会比单纯端口扫描产生更多的交互信息，所以最好的方式通常是先扫描端口，然后再根据结果来做-sV来进一步拿到更有用的信息。

1.4.2 fscan 在跳板机本地跑

fscan、kscan这类工具算是内网测试里比较经典的工具了

例如扫描一个 C 段：

./fscan -h 10.10.5.0/24 -p 22,80,135,139,445,3389,3306,6379,8080,8090,9200

# fscan如果不指定-p参数后的端口，会自动使用工具自带的一套端口集合

这条命令跑完会自动做几件事:

1. ICMP / TCP 存活探测
2. 指定端口扫描
3. 对开放端口做服务识别，比如 80 是不是 Web、识别到 Web 后跑指纹
4. 对识别出的服务尝试常见弱口令（SSH、MySQL、Redis、SMB 等）
5. 跑一些经典 PoC(MS17-010、Redis 未授权、Shiro 反序列化等)

还有几个常用的参数

./fscan -h 10.10.5.0/24 -p 1-65535 -t 600    # 全端口扫描,t 是并发数
./fscan -h 10.10.5.0/24 -nopoc               # 只做端口扫描,不跑漏洞 PoC,降低噪声
./fscan -h 10.10.5.0/24 -np                  # 跳过存活探测,直接扫端口
./fscan -hf ip.txt                           # 从文件读 IP 列表
./fscan -h 10.10.5.0/24 -o result.txt        # 输出到文件

-nopoc 这个参数通常很常用，默认 fscan 会自动跑漏洞 PoC，这些 PoC 流量特征非常明显，容易被 EDR 和流量设备直接拉黑。为了防止环境里有检测设备，最好先用 -nopoc 摸清楚有什么服务，再人工挑目标针对性验证，会比让工具自动打好。

kscan 跟 fscan 思路类似，指纹库更全面且更新更勤一些，Web 服务识别比 fscan 准，但是漏洞利用模块没 fscan 全，两个工具配合用比较常见。

1.5 服务识别与指纹识别

1.5.1 nmap -sV 和它的局限

前面有提到，nmap可以用于做服务版本识别

nmap -sV -Pn -n -p 80,443,7001,8090,9200 10.10.5.50

# 或者如果想更积极一点，可以使用：
nmap -sV --version-all -Pn -n -p 7001 10.10.5.50

但是常见的也会有一些误差，比如

1. 服务隐藏 banner
2. 反向代理挡在前面
3. 中间件自定义响应
4. WAF 或网关拦截探测
5. 内部系统返回统一错误页
6. 端口被复用

例如 nmap 显示：

8080/tcp open  http-proxy

不代表它一定是代理服务，可能只是某个普通 Web 后台。

1.5.2 Web 服务指纹

Web的服务指纹一般主要是看：Title、响应头、Cookie、favicon hash、静态资源路径、登录页文案、错误页面、默认接口等

简单手工判断，通常就直接使用curl命令

curl -I http://10.10.5.50:8080

再返回内容中重点看：Server、X-Powered-By、Set-Cookie、Location、WWW-Authenticate

例如，如果返回是：

Set-Cookie: JSESSIONID=xxxx		# 说明可能是 Java Web
Set-Cookie: PHPSESSID=xxxx		# 说明可能是 PHP 应用
Location: /login.action				# 可能是 Struts、Confluence 或其他 Java 应用风格
Location: /jenkins/login			# Jenkins
Location: /console/login/LoginForm.jsp	# 可能是WebLogic的控制台

也可以结合一些其他工具进行识别

1.6 端口探测后的初步利用

端口探测完成后，不应该对所有服务乱打一遍，而是要有优先级。一般按照顺序：

1. 是否存在未授权访问
2. 是否存在默认口令或弱口令
3. 是否存在高危历史漏洞
4. 是否能从配置文件中获取凭据
5. 是否能用已有凭据登录其他服务

1.6.1 弱口令爆破

弱口令是内网中非常非常常见的初始权限入口，但也是最容易造成影响的测试行为，尤其是针对这些服务：

SSH
RDP
MSSQL
MySQL
Redis
MongoDB
Tomcat Manager
WebLogic Console
Jenkins
后台管理系统

SSH 弱口令

SSH 弱口令成功后，可以直接获得 Linux shell。

常见验证方式是使用已有账号密码进行低频测试，而不是对一个账号疯狂爆破，或者通过密码喷洒攻击。

爆破过程中可以使用 hydra 这类工具控制线程和频率，因为如果直接高频的爆破日志非常明显，也可能触发锁定或封禁。

hydra -L users.txt -P pass.txt ssh://10.10.5.20 -t 4 -W 5

RDP 弱口令

RDP 弱口令风险很高，但也最容易影响业务账号。因为 RDP 上挂的几乎都是真实在用的域账号（像是员工工位、管理员终端），失败会直接触发账号锁定策略，而域账号锁定会同步到域控、影响员工在所有系统（邮箱、OA、SSO、VPN）的登录。因此通常不对RDP进行爆破，而是通过一些其他方法来获得凭证

使用已有凭据验证：

域账号密码
本地管理员密码
泄露的运维账号
历史默认密码
密码喷洒得到的密码

RDP 登录成功后，攻击者可以获得交互式桌面，风险比单纯服务访问更高。

MSSQL 弱口令

MSSQL 默认端口是 1433。

MSSQL 弱口令常见账号：

sa
admin
test
sql

如果成功登录，后续关注点包括：

数据库内容
链接服务器
作业任务
xp_cmdshell 是否开启
SQL Server 服务账号权限
是否能读取其他业务凭据

MSSQL 在 Windows 域环境里价值比较高，因为它可能连接到其他 SQL Server，也可能使用域账号运行服务

Redis / MongoDB 弱口令或弱认证

Redis 和 MongoDB 更常见的问题是未授权访问，但也有认证配置较弱的情况。

测试时重点不是爆破，而是先判断：

是否需要认证
认证失败提示是什么
是否允许匿名访问部分信息
是否暴露在不该暴露的网段

弱口令测试的核心原则是：

少量、高概率、低频率

1.6.2 未授权访问拿初始权限

未授权访问是内网里非常高价值的一类问题，其主要是不需要账号密码，通常只要能访问服务端口就可能可以读取数据或者执行操作。

Redis 未授权

Redis 默认端口：

6379

低风险验证：

redis-cli -h 10.10.5.30 -p 6379 ping

如果返回：

PONG

说明 Redis 可连接。

继续测试是否需要认证：

redis-cli -h 10.10.5.30 -p 6379 info

如果无需密码就能返回大量信息，说明可能存在未授权访问。

重点记录：

Redis 版本
绑定地址
是否 requirepass
数据库数量
key 数量
是否存在敏感 key
服务运行用户
所在主机角色

Redis 未授权的风险包括：

读取缓存数据
泄露 Session
泄露 Token
影响任务队列
读取业务临时数据
在危险配置下进一步影响主机

Redis这块我也还没特别深入的学习，但是之前看到一些文章里写通过Redis 写 SSH key、写 webshell、主从复制 RCE，手法蛮多，后面抽空专门学一下。

Docker 2375 未授权

通常扫到2375端口开放，可以尝试验证：

curl http://10.10.5.40:2375/version
curl http://10.10.5.40:2375/info

如果返回Docker信息，说明Docker API暴露且可能存在未授权，可以进一步尝试

一般Docker处的风险在于：

枚举容器
读取镜像信息
读取环境变量
查看挂载目录
在危险配置下影响宿主机

这块的手法较多，由于这篇是总结目的的文章，暂时跳过具体手法，通常的手法路径是：Docker 2375 未授权 → 创建特权容器 → 挂载宿主机目录 → 宿主机 root

Hadoop YARN 未授权

YARN的端口常见于8088

如果ResourceManager Web UI存在未授权暴露，就可被用来提交任务，通常验证时可以尝试访问

http://10.10.5.60:8088/

查看结果：

• 是否无需认证进入控制台
• 是否能查看应用列表
• 是否能查看节点信息
• 是否能提交任务

YARN 未授权严重时可能导致RCE

Elasticsearch 未授权

Elasticsearch默认端口为9200，验证可通过：

curl http://10.10.5.70:9200/
curl http://10.10.5.70:9200/_cat/indices?v

如果执行后可以直接列出索引，就可能存在未授权访问风险

重点关注：

日志索引
用户索引
订单索引
接口请求日志
错误日志
登录日志

ES 里的日志经常可能包含：

Cookie
Token
Authorization Header
手机号
邮箱
身份证
内部接口路径
SQL 报错
堆栈信息

MongoDB 未授权

MongoDB默认端口为27017，验证时：

mongosh --host 10.10.5.80 --port 27017

如果能顺利连接，进入后可执行类似 show dbs，如无需认证就可以列出目标机上的数据库的话，就存在未授权访问

1.6.3 中间件已知漏洞快速验证

中间件漏洞验证要先确认服务和版本，不要看到端口就直接打 PoC。

比较稳的流程是：

确认端口
  ↓
访问页面
  ↓
识别产品
  ↓
判断版本
  ↓
对照漏洞影响范围
  ↓
低风险验证

WebLogic 反序列化

WebLogic 常见端口：

7001
7002

首先访问：

http://10.10.5.50:7001/console

如果出现 WebLogic 控制台，再进一步判断版本。

WebLogic 历史上有很多反序列化漏洞，但验证时要注意：

不要盲打所有 PoC
不要直接执行破坏性命令
先判断版本和补丁
优先使用无害验证方式

报告中可以描述为：

目标开放 WebLogic 控制台，版本疑似处于历史漏洞影响范围内，若未修复相关补丁，可能存在远程代码执行风险。

Confluence OGNL

Confluence 常见端口：

8090

常见路径：

/login.action
/dashboard.action

Confluence 历史上多次出现 OGNL 表达式注入相关漏洞。

验证思路：

确认是否 Confluence
判断版本
查看是否暴露在内网大范围
对照漏洞影响版本
使用低风险方式验证漏洞特征

Confluence 通常存放企业内部知识库内容，一旦被打穿，不仅是主机权限问题，还可能泄露大量内部文档、账号、接口、系统架构信息。

ActiveMQ CVE-2023-46604

ActiveMQ 常见端口：

8161    Web 控制台
61616   OpenWire

如果看到 8161，可以访问：

http://10.10.5.90:8161/admin

关注：

是否默认口令
是否暴露管理后台
版本是否受影响
61616 是否对内网大范围开放

CVE-2023-46604 是 ActiveMQ 历史上非常高危的远程代码执行漏洞。验证时同样不建议直接执行命令，应该先通过版本、服务特征和低风险检测方式确认风险。

2. 权限提升

通常，在初步拿到shell的情况下，大多数时候当前的权限是不足的，我们为了能够执行更多操作，通常需要root或者admin权限，那么下一步就是要判断权限够不够，有没有办法提升权限。

单机提权的目标不是单纯为了拿 root 或 Administrator，而是为了扩大当前机器上的可见范围。权限越高，能读取的配置、凭据、进程、网络连接、历史记录也越多，后续横向移动的机会也越多。

提权手法有些过多了，就在我写到这块时，看到了最新的最优雅的提权手法CVE-2026-31431，有时间单独分析一下。这块的内容只大概列举一下。

2.1 Linux提权

2.1.1 基础信息收集

先确认当前用户、系统版本、网络情况和进程信息，一般就是通过命令

whoami
id
hostname
uname -a
cat /etc/os-release
ip addr
ip route
ss -tunap
ps aux

以上的信息一般主要是用来判断，当前用户的权限是什么样的（root还是低权限），系统版本是否比较老（有没有可以用的提权方法），当前机器能访问哪些网段，有哪些服务和进程在运行（会不会有能利用的），是否存在数据库、缓存、内部API等连接

比如如果拿到的用户是www-data，这通常是通过web拿到的shell的权限，并且如果当前机器还能连接数据库、Redis或其他内网服务，通常这台机器就有可继续利用价值。

2.1.2 sudo配置问题

Linux 上比较常见的一类提权点是 sudo 配置不当，可以查看当前用户能执行哪些 sudo 命令：

sudo -l

如果发现当前用户可以免密码执行某些命令，就要重点关注，比如返回的是：

(root) NOPASSWD: /usr/bin/vim
(root) NOPASSWD: /usr/bin/find
(root) NOPASSWD: /usr/bin/python3

如果普通用户可以以 root 身份执行一个可逃逸的程序，就可能造成提权

2.1.3 SUID / capabilities 配置问题

SUID 和 capabilities 都属于 Linux 权限机制里的特殊配置。

查找SUID文件：

find / -perm -4000 -type f 2>/dev/null

查看 capabilities：

getcap -r / 2>/dev/null

正常系统里本来就会有一些 SUID 文件，所以不能看到 SUID 就直接判断有漏洞。重点要看文件路径是否异常、是否是自定义程序、当前用户是否可写、程序是否可执行命令、程序是否可读写敏感文件等。

比如/usr/bin/passwd 这种属于正常的系统文件，但是如果在/tmp/、/opt/、/home/之类路径下发现奇怪的suid root程序，就可以重点关注一下。

capabilities 也是类似。如果某些解释器、脚本执行器或异常程序带有高危 capability，就可能绕过普通权限限制。

2.1.4 计划任务和服务文件

计划任务和服务文件也是常见配置问题来源，可以查看：

crontab -l
cat /etc/crontab
ls -la /etc/cron*
systemctl list-units --type=service

# 是否有 root 定时任务
# 定时任务执行的脚本是否可写
# 服务文件是否可写
# 服务调用的脚本是否可写
# 服务是否以 root 权限运行

比如 root 定时任务每分钟执行 /opt/backup/backup.sh，而当前用户刚好可以修改这个脚本，这就是典型的配置错误。

2.1.5 凭据和配置文件

常见配置文件包括：

Web 配置文件
.env 文件
数据库配置
SSH 私钥
历史命令
备份文件
部署脚本

很多时候，当前机器本身提不了 root，但配置文件里泄露的凭据可以登录数据库、后台系统，甚至其他内网服务器

2.1.6 内核漏洞

内核漏洞属于最后考虑的方向。常见的一些历史漏洞包括DirtyCow、DirtyPipe、OverlayFS、PwnKit，当然还有前面提到的前段时间刚出来的CVE-2026-31431。

通常就是通过内核版本来选择对应的可用手法。

2.2 Windows 提权

Windows提权也同样先看当前用户、权限、系统版本和配置问题

2.2.1 基础信息收集

常见基础命令

whoami
whoami /priv
whoami /groups
hostname
systeminfo
ipconfig /all
net user
net localgroup administrators

重点判断当前用户是否是本地管理员、是否是域用户、是否有高危特权、系统版本和补丁情况、是否开启 UAC、是否有安全软件

其中 whoami /priv 很重要，因为 Windows 很多提权方式都和特权有关

比如SeImpersonatePrivilege、SeBackupPrivilege、SeDebugPrivilege

2.2.2 服务和注册表配置错误

Windows 上很多提权点来自服务配置问题，比如服务路径未加引号、服务可执行文件可写、服务目录可写、服务注册表项可写、普通用户可以修改服务启动内容等

一般的判断逻辑就是：某个服务以高权限运行 + 当前用户能修改其执行的内容 = 可能可以提权

比如一个服务以 SYSTEM 权限运行，但它的程序目录普通用户可写，那攻击者就可能通过替换程序或修改启动路径来影响服务执行

2.2.3 AlwaysInstallElevated

AlwaysInstallElevated 是 Windows Installer 相关配置，如果 HKCU 和 HKLM 两处配置都开启，就可能导致普通用户以高权限安装 MSI

检查命令：

reg query HKCU\Software\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
reg query HKLM\Software\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated

这个问题在真实环境中一旦存在，风险比较直接

2.2.4 令牌和高危特权

Windows 里还有一类提权方式和令牌、服务权限有关，比如常说的土豆系列。这类方法通常需要满足一定条件，例如：

1. 当前用户具有 SeImpersonatePrivilege
2. 当前进程运行在特定服务上下文
3. 目标系统版本和补丁情况符合条件

所以不能看到土豆系列工具就无脑跑。正确做法是先判断当前权限和系统环境，再决定是否有验证价值。

2.2.5 UAC Bypass

UAC Bypass通常不是从普通用户直接变成管理员，而是要求当前用户本身已经属于本地管理员组，只是当前进程不是高完整性。如果当前用户本来就不是管理员，单纯 UAC Bypass 通常没有意义。

2.2.6 凭据泄露

Windows 上的凭证也是比较重要的一点，常见来源包括：

浏览器保存密码
远程桌面连接记录
共享目录
配置文件
脚本文件
历史命令
数据库连接字符串
运维工具配置

如果可以直接从机器上找到可复用的账号密码，反而更容易进入下一阶段

2.2.7 自动化检查工具

当然也有一些工具，但是此处就不多赘述，比如：

PowerUp
winPEAS
Seatbelt
SharpUp

但这些已经存在的比较久的工具，通常很容易被EDR之类的防护识别到

3. 防守侧关注点

把前面的攻击动作反过来看，端口探测、弱口令测试、未授权访问验证和提权行为都会留下痕迹。

3.1 内网扫描行为的网络特征

端口扫描常见特征：

单源 IP 访问大量目标 IP
单源 IP 访问大量端口
短时间内大量连接失败
访问端口集中在 22、445、3389、3306、6379、8080 等敏感端口
扫描流量来自非扫描器资产
普通办公终端访问服务器网段
Web 服务器突然访问大量内网主机

但通常一棒子打死会导致有很多的噪声，比如如果是运维扫描器访问大量服务器，那通常是正常的行为。但是如果是一个Web服务器突然扫描某个内网IP的整个网段的一些特殊端口，比如445、3389等，那就可能是异常。

所以通常可以基于设备的角色做画像。比如Web服务器平常访问哪些数据库，数据库服务器是否应该主动访问其他机器，办公终端是否应该访问服务器网段，堡垒机访问哪些资产是正常的。一旦某台机器出现和角色不匹配的访问行为时，就值得进一步进行排查。

3.2 弱口令爆破的认证日志特征

弱口令和密码喷洒通常会留下大量认证失败日志。

通常就是要注意：

1. 同一源 IP 尝试多个账号
2. 同一账号短时间多次失败
3. 失败后紧跟成功登录
4. 非工作时间认证失败增多
5. 来自非运维主机的登录尝试

3.2.1 Windows

Windows 重点看Security 安全日志。常见查看位置：Event Viewer -> Windows Logs -> Security

4625    登录失败
4624    登录成功
4771    Kerberos 预认证失败
4776    NTLM 认证失败
4740    账号锁定

也可以用 PowerShell 简单查询：

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 20

如果要看最近的登录成功：

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 20

如果短时间内看到同一个来源 IP 对多个账号产生大量 4625，或者大量 4771 / 4776，就要怀疑密码喷洒或爆破行为

3.2.2 Linux

Linux 上 SSH 爆破主要看认证日志。

Debian / Ubuntu 常见位置：

/var/log/auth.log

CentOS / RHEL 常见位置：

/var/log/secure

关键词一般是Failed password、Invalid user、Accepted password

可以简单 grep：

grep "Failed password" /var/log/auth.log
grep "Invalid user" /var/log/auth.log
grep "Accepted password" /var/log/auth.log

3.2.3 数据库认证日志

数据库也要关注认证失败日志，尤其是内网里常见的 MSSQL、MySQL、PostgreSQL、MongoDB

MSSQL

Windows 上 MSSQL 认证失败通常可以在两个地方看：

​ SQL Server Error Log
​ Windows Event Viewer -> Application

关键词一般是

Login failed for user
Error: 18456

所以如果短时间内出现大量Login failed for user 'sa'，那就是值得关注的风险

MySQL

MySQL 日志位置和配置有关，可以先查看配置文件里的日志路径。

常见位置：

/var/log/mysql/error.log
/var/log/mysqld.log

常见关键词：

Access denied for user

PostgreSQL

PostgreSQL 日志位置也依赖配置，常见目录：

/var/log/postgresql/

常见关键词：

password authentication failed
no pg_hba.conf entry

MongoDB

MongoDB 常见日志位置：

/var/log/mongodb/mongod.log

常见关键词：

Authentication failed
Unauthorized

3.3 提权操作的进程和系统调用特征

Linux 常见：

sudo -l
find / -perm -4000 -type f
getcap -r /
cat /etc/crontab
uname -a
cat /etc/os-release

这些命令单独看不一定恶意，但如果它们是从 Web 进程、异常用户、临时目录脚本中执行，就需要重点关注。比如从nginx、apache、java等父进程执行了这些命令就需要重点排查一下

Windows 常见：

whoami /priv
whoami /groups
systeminfo
reg query AlwaysInstallElevated
wmic service get name,pathname
PowerUp.ps1
winPEAS.exe
Seatbelt.exe
SharpUp.exe

重点需要关注：

1. 进程创建日志
2. 命令行参数
3. 父进程
4. 执行路径
5. 文件落地目录
6. 是否从临时目录执行
7. 是否由 Web 进程拉起
8. 是否由 Office、浏览器、脚本解释器拉起

4. 小结

这篇主要整理了主机发现之后的两个问题：一是目标主机开放了哪些端口、对应什么服务；二是在拿到初始 shell 后，当前权限够不够，是否存在本地提权的空间。

端口探测这块，其实重点不在于把所有端口都扫一遍，而是通过端口组合判断主机角色。比如看到 53、88、389、445 这一类组合，就要想到域控；看到 2375，就要想到 Docker API；看到 7001、8090、8161，就要联想到对应的中间件和历史漏洞。端口只是入口，真正有价值的是根据端口继续判断服务、版本、权限边界和后续利用方向。

提权这块在整理的时候感受更明显：手法实在是太多了，而且新的方法也一直在出现，不可能靠一篇文章全部写完。Linux 里有 sudo、SUID、capabilities、计划任务、服务文件、内核漏洞；Windows 里有服务权限、注册表权限、AlwaysInstallElevated、令牌滥用、UAC Bypass、凭据泄露等。每一类展开都能单独写一篇，所以这一篇只先按方向做一个归纳。

我觉得内网学习比较难的一点就在这里，它不是单纯背几个工具命令，而是要不断把端口、服务、权限、凭据、日志、主机角色这些信息串起来看。很多时候一个点本身看起来不严重，但放进整条攻击链里，就可能变成继续深入的入口。

所以这一篇更像是一个阶段性的框架。后面如果继续整理，我觉得准备把凭据收集、横向移动、域内分析、权限维持这些内容再单独拆开写（当然如果我不偷懒的话）。内网相关的东西确实只能边做边补，边看新的案例，边把自己的知识体系慢慢补全。