 |
| Bellacosa Mainframe e o OSINT |
☕ Um Café no Bellacosa Mainframe
🎭 FRANK ABAGNALE JR. E AS SETE PISTAS QUE LEVAVAM AO MAINFRAME
OSINT, usernames, e-mails, documentos, metadados, Certificate Transparency, DNS, redes sociais, GitHub, RACF, SMF, zERT, CICS, MQ, z/OS Connect — e o dia em que um programador COBOL descobriu que ninguém precisava começar a investigação pelo mainframe.
Sob a tutela narrativa de Frank Abagnale Jr.: não confie apenas na aparência de uma informação. Observe, correlacione, confirme — e nunca confunda uma pista com uma prova.
🎬 PRÓLOGO — O HOMEM QUE NÃO PRECISAVA ENTRAR NO BANCO
O jovem programador COBOL olhou para a tela verde.
Na frente dele havia uma aplicação CICS perfeitamente normal.
TRANSACTION: PAY1
USERID: COBDEV01
PROGRAM: PAYM001
STATUS: READY
Ele tomou um gole de café e disse:
— Nosso mainframe está seguro. Para chegar aqui alguém precisaria conhecer o sistema.
Frank Abagnale Jr. colocou uma pasta sobre a mesa.
— Exatamente.
— Então estamos seguros.
— Não. Eu disse que alguém precisaria conhecer o sistema. Não disse que precisaria entrar nele para conhecê-lo.
Dentro da pasta havia sete folhas.
Na primeira:
LinkedIn
Na segunda:
GitHub
Na terceira:
PDF
Na quarta:
DNS
Na quinta:
TLS Certificate
Na sexta:
Job Posting
E na última:
CICS
O programador franziu a testa.
Frank sorriu.
— Você está olhando para a última página da investigação. Vamos começar pela primeira.
E é justamente aqui que começa nossa história.
🕵️ CAPÍTULO 1 — OSINT NÃO É GOOGLE COM ESTEROIDES
OSINT significa Open Source Intelligence.
A tradução mais comum é Inteligência de Fontes Abertas.
Mas existe uma diferença enorme entre informação aberta e inteligência.
Imagine encontrar na Internet:
COBOL
CICS
IBM MQ
joao.silva
empresa.com
Db2
GitHub
z/OS
Isso é informação.
Agora descobrimos que:
João Silva
↓
trabalha na Empresa X
↓
publicou material sobre COBOL
↓
participou de projeto CICS
↓
empresa procura profissionais de MQ
↓
documentação pública menciona APIs
↓
outro documento menciona z/OS Connect
Agora temos relações.
Quando essas relações são verificadas e começam a revelar uma arquitetura coerente, estamos produzindo inteligência.
A fórmula é:
DADO
↓
CONTEXTO
↓
CORRELAÇÃO
↓
VALIDAÇÃO
↓
INTELIGÊNCIA
Esse conceito é fundamental.
OSINT não deveria significar:
“Achei alguma coisa na Internet.”
Deveria significar:
“Encontrei informações públicas, estabeleci relações entre elas, confrontei fontes independentes e produzi uma conclusão com determinado nível de confiança.”
Para quem conhece mainframe, existe uma analogia perfeita.
Um único registro SMF pode contar uma pequena história.
Milhares de registros corretamente correlacionados podem contar a história do sistema.
🧩 CAPÍTULO 2 — A PRIMEIRA PISTA: UM USERNAME
Nos slides que deram origem à nossa investigação havia um exemplo simples:
@redhawkme
A ideia era realizar username pivoting.
Você encontra um identificador em um lugar e procura ocorrências públicas relacionadas.
No mundo mainframe precisamos acrescentar uma gigantesca placa de advertência:
USERNAME ≠ IDENTIDADE
E mais importante:
USERNAME INTERNET ≠ RACF USERID
Imagine:
GitHub: jsilva
Fórum: jsilva
Blog: jsilva
Podemos levantar a hipótese de que sejam a mesma pessoa.
Mas ainda não temos prova.
Muito menos podemos afirmar:
RACF USERID = JSILVA
Esse é um dos erros clássicos de investigação: transformar coincidência em certeza.
Frank provavelmente perguntaria:
— O que você sabe?
“Existe uma conta chamada jsilva.”
— O que você acha?
“Talvez pertença a João Silva.”
— O que consegue provar?
E de repente temos três categorias completamente diferentes.
FATO
Existe publicamente o identificador jsilva.
HIPÓTESE
Talvez pertença ao profissional João Silva.
CONCLUSÃO VALIDADA
Só poderá existir depois de evidências suficientes.
Esse pequeno hábito muda completamente uma investigação.
📧 CAPÍTULO 3 — O E-MAIL QUE VIROU UM MAPA
Agora encontramos publicamente:
joao.silva@empresa.example
Parece pouca coisa.
Mas um endereço pode indicar uma convenção:
nome.sobrenome@empresa
Se encontramos vários exemplos independentes:
maria.souza@
carlos.lima@
ana.pereira@
podemos considerar que há evidência de um padrão de e-mail.
Mas novamente:
isso não revela automaticamente USERIDs internos.
O perigo começa quando pequenas informações são combinadas.
Um e-mail pode aparecer associado a:
documentos públicos, palestras, commits públicos, artigos técnicos, fóruns profissionais ou projetos open source.
Surge o conceito de pivot.
E-MAIL
|
+--> documento
|
+--> perfil profissional
|
+--> repositório
|
+--> conferência
Cada descoberta fornece novas possibilidades de investigação.
É uma árvore.
Curiosamente, o programador IMS talvez esteja sorrindo agora.
Porque OSINT começa a parecer um banco hierárquico.
📄 CAPÍTULO 4 — O PDF QUE FALAVA DEMAIS
Aqui encontramos uma das áreas mais fascinantes.
Documentos podem carregar informações que não fazem parte do texto principal.
São os metadados.
Um PDF poderia conter algo semelhante a:
Author: João Silva
Company: Empresa X
Created: 2026-04-12
Application: PowerPoint
Nada disso necessariamente representa um problema.
Mas agora imagine uma apresentação técnica contendo um screenshot.
No canto da imagem aparece:
SDSF
Em outro ponto:
CICSPRD
Mais abaixo:
DB2P
E talvez:
CORP.PROD.LOADLIB
Acabamos de aprender muito mais do que aparentemente estava sendo apresentado.
É aquilo que podemos chamar de architectural leakage — vazamento de contexto arquitetural.
Não precisamos encontrar:
PASSWORD=123456
para que um repositório ou documento revele informação interessante.
Um simples:
//STEPLIB DD DSN=BANK.PROD.PAYMENT.LOADLIB,DISP=SHR
pode revelar convenções.
Temos potencialmente:
BANK
PROD
PAYMENT
LOADLIB
Separadamente parecem palavras banais.
Juntas começam a descrever uma organização.
🧱 CAPÍTULO 5 — GITHUB: O MUSEU DAS PISTAS ESQUECIDAS
Imagine um desenvolvedor aprendendo COBOL e publicando:
IDENTIFICATION DIVISION.
PROGRAM-ID. PAYM001.
Nenhum problema.
Agora imagine que seja código corporativo publicado acidentalmente.
Encontramos:
EXEC CICS LINK
PROGRAM('AUTH001')
END-EXEC.
Agora conhecemos outro identificador.
Depois encontramos:
//PAYMENT EXEC PGM=PAYM001
E:
MQ Queue:
PAYMENT.AUTH.REQUEST
Veja o que aconteceu.
PAYM001
|
+--> AUTH001
|
+--> CICS
|
+--> PAYMENT.AUTH.REQUEST
|
+--> MQ
Já temos um pequeno grafo arquitetural.
Por isso segurança de repositório não deveria procurar somente senhas, tokens e API keys.
Também deveria observar exposição desnecessária de:
nomes internos, endpoints, datasets, filas MQ, programas, transações, regiões CICS, identificadores Db2 e convenções ambientais.
🔐 CAPÍTULO 6 — CERTIFICATE TRANSPARENCY: O CARTÓRIO DA INTERNET
Certificados TLS precisam identificar os serviços para os quais são válidos.
Existem mecanismos públicos de Certificate Transparency que permitem acompanhar certificados emitidos.
Um certificado poderia indicar nomes como:
www.empresa.example
api.empresa.example
developer.empresa.example
vpn.empresa.example
Isso pode ajudar a reconstruir a superfície pública de uma organização sem realizar varredura ativa.
Agora imagine encontrar algo sugestivo como:
api.empresa.example
integration.empresa.example
Isso não prova absolutamente nada sobre IBM Z.
Mas outra fonte pública menciona:
z/OS Connect
Uma vaga menciona:
CICS + COBOL + REST
E uma apresentação corporativa fala:
API modernization
Temos então uma hipótese arquitetural:
Internet
|
v
API Gateway
|
v
Integration
|
v
z/OS Connect
|
v
CICS
|
v
COBOL
Repare:
hipótese.
Não prova.
Essa palavra precisa acompanhar todo bom investigador.
🌐 CAPÍTULO 7 — “MAS O MAINFRAME NÃO ESTÁ NA INTERNET!”
Eis uma frase que Frank provavelmente adoraria ouvir.
Não porque esteja necessariamente errada.
Mas porque contém uma suposição perigosa.
O IBM Z pode realmente estar várias camadas distante da Internet.
Só que a arquitetura moderna pode ser:
INTERNET
|
v
WAF
|
v
API GATEWAY
|
v
OPENSHIFT
|
v
INTEGRATION
|
+----------+
| |
v v
MQ z/OS Connect
| |
+-----+----+
|
v
IBM Z
|
+-------+-------+
| | |
CICS IMS USS
| | |
+-------+-------+
|
COBOL / PL/I
|
+----+----+
| |
Db2 VSAM
O atacante não precisa necessariamente enxergar uma tela 3270.
O cliente legítimo moderno também não enxerga.
Ele chama:
POST /payment
e talvez, muitas camadas depois, um programa COBOL processe a transação.
Portanto, a pergunta de segurança madura não é:
“Meu mainframe está na Internet?”
A pergunta é:
“Quais cadeias de confiança podem chegar aos meus serviços e dados?”
Essa diferença é enorme.
🏰 CAPÍTULO 8 — RACF: O GUARDA DA FORTALEZA
Finalmente chegamos ao RACF.
O Resource Access Control Facility está no centro da segurança de muitos ambientes z/OS.
Simplificando bastante:
QUEM É VOCÊ?
↓
AUTENTICAÇÃO
O QUE VOCÊ PODE USAR?
↓
AUTORIZAÇÃO
O QUE VOCÊ FEZ?
↓
AUDITORIA
Então suponha que OSINT descubra:
PAYM001
Isso não significa:
EXECUTAR PAYM001
Descobrir:
PROD.PAYMENT.LOADLIB
não significa:
READ
UPDATE
ALTER
Descobrir um possível USERID não significa possuir autenticação.
Essa separação precisa ficar cristalina:
CONHECIMENTO
≠
AUTORIZAÇÃO
É aqui que a defesa em profundidade começa a mostrar seu valor.
📜 CAPÍTULO 9 — SMF: O DETETIVE QUE JÁ MORAVA NO MAINFRAME
O System Management Facilities é uma das grandes fontes de telemetria do z/OS.
Quando configurado apropriadamente, o ambiente pode registrar enorme quantidade de acontecimentos operacionais e de segurança.
Podemos pensar:
OSINT
|
| olha de fora para dentro
v
----------------------------
^
| olha de dentro para os eventos
|
SMF
Isso cria uma ideia muito interessante:
External Intelligence
O que alguém pode descobrir publicamente?
Internal Telemetry
O que realmente aconteceu?
Junte os dois e temos uma visão muito mais rica.
OSINT
+
RACF
+
SMF
+
NETWORK TELEMETRY
+
SIEM
=
CONTEXT
Não é uma equação matemática.
Mas é uma excelente filosofia para SOC.
📡 CAPÍTULO 10 — zERT E AS CONEXÕES QUE CONTAM HISTÓRIAS
O z/OS também possui tecnologias para fornecer visibilidade sobre características de proteção das conexões, como o z/OS Encryption Readiness Technology — zERT.
Agora nossa investigação ganha outra dimensão.
Externamente podemos acreditar que:
API
↓
Gateway
↓
Mainframe
Internamente queremos descobrir:
Quem comunicou?
Como comunicou?
Que proteção existia?
Qual fluxo realmente ocorreu?
Essa diferença é fundamental.
OSINT reconstrói aquilo que parece existir.
Telemetria interna ajuda a demonstrar aquilo que realmente aconteceu.
🕸️ CAPÍTULO 11 — CONNECTION MAPPING: TRANSFORME PISTAS EM GRAFO
Agora chegamos à parte favorita de Frank.
Conexões.
Pare de pensar numa lista:
João
COBOL
MQ
CICS
GitHub
Empresa
API
Pense em relações:
EMPRESA
|
+-------------+-------------+
| | |
PEOPLE SYSTEMS PARTNERS
| | |
GitHub API VPN
| | |
COBOL Gateway MQ
\ | /
+------------+-----------+
|
IBM Z
|
+---------+---------+
| | |
CICS IMS MQ
|
COBOL
|
+----+----+
| |
Db2 VSAM
Agora estamos pensando como investigadores.
Cada nó pode possuir:
SOURCE
DATE
CONFIDENCE
STATUS
RELATIONSHIP
E cada conclusão pode receber uma classificação:
CONFIRMED
PROBABLE
POSSIBLE
UNVERIFIED
Isso reduz enormemente o risco de transformar imaginação em “inteligência”.
📱 CAPÍTULO 12 — LINKEDIN E AS VAGAS QUE DESENHAM DATACENTERS
Uma organização publica uma vaga:
Mainframe Developer — COBOL, CICS, Db2, MQ, z/OS Connect, Git, Jenkins.
Ela acabou de fornecer uma boa quantidade de contexto tecnológico.
Isso não significa que revelou uma vulnerabilidade.
Essa distinção é essencial:
TECNOLOGIA CONHECIDA
≠
VULNERABILIDADE
Mas contexto acumulado pode melhorar a compreensão da superfície tecnológica.
Perfis profissionais fazem algo parecido.
Imagine dez funcionários.
Um menciona CICS.
Outro RACF.
Outro MQ.
Outro z/OS Connect.
Outro Db2.
Outro OpenShift.
Outro Azure.
Depois de algumas correlações podemos começar a imaginar:
Azure
|
OpenShift
|
API
|
z/OS Connect
|
CICS
|
COBOL
|
Db2
Novamente:
imaginar não é confirmar.
Frank bate na mesa.
— Evidência, Padawan!
🛡️ CAPÍTULO 13 — O BLUE TEAM DEVERIA FAZER OSINT CONTRA SI MESMO
Aqui está talvez o exercício mais valioso de toda esta conversa.
Pergunte:
O que uma pessoa sem qualquer acesso interno consegue aprender sobre meu ambiente IBM Z?
Faça isso de maneira autorizada e documentada.
Procure exposição desnecessária de:
LPAR
SYSNAME
SYSID
USERID
HLQ
JOBNAME
CICS APPLID
CICS TRANSACTION
Db2 SSID
MQ Queue Manager
Queue names
Dataset names
Program names
API endpoints
Screenshots
JCL
Copybooks
Architecture diagrams
Internal hostnames
Depois classifique.
NECESSÁRIO PUBLICAMENTE
|
ACEITÁVEL PUBLICAMENTE
|
EXPOSIÇÃO DESNECESSÁRIA
|
SENSÍVEL
|
SEGREDO
Isso é Attack Surface Management visto pelo lado de fora.
🔄 CAPÍTULO 14 — COLLECT, PIVOT, CORRELATE, VERIFY
Chegamos à melhor metodologia apresentada pelos slides.
1 — COLLECT
Colete informações públicas relevantes.
Sem tentar provar sua teoria antecipadamente.
2 — PIVOT
Use uma pista para localizar outras informações relacionadas.
USERNAME
↓
PROFILE
↓
COMPANY
↓
DOCUMENT
3 — CORRELATE
Procure relações.
documento → CICS
vaga → COBOL
perfil → MQ
case → API
Talvez exista uma arquitetura coerente.
4 — VERIFY
Procure confirmação independente.
Esse é o passo que separa investigação de imaginação.
E então o ciclo começa novamente:
COLLECT
↓
PIVOT
↓
CORRELATE
↓
VERIFY
↓
↺
⚠️ CAPÍTULO 15 — FALSO POSITIVO: O INIMIGO INVISÍVEL
Encontramos:
github.com/jsilva
E:
linkedin.com/in/jsilva
Mesmo nome.
Mesma profissão.
Talvez mesma cidade.
É a mesma pessoa?
Talvez.
Esse “talvez” salva investigações.
Da mesma maneira:
mainframe.empresa.example
não prova que exista um IBM Z ativo atrás daquele hostname.
Pode ser:
um nome histórico, DNS abandonado, serviço migrado, proxy, documentação antiga ou convenção sem relação direta com infraestrutura atual.
Portanto:
CORRELAÇÃO
≠
CAUSALIDADE
IDENTIFICADOR
≠
IDENTIDADE
HOSTNAME
≠
SERVIDOR
TECNOLOGIA
≠
VULNERABILIDADE
PISTA
≠
PROVA
Guarde isso.
🧪 CAPÍTULO 16 — O LABORATÓRIO BELLACOSA BANK
Vamos transformar tudo em exercício.
Criamos uma empresa fictícia:
BELLACOSA BANK
O aluno recebe apenas:
bellacosabank.example
Missão:
construir um mapa de exposição externa sem exploração intrusiva.
Ele deve procurar, no cenário simulado:
DOMAINS
CERTIFICATES
PUBLIC DOCUMENTS
CODE REPOSITORIES
JOB POSTINGS
TECHNOLOGIES
PEOPLE
PUBLIC ARCHITECTURE
Cada descoberta precisa possuir:
SOURCE:
DATE:
EVIDENCE:
CONFIDENCE:
RELATION:
STATUS:
No final:
BELLACOSA BANK
|
+------------+------------+
| | |
PEOPLE DOMAINS DOCS
| | |
GitHub TLS PDF
| | |
COBOL API CICS
\ | /
+-----------+----------+
|
HYPOTHESIS
|
IBM Z ECOSYSTEM
Esse exercício ensina algo que nenhuma ferramenta consegue ensinar sozinha:
método.
💡 CAPÍTULO 17 — DEZ DICAS PARA O PADAWAN COBOL
Nunca confunda informação pública com autorização de acesso.
Registre de onde veio cada descoberta.
Coloque data na evidência. Arquiteturas mudam.
Diferencie fato, hipótese e conclusão.
Procure confirmação independente.
Não despreze documentos antigos — mas não os trate automaticamente como arquitetura atual.
Analise metadados somente dentro de contexto autorizado e legítimo.
Em revisão defensiva, procure também vazamento arquitetural, não apenas passwords.
Pense em relacionamentos, não apenas em objetos.
E a mais importante:
Não tente provar que você estava certo. Tente descobrir onde você pode estar errado.
Essa é mentalidade de investigação.
🎩 CAPÍTULO 18 — FRANK ABAGNALE E A ENGENHARIA SOCIAL
Existe ainda uma camada humana.
Um ambiente pode possuir:
RACF
MFA
TLS
Firewall
SIEM
SMF
IDS
Zero Trust
e ainda existir risco relacionado às pessoas e aos processos.
Por quê?
Porque tecnologia opera dentro de organizações.
Existem:
funcionários, terceiros, fornecedores, suporte, processos de recuperação, help desk, administradores e exceções operacionais.
A grande contribuição narrativa de Frank para nossa história não é “como enganar sistemas”.
É exatamente o contrário:
entender por que confiança precisa ser verificada.
Em segurança:
“ELE PARECE LEGÍTIMO”
não deveria equivaler a:
“ELE ESTÁ AUTORIZADO”
Esse princípio combina perfeitamente com Zero Trust:
identifique, autentique, autorize, registre e verifique continuamente conforme o contexto.
🕒 EPÍLOGO — 03:17
Às 03:17, o telefone tocou.
War Room.
O programador COBOL entrou correndo.
— Invadiram o mainframe?
Frank estava sentado olhando para um quadro cheio de linhas.
LinkedIn
|
GitHub
|
PDF
|
DNS
|
Certificate
|
API
|
Integration
|
IBM Z
— Ainda não sabemos — respondeu.
— Então o que sabemos?
Frank apontou para o início do desenho.
— Sabemos que alguém não precisou começar pelo mainframe.
Silêncio.
O programador finalmente compreendeu.
Durante anos ele imaginara a segurança assim:
🏰
MAINFRAME
Agora enxergava:
INTERNET
|
+------------+------------+
| | |
PEOPLE SERVICES PARTNERS
| | |
GitHub API VPN
| | |
DevOps Gateway MQ
\ | /
+-----------+-----------+
|
TCP/IP / TLS
|
SAF / RACF
|
+------------+------------+
| | |
CICS IMS USS
| | |
+------------+------------+
|
COBOL / PL/I
|
Db2 / VSAM
|
DATA
O mainframe continuava sendo a fortaleza.
Só que agora ele conseguia enxergar as estradas.
Frank fechou a pasta.
Na capa havia apenas uma frase:
“Uma pista não é uma prova. Mas sete pistas independentes apontando para o mesmo lugar merecem sua atenção.”
O jovem programador voltou ao ISPF.
Antes enxergava programas.
Depois aprendeu a enxergar sistemas.
Naquela madrugada começou a enxergar relações.
E essa talvez seja a maior transformação para qualquer profissional que queira sair do mundo exclusivamente COBOL e entrar em segurança, observabilidade, Red Team, Blue Team ou arquitetura IBM Z:
não olhe apenas para o mainframe.
Olhe para tudo que confia nele.
Olhe para tudo em que ele confia.
Olhe para quem fala sobre ele.
Olhe para os sistemas que chegam até ele.
E, principalmente, aprenda a distinguir aquilo que você encontrou, aquilo que você deduziu e aquilo que você realmente conseguiu provar.
Porque no mundo de OSINT aplicado ao mainframe, a informação mais perigosa nem sempre está escondida atrás de uma RACF password.
Às vezes ela estava pública havia cinco anos, esquecida no canto de um PDF.
Esperando alguém conectar os pontos.
☕ Bellacosa Mainframe — porque até uma fortaleza deixa pegadas.
