从阅读披露来看，所发生的情况似乎是开放端口实际上不仅仅是一个随机端口，而是一个从未被设计为直接暴露给外部世界的某个内部服务正在监听的端口. 如果该内部服务存在漏洞，则可能允许攻击者获取在指定时间段内使用其服务的用户的 API 密钥。

虽然他们确实注意到攻击看起来像是自动攻击而不是有针对性的攻击，但应该考虑到老练的攻击者经常使用高度可见的自动攻击来转移服务器和系统管理员的注意力，使其远离正在发生的另一个隐蔽的、有针对性的攻击同时，即引起大量关注的大型DDoS只是一种转移。

如果一个老练的攻击者设法获得进入系统的特权，使其看起来好像没有人泄露重要数据，他们可能已经删除了他们的踪迹。这就是为什么他们建议更改您的 API 密钥，即使他们没有发现实际查询数据的证据。特别是因为这是一个被入侵的日志服务器，并且由于系统管理员通常会使用日志来检测入侵，因此被入侵的日志服务器可以隐藏真正发生的事情。

一个老练的攻击者也可以在系统上留下一个后门/rootkit，以便在以后每个人都认为事情已经解决时重新进入系统，这样他们就可以从安全边界内以更悠闲的速度进行实际攻击，这可能非常危险。这就是为什么他们要停用所涉及的机器。

或者可能是他们这样做是为了向一些潜在的具有安全意识的客户展示，这些客户由于对其安全性的怀疑而对购买决定持观望态度。这可能会改变那些潜在客户决定接受他们服务的态度，因为他们现在放心，当存在可能影响他们的漏洞时，公司不会保持沉默。

是否有一些理由认为仅仅开放端口会被认为是一种潜在的妥协？

是的，开放端口暴露了一个并非为外部使用而设计的内部服务。供内部使用的服务通常缺乏面向公众的服务所获得的安全强化，因为假设该服务只能从受信任的机器访问。例如，内部服务可能不使用 SSL 在受信任的网络中进行通信，或者他们可能不会像假设受信任的发件人已经完成任何必要的验证那样彻底地验证他们的输入，或者他们可能具有无需身份验证即可使用的管理命令，因为它假定任何必要的身份验证都已由面向公众的服务完成。