The Hacker's Hackers / Offensive security
PhishRoot PenTest
You cannot defend against what you cannot emulate. Have No Doubt... We Are Hackers... We Just Work For The Good Team!
Penetration Testing
Scoped, authorized testing of your external, internal and AI/LLM surfaces to validate real vulnerabilities.
Ethical Hacking
Manual and hybrid exploration of web, network and cloud logic — thinking like an attacker, working for you.
Red Teaming
Adversary emulation that tests your people, controls and detection end to end.
Network penetration-testing scope and coordination for MSPs and MSSPs. Define the engagement, track the request and keep remediation work with your team.
Scope requests are available now. Active network testing, internal sensors and provider report sync are planned and not connected. A request does not start a test or create a recurring schedule.
01 / Engagement workspace
Define your PenTest scope
Saved requests go to your organization's Operations queue for coordination. Execution requires a connected provider, written rules of engagement and separate approval.
Loading organization…
02 / Service scope
Available coordination. Planned testing.
Scope & authorization
AvailableRecord internal or external targets, exclusions, an authorized contact and the preferred testing window.
Engagement tracking
AvailableSave a scope request to your selected organization's Operations queue and follow its status.
External posture assessment
AvailableUse the separate ownership-verified, non-intrusive assessment for public DNS and web signals.
Network attack validation
PlannedInternal and external attack simulation, segmentation checks and evidence-backed attack paths.
Recurring network tests
PlannedProvider-run monthly or quarterly engagements after an approved scope and agreed rules of engagement.
Executive & technical reports
PlannedProvider evidence, remediation recommendations and retest results synchronized to the client workspace.
Testing with clear boundaries
A vulnerability or posture assessment identifies signals; a penetration test validates compromise paths through authorized attack simulation. Our existing assessment remains non-intrusive and is not an exploit-based penetration test. Active testing will require approved targets, exclusions, stop conditions and a separately authorized provider engagement.
No compliance certification, response-time guarantee or live internal sensor is implied. Pricing lists proposed package starting prices, not available testing services. Final scope, currency and commercial terms are confirmed through your MSP or MSSP.
03 / AI & LLM security · Planned
AI & LLM security testing
Security for the application around the model: chatbots, copilots, retrieval-augmented generation (RAG) and tool-using agents. The proposed scope examines how information, instructions and permissions move through the whole AI stack—not just the model in isolation.
AI/LLM penetration testing is a planned PhishRoot PenTest service, not a connected testing capability. Discuss requirements through your MSP or MSSP; an enquiry does not start an AI test. The existing AI-assisted passive domain assessment does not test LLM applications.
Proposed coverage across the AI stack
Models & guardrails
Model configuration, safety boundaries and the controls that separate trusted instructions from untrusted inputs.
Prompts & context
User messages, uploaded files, retrieved content and tool responses that can influence the application's instructions.
RAG & retrieval
Document access, source integrity, vector-store permissions and separation between customer knowledge bases.
Agents & tools
Tool permissions, approval gates and limits on what an agent can read, change or trigger.
Outputs & connected applications
How model responses are validated before they reach a browser, an API or another system.
Infrastructure & APIs
Authentication, tenant boundaries, key handling, sensitive logging and usage controls around AI services.
04 / AI risk categories
OWASP Top 10 for LLM Applications
OWASP Top 10 for LLM Applications supplies the risk categories below. MITRE ATLAS can inform AI threat scenarios and NIST AI RMF can inform governance discussions. These are planning references only: framework-mapped reports are not implemented, and PhishRoot makes no accreditation, certification or auditor-acceptance claim.
- LLM01
Prompt injection
Untrusted messages or documents redirecting application behaviour.
- LLM02
Sensitive information disclosure
Private information appearing in responses or crossing customer boundaries.
- LLM03
Supply chain
Risks introduced by models, dependencies and third-party components.
- LLM04
Data & model poisoning
Untrusted training or retrieval sources changing system behaviour.
- LLM05
Improper output handling
Model responses reaching downstream systems without validation.
- LLM06
Excessive agency
Agents having more permissions or autonomy than their task requires.
- LLM07
System prompt leakage
Exposure of hidden instructions or sensitive configuration.
- LLM08
Vector & embedding weaknesses
Retrieval permissions and isolation failures in shared knowledge stores.
- LLM09
Misinformation
Unsupported or misleading output driving consequential decisions.
- LLM10
Unbounded consumption
Missing usage limits allowing runaway requests or unexpected costs; no load or denial-of-service testing is offered.
05 / Proposed engagement
Scope first. Evidence before conclusions.
- 01
Define scope & trust boundaries
Discuss the AI application, data sources, customer boundaries and permitted actions with your partner.
- 02
Agree safe engagement conditions
Any future testing requires a qualified provider, separate written authorization, exclusions and stop conditions. Prefer isolated staging, synthetic data and restricted tools.
- 03
Validate evidence
Planned provider-led assessment would distinguish reproducible security issues from variable model behaviour. PhishRoot does not execute adversarial AI tests today.
- 04
Report, remediate & review
Proposed reports would connect business impact to technical evidence and recommended fixes. Retest scope and timing must be agreed separately.
06 / Proposed deliverables · Planned
Clear findings for engineers and leadership
Technical findings
Proposed evidence-backed findings with affected components, severity rationale, relevant risk categories and remediation guidance.
Executive summary
Proposed business-risk overview covering impact, priorities and remaining risk.
Controlled validation evidence
Proposed sanitized reproduction records from an authorized provider, without customer secrets or unsafe actions against production systems.
Remediation review
A future, separately agreed provider review of fixes—not a free retest, certification or guaranteed outcome.
07 / Common questions