安全服务商不仅会剖析网络攻击者可以做些什么来获取凭据，还会剖析他们在获得初始访问权限后会做些什么，并介绍不同的威胁场景，讲述黑客的攻击故事，而这些故事或者基于真实事件，或者是合理的理论。
查找泄露的TLS私钥
对于这种威胁场景，将探索嵌入到容器映像中的秘密的潜在滥用;特别是TLS证书中使用的RSA私钥。在这一场景中，PoorCorp公司使用DockerHub来公开托管他们的容器镜像。黑客扫描DockerHub的图像以查找在构建过程中添加到容器中的秘密。就在那时，他们偶然发现了PoorCorp公司的原有的GitLab容器镜像。
黑客发现了几个添加到图像层的文件，扩展名为.crt和.key。当黑客下载图像并检查.key文件的内容时，他们会看到以下内容：
-----BEGINRSAPRIVATEKEY-----
...(validkeycontents)...
-----ENDRSAPRIVATEKEY-----
然后，黑客检查证书。该证书是通配符TLS证书，对PoorCorp公司域的所有子域均有效。在构建GitLab映像时，PoorCorp公司添加了他们的TLS证书和私钥，以便企业的开发人员能够从内部网络外部访问GitLab。
伪装成PoorCorp公司
既然黑客有了通配符证书，他们就可以冒充PoorCorp公司的域。但是要做到这一点，他们还需要将PoorCorp公司的一个子域访问黑客控制的计算机。是时候进行一些DNS篡改了。
黑客有几个不同的选择。如果PoorCorp是像谷歌这样的知公司，黑客可以带着WiFiPineapple(这是一个使网络攻击者能够通过设置恶意无线接入点窃取用户数据的设备)去繁忙的地方，并欺骗他们的单点登录(SSO)在强制门户中。任何连接到恶意设备的人都会看到他们的凭据被盗。不幸的是，对于黑客来说，PoorCorp公司并没有像谷歌那样普遍用于身份验证。相反，黑客发现了一个不同的攻击媒介：子域接管。
知道他们可以欺骗PoorCorp公司的任何子域之后，黑客立即开始检查PoorCorp.公司域上的所有DNS记录。很快，他们找到了一条指向GitHub页面的A记录(“A”代表“地址”)。PoorCorp公司最近从GitLab迁移到了GitHub，他们将演示网站的代码放在GitHub存储库中，并与GitHub页面一起发布。
PoorCorp公司删除了他们的GitHub页面测试存储库，但忘记清理指向它的DNS记录。黑客启动了一个新的GitHub帐户，创建了PoorCorp公司的SSO的克隆，添加了泄露的TLS证书和密钥，并在GitHub页面上发布了该克隆。当他们设置GitHub页面时，他们将其配置为具有废弃A记录的子域。现在，网络攻击者控制了PoorCorp公司的子域，并且拥有了一个有效的TLS证书。
使用SSO克隆，黑客向PoorCorp公司的几个IT管理员发送了一封鱼叉式网络钓鱼电子邮件。两位管理员都在有效域中被欺骗，并且网络攻击者现在在PoorCorp公司的网络中拥有特权凭据。从那里开始，网络攻击者可以在网络中隐藏并寻找高价值目标，同时伪装成管理员。最终，黑客可以窃取PoorCorp公司的宝贵数据并部署勒索软件。
吸取的教训
现在介绍了完整的场景，以下了解哪里出了问题。
首先是泄露的TLS私钥。PoorCorp公司将他们的通配符证书添加到他们的GitLab映像中，但他们认为一旦发布在DockerHub上，任何人无法从Docker映像中窃取私钥。与其在构建容器时将敏感文件和硬编码环境变量添加到容器中，PoorCorp公司应该使用运行时环境变量和挂载的卷来将秘密传递到容器中，GitGuardian的机密检测CLIggshield已经用于扫描Docker映像的命令。如果人们发现自己也犯了这个错误，则需要立即撤销任何暴露的证书或凭证。
PoorCorp公司做错的另一件事是忘记了被遗弃的GitHubPagesDNS记录。在GitHub页面上发布的站点将始终使用相同的IP地址：
·185.199.108.153
·185.199.109.153
·185.199.110.153
·185.199.111.153
当A记录指向GitHub页面时，对该子域的任何请求都将转到GitHuprepo配置的子域。由于PoorCorp公司放弃了其GitHub页面存储库，它为黑客敞开了大门，让他们可以创建自己的具有相同子域的域。子域接管并不是什么新鲜事，随着技术的发展，总会有新的方法来利用它们。使公共DNS记录保持最新始终是至关重要的。
希望这个场景能让用户在自己的运营环境中进行一些调查，并激发对容器和代码安全性的兴趣。暴露的凭证是威胁参与者的一个巨大的初始访问向量。作为防御者，需要了解凭据可能被泄露的新方式，并且还需要领先于攻击者，切断他们在发现泄露的机密后可能采取的攻击途径。
