获取todesk密码与解除锁屏工具

这篇分享一下零攻防@生吃香菜师傅用C.exe进程内存中提取如版本号、ID、密码、手机号等信息和解除本地锁屏密码限制的工具。

工具优势：

可直接使用CS的execute-assembly命令或者其他C2的.NET执行命令/插件/工具在内存执行提取ToDesk凭据信息（都在内存中执行，无需落地），这样就不用先去dump转储todesk.exe进程内存后下载到本地查找凭据等信息了...而且一些dump操作也会被防护拦截...。

下载地址

https://pan.baidu.com/s/1PLwFvaawtATnGyZuldQhXQ?pwd=dmj9

最强防护也难防大语言模型被欺骗

诺丁汉大学副教授Michael Pound在接受采访时指出，多数安全专业人员对LLM（大语言模型）的底层机器学习原理并不熟悉。虽然这在过去的技术中问题不大，但LLM表面强大的能力容易让人误以为它们不会被欺骗。这种认知偏差可能导致企业仓促构建考虑不周的系统，最终在实际应用中严重失效。

Pound强调，包括LLM在内的大多数生成式AI本质上是概率性的——其行为具有随机性。这意味着它有很大概率能完成预期任务，但几乎不可能达到100%可靠。AI解决方案供应商常宣称其模型具备防护机制和一致性，暗示这些模型不可能出错。但实际上，这只是说明企业尝试训练LLM拒绝一系列预设的恶意提示词，只能将异常行为概率降低到较小值而非归零。对于全新未见过的提示词，LLM是否会拒绝，我们无法提前预知。

Part01

使用LLM处理数据最常犯哪些错误？

短期内，企业应明确内部人员使用的LLM工具及其具体用途。许多终端用户并未意识到，他们输入模型的查询内容会上传至云端，某些服务还可能将这些数据纳入训练集。用户很容易在未充分考虑后果的情况下，上传包含客户或公司机密的信息。最新模型拥有足够参数来学习这些私有数据，并可能将其泄露给第三方。

与传统SQL注入攻击类似，企业必须谨慎处理不受控的用户输入。测试时向LLM重复提问可能得到不同但一致的答案，但实际部署后，用户稍加修改的提问方式——甚至蓄意构造的恶意提示——都可能绕过防护机制。与传统编程不同，LLM无法通过输入格式校验来防范风险，因为语言模型无法区分提示词与其处理的数据——上传的文档或文件都可能成为恶意提示源。

随着LLM获得工具调用能力（如连接其他代码和API），风险进一步加剧。若LLM能发起网络请求，攻击者就可能通过Markdown或URL外泄数据。一旦LLM能访问私有数据，风险等级将显著提升。

Part02

当前最有效的LLM防护措施有哪些？

训练模型识别恶意提示词的防护措施往往只能短期有效，攻击者很快会找到新的绕过方法。防护策略应根据LLM用途定制：若用于文档摘要或数据检索，需严格控制其可访问的文档内容；若直接响应用户输入，则需定期测试LLM行为，并部署辅助功能检测异常提示。

SQL防护的基本原则仍然适用：最小权限原则和基于角色的访问控制。应配置AI系统使LLM即使尝试恶意行为也无法造成实际损害。

Part03

如何安全地将LLM集成到业务流程中？

尽管LLM讨论热度很高，但其实际发展仅数年时间。当前推荐的技术框架包括Haystack、LangChain和Llama-Index，这些方案多基于本地化模型部署，特别适合注重数据隐私的场景。大型模型需要巨额资源，但中等规模模型在标准硬件上也能表现良好。本地测试推荐Ollama工具，精准控制输出则可使用Unsloth进行模型微调。商业产品如Copilot、ChatGPT和Anthropic Claude虽然成本较高但更为可靠。

Part04

LLM集成将带来哪些长期安全挑战？

我们正将LLM嵌入越来越多系统，但人们尚未适应其与传统软件的根本差异。想象编写一段偶尔失效或输出异常结果的代码——即使正确率达99.999%的LLM，每1000次调用仍会出现1次故障。我们需要彻底重构软件开发方式，确保非确定性的LLM能在稳健系统中安全运行。正如我们花费多年修补SQL注入漏洞（2015年仍发生重大事件），未来很长时间里，我们都将面对非常规提示导致LLM灾难性故障的案例。

声明：除发布的文章无法追溯到作者并获得授权外，我们均会注明作者和文章来源。如涉及版权问题请及时联系我们，我们会在第一时间删改，谢谢！文章来源：Hack分享吧、FreeBuf