Find where impersonation
could lead to access.
Combine social engineering with breach and attack simulation. Build campaigns across messages, calls, and identity workflows to see where an attack succeeds, where it stops, and what needs to change.
Define the first campaign.
An attacker impersonates an employee who has lost their phone and asks the help desk for an MFA reset. Scope the verification test and any follow-on application access check with our team.
- Objective
- Does the recovery procedure need to change, and can the SOC identify any access that follows?
- Scope
- One help-desk recovery route, designated test accounts, and one approved test application.
- Team
- A security lead, the help-desk owner, an identity administrator, and a SOC contact.
- Before launch
- Agree on the testing window, permitted account changes, records to review, and who can stop the exercise.
- Stopping point
- Stop when verification blocks the request or after the approved application access check. Endpoint activity requires an extension to this scope.
- 01
Run the call
The configured voice agent presents the recovery request.
- 02
Review the response
Check which verification steps the help desk required.
- 03
Confirm the change
Correlate the ticket with identity records to establish whether MFA was reset.
- 04
Validate access
If recovery succeeds and access testing is in scope, complete the agreed application check with our team and review the available SOC records.
A reset does not prove application access. Record blocked, successful, and untested steps separately. Compare event time with alert receipt time when assessing detection.
Who runs what.
Use GhostEye to execute and repeat the campaign workflow. Our team helps with setup and scope; your owners provide the environment context and decide what to change.
The platform automates
- Voice and message steps in the configured workflow.
- Recurring execution for the groups and exclusions you select.
- Collection of campaign metrics for dashboard review.
Our team works with you
- Define the scenario and stopping point.
- Prepare the campaign and relevant sign-in pages during onboarding.
- Confirm integrations and agree on any identity testing, endpoint testing, or additional reporting support.
Your team decides
- Approve the audience, timing, systems, and permitted actions.
- Coordinate with the SOC and confirm which support and identity records your team or integrations will supply.
- Review the evidence, assign the fix, and choose when to retest.
What you can review
and export.
Campaign reporting shows what happened in the simulation. A finding about account access or detection also needs evidence from the systems involved.
A campaign view in GhostEye
Select the campaign, filter by attack type, and arrange the reporting metrics for your audience. Use the same view when reviewing a later run.
An Excel workbook
Export campaign reporting data into separate sheets for your team’s reporting process. The export contains campaign metrics; review support tickets and identity logs alongside it. A reporting API is not currently available.
An evidence review with your owners
Use support records to confirm the recovery action, identity and application records to establish access, and SOC records to assess detection. Agree on collection and review responsibilities before launch.
- Finding
- The designated test account was recovered without the required callback. The subsequent access check succeeded.
- Evidence
- The support record shows the missed callback, the identity audit shows the reset, and the application record confirms access to the approved test resource.
- Open questions
- SOC alert receipt has not been verified. This finding does not establish a detection failure or access to other applications.
- Action and owner
- The help-desk owner corrects the callback exception. The identity owner reviews the recovery records; the SOC checks the associated alerts.
- Retest
- A comparable unverified request is refused before an account change. Review alert handling separately against the SOC’s agreed criteria.
Decide what to fix
or test next.
Agree on these decisions before the campaign. A blocked request can validate a control; a completed recovery can expose a process gap. Neither result establishes how every recovery route behaves.
The help desk blocks the request
Confirm that the approved verification route caused the block. Keep that control, then choose a different shift or recovery route to test.
Owner: Help-desk owner
Recovery succeeds without required verification
Identify the missed check or exception. Change that procedure and repeat a comparable request after the fix.
Owner: Help-desk and identity owners
Application access succeeds
Review whether that access should have been allowed and whether the SOC received usable evidence. Check telemetry coverage before concluding that detection failed.
Owner: Identity and security operations teams
Scope your first recovery campaign.
Bring your recovery procedure and the application you want to test. We’ll walk through the workflow and reporting, then agree on scope, evidence, and responsibilities.