![有什么好方法可以找到尝试使用错误密码访问数据库的源应用程序?](https://linux22.com/image/783601/%E6%9C%89%E4%BB%80%E4%B9%88%E5%A5%BD%E6%96%B9%E6%B3%95%E5%8F%AF%E4%BB%A5%E6%89%BE%E5%88%B0%E5%B0%9D%E8%AF%95%E4%BD%BF%E7%94%A8%E9%94%99%E8%AF%AF%E5%AF%86%E7%A0%81%E8%AE%BF%E9%97%AE%E6%95%B0%E6%8D%AE%E5%BA%93%E7%9A%84%E6%BA%90%E5%BA%94%E7%94%A8%E7%A8%8B%E5%BA%8F%EF%BC%9F.png)
为了改善我们的安全态势,几个月前我们将几十个内部应用程序改为使用新的用户名和密码来访问 AS400 数据库。
但是,Windows Server(托管我们的主要 SQL Server 实例)上运行着一些神秘进程,该进程仍在使用以前的用户名和密码访问 AS400。AS400 日志显示源是此特定的 Windows Server。
我们搜索了所能想到的一切来查找这个旧用户/密码的使用地点。
- 我们改变了 SQL Server 中的链接服务器。
- 我们禁用了该服务器上的 SQL 代理。
- 我们检查 Windows Server 内的服务。
- 我们检查了 Windows Server 计划任务。
- 我运行了 Wireshark 20 分钟,看看是否可以获得可以提供一些线索的网络跟踪。
我们没什么主意了。您能建议我们做什么来尝试找到使用旧用户名和密码登录 AS400 的源应用程序吗?
答案1
SysInternal 的 Procmon 用于 GUI,或者如果您有任何类型的 SOC/NOC/MSSP,则使用 Sysmon 来接收日志并进行分析。
使用 procmon,只需等待并查看哪个应用程序尝试联系所述 SQL 服务器。
理想情况下,我建议尝试运行 sysmon(和 WinLogBeat)将日志发送到 ELK 实例(Logz.io 上每天有 1GB 的免费空间,我自己的实验室使用)。