Phishing simulation and social engineering

Tailored pretexts

A simulation built on a generic template measures almost nothing: the team learns to recognize the template, not the attack. Our pretexts are built from reconnaissance of what is exposed about your company — what a real attacker would use.

That includes internal vocabulary leaking through job postings, team structure visible on professional networks, publicly mentioned vendors and the industry event calendar.

• Credential harvesting with a cloned page and a believable domain.
• MFA bypass scenarios, including push fatigue and session proxying.
• Attachments and documents framed as an internal process.
• Vishing and phone pretexting, when included in scope.
• Campaigns aimed at specific groups, such as finance or leadership.

What we measure

Click rate is the least interesting metric of the campaign. What matters is what happened after it.

• Time to first report — the indicator that best predicts containment of a real attack.
• Ratio between who reported and who interacted, by department and by campaign.
• Whether the report reached the right channel and what the response team did with it.
• Which technical controls blocked, alerted or let it through.
• Progress across campaigns, which is where the value of the programme shows.

How we treat people

A badly run campaign destroys trust and teaches the team to hide mistakes — the opposite of the goal. So we operate under firm rules.

Individual results are not used for punishment, and we do not hand over a leaderboard of who clicked. The report works with data aggregated by group; individual identification exists only where it is needed to guide training, and stays with whoever you designate.

Anyone who interacts with the simulation gets immediate guidance, at the moment the lesson lands best, covering what should have stood out in that specific pretext.

What you receive

• Report with behaviour and group level metrics, without unnecessary individual exposure.
• Analysis of which pretexts worked and why, with the indicators that went unnoticed.
• Assessment of the technical controls that acted, or should have acted, at each stage.
• Recommendations for the reporting channel and the response flow.
• Awareness material derived from the real scenarios used in your campaign.

When it makes sense

• As a baseline, before investing in an awareness programme.
• On a recurring basis, to measure progress rather than photograph a moment.
• Ahead of a red team operation, to calibrate the initial access vector.
• When your sector is under an active campaign and you need to know where you stand.

Frequently asked

Do you hand over the list of who clicked?

By default, no. The report works with data aggregated by group, because a campaign used for punishment teaches the team to hide incidents. If your organization needs individual identification to direct training, that is agreed beforehand and access stays restricted to whoever you designate.

Do we need to warn employees?

The organization formally authorizes the campaign, but recipients are not warned — otherwise there is nothing to measure. We recommend communicating in advance that simulations are part of the security programme, without disclosing dates or pretexts.

Can you simulate MFA bypass?

Yes. We work with push fatigue and session proxying scenarios, which are the techniques real adversaries use today. It is particularly useful for organizations that consider MFA a solved problem.

Other services

• Application and infrastructure pentest
• Red team and adversary simulation
• Offensive security training
• Custom corporate CTFs