 |
| Bellacosa Mainframe e a insegurança digital o caso da tv boxes |
☕ UM CAFÉ NO BELLACOSA MAINFRAME
🎲 KAIJI E A ROLETA RUSSA DIGITAL: O DIA EM QUE 1,3 MILHÃO DE TV BOXES APOSTARAM A SEGURANÇA DOS SEUS DONOS!
Uma fabricante chinesa, um Android adulterado, milhões de vítimas e um cassino clandestino de computadores zumbis. Sob a batuta de Kaiji Itou, vamos investigar como o malware XCPE transformou aparelhos domésticos em instrumentos de crimes digitais — e descobrir o que COBOL, RACF, JCL, APF e o IBM Z podem aprender com essa tragédia tecnológica.
Bellacosa Mainframe — Arqueologia da Computação, COBOL, IBM Z, Segurança Cibernética e os Fantasmas Escondidos no Firmware
6 de novembro de 2026 | Segurança Cibernética | COBOL | Mainframe | Android | IoT
🎬 Prólogo — Kaiji entra no cassino e descobre que a televisão está apostando por ele
Imagine a seguinte cena.
É uma noite chuvosa em Tóquio.
Kaiji Itou, protagonista do anime Gyakkyō Burai Kaiji: Ultimate Survivor, está sentado diante de uma pequena televisão. Seu apartamento é modesto, o dinheiro praticamente desapareceu e as dívidas continuam aumentando.
Na televisão, uma propaganda promete resolver seus problemas.
— Compre nossa fantástica TV Box! Milhares de canais, filmes, aplicativos, entretenimento ilimitado e um preço inacreditável!
Kaiji examina o aparelho.
— Por esse preço? Não pode ser verdade...
Mas a tentação vence.
Ele compra.
Conecta o equipamento à televisão, informa a senha do Wi-Fi e começa a assistir.
Tudo funciona perfeitamente.
Ou quase.
Durante a madrugada, enquanto Kaiji dorme, sua TV Box estabelece comunicação com servidores desconhecidos. Recebe instruções, instala programas clandestinos e começa a utilizar sua conexão residencial para atividades que ele jamais autorizou.
Em algum lugar da internet, criminosos negociam acesso àquela pequena máquina.
Kaiji desconhece tudo.
Então surge uma figura imaginária, semelhante aos administradores dos jogos cruéis que tanto marcaram sua história.
— Kaiji! Você acaba de entrar em nossa maior competição!
— Mas eu não aceitei participar de jogo nenhum!
— Isso é o mais divertido! Você comprou o equipamento, pagou a eletricidade, contratou a internet e agora nós utilizamos tudo isso para ganhar dinheiro!
ZAWA... ZAWA... ZAWA...
O suspense característico de Kaiji toma conta da sala.
Porque existe algo muito pior do que perder uma aposta.
É descobrir que alguém apostou utilizando seus recursos sem pedir autorização.
E, infelizmente, o que parecia apenas mais uma história extravagante de anime ganhou um correspondente assustador no mundo real.
Em novembro de 2026, o Google revelou uma operação envolvendo mais de 1,3 milhão de dispositivos Android comprometidos.
O nome da ameaça?
XCPE.
E a grande surpresa?
Segundo a investigação do Google, o fabricante estava envolvido intencionalmente na criação, distribuição e monetização do malware.
Prepare o café.
Nossa viagem pelo cassino clandestino da tecnologia está apenas começando.
🎲 Capítulo I — A banca sempre ganha: o escândalo Videostrong
Em 2 de novembro de 2026, o Google Threat Intelligence Group publicou uma investigação intitulada Shutting the Door on the XCPE Botnet.
O relatório apresentou uma conclusão gravíssima.
A empresa chinesa Videostrong Technology, fabricante e desenvolvedora de dispositivos Android, teria incorporado deliberadamente uma porta dos fundos ao firmware de equipamentos comercializados internacionalmente.
Essa conclusão foi apresentada pelo Google com elevado grau de confiança.
Não se tratava simplesmente de um programador descuidado.
Não era apenas uma vulnerabilidade esquecida.
O Google descreveu uma operação organizada para obter lucro mediante a exploração clandestina de equipamentos vendidos aos consumidores.
Uma fábrica de vítimas
A investigação identificou mais de 1,3 milhão de dispositivos integrados à rede XCPE.
Os aparelhos atingidos incluíam diferentes marcas e modelos, principalmente TV Boxes, mas também outras categorias de equipamentos Android.
A operação contava com uma característica especialmente preocupante: a Videostrong atuava como fabricante original e também como desenvolvedora para outras marcas.
Em outras palavras, um consumidor poderia comprar uma TV Box com determinado nome comercial sem perceber que parte do hardware ou software vinha de um fornecedor envolvido no caso.
É semelhante ao que acontece na indústria automobilística.
Diferentes fabricantes podem utilizar componentes produzidos pelo mesmo fornecedor.
Se esse componente apresentar um defeito grave, o problema poderá aparecer em veículos com marcas completamente diferentes.
No caso XCPE, entretanto, estamos falando de um componente digital capaz de executar instruções clandestinas.
O Brasil também participou desse jogo
A reportagem da Fast Company Brasil, publicada em 5 de novembro de 2026, apresentou dados da TrendAI apontando aproximadamente 150 mil dispositivos comprometidos no Brasil.
Um número impressionante.
Imagine quantas residências, pequenos comércios, escritórios e estabelecimentos podem possuir equipamentos desse tipo.
Uma TV Box escondida atrás da televisão parece inofensiva.
Mas um dispositivo conectado à rede deve ser tratado como um computador.
Porque é exatamente isso que ele é.
A punição aplicada
O Google anunciou medidas contra a Videostrong, incluindo o rompimento da relação comercial e a proibição de produzir ou fornecer dispositivos e software para o ecossistema Android certificado com aplicativos Google pré-instalados.
Também atuou, junto a parceiros, para interromper servidores e domínios de comando e controle.
A investigação apontou ainda que a interrupção da infraestrutura de grupos associados poderia afetar o acesso criminoso a pelo menos outros 10 milhões de dispositivos comprometidos por diferentes mecanismos de distribuição.
Atenção: esses 10 milhões adicionais não devem ser somados automaticamente como se todos fossem TV Boxes infectadas pelo XCPE. Trata-se de outra estimativa, relacionada às redes de malware de parceiros criminosos.
Kaiji observa os números.
— Então não era um pequeno golpe de esquina...
Não.
Era um empreendimento criminoso em escala industrial.
🧠 Capítulo II — Engenharia do golpe: o segredo estava escondido no firmware
Para compreender o que aconteceu, precisamos conhecer três elementos fundamentais: hardware, firmware e sistema operacional.
Primeiro: o hardware
Hardware é a parte física de um dispositivo.
Na TV Box encontramos processador, memória RAM, armazenamento, interfaces de rede e circuitos eletrônicos.
O equipamento recebe eletricidade e executa instruções.
Segundo: o firmware
Firmware é o software armazenado no equipamento que participa de sua inicialização e de seu funcionamento básico.
Em dispositivos Android, a imagem de firmware pode conter o sistema operacional, componentes privilegiados, aplicativos pré-instalados e configurações específicas do fabricante.
É importante distinguir firmware de uma memória ROM imutável.
Muitos equipamentos modernos armazenam esse software em memória flash, permitindo atualizações e substituições controladas.
Portanto, firmware não significa necessariamente um programa impossível de modificar.
Terceiro: o Android
O Android fornece serviços, processos, permissões, interfaces e mecanismos de segurança.
Aplicativos comuns devem operar dentro das permissões concedidas.
Mas componentes privilegiados, instalados pelo fabricante, podem ter capacidades superiores às de um aplicativo baixado pelo usuário.
E aqui começa nossa tragédia.
A porta clandestina
O relatório do Google descreve um componente identificado como x.cpe, também encontrado como com.oemservice.
Esse software era pré-instalado e executava com o identificador privilegiado android.uid.system.
Para um iniciante, isso significa que ele não estava simplesmente brincando na área comum dos aplicativos.
Ele operava com uma posição privilegiada dentro do ambiente Android.
O componente conseguia manter comunicação com a infraestrutura criminosa e facilitar a instalação de outros módulos.
Se determinada instalação fosse removida pelo usuário, mecanismos presentes no equipamento poderiam restaurá-la a partir da partição /oem/ após uma reinicialização.
Kaiji grita:
— Mas eu já apaguei o programa!
O operador do cassino sorri:
— Você apagou uma cópia. Nossa reserva continua guardada.
ZAWA... ZAWA...
É o conceito de persistência.
Uma ameaça persistente possui mecanismos para continuar funcionando ou retornar depois de tentativas superficiais de remoção.
Uma curiosidade importante
Nem todo malware persistente está no firmware.
Existem ameaças que utilizam tarefas agendadas, serviços, mecanismos de inicialização, scripts ou alterações em aplicativos.
A particularidade do XCPE era sua integração privilegiada ao software fornecido com o equipamento.
Isso tornava a simples restauração de fábrica insuficiente nos aparelhos comprometidos.
É como restaurar uma sala de computadores a partir de uma imagem de sistema que já contém o invasor.
A restauração funciona.
O problema é que restaura também a ameaça.
📡 Capítulo III — O servidor do cassino: HTTP, MQTT e o comando remoto
Agora chegamos à parte mais interessante da engenharia.
O malware precisava receber instruções.
Para isso, utilizava uma arquitetura de comando e controle, frequentemente abreviada como C2.
O funcionamento descrito pelo Google envolvia inicialmente solicitações HTTP para obtenção de parâmetros e depois comunicação persistente utilizando MQTT.
O que é HTTP?
HTTP é um protocolo utilizado na comunicação entre aplicações.
Navegadores o utilizam para solicitar páginas e recursos, embora sistemas modernos também utilizem HTTP em inúmeras integrações.
O malware podia empregar solicitações HTTP para obter configurações.
O que é MQTT?
MQTT significa Message Queuing Telemetry Transport.
Trata-se de um protocolo leve de comunicação baseado no modelo de publicação e assinatura.
Ele é muito comum em projetos legítimos de Internet das Coisas.
Imagine uma fábrica com centenas de sensores.
Cada sensor pode publicar informações sobre temperatura ou pressão.
Outros sistemas assinam determinados tópicos e recebem os dados relevantes.
Essa arquitetura é eficiente.
Mas uma tecnologia legítima pode ser utilizada de maneira maliciosa.
No caso XCPE, o MQTT permitia a distribuição de instruções para aparelhos comprometidos.
Por que isso é perigoso?
Porque o dispositivo deixa de executar apenas funções solicitadas por seu proprietário.
Ele passa a obedecer também a ordens de uma infraestrutura externa não autorizada.
O Google documentou capacidades como instalação silenciosa de aplicativos, execução de comandos, reconhecimento de rede, captura de telas e coleta de informações.
Não significa que todas essas operações tenham ocorrido em todos os aparelhos.
Significa que a infraestrutura possuía recursos capazes de realizar atividades desse tipo.
O falso aplicativo de sistema
Outra característica interessante foi a evolução do malware.
O Google identificou componentes que procuravam parecer aplicativos normais do Android, inclusive utilizando nomes semelhantes aos de serviços de sistema.
Isso nos apresenta um princípio essencial de segurança:
O nome de um programa não comprova sua legitimidade.
Um arquivo chamado SECURITY.EXE pode ser malicioso.
Um aplicativo chamado SYSTEM-UPDATE pode não ter relação alguma com o fabricante legítimo.
E uma biblioteca mainframe chamada PAYROLL.SECURE.LOAD não é necessariamente segura apenas porque seu nome contém a palavra SECURE.
A confiança exige procedência, integridade, autorização e verificação.
💰 Capítulo IV — O cassino invisível: como os criminosos ganhavam dinheiro
Em Kaiji, os participantes frequentemente descobrem que as regras favorecem os administradores.
No caso XCPE, a lógica comercial do crime apresentava uma característica semelhante.
Os operadores monetizavam equipamentos que não lhes pertenciam mais.
O consumidor havia comprado o produto.
Mas o acesso clandestino continuava rendendo dinheiro.
Primeira modalidade: proxies residenciais
Imagine que um criminoso queira acessar determinado serviço utilizando um endereço IP residencial.
Ele poderia tentar utilizar a conexão de uma vítima.
A TV Box comprometida passava a funcionar como intermediária de tráfego.
Assim, determinadas solicitações externas poderiam aparecer como originadas da residência do consumidor.
Isso não significa necessariamente que o criminoso tenha acesso completo a todos os computadores da casa.
Entretanto, utilizar a conexão de terceiros sem consentimento já representa um risco relevante.
Além disso, um dispositivo comprometido pode servir de ponto de partida para outras tentativas de exploração da rede local.
Segunda modalidade: fraude publicitária
A publicidade digital frequentemente remunera determinadas impressões, visualizações ou interações.
Criminosos podem tentar produzir eventos artificiais para gerar receitas.
Alguns módulos investigados pelo Google simulavam atividades publicitárias sem participação real de um usuário.
Imagine milhões de televisões produzindo silenciosamente eventos que deveriam representar pessoas assistindo a anúncios.
As empresas anunciantes podem acabar pagando por interações inexistentes.
O consumidor fornece o equipamento e a energia.
O sistema criminoso explora a capacidade computacional.
Terceira modalidade: distribuição de outros malwares
Uma vez instalada a porta clandestina, outros módulos podiam ser introduzidos.
É uma estratégia modular.
O operador principal fornece acesso.
Parceiros criminosos oferecem diferentes formas de exploração.
Essa organização lembra uma plataforma comercial legítima, mas com finalidade criminosa.
Existe infraestrutura, distribuição, controle de versões, comunicação, módulos especializados e gerenciamento remoto.
Uma comparação com COBOL
Imagine um sistema bancário desenvolvido em COBOL.
O programa de contas correntes possui regras, controles, arquivos e transações.
Agora imagine, hipoteticamente, que uma biblioteca privilegiada tenha sido alterada para executar uma operação clandestina sempre que determinada aplicação for iniciada.
O operador bancário pode executar os procedimentos corretamente.
O programa principal pode até parecer intacto.
Mas a cadeia de execução contém um componente comprometido.
A lição é clara.
Uma aplicação confiável não consegue compensar, sozinha, uma infraestrutura profundamente comprometida.
🏠 Capítulo V — O cidadão comum: o participante que nunca recebeu as regras
Voltemos ao apartamento de Kaiji.
Ele pensa que o maior problema será a conta de eletricidade.
Infelizmente, existem outros riscos.
Exposição de informações
O Google identificou capacidades de captura de telas, obtenção de informações sobre dispositivos e contas e execução de comandos.
Dependendo da atividade realmente executada e das informações presentes no aparelho, dados sensíveis poderiam ser expostos.
É importante não afirmar que todos os usuários tiveram senhas bancárias roubadas.
A investigação demonstrou capacidades e atividades maliciosas, mas isso não equivale a comprovar cada consequência em todas as vítimas.
Reputação do endereço IP
Quando um criminoso utiliza a conexão residencial de uma vítima, serviços externos podem associar atividades suspeitas ao endereço IP utilizado.
Isso pode resultar em bloqueios, verificações adicionais ou dificuldades de acesso.
O endereço IP, isoladamente, não identifica necessariamente a pessoa responsável por uma atividade.
Redes compartilhadas, tradução de endereços e outros fatores tornam a atribuição muito mais complexa.
Mesmo assim, a situação pode gerar transtornos consideráveis.
Riscos para a rede doméstica
Uma TV Box normalmente compartilha a rede com outros equipamentos.
Computadores, celulares, impressoras, câmeras e dispositivos inteligentes podem utilizar o mesmo roteador.
Um aparelho comprometido representa uma superfície adicional de ataque.
Ele não garante automaticamente acesso aos demais dispositivos.
Contudo, sua presença cria oportunidades para reconhecimento de rede e tentativas de exploração.
A ameaça silenciosa
Talvez o maior problema seja a ausência de sintomas.
Um aparelho infectado pode continuar reproduzindo vídeos normalmente.
Nem sempre há anúncios estranhos.
Nem sempre o equipamento fica lento.
Nem sempre aparecem mensagens de erro.
O usuário pode acreditar que está seguro simplesmente porque tudo funciona.
Mas funcionamento e segurança são propriedades diferentes.
🛡️ Capítulo VI — Como evitar cair na armadilha da TV Box
Kaiji finalmente compreende que precisa abandonar o jogo.
Mas qual seria o procedimento correto?
Passo 1 — Identifique o equipamento
Verifique a marca, modelo exato, versão de firmware e fabricante responsável.
Uma marca comercial não revela necessariamente todos os fornecedores envolvidos na fabricação.
Consulte comunicados oficiais, atualizações de segurança e alertas específicos sobre o modelo.
Passo 2 — Avalie a procedência
Prefira fabricantes reconhecidos, com histórico de atualizações e suporte técnico.
No Brasil, confira também as informações de homologação da Anatel quando aplicáveis.
A certificação é uma camada importante, mas não constitui garantia absoluta de ausência de ameaças.
O próprio caso XCPE revelou limitações em processos de verificação anteriores.
Passo 3 — Desconecte dispositivos suspeitos
Se houver confirmação de comprometimento ou suspeita fundamentada de que o modelo foi afetado, interrompa sua comunicação de rede.
Desconecte Wi-Fi e cabo Ethernet.
Não tente executar programas desconhecidos de suposta limpeza.
Uma ferramenta fornecida por fonte não confiável pode aumentar o problema.
Passo 4 — Não confie apenas na restauração de fábrica
Se o firmware original já estiver comprometido, restaurar as configurações poderá simplesmente reinstalar a ameaça.
Procure orientações verificáveis sobre atualizações limpas e oficiais.
Na ausência de solução confiável, a substituição do dispositivo pode ser a alternativa mais segura.
Passo 5 — Proteja os demais equipamentos
Atualize o roteador e os outros dispositivos.
Verifique as contas utilizadas no equipamento suspeito.
Se houver indícios de exposição de credenciais, altere as senhas a partir de um dispositivo confiável e habilite autenticação multifator.
Considere criar uma rede separada para dispositivos IoT.
Essa separação deve ser configurada corretamente, com regras que limitem a comunicação com a rede principal.
Uma rede de convidados mal configurada pode não fornecer o isolamento esperado.
Passo 6 — Observe o tráfego
Ferramentas de monitoramento de rede podem ajudar a identificar comunicações incomuns.
Entretanto, tráfego intenso ou conexões desconhecidas não comprovam isoladamente uma infecção.
A análise precisa considerar o comportamento normal do equipamento, os destinos, os horários e os indicadores documentados pelos pesquisadores.
🏛️ Capítulo VII — Kaiji visita um CPD: o que o mundo mainframe pode aprender?
Agora imaginemos que Kaiji abandona seu apartamento e visita um grande centro de processamento de dados.
À sua frente encontra um ambiente IBM Z executando z/OS.
Milhares de transações são processadas.
Programas COBOL acessam bases Db2 e arquivos VSAM.
Regiões CICS atendem aplicações corporativas.
Rotinas JCL controlam processamento batch.
O RACF participa das decisões de autorização e controle de acesso.
Kaiji contempla os equipamentos.
— Aqui deve ser impossível acontecer algo semelhante!
Infelizmente, nenhuma arquitetura é imune a comprometimentos.
O IBM Z possui mecanismos sofisticados de segurança, isolamento, proteção e auditoria.
Mas sua efetividade depende de configuração adequada, gestão de privilégios, controle dos fornecedores e disciplina operacional.
Vamos comparar as ameaças.
Firmware comprometido versus software privilegiado
O paralelo mais útil com XCPE não é afirmar que o z/OS funciona como Android.
São arquiteturas diferentes.
O ponto comum está na confiança concedida a componentes de alto privilégio.
No z/OS, determinados programas e bibliotecas podem ser autorizados a executar operações privilegiadas.
As bibliotecas APF são um exemplo relevante.
APF significa Authorized Program Facility.
É um mecanismo pelo qual o sistema identifica bibliotecas autorizadas, permitindo que programas que satisfaçam as condições necessárias operem com capacidades especiais.
Um programa não se torna automaticamente confiável apenas porque está numa biblioteca APF.
E colocar código inadequado numa cadeia de execução privilegiada pode introduzir riscos graves.
A grande lição da APF
Bibliotecas autorizadas exigem proteção rigorosa.
É necessário controlar quem pode atualizar seus membros, quais processos podem distribuir alterações e como a integridade dos componentes será verificada.
O princípio é semelhante ao aprendido com a TV Box:
Não basta confiar na aparência do componente.
É preciso controlar quem o produziu, quem o alterou e quem autorizou sua entrada em produção.
RACF: o segurança do cassino
O Resource Access Control Facility, RACF, fornece mecanismos de identificação, autenticação, autorização e auditoria.
Ele permite controlar o acesso a recursos e registrar eventos relevantes.
Mas considere uma situação hipotética.
Um usuário possui autorização excessiva para atualizar uma biblioteca crítica.
Esse usuário pode ser uma pessoa legítima, uma conta de serviço ou uma identidade comprometida.
Se as permissões forem amplas demais, a própria configuração de segurança pode facilitar a introdução de alterações indevidas.
Por isso, aplicar RACF não significa apenas criar perfis.
Significa desenhar uma política de acesso coerente.
Princípio do menor privilégio
Cada identidade deve possuir apenas as permissões necessárias para realizar seu trabalho.
Um programador que precisa consultar componentes de produção não deveria receber automaticamente autorização para alterá-los.
Uma conta de execução batch não precisa necessariamente possuir poderes administrativos.
Uma ferramenta de implantação não deve ter acesso irrestrito a todos os recursos do sistema.
A pergunta correta não é:
— Esse usuário é confiável?
A pergunta mais segura é:
— Quais operações essa identidade realmente precisa executar?
📚 Capítulo VIII — Laboratório COBOL: criando um detector didático de eventos suspeitos
Chegou a hora de colocar as mãos no código.
Nosso objetivo será construir um pequeno programa COBOL para analisar registros fictícios de eventos de segurança.
Ele não detectará o malware XCPE diretamente.
Também não substituirá RACF, SIEM, SMF ou ferramentas especializadas.
Será um exercício introdutório para compreender a lógica de classificação de eventos.
Cenário
Imagine que nosso sistema receba registros de auditoria já normalizados por uma ferramenta de coleta.
Cada registro contém um código de evento.
Vamos utilizar quatro classificações:
APF— alteração em componente associado a biblioteca autorizada.RAC— falha de autorização.JCL— alteração de um job considerado crítico.NET— comunicação de rede potencialmente suspeita.
Esses códigos são exclusivamente didáticos e não correspondem a uma codificação oficial de registros SMF.
O programa KAIJISEC
>>SOURCE FORMAT FREE
identification division.
program-id. KAIJISEC.
environment division.
input-output section.
file-control.
select audit-file
assign to "AUDIT.DAT"
organization is line sequential
file status is ws-file-status.
data division.
file section.
fd audit-file.
01 audit-record.
05 audit-type pic x(3).
05 audit-description pic x(60).
working-storage section.
01 ws-file-status pic xx.
01 ws-end pic 9 value 0.
01 ws-count pic 9(5) value 0.
01 ws-alerts pic 9(5) value 0.
procedure division.
main-process.
open input audit-file
if ws-file-status not = "00"
display "ERRO AO ABRIR ARQUIVO"
display "FILE STATUS: " ws-file-status
goback
end-if
perform until ws-end = 1
read audit-file
at end
move 1 to ws-end
not at end
add 1 to ws-count
perform check-event
end-read
end-perform
close audit-file
display "REGISTROS: " ws-count
display "ALERTAS: " ws-alerts
goback.
check-event.
evaluate audit-type
when "APF"
display "ALERTA APF: "
audit-description
add 1 to ws-alerts
when "RAC"
display "ALERTA RACF: "
audit-description
add 1 to ws-alerts
when "JCL"
display "REVISAR JCL: "
audit-description
add 1 to ws-alerts
when "NET"
display "REVISAR REDE: "
audit-description
add 1 to ws-alerts
when other
continue
end-evaluate.Explicação para o iniciante
O programa começa com IDENTIFICATION DIVISION, onde declaramos sua identificação.
Em ENVIRONMENT DIVISION, definimos o arquivo de entrada.
A instrução SELECT estabelece a associação lógica entre o arquivo COBOL e o recurso externo.
A variável ws-file-status permite verificar se a operação de abertura foi bem-sucedida.
A estrutura PERFORM UNTIL executa um laço até atingir o fim do arquivo.
A instrução READ lê um registro de cada vez.
Em seguida, EVALUATE examina o tipo de evento e seleciona uma ação.
Esse comando lembra a estrutura switch de outras linguagens.
Quando ocorre uma classificação prevista, o programa apresenta uma mensagem e incrementa o contador.
Arquivo de teste
Crie um arquivo de texto contendo os registros abaixo, em que os três primeiros caracteres representam o código.
APFALTERACAO NA BIBLIOTECA AUTORIZADA
RACACESSO NEGADO A RECURSO CRITICO
JCLMODIFICACAO DE JOB FINANCEIRO
NETCONEXAO EXTERNA NAO RECONHECIDA
INFEXECUCAO ROTINEIRA CONCLUIDANosso programa deverá identificar quatro eventos para revisão.
O registro INF será ignorado pela regra de classificação atual.
Isso não significa que seja necessariamente seguro; significa apenas que nenhuma regra foi criada para esse código.
Uma limitação importante
O programa considera qualquer ocorrência de APF, RAC, JCL ou NET como um alerta.
Num ambiente real, essa estratégia produziria muitos falsos positivos.
Alterações autorizadas em bibliotecas APF podem fazer parte da manutenção.
Falhas RACF podem decorrer de erros operacionais legítimos.
Jobs JCL são modificados durante mudanças aprovadas.
Conexões externas podem ser completamente normais.
Portanto, um sistema de monitoramento profissional precisa incorporar contexto.
O evento ocorreu durante uma janela autorizada?
Quem solicitou a alteração?
Existe uma mudança aprovada?
O destino de rede está permitido?
A operação corresponde ao comportamento histórico?
Essas informações são essenciais para diferenciar um evento suspeito de uma atividade legítima.
🧪 Capítulo IX — JCL: executando nosso laboratório em ambiente z/OS
No mundo mainframe, COBOL e JCL frequentemente trabalham juntos.
COBOL implementa a lógica da aplicação.
JCL descreve como determinadas tarefas batch serão executadas.
Em nosso exemplo, consideraremos que o programa KAIJISEC já foi compilado e ligado, estando disponível numa biblioteca de carga apropriada.
O JCL abaixo é ilustrativo e deve ser adaptado aos padrões e permissões do ambiente.
//KAIJISEC JOB (ACCT),'AUDIT LAB',
// CLASS=A,MSGCLASS=X,
// NOTIFY=&SYSUID
//*
//RUN EXEC PGM=KAIJISEC
//STEPLIB DD DISP=SHR,
// DSN=LAB.COBOL.LOAD
//SYSOUT DD SYSOUT=*
//AUDITDD DD DISP=SHR,
// DSN=LAB.SECURITY.INPUTObserve um detalhe fundamental.
Nosso programa COBOL foi escrito com ASSIGN TO "AUDIT.DAT" e organização LINE SEQUENTIAL.
Para executar a mesma lógica em z/OS tradicional, precisamos adaptar a associação do arquivo ao DDNAME e utilizar um formato de registro compatível com o compilador, o runtime e o dataset.
Uma versão propriamente mainframe poderia declarar:
select audit-file
assign to AUDITDD
organization is sequential
file status is ws-file-status.Nesse caso, a definição do arquivo e sua estrutura física devem ser ajustadas conjuntamente.
O dataset deve conter registros com o layout esperado pelo programa.
Em uma implementação simples, poderíamos utilizar registros de comprimento fixo e preencher os campos de acordo com o FD.
A solução inicial com LINE SEQUENTIAL é particularmente conveniente para testes locais com compiladores que suportam esse formato.
Por que essa distinção importa?
Porque COBOL não funciona isoladamente do ambiente.
Uma aplicação que executa num computador pessoal pode precisar de adaptações para utilizar datasets MVS.
O compilador, o runtime, a organização dos arquivos e os recursos do sistema operacional influenciam a solução.
Essa também é uma lição de segurança.
Conhecer a lógica do programa não basta; precisamos conhecer o ambiente no qual ele executa.
🔐 Capítulo X — RACF, APF, SMF e a defesa em profundidade
Vamos aprimorar nosso laboratório.
Em vez de depender exclusivamente de registros fictícios, um sistema corporativo pode utilizar informações de auditoria provenientes de mecanismos legítimos do z/OS.
SMF: a memória operacional do sistema
SMF significa System Management Facilities.
É uma infraestrutura de coleta e registro de eventos e métricas no z/OS.
Determinados tipos de registros SMF documentam informações sobre execução, utilização de recursos, operações do sistema e eventos relacionados à segurança.
Registros do tipo 80, por exemplo, estão associados à auditoria de eventos RACF.
Mas não devemos imaginar que todo evento SMF possa ser lido diretamente como uma linha de texto.
Muitos registros possuem estruturas binárias complexas, layouts específicos e variações conforme o tipo e subtipo.
Um programa COBOL profissional precisa conhecer essas estruturas.
A arquitetura recomendada
Em um projeto didático de monitoramento, poderíamos desenvolver a seguinte sequência:
Coletar registros SMF por meios autorizados.
Extrair os tipos de evento necessários.
Interpretar os layouts utilizando ferramentas e documentação apropriadas.
Normalizar os eventos para um arquivo ou fluxo de dados.
Executar regras de classificação.
Correlacionar eventos com usuários, horários e mudanças aprovadas.
Gerar relatórios e alertas para revisão humana.
A aplicação COBOL poderia participar da etapa de classificação.
Ferramentas especializadas poderiam realizar coleta, correlação e análise mais sofisticada.
O que monitorar?
Em um ambiente corporativo, merecem atenção especial:
Bibliotecas privilegiadas: mudanças em bibliotecas APF, componentes de inicialização e bibliotecas críticas.
Identidades: criação de usuários, alterações de permissões, elevações de privilégio e uso de contas de serviço.
Execução batch: alterações inesperadas em jobs, procedimentos catalogados e parâmetros críticos.
Comunicação externa: conexões não previstas, mudanças em destinos permitidos e fluxos de dados incomuns.
Integridade de software: divergências entre componentes implantados e versões aprovadas.
Automação: alterações em pipelines, scripts REXX, configurações e ferramentas com capacidade de implantação.
A importância da correlação
Um único acesso negado pelo RACF pode ser apenas um erro.
Entretanto, imagine a seguinte sequência hipotética:
Às 02h10 ocorre uma tentativa de acesso a uma biblioteca crítica.
Às 02h12 uma identidade recebe uma autorização adicional.
Às 02h14 um membro de biblioteca é alterado.
Às 02h17 um job inesperado é executado.
Às 02h20 surge uma comunicação externa desconhecida.
Isoladamente, cada evento exige interpretação.
Em conjunto, podem justificar uma investigação urgente.
Essa é uma das diferenças entre registrar dados e produzir inteligência de segurança.
🕵️ Capítulo XI — O malware ensina uma lição sobre confiança e fornecedores
O caso Videostrong demonstra que o risco não termina no código escrito pelos profissionais de uma organização.
Também precisamos considerar componentes produzidos por terceiros.
No mundo mainframe, essa preocupação se estende a:
Bibliotecas comerciais, ferramentas de monitoração, agentes de automação, produtos de segurança, componentes de conectividade, aplicações adquiridas, pacotes de atualização e soluções integradas a pipelines DevOps.
Isso não significa que esses produtos sejam suspeitos por natureza.
Significa que precisam participar de um processo adequado de avaliação e controle.
SBOM: o inventário dos componentes
SBOM significa Software Bill of Materials.
É uma relação estruturada dos componentes que integram determinado software.
Sua finalidade é melhorar a visibilidade sobre dependências e tecnologias utilizadas.
Uma organização que conhece seus componentes consegue investigar mais rapidamente a exposição a vulnerabilidades conhecidas.
Porém, uma SBOM não comprova que o software seja seguro.
Ela é um instrumento de transparência, não uma garantia absoluta.
Assinaturas digitais e integridade
Assinaturas digitais podem ajudar a verificar autoria e integridade de artefatos, desde que as chaves e os processos de confiança estejam adequadamente protegidos.
Hashes também são úteis para detectar alterações.
Mas atenção: um hash apenas confirma a correspondência entre conteúdos.
Se um arquivo malicioso for considerado a versão de referência, calcular seu hash não o tornará confiável.
É fundamental que a referência seja obtida por um processo independente e legítimo.
O paralelo com o firmware
O problema XCPE revelou que mecanismos de certificação podem ser contornados quando o processo de avaliação não examina suficientemente o comportamento do equipamento após sua inicialização.
A lição para a engenharia de software é poderosa.
Não devemos avaliar somente a aparência inicial de um componente.
Precisamos compreender seu comportamento em operação, suas dependências e a possibilidade de receber instruções externas posteriormente.
⚙️ Capítulo XII — Dez medidas para fortalecer um ambiente IBM Z
Kaiji finalmente chega à sala onde a equipe de segurança acompanha o ambiente corporativo.
Em vez de apostar, ele deseja estabelecer regras.
E a primeira é simples:
A banca não pode possuir privilégios ilimitados.
1. Proteger as bibliotecas APF
Revisar regularmente as bibliotecas autorizadas e restringir rigorosamente as permissões de atualização.
Alterações devem passar por processos formais de mudança.
2. Revisar autorizações RACF
Identificar permissões excessivas, contas antigas, identidades de serviço e acessos administrativos que não sejam mais necessários.
Aplicar o menor privilégio.
3. Controlar programas privilegiados
Examinar programas com capacidades especiais e validar sua origem.
A execução privilegiada precisa ser justificada, controlada e auditável.
4. Proteger a cadeia de implantação
Aplicar controles nos repositórios, pipelines, ferramentas de build e processos de liberação.
Uma alteração maliciosa pode entrar antes de o programa chegar à produção.
5. Adotar segregação de funções
Evitar que a mesma pessoa ou identidade possa desenvolver, aprovar e implantar alterações críticas sem controles independentes.
6. Monitorar SMF e eventos RACF
Selecionar eventos relevantes, manter registros protegidos e estabelecer regras de investigação.
O monitoramento precisa ter responsáveis e procedimentos de resposta.
7. Validar componentes de terceiros
Verificar procedência, versões, assinaturas quando disponíveis e recomendações de segurança dos fornecedores.
Manter inventário atualizado.
8. Proteger os canais de comunicação
Controlar conexões externas, autenticação de serviços, certificados e integrações.
Um programa COBOL pode ser seguro em sua lógica e ainda assim depender de uma integração mal protegida.
9. Testar recuperação e integridade
Backups são essenciais, mas precisam ser verificados.
Uma recuperação baseada em componentes comprometidos poderá restaurar o problema.
Os procedimentos devem prever fontes confiáveis de software e configurações.
10. Exercitar a resposta a incidentes
Simular alterações indevidas, credenciais comprometidas e tentativas de acesso a bibliotecas críticas.
Verificar se a equipe consegue identificar, conter, investigar e recuperar o ambiente.
A existência de uma ferramenta não garante que ela esteja corretamente configurada ou que a equipe saiba utilizá-la numa emergência.
🎰 Capítulo XIII — Um laboratório de investigação: cinco perguntas antes de liberar um programa COBOL
Imagine que uma equipe está prestes a colocar um novo programa em produção.
O nome do programa é FINPAG01.
Ele processa pagamentos.
Kaiji recebe a tarefa de revisar sua segurança.
Não basta verificar se o programa compila.
Ele precisa responder a cinco perguntas.
Primeira pergunta: quem escreveu o código?
A versão que será executada corresponde a um commit e a uma mudança formalmente aprovados?
Segunda pergunta: quem compilou?
O pipeline de construção utiliza ferramentas confiáveis e parâmetros controlados?
Terceira pergunta: onde o programa será instalado?
A biblioteca de destino possui proteções adequadas?
Se estiver associada a execução privilegiada, a justificativa foi revisada?
Quarta pergunta: com quais permissões executará?
A identidade utilizada possui somente os acessos necessários?
Quinta pergunta: como detectaremos uma alteração indevida?
Existem registros, verificações de integridade e responsáveis pela investigação?
Essas perguntas representam uma forma prática de aplicar a lição do XCPE ao cotidiano de desenvolvimento.
Um exercício para o estudante
Crie uma pequena aplicação COBOL chamada VALIDA01.
Ela deverá receber um arquivo de inventário contendo:
Nome de um programa.
Identificação da versão aprovada.
Identificação da versão implantada.
Indicador de aprovação da mudança.
O programa deve comparar os campos.
Se as versões forem diferentes, deverá produzir um alerta.
Se a alteração não possuir aprovação, deverá produzir outro alerta.
Se ambos estiverem corretos, deverá indicar que o registro passou pelas verificações.
Depois, amplie o exercício para gerar um relatório consolidado.
Esse laboratório não comprova a integridade criptográfica dos programas.
Ele ensina a lógica de comparação entre o estado esperado e o estado observado.
Em uma solução real, os identificadores devem ser derivados de evidências confiáveis, como manifestos assinados, inventários controlados e processos seguros de implantação.
🧩 Capítulo XIV — Curiosidades: quando a ficção encontra a engenharia
Curiosidade 1 — O malware pode se comportar como um produto comercial
O XCPE utilizava uma arquitetura modular, permitindo diferentes formas de monetização.
Essa característica lembra plataformas que oferecem serviços por meio de componentes independentes.
A diferença está na ausência de consentimento e na finalidade maliciosa.
Curiosidade 2 — MQTT não é um protocolo criminoso
O mesmo protocolo empregado numa operação maliciosa pode ser utilizado legitimamente para telemetria industrial e automação.
Bloquear uma tecnologia inteira simplesmente porque criminosos a utilizaram pode causar impactos desnecessários.
A defesa deve considerar contexto, autorização e comportamento.
Curiosidade 3 — Um sistema pode ser comprometido sem apresentar falhas visíveis
A televisão pode continuar funcionando.
Uma aplicação financeira também pode continuar processando transações enquanto alguma atividade indevida ocorre em outro componente.
Por isso, testes funcionais não substituem verificações de segurança.
Curiosidade 4 — Os mainframes também dependem de cadeias de fornecimento
Apesar das diferenças arquiteturais, ambientes IBM Z utilizam ferramentas, componentes de software, bibliotecas, atualizações e integrações de múltiplas origens.
A confiança precisa acompanhar toda essa cadeia.
Curiosidade 5 — Segurança é também um problema econômico
No caso XCPE, o incentivo financeiro era parte fundamental da operação.
O aparelho vendido continuava gerando possibilidades de receita para os operadores.
Isso explica por que algumas campanhas criminosas investem tanto em persistência, automação e evasão.
Curiosidade 6 — A quantidade de dispositivos não mede diretamente o prejuízo
Mais de 1,3 milhão de aparelhos comprometidos constitui uma escala significativa.
Mas não podemos calcular o prejuízo financeiro total apenas multiplicando o número de equipamentos por um valor arbitrário.
É necessário conhecer receitas criminosas, perdas das vítimas, impactos operacionais e outras variáveis.
Curiosidade 7 — Kaiji representa o usuário sem informações suficientes
Uma característica recorrente de Kaiji é a desigualdade entre participantes e organizadores dos jogos.
Os administradores conhecem mecanismos ocultos.
Os participantes precisam descobrir as regras enquanto enfrentam consequências.
Essa assimetria de informação é uma metáfora particularmente útil para o mercado de dispositivos conectados.
Curiosidade 8 — O maior problema pode estar no que não conseguimos observar
Uma organização pode ter excelentes regras para seus programas COBOL e, mesmo assim, desconhecer o comportamento de uma ferramenta privilegiada instalada por terceiros.
Quanto maior a capacidade de um componente, maior deve ser a exigência de transparência, controle e monitoramento.
🧠 Capítulo XV — A grande lição de Kaiji: nunca entregue todas as fichas a um único participante
Depois de atravessar tantos jogos perigosos, Kaiji compreende uma regra essencial.
Não se deve participar de uma competição na qual o adversário controla secretamente todas as condições.
Em segurança informática, precisamos transformar essa ideia em arquitetura.
Nenhuma identidade deve ter poderes ilimitados sem justificativa.
Nenhum componente deve ser considerado seguro exclusivamente por sua origem declarada.
Nenhum fornecedor deve receber confiança irrestrita.
Nenhuma atualização deve ser liberada sem controles adequados.
Nenhum mecanismo de auditoria deve depender exclusivamente do componente que está sendo auditado.
É aqui que entra o conceito de defesa em profundidade.
Em vez de confiar numa única barreira, a organização distribui controles por diferentes camadas.
No mainframe, isso pode envolver RACF, proteção de datasets, integridade de software, controles de implantação, segregação de funções, monitoramento SMF e procedimentos de resposta.
Cada camada possui responsabilidades diferentes.
E nenhuma deve ser tratada como solução mágica.
Zero Trust não significa desconfiar de todas as pessoas
Significa evitar que a localização de um componente ou a identidade declarada de um serviço seja suficiente para conceder acesso irrestrito.
As permissões devem considerar identidade, contexto, necessidade e controles apropriados.
Para o programador COBOL, isso se traduz em práticas concretas.
Validar entradas.
Tratar erros.
Evitar informações sensíveis desnecessárias em logs.
Não colocar credenciais diretamente no código.
Utilizar identidades de execução com permissões mínimas.
Proteger bibliotecas e arquivos.
Testar comportamentos inesperados.
E compreender que segurança da aplicação e segurança da plataforma são responsabilidades complementares.
🎬 Epílogo — A última aposta de Kaiji: o verdadeiro patrimônio é a confiança
A madrugada termina.
Kaiji observa a pequena TV Box agora desconectada da internet.
O aparelho continua sobre a mesa.
Ele pagou por aquele equipamento.
Esperava receber entretenimento.
Mas descobriu que outra pessoa havia transformado sua compra numa fonte clandestina de receitas.
— Então o problema não era somente o vírus...
Exatamente.
Era a confiança.
Confiança no fabricante.
Confiança no sistema operacional.
Confiança no firmware.
Confiança nos processos de certificação.
Confiança na cadeia que leva um produto da fábrica à residência.
E confiança nos mecanismos que deveriam impedir alterações clandestinas.
O mesmo princípio vale para o universo IBM Z.
Um programa COBOL pode conter décadas de regras de negócio cuidadosamente aperfeiçoadas.
Uma transação CICS pode executar corretamente milhões de vezes.
Uma base Db2 pode manter informações fundamentais para uma instituição.
Um conjunto de jobs JCL pode sustentar processos financeiros inteiros.
Mas todos esses componentes dependem de uma infraestrutura cujas permissões, versões, bibliotecas e integrações precisam ser continuamente protegidas.
O caso XCPE demonstra que a origem de uma ameaça pode estar antes mesmo da primeira execução do equipamento pelo comprador.
É uma advertência para a indústria de tecnologia.
E também para quem trabalha com sistemas corporativos.
Não devemos perguntar apenas se nosso programa está seguro. Precisamos perguntar se podemos confiar na cadeia inteira que permite a ele funcionar.
Kaiji ergue a xícara de café.
— Desta vez, eu quero conhecer as regras antes de apostar!
ZAWA... ZAWA... ZAWA...
E, em algum lugar de um centro de processamento de dados, um programador COBOL examina cuidadosamente a próxima alteração de uma biblioteca autorizada.
Porque a segurança não começa quando o ataque acontece.
Ela começa quando decidimos quais componentes merecem nossa confiança.
No cassino digital, a banca só ganha sempre quando ninguém fiscaliza as regras.
📖 Fontes e referências técnicas
Google Threat Intelligence Group — Shutting the Door on the XCPE Botnet, 2 de novembro de 2026. Investigação primária da infraestrutura XCPE, arquitetura do malware, persistência, monetização e medidas de interrupção.
https://cloud.google.com/blog/topics/threat-intelligence/shutting-the-door-on-the-xcpe-botnetFast Company Brasil — Google bane fabricante de TV Box após descobrir malware em mais de 1,3 milhão de aparelhos, 5 de novembro de 2026. Cobertura do incidente e dados relativos ao Brasil.
https://fastcompanybrasil.com/tech/google-bane-fabricante-tv-box-apos-descobrir-malware-13-milhao-aparelhos/Malwarebytes — A hidden backdoor put 1.3 million TV boxes to work for criminals, 3 de novembro de 2026. Análise complementar dos riscos para consumidores e persistência no firmware.
https://www.malwarebytes.com/blog/mobile/2026/11/a-hidden-backdoor-put-1-3-million-tv-boxes-to-work-for-criminalsIBM Documentation — Documentação de z/OS, RACF, APF, SMF, JCL e Enterprise COBOL. Referência para implementação e verificação de procedimentos específicos de cada versão e ambiente.
https://www.ibm.com/docs/en/zosKaiji — Gyakkyō Burai Kaiji: Ultimate Survivor. Obra de ficção utilizada como recurso narrativo e educativo. As falas e situações envolvendo o incidente XCPE foram criadas exclusivamente para este artigo e não pertencem à história original do anime.
Bellacosa Mainframe — Onde a arqueologia da computação encontra os desafios da segurança digital. Porque compreender o passado é uma das melhores maneiras de proteger o futuro.
☕ Até o próximo café no Bellacosa Mainframe!
Sem comentários:
Enviar um comentário