DEV Community: Ronaldo Modesto

Using local LLMs in API log analysis for near real-time attack detection

Ronaldo Modesto — Fri, 26 Jun 2026 16:57:52 +0000

A practical Proof of Concept (PoC): running a compact language model (qwen2.5-coder:1.5b) locally via Ollama to inspect logs from a REST API and detect attacks — including semantic ones, such as IDOR — that slip past WAFs and static rules.

The project used for this POC can be found here:

github -> https://github.com/R9n/api-logs-llm-analyze

1. Introduction

In recent years, Artificial Intelligence has gone from being a distant promise to becoming part of the day-to-day life of software engineering. Code generation, automated pull request review, assisted documentation, synthetic tests — the adoption curve of LLMs (Large Language Models) in the SDLC (Software Development Life Cycle) has grown almost exponentially. What once required specialized tools and dedicated teams can now be prototyped in an afternoon, on a personal machine.

This same movement opens a fascinating (and ambiguous) chapter for defensive security (AppSec). On one hand, we gain a new kind of "analyst": a model capable of reading unstructured text, understanding context, and reasoning about intent — something that tools based on fixed patterns were never able to do well. On the other hand, AI itself introduces new risks: prompt injection, leakage of sensitive data in prompts, hallucinations that generate false positives, and the dependence on expensive infrastructure for inference at scale.

At the center of this debate lies an old and increasingly acute problem: how do we monitor large volumes of API logs in real time? A modern application generates thousands of log lines per minute. Most of it is legitimate operational noise. Hidden in that stream are the signs of attacks — a sequence of login attempts, a swapped ID, an exposed debug endpoint. Finding these signals manually is unfeasible, and traditional tools, as we will see, have structural limitations in detecting attacks that depend on context rather than signature.

In this article we will explore this idea a bit, trying to identify context-based attacks using an LLM and a simple but fast model.

2. Proposed Approach and Objectives

The core of this work is simple to state and challenging to execute: run a local LLM as an automated security analyst, feeding it logs from a REST API in time windows, and measure its ability to detect attacks in (near) real time. I say near real time because we will always have the overhead of the model itself to analyze the logs, build the response, and return it to us.

Why not just Regex and signatures?

Traditional detection approaches — rule-based WAFs, signature-based IDS, Regex filters — are excellent at what they were designed for: capturing known and textually explicit patterns. A SQL Injection payload with ' OR '1'='1, a Path Traversal attempt with ../../etc/passwd, an XSS <script> — all of these have a clear "signature" that a static pattern recognizes.

The problem is that an entire class of attacks has no signature at all. Consider IDOR (Insecure Direct Object Reference) / BOLA (Broken Object Level Authorization):

GET /users/47b4f0a3-d582-47e9-832f-1e80ac12fe4b
Authorization: Bearer <common-user-token>

Syntactically, this request is identical to a legitimate one. There is no malicious character, no suspicious payload. What makes it an attack is the context: a regular user accessing another user's resource, or a single token touching many distinct IDs in a few seconds. Regex has no way of knowing this — it sees the line, not the story.

This is exactly where AI changes the game. An LLM can understand the context of a set of logs: correlate IPs, observe the cadence of requests, notice that a PATCH /users/:id/promote-admin coming from a recently created token is semantically anomalous — even if each request, in isolation, seems legitimate. It analyzes the intent inferred from behavior, not just the form.

Scope: this is a PoC

It is important to make clear from the outset: this work is a Proof of Concept (PoC). It is not a production-ready product, nor a replacement for corporate SIEM/WAF. It is a "start" — a controlled and reproducible experiment to answer a feasibility question:

Is it possible to use a lightweight local LLM to point out real attacks in API logs, including the logical/semantic attacks that static tools don't catch?

The goal is to demonstrate the feasibility of the approach and map out its pros, cons, and evolution paths toward a production scenario. This project THIS PROJECT IS NOT READY FOR PRODUCTION; IT LACKS ADEQUATE PROTECTION MECHANISMS

3. Technology Stack

To run the experiment we will adopt the "all local" policy: no log data leaves the machine, no calls to third-party APIs, inference cost equal to zero. This is especially relevant for security, where logs frequently contain sensitive data.

Execution platform: Ollama

Inference runs on Ollama, which exposes the model locally at http://localhost:11434. It handles loading the model onto the GPU, managing the context, and serving the responses via HTTP API — which makes it trivial to integrate into any Python pipeline.

Model used: `qwen2.5-coder:1.5b`

The choice of model was deliberate and perhaps counterintuitive. Instead of a giant model with tens of billions of parameters, we opted for qwen2.5-coder:1.5b — a model with only 1.5 billion parameters. The rationale:

Lightweight and fast: it fits comfortably in the VRAM of a more modest GPU and responds fast enough for analysis in 1-minute windows.
Optimized for structured tasks: being a coder variant, it is particularly good at understanding and producing structured outputs (JSON), interpreting technical formats (HTTP, paths, query strings), and following format instructions — exactly the profile needed to classify logs.
Proof of efficiency: part of the experiment's hypothesis is that analysis of text/structured logs does not require colossal models. A compact, specialized model may be sufficient.

Hardware configuration

The experiment ran entirely on a developer workstation (consumer hardware, not a server):

Component	Specification
GPU	NVIDIA RTX 3080 (10 GB VRAM)
CPU	Intel Core i5 13600KF
Memory	32 GB RAM
Storage	Standard NVMe SSD

Language and main libraries

The ecosystem is divided into two worlds, reflecting the real structure of the project:

Monitor and scripts (Python):

CrewAI — orchestration of the analysis agent (definition of Agent, Task, and Crew).
langchain-ollama / Ollama integration — bridge between CrewAI and the local model.
requests — collecting API logs and running the traffic/attack scripts.
schedule — scheduling the analysis windows (periodic execution).
pydantic — validation and typing of the model's output.

Target API (Node.js / TypeScript):

NestJS 11 — framework for the user management REST API. It's just an example API, only so we have something to analyze.
@nestjs/jwt + passport-jwt — JWT authentication.
bcrypt — password hashing.
class-validator / class-transformer — DTO validation.
@nestjs/swagger — automatic API documentation.

4. Architecture and Project Structure

The project was organized into four major blocks: the target API, the monitor (LLM agent), the simulation/attack scripts, and the consolidation utilities. The general data flow is as follows:

┌─────────────────────┐     ┌──────────────────────┐     ┌─────────────────────┐
│  Simulation / Attack│────▶│   NestJS API         │────▶│  operations.log     │
│  (Python scripts)   │     │   (generates JSON    │     │  (api/logs/)        │
│                     │     │    logs)             │     │                     │
└─────────────────────┘     └──────────────────────┘     └──────────┬──────────┘
                                                                     │
                                                                     ▼
┌─────────────────────┐     ┌──────────────────────┐     ┌─────────────────────┐
│  Results (.json)    │◀────│   CrewAI Monitor     │◀────│  GET /logs          │
│  monitor/results/   │     │   + Ollama (Qwen)    │     │  (time window)      │
└─────────────────────┘     └──────────────────────┘     └─────────────────────┘

Macro role of each component

api/ — The target application. A user management API with JWT authentication. Its key role for the experiment lies in the logging/ module: a global interceptor (LoggingInterceptor) captures each request and writes a structured JSON record (method, path, IP, userId, sanitized body, status code, latency). The GET /logs endpoint allows querying these records by time window (?start=&end=&limit=) — it is the source the monitor consumes.
monitor/ — The AI agent. main.py runs in a loop: every minute, it computes the time window, fetches the logs via GET /logs, assembles the prompt, and triggers the CrewAI Crew. The model's response is validated against the Pydantic schema and persisted as analysis-YYYYMMDD-HHMMSS.json.
scripts/trafic-simulation/ — Generates the legitimate background noise: sign-ups, correct and incorrect logins, profile editing, password reset, expected validation errors (400/401/409). This is fundamental for testing whether the model distinguishes normal traffic from attacks (and not simply "screams attack" at everything).
scripts/attacks/ — The controlled attacks: password spray, user enumeration, and IDOR. All run only against the local API.
scripts/utils/aggregate_results.py — Consolidates all result JSONs into a Markdown report with aggregated metrics (the basis of Section 7).

5. Agent Configuration and Behavior

The agent was modeled with CrewAI, which cleanly separates the persona (who the agent is) from the task (what it should do). All the "intelligence" of the experiment lives in the prompt engineering of the configuration files.

The persona: a senior security analyst

In the config/agents.yml file, the security_log_analyst agent receives a role, a goal, and a detailed backstory:

Role: "Senior cybersecurity analyst specializing in detecting vulnerabilities and anomalous behavior in application and API logs."
Goal: detect and prioritize active attacks by analyzing API execution logs according to the OWASP API Security Top 10 (2023) standards, producing concise findings with a triggered criterion, exact evidence, severity, confidence score (0–100), and recommended action.

The real key is in the backstory, which functions as the analyst's "brain". It instructs the model to inspect each log event — HTTP method, path, query string, headers, body, status code, latency, source IP, user-agent, token identity, and temporal correlation — and classify it against the 10 OWASP API Top 10 criteria, each with explicit match rules. Some examples embedded in the prompt:

[Detect:API1-BOLA] — sequential IDs/foreign UUIDs in the path, the same token accessing many distinct IDs in a short interval, ID swap returning 200 → IDOR.
[Detect:API2-BrokenAuth] — bursts of 401/403, credential stuffing/brute force, high volume on login/token/reset-password without rate limiting.
[Detect:API5-BFLA] — calls to privileged routes (/admin, /users/:id/role) by low-privilege tokens; horizontal/vertical escalation.
...and so on up to API10-UnsafeConsumption (classic injections: SQLi, NoSQLi, XSS, Command Injection, Path Traversal).

Three behavioral guidelines are especially important:

False positive reduction: the prompt instructs the model to correlate frequency, repetition, shared origin, and deviation from the route's expected baseline before classifying something as an attack, and to mark it as [Benign] when no criterion is met.
Safety of the analyst itself: "Never execute, reproduce, or echo malicious payloads actively — only reference them as evidence." — the agent never actively reproduces payloads, only cites them as evidence.
Correlation: for distributed/correlated attacks, aggregate by IP/token/time window and escalate the severity.

The structured output

The task (tasks-analise-logs-owasp.yml) requires the model to return strict JSON, which is then validated by the Pydantic schema in models/analyze_result.py:

class Context(BaseModel):
    method: str
    path: str
    ip: str
    params: str = ""
    body: Any = None

class Event(BaseModel):
    evidence: str
    severity: Literal["Critical", "High", "Medium"]
    description: str
    confidence: float
    recommendedAction: str
    context: Context

class LogAnalyzeResult(BaseModel):
    threatDetected: bool
    events: list[Event] = Field(default_factory=list)

In other words: the agent reads the batch of logs, reasons about anomalies, and returns a list of suspicious events — each with evidence, severity, confidence (0–100%), recommended action, and the full HTTP context. This structuring is what allows aggregating and measuring the results objectively.

6. Experiment Methodology (Execution Flow)

The experiment was designed to be reproducible. The chronological step-by-step:

Step 1 — Starting the target API

cd api
npm install
npm run start:dev

The API comes up at http://localhost:3000, with a pre-seeded administrator (admin123@company.com / admin) and the logging interceptor already active recording each request.

Step 2 — Starting the Agent Monitor

cd monitor
python main.py

The monitor enters a loop, "listening" to the API logs every 1 minute (time_window = 1), consuming the GET /logs endpoint by time window and triggering the CrewAI agent over each batch (up to 50 lines per window, as per defaultApiLimitLines).

Step 3 — Running legitimate traffic

python scripts/trafic-simulation/normal-trafic.py

This script generates the realistic background noise: successful and unsuccessful logins, valid and invalid sign-ups, profile edits, admin block/unblock cycles, password reset. It is the experiment's "control" — the traffic that the model should not classify as an attack.

Step 4 — Running the simulated attacks

cd scripts/attacks
python password-spray.py        # one common password against many users
python user-enumeration.py      # 401 vs 404 differentiation to map users
python idor.py                  # semantic attack: GET/PATCH on others' resources

With emphasis on idor.py, the central semantic attack of the experiment: it creates a regular "attacker", logs in, and tries GET /users/:id, PATCH /users/:id/block, .../unblock, and .../promote-admin on a victim's ID — requests that look perfectly legitimate in form, but are malicious in context.

Step 5 — Observation, collection, and analysis

While normal traffic and attacks run in parallel (generating the mixed traffic that makes the test realistic), the monitor produces one JSON per window in monitor/results/. At the end, the consolidation:

python scripts/utils/aggregate_results.py

generates the analise-resultados.md report with all the aggregated metrics — exactly the data presented in the next section.

7. Observed Results and Critical Analysis

The consolidation covered 23 runs of the agent over API logs, processing 809 log lines in mixed traffic (normal + attacks) over approximately 50 minutes.

Experiment summary

Metric	Value
Period analyzed	06/20/2026 14:46 – 06/20/2026 15:35 UTC
Total analyses	23
Analyses with threat detected	10 (43.5%)
Analyses without threat	13
Total logs processed	809
Total events generated by the LLM	221
Average events per analysis	9.6
Global average confidence	79.9%

Global severity distribution

Severity	Occurrences	Share
Critical	23	10.4%
High	187	84.6%
Medium	11	5.0%

Detections by attack type

Heuristic classification of the events based on the endpoint, HTTP method, and description returned by the model, aligned with the repository's attack scripts.

Attack	Detections (events)	Analyses with the pattern	Average severity	Average confidence	Most cited endpoint
Password Spray / Brute Force	133	10/23	High	78.0%	`POST /auth/login`
Sign-up abuse (POST /users)	38	5/23	High	83.8%	`POST /users`
API scanning / reconnaissance	16	4/23	High	83.4%	`GET /debug/database`
Other / model noise	12	3/23	High	93.3%	`POST /api-documentation`
User enumeration	11	1/23	High	67.7%	`GET /users/:id?`
IDOR (privilege escalation)	6	2/23	High	94.2%	`PATCH /users/ee87a7c3-f69e-4a4b-ae0f-db425d26a741/unblock`
Unauthorized access	5	1/23	High	64.0%	`GET /check-activity`

Here we have some prints of the execution of POC execution

Coverage by analysis window

How many monitor runs identified each attack pattern (regardless of the number of events within the same window).

Attack	Windows with detection	Rate over 23 analyses
Password Spray / Brute Force	10	43.5%
Sign-up abuse (POST /users)	5	21.7%
API scanning / reconnaissance	4	17.4%
Other / model noise	3	13.0%
IDOR (privilege escalation)	2	8.7%
Unauthorized access	1	4.3%
User enumeration	1	4.3%

Critical analysis of the data

The numbers tell an encouraging story for a PoC.

The model detected the attacks that mattered. In 10 of the 23 windows (43.5%), the agent raised a threat flag — and these detections are concentrated exactly on the vectors that were effectively simulated. Password Spray / Brute Force was the detection champion (133 events, present in 10 windows), which is entirely consistent: password-spray.py hammers POST /auth/login repeatedly, and the burst of attempts from the same IP is precisely the kind of temporal pattern that the LLM correlates well.

The high point: the semantic detection of IDOR. This was the most difficult and most relevant test of the PoC. Remember: IDOR requests are syntactically legitimate — a traditional WAF would let them through without blinking. Even so, the agent identified the pattern of privilege escalation via PATCH /users/:id/unblock and administrative actions on others' resources, and did so with the highest average confidence of the entire experiment: 94.2%. In other words, the model not only caught the attack invisible to static rules, but it was also the finding it was most confident about. This result, on its own, validates the central hypothesis of the work: the LLM's contextual analysis sees logical attacks that signatures don't see.

Confidence consistent with the clarity of the signal. The global average confidence stood at 79.9%, but the variation by category is revealing and shows a "calibrated" model: patterns with a strong signature and unambiguous context (IDOR at 94.2%, sign-up abuse at 83.8%, reconnaissance at 83.4%) receive high confidence, while more ambiguous inferences (unauthorized access at 64.0%, enumeration at 67.7%) receive lower confidence. The model, in essence, "knows when it's not sure".

The severity was well distributed. The predominance of High (84.6%) is appropriate for the set of attacks tested, with Critical (10.4%) appearing mainly in the windows of the most intense password spray — consistent with the API2-BrokenAuth criterion, classified as critical in the prompt.

And the cons already show up in the data. The "Other / model noise" category (12 events) is honest about the limit of the approach: it captures malformed or hallucinated responses from the LLM — invented or duplicated paths (POST /api-documentation, /check-activity, /token-authenticate) that don't correspond to real API endpoints. Curiously, these events came with high average confidence (93.3%), which is an important reminder: self-reported confidence by an LLM is no guarantee of correctness. This connects directly to the next section.

8. Pros and Cons of the Approach

A frank assessment, based on what the experiment showed in practice.

Pros

1. Detection of advanced attacks (the real differentiator).
The biggest asset of the approach is mitigating vulnerabilities that go unnoticed by common firewalls and WAFs — especially business logic flaws and IDOR/BOLA. Since the traffic of these attacks is syntactically legitimate, signature-based tools simply don't see them. The LLM's ability to analyze the context (who, accessing what, with what frequency, deviating from which baseline) allowed it to detect the simulated IDOR with 94.2% confidence. This is the kind of coverage that normally requires custom and expensive business rules — and that here emerged from the model's semantic understanding.

2. Efficiency of compact models.
The experiment delivered an excellent hit rate using an extremely lightweight model (Qwen 1.5B). This demystifies the idea that AI-assisted security analysis requires gigantic models. For the task of interpreting text/structured logs, a small, well-instructed model (with a good prompt based on the OWASP API Top 10) was sufficient. The practical implications are enormous: lower cost, lower latency, feasibility of running on-premise, and total privacy of the log data.

**3.Total control over data privacy.
Another critical advantage of this architecture is how it handles data privacy. By utilizing local, lightweight models, no confidential or sensitive data ever leaves the user's controlled environment. The entire pipeline—from log collection and context parsing to the final LLM evaluation—runs within your own infrastructure (on-premise or private cloud). This eliminates compliance risks associated with exposing internal traffic data to third-party APIs, ensuring absolute governance over corporate information.

Cons

1. False positives (and hallucinations).
Under mixed traffic and in stress tests, the model classified legitimate/normal traffic as an attack at some moments, and — more worryingly — even "hallucinated" endpoints that don't exist in the API (the "Other / model noise" category), sometimes with high confidence. This shows that the approach requires continuous prompt refinement (Prompt Tuning), stricter output validation (whitelist of real endpoints, grounding against the API inventory), and, above all, human supervision. An alert with 93% confidence about a non-existent endpoint is proof that self-reported confidence does not replace verification.

2. Local computational cost (Resource Exhaustion).
Even with a model of only 1.5B parameters, the GPU and VRAM consumption on the RTX 3080 (10 GB) was significant during continuous inference. For a PoC with 1-minute windows and ~50 logs per batch, it is perfectly manageable. But the experiment makes it clear that the approach does not scale linearly without cost: in a real production scenario — thousands of requests per second, multiple APIs, smaller windows — it would be necessary either to migrate to cloud models via API (trading privacy and variable cost for scale) or to invest in dedicated GPU infrastructure (raising Capex/Opex considerably). There is no free lunch: the inference cost is the tribute of semantic analysis.
Here we have an print of the moment that the monitor was performing an analyze, as we can see, to run a llm model, even a tiny one, you need a considerable computational power

9. Conclusion and Next Steps

This experiment demonstrated, in practice, that AI opens up disruptive horizons for application security — and not only in runtime detection, but at any stage of the SDLC. A lightweight local model, guided by a prompt grounded in the OWASP API Top 10, was able to detect not only classic attacks (password spray, enumeration, reconnaissance), but mainly the semantic attacks like IDOR, which are the historical blind spot of signature-based tools. For a PoC running on consumer hardware, it is an expressive result.

That said, the same PoC exposed the frontiers of the approach: false positives, occasional hallucinations, and non-trivial computational cost. Therefore, the most important conclusion is also the most sober one: the "Human-in-the-loop" factor is indispensable. AI should act as a force multiplier for the analyst — triaging, prioritizing, and contextualizing — and not as an autonomous judge. Human review remains the quality control that separates a useful alert from expensive noise.

Next Steps: evolving the PoC with Vector DB / RAG

The most structural limitation of the current design is that it analyzes isolated windows, without memory. Each run sees only the last minute of logs — and this amnesia is a conceptual vulnerability.

The next big leap is to integrate a Vector Database (Vector DB) in a RAG (Retrieval-Augmented Generation) architecture. The idea: store embeddings of the history of events and behaviors, so that each new analysis can retrieve relevant past context before deciding.

This would unlock the detection of a class of attacks that is today impossible to capture by analyzing isolated lines:

"Low and Slow" attacks: the attacker makes one malicious request today, another tomorrow, deliberately spacing out the actions to stay below rate limiting thresholds and correlation windows. Without memory, each request seems harmless; with semantic memory, the pattern distributed over time emerges.
Advanced Persistent Threats (APT): long, multi-stage campaigns, where reconnaissance, escalation, and exfiltration happen over days or weeks. Only a correlatable long-term memory allows connecting the dots.

With a Vector DB, the agent would stop being an analyst with amnesia every minute and become an analyst with long-term memory — able to ask "have I seen this IP/token/behavior before?" and to reconstruct the narrative of an attack that unfolds slowly. This is the natural path to transforming this PoC into something that approaches a truly contextual detection tool.

Legal disclaimer: all attack scripts in this experiment are intended exclusively for controlled lab environments and educational purposes. Never use them against systems without express authorization.

References

CrewAi Docs

OWASP Top 10 API

Ollama

Prompt Engineering Guide by Google

I hope this article serves at least to spark curiosity about how we can advance the monitoring of our applications.
Stay well and see you next time 🙂

Protocols Visualizer: An Interactive Way to Learn Network Protocols

Ronaldo Modesto — Sat, 07 Mar 2026 13:35:49 +0000

Understanding how network protocols work is often heavy going: RFCs and textbooks explain the concepts, but it's hard to "see" handshakes, packet structure, and attacks in action. Protocols Visualizer is a free, interactive web app that turns those ideas into visual, step-by-step flows and simulations.

Try it here: https://protocols-visualizer.vercel.app/en

The app is built around the OSI model. You can browse all seven layers — from Physical (Bluetooth, USB, Coaxial) up to Application (HTTP, DNS, FTP, SMTP) — and open each protocol to explore three main areas: Communication Flow (animated sequence diagrams), Packet Anatomy (interactive headers), and Attack Simulation (e.g. SYN Flood, ARP Spoofing, deauth, Bad USB). The goal is to make dense topics like TCP handshakes, IP routing, or common attacks easier to grasp by showing them in motion instead of only in text.

The project is implemented with Next.js, React, TypeScript, and Tailwind CSS, and is available in English and Portuguese. Whether you're studying for certs, teaching networking, or just curious how the stack works, Protocols Visualizer is a handy companion to see protocols in action.

Feedbacks are welcome

Safeinstall: Um aliado no combate a ataques de Supply chain

Ronaldo Modesto — Thu, 19 Feb 2026 22:10:25 +0000

Olá, pessoal!

Se você é desenvolvedor ou, pelo menos, envolvido com a área tech, tenho certeza de que já ouviu falar de ataques de supply chain, ou ataques de cadeia de suprimentos.

Esse tipo de ataque tem se tornado cada vez mais frequente, ainda mais com IAs gerando cada vez mais código sem supervisão. Com isso em mente, criei uma ferramenta que visa impedir que dependências comprometidas sejam instaladas em seu projeto, reduzindo o risco de um ataque bem-sucedido de cadeia de suprimentos.

Chega mais para conhecer! E, claro, todo feedback é super bem-vindo. 🙂

Ha e claro, se quiser saber mais sobre o que é supply chain atack, dá uma conferida aqui O que é Suply Chain Attack

A Crise de Segurança na Cadeia de Suprimentos Open Source

Os ataques de supply chain (cadeia de suprimentos) têm aumentado de forma alarmante nos últimos anos. Dados recentes revelam um cenário preocupante:

Malware em código aberto subiu 156% de um ano para outro em 2024, com mais de 704 mil pacotes maliciosos identificados desde 2019.
Em 2025, houve um aumento de 73% em pacotes open source maliciosos detectados em comparação com 2024.
Entre 2020 e 2023, as ameaças em repositórios open source cresceram 1.300%.
O custo global anual projetado de ataques de supply chain deve alcançar US$ 60 bilhões em 2025.
No ecossistema npm, a atividade maliciosa mais do que dobrou em 2025, representando quase 90% de todo o malware open source detectado.
Terceiros comprometidos passaram a representar 30% de todas as violações de dados em 2025.

Instalar dependências sem verificação tornou-se uma operação de risco. Mesmo pacotes populares podem conter vulnerabilidades conhecidas ou, em cenários mais graves, serem comprometidos por atacantes.

O que é o SafeInstall ✅?

O SafeInstall é um wrapper de segurança para comandos de instalação de pacotes que consulta a API do OSV (Open Source Vulnerabilities) para identificar vulnerabilidades conhecidas antes de permitir que a instalação seja concluída. Assim, ele ajuda a reduzir ataques de supply chain alertando o desenvolvedor sobre pacotes vulneráveis antes que eles entrem no projeto.

Repositório da ferramenta 🚀: Github

Benefícios Principais

Verificação antes da instalação — Nada é instalado sem checagem de vulnerabilidades.
Integração com OSV — Usa dados agregados do GitHub Advisory, PyPI Advisory, CVE/NVD, RustSec, Go Vulnerability Database e outros.
Suporte a múltiplos ecossistemas — npm, pip, Go, Cargo, RubyGems, Packagist, Pub.
Instalações em lote — Protege comandos como npm install e pip install -r requirements.txt.
Controle nas suas mãos — Permite confirmar ou cancelar instalações com risco identificado.

A seguir temos mostro exemplos de como a ferramenta funciona e como ela pode auxiliar na proteção desse tipo de ataque.

Bloqueando instalação de biblioteca especificando uma versão

Bloqueando instalação de biblioteca utilizando instalação em massa, por exemplo npm i

Permitindo instalação de bibliotecas mesmo com vulnerabilidades(ambientes de CI/CD por exemplo)

Quando uma versão não é especificada, a ferramenta tenta identificar automaticamente a última versão e então analisa para ver se alguma vulnerabilidade é encontrada

Exemplo golang para instalação vulnerável vs instalação de última versão

Exemplo de biblioteca python

Exemplo de biblioteca sem vulnerabilidades em lotes

Exemplo de biblioteca sem vulnerabilidade

Como Instalar 💥

Pré-requisitos

Go 1.25.7+ — Necessário para compilar o SafeInstall e para o osv-scanner.
osv-scanner — Necessário para varreduras em lote. É instalado automaticamente pelos scripts de instalação.

Para instalar o osv-scanner manualmente (se necessário):

go install github.com/google/osv-scanner/v2/cmd/osv-scanner@v2

Garanta que $(go env GOPATH)/bin esteja no seu PATH.

Instalação por plataforma

Windows (PowerShell):

.\scripts\install.ps1

Windows (Prompt de Comando):

scripts\install.bat

Linux / macOS:

chmod +x scripts/install.sh
./scripts/install.sh

Compilação manual:

go build -o safeinstall .

Comandos e Uso

Sintaxe básica

Sintaxe nova (recomendada):

safeinstall [-y|--yes] <ecosistema> "<pacote>"

Sintaxe legada (comando completo):

safeinstall [-y|--yes] "<comando de instalação>"

Instalação de pacote único

Ao especificar um pacote com versão, o SafeInstall:

Consulta a API do OSV em busca de vulnerabilidades conhecidas
Aplica o algoritmo IsVulnerable para saber se sua versão exata é afetada
Se houver vulnerabilidade: exibe CVE/GHSA em vermelho e pede confirmação
Se estiver seguro: exibe mensagem em verde e prossegue automaticamente

Exemplos (sintaxe nova):

safeinstall npm "express"
safeinstall npm "express@4.17.1"
safeinstall pip "requests==2.25.1"
safeinstall pip "jinja2"
safeinstall go "golang.org/x/crypto@v0.1.0"

Exemplos (sintaxe legada):

safeinstall "npm i express"
safeinstall "pip install -r requirements.txt"

Instalação em lote (npm i, pip install -r, etc.)

Para comandos que não especificam um único pacote (ex.: npm install, npm ci, pip install -r requirements.txt):

O osv-scanner roda antes da instalação, analisando manifests e lockfiles
Se forem encontradas vulnerabilidades e você não passou -y/--yes, o SafeInstall pede confirmação
Se você recusar, a instalação é cancelada — pacotes vulneráveis não são instalados
Se não houver vulnerabilidades (ou você aceitar o risco), o comando de instalação é executado
Após a instalação, o osv-scanner roda novamente para verificar as dependências instaladas

Exemplos:

safeinstall "npm install"
safeinstall "npm ci"
safeinstall "pip install -r requirements.txt"

Modo CI/CD

Use -y ou --yes para aceitar automaticamente os riscos em ambientes automatizados:

safeinstall -y "npm install express@4.17.1"

Desinstalação

Para remover o SafeInstall por completo:

safeinstall --uninstall
# ou
safeinstall -u
# ou
safeinstall uninstall

Ou use os scripts de desinstalação:

Windows (PowerShell): .\scripts\uninstall.ps1
Windows (CMD): scripts\uninstall.bat
Linux/macOS: ./scripts/uninstall.sh

Ecossistemas Suportados

Ecossistema	Gerenciador de Pacotes	Exemplo
npm	npm, yarn, pnpm	`safeinstall npm "express@4.17.1"`
PyPI	pip, pip3, poetry	`safeinstall pip "requests==2.25.1"`
Go	go get	`safeinstall go "golang.org/x/crypto@v0.1.0"`
crates.io	cargo	`safeinstall "cargo add serde@1.0"`
RubyGems	gem	`safeinstall "gem install rails:7.0"`
Packagist	composer	Pacotes PHP
Pub	pub	Pacotes Dart

Como o SafeInstall Reduz o Risco de Supply Chain

Bloqueio proativo — Evita instalações de pacotes conhecidamente vulneráveis ou maliciosos.
Uso de dados confiáveis — OSV agrega bases como GitHub Advisory, PYSEC, CVE e RustSec.
Avaliação precisa — Usa o algoritmo oficial do OSV (IncludedInVersions, IncludedInRanges, BeforeLimits).
Dupla verificação em lote — Analisa antes e depois da instalação em cenários como npm install e pip install -r.
Decisão consciente — O desenvolvedor escolhe se aceita o risco em casos específicos.
Integração simples — Substitui chamadas diretas aos gerenciadores de pacotes com um comando único.

Requisitos

Conexão com a internet para consultas à API

- Go e osv-scanner no PATH (para instalações em lote)

Fontes:

[1] Supply Chain Attack Statistics 2025: Costs & Defenses — DeepStrike. https://deepstrike.io/blog/supply-chain-attack-statistics-2025
[2] The State of the Software Supply Chain 2025 — JFrog. https://jfrog.com/blog/state-of-software-supply-chain-security-2025
[3] ReversingLabs 2026 Software Supply Chain Security Report — 73% aumento em pacotes open source maliciosos. https://www.reversinglabs.com/press-releases/reversinglabs-2026-software-supply-chain-security-report-identifies-73-increase-in-malicious-open-source-packages
[4] Sonatype's 10th Annual State of the Software Supply Chain Report — 156% de aumento em malware open source. https://www.globenewswire.com/news-release/2024/10/10/2961239/0/en/Sonatype-s-10th-Annual-State-of-the-Software-Supply-Chain-Report-Reveals-156-Surge-in-Open-Source-Malware.html

Como Funciona Supply Chain Attack -PTBR

Ronaldo Modesto — Thu, 19 Feb 2026 22:08:09 +0000

Access the english version here: Click Here

Olá pessoal.
Hoje quero trazer um pouquinho a mais de conhecimento a respeito de um tipo de ataque que tem se tornado cada vez mais frequente. O Supply Chain Attack, ou ataque de cadeia de suprimentos.
Bora lá ver como isso funciona no ecossistema npm e o que podemos fazer para mitigar esse risco.
Lembrando que aqui eu trouxe o npm apenas como exemplo, mas esse tipo de ataque pode ocorrer em outros gerenciadores de pacotes também!

Aqui você encontra uma ferramenta que eu desenvolvi para mitigar esse tipo de ataque: Safeinstall

Caso queira ver como a ferramenta funciona, dá uma olhada aqui SafeInstall

Introdução

Quantas vezes por dia você executa npm install? Para a maioria dos desenvolvedores JavaScript e Node.js, a resposta é: várias. Essa rotina aparentemente inocente — instalar uma dependência para resolver um problema — esconde um vetor de ataque cada vez mais explorado por cibercriminosos: o ataque de supply chain (ou ataque de cadeia de suprimentos).

Neste artigo, exploramos o que são esses ataques, como funcionam na prática usando um projeto de demonstração real, quais seriam as consequências em ambientes de produção e como você pode se proteger.

O projeto utilizado no artigo pode ser encontrado aqui: Projeto Exemplo

O que é um Supply Chain Attack?

Um ataque de supply chain ocorre quando um atacante compromete algum componente que faz parte da cadeia de suprimentos de software — ou seja, algo que os desenvolvedores ou sistemas confiam e utilizam sem questionar. No ecossistema npm, isso se materializa principalmente através de:

Pacotes maliciosos criados do zero para parecerem legítimos
Pacotes legítimos comprometidos (manutenção abandonada, conta hackeada, typosquatting)
Scripts de lifecycle que executam automaticamente durante npm install

O ponto crítico é que o desenvolvedor não precisa fazer nada além de instalar o pacote. Não é necessário abrir um arquivo suspeito, clicar em um link ou executar um binário desconhecido. O simples ato de adicionar uma dependência ao package.json e rodar npm install pode ser suficiente para comprometer a máquina, o repositório ou a infraestrutura.

Scripts de Lifecycle: A Porta de Entrada

O npm define diversos scripts que são executados em momentos específicos do ciclo de vida de um pacote:

Script	Momento de execução
`preinstall`	Antes do pacote ser instalado
`install`	Durante a instalação
`postinstall`	Imediatamente após a instalação — alvo preferido de ataques
`preuninstall`	Antes de desinstalar
`postuninstall`	Após desinstalar
`prepublish`	Antes de publicar no registro npm

Qualquer pessoa que execute npm install rodará esses scripts automaticamente, sem avisos claros. É aí que reside o perigo.

Projeto de Demonstração: Estrutura e Código

Para ilustrar o vetor de ataque, criamos um projeto educacional composto por:

Pacote “malicioso” — um pacote que parece útil, mas executa código nas fases de instalação
Projeto vítima — um projeto que simplesmente depende desse pacote

Estrutura do Pacote Malicioso

O package.json do pacote define os scripts que serão executados:

{
  "name": "utilidades-uteis",
  "version": "1.0.0",
  "description": "Pacote útil que parece legítimo mas executa código no post-install",
  "main": "index.js",
  "scripts": {
    "postinstall": "node postinstall.js",
    "preinstall": "node preinstall.js"
  },
  "keywords": ["utility", "helper"],
  "author": "Atacante Anônimo",
  "license": "MIT"
}

Note que postinstall e preinstall apontam para scripts Node.js. Esses scripts rodam automaticamente durante a instalação.

Script preinstall.js

Este script executa antes da instalação do pacote:

/**
 * PREINSTALL - Roda ANTES da instalação do pacote
 * Outra fase onde código malicioso pode executar
 */

console.log('\u001b[35m[preinstall]\u001b[0m Este script roda antes mesmo do pacote ser instalado!');

Em um ataque real, aqui poderia haver coleta inicial de dados ou preparação do ambiente.

Script postinstall.js — O Coração do Ataque

Aqui está o script que simula a exfiltração de dados sensíveis:

const fs = require('fs');
const path = require('path');
const os = require('os');

// Simula o que um atacante PODERIA coletar (apenas mostra, não envia)
const dadosSensiveis = {
  executadoEm: new Date().toISOString(),
  usuario: os.userInfo().username,
  diretorioAtual: process.cwd(),
  platform: process.platform,
  nodeVersion: process.version,
  // Um atacante real tentaria ler:
  // env: process.env,  // Tokens, senhas, API keys
  // arquivos: fs.readdirSync(process.env.HOME)
};

// Cria arquivo de "prova" - em ataque real seria enviado para servidor
const arquivoProva = path.join(process.cwd(), 'PROVA_ATAQUE_SUPPLY_CHAIN.json');
fs.writeFileSync(arquivoProva, JSON.stringify(dadosSensiveis, null, 2), 'utf8');

console.log(`\u001b[31m[ATAQUE SIMULADO]\u001b[0m Dados coletados salvos em: ${arquivoProva}`);
console.log('\nEm um ataque REAL, isso seria enviado para o servidor do atacante.\n');

Exemplo de arquivo criado após o script executar

E ao executar a aplicação o usuário nem percebe o que aconteceu

Em uma versão maliciosa real, o atacante trocaria fs.writeFileSync por uma chamada HTTP (por exemplo, com https.request) para enviar esses dados a um servidor sob seu controle. O pacote também expõe um módulo legítimo (index.js) que faz algo útil — tornando o pacote plausível e reduzindo a suspeita.

Fluxo do Ataque

1. Desenvolvedor: npm install utilidades-uteis
2. npm baixa o pacote
3. npm executa preinstall  → código malicioso #1
4. npm executa postinstall → código malicioso #2 (coleta dados)
5. Pacote instalado normalmente
6. Desenvolvedor não percebe que foi comprometido

Consequências em Ambientes Reais

O que poderia acontecer se esse fosse um ataque real? As consequências variam conforme o contexto da vítima.

1. Exfiltração de Credenciais e Segredos

Variáveis de ambiente (process.env): tokens de API (AWS, GitHub, Stripe), chaves de banco de dados, senhas
Arquivos .env: credenciais em texto plano em vários projetos
Arquivos de configuração: ~/.npmrc, ~/.aws/credentials, ~/.ssh/config

Impacto: Acesso a contas cloud, bancos de dados, repositórios privados e sistemas de terceiros.

2. Roubo de Chaves SSH e Certificados

Leitura de ~/.ssh/ (chaves privadas, known_hosts)
Uso das chaves para acessar servidores, GitHub, repositórios privados

Impacto: Invasão de servidores, clonagem de repositórios privados, commit de código malicioso em nome da vítima.

3. Cryptojacking

Execução de minerador de criptomoeda em segundo plano
Uso de CPU e energia da máquina ou servidor da vítima

Impacto: Custos elevados de infraestrutura, degradação de desempenho, possível violação de políticas de uso de cloud.

4. Backdoors e Persistência

Instalação de ferramentas de acesso remoto
Adição de tarefas agendadas ou scripts de inicialização

Impacto: Controle prolongado da máquina, espionagem, preparação para ataques futuros.

5. Modificação de Outros Pacotes

Alteração de código em node_modules de outras dependências
Injeção de backdoors em bibliotecas usadas em produção

Impacto: Comprometimento em escala, propagação do ataque para todos os usuários da aplicação.

6. Em Ambientes CI/CD

Acesso a secrets de pipelines (tokens, credenciais)
Possibilidade de modificar artefatos de build ou imagens Docker
Deploy de versões comprometidas em produção

Impacto: Comprometimento de toda a cadeia de entrega, desde o build até produção.

Casos Reais Documentados

Caso	Ano	Descrição
event-stream	2018	Pacote com ~2M downloads/semana. Código malicioso adicionado para roubar carteiras Bitcoin.
ua-parser-js	2021	Biblioteca popular comprometida; executava minerador de criptomoeda.
coa e rc	2021	Typosquatting; pacotes roubavam variáveis de ambiente e as enviavam para servidor remoto.
node-ipc	2022	Adicionou código que alterava arquivos em máquinas de desenvolvedores de certas regiões geográficas.

Medidas de Proteção

Use --ignore-scripts quando possível: npm install --ignore-scripts
Audite dependências: npm audit, npm audit fix
Verifique scripts: npm view nome-do-pacote antes de instalar
Ferramentas especializadas: Socket.dev, Snyk para detecção de comportamentos suspeitos
Mantenha package-lock.json versionado e revise mudanças
Verifique procedência: downloads, manutenção ativa, repositório aberto

Conclusão

O ecossistema npm é extremamente conveniente, mas essa conveniência traz riscos. O ato aparentemente trivial de npm install pode executar código arbitrário na sua máquina. A consciência sobre supply chain attacks e a adoção de boas práticas de segurança são fundamentais para reduzir a superfície de ataque e proteger projetos e infraestrutura.

O projeto de demonstração está disponível para que você possa testar o fluxo em um ambiente controlado e entender na prática como esses ataques funcionam.

How Supply Chain Attacks Work

Ronaldo Modesto — Thu, 19 Feb 2026 22:08:03 +0000

Acesse a versão em português aqui: Clique Aqui

Hi everyone.

Today I want to share a little more knowledge about a type of attack that has become increasingly frequent: the Supply Chain Attack.

Let's see how this works in the npm ecosystem and what we can do to mitigate this risk.
Remember that I've only used npm as an example here, but this type of attack can occur in other package managers as well!

Here you'll find a tool I developed to mitigate this type of attack. Safeinstall

If you want to see how the tool works, take a look here SafeInstall

Introduction

How many times a day do you run npm install? For most JavaScript and Node.js developers, the answer is: many. This seemingly innocent routine — installing a dependency to solve a problem — hides an attack vector increasingly exploited by cybercriminals: the supply chain attack.

In this article, we explore what these attacks are, how they work in practice using a real demonstration project, what the consequences would be in production environments, and how you can protect yourself.

The project used in the article can be found here: Example Project

What is a Supply Chain Attack?

A supply chain attack occurs when an attacker compromises a component that is part of the software supply chain — something that developers or systems trust and use without question. In the npm ecosystem, this materializes mainly through:

Malicious packages created from scratch to appear legitimate
Compromised legitimate packages (abandoned maintenance, hacked account, typosquatting)
Lifecycle scripts that execute automatically during npm install

The critical point is that the developer does not need to do anything beyond installing the package. No need to open a suspicious file, click a link, or run an unknown binary. The simple act of adding a dependency to package.json and running npm install can be enough to compromise the machine, repository, or infrastructure.

Lifecycle Scripts: The Entry Point

npm defines various scripts that run at specific moments in a package's lifecycle:

Script	When it runs
`preinstall`	Before the package is installed
`install`	During installation
`postinstall`	Immediately after installation — preferred target for attacks
`preuninstall`	Before uninstalling
`postuninstall`	After uninstalling
`prepublish`	Before publishing to the npm registry

Anyone who runs npm install will execute these scripts automatically, with no clear warning. That is where the danger lies.

Demonstration Project: Structure and Code

To illustrate the attack vector, we built an educational project consisting of:

"Malicious" package — a package that appears useful but runs code during installation
Victim project — a project that simply depends on that package

Malicious Package Structure

The package's package.json defines the scripts that will be executed:

{
  "name": "utilidades-uteis",
  "version": "1.0.0",
  "description": "Pacote útil que parece legítimo mas executa código no post-install",
  "main": "index.js",
  "scripts": {
    "postinstall": "node postinstall.js",
    "preinstall": "node preinstall.js"
  },
  "keywords": ["utility", "helper"],
  "author": "Atacante Anônimo",
  "license": "MIT"
}

Note that postinstall and preinstall point to Node.js scripts. These scripts run automatically during installation.

preinstall.js Script

This script runs before the package is installed:

/**
 * PREINSTALL - Runs BEFORE the package is installed
 * Another phase where malicious code can execute
 */

console.log('\u001b[35m[preinstall]\u001b[0m This script runs even before the package is installed!');

In a real attack, initial data collection or environment preparation could happen here.

postinstall.js Script — The Heart of the Attack

Here is the script that simulates exfiltration of sensitive data:

const fs = require('fs');
const path = require('path');
const os = require('os');

// Simulates what an attacker COULD collect (only shows, does not send)
const dadosSensiveis = {
  executadoEm: new Date().toISOString(),
  usuario: os.userInfo().username,
  diretorioAtual: process.cwd(),
  platform: process.platform,
  nodeVersion: process.version,
  // A real attacker would try to read:
  // env: process.env,  // Tokens, passwords, API keys
  // arquivos: fs.readdirSync(process.env.HOME)
};

// Creates "proof" file - in real attack would be sent to server
const arquivoProva = path.join(process.cwd(), 'PROVA_ATAQUE_SUPPLY_CHAIN.json');
fs.writeFileSync(arquivoProva, JSON.stringify(dadosSensiveis, null, 2), 'utf8');

console.log(`\u001b[31m[SIMULATED ATTACK]\u001b[0m Data collected saved to: ${arquivoProva}`);
console.log('\nIn a REAL attack, this would be sent to the attacker\'s server.\n');

Example of a file created after the script runs:

And when running the application, the user doesn't even notice what happened:

In a real malicious version, the attacker would replace fs.writeFileSync with an HTTP call (e.g., using https.request) to send this data to a server under their control. The package also exposes a legitimate module (index.js) that does something useful — making the package plausible and reducing suspicion.

Attack Flow

1. Developer: npm install utilidades-uteis
2. npm downloads the package
3. npm runs preinstall  → malicious code #1
4. npm runs postinstall → malicious code #2 (collects data)
5. Package installed normally
6. Developer does not realize they have been compromised

Consequences in Real Environments

What could happen if this were a real attack? The consequences vary depending on the victim's context.

1. Exfiltration of Credentials and Secrets

Environment variables (process.env): API tokens (AWS, GitHub, Stripe), database keys, passwords
.env files: credentials in plain text across multiple projects
Configuration files: ~/.npmrc, ~/.aws/credentials, ~/.ssh/config

Impact: Access to cloud accounts, databases, private repositories, and third-party systems.

2. Theft of SSH Keys and Certificates

Reading ~/.ssh/ (private keys, known_hosts)
Using the keys to access servers, GitHub, private repositories

Impact: Server intrusion, cloning of private repositories, malicious commits in the victim's name.

3. Cryptojacking

Running a cryptocurrency miner in the background
Consuming the victim's machine or server CPU and power

Impact: High infrastructure costs, performance degradation, possible violation of cloud usage policies.

4. Backdoors and Persistence

Installing remote access tools
Adding scheduled tasks or startup scripts

Impact: Prolonged control of the machine, espionage, preparation for future attacks.

5. Modification of Other Packages

Altering code in node_modules of other dependencies
Injecting backdoors into libraries used in production

Impact: Compromise at scale, propagation of the attack to all application users.

6. In CI/CD Environments

Access to pipeline secrets (tokens, credentials)
Ability to modify build artifacts or Docker images
Deployment of compromised versions to production

Impact: Compromise of the entire delivery chain, from build to production.

Documented Real-World Cases

Case	Year	Description
event-stream	2018	Package with ~2M weekly downloads. Malicious code added to steal Bitcoin wallets.
ua-parser-js	2021	Popular library compromised; ran cryptocurrency miner.
coa and rc	2021	Typosquatting; packages stole environment variables and sent them to a remote server.
node-ipc	2022	Added code that modified files on machines of developers from certain geographic regions.

Protection Measures

Use --ignore-scripts when possible: npm install --ignore-scripts
Audit dependencies: npm audit, npm audit fix
Verify scripts: npm view package-name before installing
Specialized tools: Socket.dev, Snyk for detecting suspicious behavior
Keep package-lock.json in version control and review changes
Verify package provenance: download counts, active maintenance, open repository

Conclusion

The npm ecosystem is extremely convenient, but that convenience carries risks. The seemingly trivial act of npm install can execute arbitrary code on your machine. Awareness of supply chain attacks and adopting security best practices are essential to reduce the attack surface and protect projects and infrastructure.

The demonstration project is available so you can test the flow in a controlled environment and understand how these attacks work in practice.

This article was written for educational purposes. The demonstration project contains only simulated code and does not perform any real malicious actions.

Hi, I created Cyber Alerts, a collaborative website for reporting scams. The goal is to prevent more people from falling into traps. Feedback and ideas for improvement are very welcome 🚀 https://cyber-alerts.com.br

Ronaldo Modesto — Mon, 22 Dec 2025 16:43:13 +0000

CyberAlert: Mapa Comunitário de Golpes | Segurança Digital Colaborativa

Plataforma colaborativa para reportar e mapear golpes digitais em tempo real. Proteja-se e ajude a proteger outros.

cyber-alerts.com.br

Plataforma Para Reportar Golpes: Cyber Alerts 🛡️

Ronaldo Modesto — Mon, 22 Dec 2025 13:38:27 +0000

Hi everyone, how are you?

With the end of the year approaching and some free time to spare, I finally managed to bring to life an idea that had been on hold: Cyber Alerts.

The Problem
We know that, with the use of AI, scams are becoming increasingly sophisticated (deepfakes, personalized phishing, etc.). I believe that the best defense, besides technology, is shared information.

The Solution
I created this platform so that anyone can quickly report scams they've suffered. The goal is to create a community database where people can consult recent tactics and avoid falling into traps.

What's coming next?

The platform is simple and intuitive.

I will soon add support for multiple languages (English is next on the list).

I am open to suggestions for new features (filters by category, integration with security APIs, etc.).

Project link: https://cyber-alerts.com.br

Suggestions for improvement, stack ideas, or constructive criticism are very welcome! As this community is tech-oriented, I'd love to know what you think of the usability and the project's concept 🙂.

Ebook: Desenvolvimento Seguro de Apis

Ronaldo Modesto — Wed, 19 Mar 2025 21:49:23 +0000

Olá, pessoal! Tudo bem? 😀

Hoje quero apresentar um projeto no qual venho trabalhando há algum tempo.

Desde que a onda da inteligência artificial começou, muitos desenvolvedores passaram a utilizar assistentes de código para criar suas aplicações. Isso é ótimo, pois aumenta consideravelmente a produtividade. No entanto, essa prática também esconde um grande perigo: falhas de segurança.

Infelizmente, a maioria dos desenvolvedores não se preocupa em validar o que a IA gera, e, com isso, muitas vulnerabilidades acabam indo para ambientes de produção, resultando em softwares com diversas brechas.

Outro ponto que me incomoda ao pesquisar sobre cibersegurança é que a maioria dos sites ensina apenas a detectar vulnerabilidades, mas não oferece soluções eficazes para corrigi-las.

Pensando nisso, criei este eBook, onde abordo várias falhas comuns em APIs. Diferente de outros materiais, não apenas mostro as vulnerabilidades, mas também explico em detalhes como elas surgem e apresento exemplos de código para mitigá-las. Dessa forma, qualquer desenvolvedor poderá identificar e corrigir essas falhas em qualquer tecnologia.

Se quiser adquirir o eBook, basta acessar minha página de vendas. Por um valor simbólico de R$ 49,90, você terá acesso a um conteúdo valioso.

Aqui está um exemplo do que você encontrará no eBook:

Na imagem a seguir, apresento uma explicação detalhada sobre a vulnerabilidade de Path Traversal, uma falha muito comum e extremamente perigosa em APIs.

Com este eBook, você aprenderá a identificar e corrigir essa e muitas outras vulnerabilidades 🚀🚀.

Caso queira adquirir o ebook pode fazê-lo aqui

https://rm-ebook-api-development.com.br

Espero que esse ebook possa te ajudar a escrever códigos melhores e mais seguros tanto para projetos pessoas quanto profissionais 🙂

Fiquem bem e até a próxima 🙂

Flappy Bird Multiplyer

Ronaldo Modesto — Thu, 21 Nov 2024 01:34:34 +0000

Hello everyone, how are you? I hope well 😃

Today I'm here to show you something different.
Nothing about cybersecurity or anything like that.
Today I'm here to show you my new project, I'm a flappy bird game with single and multiplayer

➡️ You can find the game here: https://www.multibirds.dev ⬅️

This game was made with the following technologies

io socket
Angular
NestJs
Screen
Nginx
Google AdSense

Basically there are 4 game modes

Single player

The mode where you play alone move to get the highest possible score. This is the classic mode.

Multiplayer Co-op

In this mode you play with a friend, it's a great way to kill time while waiting for something 😃

Multiplayer versus
In this mode you can challenge a friend to see who survived the most, it also looks really cool 🙂

Practice Mode

In this mode you can practice withowt dying and you can play as long as you want.

How to play

To play, just copy your ID and send it to a friend or ask him to send you his ID and you can call him to play.
No need to create an account or anything like that, just come and play :)

Well that's it for today guys, I just wanted to present this little project that I intend to improve in the future, I have some really cool ideas, I just need time.
Here are some screeshots, but this is a work in progress and will be updated soon :)

Stay safe and see you next time 😃

Removendo Dados Sensiveis de Images

Ronaldo Modesto — Fri, 17 May 2024 22:01:33 +0000

Hoje quero falar sobre um tema importante quando falamos em segurança de dados e o que podemos fazer para melhorar a nossa segurança de dados quando processamos imagens com dados sensíveis de nossos usuários. Vou apresentar uma solução que construí pensando nessa situação. Vamos nessa 😃

Imagens e Dados Sensíveis

A crescente capacidade de processamento e armazenamento de dados permitiu que empresas capturassem e analisassem um volume imenso de informações, muitas vezes sem o consentimento explícito dos indivíduos envolvidos.

Em termos de cibersegurança, a proteção de dados pessoais em imagens é de suma importância. O vazamento de informações sensíveis, como CPF e e-mail, pode ter consequências desastrosas. Criminosos cibernéticos podem utilizar essas informações para realizar fraudes, roubo de identidade e outras atividades ilícitas. Por exemplo, com um CPF e um endereço de e-mail, um criminoso pode tentar abrir contas bancárias em nome da vítima, solicitar empréstimos ou realizar compras online, tudo isso sem o conhecimento da pessoa afetada.

Além disso, a exposição de dados pessoais pode levar ao assédio e à violação de privacidade. Imagine uma situação onde fotos de uma reunião ou evento são compartilhadas publicamente e nelas estão visíveis documentos ou identificações pessoais. Essas informações podem ser exploradas maliciosamente, comprometendo a segurança e o bem-estar das pessoas envolvidas.

Então, o que fazer?

Sabemos que dados sensíveis em imagens podem ser um problema, então, o que fazer? Anonimizar!

A anonimização de dados em imagens tornou-se uma prática crucial nos dias atuais, especialmente com o crescimento exponencial da coleta de dados por grandes empresas para treinar inteligências artificiais (IA).

Portanto, a anonimização de dados em imagens é uma prática essencial não apenas para proteger a privacidade individual, mas também para garantir a segurança cibernética. Com a intensificação da coleta de dados por grandes corporações para o treinamento de IA, a adoção de medidas rigorosas de anonimização torna-se ainda mais crítica. É responsabilidade das empresas e desenvolvedores implementar técnicas eficazes para garantir que os dados pessoais sejam adequadamente protegidos, preservando a privacidade e a segurança dos indivíduos em um mundo cada vez mais digitalizado.

Anonimizar dados em imagens envolve a remoção ou ocultação de informações identificáveis, como rostos, placas de veículos, endereços de e-mail, números de CPF, entre outros. Essa prática é vital para proteger a privacidade dos indivíduos, impedindo que dados pessoais sejam facilmente associados a pessoas específicas. Com a anonimização, mesmo que as imagens sejam acessadas por terceiros, a possibilidade de identificar e prejudicar os indivíduos retratados é significativamente reduzida.

Com isso queria trazer uma API que construí pensando em viabilizar a anonimização de dados em imagens de forma sistemática.

Ela possui os seguintes endpoints em sua versão V1:

/v1/remove/all: Este endpoint remove todos os textos encontrados na imagem
/v1/remove/cep: Este endpoint remove todos os ceps encontrados na imagem
/v1/remove/cnpj: Aqui são removidos todos os cnpj's
/v1/remove/cpf: Este endpoint remove todos os cpf's
/v1/remove/custom-text: Aqui são removidos textos específicos que o usuário queira
/v1/remove/email: Remove todos os emails

-/v1/remove/face: Este endpoint remove todos os rostos detectados na imagem

/v1/remove/ipv4: Aqui são removidos os ipv4's que forem encontrados
/v1/remove/phone: Remove todos telefones
/v1/remove/rg: Remove todos os numeros de rg (por enquanto apenas Minas Gerais)

Caso queira acessar a API para checar todas as features e apoiar meu trabalho é só dar uma conferida aqui 😃

==>>>DOCK ANONYMIZE API<<<==

Anonimizando dados

Agora vamos explorar como utilizar a API para anonimizar dados em exemplos de imagens contendo informações sensíveis de usuários.

CPFs
Os CPFs são informações extremamente confidenciais e toda empresa deve garantir que essas informações não sejam vazadas na internet. A seguir, apresentamos um exemplo de anonimização de CPF em uma imagem de um contrato de trabalho. Este poderia ser um documento escaneado real.

Imagem original

Imagem anonimizada

Emails
Os emails também são informações que podem ser divulgadas inadvertidamente. Se for intencional, como na divulgação de um email de contato para um serviço, não há problema. Porém, quando se trata de emails pessoais, existe o risco de que pessoas maliciosas os utilizem para criar cadastros em diversos sites ou até mesmo realizar compras online.

Imagem original

Imagem anonimizada

Mais Exemplos
Agora, vamos ver um exemplo de uma tela de sistema que pode conter informações pessoais do usuário ou da empresa cujo cadastro está sendo acessado.

Perceba que na imagem original existem diversas informações de cunho pessoal, como CNPJ, email, CEP, entre outras.

Imagine que você possui um serviço que lida com muitas imagens semelhantes (por exemplo, um serviço que processa notas fiscais e depois as armazena). Para garantir a segurança das informações do cliente, você pode anonimizar alguns dados. Neste caso, vamos anonimizar campos como email, CNPJ e um valor arbitrário, como o limite de crédito.

Imagem anonimizada

Como pode ser visto é possível anonimizar de forma sistemática dados sensíveis em imagens, garantindo assim, a privacidade dos dados dos usuários.

Casos de uso

Trago aqui mais alguns casos de uso onde pode ser extremamente necessário a anonimização dos dados presentes.

Processamento de Documentos Fiscais
Empresas que lidam com um grande volume de documentos fiscais (notas fiscais, recibos, etc.) podem precisar anonimizar dados sensíveis antes de armazená-los ou compartilhá-los com terceiros.
Segurança em Sistemas de RH
Sistemas de Recursos Humanos que gerenciam documentos como contratos de trabalho, formulários de cadastro de funcionários, e declarações de imposto podem anonimizar informações sensíveis para proteger a privacidade dos funcionários.
Compliance com Regulamentações
Organizações que precisam cumprir regulamentações de proteção de dados (como a GDPR na Europa ou a LGPD no Brasil).
Serviços de Armazenamento em Nuvem
Provedores de serviços de armazenamento em nuvem podem querer oferecer um nível adicional de segurança, garantindo que dados sensíveis em documentos escaneados sejam automaticamente anonimizados antes de serem armazenados.
Aplicativos de Telemedicina
Plataformas de telemedicina que processam imagens de documentos médicos (receitas, laudos, etc.) podem anonimizar dados pessoais dos pacientes para proteger a privacidade e garantir a segurança das informações médicas.
Gestão de Imóveis
Empresas de gestão imobiliária podem querer anonimizar dados sensíveis em documentos como contratos de aluguel e comprovantes de residência antes de compartilhá-los com partes interessadas.
Bancos e Instituições Financeiras
Bancos podem anonimizar dados em imagens de documentos financeiros (extratos bancários, contratos de empréstimo) para proteger a privacidade dos clientes ao realizar auditorias ou ao compartilhar informações internamente.
Sistemas de Educação
Instituições de ensino podem anonimizar dados em documentos estudantis (boletins, registros acadêmicos) ao compartilhar informações com terceiros ou ao armazená-las de forma segura.
Agências Governamentais
Agências governamentais podem anonimizar dados em documentos oficiais (identidade, passaportes, declarações de imposto) antes de processá-los ou arquivá-los para garantir a privacidade dos cidadãos.
Aplicações Jurídicas
Escritórios de advocacia e tribunais podem precisar anonimizar informações sensíveis em documentos legais (petições, contratos, depoimentos) para proteger a privacidade das partes envolvidas.
Plataformas de Crowdsourcing
Plataformas que utilizam crowdsourcing para processamento de dados podem anonimizar informações sensíveis em documentos submetidos pelos usuários para garantir a segurança e privacidade durante o processo de revisão.
Serviços de Análise de Dados
Empresas que oferecem serviços de análise de dados podem anonimizar informações sensíveis em documentos antes de realizar análises, garantindo que nenhum dado pessoal seja comprometido.

Conclusões

Com isso podemos ver que em várias situações pode ser bom, e até necessário, a anonimização de dados em imagens, principalmente quando falamos de documentos.

Se você trabalha com iamgens que podem conter dados sensíveis sempre considere a anonimização dos dados pois assim você colabora para a privacidade dos dados de seus usuários, além de evitar possíveis multas ou outros problemas decorrentes de vazamentos de dados 💯

Bom por hora é isso, fiquem bem e até a próxima 🙂

Otimizando Wordlists para Pentests

Ronaldo Modesto — Sat, 02 Mar 2024 20:48:12 +0000

Olá, espero que este artigo encontre você e seus familiares todos bem e cheios de saúde 🙂.
Hoje vamos falar sobre ataques de força bruta e como otimizar as wordlists utilizadas para conseguir ser mais assertivo em seus testes.
Sem mais delongas, bora lá 💯.

Responsabilidade

Antes de mais nada quero deixar bem claro que fiz esta ferramenta pensando em auxiliar pentesters e pessoas que queiram realizar estes testes em seus próprios sistemas.
O que você fizer com ela é responsabilidade única e exclusivamente sua, ok?

O que é um ataque de força bruta (Brute Force Attack)

Primeiro vamos começar definindo o que é um ataque do tipo brute force e em quais casos ele geralmente é utilizado.

Um ataque de força bruta é um método de tentativa e erro usado para descobrir uma senha o chave criptográfica ao testar todas as combinações possíveis em rápida sucessão. Geralmente, esse tipo de ataque é automatizado através de programas ou scripts que tentam todas as combinações de caracteres, números e símbolos em uma sequência exaustiva até que a senha correta seja encontrada.

Os ataques de força bruta são comumente usados em situações em que um invasor deseja obter acesso não autorizado a sistemas protegidos por autenticação baseada em senha. Alguns casos típicos de uso incluem:

Quebra de senha: Tentar descobrir a senha de uma conta de usuário ou administrador em sistemas online, como redes sociais, e-mails, bancos de dados, entre outros.
Quebra de criptografia: Tentar quebrar chaves criptográficas ao decifrar mensagens ou arquivos criptografados.
Descoberta de chaves de segurança: Tentar encontrar a chave de segurança de uma rede sem fio protegida por criptografia WEP, WPA ou WPA2.
Acesso não autorizado a sistemas: Tentar ganhar acesso não autorizado a sistemas, servidores ou dispositivos protegidos por senha, como roteadores, firewalls, etc.

Em resumo, ataques de força bruta são uma técnica de invasão que explora a vulnerabilidade de senhas fracas ou algoritmos de criptografia ineficientes, visando obter acesso não autorizado a sistemas e informações sensíveis.

Wordlists e sua importância neste tipo de ataque

As wordlists desempenham um papel crucial nos ataques de força bruta, fornecendo uma lista predefinida de palavras ou combinações de caracteres que são usadas como tentativas durante o processo de tentativa e erro para descobrir uma senha ou chave.

Essas listas podem conter uma ampla variedade de informações, incluindo:

Palavras comuns: Palavras frequentemente usadas em senhas, como "password", "123456", "qwerty", entre outras.
Dicionários de idiomas: Palavras de dicionários de diferentes idiomas são frequentemente incluídas, pois muitas pessoas usam palavras do seu próprio idioma como senha.
Combinações de caracteres: Sequências de caracteres como números, letras maiúsculas e minúsculas, símbolos, e suas combinações.
Padrões: Sequências de caracteres que seguem padrões comuns, como datas de nascimento, nomes próprios, palavras seguidas de números, entre outros.
Ao usar uma wordlist durante um ataque de força bruta, o processo de tentativa e erro é agilizado, pois o atacante não precisa gerar as combinações de caracteres manualmente, aumentando as chances de sucesso.

O lado ruim...

Bom como sabemos bem, tudo na vida tem um preço 😅.
Neste caso o lado ruim desse tipo de ataque é o tempo!! Existem vários tipos de wordlists por ai e seus tamanhos variam de algumas linhas a milhões de registros. Dependendo do poder de processamento do seu alvo, no caso de um teste de brute force contra algum serviço, ou do poder de processamento de seu computador no caso de ser um brute force local, a conclusão desse teste pode durar horas ou até mesmo dias!! O que por mais que você tenha tempo disponível para isso é meio complicado esperar horas para descobrir que a senha que você procura não está naquela wordlist. Se por um lado wordlists maiores aumentam a chance de sucesso, por outro elas aumentam também o tempo de execução do teste, e isso algo que definitivamente não queremos.
Então o que podemos fazer ? Bom aí vem uma coisa chamada OsInt 🙂

Osint

OSINT (Open Source Intelligence),ou inteligência de fontes abertas, refere-se à prática de coletar e analisar informações de fontes disponíveis ao público para obter insights e conhecimentos úteis. Essas fontes podem incluir redes sociais, sites da internet, fóruns online, notícias, registros públicos, e qualquer outra informação acessível ao público em geral, sem a necessidade de técnicas de invasão ou acesso não autorizado.
Ou seja, significa tentar descobrir características que podem ser utilizadas para inferir informações acerca da senha ou dado que você busca. Trazendo isso para um contexto de pentest, imagine que você deseja testar a segurança de um site x, e você vai tentar fazer um brute force para ver como está a segurança das senhas dos usuários.

Se você pegar uma wordlist genérica de 5 milhões de senhas, você pode acabar demorando demais e consumindo muito recurso de processamento para, no fim, não achar nenhuma senha que batesse para determinado login. Porém, você, como um bom pentester, resolveu ir lá no site e dar uma olhadinha para ver se conseguia descobrir algo sobre a senha daquele site. Você tenta criar uma conta e quando é questionado sobre a senha, insere uma senha qualquer e boom! O site te retorna uma mensagem dizendo que as senhas que ele aceita possuem um formato específico, geralmente algo parecido com isso:

Ou seja, sobre esse site x, agora você sabe que não adianta testar senhas como 123, ou teste1234 pois as senhas precisam ter, pelo menos, letras minúsculas, maiúsculas entre outras combinações.
Com isso você sabe que de alguma maneira precisa limpar a wordlist que vai ser utilizada senão tudo que vai conseguir é perder tempo. E como podemos fazer isso ? 🤔
Aí vem a uma ferramenta bem bacana, e simples, que fiz pensando nessa situação 🙂.

Wordlist Optimizer

Pensando nessa situação resolvi aproveitar que estou iniciando meus estudos em Go, que é uma linguagem compilada e por isso gera programas que possuem excelente performance, e criei uma ferramenta bem simples para ajudar nessa tarefa.
Basicamente o wordlist optimizer é uma cli ( programa de linha de comando) que filtra dados de uma worldlist baseado em um filtro que você monta passando algumas flags como por exemplo, -l para letras minúsculas , -c para lestras maiúsculas, entre outras opções. A documentação completa você encontra no repositório da ferramenta no github WorlistOptimizer.
Com ela você pode criar filtros para selecionar apenas linhas que atendam, minimamente, ao que você quer.
No exemplo a seguir eu filtrei a wordlist teste.txt para recuperar apenas as linhas que tivessem letras maiúsculas, números e tamanho mínimo de 5 caracteres. Senhas como teste123, teste3444 ficariam de fora desse filtro e não seriam gravadas no arquivo de saída teste-optimized.txt.
Essa será nossa wordlist teste.txt

Ao terminar de executar a ferramenta exibe as estatísticas do processamento dos dados

Esse é o arquivo gerado com todas dos dados que deram match( minimamente) com o filtro passado.

E esse é o arquivo gerado como complemento do arquivo de match, ou seja, são todos os dados que não deram match.
É importante ter esse arquivo pois quando estamos fazendo pentest real, o as wordlists podem ser muito grandes, na casa de milhões e milhões e as vezes até mais, então é importante ir segmentando seu teste para caso você mude de estratégia já ter esses dados filtrados.

Como vocês podem ver, no arquivo removed-teste.txt estão as senhas que não deram match no filtro.
Com essa simples ação você pode tornar seu teste muito mais efetivo, reduzindo o tamanho da sua wordlist e economizando processamento de seu alvo de testes 😃.

E uma última dica é, sempre que for realizar um pentest e precisar utilizar utilizar um brute force, tome cuidado para não sobrecarregar o sistema de seu cliente, pois como ataques de forças bruta operam através de tentativa e erro, é normal que ele erre muito (mas muuuuuuito) antes de acertar, não é atoa que as wordlists possuem facilmente milhões e milhões de dados. Se conduzido de forma errada o seu teste pode ser mais prejudicial do que um ataque legítimo 😅.

Além disso, deixo aqui uma sugestão para os programadores e arquitetos de software: sempre considerem a implementação de um RATE LIMIT em suas aplicações. Em um cenário de ataque mal-intencionado, é esse rate limit que cuidará para que sua aplicação não seja comprometida. Embora não exista uma solução única em segurança e haja métodos para burlar o rate limit, ter um rate limit configurado em sua aplicação ou WAF (Web Application Firewal) é uma prática recomendada.

Bom por hoje é isso, espero que essa dica e essa ferramenta possam tornar seus testes mais efetivos 🚀. Segue aí para mais dicas 🙂.

Fiquem bem, estudem bastante e descansem a cuca também porque a vida é para ser aproveitada 💯.

Obrigado por chegar até aqui e até a próxima 🚀

Referências

OsInt (Owasp)

BruteForce (owasp)

Exemplos de wordlists (github)

Web Application Firewall (cloudflare)

Protegendo sua API NodeJs contra ReDos Attack[Parte 3]

Ronaldo Modesto — Thu, 26 Jan 2023 16:52:10 +0000

Ok! Vimos o que é uma expressão regular, como utilizá-la, o que é um ReDos e como podemos resolver esse problema!

Caso você tenha caído aqui de paraquedas, seguem os links para as duas primeiras partes desse artigo:
Parte 1 (Definição do problema)
Parte 2 (Construção de uma possível solução)

Agora chegou a hora de testar nossa solução e fazer algumas considerações acerca da mesma. Bora ver se o que construímos de fato funciona ? 🙂

Primeiramente vamos executar o mesmo teste que fizemos quando utilizamos a abordagem que acabava travando toda a nossa API.
Conforme podemos ver a seguir, ao utilizar o mesmo payload que causou problemas anteriormente, dessa vez nosso sistema não sofreu com nenhum impacto pois a thread que acabou travando foi a thread da micro vm que criamos, e dado que acabou gerando um timeout, nós apenas recebemos uma mensagem dizendo que um timeout ocorreu, mas nossa API segue firme e forte 💪.

Nosso endpoint de teste de responsividade também continua a todo vapor.

Ok vimos que de fato nossa API não está mais travando quando recebe um payload malicioso. Porém temos que nos fazer seguinte pergunta, Ok, funcionou, mas essa solução é escalável?, sempre que implementamos uma solução para um dado problema.

Então vamos testar a responsividade de nossa API sob alta carga e para isso vamos usar uma ferramenta de teste de carga chamada K6.

O K6 é uma ferramenta utilizada para testar aplicação com diferentes cenários de teste de carga(teste de absorção, teste de estresse dentre outros). É uma ótima ferramenta e sugiro, para aqueles que não a conhecem, ler mais a respeito desse carinha. Clique aqui e conheça o K6.

A seguir temos o nosso arquivo de teste de carga. É um teste simples, basicamente vamos testar nossa API contra uma quantidade considerável de requisições simultâneas e ver como ela se comporta no que diz respeito à memória e uso de CPU.

import http from "k6/http";
import { check, sleep } from "k6";

export const options = {
  stages: [
    { duration: "2m", target: 250 }, // Simula um aumento de 0 até 100 requisições, em um período de 2 minutos
    { duration: "2m", target: 300 }, // Permaneçe em 300 requisições por 2 min
    { duration: "1m", target: 0 }, // Desce para 0 requisições ao longo de 1 minuto
  ],
};

const BASE_URL = "http://192.168.2.176:3000"; // Aqui eu coloquei o ip do computador que estava rodando a api, utilizei um outro computador para rodar o teste para garantir que não haveriam interferências

export default () => {
  const headers = { "Content-Type": "application/json" };

  // Primeiro envio um payload malicioso, simulando um ataque
  const maliciusPatternResult = http.post(
    `${BASE_URL}/validate-form-safe`,
    JSON.stringify({
      email: "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa@gmail.com",
      password: "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
    }),
    { headers: headers }
  );

  // Verifico para ver se recebi um timeout como resposta
  check(maliciusPatternResult, {
    "Bad-request-blocked-successfully": (response) => {
      return (
        JSON.parse(response.body).message === "Email ou senha são inválidos"
      );
    },
  });

  // Depois envio um payload válido paar verificar se a api está funcionando como deveria e não foi prejudicada pelo payload malicioso enviado anteriorment

  const validPatternResult = http.post(
    `${BASE_URL}/validate-form-safe`,
    JSON.stringify({
      email: "email-valido@gmail.com",
      password: "ab.cd.Zz",
    }),
    { headers: headers }
  );

  // Aqui verifico a resposta para checar se a resposta foi correta
  check(validPatternResult, {
    "Valid-Pattern-Accepted-successfully": (response) =>
      JSON.parse(response.body).isValidForm === true,
  });

  // Por fim faço uma requisição para o endpoint de checagem da api, para ver e ele ainda está respondendo
  const serverCheckResponse = http.get(`${BASE_URL}/test-server`).json();

  // e verifico se ele de fato está ativo
  check(serverCheckResponse, {
    "servidor responsivo": (obj) =>
      obj.message === "Servidor está respondendo normalmente",
  });

  sleep(1); // apenas um pequeno timer entre uma iteração do teste e outra
};

Após rodar o teste de carga em outro computador para não afetar o desempenho de nossa API, utilizando um computador com processador de 4 núcles e 8GB de RAM, além de ter subido a nossa API utilizando o gerenciador de processos PM2 que consegue subir as aplicações NodeJs em forma de cluster, caso não conheça o PM2, clique aqui e confira, consegui uma taxa de 300 request/segundo o que é um resultado considerável considerando o que computador não era muito forte e considerando que internamente o nodeJs tem sim um overhead a mais para executar esse script em um contexto separado. Cumprimos nosso objetivo 🙂.

Considerações e dicas

Essa solução que foi apresentada aqui é extensível para outras tarefas que podem ser bloqueantes, (cálculo de hashes por exemplo). Se você não tem certeza de que aquela operação será rápida ou se pode ou não ser bloqueante, a solução apresentada neste artigo pode ser uma forma de garantir que seu sistema não irá travar.

Aqui vão algumas dicas que podem ajudar a manter essa falha longe de suas APIs NodeJs.

Não escreva sua própria regex: Evite criar suas próprias reges, principalmente se você não for expert em expressões regulares, pois a chance de você acabar criando um regex com essa falha é muito grande.
Use expressões regulares já prontas e validadas: Essa é um complemento à dica 1. Se precisar validar algo procure por expressões regulares que já foram validadas contra esse tipo de falha, e até mesmo outras falhas.
Use validadores: Existem validadores já pronto que podem validar uma grande variedade de padrões e é muito provável que já exista um validador para o que você quer. Por exemplo:
Validator.js
Safe Regex
Redos Detector
Valide sua regex caso precise fazer uma: Se você de fato precisar construir sua própria expressão regular então tente validá-la para saber se ela está vulnerável a essa falha. Alguns são:
Devina
RedosDetector
Recheck

E por fim, a mais importante dica de todas 🙂

Entenda o que ela está fazendo!!! Estude sobre a expressão que você quer usar, identifique o que ela está reconhecendo e como ela o está fazendo, estude expressões regulares para que você pelo menos consiga dizer o que aquela expressão está validando.

E esse conselho se estende a todas as coisas que você precisar utilizar, evite copiar e colar coisas sem saber o que aquilo está fazendo pois você pode acabar inserindo brechas de segurança em seu sistema 🙂.

Bom por hoje foi isso pessoal, espero que esse artigo lhe ajude de alguma forma, fiquem com Deus e ate a próxima 🙂.

DEV Community: Ronaldo Modesto

Using local LLMs in API log analysis for near real-time attack detection

1. Introduction

2. Proposed Approach and Objectives

Why not just Regex and signatures?

Scope: this is a PoC

3. Technology Stack

Execution platform: Ollama

Model used: qwen2.5-coder:1.5b

Hardware configuration

Language and main libraries

4. Architecture and Project Structure

Macro role of each component

5. Agent Configuration and Behavior

The persona: a senior security analyst

The structured output

6. Experiment Methodology (Execution Flow)

Step 1 — Starting the target API

Step 2 — Starting the Agent Monitor

Step 3 — Running legitimate traffic

Step 4 — Running the simulated attacks

Step 5 — Observation, collection, and analysis

7. Observed Results and Critical Analysis

Experiment summary

Global severity distribution

Detections by attack type

Coverage by analysis window

Critical analysis of the data

8. Pros and Cons of the Approach

Pros

Cons

9. Conclusion and Next Steps

Next Steps: evolving the PoC with Vector DB / RAG

CrewAi Docs

OWASP Top 10 API

Ollama

Prompt Engineering Guide by Google

Protocols Visualizer: An Interactive Way to Learn Network Protocols

Safeinstall: Um aliado no combate a ataques de Supply chain

A Crise de Segurança na Cadeia de Suprimentos Open Source

O que é o SafeInstall ✅?

Benefícios Principais

Como Instalar 💥

Pré-requisitos

Instalação por plataforma

Comandos e Uso

Sintaxe básica

Instalação de pacote único

Instalação em lote (npm i, pip install -r, etc.)

Modo CI/CD

Desinstalação

Ecossistemas Suportados

Como o SafeInstall Reduz o Risco de Supply Chain

Requisitos

- Go e osv-scanner no PATH (para instalações em lote)

Como Funciona Supply Chain Attack -PTBR

Introdução

O que é um Supply Chain Attack?

Scripts de Lifecycle: A Porta de Entrada

Projeto de Demonstração: Estrutura e Código

Estrutura do Pacote Malicioso

Script preinstall.js

Script postinstall.js — O Coração do Ataque

Fluxo do Ataque

Consequências em Ambientes Reais

1. Exfiltração de Credenciais e Segredos

2. Roubo de Chaves SSH e Certificados

3. Cryptojacking

4. Backdoors e Persistência

5. Modificação de Outros Pacotes

6. Em Ambientes CI/CD

Casos Reais Documentados

Medidas de Proteção

Conclusão

How Supply Chain Attacks Work

Introduction

What is a Supply Chain Attack?

Lifecycle Scripts: The Entry Point

Demonstration Project: Structure and Code

Malicious Package Structure

Model used: `qwen2.5-coder:1.5b`