概念验证（Proof of Concept, PoC）或原理证明（Proof of Principle）是一个项目管理术语。在项目管理中，它用于证明某个项目在原则上是可行的。判断标准可以基于技术或商业因素。因此，它是后续工作的基础，就我们而言，即通过确认已发现的漏洞来保护企业网络所需采取的步骤。换句话说，它作为决定后续行动方向的决策基础。同时，它能够帮助识别并最小化风险。

渗透测试流程包括：前期交互（Pre-Engagement）、信息收集（Information Gathering）、脆弱性评估（Vulnerability Assessment）、利用（Exploitation）、后渗透（Post-Exploitation）、横向移动（Lateral Movement）、概念验证（Proof-of-Concept）和后期交互（Post-Engagement）。

这个项目步骤通常被整合到新应用软件（原型开发）或IT安全解决方案的开发流程中。对于我们信息安全领域而言，这是我们在操作系统或应用软件中证明漏洞存在的阶段。我们使用这个PoC来证明存在安全问题，以便开发人员或管理员能够验证它、复现它、了解其影响并测试他们的修复措施。用来证明软件漏洞最常用的例子之一是在目标系统上执行计算器（Windows 上的 calc.exe）。原则上，PoC 也会评估实际利用系统访问的成功概率。

PoC可以有许多不同的表现形式。例如，记录已发现漏洞的文件也可以构成一个PoC。更实用的PoC形式是一个能自动利用所发现漏洞的脚本或代码。这展示了对漏洞的无瑕疵利用。这种变体对于管理员或开发人员来说非常直接，因为他们可以看到我们的脚本利用了哪些步骤来利用该漏洞。

然而，这里有一个显著的缺点，这种情况不时发生。一旦管理员和开发人员从我们这里收到了这样的脚本，他们很容易就会去”对付”我们的脚本。他们专注于改变系统，使得我们创建的脚本不再起作用。重要的是，该脚本只是利用给定漏洞的一种方式。因此，与其配合脚本工作相反，而是针对我们的脚本进行修改和保护系统，使得我们的脚本失效，这并不意味着通过脚本获得的信息无法通过其他方式获取。这是一个重要的方面，应该与管理员和开发人员讨论，并明确提及和指出。

他们从我们这里收到的报告应该能帮助他们看清全局，关注更广泛的问题，并提供清晰的修复建议。在内部评估中发生域沦陷的情况下，在报告中加入攻击链演练是一种很好的方式，可以展示多个缺陷如何被组合利用，以及修复一个缺陷会如何中断整个攻击链，但其他缺陷仍然存在。如果这些缺陷也没有被修复，那么攻击者可能存在另一条路径能够到达攻击链已被修复的点，并继续前进。我们也应该在报告评审会议上强调这一点。

例如，如果某个用户使用了密码Password123，根本的漏洞不在于这个密码本身，而在于密码策略。如果发现一个域管理员使用了这个密码并且随后密码被更改了，那么这一个帐户现在将拥有一个更强的密码，但弱密码问题很可能在组织内仍然普遍存在。

如果密码策略遵循高标准，用户将无法使用如此弱的密码。管理员和开发人员负责其系统和应用的功能性和质量。此外，高质量代表着高标准，这一点我们应该通过我们的修复建议来强调。