# SilentGrid: complete plain-text mirror Every per-topic text file, concatenated in one document. Index: https://www.silentgrid.com/llms.txt Generated from the SilentGrid site source on 2026-10-13. Do not edit by hand. ============================================================================== # SilentGrid service catalogue SilentGrid sells 20 services in two families, plus two programs that repeat or rotate those services over a year. Nothing outside this list is offered. ## Adversary simulation (11 services) Family page: https://www.silentgrid.com/adversary-simulation ### Red Teaming Page: https://www.silentgrid.com/adversary-simulation/red-teaming Text: https://www.silentgrid.com/txt/red-teaming.md Full-scope adversary simulation against your organisation to achieve real objectives and test your defences end-to-end. ### Purple Teaming Page: https://www.silentgrid.com/adversary-simulation/purple-teaming Text: https://www.silentgrid.com/txt/purple-teaming.md Joint attack and defence exercises to improve your detection and response capabilities. ### CORIE Framework Page: https://www.silentgrid.com/adversary-simulation/corie Text: https://www.silentgrid.com/txt/corie.md Financial-sector resilience exercises guided by the CORIE framework. ### Assumed Breach Page: https://www.silentgrid.com/adversary-simulation/assumed-breach Text: https://www.silentgrid.com/txt/assumed-breach.md Test your internal defences and incident response by simulating an attacker who has already gained initial access. ### Perimeter Assessment Page: https://www.silentgrid.com/adversary-simulation/perimeter-assessment Text: https://www.silentgrid.com/txt/perimeter-assessment.md Comprehensive testing of your external attack surface to identify and validate vulnerabilities. ### Social Engineering Page: https://www.silentgrid.com/adversary-simulation/social-engineering Text: https://www.silentgrid.com/txt/social-engineering.md Evaluate your human security controls through simulated phishing, vishing, and physical security tests. ### Ransomware Simulation Page: https://www.silentgrid.com/adversary-simulation/ransomware-simulation Text: https://www.silentgrid.com/txt/ransomware-simulation.md Controlled ransomware attack simulation to test your prevention, detection, and recovery capabilities. ### Cloud Assumed Breach Page: https://www.silentgrid.com/adversary-simulation/cloud-assumed-breach Text: https://www.silentgrid.com/txt/cloud-assumed-breach.md Specialised post-compromise assessment for cloud environments, testing cloud-native security controls and response. ### OT/ICS Adversary Simulation Page: https://www.silentgrid.com/adversary-simulation/ot-ics Text: https://www.silentgrid.com/txt/ot-ics.md Specialised security assessment for operational technology and industrial control systems with safety-first approach. ### Supply Chain Attack Assumed Breach Page: https://www.silentgrid.com/adversary-simulation/supply-chain-assumed-breach Text: https://www.silentgrid.com/txt/supply-chain-assumed-breach.md Start from a compromised developer account and establish what an attacker could reach, modelling a backdoored software dependency. ### Scattered Spider Adversary Emulation Page: https://www.silentgrid.com/adversary-simulation/scattered-spider-emulation Text: https://www.silentgrid.com/txt/scattered-spider-emulation.md A collaborative purple team exercise running test cases drawn from Scattered Spider’s published tactics, across the full lifecycle of their attacks. ## Penetration testing (9 services) Family page: https://www.silentgrid.com/penetration-testing #### Application and API ### Web Application and Services Page: https://www.silentgrid.com/penetration-testing/web-application-and-services Text: https://www.silentgrid.com/txt/web-application-and-services.md Category: Application and API Identify and eliminate critical vulnerabilities in your web applications. ### Mobile Application Security Page: https://www.silentgrid.com/penetration-testing/mobile-application Text: https://www.silentgrid.com/txt/mobile-application.md Category: Application and API Identify and remediate vulnerabilities in your mobile applications to protect user data and prevent exploitation. ### Desktop Application Security Page: https://www.silentgrid.com/penetration-testing/desktop-application Text: https://www.silentgrid.com/txt/desktop-application.md Category: Application and API Identify and remediate vulnerabilities in your desktop applications to prevent exploitation and safeguard sensitive data. #### Infrastructure and Cloud ### External Infrastructure Page: https://www.silentgrid.com/penetration-testing/external-infrastructure Text: https://www.silentgrid.com/txt/external-infrastructure.md Category: Infrastructure and Cloud Assess your internet-facing assets to identify vulnerabilities before attackers exploit them. ### Internal Infrastructure Page: https://www.silentgrid.com/penetration-testing/internal-infrastructure Text: https://www.silentgrid.com/txt/internal-infrastructure.md Category: Infrastructure and Cloud Identify and remediate vulnerabilities within your internal network to prevent data breaches and unauthorised lateral movement. ### Wireless Network Security Page: https://www.silentgrid.com/penetration-testing/wireless Text: https://www.silentgrid.com/txt/wireless.md Category: Infrastructure and Cloud Identify and mitigate vulnerabilities in your wireless networks to prevent unauthorised access, data interception, and rogue attacks. ### Restricted Environment Breakout Page: https://www.silentgrid.com/penetration-testing/restricted-environment-breakout Text: https://www.silentgrid.com/txt/restricted-environment-breakout.md Category: Infrastructure and Cloud Assess the resilience of virtual desktops, kiosks, and other locked-down environments against breakout attempts and privilege escalation. #### Hardware and IoT ### Hardware and IoT Security Page: https://www.silentgrid.com/penetration-testing/hardware-iot Text: https://www.silentgrid.com/txt/hardware-iot.md Category: Hardware and IoT Identify vulnerabilities in IoT devices and embedded systems to prevent exploitation and secure physical and digital assets. #### Emerging Technologies ### AI/LLM Penetration Testing Page: https://www.silentgrid.com/penetration-testing/ai-llm Text: https://www.silentgrid.com/txt/ai-llm.md Category: Emerging Technologies Test the security and resilience of AI models, large language models (LLMs), and AI-driven applications against adversarial attacks and exploitation techniques. ## Programs ### CAOS (Continuous Adversary Operations Service) Page: https://www.silentgrid.com/continuous-red-teaming Text: https://www.silentgrid.com/txt/continuous-red-teaming.md Operators run attacks against your environment throughout the year, in cycles, rather than in a single annual window. ### Annual programs Page: https://www.silentgrid.com/annual-programs Text: https://www.silentgrid.com/txt/annual-programs.md A year of testing planned as one program, rotating coverage across the estate so each engagement starts where the last finished. ## Choosing between them Engagement planner: https://www.silentgrid.com/which-security-test How to choose, in text: https://www.silentgrid.com/txt/choosing-a-test.md --- Source page: https://www.silentgrid.com/services Text file: https://www.silentgrid.com/txt/services.md Generated from the SilentGrid site source on 2026-10-13. Do not edit by hand. ============================================================================== # Red Teaming Canonical name: Red Teaming Family: Adversary simulation Page: https://www.silentgrid.com/adversary-simulation/red-teaming ## Description Full-scope adversary simulation against your organisation to achieve real objectives and test your defences end-to-end. ## Where it sits Adversary simulation catalogue: https://www.silentgrid.com/adversary-simulation All 20 services in text: https://www.silentgrid.com/txt/services.md Choosing an engagement: https://www.silentgrid.com/txt/choosing-a-test.md Scoping contact: https://www.silentgrid.com/contact Scope, duration and pricing are agreed during scoping. The sections below are the service page itself: approach, methodology, deliverables and common questions. ## Red teaming with SilentGrid SilentGrid's red team engagements test whether an adversary can reach an agreed business objective within your environment. The team follows realistic attack paths across the authorised scope, assessing how security controls and response teams perform as the intrusion progresses. Each exercise documents the attack path and the gaps in detection and response, with remediation guidance for the defensive team. The findings give security leaders evidence to prioritise improvements and validate them through follow-up testing. ## Objectives and outcomes ### Expose security blind spots Identify attack paths and techniques that bypass traditional defences ### Test detection capabilities Assess SOC, IR teams, and SIEM effectiveness in detecting threats ### Evaluate security ROI Quantify effectiveness of security tools and incident response processes ### Uplift defensive teams Provide tactical feedback to strengthen detection and response ## Is red teaming the right fit? Red teaming suits organisations with established detection and response capabilities. Where those capabilities are still being built, a covert exercise offers limited additional evidence. Red team vs penetration test: which do you need? Red teaming fits when - Operate mature security programs and want to test their full defensive capabilities. - Need to evaluate how well their SOC, IR and blue teams handle real-world threats . - Seek to identify unknown attack paths beyond vulnerability assessments. - Require executive-level insights into security resilience and ROI . ## How the engagement runs Four stages, from agreeing the objective through to an optional replay with your defensive team. ### Activity planning - The objective and its evidence are agreed first, so both teams work to one shared reference: scope and boundaries, the agreed starting access , the business outcome under test, and the evidence the exercise should produce - A small Control Group is briefed and stays in contact throughout. Flags mark milestone targets along each scenario, and where a flag is not reached a concession turns it into an assumed breach test so coverage continues across the whole attack chain ### Execution - Attacks follow the tactics, techniques and procedures of the threat actors being simulated - Weaknesses are exploited in a realistic but controlled manner aligned to your risk tolerance, with approval requested before targeting systems or accounts carrying high operational risk ### Reconnaissance and target selection - Passive and active intelligence gathering to profile external attack surfaces - Open-source intelligence (OSINT) and social engineering to identify exploitable vectors ### Initial compromise - Targeting externally accessible infrastructure, third-party services, and employee endpoints - Techniques include spear phishing , supply chain compromise, and application exploitation ### Persistence and privilege escalation - Establishing footholds within compromised environments - Persistence techniques bypassing EDR and maintaining access through custom tooling ### Lateral movement and internal reconnaissance - Credential harvesting, Active Directory exploitation , and pivoting across networks - Identifying sensitive systems, mapping internal environments, and expanding access ### Objective execution and exfiltration - Attaining predefined objectives such as data exfiltration, domain dominance , or insider threat emulation - Testing data loss prevention (DLP) mechanisms and network monitoring tools ### Reporting and knowledge transfer - Comprehensive documentation of findings, attack paths, and remediation guidance with executive and technical reporting ### Post-exercise debrief - The Attack Execution Report is shared with the Control Group and circulated on a need-to-know basis - Two debriefs follow: an executive debrief covering real-world impact and systemic issues, and a technical debrief walking the defensive team through the report ### Replay attacks (optional) - Attacks from the simulation are replayed alongside the defensive team to verify that detections and response measures now fire - The feedback is used to finalise remediation ## Deliverables and reporting The engagement report is delivered within five business days of the exercise concluding, alongside the execution logs and debriefs: ### Engagement report Detailed breakdown of attack paths, vulnerabilities exploited, and post-exploitation activity ### MITRE ATT&CK mapping Each step mapped to MITRE ATT&CK to identify gaps in detection and response ### Executive summary High-level reporting summarising business risks and strategic recommendations ### Technical debrief In-depth review with blue teams and SOC analysts on techniques and detections ### Attack execution logs Timestamped logs of key actions taken during the exercise, so internally raised incidents can be cross-checked and attributed, and gaps in detection tooling identified ### Proof-of-concept payloads Custom payloads used to bypass EDRs and detection rules where applicable ### Post-engagement support Ongoing assistance during remediation and validation of security improvements ## Common questions ### What is red teaming? Red teaming tests an organisation the way a real adversary would: covertly, across the authorised scope, working towards an agreed business objective. Only a small Control Group knows the exercise is running, so the result shows how security controls and the defensive team performed as the intrusion progressed, with the attack path mapped to MITRE ATT&CK and remediation guidance for each gap. ### What does a red team engagement test? A red team engagement tests whether an adversary can reach an agreed business objective inside your environment. The team follows realistic attack paths across the authorised scope and assesses how security controls and response teams perform as the intrusion progresses. ### How is red teaming different from penetration testing? Penetration testing finds weaknesses in a defined system, such as an application or an internal network. A red team engagement works towards an agreed objective across the authorised scope and measures detection and response along the way. The red team vs penetration test guide compares them side by side. ### When is an organisation ready for red teaming? Red teaming suits organisations already running a mature security program with a SOC, incident response or blue team capability to exercise. Where detection and response are still being established, purple teaming builds those capabilities collaboratively. ### How long does a red team engagement take? Red team engagements run over weeks or months, simulating sophisticated actors across the authorised scope. The exact duration depends on the agreed objective and the scope of the exercise. ### Who inside our organisation needs to know? Only the Control Group: a small group of senior staff with the business knowledge and authority to make risk-based decisions during the exercise. The defensive team remains unaware so detection and incident response can be tested realistically. ### Can we verify that the gaps were fixed? Yes. Attacks from the simulation can be replayed alongside your defensive team to confirm that detections and response measures now fire. This optional replay phase is delivered as purple teaming and the feedback is used to finalise remediation. ### What do we receive at the end? A comprehensive engagement report documenting the attack path, MITRE ATT&CK mapping of the techniques used, an executive summary, a technical debrief, proof-of-concept payloads and remediation support. ### Can red teaming run as an ongoing program? Yes. CAOS, SilentGrid's continuous red teaming service, re-tests remediated attack paths, introduces new techniques and TTPs as they emerge, and simulates evolving threat groups against your current defences. --- Source page: https://www.silentgrid.com/adversary-simulation/red-teaming Text file: https://www.silentgrid.com/txt/red-teaming.md Generated from the SilentGrid site source on 2026-10-13. Do not edit by hand. ============================================================================== # Purple Teaming Canonical name: Purple Teaming Family: Adversary simulation Page: https://www.silentgrid.com/adversary-simulation/purple-teaming ## Description Joint attack and defence exercises to improve your detection and response capabilities. ## Where it sits Adversary simulation catalogue: https://www.silentgrid.com/adversary-simulation All 20 services in text: https://www.silentgrid.com/txt/services.md Choosing an engagement: https://www.silentgrid.com/txt/choosing-a-test.md Scoping contact: https://www.silentgrid.com/contact Scope, duration and pricing are agreed during scoping. The sections below are the service page itself: approach, methodology, deliverables and common questions. ## Collaborative threat simulation Purple teaming brings offensive operators and defenders into a collaborative environment where red and blue teams work together to detect, respond to, and mitigate advanced threats in real time. SilentGrid's purple team engagements focus on adversary emulation, simulating sophisticated attack techniques while actively engaging your defensive teams and SOC analysts. Each exercise identifies detection gaps, refines response processes and tests how your security infrastructure adapts to emerging threats. The process is transparent and iterative: operators replay attacks after defenders adjust controls and response procedures, then verify what improved. ## Objectives and outcomes ### Enhance detection capabilities Improve your ability to identify sophisticated attack techniques across all phases of the kill chain ### Validate security controls Test and tune EDR, SIEM, and other security tools against real-world attack scenarios ### Improve response times Reduce mean time to detect (MTTD) and respond (MTTR) through hands-on practice ### Upskill security teams Provide practical, real-world training to SOC analysts and incident responders ## Is purple teaming the right fit? Purple teaming requires a defensive team able to participate. Where detection and response are mature enough to be tested without warning, red teaming measures them covertly instead. Purple teaming is ideal for organisations that - Have an established SOC or blue team that wants to improve detection and response. - Want to know whether their EDR, SIEM and logging catch the techniques used against their sector. - Want their analysts to work directly with offensive operators and see how attacks are run. - Need evidence that detection has improved , technique by technique, for leadership or audit. ## Purple team methodology SilentGrid follows real-world attack chains, with operators and defenders collaborating throughout the engagement. ### Engagement planning and threat modelling - Jointly define objectives, adversaries, and target environments - Select specific tactics, techniques, and procedures (TTPs) based on industry threats and past incidents ### Adversary emulation and initial testing - Simulate targeted attacks aligned with the MITRE ATT&CK framework - Baseline existing detection capabilities to identify immediate gaps ### Real-time collaboration and detection - Execute attack techniques while blue teams monitor in real-time - Provide immediate feedback on detection successes and misses ### Iterative refinement - Replay attacks with modified detection rules and response procedures - Validate improvements and identify remaining blind spots ### Process enhancement - Update incident response playbooks based on lessons learned - Train SOC analysts on advanced detection techniques ### Knowledge transfer and documentation - Deliver comprehensive documentation of all techniques tested - Provide actionable recommendations for long-term improvements ## Deliverables and reporting Purple team reporting documents the techniques tested and changes to detection and response: ### Attack technique documentation Detailed documentation of all techniques tested, including commands, tools, and IOCs ### Detection gap analysis Comprehensive mapping of detection capabilities against MITRE ATT&CK framework ### Detection rule guidance Expert assistance in developing and tuning SIEM queries, EDR rules, and threat hunting playbooks ### Response playbook updates Enhanced incident response procedures based on engagement findings ### Training materials Hands-on exercises and scenarios for ongoing team development ### Executive briefing Strategic insights on security posture improvements and risk reduction ## Common questions ### What is purple teaming? Purple teaming tests detection and response the way an attacker would, with the defenders watching: operators execute adversary techniques aligned with MITRE ATT&CK while your SOC analysts monitor, detection successes and misses are fed back as they happen, and attacks are replayed against modified detection rules. The result is a documented detection gap analysis and tuned detections. ### What does a purple team engagement test? Whether your SOC and security tools detect and respond to specific adversary techniques. Operators run each technique alongside your analysts, record what was caught and what was missed, and run it again once detection rules or response steps change. ### How is purple teaming different from red teaming? Red teaming works covertly towards an agreed business objective and tests whether your defences notice. Purple teaming is transparent and collaborative: techniques are executed alongside your defenders and replayed to tune detection rules. ### What do we need in place to run one? A SOC or blue team to work alongside. Purple teaming suits organisations with established security teams looking to improve detection and response; scope and intensity are tailored to your defensive maturity. ### How long does a purple team engagement take? One to four weeks is typical, with scope and intensity aligned to your defensive maturity. ### Can purple teaming run as an ongoing program? Yes, in two ways. In an annual program, purple team sessions run alongside the adversary campaigns, either as two longer sessions a year or four shorter ones, and the cadence can change at any quarterly planning session. In CAOS (Continuous Adversary Operations Service), the TTPs used in a cycle can be replayed with your security team before the next cycle begins, together with techniques current threat actors use. That replay is optional, up to two a year, and a whole cycle can also be dedicated to purple teaming. ### How is improvement measured? By running the same techniques again after detection rules or response steps change, and recording which are now detected and how long your team took to respond and contain them (MTTR). The detection gap analysis maps those results to MITRE ATT&CK, so coverage before and after tuning can be compared. In a CAOS program, HackTrack (SilentGrid's platform for operator logs, indicators of compromise and the techniques used) holds the data from every cycle and purple team. ### What do we receive at the end? Attack technique documentation, a detection gap analysis, detection rule guidance, response playbook updates, training materials and an executive briefing. --- Source page: https://www.silentgrid.com/adversary-simulation/purple-teaming Text file: https://www.silentgrid.com/txt/purple-teaming.md Generated from the SilentGrid site source on 2026-10-13. Do not edit by hand. ============================================================================== # CORIE Framework Canonical name: CORIE Framework Family: Adversary simulation Page: https://www.silentgrid.com/adversary-simulation/corie ## Description Financial-sector resilience exercises guided by the CORIE framework. ## Where it sits Adversary simulation catalogue: https://www.silentgrid.com/adversary-simulation All 20 services in text: https://www.silentgrid.com/txt/services.md Choosing an engagement: https://www.silentgrid.com/txt/choosing-a-test.md Scoping contact: https://www.silentgrid.com/contact Scope, duration and pricing are agreed during scoping. The sections below are the service page itself: approach, methodology, deliverables and common questions. ## Simulating advanced threats for financial sector resilience The Cyber Operational Resilience Intelligence-led Exercises (CORIE) framework sets out intelligence-led adversary simulation for Australia's financial sector. Developed by the Council of Financial Regulators (CFR), CORIE exercises simulate the techniques of sophisticated threat actors including nation-states, organised cybercrime, and advanced persistent threats (APTs). SilentGrid conducts CORIE-aligned red team exercises to assess the resilience of financial institutions. The engagements test your organisation's technology, personnel and incident response capabilities across the attack chain, identifying weaknesses before a real attack. ## Why CORIE matters ### A financial sector under threat The financial sector remains one of the most targeted industries globally. CORIE tests whether an institution's defences hold up against evolving threats. ### Regulatory and operational significance For many financial entities, CORIE is a regulatory requirement mandated by the CFR, and tests resilience against cyber incidents with severe operational consequences. ## Is CORIE the right fit? CORIE is the Council of Financial Regulators' framework, so the exercise is built around financial sector threat profiles and Critical Business Services. Outside that sector, a red team engagement tests the same defences without the CORIE framing and reporting. CORIE testing is ideal for - Banks, insurers, and payment providers mandated by the Council of Financial Regulators - Financial institutions aiming to proactively enhance resilience against APTs - Organisations seeking real-world insights beyond standard penetration tests - Entities prioritising resilience, compliance, and threat readiness ## CORIE engagement lifecycle SilentGrid follows the CORIE-mandated engagement lifecycle, which mirrors real-world attack chains while aligning with regulatory expectations. ### Threat intelligence and reconnaissance - Intelligence gathering aligned with financial sector threats - Client-provided threat intelligence integration for targeted scenarios ### Initial compromise - Simulating spear phishing, web application exploitation, and credential harvesting - Custom malware payloads to bypass security controls and gain foothold ### Persistence and lateral movement - Testing for Active Directory misconfigurations and privilege escalation - Moving laterally through internal environments to expand access ### Impact and objective execution - Simulating data exfiltration, financial fraud, or disruption scenarios - Testing resilience of Critical Business Services and essential functions ### Post-engagement review and uplift - Technical and executive debriefs covering the findings - MITRE ATT&CK mapping documenting detection blind spots ## Our approach ### Advanced adversary emulation SilentGrid simulates the tactics of ransomware groups, state-sponsored hackers and insider threats targeting the financial sector. ### Industry-specific targeting CORIE exercises are scoped to the attack paths and threat profiles facing your institution, based on its business model and infrastructure. ### Critical Business Services focus SilentGrid helps identify and prioritise Critical Business Services: those functions that, if disrupted, would significantly impact confidentiality, integrity, or availability of core financial systems. ## Deliverables and reporting CORIE reporting covers operational findings and business risk for technical teams and executive leadership: ### Attack execution report Step-by-step documentation of red team activities with actionable recommendations ### Executive summary Board-level insights on business risks and strategic recommendations ### Tactical uplift workshops Post-engagement sessions with custom remediation roadmaps ### Critical Business Services analysis Assessment of systemically important services and their resilience ## The team CORIE requires The framework specifies these delivery roles. SilentGrid's experience and credentials for each are outlined below: ### Red Team Lead Our founders have delivered CBEST engagements in the United Kingdom, the intelligence-led framework CORIE was modelled on, and have led red team exercises against major Australian banks and ASX-listed organisations. ### Red Team Specialist Credentials across the delivery team include OSEE, OSCE3, OSEP, OSWE, GXPN, CRTO, CRTE, CRTP and OSCP, alongside CREST registrations. SilentGrid is a CREST ANZ approved company. ### Exploit Development Specialist Consultants certified OSEE and OSED who have discovered and responsibly disclosed previously unknown vulnerabilities in commercial software from Hexagon, VMware and Commvault. The advisories and the exploit development behind them are published at /security-advisories. ### Threat intelligence Delivered by a specialist intelligence partner under our management, so the targeting package is produced by dedicated analysts rather than by the operators who will execute against it. ## Common questions ### What is the CORIE framework? CORIE (Cyber Operational Resilience Intelligence-led Exercises) is the Council of Financial Regulators' framework for testing Australia's financial sector the way a sophisticated threat actor would: an intelligence-led red team exercise against an institution's Critical Business Services, covering technology, personnel and incident response, and simulating the techniques of nation-states, organised cybercrime and advanced persistent threats. ### Who is a CORIE exercise for? Banks, insurers and payment providers mandated by the Council of Financial Regulators, along with financial institutions that want to enhance resilience against advanced persistent threats ahead of any mandate. ### How does a CORIE exercise run? It follows the CORIE-mandated engagement lifecycle: threat intelligence and reconnaissance, initial compromise, persistence and lateral movement, impact and objective execution, then post-engagement review and uplift. ### What are Critical Business Services? The functions that, if disrupted, would significantly impact the confidentiality, integrity or availability of core financial systems. Identifying and prioritising them is part of the engagement, and their resilience is tested during objective execution. ### How is CORIE different from a standard penetration test? A CORIE exercise assesses the end-to-end security posture of the organisation, targeting technology, personnel and incident response capabilities, rather than testing a defined system. It is intelligence-led and tailored to the attack paths facing financial institutions. ### Is SilentGrid qualified to deliver CORIE engagements? Yes. We field the team structure the framework specifies. Our founders have delivered CBEST engagements in the United Kingdom, the intelligence-led framework CORIE was modelled on, and have led red team exercises against major Australian banks and ASX-listed organisations. Exploit development is held by consultants certified OSEE and OSED who have discovered and disclosed previously unknown vulnerabilities in commercial software from Hexagon, VMware and Commvault. SilentGrid is a CREST ANZ approved company. ### Who will lead the exercise, and what are their credentials? The delivery team is named before you sign. The CORIE framework specifies a Red Team Lead, a Red Team Specialist and an Exploit Development Specialist. Our exploit development capability is held by consultants certified OSEE and OSED who have discovered and disclosed previously unknown vulnerabilities in commercial software from Hexagon, VMware and Commvault. Credentials across the delivery team include OSEE, OSCE3, OSEP, OSWE, GXPN, CRTO, CRTE, CRTP and OSCP, and every consultant is listed publicly on our team page. ### Is threat intelligence provided in-house or subcontracted? A specialist intelligence partner delivers it under SilentGrid's management. Dedicated analysts produce the targeting package independently of the operators who execute against it, to reflect what a real adversary would find. ### How is separation from the Blue Team maintained? Through a Control Group: a small, named set of people at your organisation who know the exercise is running, agreed before it starts. Defenders are not told. Communications with the control group run out of band, away from the systems in scope, so an exercise is not revealed by the response to it. Deconfliction procedures let the control group confirm within minutes whether an alert is us or a real intrusion. ### Can you run the physical and social engineering components? Yes, and they are in scope where the threat scenario justifies them. Social engineering is delivered in person, over video calls, and via email, SMS, voice and social media. Physical intrusion is scoped separately with written authorisation, since it carries obligations that email-based phishing does not. ### Is SilentGrid CREST approved? Yes. SilentGrid is a CREST ANZ approved company, listed on the CREST ANZ approved companies register. For procurement, CREST approval and CORIE capability need separate assessment, and the Council of Financial Regulators does not treat one as evidence of the other. CORIE is intelligence-led and built around adversary objectives rather than vulnerability discovery, so evaluate the two separately. ### What do we receive at the end? An attack execution report documenting red team activity step by step with actionable recommendations, a board-level executive summary, tactical uplift workshops with a custom remediation roadmap, and a Critical Business Services analysis. --- Source page: https://www.silentgrid.com/adversary-simulation/corie Text file: https://www.silentgrid.com/txt/corie.md Generated from the SilentGrid site source on 2026-10-13. Do not edit by hand. ============================================================================== # Assumed Breach Canonical name: Assumed Breach Family: Adversary simulation Page: https://www.silentgrid.com/adversary-simulation/assumed-breach ## Description Test your internal defences and incident response by simulating an attacker who has already gained initial access. ## Where it sits Adversary simulation catalogue: https://www.silentgrid.com/adversary-simulation All 20 services in text: https://www.silentgrid.com/txt/services.md Choosing an engagement: https://www.silentgrid.com/txt/choosing-a-test.md Scoping contact: https://www.silentgrid.com/contact Scope, duration and pricing are agreed during scoping. The sections below are the service page itself: approach, methodology, deliverables and common questions. ## Testing resilience beyond the perimeter Supply chain attacks, phishing campaigns and zero-day exploits can bypass perimeter defences. An assumed breach assessment tests how far an attacker can go once inside. SilentGrid's assumed breach assessment starts from the premise that your perimeter has already been compromised. This controlled exercise simulates post-breach scenarios to evaluate your organisation's ability to detect, respond to, and contain adversarial movement within the internal network. SilentGrid uses the tactics, techniques and procedures (TTPs) of advanced threat actors to test your controls against lateral movement, privilege escalation and data exfiltration. The results document blind spots and operational gaps that may otherwise go unnoticed until an incident. ## Assumed breach assessments are critical After breaching the perimeter, attackers exploit misconfigurations, unpatched systems, and overlooked vulnerabilities to achieve persistence, access sensitive data, or escalate privileges. ### Internal navigation Reveals how easily attackers can navigate internal systems ### Security gaps Identifies gaps in segmentation, access controls, and detection ### Response effectiveness Tests SOC, IR, and monitoring solutions under real conditions ## Is assumed breach the right fit? The exercise begins after initial access, so it assumes there are external defences worth bypassing and an internal environment worth defending. Where the perimeter itself is the open question, external infrastructure or perimeter assessment answers it first. Assumed breach fits organisations that - Have mature perimeter defences but need to validate internal security. - Want to understand their true breach impact and containment capabilities. - Need to test Zero Trust implementations and network segmentation. - Require evidence of defence-in-depth effectiveness for compliance or insurance. ## SilentGrid's assumed breach methodology SilentGrid simulates realistic post-compromise scenarios to test your internal defences and response capabilities. ### Establishing initial foothold - Simulate scenarios such as compromised endpoints or user credentials - Malware deployment through spear phishing or supply chain attacks - Insider threat emulation from compromised accounts or rogue employees - Evaluate your endpoint detection and response (EDR) capabilities ### Privilege escalation and lateral movement - Exploit misconfigurations, weak passwords, and insecure protocols - Move laterally using legitimate administrative tools to avoid detection - Test Active Directory controls, segmentation, and access restrictions ### Persistence and command & control - Establish persistent backdoors using sophisticated techniques - Deploy custom C2 infrastructure to simulate APT communication patterns - Test your ability to detect and block covert channels ### Data discovery and staging - Identify and access sensitive data repositories - Test data classification and access control effectiveness - Simulate data staging techniques used by real adversaries ### Exfiltration and impact - Test data loss prevention (DLP) controls - Simulate various exfiltration methods including encrypted channels - Assess potential business impact of successful attacks ### Detection and response analysis - Comprehensive evaluation of detection capabilities at each stage - Analysis of incident response effectiveness and containment strategies - Detailed timeline of detection opportunities and misses ## Scenario-based testing SilentGrid runs targeted scenario simulations based on the threats most relevant to your industry. Popular scenarios include: ### Ransomware simulation Test resilience against encryption and lateral spread ### Data theft scenarios Evaluate protection of intellectual property and sensitive data ### Supply chain attacks Simulate compromise through trusted third-party access ## Key findings and insights Assumed breach findings show the weaknesses an attacker could exploit from the granted foothold: ### Internal vulnerability exposure Comprehensive mapping of exploitable vulnerabilities accessible from an assumed breach position ### Lateral movement paths Detailed documentation of how attackers can pivot through your network ### Privilege escalation vectors Identification of pathways to administrative access and domain dominance ### Detection blind spots Areas where adversary activity goes undetected by current security controls ## Deliverables and reporting ### Attack path documentation Visual mapping of all successful attack paths and pivot points discovered ### Detection opportunity timeline Chronological analysis of where attacks could have been detected ### Risk-prioritised findings Vulnerabilities ranked by exploitability and potential business impact ### Tactical recommendations Specific hardening measures to block identified attack vectors ### Strategic security roadmap Long-term improvements for defence-in-depth architecture ### Executive risk assessment Business-focused analysis of potential breach impacts ## Common questions ### What is an assumed breach assessment? An assumed breach assessment tests an organisation the way an attacker already inside would: it starts from a granted foothold, such as a compromised endpoint or user credentials, and spends the whole exercise on lateral movement, privilege escalation and data access, with detection and containment evaluated at each stage. It does not test whether the initial compromise would have succeeded. ### Where does the assessment start from? From a simulated initial foothold, such as a compromised endpoint or set of user credentials, malware deployed through spear phishing or a supply chain attack, or insider threat emulation from a compromised account. ### How is this different from a red team engagement? A red team engagement works covertly towards an agreed business objective and includes gaining initial access. An assumed breach assessment grants that starting access up front, so the whole exercise is spent on what happens inside: lateral movement, privilege escalation, data access and the response to it. ### How long does an assessment take? Two to six weeks is typical, depending on the size of the internal environment in scope and the scenarios being simulated. ### Can the exercise be built around a specific threat? Yes. Targeted scenario simulations are based on the threats most relevant to your industry, and popular scenarios include ransomware, data theft and supply chain compromise. Scenario testing validates incident response procedures against specific threats, tests backup and recovery capabilities under pressure, identifies the critical assets most at risk, and builds confidence in breach response capabilities. ### Does the assessment test detection and response? Yes. Detection capabilities are evaluated at each stage, incident response effectiveness and containment strategies are analysed, and you receive a detailed timeline of detection opportunities and misses. ### What do we receive at the end? Visual documentation of the attack paths and pivot points discovered, a detection opportunity timeline, risk-prioritised findings, tactical hardening recommendations, a strategic security roadmap and an executive risk assessment. --- Source page: https://www.silentgrid.com/adversary-simulation/assumed-breach Text file: https://www.silentgrid.com/txt/assumed-breach.md Generated from the SilentGrid site source on 2026-10-13. Do not edit by hand. ============================================================================== # Perimeter Assessment Canonical name: Perimeter Assessment Family: Adversary simulation Page: https://www.silentgrid.com/adversary-simulation/perimeter-assessment ## Description Comprehensive testing of your external attack surface to identify and validate vulnerabilities. ## Where it sits Adversary simulation catalogue: https://www.silentgrid.com/adversary-simulation All 20 services in text: https://www.silentgrid.com/txt/services.md Choosing an engagement: https://www.silentgrid.com/txt/choosing-a-test.md Scoping contact: https://www.silentgrid.com/contact Scope, duration and pricing are agreed during scoping. The sections below are the service page itself: approach, methodology, deliverables and common questions. ## Securing your external attack surface The external perimeter is often the first point of contact for adversaries seeking to infiltrate your organisation. Misconfigured systems, forgotten development environments, and exposed services can provide attackers with direct paths to internal networks. SilentGrid's Perimeter Assessment maps Internet-facing assets across your organisation and tests them for exploitable weaknesses. The assessment is manual and expert-driven, covering vulnerabilities automated tools miss in custom-built applications and exposures that depend on your industry's processes and systems. Researchers investigate logic flaws, business process vulnerabilities, and exposures in third-party software not covered by mainstream security research, alongside known CVEs. Asset discovery checks for external systems that have escaped the organisation's inventory, reducing the risk of unintended exposure. Depending on the time allocated and your budget, the exercise can simulate an opportunistic attacker looking for easy targets or a targeted attack against your organisation with specific objectives. ## The growing external attack surface Cloud platforms, third-party services and global infrastructure can make external assets difficult to track. A perimeter assessment checks for these exposures: ### Unknown systems Development or test environments left online ### Shadow IT Unmonitored systems spun up outside official processes ### Legacy exposure Forgotten or unpatched systems presenting vulnerabilities ### Third-party risks Exposed integrations and cloud service misconfigurations ## Is perimeter assessment the right fit? The assessment looks inward from the internet, so it answers what is exposed and reachable rather than what an intruder could do afterwards. Where the perimeter is already well understood, assumed breach testing picks up from the foothold onwards. Perimeter assessments are ideal for organisations that - Operate large, distributed or cloud-integrated infrastructures - Require visibility into forgotten or unmonitored Internet-facing assets - Are preparing for regulatory audits or compliance reviews - Need to reduce external attack surfaces as part of broader security initiatives ## Our methodology SilentGrid combines reconnaissance, threat intelligence and active testing to map your external attack surface. Researchers manually validate exploitability and pursue attack paths that depend on the context of your environment. ### Passive reconnaissance - OSINT, DNS enumeration, and internet-wide scans to identify exposed assets without direct interaction ### Active enumeration - Probing for misconfigurations in public-facing services, web applications, and network devices ### Vulnerability identification - Detecting known vulnerabilities , outdated software, and misconfigured service implementations ### Targeted exploitation - Time-boxed validation of exploitability including credential stuffing and weak configurations ## Deliverables and reporting Perimeter assessment reporting records the assets found, exploitable entry points and remediation priorities: ### Comprehensive asset inventory Full list of identified Internet-facing assets, subdomains, and third-party systems ### Risk prioritisation Vulnerabilities ranked by severity, exploitability, and potential business impact ### Attack surface analysis Visual mapping of external entry points, open ports, and exposed APIs ### Remediation guidance Clear, practical steps to harden exposed services and mitigate risk ## Beyond the assessment: strengthening defences Perimeter findings identify where further testing would be useful, from exposed applications to the internal paths an attacker could follow after gaining access: ### Red team operations Full-scope adversary simulation across technology, people and response processes ### Assumed breach Test internal defences once an external foothold is established ### Social engineering Test human defences against phishing and pretexting attacks ### Web application testing Focus on critical web applications to uncover application-level vulnerabilities ## Common questions ### What is a perimeter assessment? A perimeter assessment tests an organisation's internet-facing footprint the way an external attacker would: it maps exposed assets, including forgotten development systems, shadow IT and third-party services, then validates which are exploitable through manual, time-boxed testing. Depending on the time and budget allocated, it can simulate an opportunistic attacker or a targeted attack with specific objectives. ### How is this different from an automated vulnerability scan? The assessment is fundamentally manual and expert-driven. Security researchers go beyond known CVEs to uncover logic flaws, business process vulnerabilities and exposures in third-party software that mainstream security research has not covered. ### What is in scope? Internet-facing assets across the organisation, including subdomains, third-party systems, open ports and exposed APIs. Assets are identified through passive reconnaissance first, then probed through active enumeration. ### How long does an assessment take? One to six weeks, depending on the size of the external estate and the depth agreed for the exercise. ### Can you simulate a particular kind of attacker? Yes. Depending on the time allocated and your budget, the exercise can simulate an opportunistic attacker looking for easy targets, or a targeted attack against your organisation with specific objectives. ### Do you exploit what you find? Exploitation is time-boxed and used to validate exploitability, including credential stuffing and weak configurations, so that reported findings are demonstrated rather than assumed. ### What does continuous monitoring add? Monthly asset discovery to identify new exposures and shadow IT, scheduled vulnerability assessments at a frequency that suits you, and real-time alerts when critical exposures are detected. It maintains continuous visibility of the external attack surface, catches exposures before attackers find them, tracks posture improvements over time and supports external compliance requirements. ### What do we receive at the end? A comprehensive inventory of Internet-facing assets, subdomains and third-party systems, vulnerabilities ranked by severity, exploitability and business impact, a visual attack surface analysis, and practical remediation guidance. --- Source page: https://www.silentgrid.com/adversary-simulation/perimeter-assessment Text file: https://www.silentgrid.com/txt/perimeter-assessment.md Generated from the SilentGrid site source on 2026-10-13. Do not edit by hand. ============================================================================== # Social Engineering Canonical name: Social Engineering Family: Adversary simulation Page: https://www.silentgrid.com/adversary-simulation/social-engineering ## Description Evaluate your human security controls through simulated phishing, vishing, and physical security tests. ## Where it sits Adversary simulation catalogue: https://www.silentgrid.com/adversary-simulation All 20 services in text: https://www.silentgrid.com/txt/services.md Choosing an engagement: https://www.silentgrid.com/txt/choosing-a-test.md Scoping contact: https://www.silentgrid.com/contact Scope, duration and pricing are agreed during scoping. The sections below are the service page itself: approach, methodology, deliverables and common questions. ## Testing the human element Social engineering targets human behaviour and trust, manipulating authority and urgency to bypass technical defences. Attackers use these tactics to gain access through employees, contractors and third-party partnerships. SilentGrid's Social Engineering Services simulate real-world manipulation tactics to assess how well your workforce recognises, defends against, and responds to these threats. By targeting human vulnerabilities, our engagements strengthen awareness, improve response protocols, and reduce the risk of successful social engineering campaigns. ## Why social engineering testing matters Even with advanced endpoint detection and firewalls, adversaries exploit human psychology to bypass defences. A deceptive conversation or phishing message can expose credentials and give an attacker access. ### 85% of breaches Involve the human element ### Phishing Remains the primary delivery vector for ransomware ### AI-driven attacks Are increasing success rates significantly ### One click Can undermine entire security architectures ## Is social engineering the right fit? The engagement measures how people respond to manipulation, so its value depends on having awareness training and verification procedures worth testing. Where the question is what an attacker does after someone clicks, assumed breach testing picks up from there. Social engineering assessments are ideal for organisations that - Want to assess and improve employee security awareness - Need to validate security training effectiveness - Require compliance with industry regulations requiring security awareness - Have experienced previous social engineering incidents ## Simulated social engineering techniques SilentGrid replicates real-world attack scenarios, exposing employees to the same tactics used by adversaries: ### Phishing (email-based) Simulated campaigns targeting individuals, departments, or executives with realistic business email compromise scenarios ### Vishing (voice-based) Voice phishing calls impersonating IT, HR, or management to test verification procedures ### Smishing (SMS-based) SMS attacks using fake delivery notifications, account alerts, or urgent requests ### Physical security testing Tailgating attempts, badge cloning, and testing physical access controls ### Baiting attacks Deployment of USB drives and rogue devices to test employee response to physical lures ### AI-enhanced attacks AI used for personalisation and deepfake impersonation ## AI-driven social engineering AI can make impersonation and phishing more convincing and difficult to detect. SilentGrid tests these tactics: ### AI-generated phishing Highly personalised emails that bypass traditional filters ### Deepfake vishing Voice cloning to impersonate executives and trusted contacts ### Automated profiling AI-driven reconnaissance to build convincing attack profiles ## Our tailored approach Each engagement is tailored to your organisation, based on the threats it faces, industry risks and target profiles. The engagement follows these steps: ### Define objectives - Align testing with your security goals and compliance requirements ### Select targets - Focus on high-risk departments or test organisation-wide ### Customise scenarios - Create realistic attacks based on your industry and threats ### Control intensity - Graduate from basic to advanced techniques as awareness improves ### Measure progress - Track improvements over time with repeat assessments ### Enable learning - Turn failures into teachable moments without punishment ## Deliverables and reporting Reporting documents campaign results and recommended changes to awareness training and verification procedures: ### Campaign results analysis Detailed metrics on click rates, credential submissions, and user responses ### Risk assessment report Department and role-based vulnerability analysis with targeted recommendations ### Training recommendations Customised security awareness training based on identified weaknesses ### Process improvements Updates to verification procedures and incident response protocols ## Common questions ### What is social engineering testing? A social engineering assessment tests a workforce the way an attacker would target it: through email phishing, voice phishing, SMS, baiting with USB drives and physical attempts such as tailgating and badge cloning, including AI-generated phishing and deepfake voice. Scenarios are built around your industry and chosen target groups, and failures are treated as teachable moments, without punishment. ### What does social engineering testing cover? Email phishing against individuals, departments or executives, voice phishing impersonating IT, HR or management, SMS attacks, physical security testing, baiting with USB drives and rogue devices, and AI-enhanced techniques. ### Do you test physical security as well? Yes. Tailgating attempts, badge cloning and physical access controls are tested, along with baiting attacks that deploy USB drives and rogue devices to see how employees respond to physical lures. ### How do you simulate AI-driven attacks? Through AI-generated phishing emails that are highly personalised enough to bypass traditional filters, deepfake vishing that clones voices to impersonate executives and trusted contacts, and automated profiling that builds convincing attack profiles. ### Can we choose who is targeted? Yes. Targets are selected with you: testing can focus on high-risk departments or run organisation-wide, and scenarios are customised to your industry and the threats it faces. ### Is this used to punish employees who fail? No. The engagement is designed to turn failures into teachable moments without punishment, and the intensity graduates from basic to advanced techniques as awareness improves. ### How do we measure whether awareness is improving? Repeat assessments track improvements over time, supported by campaign metrics on click rates, credential submissions and user responses, broken down by department and role. ### What do we receive at the end? A campaign results analysis, a department and role-based risk assessment, customised security awareness training recommendations, and process improvements for verification procedures and incident response protocols. --- Source page: https://www.silentgrid.com/adversary-simulation/social-engineering Text file: https://www.silentgrid.com/txt/social-engineering.md Generated from the SilentGrid site source on 2026-10-13. Do not edit by hand. ============================================================================== # Ransomware Simulation Canonical name: Ransomware Simulation Family: Adversary simulation Page: https://www.silentgrid.com/adversary-simulation/ransomware-simulation ## Description Controlled ransomware attack simulation to test your prevention, detection, and recovery capabilities. ## Where it sits Adversary simulation catalogue: https://www.silentgrid.com/adversary-simulation All 20 services in text: https://www.silentgrid.com/txt/services.md Choosing an engagement: https://www.silentgrid.com/txt/choosing-a-test.md Scoping contact: https://www.silentgrid.com/contact Scope, duration and pricing are agreed during scoping. The sections below are the service page itself: approach, methodology, deliverables and common questions. ## Testing your defences against encryption-based attacks Ransomware remains one of the most disruptive and costly cyber threats organisations face. Attacks combine data exfiltration, targeted encryption, and multi-stage extortion techniques. SilentGrid's Ransomware Simulation uses custom-built ransomware to safely replicate the encryption of local folders, network shares, and critical paths, simulating the full lifecycle of modern ransomware attacks. The controlled simulation measures detection, response and containment under realistic attack conditions, without risking production environments. ## Why simulate ransomware attacks? Ransomware simulations expose weaknesses in endpoint security, SIEM alerting, EDR configurations, and response workflows, so those gaps can be addressed before a real attack. ### Double extortion Attackers encrypt data while exfiltrating for additional leverage ### Targeted campaigns Modern gangs conduct thorough reconnaissance for high-value assets ### Rapid impact Ransomware spreads laterally, encrypting critical data in minutes if undetected ## Is ransomware simulation the right fit? The simulation measures how detection, containment and recovery hold up against encryption, so it assumes those controls exist and are worth testing. Where the question is how an attacker would reach that position in the first place, assumed breach or red teaming answers it. Ransomware simulation is ideal for organisations that - Manage high-value data or operate in targeted industries (finance, healthcare, critical infrastructure) - Have SIEM, EDR, and incident response processes that need validation - Want to test network segmentation and endpoint protections against encryption threats - Require hands-on experience to train SOC analysts and response teams ## Our custom ransomware approach SilentGrid uses internally developed ransomware that mimics real-world payloads: ### Safe execution Designed to safely encrypt files without destructive impact: files are restorable post-simulation ### Controlled environment Executed in sandbox environments, isolated networks, or dedicated testing systems ### Local and network testing Encrypts files on local machines, remote shares, and critical paths to simulate lateral spread ### Payload flexibility Tailored to match your environment, testing different payload delivery mechanisms ## How we simulate ransomware Our simulation tests your security stack's effectiveness at every stage of a ransomware attack: ### Initial execution - Testing detection of ransomware payload delivery and initial execution ### File encryption - Monitoring response to active file encryption across local and network drives ### Lateral movement - Assessing containment of ransomware spread to network shares and endpoints ### Detection speed - Measuring time from initial execution to detection and response ### Containment actions - Evaluating effectiveness of isolation and remediation procedures ### Recovery testing - Validating backup and recovery processes post-encryption ## Benefits of ransomware simulation ### Test real-world scenarios Experience ransomware attacks safely and realistically in controlled environments ### Identify detection gaps Uncover blind spots in EDR, SIEM, and incident response processes ### Strengthen containment Assess your ability to contain ransomware spread across endpoints and networks ### Improve response readiness Equip SOC and IR teams with real-world experience managing ransomware incidents ## Deliverables and reporting Reporting documents detection, containment and response findings, with guidance to strengthen your ransomware defences: ### Detection and response gaps Identification of missed detections, slow responses, and containment delays ### Endpoint security evaluation Performance assessment of EDR, antivirus, and file integrity monitoring tools ### Incident response recommendations Tactical guidance on improving ransomware readiness and remediation workflows ### Executive summary High-level overview detailing potential business impacts and strategic risk mitigations ## Common questions ### What is a ransomware simulation? A ransomware simulation tests an organisation the way a ransomware operator would, using internally developed ransomware: files on local machines, network shares and critical paths are encrypted in sandbox environments, isolated networks or dedicated test systems, then restored. The exercise measures how quickly execution is detected, whether the spread is contained, and whether backup and recovery work afterwards. ### Is the simulation safe to run? Yes. The ransomware is designed to encrypt files without destructive impact and the files are restorable after the simulation. It runs in sandbox environments, isolated networks or dedicated testing systems rather than production. ### What ransomware is used? Internally developed ransomware built to mimic real-world payloads. It is tailored to match your environment and can test different payload delivery mechanisms. ### What does the simulation test? Every stage of a ransomware attack: payload delivery and initial execution, file encryption across local and network drives, lateral spread to shares and endpoints, the time from execution to detection, the effectiveness of isolation and remediation, and backup and recovery afterwards. ### Does it encrypt network shares as well as local files? Yes. Files are encrypted on local machines, remote shares and critical paths so that lateral spread is simulated rather than assumed. ### Why simulate ransomware rather than rely on existing controls? Simulations expose weaknesses in endpoint security, SIEM alerting, EDR configurations and response workflows, so those gaps can be addressed before a real attack. Modern campaigns combine double extortion, targeted reconnaissance and lateral spread that encrypts critical data in minutes if undetected. ### Does it help train our SOC and incident response teams? Yes. The exercise gives SOC and IR teams hands-on experience managing a ransomware incident. ### What do we receive at the end? A report identifying missed detections, slow responses and containment delays, a performance assessment of EDR, antivirus and file integrity monitoring, tactical incident response recommendations, and an executive summary covering business impact. --- Source page: https://www.silentgrid.com/adversary-simulation/ransomware-simulation Text file: https://www.silentgrid.com/txt/ransomware-simulation.md Generated from the SilentGrid site source on 2026-10-13. Do not edit by hand. ============================================================================== # Cloud Assumed Breach Canonical name: Cloud Assumed Breach Family: Adversary simulation Page: https://www.silentgrid.com/adversary-simulation/cloud-assumed-breach ## Description Specialised post-compromise assessment for cloud environments, testing cloud-native security controls and response. ## Where it sits Adversary simulation catalogue: https://www.silentgrid.com/adversary-simulation All 20 services in text: https://www.silentgrid.com/txt/services.md Choosing an engagement: https://www.silentgrid.com/txt/choosing-a-test.md Scoping contact: https://www.silentgrid.com/contact Scope, duration and pricing are agreed during scoping. The sections below are the service page itself: approach, methodology, deliverables and common questions. ## Testing resilience in cloud environments Cloud environments have attack paths that differ from on-premises infrastructure. Adversaries use identity-based attacks, misconfigured resources, insecure APIs, and over-permissioned accounts to move laterally and escalate privileges within cloud platforms. SilentGrid's Cloud Assumed Breach simulates post-compromise scenarios, starting from the premise that an adversary has already gained initial cloud access. The objective is to test your detection, response, and mitigation capabilities against internal cloud threats and identity-based compromises across AWS, Azure, GCP, and multi-cloud environments. ## Why cloud assumed breach is critical Cloud providers offer platform security controls, but misconfigurations, poor visibility and excessive trust relationships can still give attackers access. ### Identity is the new perimeter A single compromised identity can lead to widespread breach ### Cloud misconfigurations Remain the leading cause of cloud breaches ### Over-permissioned accounts Allow attackers to move laterally across environments ### Poor visibility In cloud environments, hampers detection and response ## Is cloud assumed breach the right fit? The simulation begins with cloud access already in an attacker's hands, so it suits organisations whose critical workloads and identities live in the cloud. Where on-premises networks are the environment under question, assumed breach testing covers that ground instead. Cloud assumed breach fits organisations that - Operate heavily in AWS, Azure, GCP, or multi-cloud environments - Need to test the effectiveness of cloud-native security controls - Want to validate identity and access management (IAM) security - Seek to simulate post-compromise scenarios and lateral movement risks ## Our cloud testing methodology SilentGrid uses real-world adversary tactics to simulate attackers operating within compromised cloud accounts. ### Establishing initial foothold - Simulate compromised access keys, service tokens, or OAuth tokens - Insider threat scenarios with existing cloud credentials - Compromised developer accounts or stolen API keys ### Privilege escalation and lateral movement - Abuse IAM policies, trust relationships, and role assumption paths - Identify over-permissioned roles and misconfigured service identities - Exploit serverless functions, containers, and Kubernetes clusters ### Resource discovery and data exfiltration - Enumerate storage buckets, databases, and critical assets - Test for publicly exposed resources and data leaks - Simulate data exfiltration while bypassing logging and monitoring ### Persistence testing - Create rogue IAM roles, long-lived tokens, and shadow infrastructure - Evaluate visibility in cloud monitoring solutions (CloudTrail, Azure Monitor, GCP Logging) ### Incident response validation - Trigger alerts through controlled exploitation to test SOC and IR workflows - Evaluate effectiveness of SIEM, CSPM, and EDR tools for cloud attacks ## Key attack scenarios simulated The scenarios replicate current cloud attack techniques used by adversaries: ### Cloud credential harvesting Testing for credential leaks, unprotected environment variables, and insecure repositories ### IAM privilege escalation Simulating abuse of role chaining, misconfigured trust policies, and role assumption paths ### Cloud lateral movement Exploiting cloud-native services, containers, and serverless functions for pivoting ### Data breach simulation Testing for open storage buckets, misconfigured databases, and exfiltration paths ### Serverless and API exploitation Targeting Lambda functions, API gateways, and microservices to expand access ### Multi-cloud attack paths Testing cross-cloud attack scenarios in hybrid and multi-cloud environments ## Key benefits ### Expose cloud-specific attack paths Test for misconfigurations, unprotected APIs, and privilege escalation paths unique to cloud ### Validate cloud security posture Assess how well your cloud configurations defend against identity-based threats ### Enhance incident response Improve cloud SOC workflows, alerting pipelines, and incident containment strategies ### Continuous improvement Receive iterative feedback and re-testing to ensure vulnerabilities are fully addressed ## Deliverables and reporting Cloud assumed breach reporting documents attack paths and exploited misconfigurations, with guidance for remediation: ### Attack path documentation Detailed breakdown of attack paths, privilege escalation, and exploited misconfigurations ### Cloud IAM analysis Identifying over-permissioned accounts, misaligned roles, and unnecessary privileges ### Persistence techniques report Demonstrations of how adversaries establish long-term access in cloud environments ### Incident response recommendations Strategic guidance to improve cloud logging, monitoring, and detection rules ## Common questions ### What is a cloud assumed breach? A cloud assumed breach tests a cloud estate the way an attacker holding stolen cloud access would: it starts from compromised access keys, tokens or a developer account in AWS, Azure or GCP, then abuses IAM policies, trust relationships and over-permissioned roles to reach data, while measuring what CloudTrail, Azure Monitor, GCP Logging and your SOC detect. ### Which cloud platforms do you test? AWS, Azure and GCP, including hybrid and multi-cloud environments where cross-cloud attack paths are tested in their own right. ### Where does the simulation start? From a simulated compromise of access keys, service tokens or OAuth tokens, an insider scenario using existing cloud credentials, or a compromised developer account or stolen API key. ### What does the testing cover? Identity through to data: IAM policies, trust relationships and role assumption paths, over-permissioned roles and misconfigured service identities, serverless functions, containers and Kubernetes clusters, and storage buckets, databases and other critical assets. ### Our cloud provider secures the platform. Why is this needed? Cloud providers offer platform security controls, but misconfigurations, poor visibility and excessive trust relationships on the customer side can still give attackers access. ### Does the exercise test detection and response? Yes. Alerts are triggered through controlled exploitation to test SOC and IR workflows, and the effectiveness of SIEM, CSPM and EDR tooling for cloud attacks is evaluated, along with visibility in CloudTrail, Azure Monitor and GCP Logging. ### What do we receive at the end? Attack path documentation covering privilege escalation and the misconfigurations exploited, a cloud IAM analysis, a persistence techniques report, and incident response recommendations for cloud logging, monitoring and detection rules. --- Source page: https://www.silentgrid.com/adversary-simulation/cloud-assumed-breach Text file: https://www.silentgrid.com/txt/cloud-assumed-breach.md Generated from the SilentGrid site source on 2026-10-13. Do not edit by hand. ============================================================================== # OT/ICS Adversary Simulation Canonical name: OT/ICS Adversary Simulation Family: Adversary simulation Page: https://www.silentgrid.com/adversary-simulation/ot-ics ## Description Specialised security assessment for operational technology and industrial control systems with safety-first approach. ## Where it sits Adversary simulation catalogue: https://www.silentgrid.com/adversary-simulation All 20 services in text: https://www.silentgrid.com/txt/services.md Choosing an engagement: https://www.silentgrid.com/txt/choosing-a-test.md Scoping contact: https://www.silentgrid.com/contact Scope, duration and pricing are agreed during scoping. The sections below are the service page itself: approach, methodology, deliverables and common questions. ## Protecting critical infrastructure Operational Technology (OT) environments, including SCADA, ICS, and industrial systems, are increasingly interconnected with IT networks, exposing them to new threats. Adversaries targeting critical infrastructure seek to exploit this convergence, breaching IT environments to pivot into OT systems with the goal of disrupting or manipulating industrial processes. SilentGrid's OT/ICS Adversary Simulation replicates these attack paths, testing how effectively your organisation's segmentation, monitoring, and response capabilities prevent adversaries from bridging into OT environments. Our engagements uncover segmentation weaknesses, misconfigured firewalls, and insufficient network controls that expose OT to external compromise. ## Why OT/ICS security matters Traditionally isolated OT systems are now integrated with IT networks to enable efficiency, automation, and remote monitoring. This creates new attack surfaces for adversaries capable of pivoting from the IT side. ### IT-OT convergence Creates new attack surfaces for adversaries ### Ransomware groups Increasingly target OT environments for operational disruption ### Nation-state actors Seek to manipulate ICS protocols and gain persistence ### Operational impact Breaches can lead to production halts, physical damage, and safety incidents ## Is OT/ICS adversary simulation the right fit? The exercise is built around the IT-OT boundary, so it assumes there is industrial process to protect and a corporate network connected to it. Where the environment is corporate IT alone, assumed breach or red teaming covers the same ground without the industrial scope. This service is ideal for organisations that - Operate ICS, SCADA, or industrial networks managing critical infrastructure - Have IT-OT converged environments but lack visibility into lateral movement risks - Need to assess firewall and segmentation controls at the IT-OT boundary - Are concerned about nation-state threats or targeted ransomware disrupting operations ## OT adversary simulation methodology SilentGrid follows the lifecycle of real-world OT-focused attacks, from IT compromise through to simulated industrial impact. ### Reconnaissance and target profiling - Map the IT-OT boundary and interaction points - Perform OSINT and network enumeration to locate exposed remote access, HMIs, and ICS interfaces ### Initial compromise (IT environment) - Simulate initial IT compromise through phishing, credential theft, or endpoint exploitation - Establish footholds in IT environments with the goal of reaching ICS assets ### Lateral movement to OT networks - Attempt to bypass segmentation through dual-homed devices, misconfigured firewalls - Leverage RDP, SSH, SMB, and industrial protocols (Modbus, DNP3, OPC UA) to move laterally ### Persistence and control escalation - Deploy custom ICS-focused malware or simulate implanting rogue scripts in PLCs - Attempt to modify ladder logic, SCADA parameters, or issue rogue actuator commands in testing ### Critical impact and safety testing - Simulate manipulation of critical assets without disrupting live operations - Validate that safety instrumentation systems (SIS) and fail-safes engage properly ## Key engagement objectives OT/ICS simulations reflect the tactics of advanced persistent threats, ransomware actors, and insider threats: ### Identify IT-to-OT pivoting paths Discover how adversaries can move from corporate networks to industrial systems ### Simulate SCADA and PLC attacks Test resilience of control systems against targeted manipulation ### Test segmentation controls Validate effectiveness of firewalls and network separation ### Assess incident response Evaluate readiness for OT-specific security incidents ## Key benefits of OT adversary simulation ### Identify segmentation gaps Test the effectiveness of firewalls, VLANs, and segmentation rules ### Expose dual-homed devices Discover insecure engineering laptops, remote access solutions, and bridging devices ### Validate OT incident response Evaluate your ability to detect, respond to, and contain OT-targeted attacks ### Protect critical operations Ensure industrial processes and safety mechanisms are resilient against compromise ## Deliverables and reporting SilentGrid reports document the technical attack paths, segmentation gaps and response findings, with guidance for protecting industrial environments: ### Attack path documentation Full breakdown of how adversaries moved from IT to OT environments ### OT segmentation analysis Identification of firewall misconfigurations, dual-homed devices, and network paths ### Critical vulnerability report ICS-specific misconfigurations, insecure protocols, and device-level weaknesses ### Incident response evaluation Assessment of your team's ability to detect and contain OT-targeted attacks ## Common questions ### What is OT/ICS adversary simulation? OT/ICS adversary simulation tests critical infrastructure the way an attacker targeting industrial operations would: it starts with a compromise of the corporate IT network and tries to cross into OT over RDP, SSH, SMB and industrial protocols such as Modbus, DNP3 and OPC UA. Manipulation of SCADA and PLC assets is simulated without disrupting live operations. ### What does an OT/ICS adversary simulation test? It replicates the attack paths adversaries use to breach an IT environment and pivot into OT, testing how effectively your segmentation, monitoring and response capabilities prevent that bridge from being crossed. ### Will testing disrupt live operations? No. Manipulation of critical assets is simulated without disrupting live operations, and part of the exercise is validating that safety instrumentation systems and fail-safes engage properly. ### Where does the simulation start? In the IT environment, with a simulated initial compromise through phishing, credential theft or endpoint exploitation. Footholds are established with the goal of reaching ICS assets, after which segmentation at the IT-OT boundary is tested. ### Which industrial protocols and systems are covered? Lateral movement is attempted over RDP, SSH, SMB and industrial protocols including Modbus, DNP3 and OPC UA, and the exercise covers SCADA parameters, PLC logic, HMIs and exposed remote access. ### Why does OT need testing if it used to be isolated? Traditionally isolated OT systems are now integrated with IT networks to enable efficiency, automation and remote monitoring. That convergence creates new attack surfaces for adversaries capable of pivoting from the IT side. ### Does the exercise test our detection and response? Yes. Readiness for OT-specific security incidents is assessed, including your team's ability to detect, respond to and contain attacks that target industrial systems. ### What do we receive at the end? Attack path documentation covering the move from IT to OT, an OT segmentation analysis identifying firewall misconfigurations and dual-homed devices, a critical vulnerability report on ICS-specific weaknesses, and an incident response evaluation. --- Source page: https://www.silentgrid.com/adversary-simulation/ot-ics Text file: https://www.silentgrid.com/txt/ot-ics.md Generated from the SilentGrid site source on 2026-10-13. Do not edit by hand. ============================================================================== # Supply Chain Attack Assumed Breach Canonical name: Supply Chain Attack Assumed Breach Family: Adversary simulation Page: https://www.silentgrid.com/adversary-simulation/supply-chain-assumed-breach ## Description Start from a compromised developer account and establish what an attacker could reach, modelling a backdoored software dependency. ## Where it sits Adversary simulation catalogue: https://www.silentgrid.com/adversary-simulation All 20 services in text: https://www.silentgrid.com/txt/services.md Choosing an engagement: https://www.silentgrid.com/txt/choosing-a-test.md Scoping contact: https://www.silentgrid.com/contact Scope, duration and pricing are agreed during scoping. The sections below are the service page itself: approach, methodology, deliverables and common questions. Software dependencies have become a direct route to developer accounts, and developers usually hold more privileged access than a typical end user. A backdoored open-source package is a functional version of legitimate software with harmful logic embedded, installed as part of routine local development. Once a compromised package enters a development environment it can persist undetected while work continues as normal, and in many cases the compromise stays invisible until significant damage has been done. The exercise starts after the initial compromise, modelling access that arrives without warning. It tests what a threat actor could achieve from the developer's device and whether existing controls would detect or contain the activity. Further reading: what follows a compromised dependency, and the dependency compromise exposure worksheet for mapping your own exposure. ## Why this route matters Compromise typically occurs when a developer installs a package from a public repository without scrutinising the underlying logic. The open nature of these ecosystems, and the perceived trustworthiness of publicly readable source code, gives a threat actor a quiet foothold inside the organisation. ### Privileged by default Developer accounts commonly reach source control, pipelines and cloud consoles that ordinary user accounts never touch. ### Quiet persistence A compromised dependency keeps working as intended, so nothing about day-to-day development looks wrong. ### An actively used route Campaigns attributed to financially motivated groups have deliberately targeted widely used packages in standard development workflows. ### Unclear blast radius Most organisations cannot say with confidence what a single compromised developer laptop would expose. ## Is a supply chain assumed breach the right fit? It suits organisations whose developers pull from public package repositories and whose developer accounts reach systems that matter. A supply chain assumed breach fits when - Developers install packages from public repositories as part of normal work - Developer accounts reach source control, CI/CD or a cloud environment - Endpoint and identity controls are deployed and need testing - Evidence is needed of the access an attacker could attain ## How the engagement runs Five stages, from agreeing the account to model through to pursuing the objectives it can reach. ### Agree the account to model - Your organisation designates a developer account and a system representative of a real profile , with standard controls enabled - The choice directly shapes the attack paths explored and is agreed during preparation - Candidates include the most common developer role, a junior developer, a contractor or remote developer, or a role siloed to one team - Permissions are best cloned from an existing user so the exercise reflects access a real attacker would obtain ### Deploy the simulated dependency - SilentGrid develops Python and Node.js packages tailored to the environment - Each carries an embedded command-and-control payload that runs when the module is imported by a local program - This models the behaviour of a backdoored dependency delivering an implant, without touching any public package registry ### Establish the foothold - The engagement begins with all security controls fully enforced , including EDR, ITDR, and firewall and network monitoring - Detections and blocks at this stage are recorded as positive observations - Concessions are then introduced so assessment can continue past the initial foothold ### Assess what the account reaches - Cloud environments across platforms such as AWS, Azure and GCP - CI/CD platforms such as Jenkins, Octopus Deploy or Azure Pipelines - Source code repositories such as GitHub, GitLab or Bitbucket - Knowledge repositories such as Jira, Confluence and SharePoint - Identity platforms such as Microsoft Entra ID and Okta, and on-premises Active Directory ### Pursue the agreed objectives - Map the services and resources the compromised account can reach, and identify viable paths for lateral movement and privilege escalation - Prioritise paths leading to core business systems, sensitive data or other targets that demonstrate tangible impact - Activities may include evading endpoint and network controls, obtaining domain credentials, escalating to privileged accounts, moving between network segments, and staging or simulating exfiltration of sensitive data ## Controls and concessions Running the engagement against every control is valuable in itself, but where those controls block the simulated implant, assessment of the wider environment stops at the first host. Concessions keep the exercise moving without discarding that first result. ### Enforced at the start Controls run fully enforced until they detect or block the implant, and whatever they catch is written up as a positive observation. ### Applied narrowly Concessions may place EDR in monitoring-only mode on the foothold host, or allow-list command-and-control infrastructure. ### Limited to the foothold Concessions are not expected to apply to other hosts reached during the engagement, only the host used for initial access. ### Detection, not stealth Operators remain undetected where viable, but effort is not spent on evasion at the cost of reaching the agreed objectives. ## What you provide The engagement requires an account with the access and tooling of a real developer, so the findings reflect that role. ### A representative account Username and password, multi-factor authentication, and group and role assignments cloned from a real developer profile. ### A name that fits The account should carry a plausible name rather than one identifying the assigned SilentGrid operators. ### A representative system An end-user laptop with VPN access, or a VDI development environment, connected to the corporate network. ### Developer tooling The account should be able to install the tooling a developer in that environment could install, such as Python and Node.js. ### Matching application access Messaging, knowledge, CI/CD and source control access aligned with the modelled role, across cloud identity and Active Directory where applicable. ### Any exclusions Employees, systems or services that must stay out of scope are agreed with SilentGrid before the engagement begins. ## Deliverables and reporting Reporting covers what was reached, how it was reached, and what held. Positive observations are recorded alongside findings. ### Executive summary A high-level, non-technical account of the exercise and what it found. ### Technical summary The objectives, the concessions applied, positive observations and a summary of findings. ### Positive observations Security controls and mechanisms that worked during the engagement. ### Attack narrative A step-by-step account of the attack from the operator's perspective, in the order it happened. ### Recommendations Practical changes to improve resilience, prioritised against the paths that were actually attainable. ### Appendices Remaining cleanup items, compromised accounts, public IP addresses, file hashes and command-and-control details. ## Common questions ### What is a supply chain attack assumed breach? A supply chain attack assumed breach tests an organisation the way an attacker behind a backdoored software package would: SilentGrid builds a Python or Node.js dependency with an embedded command-and-control payload, runs it on a representative developer's device without touching any public registry, then maps what that account reaches across source control, CI/CD, cloud and identity platforms. ### Do you simulate the supply chain compromise itself? No. The exercise assumes the initial access has already happened, because in practice a backdoored dependency arrives without warning. Testing begins from the developer's device and measures what follows. ### What do we need to provide? A developer account and a representative system with standard controls enabled, provisioned to mirror the roles, privileges and access rights of a real developer. Any employees, systems or services that must be excluded are agreed beforehand. ### Which developer account should we choose? The choice shapes the attack paths explored, so it is worth deliberating. A junior developer may be the more likely target for an inadvertent install; a senior or specialist developer is more security-aware but usually holds access to core systems and source repositories. Both are valid, and they answer different questions. ### Do you ask us to turn our security controls off? The engagement starts with controls fully enforced, and anything they detect or block is recorded as a positive observation. Concessions are then introduced so assessment can continue past the first host. They may include placing EDR in monitoring-only mode on the foothold host or allow-listing command-and-control infrastructure, and are not expected to apply to other hosts. ### Will you try to stay undetected? Operators remain undetected where that is viable, but effort is not spent on evasion at the cost of reaching the agreed objectives within the engagement. Where a security team is monitoring, the activity generated is useful for validating and tuning alerting and detection rules. ### How are the objectives decided? They are agreed during scoping and reflect what would demonstrate real impact in your environment. Access to sensitive data, a primary code repository, a connected cloud environment or a specific business system are all common starting points. ### What do we receive at the end? A report covering an executive summary, a technical summary, positive observations, a step-by-step attack narrative, recommendations, and appendices including cleanup items and indicators from the engagement. --- Source page: https://www.silentgrid.com/adversary-simulation/supply-chain-assumed-breach Text file: https://www.silentgrid.com/txt/supply-chain-assumed-breach.md Generated from the SilentGrid site source on 2026-10-13. Do not edit by hand. ============================================================================== # Scattered Spider Adversary Emulation Canonical name: Scattered Spider Adversary Emulation Family: Adversary simulation Page: https://www.silentgrid.com/adversary-simulation/scattered-spider-emulation ## Description A collaborative purple team exercise running test cases drawn from Scattered Spider’s published tactics, across the full lifecycle of their attacks. ## Where it sits Adversary simulation catalogue: https://www.silentgrid.com/adversary-simulation All 20 services in text: https://www.silentgrid.com/txt/services.md Choosing an engagement: https://www.silentgrid.com/txt/choosing-a-test.md Scoping contact: https://www.silentgrid.com/contact Scope, duration and pricing are agreed during scoping. The sections below are the service page itself: approach, methodology, deliverables and common questions. Scattered Spider (also tracked as Octo Tempest, UNC3944, Starfraud, Scatter Swine and Muddled Libra) is a financially motivated group whose methods are unusually well documented. That makes them a practical benchmark: the tactics are published, so your controls can be measured against them one technique at a time. In this collaborative exercise, SilentGrid operators work alongside your security team to execute scenarios covering the full lifecycle of a typical Scattered Spider attack, assessing for each test case whether your current controls prevent it, detect it, or neither. The security team uses its own tooling throughout, in a safe and controlled setting. The result is a clear picture of where controls hold, where telemetry exists but no alert fires, and where nothing is seen at all. ## Where the scenarios come from Scenarios and test cases are derived from published threat intelligence on the group. The sources are named in the report so findings can be traced back to them. ### Microsoft Octo Tempest analysis covering extortion, encryption and destruction activity. ### CISA Advisory AA23-320A on Scattered Spider tactics, techniques and procedures. ### Google Cloud UNC3944 hardening recommendations, and reporting on SMS phishing, SIM swapping and ransomware. ### Permiso LUCR-3 research on the group's activity across SaaS and cloud environments. ## Is a Scattered Spider emulation the right fit? It suits organisations with a security team able to take part, who want technique-level evidence of what their controls cover. A Scattered Spider emulation fits when - A security team is in place and able to take part day to day - Identity, endpoint and cloud controls are deployed and you want them measured - Help desk processes handle account and MFA changes - Evidence is needed of coverage for specific techniques ## The scenarios Six scenarios covering the full lifecycle of a typical attack, from reconnaissance to an administrator account. ### Discovery and resource development - Reconnaissance to build a picture of the organisation's external attack surface - Registration of a look-alike domain for use in later phishing test cases ### Compromised user credentials - Techniques used after obtaining the username and password of a business-as-usual account - Attempts to reach internet-facing systems and services - Multi-factor authentication bypasses, and discovery where possible ### Compromised credentials and SIM swap - A consultant's phone number is assigned to the account to simulate a SIM swap - Test cases probe whether phone-based authentication can be used to authenticate or reset credentials ### Compromised credentials, device and MFA - Assumes the account, end-user device and a factor of authentication are all under the actor's control - Focuses on discovery of cloud and on-premises assets , credential access and persistence ### Compromised help desk credentials - Scattered Spider frequently target help desk staff after an initial compromise - Test cases cover further discovery, credential access, persistence and privilege escalation from a help desk profile ### Compromised IT administrator account - The later stages of the group's attacks, spanning cloud and on-premises assets - Techniques requiring higher privileges, including hypervisor access, credential dumping on domain controllers and simulated exfiltration ## What we need from you The exercise requires active participation from your security team. A nominated point of contact should expect to give it roughly an hour a day. ### Representative accounts A business-as-usual account, a help desk account, and an account representative of a privileged systems administrator. ### Representative access A corporate end-user device, and network access matching what each of those three roles would normally have. ### Daily stand-up Someone available each day to keep the exercise moving, whether or not the nominated contact is free. ### Detection evidence Evidence relating to detections uploaded promptly. Where evidence is not provided in time, a technique may default to undetected. ### Retrospective review Reviewing tooling and telemetry to establish whether an undetected technique was nonetheless captured somewhere. ### A channel to work in A shared chat for the duration, provisioned by SilentGrid or an equivalent you prefer. ## What an emulation cannot tell you An emulation measures logging, detection and prevention for specific techniques in isolation. The results have these limits: ### Your team knows it is happening Because the exercise is collaborative, it cannot show how the organisation would respond under the pressure of a real incident. Red teaming answers that question. ### Actors change Coverage reflects the techniques the group has used to date. A future campaign may not look like the published record. ### Techniques, not campaigns Each test case is assessed on its own. Strong coverage across individual techniques is not the same as stopping a full attack chain. ### Scheduling shapes coverage Where account provisioning or environment constraints delay the work, SilentGrid agrees with you which test cases to prioritise. ## Deliverables and reporting Every test case is reported with its technical detail and result so coverage can be audited. ### Executive summary A high-level overview of the exercise, its objective, the results and the recommendations. ### Technical summary Threat intelligence summary, the scenarios run, concessions applied, positive observations and a recommendations summary. ### Findings Detailed findings describing each security issue, the risk it presents and how to remediate it. ### Test case results The technical detail and result of every executed test case, so coverage can be audited. ### Technical debrief A 60 to 90 minute report walkthrough for technical stakeholders, with time for questions. ## Common questions ### What is a Scattered Spider adversary emulation? A Scattered Spider adversary emulation tests an organisation's controls the way that group attacks: around 70 test cases drawn from published threat intelligence, run across six scenarios from reconnaissance and a simulated SIM swap to compromised help desk and administrator accounts. It is a collaborative purple team exercise, and each technique is recorded as prevented, detected or neither. ### Is this a red team exercise? No. It is a collaborative purple team exercise. Your security team knows it is running and takes part throughout, using their own tooling to detect and prevent the techniques as they are executed. If you want to know how the organisation responds without warning, red teaming is the engagement for that. ### How many test cases are run? Around 70, derived from individual tactics, techniques and procedures the group has used. Together the scenarios span the full lifecycle of a typical attack, from reconnaissance through to exfiltration. ### How long does it take? Typically four to five weeks. Where the environment, account provisioning or unexpected delays mean not every test case can be executed in that window, SilentGrid works with you to decide which ones matter most. ### Where do the scenarios come from? Published threat intelligence on the group, including Microsoft's Octo Tempest analysis, CISA advisory AA23-320A, Google Cloud's UNC3944 reporting and Permiso's LUCR-3 research. The sources are cited so findings can be traced back to them. ### What does our team need to do? Nominate a point of contact who can give the exercise about an hour a day, attend a regular stand-up, upload evidence of detections promptly, and retrospectively review tooling to establish whether an undetected technique was captured somewhere. Where evidence is not supplied in time, a technique may be recorded as undetected. ### Do you actually perform a SIM swap? No. A SilentGrid consultant's phone number is assigned to the test account with your agreement, which reproduces the effect of a SIM swap without involving a carrier or a real person's service. ### What do we receive at the end? A report covering an executive summary, a technical summary with the threat intelligence behind the scenarios, detailed findings, and the technical result of every test case. A 60 to 90 minute technical debrief walks your team through it. --- Source page: https://www.silentgrid.com/adversary-simulation/scattered-spider-emulation Text file: https://www.silentgrid.com/txt/scattered-spider-emulation.md Generated from the SilentGrid site source on 2026-10-13. Do not edit by hand. ============================================================================== # Web Application and Services Canonical name: Web Application and Services Family: Penetration testing Category: Application and API Page: https://www.silentgrid.com/penetration-testing/web-application-and-services ## Description Identify and eliminate critical vulnerabilities in your web applications. ## Where it sits Penetration testing catalogue: https://www.silentgrid.com/penetration-testing All 20 services in text: https://www.silentgrid.com/txt/services.md Choosing an engagement: https://www.silentgrid.com/txt/choosing-a-test.md Scoping contact: https://www.silentgrid.com/contact Scope, duration and pricing are agreed during scoping. The sections below are the service page itself: approach, methodology, deliverables and common questions. ## Protecting your web applications and APIs Web applications and APIs are key attack vectors for adversaries, providing access to sensitive data and core systems. SilentGrid's Web Application and Services Penetration Testing identifies vulnerabilities that evade automated scans by simulating real-world attack scenarios. Hands-on testing informed by security research examines how modern web architectures withstand emerging attack techniques. ## What sets us apart ### Realistic threat simulation Consultants replicate attacker techniques to identify exploitable vulnerabilities and assess how applications withstand targeted attacks. ### Tailored for complex environments Each engagement is scoped around the application's architecture, frameworks and business logic so testing addresses risks specific to its technology stack. ### Advanced manual testing Deep manual testing combined with automation identifies hard-to-spot vulnerabilities that generic testing tools often overlook. We focus on uncovering complex flaws such as business logic errors, chained exploits, and misconfigurations that can't be detected through automation alone. ### Technical innovation SilentGrid investigates emerging web attack techniques through active research and custom tool development. The team develops tools to identify complex vulnerability chains across modern web applications and APIs. ## Methodology SilentGrid's methodology combines current adversarial techniques with established frameworks such as OWASP and ASVS (Application Security Verification Standard). These ensure comprehensive application coverage and assessment of critical vulnerabilities against recognised security standards. ### Reconnaissance and threat modelling - Mapping application components and services - Identifying potential attack vectors ### Automated and manual testing - Running automated scans to detect standard vulnerabilities - Performing detailed manual analysis to uncover complex flaws ### Exploitation and validation - Safely exploiting vulnerabilities to demonstrate real-world impacts ### Reporting and remediation - Delivering technical reports with clear remediation paths and development-friendly recommendations ## Code-assisted penetration testing Optional code-assisted assessments combine black-box testing with source code analysis to uncover issues that would be difficult or impossible to identify through black-box methods alone. ### Deeper analysis Access to source code allows consultants to identify vulnerabilities that are often invisible to standard black-box testing techniques. ### Improved coverage Source code analysis ensures thorough evaluation of security-sensitive areas. ### Customised insights Recommendations address your application's architecture and codebase so developers can fix the underlying flaws. ## Deliverables and reporting Reports give technical teams guidance for immediate remediation and executives a record of the risks and recommended actions. ### Comprehensive vulnerability report Detailed technical insights into risks ### Proof of concept (PoC) Demonstrations of vulnerability exploitation ### Remediation roadmap Prioritised, actionable fixes ### Executive summary High-level overview tailored for leadership ### Consultation and support Guidance to assist development teams during remediation ## Common questions ### What is web application penetration testing? Web application penetration testing examines an application and its APIs the way an attacker would: consultants map the components, combine automated scanning with manual testing to find business logic errors, chained exploits and misconfigurations, and safely exploit what they find to demonstrate impact. Testing aligns with OWASP and ASVS, and can be code-assisted where source code is available. ### What does a web application penetration test cover? Application components and services are mapped and threat modelled, then tested for vulnerabilities. Automated scans detect standard vulnerabilities and detailed manual analysis uncovers complex flaws such as business logic errors, chained exploits and misconfigurations that automation alone cannot detect. ### How is this different from an automated vulnerability scan? Automated scanning detects standard vulnerabilities. Deep manual testing identifies the hard-to-spot vulnerabilities that generic testing tools often overlook, and vulnerabilities are safely exploited to demonstrate real-world impact rather than reported as a scanner rating. ### Do you test APIs as well as the application itself? Yes. Web applications and APIs are both key attack vectors, and application components and services are mapped during reconnaissance so the assessment covers modern web architectures. ### Can you test with access to our source code? Yes. Code-assisted penetration testing combines traditional black-box testing with insights gained from source code analysis. It identifies vulnerabilities that are invisible to standard black-box techniques, ensures thorough evaluation of security-sensitive areas, and produces recommendations tailored to your architecture and codebase. ### What standards does the testing align with? The methodology reflects current adversarial techniques and aligns with established industry frameworks such as OWASP and the Application Security Verification Standard (ASVS), so assessments address the most critical vulnerabilities against recognised security standards. ### What do we receive at the end of the engagement? A comprehensive vulnerability report with detailed technical insight, proof-of-concept demonstrations, a prioritised remediation roadmap, an executive summary for leadership, and post-engagement consultation to assist development teams during remediation. ### How often should applications be retested? Ongoing penetration testing programs run in regular cycles, commonly every 6 or 12 months. Each cycle retests prior vulnerabilities, applies new attack methods and expands scope to cover new features and updates, which aligns security with your development pipeline. --- Source page: https://www.silentgrid.com/penetration-testing/web-application-and-services Text file: https://www.silentgrid.com/txt/web-application-and-services.md Generated from the SilentGrid site source on 2026-10-13. Do not edit by hand. ============================================================================== # Mobile Application Security Canonical name: Mobile Application Security Family: Penetration testing Category: Application and API Page: https://www.silentgrid.com/penetration-testing/mobile-application ## Description Identify and remediate vulnerabilities in your mobile applications to protect user data and prevent exploitation. ## Where it sits Penetration testing catalogue: https://www.silentgrid.com/penetration-testing All 20 services in text: https://www.silentgrid.com/txt/services.md Choosing an engagement: https://www.silentgrid.com/txt/choosing-a-test.md Scoping contact: https://www.silentgrid.com/contact Scope, duration and pricing are agreed during scoping. The sections below are the service page itself: approach, methodology, deliverables and common questions. ## Securing iOS and Android applications Mobile application attacks target user data, backend services and device security on iOS and Android platforms. Adversary techniques change as applications and platforms evolve. SilentGrid's Mobile Application Penetration Testing evaluates your apps from source code to runtime, identifying vulnerabilities that could lead to data leakage, unauthorised access, and compromised user privacy. Assessments ensure that both client-side and backend components are secure, safeguarding users and maintaining trust in your mobile ecosystem. ## Testing standards and frameworks SilentGrid's mobile penetration testing follows recognised industry frameworks, so each assessment is consistent and thorough. ### OWASP Mobile Application Security Verification Standard (MASVS) Comprehensive security requirements for mobile apps ### OWASP Mobile Security Testing Guide (MSTG) Industry-standard testing methodology for mobile applications ## Methodology Testing evaluates vulnerabilities across application code, device interactions, and backend communications. ### Static analysis and code review - Decompiling and analysing app code to uncover hardcoded secrets, insecure configurations, and weak cryptographic implementations - Identifying security flaws at the code level for iOS and Android - Reverse engineering to understand app logic and data flows ### Dynamic testing - Testing the application during runtime to identify vulnerabilities through reverse engineering, API manipulation, and runtime analysis ### API and backend service testing - Assessing the security of APIs, server communications, and data flows - Testing for unauthenticated access, weak authorisation and injection vulnerabilities ### Device and local data storage - Evaluating how sensitive data is stored on the device - Testing for data leakage, insecure local storage, and unprotected files or databases ### Network communication and encryption - Analysing network traffic to ensure encryption standards are followed - Testing for man-in-the-middle (MITM) vulnerabilities and insecure transport protocols ### Platform-specific vulnerabilities - iOS Keychain and Android Keystore analysis - Biometric authentication bypass testing - App permissions and privacy controls review - Deep linking and URL scheme testing - WebView security assessment - Push notification and background services security ## Why mobile security matters Mobile applications are increasingly targeted by adversaries due to their access to sensitive user data, device functionality, and backend services. A single vulnerability can compromise user data privacy, corporate intellectual property, and reputation and user trust. Proactive testing protects against these risks and ensures compliance with privacy regulations and app store security requirements. ## Deliverables and reporting Reports give developers and product teams detailed findings and remediation guidance, ensuring vulnerabilities are addressed swiftly and securely. ### Comprehensive vulnerability report Detailing vulnerabilities in the mobile app and backend services ### Proof of concept (PoC) Demonstrations of exploitable weaknesses and attack paths ### Remediation guidance Actionable steps for developers to resolve vulnerabilities across mobile platforms ### Executive summary High-level overview of risks and the application’s security posture ### Consultation and support Post-assessment guidance to help development teams address issues effectively ## Common questions ### What is mobile application penetration testing? Mobile application penetration testing examines an iOS or Android app the way an attacker would: decompiling and reverse engineering the build, manipulating it at runtime, inspecting what it stores on the device and sends over the network, and testing the APIs and backend services behind it. Source code is not required, and testing follows OWASP MASVS and the Mobile Security Testing Guide. ### What does mobile application testing cover? The application from source code to runtime, plus the APIs and backend services behind it. Both client-side and backend components are assessed, along with how data is stored on the device and transmitted over the network. ### Do you test both iOS and Android? Yes. Security flaws are identified at the code level on both platforms, including iOS Keychain and Android Keystore analysis, biometric authentication bypass, app permissions and privacy controls, deep linking and URL schemes, WebView security, and push notification and background service handling. ### Do you need our source code? No. App code is decompiled and analysed to uncover hardcoded secrets, insecure configurations and weak cryptographic implementations, and reverse engineering is used to understand app logic and data flows. ### Do you test the backend APIs as well? Yes. API security, server communications and data flows are assessed, including unauthenticated access, weak authorisation and injection vulnerabilities. ### What standards does the testing follow? The OWASP Mobile Application Security Verification Standard (MASVS) and the OWASP Mobile Security Testing Guide (MSTG). Adhering to these frameworks ensures thorough testing that meets recognised security benchmarks. ### Does testing help with app store and privacy requirements? Proactive testing protects against the risks to user data, intellectual property and reputation, and supports compliance with privacy regulations and app store security requirements. ### What do we receive at the end? A vulnerability report covering the app and its backend services, proof-of-concept demonstrations of exploitable weaknesses, remediation guidance written for developers, an executive summary, and post-assessment consultation. --- Source page: https://www.silentgrid.com/penetration-testing/mobile-application Text file: https://www.silentgrid.com/txt/mobile-application.md Generated from the SilentGrid site source on 2026-10-13. Do not edit by hand. ============================================================================== # Desktop Application Security Canonical name: Desktop Application Security Family: Penetration testing Category: Application and API Page: https://www.silentgrid.com/penetration-testing/desktop-application ## Description Identify and remediate vulnerabilities in your desktop applications to prevent exploitation and safeguard sensitive data. ## Where it sits Penetration testing catalogue: https://www.silentgrid.com/penetration-testing All 20 services in text: https://www.silentgrid.com/txt/services.md Choosing an engagement: https://www.silentgrid.com/txt/choosing-a-test.md Scoping contact: https://www.silentgrid.com/contact Scope, duration and pricing are agreed during scoping. The sections below are the service page itself: approach, methodology, deliverables and common questions. ## Securing desktop applications across all platforms Desktop applications handle sensitive data, business workflows and direct access to system resources. Attackers target vulnerabilities in application logic, local data storage, or interprocess communications. SilentGrid's Desktop Application Penetration Testing simulates real-world attack scenarios to uncover vulnerabilities that could lead to unauthorised code execution, privilege escalation, and data leakage. Testing across application and system layers helps organisations secure their desktop software and protect users across Windows, macOS, and Linux platforms. ## What sets us apart ### Platform-agnostic testing Testing covers Windows, macOS and Linux environments, identifying vulnerabilities across platforms and examining platform-specific attack vectors. ### Comprehensive application and system-level analysis Consultants evaluate desktop applications from installation to execution, testing for weaknesses that could compromise user environments, data integrity, or system security. ### Real-world exploit simulation SilentGrid simulates real-world attack techniques to identify vulnerabilities that could be exploited to gain unauthorised access, bypass controls, or escalate privileges within the operating system. ## Methodology SilentGrid's desktop penetration testing aligns with OWASP Application Security Verification Standard (ASVS) and draws on techniques from reverse engineering, exploit development, and secure coding practices. ### Static analysis and code review - Decompiling or reverse-engineering application binaries to identify vulnerabilities at the code level - Reviewing source code (when available) for insecure coding patterns, hardcoded credentials, and weak cryptographic implementations ### Dynamic testing and execution - Testing the application at runtime to detect misconfigurations, buffer overflows, and insecure memory handling - Assessing how the application interacts with system components and other processes ### Privilege escalation and local exploitation - Simulating privilege escalation attacks through exploited vulnerabilities - Testing for path traversal, DLL hijacking, and local privilege elevation opportunities ### File handling and data storage - Evaluating how sensitive data is stored within the application's local environment - Testing for data leakage, unencrypted files, and insecure configurations ### Interprocess communication (IPC) testing - Assessing communication between application components to identify vulnerabilities in IPC channels that could be exploited for lateral movement or privilege escalation ### API and backend interaction - Testing desktop applications that communicate with remote APIs or cloud services, ensuring data transmission and authentication flows are secure ## Why desktop application security matters Desktop applications often operate with elevated privileges, making them high-value targets for adversaries. Exploiting vulnerabilities within desktop software can lead to privilege escalation attacks, code execution at the operating system level, exfiltration of sensitive data and compromised user environments. Proactively addressing vulnerabilities prevents these risks and ensures desktop applications contribute to overall system security rather than becoming potential points of failure. ## Deliverables and reporting Reports give development teams exploitation evidence and remediation guidance for their desktop applications. ### Comprehensive vulnerability report Detailing identified vulnerabilities and potential exploitation paths ### Proof of concept (PoC) Demonstrations of successful exploit scenarios ### Remediation guidance Prioritised recommendations with actionable remediation steps ### Executive summary A high-level overview for stakeholders, outlining risks and recommended actions ### Consultation and support Ongoing support post-assessment to assist development teams in addressing vulnerabilities ## Common questions ### What is desktop application penetration testing? Desktop application penetration testing examines installed software on Windows, macOS or Linux the way an attacker would: reverse engineering the binaries, testing runtime behaviour, local data storage and interprocess communication, and attempting privilege escalation through flaws such as DLL hijacking. Source code review is optional, and any remote APIs or cloud services the application uses are tested too. ### Which platforms do you test? Windows, macOS and Linux, including the platform-specific attack vectors that differ between them. ### Do you need access to our source code? No. Application binaries are decompiled or reverse-engineered to identify vulnerabilities at the code level. Where source code is available, it is reviewed for insecure coding patterns, hardcoded credentials and weak cryptographic implementations. ### What kinds of vulnerabilities do you look for? Misconfigurations, buffer overflows and insecure memory handling at runtime, path traversal, DLL hijacking and local privilege elevation, insecure local data storage and unencrypted files, and weaknesses in interprocess communication channels. ### Do you test the backend the application talks to? Yes, where the application communicates with remote APIs or cloud services. Data transmission and authentication flows are assessed as part of the engagement. ### What standards does the testing follow? Testing aligns with the OWASP Application Security Verification Standard and draws on techniques from reverse engineering, exploit development and secure coding practices. ### Why do desktop applications need testing? They often operate with elevated privileges, which makes them high-value targets. Exploiting them can lead to privilege escalation, code execution at the operating system level, exfiltration of sensitive data and compromised user environments. ### What do we receive at the end? A comprehensive vulnerability report with exploitation paths, proof-of-concept demonstrations, prioritised remediation guidance, an executive summary for stakeholders, and post-assessment consultation for the development team. --- Source page: https://www.silentgrid.com/penetration-testing/desktop-application Text file: https://www.silentgrid.com/txt/desktop-application.md Generated from the SilentGrid site source on 2026-10-13. Do not edit by hand. ============================================================================== # External Infrastructure Canonical name: External Infrastructure Family: Penetration testing Category: Infrastructure and Cloud Page: https://www.silentgrid.com/penetration-testing/external-infrastructure ## Description Assess your internet-facing assets to identify vulnerabilities before attackers exploit them. ## Where it sits Penetration testing catalogue: https://www.silentgrid.com/penetration-testing All 20 services in text: https://www.silentgrid.com/txt/services.md Choosing an engagement: https://www.silentgrid.com/txt/choosing-a-test.md Scoping contact: https://www.silentgrid.com/contact Scope, duration and pricing are agreed during scoping. The sections below are the service page itself: approach, methodology, deliverables and common questions. ## Protecting your external attack surface External infrastructure exposes systems and services to attackers on the internet. Penetration testing examines vulnerabilities within targeted systems; broader, continuous assessment addresses the perimeter as it changes. SilentGrid's External Infrastructure Penetration Testing simulates real-world attack scenarios to assess the security of internet-facing systems, identifying misconfigurations, unpatched services, and potential entry points for adversaries. For a broader evaluation of the attack surface, Perimeter Assessment extends beyond traditional penetration testing, uncovering and cataloguing all internet-exposed assets across your environment. ## What sets us apart ### Real-world attack simulation Consultants use attacker techniques to identify and validate exploitable misconfigurations, outdated services and exposed entry points in external infrastructure. ### Focused testing or perimeter analysis External penetration testing targets specific systems or environments. A Perimeter Assessment examines your entire internet-facing footprint. This service identifies forgotten or misconfigured assets that could inadvertently expose your organisation to risk. ### Advanced manual testing Consultants combine detailed manual testing with automated scans to investigate chained exploits, overlooked misconfigurations and complex flaws that tools often miss. Findings include guidance to fix them. ### Technical innovation SilentGrid uses custom tooling and continuous research to investigate emerging attack vectors targeting external environments and adapt testing as adversary techniques change. ## Methodology SilentGrid's external penetration testing adheres to established frameworks such as OWASP, CIS Benchmarks, and NIST 800-53 to structure assessments against recognised security standards. ### Reconnaissance and asset mapping - Enumerating exposed systems, DNS records, and cloud resources - Identifying misconfigurations, open ports, and forgotten systems ### Vulnerability discovery and exploitation - Running automated scans and manual tests to uncover exploitable vulnerabilities - Validating and safely exploiting findings to demonstrate impact ### Privilege escalation and lateral movement - Assessing pathways from compromised external systems to internal environments - Identifying risks associated with exposed credentials, misconfigurations, and open services ### Reporting and remediation - Providing comprehensive, actionable reports designed to prioritise high-risk issues and outline remediation steps ## Deliverables and reporting Reports give technical teams remediation guidance and executive leadership a summary of risks and business impact. ### Comprehensive vulnerability report A detailed overview of all identified vulnerabilities, including severity and impact ### Proof of concept (PoC) Demonstrations validating critical vulnerabilities ### Remediation roadmap Clear and prioritised recommendations for remediation ### Executive summary A concise overview highlighting risks and the business impact of findings ### Consultation and retesting Post-engagement guidance and retesting to validate the effectiveness of remediation efforts ## Common questions ### What is external infrastructure penetration testing? External infrastructure penetration testing examines the internet-facing systems in an agreed scope the way an outside attacker would: enumerating exposed hosts, DNS records and cloud resources, finding misconfigurations and unpatched services, safely exploiting them to prove impact, and checking whether a compromised external system leads into the internal network. A perimeter assessment, by contrast, first discovers everything that is exposed. ### What does external infrastructure testing cover? Internet-facing systems within the agreed scope. Exposed systems, DNS records and cloud resources are enumerated, then tested for misconfigurations, unpatched services, open ports and forgotten systems that offer an entry point. ### How is this different from a perimeter assessment? External penetration testing targets specific systems or environments. A perimeter assessment examines your entire internet-facing footprint, uncovering and cataloguing assets, including forgotten or misconfigured ones you may not know about. ### Do you exploit the vulnerabilities you find? Yes. Findings are validated and safely exploited to demonstrate impact, which also rules out false positives before anything is reported. ### Do you test whether external access leads inside? Yes. Pathways from compromised external systems into internal environments are assessed, along with the risks from exposed credentials, misconfigurations and open services. ### What standards does the testing follow? Assessments adhere to established frameworks including OWASP, the CIS Benchmarks and NIST 800-53, in line with recognised industry practice. ### Can testing run on an ongoing basis? Yes. Continuous external infrastructure assessments run in regular cycles, commonly every 6 or 12 months, retesting prior vulnerabilities, assessing newly deployed infrastructure and applying emerging attack techniques as they appear. ### What do we receive at the end? A comprehensive vulnerability report covering severity and impact, proof-of-concept demonstrations for critical findings, a prioritised remediation roadmap, an executive summary, and post-engagement consultation with retesting to confirm fixes. --- Source page: https://www.silentgrid.com/penetration-testing/external-infrastructure Text file: https://www.silentgrid.com/txt/external-infrastructure.md Generated from the SilentGrid site source on 2026-10-13. Do not edit by hand. ============================================================================== # Internal Infrastructure Canonical name: Internal Infrastructure Family: Penetration testing Category: Infrastructure and Cloud Page: https://www.silentgrid.com/penetration-testing/internal-infrastructure ## Description Identify and remediate vulnerabilities within your internal network to prevent data breaches and unauthorised lateral movement. ## Where it sits Penetration testing catalogue: https://www.silentgrid.com/penetration-testing All 20 services in text: https://www.silentgrid.com/txt/services.md Choosing an engagement: https://www.silentgrid.com/txt/choosing-a-test.md Scoping contact: https://www.silentgrid.com/contact Scope, duration and pricing are agreed during scoping. The sections below are the service page itself: approach, methodology, deliverables and common questions. ## Securing your internal networks Unpatched systems, misconfigurations and weak access controls within internal networks can expose an organisation to lateral movement and privilege escalation. SilentGrid's Internal Infrastructure Penetration Testing focuses on identifying and exploiting vulnerabilities within a defined scope to help organisations harden their internal defences. This service simulates insider threats and post-breach scenarios to identify paths attackers could take to compromise sensitive systems. For objective-driven testing, consider an Assumed Breach Assessment. This service simulates attacker behaviour in pursuit of objectives such as data exfiltration, domain compromise or privilege escalation. Along the way, we identify and report vulnerabilities, misconfigurations, and gaps in detection that adversaries might exploit. ## What sets us apart ### Vulnerability-driven testing for defined environments Internal Infrastructure Penetration Testing targets specific systems, networks, or environments to uncover vulnerabilities that could lead to internal compromise. Testing remains within the predefined boundaries. ### Simulated insider threats Consultants replicate the actions of malicious insiders or compromised users to identify weaknesses in internal systems that could facilitate privilege escalation or lateral movement. ### Advanced manual testing Consultants pair manual testing with automated tools to uncover complex attack paths, misconfigurations, and vulnerabilities that scanners alone often miss. ### Assumed breach for objective-based testing SilentGrid’s Assumed Breach service provides a broader, goal-oriented approach that tests your organisation's resilience to advanced threats. This service mirrors real-world adversary behaviour, focusing on achieving objectives while exposing vulnerabilities along the attack path. ## Methodology SilentGrid's internal penetration testing follows established frameworks, applying adversarial techniques to identify weaknesses across internal networks. ### Network mapping and asset discovery - Enumerating internal devices, systems, and services - Mapping relationships between systems to understand trust paths and potential pivot points ### Vulnerability analysis and exploitation - Identifying misconfigurations, insecure services, and unpatched systems - Exploiting vulnerabilities to simulate real-world attack scenarios ### Privilege escalation and lateral movement - Escalating privileges through exploited systems - Moving laterally across the environment to identify additional targets ### Credential harvesting and reuse - Extracting and testing stored credentials across the network - Assessing password policies and credential management ### Reporting and remediation guidance - Providing a detailed report outlining vulnerabilities, associated risks, and recommended remediation steps ## Internal testing compared with assumed breach Both test the inside of your environment. They answer different questions, so the right choice depends on what you need to know. Read more about Assumed Breach. ### Scope and focus Internal penetration testing: targets specific systems and environments. Assumed breach: simulates a breach, moving laterally across the organisation's infrastructure. ### Testing objectives Internal penetration testing: aims to identify and report vulnerabilities. Assumed breach: focuses on achieving goals such as data exfiltration or domain compromise while identifying vulnerabilities along the way. ### Operational focus Internal penetration testing: evaluates system security at the technical level. Assumed breach: tests defensive controls, monitoring, and incident response capabilities to provide a realistic assessment of how well internal teams detect and respond to threats. ## Deliverables and reporting Reports document vulnerabilities and attack paths, with clear remediation guidance for IT teams. ### Detailed vulnerability report Outlining identified misconfigurations, unpatched systems, and privilege escalation paths ### Proof of concept (PoC) Demonstrations of vulnerabilities successfully exploited during the engagement ### Remediation roadmap Actionable recommendations prioritised by severity and ease of exploitation ### Executive summary High-level overview for leadership, highlighting key findings and risks ### Consultation and retesting Post-assessment guidance and retesting to confirm successful remediation ## Common questions ### What is internal infrastructure penetration testing? Internal infrastructure penetration testing examines a defined internal network the way a malicious insider or compromised user would: mapping hosts, services and trust paths, exploiting misconfigurations and unpatched systems, harvesting and reusing credentials, and escalating privileges within the agreed boundaries. The aim is a prioritised list of vulnerabilities to fix; an assumed breach assessment pursues objectives and tests detection instead. ### What does internal infrastructure testing cover? Internal devices, systems and services within an agreed scope. They are enumerated and mapped for trust paths and pivot points, then tested for misconfigurations, insecure services and unpatched systems, with privilege escalation and lateral movement attempted from what is found. ### How is this different from an assumed breach assessment? Internal penetration testing targets specific systems and environments and aims to identify and report vulnerabilities at the technical level. An assumed breach assessment simulates a breach and works towards objectives such as data exfiltration or domain compromise, testing defensive controls, monitoring and incident response along the way. ### Does the testing simulate an insider? Yes. The engagement replicates the actions of malicious insiders or compromised users to identify weaknesses that could facilitate privilege escalation or lateral movement. ### Do you test credentials and password policy? Yes. Stored credentials are extracted and tested for reuse across the network, and password policies and credential management are assessed. ### Will testing stay within our agreed boundaries? Yes. Testing stays within the predefined scope agreed for the engagement. ### Do you retest after we fix the findings? Yes. Post-assessment consultation and retesting confirm that remediation has been successful. ### What do we receive at the end? A detailed vulnerability report covering misconfigurations, unpatched systems and privilege escalation paths, proof-of-concept demonstrations, a remediation roadmap prioritised by severity and ease of exploitation, and an executive summary. --- Source page: https://www.silentgrid.com/penetration-testing/internal-infrastructure Text file: https://www.silentgrid.com/txt/internal-infrastructure.md Generated from the SilentGrid site source on 2026-10-13. Do not edit by hand. ============================================================================== # Wireless Network Security Canonical name: Wireless Network Security Family: Penetration testing Category: Infrastructure and Cloud Page: https://www.silentgrid.com/penetration-testing/wireless ## Description Identify and mitigate vulnerabilities in your wireless networks to prevent unauthorised access, data interception, and rogue attacks. ## Where it sits Penetration testing catalogue: https://www.silentgrid.com/penetration-testing All 20 services in text: https://www.silentgrid.com/txt/services.md Choosing an engagement: https://www.silentgrid.com/txt/choosing-a-test.md Scoping contact: https://www.silentgrid.com/contact Scope, duration and pricing are agreed during scoping. The sections below are the service page itself: approach, methodology, deliverables and common questions. ## Securing your wireless infrastructure Wi-Fi (802.11) networks are often a critical entry point for attackers, providing opportunities for unauthorised access, data interception, and man-in-the-middle (MITM) attacks. Misconfigurations, weak encryption protocols, and rogue devices can leave networks exposed, compromising internal systems and sensitive data. SilentGrid's Wi-Fi Network Penetration Testing evaluates the security of your wireless infrastructure by identifying vulnerabilities in network configurations, encryption, and access controls. The aim is to help organisations secure their wireless environments, preventing attackers from using rogue access points or exploiting weak wireless protocols. ## Methodology SilentGrid's wireless penetration testing is aligned with industry standards to structure the assessment of wireless network vulnerabilities. ### Wireless reconnaissance and discovery - Identifying all active wireless networks, SSIDs, and hidden access points - Mapping corporate, guest, and shadow networks for attack surface visibility ### Encryption and authentication testing - Testing wireless encryption protocols (WPA2, WPA3) for weaknesses - Assessing 802.1X configurations, RADIUS servers, and authentication methods ### Rogue access point and evil twin simulation - Simulating rogue access points to trick users into connecting to attacker-controlled networks - Performing evil twin attacks to intercept traffic and capture credentials ### Deauthentication and DoS attacks - Testing deauthentication vulnerabilities that can force devices off secure networks - Simulating pre-agreed denial-of-service attacks targeting wireless infrastructure ### Post-exploitation and network pivoting - Assessing lateral movement opportunities from compromised wireless access - Testing for segmentation flaws that allow attackers to pivot into sensitive internal environments ## Why wireless security matters Wireless networks are inherently more vulnerable than wired environments due to signal leakage beyond physical perimeters and user reliance on mobile and BYOD (Bring Your Own Device) policies. A single weak wireless access point can provide attackers with the foothold they need to compromise internal systems, intercept sensitive communications and launch lateral movement across the organisation. ## Deliverables and reporting Reports give network teams remediation guidance to secure wireless environments and prevent unauthorised access. ### Wireless security report Detailing vulnerabilities in wireless networks and access points ### Proof of concept (PoC) Demonstrations of successful exploits (e.g., WPA cracking, rogue AP simulations) ### Remediation recommendations Prioritised actions to address vulnerabilities and strengthen wireless security ### Executive summary High-level insights for leadership, outlining overall risks and the security posture of wireless networks ### Consultation and retesting Support to assist with remediation and retesting efforts ## Common questions ### What is wireless penetration testing? Wireless penetration testing examines Wi-Fi networks the way an attacker within signal range would: discovering corporate, guest, shadow and hidden networks, testing WPA2, WPA3 and 802.1X authentication, running rogue access point and evil twin attacks to capture credentials, and checking whether wireless access leads into sensitive internal networks. Denial-of-service tests run only where agreed in advance. ### What does wireless penetration testing cover? All active wireless networks, SSIDs and hidden access points in scope, including corporate, guest and shadow networks, along with the encryption, authentication and access controls protecting them. ### Which encryption and authentication mechanisms do you test? WPA2 and WPA3 encryption protocols are tested for weaknesses, alongside 802.1X configurations, RADIUS servers and the authentication methods in use. ### Do you simulate rogue access points? Yes. Rogue access points are simulated to see whether users connect to attacker-controlled networks, and evil twin attacks are used to intercept traffic and capture credentials. ### Do you run denial-of-service tests? Only where agreed in advance. Deauthentication vulnerabilities that can force devices off secure networks are tested, and denial-of-service attacks against wireless infrastructure are simulated on a pre-agreed basis. ### Do you test what happens after wireless access is gained? Yes. Lateral movement opportunities from compromised wireless access are assessed, along with segmentation flaws that would let an attacker pivot into sensitive internal environments. ### Why are wireless networks more exposed than wired ones? Signal leakage extends beyond physical perimeters, and user reliance on mobile and BYOD policies widens the attack surface. A single weak access point can give an attacker the foothold needed to compromise internal systems, intercept communications and move laterally. ### What do we receive at the end? A wireless security report covering networks and access points, proof-of-concept demonstrations such as WPA cracking and rogue AP simulations, prioritised remediation recommendations, an executive summary, and post-assessment consultation including retesting. --- Source page: https://www.silentgrid.com/penetration-testing/wireless Text file: https://www.silentgrid.com/txt/wireless.md Generated from the SilentGrid site source on 2026-10-13. Do not edit by hand. ============================================================================== # Restricted Environment Breakout Canonical name: Restricted Environment Breakout Family: Penetration testing Category: Infrastructure and Cloud Page: https://www.silentgrid.com/penetration-testing/restricted-environment-breakout ## Description Assess the resilience of virtual desktops, kiosks, and other locked-down environments against breakout attempts and privilege escalation. ## Where it sits Penetration testing catalogue: https://www.silentgrid.com/penetration-testing All 20 services in text: https://www.silentgrid.com/txt/services.md Choosing an engagement: https://www.silentgrid.com/txt/choosing-a-test.md Scoping contact: https://www.silentgrid.com/contact Scope, duration and pricing are agreed during scoping. The sections below are the service page itself: approach, methodology, deliverables and common questions. ## Testing locked-down environment security Restricted environments (such as virtual desktops, kiosks, and embedded terminals) are designed to enforce user limitations and prevent unauthorised access to underlying systems. Misconfigurations, software vulnerabilities and insecure design can allow attackers to escape these environments, escalate privileges, and gain access to sensitive resources. SilentGrid's Restricted Environment Breakout Testing simulates real-world attacks against virtual desktops, kiosk terminals, embedded systems, and locked-down environments to uncover vulnerabilities that could lead to breakouts, data exposure, or network compromise. ## Methodology Breakout testing uses adversarial tactics and draws on senior consultants’ technical experience. ### Environment reconnaissance - Mapping and enumerating restrictions, configurations, and sandbox policies - Identifying hidden functionality and exposed file systems ### Breakout attempt and exploitation - Simulating command injection, script execution, and interface bypass attacks - Testing for vulnerabilities in underlying hypervisors, kiosk software, or desktop environments ### Privilege escalation and lateral movement - Assessing pathways for post-breakout privilege escalation - Testing for segmentation flaws that allow attackers to pivot into sensitive networks ### Persistence testing - Evaluating methods for gaining persistence within compromised environments - Testing breakout methods that persist through reboots or session resets ## Why restricted environment security matters Breakouts from locked-down environments can lead to access to internal networks and sensitive systems, privilege escalation, data exfiltration, network reconnaissance and unauthorised administrative access through overlooked misconfigurations. Protecting restricted environments reduces the risk of internal compromise, financial losses, and operational disruption. ## Deliverables and reporting Reports document breakout methods and attack paths, with remediation guidance for strengthening restrictions and access controls. ### Comprehensive vulnerability report Documenting all breakout methods, privilege escalation paths, and system misconfigurations ### Proof of concept (PoC) Demonstrations of successful breakout attempts ### Remediation guidance Prioritised recommendations to tighten restrictions and secure environments ### Executive summary High-level findings tailored for leadership and IT teams ### Consultation and support Post-assessment guidance to assist with hardening environments against breakout techniques ## Common questions ### What is restricted environment breakout testing? Restricted environment breakout testing examines virtual desktops, kiosks and embedded terminals the way an attacker with an ordinary user session would: mapping restrictions and sandbox policies, attempting command injection, script execution and interface bypass, then checking whether a breakout leads to privilege escalation, persistence through reboots or session resets, and access to the network underneath. ### What environments do you test? Virtual desktops, kiosk terminals, embedded systems and other locked-down environments designed to enforce user limitations and prevent access to the systems underneath. ### What does the testing involve? Restrictions, configurations and sandbox policies are mapped first, along with hidden functionality and exposed file systems. Breakout is then attempted through command injection, script execution and interface bypass, and through vulnerabilities in the underlying hypervisor, kiosk software or desktop environment. ### What happens after a breakout succeeds? Post-breakout privilege escalation pathways are assessed, along with segmentation flaws that would let an attacker pivot into sensitive networks, and methods of gaining persistence, including breakouts that survive reboots or session resets. ### Why does a kiosk or virtual desktop need testing? Because a breakout can give access to internal networks and sensitive systems, enable privilege escalation, data exfiltration and network reconnaissance, and grant unauthorised administrative access through overlooked misconfigurations. ### Who performs the testing? Breakout testing uses adversarial tactics and draws on senior consultants’ technical experience. ### What do we receive at the end? A report documenting every breakout method, privilege escalation path and misconfiguration found, proof-of-concept demonstrations, prioritised remediation guidance, an executive summary, and post-assessment support for hardening the environment. --- Source page: https://www.silentgrid.com/penetration-testing/restricted-environment-breakout Text file: https://www.silentgrid.com/txt/restricted-environment-breakout.md Generated from the SilentGrid site source on 2026-10-13. Do not edit by hand. ============================================================================== # Hardware and IoT Security Canonical name: Hardware and IoT Security Family: Penetration testing Category: Hardware and IoT Page: https://www.silentgrid.com/penetration-testing/hardware-iot ## Description Identify vulnerabilities in IoT devices and embedded systems to prevent exploitation and secure physical and digital assets. ## Where it sits Penetration testing catalogue: https://www.silentgrid.com/penetration-testing All 20 services in text: https://www.silentgrid.com/txt/services.md Choosing an engagement: https://www.silentgrid.com/txt/choosing-a-test.md Scoping contact: https://www.silentgrid.com/contact Scope, duration and pricing are agreed during scoping. The sections below are the service page itself: approach, methodology, deliverables and common questions. ## Testing connected devices and their supporting systems Across consumer IoT devices, industrial control systems (ICS) and custom embedded products, attackers target misconfigurations, weak firmware, and insecure communication channels to gain unauthorised access or disrupt operations. SilentGrid's Hardware and IoT Penetration Testing evaluates the security of embedded systems, IoT devices, and hardware products to uncover vulnerabilities at the firmware, communication, and physical access layers. The aim is to ensure hardware and IoT ecosystems resist attacks across their physical and digital security controls. ## What sets us apart ### End-to-end IoT and hardware testing Testing covers IoT ecosystems across the full stack, from firmware analysis and hardware debugging to API security and cloud interaction. This identifies vulnerabilities across all components of the IoT infrastructure. ### Embedded systems expertise Consultants use their experience in embedded architectures, reverse engineering and custom hardware exploitation to identify weaknesses at the binary, bootloader and kernel levels. ### Real-world attack simulation SilentGrid simulates real-world attack scenarios targeting IoT ecosystems and hardware devices: firmware reverse engineering and modification, hardware-based attacks (JTAG, UART, SPI, I2C), wireless protocol exploitation (Bluetooth, Zigbee, LoRa, NFC), and physical tampering and side-channel attacks. ## Testing standards and frameworks SilentGrid's hardware and IoT testing is aligned with these frameworks to structure coverage: ### OWASP IoT Top 10 Addressing the most critical IoT vulnerabilities ### MITRE ATT&CK for ICS Focusing on industrial control system threats ### NIST 8259 IoT device cybersecurity guidance ### CWE (Common Weakness Enumeration) Identifying common weaknesses in embedded and IoT software ## Methodology Testing evaluates vulnerabilities across the hardware lifecycle, from development to deployment. ### Hardware reconnaissance and threat modelling - Identifying exposed interfaces (e.g., JTAG, UART) and insecure boot configurations - Assessing device architecture, chipsets, and embedded operating systems ### Firmware extraction and analysis - Extracting and reverse-engineering firmware to identify backdoors, hardcoded credentials, or insecure code - Testing for buffer overflows, command injection, and privilege escalation opportunities ### Communication and protocol testing - Testing communication protocols (Bluetooth, Zigbee, Wi-Fi, MQTT, etc.) for vulnerabilities - Simulating man-in-the-middle (MITM) attacks on data flows between devices and cloud platforms ### Physical and side-channel analysis - Conducting physical tampering assessments to evaluate access controls and hardware resilience - Testing for voltage glitching, electromagnetic interference (EMI), and chip-level attacks ### Cloud and API integration testing - Assessing IoT cloud services and backend APIs for misconfigurations, authentication issues, and data exposure risks ## Why IoT and hardware security matters IoT and embedded devices often interact with sensitive environments, including critical infrastructure, healthcare, smart cities, and enterprise networks. A single compromised device can facilitate lateral movement within corporate environments, expose sensitive data through insecure storage or transmission, enable remote code execution and persistent backdoors, and lead to operational disruption through attacks on industrial IoT (IIoT) or OT systems. Securing hardware and IoT devices protects device functionality and the broader network and services they interact with. ## Deliverables and reporting Reports give product teams findings and remediation guidance, ensuring secure development and deployment of connected devices. ### Comprehensive vulnerability report Documenting security risks across firmware, hardware, and communication channels ### Proof of concept (PoC) Demonstrations of successful hardware, firmware, or communication exploits ### Remediation guidance Detailed recommendations to address vulnerabilities at the hardware, software, and API levels ### Executive summary High-level overview of findings and risks for non-technical stakeholders ### Consultation and support Post-assessment support to assist engineering teams in securing hardware products ## Common questions ### What is hardware and IoT penetration testing? Hardware and IoT penetration testing examines connected devices the way an attacker with the device in hand would: probing JTAG and UART interfaces, extracting and reverse engineering firmware, attacking Bluetooth, Zigbee, Wi-Fi and MQTT communications, attempting physical tampering and side-channel attacks such as voltage glitching, and testing the cloud services and APIs the device relies on. ### What does hardware and IoT testing cover? The full stack: firmware analysis and hardware debugging, communication and wireless protocols, physical and side-channel attacks, and the cloud services and backend APIs the devices talk to. ### Do you test the physical device itself? Yes. Exposed interfaces such as JTAG and UART are identified, insecure boot configurations assessed, physical tampering used to evaluate access controls and hardware resilience, and voltage glitching, electromagnetic interference and chip-level attacks tested. ### Which wireless protocols do you test? Bluetooth, Zigbee, Wi-Fi, MQTT, LoRa and NFC among others, including man-in-the-middle attacks against data flows between devices and cloud platforms. ### Do you need the firmware source? No. Firmware is extracted and reverse-engineered to identify backdoors, hardcoded credentials and insecure code, and tested for buffer overflows, command injection and privilege escalation opportunities. ### Which standards does the testing align with? The OWASP IoT Top 10, MITRE ATT&CK for ICS, NIST 8259 device cybersecurity guidance, and the Common Weakness Enumeration for embedded and IoT software. ### Why does a single device matter? IoT and embedded devices interact with sensitive environments such as critical infrastructure, healthcare, smart cities and enterprise networks. One compromised device can facilitate lateral movement, expose sensitive data, enable remote code execution and persistent backdoors, or disrupt operations on industrial IoT and OT systems. ### What do we receive at the end? A vulnerability report covering firmware, hardware and communication channels, proof-of-concept demonstrations, remediation guidance at hardware, software and API levels, an executive summary, and post-assessment consultation for the engineering team. --- Source page: https://www.silentgrid.com/penetration-testing/hardware-iot Text file: https://www.silentgrid.com/txt/hardware-iot.md Generated from the SilentGrid site source on 2026-10-13. Do not edit by hand. ============================================================================== # AI/LLM Penetration Testing Canonical name: AI/LLM Penetration Testing Family: Penetration testing Category: Emerging Technologies Page: https://www.silentgrid.com/penetration-testing/ai-llm ## Description Test the security and resilience of AI models, large language models (LLMs), and AI-driven applications against adversarial attacks and exploitation techniques. ## Where it sits Penetration testing catalogue: https://www.silentgrid.com/penetration-testing All 20 services in text: https://www.silentgrid.com/txt/services.md Choosing an engagement: https://www.silentgrid.com/txt/choosing-a-test.md Scoping contact: https://www.silentgrid.com/contact Scope, duration and pricing are agreed during scoping. The sections below are the service page itself: approach, methodology, deliverables and common questions. ## Testing AI models and deployment pipelines AI systems, particularly large language models (LLMs) and machine learning applications, introduce attack surfaces that adversaries can exploit. These models are susceptible to adversarial manipulation, data poisoning, model extraction, and prompt injection attacks. SilentGrid's AI/LLM Penetration Testing evaluates the security of AI models, uncovering vulnerabilities that could lead to malicious model manipulation, privacy violations, and data leakage. Engagements focus on securing AI pipelines, model integrity, and deployment environments. The methodology combines adversarial machine learning techniques with conventional security testing, drawing on the OWASP Top 10 for Large Language Model Applications and MITRE ATLAS. Manual analysis by consultants is paired with customised adversarial tooling, so findings reflect real impact on model integrity, data confidentiality and system availability rather than tool output alone. ## AI/LLM attack surfaces Attack techniques and exposed interfaces: ### Prompt injection Attackers manipulate LLM responses by crafting malicious prompts to bypass guardrails or extract sensitive data ### Model extraction Adversaries attempt to reverse engineer AI models, stealing intellectual property or replicating models for malicious use ### Data poisoning Manipulation of training data to inject bias, backdoors, or malicious behaviours into deployed models ### Insecure endpoints Exposed AI APIs and inference endpoints provide new vectors for unauthorised access and manipulation ## Is AI/LLM penetration testing the right fit? The engagement tests the model, its training data and the pipeline around it, so it suits organisations running AI in production or building models of their own. Where AI is only consumed through a third-party product, application testing of that integration is the more useful question. AI/LLM penetration testing is essential for - Organisations deploying LLMs, AI chatbots, or machine learning models in production - Businesses handling sensitive data through AI models - Companies developing proprietary AI/ML solutions and seeking to protect intellectual property - Enterprises integrating AI into customer-facing services or automation pipelines ## Testing areas SilentGrid combines adversarial AI techniques, manual testing and proprietary tooling to simulate attacks on AI/LLM systems. Consultants assess pipelines from data ingestion to model deployment, identifying weaknesses at every stage. ### Prompt injection and output manipulation - Testing LLMs for prompt injection vulnerabilities that lead to model misalignment, data leakage, or output control - Evaluating model guardrails for bypass techniques ### Model extraction and theft - Simulating adversaries attempting to extract model weights, parameters, or training data through API interaction - Testing for query-based model extraction techniques ### Adversarial input manipulation - Crafting adversarial inputs that trigger incorrect outputs or misclassification in AI systems - Evaluating vision-based models for image perturbations and audio-based models for adversarial waveforms ### Data poisoning and model integrity - Testing the resilience of models against data poisoning attacks during the training phase - Simulating data manipulation that introduces bias or backdoors into production models ### Model integrity and guardrail bypass - Testing whether safety and policy guardrails can be circumvented through indirect or chained instructions - Assessing whether the model's behaviour can be altered in ways its operators would not sanction ### Privacy violations and data leakage - Probing for disclosure of training data, system prompts or other users' information - Testing what the model reveals about the systems and data it is connected to ### API and endpoint security - Assessing inference APIs for improper authentication, excessive permissions, and insecure deployments - Testing for model abuse, misuse, and unauthorised access to AI pipelines ## Benefits of AI/LLM penetration testing ### Protect model integrity Ensure AI models remain free from manipulation, poisoning, or adversarial bias ### Secure AI pipelines Harden the entire AI lifecycle, from data ingestion to deployment ### Prevent model theft and extraction Safeguard intellectual property by detecting model extraction vulnerabilities ### Harden inference endpoints Lock down AI/LLM APIs and inference points to prevent abuse and exploitation ## Frameworks behind the testing Published frameworks structure the testing and give clients and consultants a shared reference for discussing coverage. ### OWASP Top 10 for LLM Applications The reference list of risks specific to applications built on large language models. ### MITRE ATLAS The Adversarial Threat Landscape for Artificial-Intelligence Systems, mapping tactics and techniques used against AI. ## Deliverables and reporting Reports document AI/LLM vulnerabilities and show whether models and deployment pipelines are resilient against adversarial threats. ### Adversarial testing report Documentation of successful prompt injections, model theft attempts, and adversarial perturbations ### Model extraction analysis Pathways that lead to partial or complete model extraction ### Training data security report Identifying data poisoning risks and model integrity issues ### API/endpoint vulnerability analysis Assessing AI deployment endpoints for access control weaknesses and misconfigurations ### Executive summary A high-level overview for leadership, summarising the impact of AI/LLM vulnerabilities and recommended mitigations ### Consultation and support Post-assessment guidance to help engineering teams address the findings effectively ## Common questions ### What is AI/LLM penetration testing? AI/LLM penetration testing examines models, LLM applications and their pipelines the way an adversary would: attempting prompt injection and guardrail bypass, model extraction, data poisoning, adversarial inputs, and leakage of training data or system prompts, and testing the inference APIs around them. Manual analysis is paired with customised adversarial tooling, structured against the OWASP Top 10 for LLM Applications and MITRE ATLAS. ### What does AI/LLM penetration testing cover? Prompt injection and output manipulation, model extraction and theft, adversarial input manipulation, data poisoning and model integrity, and the security of inference APIs and endpoints. ### What is prompt injection? An attack where crafted prompts manipulate the model's responses to bypass guardrails or extract sensitive data. Testing covers both the injection itself and whether the model's guardrails can be bypassed. ### Can you test whether our model can be extracted? Yes. We simulate adversaries attempting to extract model weights, parameters or training data through API interaction, including query-based model extraction techniques, and report the pathways that lead to partial or complete extraction. ### Do you test the pipeline or only the model? The whole lifecycle. AI pipelines are assessed from data ingestion through to model deployment, identifying weaknesses at every stage, including the deployment environment itself. ### Do you test vision and audio models as well as LLMs? Yes. Vision-based models are evaluated for image perturbations and audio-based models for adversarial waveforms, alongside adversarial inputs that trigger incorrect outputs or misclassification. ### How is the testing performed? Through a combination of adversarial AI techniques, manual testing and proprietary tooling, used to simulate real-world attacks against AI and LLM systems. ### What do we receive at the end? An adversarial testing report documenting successful prompt injections, model theft attempts and adversarial perturbations, a model extraction analysis, a training data security report, an API and endpoint vulnerability analysis, an executive summary, and post-assessment consultation. --- Source page: https://www.silentgrid.com/penetration-testing/ai-llm Text file: https://www.silentgrid.com/txt/ai-llm.md Generated from the SilentGrid site source on 2026-10-13. Do not edit by hand. ============================================================================== # Continuous Adversary Operations (CAOS) Canonical name: Continuous Adversary Operations Service (CAOS) Also called: continuous red teaming Family: Adversary simulation program Page: https://www.silentgrid.com/continuous-red-teaming ## Description A persistent, objective-driven adversary simulation program. Senior operators run attacks against your environment year-round, in cycles, with findings logged in real time. ## At a glance - Objective: Critical business services - Maturity: SOC responding as normal - Method: Year-round cycles - Result: Improvement across cycles ## Overview CAOS is a persistent, objective-driven adversary simulation program delivered by a dedicated team of senior operators. They run attacks against your environment throughout the year, using the tactics, techniques and procedures real adversaries employ against your sector, testing technical controls, people and processes under sustained pressure. Reports follow each cycle, documenting results, observations, recommendations and improvements since previous cycles. Key operational activity is logged in real time on HackTrack, and your security team is given access once an execution cycle completes. ## Objectives - Test under sustained pressure: Operations run continuously rather than within a fixed window, so controls, people and processes are exercised the way a persistent adversary would exercise them - Keep pace with change: New systems, new exposure and completed remediation are tested as they appear, instead of waiting for the next annual assessment - Exercise incident response: Where an objective is reached without detection, operators can deliberately trigger an alert so the security team runs its response process for real - Show improvement over time: Each cycle report records observations and improvements since the previous cycle, and earlier test cases can be replayed to check whether detection has improved ## Who it fits CAOS fits when you: - Run a SOC, internal or managed, that will detect and respond as it would to a real threat during operations. - Need evidence of security improvement over time rather than a single point-in-time result. - Have critical business services worth defining as objectives. - Can nominate a Control Group of senior staff able to make risk-based decisions throughout. Is CAOS the right fit? CAOS suits organisations that already run detection and response and want it tested continuously. A SOC operating normally during operations is a prerequisite, because deliberately suppressing detection invalidates the result for that period. ## How a cycle runs ### Preparation - A workshop defines the critical business services, the cycle objectives, the Control Group and the communication channels, including an emergency channel - Rules of engagement are agreed, covering any staff, techniques or systems that must not be targeted, along with the checkpoint cadence - The output is a Cycle Execution Plan, approved by both parties before execution begins, and the reference point for the cycle ### Cycle execution - Operators run a campaign of attacks against the cycle's objectives. A cycle is not time-boxed; it is divided into Pushes and Checkpoints - Each checkpoint reviews where attacks succeeded, where controls prevented or detected them, what incident response was observed, and the goal for the next push - The Control Group shapes the next push, and can grant a concession where an objective has blocked progress across several pushes ### Close out - A Cycle Execution Report is delivered to the Control Group to distribute internally - A technical debrief walks through the report, and a separate executive debrief covers the objectives, approach, results and recommendations - The security team is given access to the engagement data in HackTrack, including operator logs and test cases aligned to MITRE ATT&CK ### Purple team (optional) - Before the next iteration begins, the TTPs used during the cycle can be replayed alongside the security team, together with techniques currently used by real threat actors - A cycle can also be dedicated to purple teaming, taking either a coverage-based or intelligence-led approach ## Attack methodology within a cycle ### Breach - Deep reconnaissance profiles the organisation, its staff, third parties and subsidiaries, and is repeated continually as access and knowledge grow - Effort runs in parallel across three pillars: identity, social engineering and internet-facing services - Attacks on identity and exposed attack surface continue after a successful breach, building redundant access for use after eviction or in later cycles ### Privilege escalation and persistence - Internal reconnaissance builds an understanding of on-premises systems, cloud platforms and SaaS applications, and runs continuously - Insecurely stored credentials, post-exploitation on compromised systems, and pivots into developer environments and code repositories provide routes to privileged access - Each action is weighed for its likelihood of detection against the value of the outcome ### Action on objectives - Systems associated with the objective are identified along with the users who can reach them, and a plan is formed to compromise both - Sufficient evidence is collected to show the objective was completed ## Deliverables - Adversary operations: Continuous - HackTrack platform access: Real-time findings tracking - Cycle execution plan: Per cycle - Checkpoint meetings: Roughly every two months - Checkpoint status document: Roughly every two months - Cycle execution report: Per cycle, up to two a year - Technical and executive debriefs: Per cycle, up to two a year - Purple team, optional: Per cycle, up to two a year ## Why SilentGrid A CAOS program is delivered by a named Lead and Specialist who stay with it for its duration, so the team builds and keeps a detailed understanding of your environment. Where a cycle needs depth in a particular domain, such as mobile, wireless, cloud-native attack paths, thick client or hardware and IoT, the relevant specialist joins the core team for that phase. SilentGrid's consultants are hand-picked, and between them they have delivered red team engagements globally over decades, including CBEST for UK financial institutions and CORIE engagements in Australia. Year-round operations let the team test emerging techniques and pursue new opportunities as they appear. Individual credentials across our team include: OSEE, OSCE3, OSED, OSEP, OSWE, GXPN, CRTO, CRTE, CRTP, OSCP. SilentGrid is a CREST ANZ approved company. ## Questions and answers ### How is CAOS different from an annual red team engagement? A red team engagement measures your defences within a fixed window. CAOS runs year-round in cycles, so changes to the environment and the fixes made after each cycle are tested as they happen. Cycles are not time-boxed; they close when the objectives are met, sufficient effort has been spent, or a high-severity incident means the activity must be disclosed. ### Who inside our organisation knows the program is running? Only the Control Group: a small group of senior staff with the business knowledge and seniority to make risk-based decisions. Restricting that knowledge keeps the test of detection and incident response realistic. ### What happens if our security team detects the activity? Respond as though it were real. The Control Group can deconflict through the primary channel, or the emergency channel when urgent. If operators are evicted they use redundant access, and if removed entirely they attempt to breach again unless the Control Group grants an assumed breach concession. ### What is HackTrack? SilentGrid's platform for capturing operator logs, indicators of compromise and the techniques used during a cycle. Your instance holds the data from every cycle and purple team. Key techniques are visible to the Control Group during a cycle, and the full data set opens to your security team once the report is delivered, searchable and annotatable. ### Can we direct what gets targeted? Yes. Objectives are set in the preparation workshop, and at each checkpoint the Control Group shapes the next push. A cycle can also be run as an intelligence-led exercise against a specific threat, or as a dedicated purple team. ## Related Annual programs: https://www.silentgrid.com/txt/annual-programs.md Service catalogue: https://www.silentgrid.com/txt/services.md Scoping contact: https://www.silentgrid.com/contact --- Source page: https://www.silentgrid.com/continuous-red-teaming Text file: https://www.silentgrid.com/txt/continuous-red-teaming.md Generated from the SilentGrid site source on 2026-10-13. Do not edit by hand. ============================================================================== # Annual Testing Programs Canonical name: Annual Testing Program Family: Security testing program Page: https://www.silentgrid.com/annual-programs ## Description A twelve-month security testing program, built around your estate, your priorities and your budget. The example below rotates penetration testing across the year, with adversary simulation and purple team as a second stream. ## At a glance - Term: Twelve months, built to renew - Scope: Shaped around your estate - Planning: One session each quarter - Shape: Customised, not packaged ## Overview The following is an example of how an annual program can be structured. Each program's activities, rotation, assessment depth and balance between the two streams are agreed during scoping, based on your environment, priorities and budget. An annual program replaces a series of disconnected engagements with a single twelve-month plan. Testing rotates across infrastructure, applications, cloud and identity through the year, following an agreed coverage plan, and each quarter builds on what the last one found. The program is structured as two streams. The testing stream is a complete program in its own right and produces the evidence base for remediation, audit and board reporting. The adversary stream is optional, and tests whether the weaknesses found in the testing stream can actually be exploited, and whether your security operations would see it happen. The program year runs from whenever it starts, not from a fixed calendar date. Each of the four quarters has a planning session, and the year-end view compares results to show what changed. SilentGrid recommends running the program across multiple years. The first year establishes a baseline. In subsequent years, scoping becomes more precise, the same consultants retain their knowledge of the environment, and results can be compared over time to guide improvements. To sketch a year of testing before the first conversation, use the continuous testing program planner. ## Objectives - Cover the estate deliberately: Infrastructure, applications, cloud, identity and APIs are scheduled across the year, following the agreed coverage plan - Remove the per-test overhead: One planning session a quarter replaces individual scoping requests, approvals and procurement workflows for every engagement - Verify that fixes hold: Retesting is built into each quarter to verify remediation and record evidence that the security program is working - Show progress over time: Four quarters of results in one place give trend data for board reporting, audit evidence and year-on-year comparison within the tested scope ## Who it fits An annual program fits when you: - Have enough estate to cover that testing it once a year in a single engagement would be superficial. - Need a predictable testing calendar your internal teams and release schedules can plan around. - Are asked to evidence security posture and improvement to a board, an auditor or a regulator. - Ship changes through the year and want new releases validated rather than left until the next annual assessment. Is an annual program the right fit? An annual program suits organisations with a broad enough estate, or a fast enough rate of change, that a single yearly engagement cannot cover it meaningfully. Where the need is a defined application or a one-off technical question, a targeted assessment is the better answer and remains available on its own. ## The two streams ### Testing stream - Internal infrastructure, Active Directory and identity, tested together because the attack paths between them are coupled. Delivered onsite where the environment calls for it, and scoped separately for each distinct organisation or forest - External infrastructure: asset discovery, service analysis, exposed management and remote access surfaces, mail gateway and email authentication configuration, and the forgotten services nobody has an owner for - Cloud configuration review across the accounts in scope, covering identity and access policies, privilege escalation paths, cross-account trust, data exposure, network controls, secrets handling and logging coverage - Web applications, batched across quarters and prioritised by business criticality, change frequency and known risk. Effort is matched to each application's complexity - APIs and web services as a dedicated assessment, covering object and function level authorisation, token handling, rate limiting, versioning gaps and undocumented endpoints - Release validation each month for applications that ship changes after their first assessment, and retesting each quarter to verify that fixes are complete ### Adversary stream - Quarterly campaigns alternating between perimeter assessment and assumed breach, each time-boxed and objective-driven rather than full-scope red team operations - Perimeter campaigns test realistic attack chains against external services and whether external threat activity is detected. Assumed breach campaigns start from a simulated internal foothold and test lateral movement, privilege escalation, persistence, data access and evasion - A social engineering thread runs throughout the year. Phishing infrastructure is established early and maintained, so sending reputation builds the way a real adversary's would, and pretexts evolve across the year - Purple team sessions where operators replay techniques alongside your security team, who validate detection coverage and identify gaps in real time. Sessions are cooperative throughout - A TTP detection register that records every technique tested, how it was executed, whether it was detected, and what changed after remediation ## Example quarterly rotation In this example year, testing stream findings inform the adversary campaigns that follow, and those campaigns validate whether remediation held. Purple team sessions develop detections for the techniques both streams surfaced. Different priorities call for different sequencing and may not require every activity shown here. Each quarter's exact schedule is confirmed at its planning session. ### First quarter - Testing stream: internal infrastructure, Active Directory and identity, plus the first batch of priority applications. Front-loading the applications that matter most gives the longest remediation runway before year end - Adversary stream: a perimeter campaign establishes the adversary baseline from outside, and the social engineering infrastructure for the year is set up ### Second quarter - Testing stream: external infrastructure and the second application batch - Adversary stream: the first assumed breach campaign, using the internal findings from the first quarter to target where weaknesses were identified and test whether the remediation holds under pressure. The first purple team session establishes a detection baseline ### Third quarter - Testing stream: cloud configuration review, API surfaces and the third application batch - Adversary stream: a second perimeter campaign that validates whether the external weaknesses found in the previous quarter were effectively remediated ### Fourth quarter - Testing stream: deliberately lighter on new testing, leaving room for remaining applications, deeper dives into areas of concern and overflow from earlier quarters - Adversary stream: a second assumed breach campaign covering persistence, evasion and exfiltration paths, and a final purple team session drawing on the full year of campaign data ## How the program runs ### Quarterly planning - At the start of each quarter, both teams agree what will be tested, which consultants are allocated and when the testing windows fall - One session replaces the scoping requests, approvals and procurement workflow that each individual engagement would otherwise carry - Between sessions, a nominated customer success contact handles ad-hoc requests, urgent testing, release validation and scheduling changes ### Reserved capacity - A share of the program's capacity is reserved for unplanned work, so it does not require a contract amendment or a new procurement cycle - It covers urgent release validation, response to a newly published critical vulnerability, extended retesting, deeper dives into areas of concern, and campaign extensions where a promising attack path deserves more time - Draws are agreed by both parties and documented with their purpose and deliverable. Capacity unused at year end carries into the next year's planning ### Testing windows - Windows are booked wider than the testing effort itself, with buffer either side for access verification, credential provisioning and scope confirmation before, and report writing, quality assurance and debrief after - Booking a window to the exact number of operator days is what compresses timelines later. Recommended windows are proposed at the planning session so internal availability can be arranged around confirmed dates - Testing can be suspended at any time with immediate effect, and resumes by agreement ### Scope, agreed and refined - Scope assumptions are reviewed and confirmed before the program is agreed, then validated in detail during the first quarter - Where the environment turns out to differ materially from the assumptions, adjusted options are presented within the agreed allocation before any work proceeds - A second year benefits from a full year of familiarity with the environment, and is scoped far more precisely as a result ## Across multiple years A single year establishes a baseline. Subsequent years allow comparison against it, providing evidence of improvement for a board, auditor or regulator. SilentGrid recommends a multi-year program, with each year building on the scope knowledge and findings of the previous one. ### Year one: establish the baseline - A complete picture across every layer of the attack surface, and four quarters of evidence showing which findings were remediated and verified - The first quarter validates scope assumptions in practice, and the team learns how the environment is run alongside what its documentation records - The detection register opens, and the first baseline of what your security team sees is established ### Year two: test what changed - Scoping is far more precise, because a year of operational familiarity replaces guesswork. Effort shifts from discovery towards depth - Results are compared with last year's to show which findings and detections changed. Regression testing confirms that the detections built in year one still fire - Campaigns push into the areas that held up under pressure the first time, because the easy ground has already been covered ### Year three and beyond: raise the ceiling - With the obvious weaknesses closed, testing moves to the attack paths that only appear under sustained pressure and patient tradecraft - Detection maturity is measured as a multi-year trend rather than a result per engagement, which is the evidence a board can act on - This is usually the point where continuous operations through CAOS (Continuous Adversary Operations Service) replace quarterly campaigns, applying sustained pressure to your defences ## Deliverables - Quarterly plan: Agreed scope, allocation and testing windows for the quarter ahead - Engagement reports: Per activity, for technical and executive audiences - Retest verification: Evidence that findings were remediated, each quarter - Client Portal: Posture across all activity, remediation progress and every report in one place - HackTrack: Real-time collaboration between operators and your security team during purple team - TTP detection register: Every technique tested, its detection result and remediation status - Campaign debriefs: Technical and executive, following each adversary campaign - Year-end reporting: Four quarters of results as trend data for board and audit use ## How CAOS differs from quarterly campaigns - Cadence: Continuous operations rather than quarterly campaigns with gaps between them - Dwell time: Tests whether a slow, patient attacker is detected, not one constrained to a short sprint - Tradecraft: Operators adapt as your defences improve, testing the ceiling of detection capability - Measure: A monthly adversary exposure score rather than a quarterly read CAOS in text: https://www.silentgrid.com/txt/continuous-red-teaming.md ## Why SilentGrid A program is supported by a named customer success contact responsible for scheduling, communication and escalation, so testing windows are met without the coordination falling to your security team. Consultants are allocated per activity by specialisation, and high retention means the people who learned your environment in the first quarter are still the ones testing it in the fourth, and the year after. SilentGrid holds CREST ANZ accreditation and tests to OWASP for web and API, PTES for infrastructure, CIS Benchmarks for cloud configuration and MITRE ATT&CK for technique mapping. Automated tooling is used for reconnaissance and coverage validation only. Exploitation, business logic testing and adversary simulation are manual, operator-led work. ## Questions and answers ### Is this exactly what our program would look like? No. The streams and the rotation on this page are an example of how a program can be structured, drawn from a real one. Every program is built around the organisation it is for: which activities are included, how deep each one goes, how the year is sequenced and how much of it runs are all agreed during scoping, against your environment, your priorities and your budget. The breadth of the program adjusts to the estate and budget while maintaining the same approach to delivery. ### Should we commit to more than one year? SilentGrid recommends it. A single year establishes a baseline; subsequent years provide comparisons that a board or regulator can use to assess improvement. From year two the scoping is far more precise because the environment is known, effort shifts from discovery to depth, regression testing confirms that earlier detections still fire, and the results read as a trend. Programs are agreed a year at a time, so renewal is based on evidence from the previous year. ### Can we take the testing stream on its own? Yes. The testing stream is designed as a complete, standalone program and delivers a full year of structured penetration testing without the adversary stream. The adversary stream can be added at program start or at any quarterly planning session, and its rotation adjusts to begin from whichever quarter it joins. ### How is the scope agreed? Scope assumptions are reviewed and confirmed before the program is signed, then validated in detail during the first quarter. If the environment materially exceeds the assumptions, adjusted options are presented within the agreed allocation before work proceeds, and a scope amendment is proposed where the variance is significant. ### What happens when something urgent comes up mid-quarter? Reserved capacity covers unplanned work such as a release that needs validating, a newly published critical vulnerability affecting your infrastructure, or a deeper dive into something testing surfaced. Requests go through your customer success contact without a new procurement cycle. ### Does the program have to align to our financial year? No. The program runs for twelve months from whenever it starts, divided into four quarters of its own. If the start date happens to align with your financial year, reporting maps naturally to your budgeting and board cycles. If it does not, year-end reporting can be adjusted to coincide with the financial year close. ### How often does purple team run? Either two longer sessions a year or four shorter ones. Fewer, longer sessions suit teams that need time between them to implement findings. A quarterly cadence suits teams with dedicated detection engineering capability who can action gaps quickly. The cadence can be changed at any quarterly review, and the total annual allocation stays the same either way. ### What if our security team cannot join a purple team session? The exercise still runs and the findings are still delivered, but detection validation is limited to what can be assessed without active participation. Purple team is collaborative by design, and the value comes from your team observing technique execution as it happens. ### How is this different from buying assessments one at a time? Individual assessments each carry their own scoping, approval and scheduling overhead, and produce results that are hard to compare. A program plans coverage across the year, builds retesting in, and produces four quarters of comparable data. It also means the same consultants keep learning your environment rather than starting from scratch each time. ### Where does CAOS fit? CAOS replaces the quarterly adversary campaigns with persistent, continuous operations by a dedicated team. It can complement a program by taking over the adversary stream while the testing and purple team streams continue, or run as a standalone service. A year of program data is a natural foundation for it. ## Related Service catalogue: https://www.silentgrid.com/txt/services.md Scoping contact: https://www.silentgrid.com/contact --- Source page: https://www.silentgrid.com/annual-programs Text file: https://www.silentgrid.com/txt/annual-programs.md Generated from the SilentGrid site source on 2026-10-13. Do not edit by hand. ============================================================================== # About SilentGrid ## Organisation Trading name: SilentGrid Legal entity: SilentGrid Security Pty Ltd (ABN 17 637 847 351) Country: Australia Australian presence: Sydney, Melbourne, Perth, Brisbane, Adelaide, Hobart Accreditation: CREST ANZ approved company Website: https://www.silentgrid.com Contact: https://www.silentgrid.com/contact, info@silentgrid.com Team: https://www.silentgrid.com/our-team Research: https://blog.silentgrid.com ## Who we are SilentGrid brings together people who care about offensive security and the quality of the work clients receive. The team combines technical expertise with practical experience to investigate complex security challenges. Each engagement helps clients understand and address the weaknesses in their systems. ## Mission Bringing together a team of experts to challenge defences and strengthen organisations’ resilience. SilentGrid delivers advanced offensive security services that identify vulnerabilities and help close them before an attacker reaches them, so businesses across Australia can defend against threats that keep changing. Experienced practitioners lead each exercise, with clear communication, reliable delivery and a scope based on the client’s needs. A supportive environment gives the team the trust and backing to do its best work, explore new approaches and deliver responsibly for clients. ## Vision Australia’s most trusted choice for offensive security expertise. SilentGrid aims to earn the trust of Australian organisations seeking dependable, highly technical cybersecurity services and relationships that last beyond a single engagement. That requires continual learning and adaptation as threats change, so the work clients receive reflects current security challenges. The longer-term goal is to help businesses build resilient defences and grow with confidence, while setting a standard for technical work and responsible delivery. ## Values - Break boundaries: Curiosity drives the team to investigate further and look for weaknesses that might otherwise go unnoticed. - Enjoy the journey: Working together should be rewarding. Everyone has a voice, and ideas are open for discussion. - Never stop learning: Continual learning helps the team refine its approach and improve the work clients receive. - Empower and support each other: The team’s wellbeing comes first. People need trust and support to do their best work. ## Legal Privacy policy: https://www.silentgrid.com/legal/privacy Terms of use: https://www.silentgrid.com/legal/terms-and-conditions Vulnerability disclosure: https://www.silentgrid.com/legal/vulnerability-disclosure --- Source page: https://www.silentgrid.com/about-us Text file: https://www.silentgrid.com/txt/about.md Generated from the SilentGrid site source on 2026-10-13. Do not edit by hand. ============================================================================== # SilentGrid credentials and delivery experience ## Company accreditation SilentGrid is a CREST ANZ approved company. Legal entity: SilentGrid Security Pty Ltd (ABN 17 637 847 351), Australia. ## Individual credentials Individual credentials across our team include: - OSEE - OSCE3 - OSED - OSEP - OSWE - GXPN - CRTO - CRTE - CRTP - OSCP ## Adversary simulation experience SilentGrid's consultants are hand-picked, and between them they have delivered red team engagements globally over decades, including CBEST for UK financial institutions and CORIE engagements in Australia. Their sector experience covers banking and financial services, insurance, government, critical infrastructure and healthcare. Consultants find 0-day vulnerabilities in commercial software and speak or teach at security conferences. That research produces the custom tooling used to bypass EDR and network controls, and keeps techniques current with the threat actor being simulated. The methodology follows concepts set out in NIST, OWASP, PTES and OSSTMM. ## Penetration testing experience SilentGrid's consultants are hand-picked, and between them they have delivered penetration testing globally over decades. Their sector experience covers banking and financial services, insurance, government, critical infrastructure and healthcare, so findings are assessed in the context of how those systems operate. Consultants find 0-day vulnerabilities in commercial software and speak or teach at security conferences. That research produces the custom tooling used to investigate flaws automated scanning misses and keeps testing techniques current. Testing follows concepts set out in NIST, OWASP, PTES and OSSTMM. ## Standards referenced - Engagement methodology follows concepts set out in NIST, OWASP, PTES and OSSTMM. - Program testing maps to OWASP for web and API, PTES for infrastructure, CIS Benchmarks for cloud configuration, and MITRE ATT&CK for technique mapping. - Automated tooling is used for reconnaissance and coverage validation only. Exploitation, business logic testing and adversary simulation are manual, operator-led work. ## Related Service catalogue: https://www.silentgrid.com/txt/services.md About SilentGrid: https://www.silentgrid.com/txt/about.md Team profiles: https://www.silentgrid.com/our-team --- Source page: https://www.silentgrid.com/services Text file: https://www.silentgrid.com/txt/credentials.md Generated from the SilentGrid site source on 2026-10-13. Do not edit by hand. ============================================================================== # Choosing a SilentGrid engagement Interactive planner: https://www.silentgrid.com/which-security-test The planner asks about the organisation, not about services. Seven ladder steps place it on a maturity level. While findings are not reliably fixed, or no one watches the alerts, it recommends penetration testing first and asks which systems are in use. Once testing, fixing and detection are in place, it recommends adversary simulation and asks which attack worries leadership most and how defenders should take part. Budget is recorded for the scoping conversation and does not change the recommendation. It is indicative guidance, not an audit, certification or maturity score. Answers are processed in the browser and are not sent to SilentGrid. ## Steps 1 to 7: the maturity ladder ### Internet exposure Which sounds most like your internet-facing systems? - 0: We don’t have a clear list of what is exposed to the internet. - 1: We know the main systems, but there could be forgotten ones: old sites, acquisitions, test environments. - 2: We keep an inventory of internet-facing systems and it is mostly current. - 3: The inventory is current and we check regularly for anything new. ### Applications Which sounds most like the applications and APIs you build or run for customers? - 0: They have never been independently security tested. - 1: Some have been tested, usually before a major launch. - 2: Key applications are tested regularly and findings are fixed before release. - 3: Security testing is part of how we ship; every significant release is covered. - Does not apply: We don’t build or run customer-facing applications. ### Internal network Which sounds most like your internal network and identity (staff devices, Active Directory, Entra ID)? - 0: It has never been tested. - 1: It has been tested once or twice; we’re not sure how far an attacker could get. - 2: It is tested regularly, and admin access and segmentation have been tightened. - 3: It is tested regularly, and an attacker working from inside has been simulated. ### Cloud Which sounds most like your cloud platforms (AWS, Azure, Google Cloud)? - 0: No one has looked at our cloud setup from an attacker’s point of view. - 1: Configuration is reviewed, but no one has tested what a compromised identity could reach. - 2: Identities and permissions are tightly managed and have been tested. - 3: They have been tested, and cloud activity feeds our monitoring and response. - Does not apply: We use little or no cloud infrastructure of our own. ### Fixing findings What usually happens to findings from security testing? - 0: Most are still open. - 1: They get fixed eventually, but there is a backlog. - 2: They are fixed within agreed timeframes. - 3: They are fixed and retested, and recurring issues are tracked. - Does not apply: We haven’t had independent testing yet. ### Detection If an attacker got onto a staff laptop tonight, what would happen? - 0: We would probably hear about it from someone else, or not at all. - 1: Monitoring tools would raise alerts, but no one is dedicated to watching them. - 2: A security operations team or managed provider watches alerts around the clock. - 3: Our SOC would catch it, and has caught and contained a simulated attacker before. ### People How would staff handle a convincing phishing email or phone call? - 0: We have never tested it. - 1: Staff get awareness training, but we don’t know how they would respond. - 2: We run phishing simulations and track how many staff report them. - 3: Staff reliably report, and phone and physical approaches have been tested too. ## The questions that follow ### Is anyone requiring this testing? Asked of everyone. - No, it is our own decision - A customer or contract - An audit or certification - A regulator - CORIE, in the financial sector ### How often do your systems change? Asked of everyone. - Every month or faster: Frequent releases, new systems or integrations. - A few significant changes a year: Planned projects and upgrades. - Rarely: The environment is mostly stable. ### Do you also run any of these? Select all that apply. Asked of everyone. - Industrial or operational technology - Connected devices or hardware we make - AI features, chatbots or agents - None of these ### What do your customers and partners use? Select all that apply. Your applications scored low, so these are the ones to test. Asked when applications scored 0 or 1 on the ladder. - Websites or web portals - APIs, used by partners or integrations - Mobile apps - Software installed on their computers ### How do people connect to your systems? Select all that apply. Your internal network scored low, so these shape where testing starts. Asked when the internal network scored 0 or 1 on the ladder. - Offices with a staff network and Active Directory - Wi-Fi at our offices or sites - Virtual desktops, Citrix or kiosks - Remote access over VPN - Mostly cloud and SaaS; little office network ### Which attack worries your leadership most? Asked when the ladder points to adversary simulation (findings fixed within agreed timeframes and alerts watched) and the requirement is not CORIE. "Disruption to industrial systems" is offered only to organisations that run operational technology. - Ransomware that stops the business: Encryption and extortion. - A compromised supplier or software package: An attacker arriving through something we trust. - Someone talking their way past the help desk: Password and MFA resets, impersonating staff. - Disruption to industrial systems: An attacker moving from IT into operations. - A determined attacker reaching critical systems or data: Whatever route they find. - No single scenario: We want to know how our defences hold up overall. ### Where do your most important systems live? Asked when the main worry is a determined attacker, or no single scenario. - In our own network, or split with the cloud - Mostly in the cloud ### How should your defenders take part? Asked when the main worry is a determined attacker, or no single scenario. - Test them without warning: See the response as it would really happen. - Work alongside them: Share activity, then tune and replay detections together. ### Where should the attack begin? Starting from agreed access skips testing the initial compromise. Asked when defenders have caught a simulated attacker, should be tested without warning, and the most important systems are not mostly in the cloud. - Outside, as a real attacker would: Reconnaissance, phishing or exposed services. - From agreed access inside: Focus on what happens after a compromise. ### How would you like to plan testing? Asked of everyone. - One engagement now: The most useful next test. - A plan for the next 12 months: Several engagements in sequence. - Recommend what fits: Based on your answers. ### What budget is available? AUD, excluding GST. It does not change the recommendation; it helps shape the conversation. Asked of everyone. - Under $25,000 - $25,000–under $50,000 - $50,000–under $100,000 - $100,000–under $200,000 - $200,000 or more - Prefer not to say ## Example plans ### No testing yet, customer web and mobile apps, an office network with Wi-Fi Start with a perimeter assessment. Your weakest areas are internet exposure, applications and internal network. The plan starts there, and fixes what it finds before testing whether your defenders would catch an attacker. 1. Perimeter assessment (https://www.silentgrid.com/adversary-simulation/perimeter-assessment): You don’t have a complete picture of what is exposed to the internet. A perimeter assessment finds it, including forgotten assets, and shows how an attacker would get in. 2. Web application and API testing (https://www.silentgrid.com/penetration-testing/web-application-and-services): Your web applications and APIs are not tested regularly, and they are what customers and partners reach. 3. Mobile application testing (https://www.silentgrid.com/penetration-testing/mobile-application): Your customers use mobile apps; testing covers the app on the device, the data it keeps and the APIs behind it. 4. Internal infrastructure testing (https://www.silentgrid.com/penetration-testing/internal-infrastructure): Your internal network has had little testing, so it is unclear how far an attacker who gets in could go. 5. Wireless network testing (https://www.silentgrid.com/penetration-testing/wireless): Your sites run Wi-Fi, and an attacker nearby may be able to join or impersonate it. Then: Assumed breach (https://www.silentgrid.com/adversary-simulation/assumed-breach): Once the findings are fixed, an assumed breach shows whether your defences would catch an attacker who gets in. ### The same organisation, asking for a 12-month plan An annual program mixing penetration testing and adversary simulation. Your weakest areas are internet exposure, applications and internal network. The plan starts there, and fixes what it finds before testing whether your defenders would catch an attacker. 1. Perimeter assessment (https://www.silentgrid.com/adversary-simulation/perimeter-assessment): You don’t have a complete picture of what is exposed to the internet. A perimeter assessment finds it, including forgotten assets, and shows how an attacker would get in. 2. Web application and API testing (https://www.silentgrid.com/penetration-testing/web-application-and-services): Your web applications and APIs are not tested regularly, and they are what customers and partners reach. 3. Mobile application testing (https://www.silentgrid.com/penetration-testing/mobile-application): Your customers use mobile apps; testing covers the app on the device, the data it keeps and the APIs behind it. 4. Internal infrastructure testing (https://www.silentgrid.com/penetration-testing/internal-infrastructure): Your internal network has had little testing, so it is unclear how far an attacker who gets in could go. 5. Wireless network testing (https://www.silentgrid.com/penetration-testing/wireless): Your sites run Wi-Fi, and an attacker nearby may be able to join or impersonate it. 6. Assumed breach (https://www.silentgrid.com/adversary-simulation/assumed-breach): Once the findings are fixed, an assumed breach shows whether your defences would catch an attacker who gets in. - Q1: Perimeter assessment; Web application and API testing - Q2: Mobile application testing; Internal infrastructure testing - Q3: Wireless network testing; Assumed breach - Q4: Retest findings and plan the next year ### Findings fixed and alerts watched; main worry is ransomware Ransomware simulation. Testing and fixing are in place and alerts are watched, but your detection hasn’t faced a simulated attacker. That is the next thing to test. 1. Ransomware simulation (https://www.silentgrid.com/adversary-simulation/ransomware-simulation): Ransomware is your leadership’s main concern. A controlled simulation tests whether it would be stopped, detected and contained before the damage is done. 2. External infrastructure testing (https://www.silentgrid.com/penetration-testing/external-infrastructure): You know what is exposed; testing it shows which of those services an attacker could exploit. Then: Purple teaming (https://www.silentgrid.com/adversary-simulation/purple-teaming): Work through what the exercise missed with your defenders, then tune and replay the techniques. ### Findings fixed and alerts watched; main worry is a compromised supplier or package Supply chain attack assumed breach. Testing and fixing are in place and alerts are watched, but your detection hasn’t faced a simulated attacker. That is the next thing to test. 1. Supply chain attack assumed breach (https://www.silentgrid.com/adversary-simulation/supply-chain-assumed-breach): A compromised supplier or package is the main concern. This exercise starts from a backdoored dependency on a developer’s machine and finds what an attacker could reach. 2. External infrastructure testing (https://www.silentgrid.com/penetration-testing/external-infrastructure): You know what is exposed; testing it shows which of those services an attacker could exploit. Then: Purple teaming (https://www.silentgrid.com/adversary-simulation/purple-teaming): Work through what the exercise missed with your defenders, then tune and replay the techniques. ### Findings fixed and alerts watched; main worry is the help desk being talked past Scattered Spider adversary emulation. Testing and fixing are in place and alerts are watched, but your detection hasn’t faced a simulated attacker. That is the next thing to test. 1. Scattered Spider adversary emulation (https://www.silentgrid.com/adversary-simulation/scattered-spider-emulation): Attackers talking their way past the help desk is the main concern. This runs test cases drawn from Scattered Spider’s published tactics, alongside your defenders. 2. External infrastructure testing (https://www.silentgrid.com/penetration-testing/external-infrastructure): You know what is exposed; testing it shows which of those services an attacker could exploit. Then: Purple teaming (https://www.silentgrid.com/adversary-simulation/purple-teaming): Work through what the exercise missed with your defenders, then tune and replay the techniques. ### Findings fixed and alerts watched; a determined attacker, systems mostly in the cloud Cloud assumed breach. Testing and fixing are in place and alerts are watched, but your detection hasn’t faced a simulated attacker. That is the next thing to test. 1. Cloud assumed breach (https://www.silentgrid.com/adversary-simulation/cloud-assumed-breach): Your most important systems are in the cloud, so the exercise starts from a compromised cloud identity and tests what your cloud controls detect. 2. External infrastructure testing (https://www.silentgrid.com/penetration-testing/external-infrastructure): You know what is exposed; testing it shows which of those services an attacker could exploit. Then: Purple teaming (https://www.silentgrid.com/adversary-simulation/purple-teaming): Work through what the exercise missed with your defenders, then tune and replay the techniques. ### Findings fixed and alerts watched; a determined attacker, working alongside defenders Purple teaming. Testing and fixing are in place and alerts are watched, but your detection hasn’t faced a simulated attacker. That is the next thing to test. 1. Purple teaming (https://www.silentgrid.com/adversary-simulation/purple-teaming): You want to work alongside your defenders: they inspect the attack evidence, tune detections and replay the techniques. 2. External infrastructure testing (https://www.silentgrid.com/penetration-testing/external-infrastructure): You know what is exposed; testing it shows which of those services an attacker could exploit. Then: Assumed breach (https://www.silentgrid.com/adversary-simulation/assumed-breach): Once detections are tuned, test them without warning from an agreed foothold. ### Findings fixed and alerts watched; a determined attacker, defenders tested without warning Assumed breach. Testing and fixing are in place and alerts are watched, but your detection hasn’t faced a simulated attacker. That is the next thing to test. 1. Assumed breach (https://www.silentgrid.com/adversary-simulation/assumed-breach): Alerts are watched but your detection hasn’t faced a simulated attacker. Starting from agreed access tests exactly that, without the cost of a full red team. 2. External infrastructure testing (https://www.silentgrid.com/penetration-testing/external-infrastructure): You know what is exposed; testing it shows which of those services an attacker could exploit. Then: Purple teaming (https://www.silentgrid.com/adversary-simulation/purple-teaming): Work through what the exercise missed with your defenders, then tune and replay the techniques. ### Defenders have caught a simulated attacker; attack from outside without warning Red teaming. Your defenders have caught a simulated attacker before and findings get fixed. The useful test now is one they don’t see coming. 1. Red teaming (https://www.silentgrid.com/adversary-simulation/red-teaming): Your defenders have caught a simulated attacker and findings get fixed, so an objective-led attack from outside, with limited warning, is the useful test. Then: CAOS (https://www.silentgrid.com/continuous-red-teaming): Run red team cycles through the year so each change to your defences is tested again. ### The same organisation, asking for a 12-month plan CAOS: red teaming through the year. Your defenders have caught a simulated attacker before and findings get fixed. The useful test now is one they don’t see coming. 1. Red teaming (https://www.silentgrid.com/adversary-simulation/red-teaming): Your defenders have caught a simulated attacker and findings get fixed, so an objective-led attack from outside, with limited warning, is the useful test. ### A financial institution working towards CORIE A CORIE exercise. CORIE sets the method: an intelligence-led exercise against your critical business functions. Any penetration testing below covers gaps the exercise won’t. 1. CORIE exercise (https://www.silentgrid.com/adversary-simulation/corie): You are working towards CORIE. The exercise is intelligence-led and scoped against the framework. ## Related Service catalogue: https://www.silentgrid.com/txt/services.md Scoping contact: https://www.silentgrid.com/contact --- Source page: https://www.silentgrid.com/which-security-test Text file: https://www.silentgrid.com/txt/choosing-a-test.md Generated from the SilentGrid site source on 2026-10-13. Do not edit by hand.