APT attack simulation
and red teaming
An APT attack simulation is a controlled attack in which, over 4-8 weeks, we replicate the techniques of a threat group that targets your industry. A pentest shows where the vulnerabilities are. A simulation tests whether your team spots a stealthy attacker and stops them before they reach your most valuable data.
- Realistic attack vectors: phishing, custom tooling, AV and EDR evasion
- Measuring the response time of SOC and IR teams
- An operation supervised by a control team on your side
What is an APT attack simulation
An APT attack simulation replicates an APT group's attack under controlled conditions, based on the techniques of groups active in your industry, and measures whether and when your team detects it. An APT (Advanced Persistent Threat) is a well-prepared group, often state-sponsored, that attacks a chosen organization for weeks or months. It gets in quietly, keeps its access and hunts for specific data.
What an APT attack simulation covers
We don't stop at technology. We also test people, procedures and physical security, because an attacker picks the weakest link, and that isn't always a server.
Social engineering, OSINT and deepfakes
We gather publicly available information about your company and run targeted phishing, vishing and smishing campaigns against the board and staff in finance, IT and customer service. We also check whether the helpdesk resets MFA on a phone request and how people react to a deepfake: a cloned voice on a call or video in an online meeting. We always run deepfake tests with the consent of the person being impersonated.
From our research: spoofing an email senderAPT tradecraft emulation
We use our own C2 (Command & Control) software that tries to evade AV and EDR. This shows how those systems cope with an adversary who doesn't rely on off-the-shelf, well-known tools.
Supply chain attack via a trusted supplier
We check whether your IT suppliers' and partners' access is limited and monitored. We show whether you would notice an attacker coming in through a trusted supplier's account or connection.
Network security bypass
We check whether WAF, IPS/IDS and proxy servers stop attacker traffic hidden among the company's normal traffic.
More on external infrastructure penetration testingActive Directory and lateral movement (assumed breach)
We assume the attacker already has access to an employee's workstation. We check how far they get with a regular user's privileges, up to taking over the Domain Admin account.
More on internal infrastructure penetration testingPhysical security breach
On request, we also test the physical security of your offices: cloning RFID and NFC access cards, getting onto the premises and plugging a rogue device into the LAN.
Purple teaming
Our red team and your blue team work side by side. We run one technique at a time and tune detection rules on the spot until your SOC catches each one.
SOC team testing
The goal isn't a list of vulnerabilities. We check whether your monitoring (logs, SIEM) picks up an ongoing attack and how your security team responds.
Narrower simulation variants
A full operation takes 4-8 weeks. When you want to test one specific scenario, choose a shorter variant.
An assumed breach test starts inside your network, from a hijacked workstation, account or VPN. See how far an attacker gets and whether your SOC notices.
See the variantRansomware simulation: we test whether an attacker can reach your domain controller and backups and whether EDR and your SOC respond. Takes 2-4 weeks.
See the variantPentest, red team or TLPT
An APT attack simulation is not the same as a penetration test. They differ in objective, scope and who in the organization knows about the test.
| Criterion | Penetration test | Red teaming | APT emulation | Purple teaming | TLPT (DORA) |
|---|---|---|---|---|---|
| Objective | Find vulnerabilities in a defined scope | Test the team's response to a realistic attack | Replicate the techniques of a specific APT group | Collaboratively improve attack detection | DORA-mandated resilience test of critical functions |
| Scope | Selected segment, e.g. application, network or API | The whole organization: people, systems and premises | Techniques from a threat profile, e.g. APT28 | Scenarios agreed with the blue team | Critical or important functions, production systems |
| Blue team aware? | Usually yes, the test is announced | No, only the control team knows | No, the goal is to see how defenders really respond | Yes, red and blue teams work together | No, a control team coordinates the test |
| Starting point | A list of IPs or applications to test | Just the company name, like a real attacker | Scenarios from a sector threat analysis | SIEM/EDR rules to validate | Scenarios from threat intelligence |
| Duration | Depends on scope | 4-8 weeks | 4-8 weeks | Depends on scope | At least 12 weeks of active testing (RTS 2025/1190) |
| Outcome | A vulnerability list with risk ratings | An attack timeline and an ATT&CK technique map | Detection coverage mapped to the group's techniques | Improved detection rules and response procedures | Test reports and a supervisory authority attestation |
- Objective
- Find vulnerabilities in a defined scope
- Scope
- Selected segment, e.g. application, network or API
- Blue team aware?
- Usually yes, the test is announced
- Starting point
- A list of IPs or applications to test
- Duration
- Depends on scope
- Outcome
- A vulnerability list with risk ratings
- Objective
- Test the team's response to a realistic attack
- Scope
- The whole organization: people, systems and premises
- Blue team aware?
- No, only the control team knows
- Starting point
- Just the company name, like a real attacker
- Duration
- 4-8 weeks
- Outcome
- An attack timeline and an ATT&CK technique map
- Objective
- Replicate the techniques of a specific APT group
- Scope
- Techniques from a threat profile, e.g. APT28
- Blue team aware?
- No, the goal is to see how defenders really respond
- Starting point
- Scenarios from a sector threat analysis
- Duration
- 4-8 weeks
- Outcome
- Detection coverage mapped to the group's techniques
- Objective
- Collaboratively improve attack detection
- Scope
- Scenarios agreed with the blue team
- Blue team aware?
- Yes, red and blue teams work together
- Starting point
- SIEM/EDR rules to validate
- Duration
- Depends on scope
- Outcome
- Improved detection rules and response procedures
- Objective
- DORA-mandated resilience test of critical functions
- Scope
- Critical or important functions, production systems
- Blue team aware?
- No, a control team coordinates the test
- Starting point
- Scenarios from threat intelligence
- Duration
- At least 12 weeks of active testing (RTS 2025/1190)
- Outcome
- Test reports and a supervisory authority attestation
Order a simulation if:
- You have a SOC or security team and want to check whether it spots a real attack
- You already run penetration tests and have fixed the findings from the last report
- You want to measure incident response time before a real one happens
- Your entity falls under DORA and the KNF (Polish Financial Supervision Authority) may designate it for TLPT
Start with a pentest if:
You do not have monitoring or regular penetration tests yet. A full simulation against a company with no detection baseline reaches a single conclusion: the attacker gets through unnoticed. Close the known gaps first, or start with the assumed breach variant, where we begin from a compromised workstation.
See penetration testingDORA, TLPT and NIS2
DORA and TLPT
Under DORA (Art. 26), financial entities designated by the supervisory authority (in Poland, the KNF) must carry out advanced testing in the form of threat-led penetration testing (TLPT), as part of the testing program under Art. 24(6). The active red team phase lasts at least 12 weeks (RTS 2025/1190, Art. 11(5)). PWNONE meets the tester requirements of DORA Art. 27, holds professional liability insurance and has its own threat intelligence team, separate from the red team.
NIS2 and the KSC Act
Neither NIS2 nor the Polish National Cybersecurity System Act (KSC Act) explicitly requires red teaming. An attack simulation is, however, one way to assess how effective your risk-management measures are, as required by Art. 21(2)(f) of the NIS2 Directive and by Art. 8(1)(2)(h) and Art. 15 of the KSC Act (Journal of Laws of 2026, item 252).
Who attacks Polish companies
Poland is a regular target for APT groups. In its 2025 report, CERT Polska names UNC1151 (Ghostwriter) as one of the most active groups targeting Polish entities. The group ran credential-theft campaigns exploiting CVE-2024-42009, a flaw in Roundcube. APT28 also exploited the same flaw against Polish targets.
Sources: CERT Polska Annual Report 2025 (NASK); M-Trends 2026 (Mandiant, Google Cloud).
“We have several such incidents a week in Poland”
How the operation runs
A controlled process, not a surprise attack. Every stage is agreed before we start.
A conversation about goals
We agree what the operation should test and what matters most for you to protect.
Threat analysis
Our threat intelligence team, separate from the red team, picks the scenario based on groups active in your industry.
Rules and safeguards
We sign an authorization and rules of engagement (RoE). We agree the control team, stop conditions and systems excluded from scope.
The operation
We work quietly, in stages, like a real attacker. The control team can pause the operation at any time.
Report and workshop
We hand over the report and go through it in a workshop with your security team.
Retest included
After you apply the fixes we come back and check the gaps are closed. One retest is included in the price.
- detected
- detected late
- not detected
- ReconnaissanceWeek 1-2: not detected
- Initial accessWeek 2-3: detected late
- Lateral movementWeek 4-7: detected
- ObjectiveWeek 7-8: not detected
Scenario: a fake invoice
A fictional financial-sector company, 500 employees, in-house SOC. All technique IDs come from MITRE ATT&CK.
| # | Attacker action | Detection opportunity | MITRE ATT&CK |
|---|---|---|---|
| 1 | 1Positions themselves between the employee and the login page (adversary-in-the-middle) and impersonates the invoicing portal. | A login on an unusual domain, outside the list of known applications. | T1557 |
| 2 | 2Hijacks the active session and signs in without entering a password or an MFA code. | A valid session from a new IP and device, with a User-Agent header change. | T1539 |
| 3 | 3Creates a mailbox rule that hides replies from the genuine business partner. | A new rule that moves or flags messages, recorded in the mailbox audit log. | T1564.008 |
| 4 | 4From the compromised mailbox, sends an invoice with a changed account number and an amount that matches the payment history. | An email from an internal mailbox to an external partner, with an account number not seen in earlier payments. | T1657 |
In the simulation we stop at the agreed objective: we don't modify any data and no money is transferred. We measure the stage at which monitoring detected the attacker.
Based on:
Want to know at which stage your SOC would notice this attack?
What we measure and what you get
Attack timeline
The course of the operation with the points where it could have been detected.
MITRE ATT&CK map
The techniques used plotted on the matrix, with a detection-coverage assessment.
SIEM and EDR recommendations
Concrete rules to tune so that next time the attack is caught earlier.
Workshop with your team
A joint review of the operation with your blue team, technique by technique.
What we measure
- 1Time from attack to first detection by monitoring (dwell time)
- 2Which techniques succeeded and which your SOC caught
- 3Response time from detection to action by the team
We map every operation scenario to the MITRE ATT&CK Enterprise matrix (v19.2, 15 tactics). Afterwards we show which techniques went unnoticed and which your team caught. That gives concrete data for tuning SIEM and EDR rules.
Your red team
After the operation we sit down with your team over the timeline and show every moment we could have been caught. For me the test succeeded if your SOC then detects what it could not see before.
Team certifications
- OSCE3: Offensive Security Certified Expert 3
- OSEP: Offensive Security Experienced Penetration Tester
- OSED: Offensive Security Exploit Developer
- OSWE: Offensive Security Web Expert
- OSWA: Offensive Security Web Assessor
- OSCP: Offensive Security Certified Professional
- BSCP: Burp Suite Certified Practitioner
- OSWP: Offensive Security Wireless Professional
Frequently asked questions
How does red teaming differ from penetration testing?
A penetration test looks for vulnerabilities in a defined scope, and the defense usually knows about it. Red teaming simulates a whole attack without warning the defense and tests whether your team detects it.
Pentest, red team or TLPTHow does an APT simulation differ from a red team operation?
An APT simulation replicates the techniques of one group, e.g. APT28, described in its MITRE ATT&CK profile. Choose it to test detection of specific techniques. Red teaming picks methods for your company, without mimicking one group, and shows your company's weakest points.
How long does an APT attack simulation take?
An APT attack simulation usually takes 4-8 weeks, like a typical red team operation. The exact duration depends on the number of scenarios and scope. A TLPT required by DORA is longer: the active red team phase alone is at least 12 weeks.
How much does an attack simulation cost?
The price depends on the number of scenarios, the operation's duration, whether it includes physical, vishing and deepfake tests, and regulatory requirements such as TLPT. Describe the scope in the form; we will call back to confirm details and send the scope of work and a price range within two business days.
Is red teaming legal?
Yes. We work under written authorization from the system owner and signed rules of engagement (RoE). These documents are prepared before the operation and describe the scope, exclusions and stop conditions.
Is the simulation safe for production systems?
Yes. The control team on your side can stop the operation at any time, and systems you designate are excluded from scope.
How the operation runsDoes the IT team or SOC know about the test?
In red teaming, APT emulation and TLPT, no. Only the control team on your side knows about the operation, because we measure the response to a real attack. In purple teaming your team works with us from day one.
What do I get after an APT attack simulation?
An attack timeline with detection points, a MITRE ATT&CK map, SIEM and EDR recommendations, a workshop with your team and one retest included.
What we measure and what you getDoes red teaming make sense if I don't have a SOC?
Yes, in the assumed breach variant. We skip the phishing phase and start from a compromised workstation. We check how far an attacker gets in the network without monitoring. The result shows which gaps to close before you invest in a SOC or MSSP.
Is my entity subject to mandatory TLPT?
The TLPT obligation is imposed by DORA (Art. 26). The entity is designated for testing by the supervisory authority, in Poland KNF, by decision under Art. 18zk of the Act on financial market supervision. Under RTS 2025/1190 (Art. 2(2)) this covers, among others, systemically important banks (G-SII and O-SII), large payment and e-money institutions, central securities depositories (CSD), central counterparties (CCP), selected trading venues and larger insurers. If you are unsure, ask your compliance officer or contact us.
Check whether your team detects a real attack
Tell us about your organization and we will propose a simulation scope tailored to your industry.
Book a call about an attack simulation