安全排查基本功：Windows命令行速查与实战

安全圈里常有人说：工具库更新得比游戏版本还快，可到了真正需要排查的时候，决定效率的往往还是命令行的基本功。这话不是让每个人都去背脚本，而是提醒我们别把系统自带能力当成可有可无的备选项。我今天记录的这份网安学习笔记，从基础篇的 Windows 基础命令开始讲起。它既适合刚入行的安全方向学习者，也适合日常接触 Windows 服务器的运维人员——哪怕只是想把本机状态看清楚，这些命令也比一层层点开设置界面更直接。抛开图形界面的包装，你会发现系统本身已经提供了一张足够清晰的快照。

这篇不会去谈那些动辄好几层的平台级技术，只围绕真正用得到的内容展开：哪些命令负责看网络连接，哪些命令负责把进程和端口关联起来，日志取证的固定证据要注意什么。等这些点串起来，你对着一台 Windows 主机的时候，就不再是只会在任务管理器里来回切换了，而是有了一条可复现的排查路径。把这个路径写在纸上，手边常备一套常用命令速查表，比收藏大量工具分享更有用。

1. 为什么基础命令是网安入门的必修课

1.1 命令行为什么比图形界面更适合排查

说一个我在日常巡检中经常遇到的场景：某公司有几十台 Windows 主机，还没来得及部署统一监控平台，所有异常都要靠手工确认。管理员拿到任务管理器只能看到当前进程排行，看到要定位的进程还得继续右键打开文件位置，对实时变化的网络连接几乎没有可靠的展示。换成命令行之后，netstat -ano 一条命令，当前所有连接、监听端口、对应的进程标识全部出来，输出还能存成文件下发给其他人复核。命令行不是更“高端”，而是更直接，也更适合批量处理和留痕。

另一个容易忽略的优点是可追溯。你操作的每一步都有文本输出，输出的时间戳、字段、内容都可以被记录下来，后面分析问题时，不用靠记忆复述，直接把当时的快照文件调出来核对就行。图形界面通常适合“临时看一眼”，命令行却天然适合“持续观察、对比、交接”。对安全排查来说，证据意识和可追溯性和“看到异常”本身同样重要。

1.2 一条命令背后隐藏的信息维度

以 netstat -ano 为例，输出里通常包含协议、本地地址、外部地址、状态和 PID 五列。很多人只看有没有异常连接，其实这五列信息是可以不断往下索引的。拿到 PID 之后，你可以用 tasklist 反查是什么进程；拿到进程名之后，可以用 wmic 继续查它的执行路径、启动时间、命令行参数；甚至还可以在对应的用户目录里看到这个程序的文件属性、哈希值和访问记录。一条简单的连接记录，最后能铺开成一张完整的画像。

这种“命令与命令之间互相索引”的思路，才是我觉得最值得掌握的。刚开始学习的人容易把每条命令当成孤立工具，今天背一条 netstat，明天背一条 tasklist，到现场还是不知道怎么串起来。实际上，排查过程就是不断拿上一步的输出作为下一步的查询条件。你不用记住所有命令的参数，但你得清楚该在什么阶段用哪条命令，以及哪些字段能继续追问下去。

1.3 前置准备与适合的学习思路

建议准备一台可随时还原的 Windows 虚拟机或测试终端，用管理员身份打开命令提示符。系统版本跨度大一点反而没关系，只要对着输出字段学习就行。先建一个名为 logs 的目录，把每次执行的输出存成文本，后面你会发现这个习惯特别有用——它既是你的操作记录，也是判断后续变化的基线。没有基线的时候，判断可疑主要看几个点：有没有非内网网段的 ESTABLISHED 连接、有没有陌生进程监听在高端口、有没有异常的服务处于启动态。这些关键词会在后面的小节里反复出现。

也需要提个醒：基础命令是入口，不是终点。把输出当成最终结论，不做后续验证，是新手最容易踩的坑。举个例子，你看到一个进程占用了 80 端口，就认定它一定有问题，但实际它可能是正常的业务服务，也可能只是其他程序临时复用。正确的做法是先记录快照，再对照进程路径、启动时间和日志事件来综合判断，而不是条件反射一样去结束它。把这句话放在最前面，是因为我见过太多次因为“手快”导致的二次事故。

2. 核心命令分区：网络、进程、文件与日志

2.1 网络连接类命令：谁在连、从哪里来

先说网络这块，因为它是判断主机是否被异常外联的基础。我把日常常用的几条命令整理成了下面的表格，方便对照记忆：

netstat 是这里面最重要的，几乎每次排查都会用到，值得花时间把它的输出读熟。最常见的状态列有 LISTENING、ESTABLISHED、TIME_WAIT、SYN_SENT 这些。对安全排查来说，ESTABLISHED 和 SYN_SENT 最值得关注：前者代表当前已经建立的连接，后者代表正在尝试向外发起连接但没得到确认。如果一个业务终端持续出现大量对外网的 SYN_SENT，那就要小心了，不能当成普通网络波动忽略。

只看到连接还不够，还得把端口和进程连接起来。我的习惯是先跑一条 netstat -ano 存文件，然后把疑似连接的 PID 提取出来，再通过 tasklist 定位进程。命令行示例是这样的：

netstat -ano | findstr ESTABLISHED tasklist /fi "PID eq 6688"

把 PID 换成你实际拿到的值。tasklist 的 /fi 参数是过滤条件，可以按 PID、进程名、会话名等方式筛选，比在完整输出里一行行找要快得多。顺便说一句，看到外部地址不是内网段并不意味着一定是恶意，得结合业务场景来判断。但如果一个根本没有对外业务需求的终端，长期保持和其他地址建立连接，那无论如何都值得继续往下挖。公网地址、非标准端口、双向流量这些特征组合起来，威胁等级就非常高了。

ping 和 tracert 更多用于连通性判断，安全排查里用来确认主机能不能访问某个关键地址，出现异常时先判断是网络问题还是主机问题。arp -a 和 route print 平时使用频率稍低，但在排查网络劫持、异常路由时很有价值，建议保留但不需要每天都敲。

2.2 进程与服务：找异常行为的第一站

网络连接往往只是线索，下一步就要靠进程和服务命令确认到底是谁在运行。tasklist 是最常被用到的，加上 /svc 参数可以看到每个进程对应的服务，加上 /fi 参数可以按条件过滤。wmic process 系列命令虽然在新系统上逐步被替代，但学基础阶段仍然是非常好的入门材料，因为它能一次给出进程的父进程 PID、执行路径、命令行参数和创建时间，这在应急排查里几乎是救命信息。

实战中我会这样组合：

tasklist /svc wmic process where processid=6688 get ProcessId,ParentProcessId,ExecutablePath,CommandLine

ParentProcessId 也就是父进程，这个字段特别值得关注。正常情况下，常见系统进程的父进程都是明确的，例如资源管理器启动的大部分用户程序，父进程就是 explorer。如果看到一个系统名字的进程，父进程却是某个临时目录里的脚本宿主，那就说明启动链条不太正常。拿到可执行文件路径之后，再配合 dir 和 certutil 固定文件属性，基本就能判断这个程序是不是有问题的那个“点”。

服务列表也有自己的命令体系。sc query 可以查看服务状态，net start 能看到当前已启动的服务名称。权限允许的前提下，用 sc query 直接查看某个服务的可执行文件路径，比在图形化服务管理工具里一层层翻菜单要准确。安全排查时，服务命令主要用来发现“不应存在的自启动服务”。很多异常驻留方式都会注册服务，所以服务名、服务路径、启动类型这三个字段一定要会看。

2.3 文件、权限与日志：把细节固定下来

再往下就是证据固定。排查进行到需要下结论的阶段，务必要先保存现场，再去动手清理或停止相关内容。文件层面，dir 配合 /a 可以显示隐藏文件，配合 /tc 可以看到创建时间，配合 /s 可以递归遍历子目录。文件名、时间、大小、路径，这些基础属性是后续写说明报告时最常用到的字段。

权限方面，icacls 命令能够查看和修改文件或目录的访问控制列表，排查时需要确认某些可疑文件是否被赋予了异常宽泛的权限，比如普通用户都能写入系统目录，这种情况往往是后续被利用的前提。文件哈希用 certutil -hashfile 就能计算，我习惯先把哈希值记下来，再去做其他操作，因为文件一旦改变，哈希就不一样了，后续对照会失真。

日志层面，Windows 事件日志是取证的重要来源。wevtutil 是内置的命令行工具，可以查询和导出事件日志，比如 Security 日志里的进程创建记录、登录记录，System 日志里的服务启动和停止记录。命令行示例是这样的：

wevtutil qe Security "/q:*[System[(EventID=4688)]]" /c:20 /f:text

这个命令会以文本形式展示最近 20 条 4688 进程创建事件。安全审计中，4688 是进程创建事件，4689 是进程终止事件，4624 是登录成功事件，4625 是登录失败事件。平时建议先把这些 ID 背住，因为它们比在图形事件查看器里做过滤要方便得多。也提醒一句，如果系统默认没有开启进程创建审核策略，4688 可能根本记录不到，那时候不要下结论说“没有发生”，只能说“没有记录”。

3. 基于场景的实操：排查一次可疑连接

3.1 场景设定与演练目标

我设计一个常见的模拟场景，读者可以照着做一遍。设定是这样的：某研发团队的一台 Windows 终端，管理员反馈 CPU 长期在高位，网络流量明显比平时大，但任务管理器里看不出具体是哪个程序在占用。我们没有现成的监控平台，只能通过命令行现场排查。演练目标是：找出与外部地址建立的连接，定位到具体进程和文件，尽量还原启动时间，并保存一份可复核的检查记录。

这里的终端名称、团队名称都属于虚构，重要的是把排查方法走一遍。真正操作时，建议把每一步的关键输出都保存下来，不要只在屏幕上瞄一眼就继续下一步，尤其是当你需要向别人解释判断依据的时候。

3.2 排查路径：抓连接、逆进程、查关联文件

第一步，抓取当前网络连接快照。用管理员身份打开 cmd，执行：

netstat -ano > netstat_snapshot.txt

同时为了快速锁定可疑外联，可以再加一条过滤，把明显属于内网网段的连接排除掉，减少噪音。这一步不追求一步到位，先拿到完整快照，再从快照里筛选。

第二步，把可疑连接对应到进程。在快照里找到已建立连接的 PID 后，执行：

tasklist /fi "PID eq 6688"

如果这个进程名称看起来比较陌生，立刻用 wmic 补查它的执行路径和启动时间。重点看路径是不是在临时目录、下载目录或用户 AppData 目录里。这些目录出现在业务终端的正常进程路径里，本身就比较扎眼。

第三步，固定文件层面的证据。不要急着结束相关进程，先把文件相关属性记录下来。用 dir 查看目录下的文件列表和时间，用 certutil 计算哈希，用 icacls 查看权限。可以这样组织输出：

dir /a /tc "C:\用户目录\某个路径" certutil -hashfile "C:\用户目录\某个路径\可疑文件名" icacls "C:\用户目录\某个路径"

第四步，回到日志和时间线。用 wevtutil 查看最近一段时间的进程创建和登录事件，确认这个进程有没有被记载在案，以及它第一次出现的时间窗口。如果系统开启了进程创建审核策略，4688 事件里的命令行参数能把启动方式显示得比较完整。把日志事件和时间字段对应起来，就能还原一条基本时间线。

3.3 输出记录与时间线整理

在整个排查过程里，我比较强调“输出记录”这件事。原因很简单：人的记忆是不可靠的，尤其在高强度排查时，很容易把不同主机、不同时段的输出混在一起。我的做法是按照时间戳命名文件，比如 netstat_20250211_1430.txt，并在检查记录表里写明每条输出对应的主机、操作时间、操作人和判断结论。后续不管是自查还是交接给别人，都不会出现“这条命令是哪台机器上跑的”这种尴尬。

时间线整理建议拆成三个维度：进程启动时间、文件创建时间、日志事件时间。这三个时间如果无法互相印证，说明要么中间有隐藏步骤，要么某个环节没被记录下来。遇到这种情况，宁可扩大检查范围，也不要急着收工。时间线上对不上的地方，往往就是问题藏身的位置。

3.4 批处理脚本：把重复检查自动化

基础命令能同时满足“手动查”和“自动化采集”两件事。这里我提供一个日常巡检脚本模板，可以把网络连接、进程列表、服务列表全部输出到指定目录。脚本很简单，但能省下大量重复劳动：

@echo off set OUT=C:\logs if not exist %OUT% mkdir %OUT% set DAY=%date:~0,4%-%date:~5,2%-%date:~8,2% netstat -ano > %OUT%\netstat_%DAY%.txt tasklist /svc > %OUT%\tasklist_%DAY%.txt wmic process get ProcessId,ParentProcessId,ExecutablePath,CreationDate > %OUT%\process_%DAY%.txt echo done

把这段保存为 .bat 文件，以管理员身份运行即可。部分较新的 Windows 系统中 wmic 默认可能不可用，可以改用 PowerShell 的 Get-CimInstance 替换，思路完全一致。自动化采集的意义在于形成基线：你只有在一个个时间点上留存快照，才能靠前后对比发现变化。没有历史数据，系统今天和昨天有什么不同，你根本说不出来。

4. 常见问题与排查技巧实录

4.1 权限不足：命令看到空白输出的真正原因

我在实际指导别人操作时，最常见的问题不是命令拼错，而是忘了以管理员身份运行。wevtutil、某些 netstat 的扩展参数、wmic 的部分查询，在权限不足时要么返回空白，要么提示拒绝访问。很多人遇到空白输出就开始怀疑命令格式，折腾半小时，最后才发现只是命令行窗口没有提权。这里给个经验：在做系统级排查前，先确认当前窗口是否拥有管理员权限，最直接的办法是执行一条简单的 wevtutil 查询，有输出说明权限基本没问题，没有输出就先解决权限再继续。

4.2 编码与乱码：cmd 输出中文显示异常

Windows 命令行的默认代码页在不同版本上并不完全一致，这就导致一个很经典的现象：执行 dir 或 tasklist 时，中文文件名显示成一串乱码，findstr 过滤中文关键词时也经常匹配不上。我的解决习惯是在脚本开头执行 chcp 65001，切到 UTF-8 代码页，再加一条重定向导出；如果你更习惯旧代码页，也可以统一不做切换，但输出到文本时要注意保存编码，否则后续用脚本解析会非常痛苦。

4.3 输出被截断、误判进程、端口状态理解错误

有几个非常典型的判断误区值得单独列出。第一，tasklist 里看到同名进程就认为它们是同一个程序，这在多实例业务软件里很常见，直接按进程名结束会导致正常服务被连带关闭，所以处理前必须用 PID 精确定位。第二，看到 TIME_WAIT 状态就觉得异常。TIME_WAIT 是 TCP 协议正常关闭连接后的一段等待状态，大量出现不一定代表恶意，需要结合连接的对端地址和持续时间综合判断。第三，netstat 当前没有输出外联，不代表主机是“干净”的，它只能说明当时没有活动连接，很多检测行为都会有周期性，你需要多个时间点的快照对比，不能靠一次输出就下结论。

我把常见的误判整理成一张速查表，方便以后自查：

4.4 不要只依赖命令结果：结合业务与基线判断

基础命令输出的是一份数据，不是一份结论。同样一条 ESTABLISHED 连接，在一个有对外业务的服务器上可能是正常流量，在一台没有对外业务的办公终端上就是需要排查的异常线索。所以我每次给出判断前，都会先想三件事：这个主机正常状态下应该有哪些连接？这些连接一般发生在什么时候？当前时间和业务状态是否匹配？这三个问题回答清楚，再去看命令输出，才不会闹出“把业务进程当恶意进程”的乌龙。

5. 从这份笔记出发的实操心得

5.1 几个我踩过的坑

第一个坑是太相信某一次快照。早期排查时经常是 netstat 看到外联就直接把进程结束了，结果证据链没固定，后面报告里连文件哈希都没有，等于白忙。现在我的原则是：任何结束操作之前，先完成网络、进程、文件、日志四类信息的记录，然后再动手。第二个坑是只看进程名就判断身份。进程名完全是可以伪装的，同名的不一定是同一个程序，不同名的也可能只是换了名字的同一个程序。只有把父进程、路径、启动时间、命令行参数这几个维度组合起来看，判断才算站得住脚。

第三个坑是忽视输出格式和环境差异。同一套命令在不同 Windows 版本上排版并不一致，有些字段名还会变化，如果你把一条命令的输出去硬套另一台机器的场景，很容易误解。更稳妥的方式是把输出保存下来，然后对照官方字段说明或实际环境确认，而不是凭记忆猜。这个习惯帮我避开了很多不必要的误判。

5.2 常见命令速查与后续扩展方向

我把最常用的一组命令整理成速查模板，手边放一份很有用：netstat -ano 看连接，tasklist /svc 看进程和服务，wmic process 查路径和启动时间，dir /a /tc 看文件时间，certutil -hashfile 算哈希，wevtutil qe 查日志，icacls 看权限。这套组合已经能覆盖大多数基础排查需求。往后走，可以继续学习 PowerShell 的日志采集、进程审计策略配置、事件日志导出等方向，把命令行采集整合成周期性的自动化巡检脚本，逐渐从“手工排查”过渡到“主动发现”。

我自己在实际操作中还有一个不大起眼但很有效的习惯：把这份速查表打印出来放在工位上，每次突发情况出现时，先按纸上顺序跑一遍，再考虑是否需要上更复杂的工具。基础命令不性感，但它是所有上层工具的下层逻辑。把这一层打扎实，后面学任何安全平台都会快很多，因为很多平台呈现给你的，其实就是把类似命令的输出做成了图表。