Approach

From attack path to retest.

We plan the work backward from the asset an attacker would target. We find the path to it. We harden controls with you. A retest shows the fix blocks the path.

Four Contacts: our model inspired by the stages of an eclipse.

  1. C1First contact

    Critical assets

    Together we identify the data and processes to protect. This may be payment approval or customer data. We define scope and success criteria based on these assets.

  2. Authorization

    Scope, testing windows, and contacts are approved in writing. For third-party hosted systems, that party's approval is also obtained.

  3. C2Second contact

    Execution

    Instead of listing weaknesses individually, we chain them. This shows which flaw is part of a path to a critical asset.

  4. Step log

    Every step is logged with a timestamp. Your teams can compare the log with their own records. The retest repeats the same steps exactly.

  5. MAXTotality

    Prioritization

    Priority is set not only by a finding's score but also by its place on the path to a critical asset. The report highlights fixes that block the most paths.

  6. Detection comparison

    We show attack steps and your defense's response on a single timeline. Unseen steps are revealed there. Missing log sources and detection rules are identified from this list.

  7. C3-C4Egress

    Hardening

    We plan fixes with your teams. A configuration, a permission, or a line of code may change. Each change is linked to the path it blocks.

  8. Retest and closure

    We repeat the logged steps. If the attack proceeds by another path, that is visible too. We remove accounts and access created during the work and record the removal.

Reporting standard

Validated paths are marked separately from those only modeled. Areas not tested are listed with reasons.

Data security

Passwords and keys captured during the work are masked in the report. Client information is never used in any publication without permission.

Frequently asked questions

How does a Red Team operation differ from a penetration test?

A penetration test shows which weaknesses exist in defined systems. A Red Team operation tests if a critical objective can be reached and whether your defense detects it.

Do we need to share source code for a code review?

Yes, access to the relevant code is required. If code cannot be shared, we review the compiled software by reverse engineering. Testing the running application is also an option.

Can testing be done in production?

Yes. Red Team operations are usually conducted in production, as real attacks occur there. Tests that could change data are run in a test environment or maintenance window.

How long does a project take?

It depends on the scope. A Red Team operation tries to remain undetected, so it takes longer than a penetration test of the same systems.

Do you retest after fixes?

Yes, for the agreed fixes. The retest checks if the fix also closes other instances of the same flaw.

Can we engage you for a single service?

Yes. Each service can be delivered independently, with its own scope.

Can we engage you for consulting only, without testing?

Yes. We can support security architecture or ISO/IEC 27001 readiness without testing. If you wish, we can verify the result with a test later.

How do we know which service to start with?

In the first meeting, we discuss the assets you want to protect and what prompted the need. This may be an audit, cloud migration, or a past incident. We then recommend the appropriate service and scope.

Will you guarantee that we are secure afterward?

No. An assessment shows what was found within a defined scope and period. Finding no weaknesses does not mean there is no risk.

The first step is a short meeting.

Let's assess the assets you want to protect and your priorities together. Let's define the service and scope that fit your needs.

Schedule a Meeting