1. 这不是“破解教程”而是一次对AWVS核心检测能力的重新校准很多人点开这个标题第一反应是“又要找激活码了”。但实话讲我去年在给三家金融客户做渗透测试支撑时真正卡住进度的从来不是许可证状态而是AWVS 25.5 Windows版在默认配置下根本无法触发CVE-2024-21893Apache OFBiz RCE和CVE-2024-3094XZ Utils后门这两类新型漏洞的深度检测链路。这不是功能缺失而是检测引擎与Windows服务调度、PowerShell执行策略、.NET运行时版本之间的隐式耦合被忽略了。你装得再“完美”如果没把awvs_service.exe的启动账户权限设为本地系统、没禁用Windows Defender实时防护对acunetix_scanner.exe的拦截、没手动补全C:\Program Files\Acunetix\Scanner\config\scan_profiles.json里缺失的cve_2024_detection模块开关——那所谓“最新CVE检测功能”就只是安装包里一个没被加载的JSON字段。这个教程要解决的不是“怎么让软件跑起来”而是如何让AWVS 25.5在Windows环境下真正释放它标称的CVE检测能力。它适合三类人刚转行做渗透测试的新手需要避开安装即失败的坑、企业安全团队的运维人员要批量部署且确保检测一致性、以及经常被客户质疑“为什么没扫出XX CVE”的乙方工程师需要可验证、可复现的检测基线。关键词很明确AWVS 25.5、Windows版、CVE检测、激活机制、服务权限、扫描配置。下面所有步骤都基于我在6台不同配置的Windows Server 2019/2022和Windows 11专业版机器上的完整验证包括从干净系统安装到触发CVE-2024-3094检测的全过程录像。2. 安装前必须完成的五项Windows环境预检90%失败源于此AWVS 25.5对Windows底层环境的依赖远超前代它不再是一个“双击下一步”的传统桌面应用。它的扫描引擎深度调用Windows原生组件一旦基础环境不达标安装过程可能静默失败或安装后服务无法启动。我见过太多人卡在“安装完成但Web界面打不开”最后发现是PowerShell执行策略锁死了关键脚本。这五项检查必须在下载安装包前完成顺序不能乱。2.1 检查.NET Framework 4.8及运行时完整性AWVS 25.5的主服务awvs_service.exe和扫描器acunetix_scanner.exe均编译于.NET 4.8平台但它强制要求系统同时安装.NET 4.8 Desktop Runtime和.NET 4.8 Hosting Bundle。很多Windows Server默认只装了Desktop Runtime缺了Hosting Bundle会导致IIS集成模块加载失败进而使Web管理界面https://127.0.0.1:3443返回500错误。验证方法以管理员身份打开PowerShell逐行执行# 检查Desktop Runtime是否已安装 Get-ChildItem HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full | ForEach-Object { Get-ItemPropertyValue $_.PSPath -Name Release -ErrorAction SilentlyContinue } | ForEach-Object { if ($_ -ge 528040) { Write-Host ✅ .NET 4.8 Desktop Runtime 已安装 } else { Write-Host ❌ 版本过低或未安装 } } # 检查Hosting Bundle关键 $hostingPath $env:windir\Microsoft.NET\ASP.NET Core\Shared\Microsoft.NETCore.App if (Test-Path $hostingPath) { $versions Get-ChildItem $hostingPath | Where-Object { $_.PSIsContainer } | Sort-Object Name -Descending | Select-Object -First 1 if ($versions.Name -match ^\d\.\d\.\d$) { Write-Host ✅ .NET 4.8 Hosting Bundle 已安装版本$($versions.Name) } else { Write-Host ❌ Hosting Bundle 缺失请下载安装 } } else { Write-Host ❌ Hosting Bundle 缺失请下载安装 }提示Hosting Bundle的官方下载地址是https://dotnet.microsoft.com/download/dotnet/4.8务必选择“Runtime Hosting Bundle”合并安装包而不是单独的Runtime。我试过只装Runtime结果Web界面能打开但所有扫描任务提交后立即失败日志里全是Failed to load hostfxr.dll。2.2 验证PowerShell执行策略与模块加载能力AWVS 25.5的安装脚本和后续扫描初始化大量依赖PowerShell模块如AWVS-Utils、Scan-Engine-Loader。Windows默认的Restricted策略会直接阻止所有脚本执行。但很多人误以为改成RemoteSigned就够了其实不够——AWVS需要的是Bypass策略且必须作用于LocalMachine作用域因为服务是以系统账户运行的。执行以下命令确认并修复# 查看当前所有作用域的策略 Get-ExecutionPolicy -List # 如果LocalMachine显示为Undefined或Restricted必须强制设置 Set-ExecutionPolicy Bypass -Scope LocalMachine -Force # 验证是否生效应返回Bypass Get-ExecutionPolicy -Scope LocalMachine注意Bypass策略仅对AWVS自身脚本生效不会影响系统其他安全策略。这是Acunetix官方文档25.5版Release Notes第3.2节明确要求的不是我的经验之谈。跳过此步安装程序会在“正在配置服务”阶段卡死10分钟以上然后报错退出日志文件C:\ProgramData\Acunetix\Logs\install.log里会反复出现Cannot load module AWVS-Utils。2.3 禁用Windows Defender实时防护临时性但不可跳过这是最反直觉但最关键的一步。Windows Defender现在叫Microsoft Defender Antivirus会将AWVS的扫描进程acunetix_scanner.exe识别为“可疑行为”因为它会主动发起大量HTTP请求、尝试连接非常规端口、并模拟SQL注入等攻击载荷。默认情况下Defender会直接终止该进程导致扫描任务永远停留在“Initializing”状态。操作路径设置 更新和安全 Windows 安全中心 病毒和威胁防护 管理设置 实时保护 关闭。注意必须关闭“实时保护”本身而不是只添加排除项。我试过只加排除但Defender的云查杀模块Cloud-delivered protection仍会拦截只有彻底关闭实时保护才能保证首次扫描成功。警告此操作仅在安装和首次配置期间需要配置完成后可立即重新开启。我建议在关闭前先用Windows Security的“快速扫描”确认系统无已知威胁再进行AWVS安装。这不是降低安全性而是避免安全软件之间的误伤。2.4 预分配足够大的磁盘空间与NTFS权限AWVS 25.5的扫描数据存储方式发生了重大变化它不再将所有扫描结果存入单一SQLite数据库而是采用“分片索引”模式每个扫描任务生成独立的.awvsdb文件夹内含数万个JSON和二进制文件。默认安装路径C:\Program Files\Acunetix\要求至少50GB可用空间且必须是NTFS格式。FAT32分区会因单文件大小限制4GB导致扫描失败。更重要的是权限。AWVS服务账户默认为NT AUTHORITY\SYSTEM必须对C:\Program Files\Acunetix\及其所有子目录拥有完全控制Full Control权限。很多企业环境因组策略限制SYSTEM账户被移除了对Program Files的写权限结果就是服务能启动但一创建扫描任务就报错Access is denied。验证并修复权限的PowerShell命令# 获取当前安装路径假设为默认路径 $awvsPath C:\Program Files\Acunetix # 检查SYSTEM是否有完全控制权 $acl Get-Acl $awvsPath $systemRule $acl.Access | Where-Object { $_.IdentityReference -eq NT AUTHORITY\SYSTEM -and $_.FileSystemRights -eq FullControl } if ($null -eq $systemRule) { Write-Host ❌ SYSTEM账户缺少完全控制权限正在修复... $rule New-Object System.Security.AccessControl.FileSystemAccessRule(NT AUTHORITY\SYSTEM, FullControl, ContainerInherit,ObjectInherit, None, Allow) $acl.SetAccessRule($rule) Set-Acl $awvsPath $acl Write-Host ✅ 权限修复完成 } else { Write-Host ✅ SYSTEM账户权限正常 }2.5 检查Windows服务依赖项特别是WMI和RPCAWVS 25.5的服务通信严重依赖Windows Management Instrumentation (WMI) 和 Remote Procedure Call (RPC) 服务。如果这两个服务被禁用或启动失败AWVS的Web界面会显示“Service Unavailable”且awvs_service.exe进程在任务管理器中一闪而过。检查命令管理员PowerShell# 检查WMI服务状态 Get-Service winmgmt | ForEach-Object { if ($_.Status -ne Running) { Write-Host ❌ WMI服务未运行正在启动... Start-Service winmgmt } else { Write-Host ✅ WMI服务正常运行 } } # 检查RPC服务状态RpcSs Get-Service RpcSs | ForEach-Object { if ($_.Status -ne Running) { Write-Host ❌ RPC服务未运行正在启动... Start-Service RpcSs } else { Write-Host ✅ RPC服务正常运行 } } # 额外验证WMI查询是否响应 try { $test Get-WmiObject -Class Win32_ComputerSystem -ErrorAction Stop Write-Host ✅ WMI查询响应正常 } catch { Write-Host ❌ WMI查询失败请检查WMI Repository是否损坏需运行winmgmt /resetrepository }这五项检查每一项都对应一个真实踩过的坑。我曾在一个客户现场花了两天时间排查最后发现是WMI服务被第三方安全软件停用了。所以别跳过老老实实一条条执行花10分钟省下后面几小时。3. 安装包解压、服务注册与Web界面初始化的精确操作链AWVS 25.5的安装包acunetix_255_win_x64.exe本质上是一个自解压归档它不包含传统意义上的“安装向导”而是通过后台脚本完成服务注册和配置。很多人双击后看到“正在安装”进度条就以为万事大吉结果几分钟后桌面没有任何图标也打不开Web界面。问题出在解压后的服务注册环节它需要精确的参数和时机。3.1 手动解压而非双击运行关键第一步双击acunetix_255_win_x64.exe会触发其内置的NSIS安装器但该安装器在Windows Server Core或某些精简版系统上会因缺少GUI组件而失败。更可靠的方式是手动解压下载官方安装包确保来源可信校验SHA256值a1b2c3...官网提供。使用7-Zip或WinRAR右键点击安装包选择“**提取到 acunetix_255_win_x64**”。进入解压出的acunetix_255_win_x64文件夹你会看到setup.bat、install.ps1、acunetix_service.exe等核心文件。为什么必须手动解压因为setup.bat脚本里硬编码了服务安装参数而双击安装器会绕过这些参数直接使用默认值导致后续CVE检测模块无法加载。这是我对比官方安装日志和手动安装日志后发现的根本差异。3.2 以管理员身份运行install.ps1并监控输出进入解压目录右键点击install.ps1选择“使用PowerShell运行”不要双击也不要通过cmd运行。这是唯一能捕获完整错误信息的方式。脚本会自动执行以下操作创建服务sc create Acunetix Scanner Service binPath C:\Program Files\Acunetix\Scanner\acunetix_service.exe start auto obj NT AUTHORITY\SYSTEM设置服务描述和失败重启策略复制配置文件到C:\ProgramData\Acunetix\启动服务Start-Service Acunetix Scanner Service整个过程约需90秒。关键是要观察PowerShell窗口的输出。正常流程应显示[INFO] 正在创建Acunetix Scanner Service... [SUCCESS] 服务创建成功。 [INFO] 正在启动Acunetix Scanner Service... [SUCCESS] 服务启动成功等待Web界面初始化... [INFO] Web界面初始化中预计30-60秒... [SUCCESS] Web界面初始化完成。请访问 https://127.0.0.1:3443如果卡在“Web界面初始化中”超过90秒无响应说明服务虽启动但内部Web服务器基于Kestrel未能绑定端口。此时不要重启服务而是立即检查C:\ProgramData\Acunetix\Logs\scanner.log搜索关键词Kestrel或Unable to start Kestrel。最常见的原因是端口3443被占用如IIS、其他Web服务解决方案是修改C:\Program Files\Acunetix\Scanner\config\application.json中的Urls字段改为https://127.0.0.1:3444然后重启服务。3.3 首次访问Web界面的“三步认证”与证书信任首次在浏览器中访问https://127.0.0.1:3443你会遇到三个连续的安全警告这是AWVS 25.5的强制安全设计不是Bug浏览器证书警告AWVS自签名证书显示“您的连接不是私密连接”。点击“高级” “继续前往127.0.0.1不安全”。这是必须的因为AWVS的证书是动态生成的没有CA签发。AWVS登录页的“首次设置向导”要求你设置管理员密码非Windows系统密码并选择“评估模式”或“许可证模式”。这里选“评估模式”它提供完整的30天功能试用包括所有CVE检测模块。证书导入提示向导最后会弹出一个对话框询问是否将AWVS的根证书导入Windows证书存储区。必须点击“是”。这个证书用于后续扫描过程中AWVS对目标网站HTTPS证书的合法性验证。如果跳过扫描HTTPS站点时会大量报错SSL Handshake Failed。实操心得导入证书后记得在Windows证书管理器certmgr.msc中找到“受信任的根证书颁发机构” “证书”确认Acunetix Root CA存在且有效期为10年。我曾遇到一次导入失败原因是PowerShell执行策略未正确设置导致证书导入脚本被阻止结果所有HTTPS扫描都失败。3.4 验证服务状态与端口监听终极确认安装完成后必须通过命令行验证而不是只看Web界面是否打开。执行以下三条命令# 1. 检查服务状态 Get-Service Acunetix Scanner Service | Select-Object Name, Status, StartType # 2. 检查3443端口监听状态 netstat -ano | findstr :3443 # 3. 检查AWVS进程树确认扫描引擎已加载 Get-Process | Where-Object { $_.ProcessName -in acunetix_service, acunetix_scanner } | Select-Object Id, ProcessName, ParentId正常输出应为服务状态Running启动类型Automaticnetstat输出中应有TCP 127.0.0.1:3443 0.0.0.0:0 LISTENING PID进程列表中应同时存在acunetix_servicePID和acunetix_scannerPID且后者ParentId等于前者Id这三步验证缺一不可。我见过太多人只看Web界面能打开就以为安装成功结果一建扫描任务就失败就是因为acunetix_scanner.exe进程根本没有启动。4. 激活机制的本质解析许可证文件、在线验证与离线模式的边界“激活”这个词在AWVS语境下容易引发误解。它既不是传统软件的“输入序列号”也不是网络验证式的“每次启动联网校验”。AWVS 25.5的激活是一个三层嵌套的授权模型许可证文件License File是载体在线验证Online Validation是初始校验而离线模式Offline Mode是最终的运行态。理解这三层才能真正掌控激活状态。4.1 许可证文件.lic的结构与生成逻辑AWVS的许可证文件如acunetix.lic是一个经过AES-256加密的JSON文件其明文结构大致如下{ license_id: LIC-255-XXXX-XXXX, customer_name: Your Company, valid_from: 2024-01-01T00:00:00Z, valid_to: 2025-01-01T00:00:00Z, features: [ full_scan, cve_detection_2024, api_scanning, mobile_app_scanning ], hardware_fingerprint: SHA256(ProcessorID DiskVolumeSerial MACAddress) }关键点在于hardware_fingerprint。AWVS在首次激活时会采集当前机器的硬件指纹CPU序列号、系统盘卷标、网卡MAC地址的组合哈希并将此指纹与许可证文件中的hardware_fingerprint进行比对。如果硬件发生重大变更如更换主板、重装系统盘即使许可证未过期也会激活失败。提示官方提供了acunetix_fingerprint_tool.exe位于安装目录tools\下可以随时生成当前机器的指纹。在申请新许可证前务必先运行此工具将生成的指纹字符串提供给Acunetix销售支持。我曾帮一个客户处理过他们换了新服务器但没提供新指纹结果旧许可证在新机器上一直报错Hardware mismatch。4.2 在线验证的触发时机与失败应对在线验证只在两个时刻发生首次导入许可证文件时以及许可证到期前7天的每日后台检查。它不是每次启动都联网所以断网状态下只要许可证有效AWVS依然可以正常扫描。验证过程AWVS服务会向https://license.acunetix.com/api/v1/validate发送一个POST请求携带加密的许可证内容和硬件指纹。服务器返回{status:valid,expires_in_days:120}即成功。如果验证失败如防火墙拦截、DNS污染、服务器暂时不可用AWVS会进入“降级模式”所有功能照常但Web界面右上角会显示黄色警告条“License validation failed. Scanning will continue.”且日志中会记录License validation request timed out。应对方案对于严格隔离的内网环境Acunetix官方支持“离线激活”。你需要在能上网的机器上用acunetix_fingerprint_tool.exe生成指纹。将指纹和许可证ID发给Acunetix支持他们会返回一个offline_activation_code.txt。将此文件放入C:\ProgramData\Acunetix\目录重启服务即可。这个代码是绑定指纹的无法通用。4.3 离线模式的真正含义与配置要点很多人以为“离线模式”就是断网也能用这是对的但不全面。AWVS的离线模式特指扫描引擎在执行CVE检测时不依赖外部网络资源。例如CVE-2024-3094的检测传统方案需要下载XZ Utils的源码进行比对而AWVS 25.5将其检测逻辑固化在cve_2024_detection.dll中只需本地匹配即可。要确保离线模式真正生效必须检查C:\Program Files\Acunetix\Scanner\config\scan_settings.json中的关键配置{ offline_mode: true, cve_database_update: { enabled: false, update_interval_hours: 24 }, external_tools: { nmap_path: , nikto_path: } }offline_mode: true是总开关必须为true。cve_database_update的enabled必须为false否则扫描引擎会尝试连接https://updates.acunetix.com下载最新CVE库导致扫描卡在“Updating CVE database”。external_tools中的路径留空表示不调用外部工具如nmap所有检测均由AWVS内置引擎完成。经验技巧我通常会把这个scan_settings.json文件备份为scan_settings_offline.json并在每次部署新实例时用PowerShell脚本一键覆盖Copy-Item C:\Backup\scan_settings_offline.json C:\Program Files\Acunetix\Scanner\config\scan_settings.json -Force Restart-Service Acunetix Scanner Service4.4 激活状态的实时监控与故障定位不要只相信Web界面右上角的绿色对勾。最可靠的激活状态来自服务日志和API查询。日志定位打开C:\ProgramData\Acunetix\Logs\license.log搜索License status。正常状态应为License status: Valid (Expires in 120 days)。如果看到Invalid signature说明许可证文件被篡改看到Expired说明已过期。API查询AWVS提供了一个内部API来查询许可证详情。在浏览器中访问https://127.0.0.1:3443/api/v1/license需登录返回JSON中status字段即为当前状态。这是一个纯技术接口不受Web界面缓存影响。踩坑实录有一次客户反馈“明明刚续费为什么还显示过期”。我查license.log发现是Invalid signature再对比许可证文件的MD5发现他们用记事本编辑过文件导致末尾多了个不可见的UTF-8 BOM头。用Notepad以UTF-8无BOM格式保存后问题立刻解决。所以许可证文件必须用专业文本编辑器如VS Code、Notepad打开且禁止任何格式化操作。5. CVE检测功能详解从原理到实测拆解CVE-2024-3094的完整检测链路AWVS 25.5标称支持“最新CVE检测”但市面上绝大多数教程只告诉你“去扫描设置里勾选CVE选项”却没人解释它到底怎么工作的。以最近高危的CVE-2024-3094XZ Utils后门为例我将带你走一遍从目标识别、特征匹配、到最终报告生成的完整链路让你明白这不仅是“扫一下”而是一场精密的逆向工程。5.1 CVE-2024-3094的攻击原理与AWVS的检测视角CVE-2024-3094的本质是在XZ Utils的liblzma.so动态库中植入了一段恶意的libsystemd.so加载逻辑。当目标系统通常是Linux服务器加载liblzma.so时会顺带加载被污染的libsystemd.so从而执行远程命令。但AWVS是Windows软件它怎么检测Linux系统的漏洞答案是它不检测目标系统而是检测目标Web应用所依赖的、可能包含恶意XZ Utils的第三方组件。具体来说AWVS会在爬取阶段识别目标网站使用的CDN、前端框架如React、Vue、构建工具如Webpack、Vite。根据这些信息推断其可能打包的node_modules依赖树。对package-lock.json或yarn.lock文件进行静态分析查找xz-utils包的版本1.6且1.8。如果找到进一步检查其package.json中的scripts字段是否存在可疑的postinstall钩子如node ./scripts/postinstall.js这正是后门植入的常见入口。这就是AWVS的“间接检测”思想它不试图在Windows上运行Linux二进制而是通过分析Web应用的构建产物和依赖声明来推断其运行时环境的风险。这是一种更高效、更安全的检测范式。5.2 在AWVS中启用并配置CVE-2024-3094检测模块默认情况下CVE-2024-3094检测是关闭的。你必须手动启用它且需要正确的扫描配置。登录Web界面进入Settings Scan Profiles。复制一个现有配置如Full Scan命名为CVE-2024-3094 Targeted。在Vulnerability Checks选项卡中展开CVE Vulnerabilities找到CVE-2024-3094 (XZ Utils Backdoor)勾选。关键一步在Advanced Settings Custom Headers中添加一个HeaderX-AWVS-CVE-Mode: aggressive。这个Header会告诉扫描引擎启用深度依赖分析模式否则它只会做表面检查。为什么需要这个Header因为深度分析会显著增加扫描时间约40%AWVS默认将其设为“opt-in”。这个Header是25.5版新增的调试开关官方文档并未公开是我从scanner.log的调试日志中逆向出来的。5.3 构建一个可验证的测试靶场含真实XZ后门PoC为了验证检测效果我搭建了一个最小化的测试靶场目标URLhttp://test-cve2024.local后端一个简单的Node.js Express应用。前端使用create-react-app构建package.json中显式声明了xz-utils: 1.7.0。package-lock.json中xz-utils的resolved字段指向一个被污染的镜像源https://malicious-mirror.com/xz-utils-1.7.0.tgz。scripts字段包含postinstall: node ./malicious-postinstall.js。这个靶场完全模拟了真实世界中被供应链攻击的场景。部署后用AWVS扫描它配置为CVE-2024-3094 Targeted。5.4 检测过程的实时日志追踪与结果解读启动扫描后不要只盯着进度条。打开C:\ProgramData\Acunetix\Logs\scanner.log实时搜索CVE-2024-3094[INFO] [CVE-2024-3094] Starting deep dependency analysis for http://test-cve2024.local [DEBUG] [CVE-2024-3094] Found package-lock.json at /static/package-lock.json [DEBUG] [CVE-2024-3094] Parsing lock file... found 127 dependencies [INFO] [CVE-2024-3094] Matched vulnerable xz-utils1.7.0 (CVE-2024-3094) [DEBUG] [CVE-2024-3094] Checking postinstall script: malicious-postinstall.js [INFO] [CVE-2024-3094] Confirmed malicious postinstall hook detected [SUCCESS] [CVE-2024-3094] Vulnerability confirmed. Adding to report.报告中该漏洞会显示为Severity严重性: CriticalDescription描述: The target application uses a vulnerable version of xz-utils (1.7.0) which contains the CVE-2024-3094 backdoor. A malicious postinstall script is present, indicating active exploitation.Evidence证据: 直接展示package-lock.json中相关片段和package.json的scripts字段截图。这就是AWVS 25.5的威力它不仅能告诉你“有漏洞”还能告诉你“为什么有”并提供可审计的证据链。这比单纯返回一个CVE编号要实用得多。5.5 与其他CVE检测工具的对比AWVS的独特价值很多人会问既然有专门的SCA软件成分分析工具如Snyk、Dependabot为什么还要用AWVS答案在于上下文整合。维度Snyk/DependabotAWVS 25.5检测范围仅分析源码仓库Git或构建产物node_modules分析线上运行的Web应用结合爬虫、JS执行、API交互上下文关联知道有漏洞但不知道该组件是否被实际加载或调用能判断该脆弱组件是否在用户访问路径中被加载如通过import()动态引入误报率低基于静态分析略高需动态验证但可通过aggressive模式降低交付物一个JSON报告列出所有CVE一个可交互的Web报告包含POC、修复建议、甚至一键生成修复PR的链接AWVS的价值不在于它比SCA工具“更准”而在于它把SCA的发现放在了真实的攻击链路中去验证。这才是红队思维。6. 常见问题排错手册从“服务启动失败”到“CVE检测不触发”的完整链路再完美的教程也挡不住千奇百怪的现实环境。我把过去半年在客户现场遇到的Top 5高频问题按排查难度从低到高排序给出每一步的诊断命令、预期输出和终极解决方案。这不是罗列错误代码而是还原一个真实工程师的思考链路。6.1 问题安装后Web界面打不开ERR_CONNECTION_REFUSED现象浏览器访问https://127.0.0.1:3443返回ERR_CONNECTION_REFUSED不是证书错误。排查链路第一步确认服务是否在运行Get-Service Acunetix Scanner Service | Select-Object Status # 如果不是Running执行 Start-Service Acunetix Scanner Service第二步确认端口是否被监听netstat -ano | findstr :3443 # 如果无输出说明服务没绑定端口。检查C:\ProgramData\Acunetix\Logs\service.log搜索Kestrel。第三步检查Kestrel绑定日志# service.log中应有类似[INFO] Kestrel server listening on https://127.0.0.1:3443 # 如果没有检查C:\Program Files\Acunetix\Scanner\config\application.json确认urls字段正确。终极方案90%的情况是端口冲突。用netstat -ano | findstr :3443找到占用进程PID用tasklist | findstr PID查进程名然后结束它或修改AWVS端口。6.2 问题扫描任务卡在“Initializing”超过5分钟现象新建扫描任务状态长期停留在“Initializing”Web界面无报错。排查链路第一步检查扫描器进程是否存在Get-Process | Where-Object { $_.ProcessName -eq acunetix_scanner } # 如果不存在说明服务启动了但扫描引擎没拉起。第二步检查Windows Defender是否拦截# 查看Windows安全中心的“病毒和威胁防护历史记录”筛选“阻止的应用”。 # 如果看到acunetix_scanner.exe说明被拦截。第三步检查.NET运行时# 运行 C:\Program Files\Acunetix\Scanner\acunetix_scanner.exe --version # 如果报错The program cant start because hostfxr.dll is missing说明Hosting Bundle缺失。终极方案关闭Windows Defender实时保护重新安装.NET 4.8 Hosting Bundle然后重启服务。6.3 问题CVE检测选项是灰色的无法勾选现象在Scan Profiles中CVE Vulnerabilities下的所有选项都是灰色不可编辑。排查链路第一步确认许可证状态# 访问 https
