Engage Labs

We are a small offensive and research team. When you hire us, you get the people who find the bugs, not the people who manage them.

We like strange behaviour, ugly edges and problems that do not fit standard cybersecurity services.

If you have one hard security problem and you want someone to break it, understand it and explain it clearly, this is what we do.

Our only service

Deep Threat Research Sprint

You bring us one hard problem.

We spend a short, intense period going as deep as needed.

You leave with a clear threat model, proof of impact and concrete actions.

What this is for

This is not a generic cybersecurity service.

Good fit if at least one of these is true for you:

  • You own a product, platform or tech stack and you feel something is wrong but cannot prove it
  • You had an incident or weird behaviour and your current tools and vendors cannot give you a good answer
  • You want to know if there is a new class of attack hidden in one feature, protocol or workflow
  • You are ready to fix and improve things if we show you real risk

If you just need a checkbox pentest, standard red team or basic DFIR, ITRES already does that in other services.

LABS is for the cases that do not fit.

What you’ll decide at the end

By the end of the sprint you should be able to answer:

  • Is this real risk or just noise? How quickly can it impact you?
  • What is the shortest realistic attack path? Are there other attack paths you should consider?
  • What should you change first (code, configuration, logging, detections)?

What problem we solve

Typical questions that fit a Deep Threat Research Sprint:

  • “Can my product security countermeasures be bypassed or exploited?”
  • “Does this new feature hide a takeover path?”
  • “Can this business process leak data or internal artifacts?”
  • “Is this strange behavior actually a new technique, and how would a real attacker use it?”

This is the same type of work behind our public research on:

How a sprint works

We keep it simple. One sprint, one problem.

  1. Understand
    • Short calls and document review
    • We agree on the exact question and the scope of the sprint
    • Access to lab environment, test accounts or sample data if needed
  2. Break and map
    • We try to abuse the feature, protocol or workflow in realistic ways
    • We build safe proof of concept chains where possible
    • We map real impact, preconditions and attacker effort
  3. Explain and harden
    • We write a clear technical report
    • We give you a threat model with concrete attack paths
    • We propose practical fixes, hardening steps and or detections
    • Optional session with your team to walk through everything

Sprints are short by design. Think weeks (2~5 weeks) not months. We work on a fixed-fee, turnkey basis. A typical sprint budget is €15,000–€40,000.

We focus on depth for one problem, not on finding “as many bugs as possible”.

If there is more to explore

Sprints are intentionally narrow.

If we confirm there’s more worth digging into, we can continue with another sprint or, for ongoing collaboration, a limited-seat research partnership.

What you get

At the end of a Deep Threat Research Sprint you get:

  • A clear description of what is really going on
  • Proof of concept material when it is safe and relevant
  • A threat model that your engineers and your CISO can both read
  • A list of concrete changes you can make (configuration, protocol changes, code fixes, extra logging or detections)
  • Optional support text for your customers: security advisory, FAQ or co written blogpost if you want to communicate the work

You also keep all IP and code that we create for you inside the sprint. We only publish anything publicly if you explicitly agree.

Why us?

We do this kind of work on our own time and through unusual situations we encounter in our day-to-day work at ITRES. For example:

  • Turning weird behavior into a full takeover scenario and a CVE
  • Showing how CMS media, sitemaps, or workflow edges leak content teams believe is private
  • Exploring how VPNs, snapshots, or USB can hide attacker activity from standard telemetry

If you want to see how we think and how we write, the public Labs blog is the best sample.

For published/tracked CVEs and our coordination approach, see our Published Vulnerabilities and Disclosure Policy pages.

FAQ

Here is our FAQ. Expand it to answer a whole series of additional questions.

Do you work remotely? Mostly yes. If an engagement requires onsite work (hardware/OT constraints), we’ll discuss it upfront.

Will you sign an NDA before details? Yes, of course.

What access do you typically need? Usually a lab/test environment, test accounts, and/or representative sample data. We’ll scope this during the first call.

Do you always deliver a PoC? Only when it is safe and relevant. Sometimes the right output is a validated attack path plus mitigation guidance, not weaponized code.

Do you publish findings? Not without explicit permission. Default is private.

How do you handle vulnerability disclosure for vendors? We follow coordinated disclosure, typically around a ~90-day window, with exceptions when user risk is high or exploitation is likely.

Can you help us communicate the fix? Yes. We can provide advisory/FAQ text or co-author a post if you choose to go public.

What compliance assurances do you provide? We operate under an ISO/IEC 27001–certified ISMS and hold an ENS High conformity Certificate under Spain’s National Security Framework (ENS). Through these two frameworks, we operate aligned with the NIS2 Directive (Directive (EU) 2022/2555).

How does pricing work? We deliver sprints as fixed-fee, turnkey projects. Most sprints land in the €15,000–€40,000 range for 2–5 weeks (5 weeks max). If it needs multiple researchers, hardware constraints, or onsite travel, the typical fee may increase. Work beyond 5 weeks becomes a new sprint. For non-EU customers, we invoice the EUR fee converted to USD at the applicable exchange rate; other currencies by request.

What if we need more than 5 weeks? A sprint is limited by design to a maximum of 5 weeks. If the problem needs more time, we either run another sprint or move into a limited-seat research partnership for ongoing work.

What is a limited-seat research partnership? It is designed for clients who want ongoing collaboration. It is an annual agreement with an pre-defined workload, at a specific frequency, at our best fixed price, plus guaranteed scheduling and continuity with the same team. The work continues to be delivered in sprints with a scope per sprint. It’s for teams that want our support throughout the year.

How do we start? Send a short description of the system, what you observed, and what you want to decide at the end. We’ll tell you honestly if a sprint makes sense and what a realistic scope looks like.

Let’s talk

Tell us in a few lines:

  • What the system or feature is
  • What you have seen or what you are worried about
  • What you would like to decide at the end of the sprint

We will answer honestly if a Deep Threat Research Sprint makes sense for you
and what a realistic scope would look like.

← Back

Thank you for your response. ✨