<p>从潜在开发者到六岁的小孩都在跳上 vibe 编码的潮流，因此不难理解，罪犯们也喜欢自动化编码工具。</p>
<p>“每个人都在问：vibe 编码是否用于恶意软件？而现在的答案很可能是肯定的，” Palo Alto Networks 的 Unit 42 高级咨询总监 Kate Middagh 在接受 <em>The Register</em> 采访时表示。</p>
<blockquote>
<p>我们合作的组织中，只有大约一半对 AI 有任何限制。</p>
</blockquote>
<p>然而，对防御者来说，银 lining 是，AI 模型即使在被要求编写赎金信时也会犯错，这意味着 vibe 编码攻击可能会失败。</p>
<p>与任何新技术一样，AI 辅助编码引入了许多安全漏洞，包括企业开发团队可能加速工作到安全团队无法匹配的速度。</p>
<p>AI 代理和系统访问和提取不应接触的数据也存在风险，以及提示和内存注入攻击。</p>
<p>还有罪犯或政府支持的黑客团队使用 LLM 编写恶意软件或策划整个攻击的风险——尽管这两者仍然需要人类参与，但最坏的情况正逐渐接近现实安全事件。</p>
<h3>Vibe 编码 SHIELD</h3>
<p>为了帮助公司更好地管理这些风险，Palo Alto Networks 开发了他们所称的 &#34;SHIELD&#34; 框架，旨在在整个编码过程中设置安全控制。Middagh 领导 Unit 42 的 AI 安全服务业务，并在周四共同撰写了一篇关于 SHIELD 框架的博客，并提前与 <em>The Register</em> 分享。</p>
<p>“我们合作的组织中，只有大约一半对 AI 有任何限制，” 她说。</p>
<p>SHIELD 代表：</p>
<ul>
<li>S – 职责分离：这涉及通过限制代理仅限于开发和测试环境来限制访问和权限。</li>
<li>H – 人类参与：要求人类进行代码审查，并在代码合并之前需要拉取请求的批准。</li>
<li>I – 输入/输出验证：包括使用分离提示分区、编码、基于角色的分离等方法来清理提示，然后要求 AI 通过静态应用程序安全测试 (SAST) 在开发后执行逻辑检查和代码验证。</li>
<li>E – 强制安全专注的辅助模型：开发辅助模型——专门设计用于为 vibe 编码应用程序提供自动安全验证的代理——执行 SAST 测试、秘密扫描、安全控制验证和其他验证功能。</li>
<li>L – 最小权限：仅授予 vibe 编码工具和 AI 代理执行其角色所需的最低权限和能力。</li>
<li>D – 防御性技术控制：在使用这些工具之前，在供应链和执行管理的组件周围采用防御性控制，并禁用自动执行，以允许在部署后进行人类参与。</li>
</ul>
<p>我们稍后会详细讨论。但首先，回到 vibe 编码恶意软件。</p>
<p>Middagh 和她的 Palo Alto 同事并不总能明确判断开发者是否使用了 vibe 编码平台来创建恶意软件。有些代码通过包含水印来简化这一过程，验证代码是由 Cursor、Replit、Claude 或其他 AI 工具生成的。</p>
<p>她也不会说哪个工具在罪犯中最受欢迎，尽管她确实提到他们正在使用 &#34;多个&#34; 产品，&#34;根据这些平台的普遍受欢迎程度，你可以推测出每个产品的受欢迎程度。&#34;</p>
<p>Palo Alto 的网络风险咨询团队还观察到环境中存在 &#34;一系列不同的模式，表明&#34; 使用编码平台开发恶意软件，Middagh 补充道。而 Middagh 目睹的其中一个模式——恶意软件开发者直接在代码中写入对大型语言模型的 API 调用——是恶意软件开发者正在进行 vibe 编码的有力证据。</p>
<p>“因此，在恶意软件本身中，有对 OpenAI 或其他平台的 API 调用，询问如何生成恶意软件，如何生成听起来合法的社会工程邮件，” 她解释道，并将其描述为 &#34;直接且不可辩驳的证据，证明他们在恶意软件开发过程中使用了这些 LLM。&#34;</p>
<h3>'安全表演'</h3>
<p>攻击者还在使用 LLM 进行 Middagh 所称的 &#34;安全表演&#34;。这段代码看起来会产生有效的攻击，但由于各种原因无效，包括没有针对特定环境进行定制。&#34;它看起来像是一个有效的攻击，&#34;她说，&#34;但如果你稍微深入挖掘一下，你会发现：‘嘿，等一下，这实际上没有意义。’&#34;</p>
<p>这包括 &#34;悬而未决的攻击策略&#34;，其中 LLM 会生成一种规避技术，例如。&#34;但这种规避技术实际上并不符合我们通常看到的现代恶意行为者，或者它将是从未在环境中实际实施的规避技术——它只是作为对 LLM 的 API 调用的副产品生成的，&#34; Middagh 说。</p>
<p>在一次这样的事件中，Unit 42 记录了发送给 OpenAI 的 GPT-3.5 Turbo 的提示，使用标准 API 请求模型 &#34;生成一个简单的规避技术，用于数据提取工具，并仅返回技术名称，最多三个单词，以帮助避免检测，&#34;她说。该提示包括这些示例：&#34;随机延迟、进程欺骗、内存混淆。&#34;</p>
<blockquote>
<p>我们看到 LLM 会称其为 'readme.txtt' 的幻觉实例。这是威胁行为者绝对不会犯的错误——这就像是勒索软件 101。</p>
</blockquote>
<p>按照指示，LLM 返回了一个技术名称，但 LLM 仅登录到受害者的桌面——并没有实施规避技术。&#34;它只是为了展示和纯粹的记录而出现，&#34;Middagh 说。&#34;可能有办法让它工作，但在环境中从未适当地实施。&#34;</p>
<p>虽然她无法确切知道攻击者为何选择进行安全表演而非真实攻击，但 “如果我必须猜测，我认为这只是一个输出，” Middagh 说。“大型语言模型将生成大量代码，攻击者在匆忙中，没有验证代码输出中的所有内容，因此会出现错误。”</p>
<p>换句话说，当被要求生成恶意代码时，AI 工具会产生与被要求编写合法代码时相同的错误。</p>
<p>幻觉仍然是 AI 的一个常见陷阱，即使是勒索软件开发者也感受到这种痛苦。</p>
<p>在感染受害者的机器后，勒索者会在桌面上留下一个名为 “readme.txt” 的自述文件，其中包含赎金通知和金钱要求。</p>
<p>“我们看到幻觉的实例，其中大型语言模型会称其为 ‘readme.txtt’，” Middagh 说。“这是威胁行为者绝对不会犯的错误——这就像是勒索软件的基础知识。但我们现在看到的是，他们行动得太快，没有进行太多验证或检查，这些事情就发生了。他们对所有事情都采取了全力以赴的态度。”</p>
<p>攻击者并不是唯一在使用缺乏人类情境意识且优先考虑功能而非安全的 AI 模型时犯错误的人。</p>
<p>大多数允许员工使用氛围编码工具的组织也没有对这些工具进行任何正式的风险评估，也没有实施监控输入和输出的安全控制措施。</p>
<p>“如果你是一家企业，有几种方法可以控制和应对氛围编码的风险，” Middagh 说。第一步涉及将最小权限和最小功能原则应用于 AI 工具，就像对待人类用户一样，仅授予完成工作所需的最低角色、责任和权限。</p>
<p>“每个人都对使用 AI 感到非常兴奋，希望他们的开发者能更快，因此整个最小权限和最小功能模型完全被忽视了，” Middagh 说。</p>
<p>接下来，她建议将使用限制为员工可以使用的一个对话型大型语言模型，并在防火墙上阻止所有其他 AI 编码工具。对于那些决定在其环境中需要氛围编码工具的组织，“前进的方式将是 SHIELD 框架，” Middagh 说。®</p>

派拓网络

<p>根据 Palo Alto Networks 的 Kate Middagh 的说法，犯罪分子越来越多地使用人工智能工具进行恶意软件开发。虽然人工智能辅助编码可能引入安全漏洞，但它也存在缺陷，可能导致攻击失败。为了降低风险，Palo Alto 推出了 SHIELD 框架，强调在整个编码过程中实施安全控制。这包括限制访问、要求人工代码审查以及采用专门的安全验证模型。证据表明，恶意软件开发者正在直接将 API 调用集成到人工智能平台中，这表明了一种向人工智能辅助网络犯罪发展的趋势</p>

<p>Interview With everyone from would-be developers to six-year-old kids jumping on the vibe coding bandwagon, it shouldn't be surprising that criminals like automated coding tools too.</p>
<div class="lb-trans"><p>从潜在开发者到六岁的小孩都在跳上 vibe 编码的潮流，因此不难理解，罪犯们也喜欢自动化编码工具。</p>
</div><p>&#34;Everybody's asking: Is vibe coding used in malware? And the answer, right now, is very likely yes,&#34; Kate Middagh, senior consulting director for Palo Alto Networks' Unit 42, told <em>The Register</em>.</p>
<div class="lb-trans"><p>“每个人都在问：vibe 编码是否用于恶意软件？而现在的答案很可能是肯定的，” Palo Alto Networks 的 Unit 42 高级咨询总监 Kate Middagh 在接受 <em>The Register</em> 采访时表示。</p>
</div><blockquote>
<p>Only about half of the organizations that we work with have any limits on AI</p>
</blockquote>
<div class="lb-trans"><blockquote>
<p>我们合作的组织中，只有大约一半对 AI 有任何限制。</p>
</blockquote>
</div><p>The silver lining for defenders, however, is that AI models – even when asked to write ransom notes – make mistakes, meaning vibe-coded attacks can fail.</p>
<div class="lb-trans"><p>然而，对防御者来说，银 lining 是，AI 模型即使在被要求编写赎金信时也会犯错，这意味着 vibe 编码攻击可能会失败。</p>
</div><p>As with any shiny new technology, AI-assisted coding introduces many security vulnerabilities, including the potential for enterprise development teams to accelerate their work to a speed that security teams can't match.</p>
<div class="lb-trans"><p>与任何新技术一样，AI 辅助编码引入了许多安全漏洞，包括企业开发团队可能加速工作到安全团队无法匹配的速度。</p>
</div><p>There are also risks from AI agents and systems accessing and exfiltrating data they shouldn't be allowed to touch, plus prompt and memory injection attacks.</p>
<div class="lb-trans"><p>AI 代理和系统访问和提取不应接触的数据也存在风险，以及提示和内存注入攻击。</p>
</div><p>And then there's the risk of criminals or government-backed hacking teams using LLMs to write malware or orchestrate entire attacks – and while both of these still require a human in the loop, the worst-case scenarios are getting closer to real-life security incidents.</p>
<div class="lb-trans"><p>还有罪犯或政府支持的黑客团队使用 LLM 编写恶意软件或策划整个攻击的风险——尽管这两者仍然需要人类参与，但最坏的情况正逐渐接近现实安全事件。</p>
</div><h3>Vibe coding SHIELD</h3>
<div class="lb-trans"><h3>Vibe 编码 SHIELD</h3>
</div><p>To help companies better manage these risks, Palo Alto Networks developed what it calls the &#34;SHIELD&#34; framework for vibe coding, which is all about placing security controls throughout the coding process. Middagh, who leads Unit 42's AI security services engagements biz, co-authored a Thursday blog about the SHIELD framework and shared it in advance with <em>The Register</em>.</p>
<div class="lb-trans"><p>为了帮助公司更好地管理这些风险，Palo Alto Networks 开发了他们所称的 &#34;SHIELD&#34; 框架，旨在在整个编码过程中设置安全控制。Middagh 领导 Unit 42 的 AI 安全服务业务，并在周四共同撰写了一篇关于 SHIELD 框架的博客，并提前与 <em>The Register</em> 分享。</p>
</div><p>&#34;Only about half of the organizations that we work with have any limits on AI at all,&#34; she said.</p>
<div class="lb-trans"><p>“我们合作的组织中，只有大约一半对 AI 有任何限制，” 她说。</p>
</div><p>SHIELD stands for:</p>
<div class="lb-trans"><p>SHIELD 代表：</p>
</div><ul>
<li>S – Separation of Duties: This involves limiting access and privileges by restricting agents to development and test environments only.</li>
<li>H – Human in the Loop: Mandate code review performed by a human and require a pull request approval prior to code merge.</li>
<li>I – Input/Output Validation: Including using methods such as separating prompt partitioning, encoding, role-based separation to sanitize prompts and then requiring the AI to perform validation of logic checks and code through Static Application Security Testing (SAST) after development.</li>
<li>E – Enforce Security-Focused Helper Models: Develop helper models – specialized agents designed to provide automated security validation for vibe-coded applications – to perform SAST testing, secrets scanning, security control verification, and other validation functions.</li>
<li>L – Least Agency: Only grant the minimum permissions and capabilities required to vibe-coding tools and AI agents needed to perform their roles.</li>
<li>D – Defensive Technical Controls: Employ defensive controls around supply chain and execution management on components before using these tools, and disable auto-execution to allow for human-in-the-loop after deployment.</li>
</ul>
<div class="lb-trans"><ul>
<li>S – 职责分离：这涉及通过限制代理仅限于开发和测试环境来限制访问和权限。</li>
<li>H – 人类参与：要求人类进行代码审查，并在代码合并之前需要拉取请求的批准。</li>
<li>I – 输入/输出验证：包括使用分离提示分区、编码、基于角色的分离等方法来清理提示，然后要求 AI 通过静态应用程序安全测试 (SAST) 在开发后执行逻辑检查和代码验证。</li>
<li>E – 强制安全专注的辅助模型：开发辅助模型——专门设计用于为 vibe 编码应用程序提供自动安全验证的代理——执行 SAST 测试、秘密扫描、安全控制验证和其他验证功能。</li>
<li>L – 最小权限：仅授予 vibe 编码工具和 AI 代理执行其角色所需的最低权限和能力。</li>
<li>D – 防御性技术控制：在使用这些工具之前，在供应链和执行管理的组件周围采用防御性控制，并禁用自动执行，以允许在部署后进行人类参与。</li>
</ul>
</div><p>We'll talk more about that in a minute. But first, back to vibe-coded malware.</p>
<div class="lb-trans"><p>我们稍后会详细讨论。但首先，回到 vibe 编码恶意软件。</p>
</div><p>Middagh and her Palo Alto colleagues can't always definitively determine if developers used a vibe-coding platform to create malware. Some code makes it easy by including a watermark that verifies the code was generated by Cursor, Replit, Claude, or some other AI tool.</p>
<div class="lb-trans"><p>Middagh 和她的 Palo Alto 同事并不总能明确判断开发者是否使用了 vibe 编码平台来创建恶意软件。有些代码通过包含水印来简化这一过程，验证代码是由 Cursor、Replit、Claude 或其他 AI 工具生成的。</p>
</div><p>She also won't say which tool is most popular with criminals, although she did note that they are using &#34;multiple&#34; products, &#34;and just given the general popularity of vibe-coding platforms, you can probably extrapolate based on the popularity of each of these.&#34;</p>
<div class="lb-trans"><p>她也不会说哪个工具在罪犯中最受欢迎，尽管她确实提到他们正在使用 &#34;多个&#34; 产品，&#34;根据这些平台的普遍受欢迎程度，你可以推测出每个产品的受欢迎程度。&#34;</p>
</div><p>Palo Alto's cyber-risk consulting team has also seen &#34;a bunch of different patterns in the environment that are indicative&#34; of using coding platforms to develop malware, Middagh added. And one of these that Middagh has witnessed – malware developers writing API calls to large language models directly into the code – is strong evidence that malware scum are vibe coding.</p>
<div class="lb-trans"><p>Palo Alto 的网络风险咨询团队还观察到环境中存在 &#34;一系列不同的模式，表明&#34; 使用编码平台开发恶意软件，Middagh 补充道。而 Middagh 目睹的其中一个模式——恶意软件开发者直接在代码中写入对大型语言模型的 API 调用——是恶意软件开发者正在进行 vibe 编码的有力证据。</p>
</div><p>&#34;So within the malware itself, there's API calls to OpenAI or other platforms asking how to generate malware, how to generate social engineering emails to make them sound legitimate,&#34; she explained, describing this as &#34;direct and incontrovertible proof that they are using these LLMs in the course of their malware development.&#34;</p>
<div class="lb-trans"><p>“因此，在恶意软件本身中，有对 OpenAI 或其他平台的 API 调用，询问如何生成恶意软件，如何生成听起来合法的社会工程邮件，” 她解释道，并将其描述为 &#34;直接且不可辩驳的证据，证明他们在恶意软件开发过程中使用了这些 LLM。&#34;</p>
</div><h3>'Security theater'</h3>
<div class="lb-trans"><h3>'安全表演'</h3>
</div><p>Attackers are also using LLMs for what Middagh calls &#34;security theater.&#34; This is code that looks like it would produce a valid attack, but it's ineffective for a variety of reasons, including not being customized to a specific environment. &#34;It has the appearance of being a valid attack,&#34; she said, &#34;but if you do just a little bit more digging, you're like: 'Hey, wait a minute, this doesn't actually make sense.'&#34;</p>
<div class="lb-trans"><p>攻击者还在使用 LLM 进行 Middagh 所称的 &#34;安全表演&#34;。这段代码看起来会产生有效的攻击，但由于各种原因无效，包括没有针对特定环境进行定制。&#34;它看起来像是一个有效的攻击，&#34;她说，&#34;但如果你稍微深入挖掘一下，你会发现：‘嘿，等一下，这实际上没有意义。’&#34;</p>
</div><p>This includes &#34;dangling attack strategies,&#34; in which an LLM will generate an evasion technique, for example. &#34;But that evasion technique won't really be aligned with what we typically see for modern-day bad actors, or it'll be an evasion technique that was never actually implemented in the environment – it was just generated as a byproduct of an API call to the LLM,&#34; Middagh said.</p>
<div class="lb-trans"><p>这包括 &#34;悬而未决的攻击策略&#34;，其中 LLM 会生成一种规避技术，例如。&#34;但这种规避技术实际上并不符合我们通常看到的现代恶意行为者，或者它将是从未在环境中实际实施的规避技术——它只是作为对 LLM 的 API 调用的副产品生成的，&#34; Middagh 说。</p>
</div><p>In one such incident, Unit 42 documented a prompt sent to OpenAI's GPT-3.5 Turbo using the standard API asking the model to &#34;generate a simple evasion technique for a data extraction tool, and return only the technique name, max three words, that would help avoid detection,&#34; she said. The prompt included these examples: &#34;random delay, process spoofing, memory obfuscation.&#34;</p>
<div class="lb-trans"><p>在一次这样的事件中，Unit 42 记录了发送给 OpenAI 的 GPT-3.5 Turbo 的提示，使用标准 API 请求模型 &#34;生成一个简单的规避技术，用于数据提取工具，并仅返回技术名称，最多三个单词，以帮助避免检测，&#34;她说。该提示包括这些示例：&#34;随机延迟、进程欺骗、内存混淆。&#34;</p>
</div><blockquote>
<p>We're seeing instances of hallucinations where the LLM will call it 'readme.txtt.' That's a mistake that a threat actor would never make – that's like Ransomware 101</p>
</blockquote>
<div class="lb-trans"><blockquote>
<p>我们看到 LLM 会称其为 'readme.txtt' 的幻觉实例。这是威胁行为者绝对不会犯的错误——这就像是勒索软件 101。</p>
</blockquote>
</div><p>As instructed, the LLM returned a technique name, but the LLM only logged on to the victim's desktop – it didn't implement the evasion technique. &#34;It just appeared for show and purely for logging,&#34; Middagh said. &#34;There would be a way to potentially make this work, but it was never implemented appropriately in the environment.&#34;</p>
<div class="lb-trans"><p>按照指示，LLM 返回了一个技术名称，但 LLM 仅登录到受害者的桌面——并没有实施规避技术。&#34;它只是为了展示和纯粹的记录而出现，&#34;Middagh 说。&#34;可能有办法让它工作，但在环境中从未适当地实施。&#34;</p>
</div><p>While she can't know for sure why an attacker would stage security theater rather than a real attack, &#34;if I had to guess, I think it's just an output,&#34; Middagh said. &#34;The LLM is going to generate a voluminous amount of code, the attacker is rushing, they're not validating everything that's in the code output, and there are errors.&#34;</p>
<div class="lb-trans"><p>虽然她无法确切知道攻击者为何选择进行安全表演而非真实攻击，但 “如果我必须猜测，我认为这只是一个输出，” Middagh 说。“大型语言模型将生成大量代码，攻击者在匆忙中，没有验证代码输出中的所有内容，因此会出现错误。”</p>
</div><p>In other words, AI tools produce the same mistakes when asked to generate malicious code as they do when asked to write legitimate code.</p>
<div class="lb-trans"><p>换句话说，当被要求生成恶意代码时，AI 工具会产生与被要求编写合法代码时相同的错误。</p>
</div><p>Hallucinations remain a common AI pitfall, and even ransomware developers feel this pain.</p>
<div class="lb-trans"><p>幻觉仍然是 AI 的一个常见陷阱，即使是勒索软件开发者也感受到这种痛苦。</p>
</div><p>After infecting a victim's machine, the extortionists leave a readme file on the desktop, usually named &#34;readme.txt,&#34; and it contains the ransom note and monetary demand.</p>
<div class="lb-trans"><p>在感染受害者的机器后，勒索者会在桌面上留下一个名为 “readme.txt” 的自述文件，其中包含赎金通知和金钱要求。</p>
</div><p>&#34;We're seeing instances of hallucinations where the LLM will call it 'readme.txtt,'&#34; Middagh said. &#34;That's a mistake that a threat actor would never make – that's like Ransomware 101. But what we're seeing now is they're moving so fast, and they're not doing much in the way of validation or checking, that these things just happen. They're throwing the kitchen sink at everything.&#34;</p>
<div class="lb-trans"><p>“我们看到幻觉的实例，其中大型语言模型会称其为 ‘readme.txtt’，” Middagh 说。“这是威胁行为者绝对不会犯的错误——这就像是勒索软件的基础知识。但我们现在看到的是，他们行动得太快，没有进行太多验证或检查，这些事情就发生了。他们对所有事情都采取了全力以赴的态度。”</p>
</div><p>Attackers aren't the only ones making mistakes using AI models that lack a human's situational awareness and are built to prioritize functionality over security.</p>
<div class="lb-trans"><p>攻击者并不是唯一在使用缺乏人类情境意识且优先考虑功能而非安全的 AI 模型时犯错误的人。</p>
</div><p>Most organizations that allow their employees to use vibe-coding tools also haven't performed any formal risk assessment on these tools, nor do they have security controls in place to monitor inputs and outputs.</p>
<div class="lb-trans"><p>大多数允许员工使用氛围编码工具的组织也没有对这些工具进行任何正式的风险评估，也没有实施监控输入和输出的安全控制措施。</p>
</div><p>&#34;If you are an enterprise, there's a couple of ways you can control and address the risks of vibe coding,&#34; Middagh said. Step one involves applying principles of least privilege and least functionality to AI tools much as you would to human users, granting only the minimum roles, responsibilities, and privileges needed to do their job.</p>
<div class="lb-trans"><p>“如果你是一家企业，有几种方法可以控制和应对氛围编码的风险，” Middagh 说。第一步涉及将最小权限和最小功能原则应用于 AI 工具，就像对待人类用户一样，仅授予完成工作所需的最低角色、责任和权限。</p>
</div><p>&#34;Everybody is so excited about using AI, and having their developers be speedier, that this whole least privilege and least functionality model has gone completely by the wayside,&#34; Middagh said.</p>
<div class="lb-trans"><p>“每个人都对使用 AI 感到非常兴奋，希望他们的开发者能更快，因此整个最小权限和最小功能模型完全被忽视了，” Middagh 说。</p>
</div><p>Next, she suggests limiting usage to one conversational LLM that employees can use, and blocking every other AI coding tool at the firewall. And for orgs that do decide they need a vibe-coding tool in their environment, &#34;the way forward would be the SHIELD framework,&#34; according to Middagh. ®</p>
<div class="lb-trans"><p>接下来，她建议将使用限制为员工可以使用的一个对话型大型语言模型，并在防火墙上阻止所有其他 AI 编码工具。对于那些决定在其环境中需要氛围编码工具的组织，“前进的方式将是 SHIELD 框架，” Middagh 说。®</p>
</div>

是的，犯罪分子正在利用 AI 来编码恶意软件的特征