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

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

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.

Translate

quinta-feira, 1 de junho de 2006