Curiosity Drives Our Very Fabric
Curiosity Drives Our Very Fabric
Curiosity Drives Our Very Fabric
OPERATOR BRIEFINGS · LAST UPDATED SEPTEMBER 2026
Questions Before We Break In
Most FAQs explain what a pentest is. This page answers the questions people ask before they let someone break their systems on purpose including the ones procurement, QSAs and product teams usually save for the call. Exploit Security is a Sydney consultancy specialising in offensive security, IoT and hardware research, PCI DSS testing, Penetration Testing and embedded red teaming.
Exploit Security is a Sydney CREST-approved offensive-security firm that breaks web, cloud, physical and especially IoT and embedded systems before somebody else does. Directed by Victor Hanna. Testing, PCI DSS Requirement 11.4, research, and an embedded red-team function.
DEF CON 29 · Published CVEs · CREST-approved · Sydney lab · Exploit This CTF · Free OSINT tool
Written by Victor Hanna, Director and Chief Hacking Officer. Last updated September 2026.
What does Exploit Security do?
Answer: Exploit Security is a Sydney offensive-security consultancy that tests organisations the way an attacker would, with a specialty in IoT, embedded systems, hardware, physical security and hybrid AI-human red teaming. The firm also delivers web, infrastructure, wireless, mobile and AI penetration tests, PCI DSS Requirement 11.4 testing, Penetration Testing and an Embedded Exploit Security Team for companies that need an ongoing red-team function without building one internally.
Operator Note: We were set up as a connected group of white-hat researchers, not a scanner farm with a report template. If the engagement does not involve actually trying to break something, it is probably not us.
Where is Exploit Security based?
Answer: Exploit Security is based in Sydney, New South Wales, and works with organisations across Australia and remotely worldwide. Local delivery matters for physical assessments, hardware lab work, and PCI engagements that need testers on the cardholder data environment rather than a remote scan of a public URL
Operator Note: Hardware and physical work is why “Sydney pentest company” is not a marketing line. You cannot firmware-extract a device from a Zoom call as well as you can from a bench.
What is penetration testing, in plain language?
Answer: Penetration testing is an authorised attempt to break into systems the way a real attacker would, then prove what that access is worth. Unlike a vulnerability scan, a pentest exploits weaknesses, chains them, and reports business impact with evidence not a raw list of CVSS scores.
Operator Note: If a vendor will not show a proof-of-concept, they ran a scan and called it a pentest. Ask to see a sample report before you sign.
How is a penetration test different from a vulnerability assessment?
Answer: A vulnerability assessment finds and ranks known weaknesses, usually with scanners. A penetration test exploits those weaknesses to prove what an attacker could actually do. Assessments are broad and repeatable; pentests are deeper, manual, and produce attack paths. Most Australian compliance programs need both, on different cadences.
Operator Note: We will decline an engagement that is clearly a scan sold as a pentest. If you only need a scan, say so it is cheaper and honest.
How much does penetration testing cost in Australia?
Answer: Genuine manual penetration testing in Australia typically starts in the low thousands of dollars for a tightly scoped external or single-application test, and rises into the tens of thousands for multi-system, PCI, red-team or hardware engagements. Price follows scope: number of applications and networks, whether firmware and physical access are in play, evidence depth, and whether retesting is included.
Operator Note: We do not publish a rate card because a payment terminal, a smart-home fleet and a /login page are not the same job. Book a 30-minute scoping call and we will price the work, not a day-rate fantasy.
How long does a penetration test take?
Answer: Most scoped penetration tests take one to four weeks of testing plus reporting, depending on attack surface and whether hardware lab time is required. Scoping and rules of engagement happen first. A single web application can be days; an IoT product with firmware, radio and cloud backend is measured in weeks, not hours.
Operator Note: Anyone promising a “full network pentest by Friday” is scanning. Hardware especially refuses to be rushed — desoldering does not respect a sprint board.
What should be in scope for a first pentest?
Answer: A first penetration test should cover the systems that would actually hurt if they fell: internet-facing applications and infrastructure, identity paths, and any environment that holds customer, payment or operational data. For product companies, add the device, firmware, update channel and companion cloud, not only the marketing website.
Operator Note: Start with what an attacker can already see. Our free OSINT recon tool is a reasonable first look at the public footprint before we write a statement of work.
Do you test production systems?
Answer: Yes. Exploit Security tests production when the client authorises it and the rules of engagement define timing, blast radius and abort conditions. Staging is preferred for destructive or load-heavy tests. Production is required when the risk lives only there session handling, real identity providers, physical controls, and many payment flows.
Operator Note: We will not run unconstrained exploits against a live plant, a hospital, or a payment switch to look clever. Scope is a safety control, not paperwork.
Will a pentest take our systems down?
Answer: A professionally scoped penetration test is designed not to take systems down. Testers use agreed windows, rate limits and kill-switches, and they stop if stability degrades. Some checks denial-of-service, firmware bricking, physical lock bypass are excluded unless you explicitly authorise them.
Operator Note: If uptime is sacred, say so in the rules of engagement. We would rather miss a noisy test than become your incident.
What is IoT and hardware penetration testing?
Answer: IoT and hardware penetration testing examines the device as an attacker would: enclosure, debug interfaces such as UART and JTAG, firmware, bootloader, radio protocols, update paths, companion apps and the cloud behind them. It is a different discipline from web application testing because the bug is often in silicon, solder and a ten-year support life, not only in an HTTP parameter.
Operator Note: This is the centre of the practice. "DEF CON 29 talk “LED Light Lunacy: Hacking Smart Lighting Systems” and CVEs in products such as Shelly and Techview are the public trail.
Why can’t a normal web pentest cover our connected product?
Answer: A web pentest covers the browser-facing application. It will not extract firmware, speak Zigbee or BLE, abuse an insecure update channel, dump secrets from flash, or walk a debug header left on the production board. Connected products fail in those layers more often than they fail in the marketing site.
Operator Note: If your QSA or customer is asking about the device and you hand them an OWASP web report, they will ask again. Correctly.
What does an embedded or IoT engagement usually include?
Answer: A typical Exploit Security IoT engagement includes reconnaissance, hardware inspection, firmware extraction and analysis, protocol and radio review, exploit development where justified, and a remediation roadmap the product team can implement. Findings are written so firmware engineers and compliance leads can both act on them.
Operator Note: We document input models and timing when the finding is subtle. Product teams should be able to reproduce the fix, not just file the PDF.
Do you work on payment-enabled or regulated devices?
Answer: Yes. Exploit Security tests payment-enabled and regulated embedded devices, including mapping findings to PCI DSS controls and assessor evidence. Common blind spots on these products are hardcoded credentials, weak cryptography, unsigned or rollback-able firmware, and debug interfaces left alive in production.
Operator Note: Compliance evidence and exploitability are not opposites. A QSA wants a paper trail. An attacker wants a shell. We write for both.
Does PCI DSS require a penetration test?
Answer: Yes. PCI DSS v4.0.1 Requirement 11.4 requires penetration testing of the cardholder data environment at least annually and after significant change, using a documented methodology. Requirement 11.4.4 requires exploited findings to be corrected and retested. Where segmentation reduces scope, Requirement 11.4.5 requires that segmentation be tested every six months for service providers.
Operator Note: A vulnerability scan is Requirement 11.3. It does not satisfy 11.4. If a vendor sells you an ASV scan as your pentest, your ROC is the next problem.
Can Exploit Security perform PCI DSS penetration testing in Sydney?
Answer: Yes. Exploit Security delivers PCI DSS penetration testing in Sydney against the cardholder data environment and connected systems, including application, network, segmentation and, where relevant, payment-enabled devices. Testing is mapped to Requirement 11.4 so QSAs receive evidence, not a generic pentest PDF with the PCI logo dropped on page one.
Operator Note: Tell us which SAQ or ROC you are on before scoping. SAQ D and service-provider environments are a different job from a tiny e-commerce SAQ A story.
Does a penetration test make us compliant with PCI DSS, ISO 27001 or SOC 2?
Answer: No. A penetration test does not make an organisation compliant by itself. It produces the independent technical evidence those frameworks expect PCI DSS Requirement 11.4, ISO 27001 control testing around vulnerabilities and secure development, and SOC 2 CC7-style detection and protection criteria. Auditors still assess policy, operation and consistency over time.
Operator Note: Treat the report as evidence, not a certificate. We will map findings to the controls you name. We will not sign a letter that says “you are compliant”.
How often should an Australian organisation get a pentest?
Answer: Most Australian organisations should run a manual penetration test at least annually and after significant change new internet-facing apps, major cloud moves, mergers, or payment-flow changes. PCI service providers must retest segmentation every six months. Higher-threat environments, and any organisation covered by APRA CPS 234, should treat “annual” as a floor, not a strategy.
Operator Note: The Embedded Exploit Security Team exists because the calendar is a terrible threat model. Attackers do not wait for your Q4 budget cycle.
What is the Embedded Exploit Security Team?
Answer: The Embedded Exploit Security Team is Exploit Security’s ongoing offensive-security function for organisations that do not have, or cannot yet justify, an internal red team. Named testers embed with your environment and deliver continuous vulnerability discovery, targeted red-team exercises, retesting and strategic guidance across infrastructure, applications, cloud, networks and people.
Operator Note: This is not a retainer that emails you scanner noise once a month. If we are not learning your stack, it is the wrong product.
Who is the Embedded Exploit Security Team for?
Answer: The Embedded Exploit Security Team is for companies that need continuous, context-rich offensive testing but cannot recruit, clear, train and retain a specialist red team. It fits scale-ups, product companies with firmware and cloud in the same blast radius, and security leaders who are tired of buying one annual snapshot and hoping nothing changes.
Operator Note: If you already have a mature internal red team, hire us for a specialist hardware or research surge instead. Do not pay twice for the same function.
How is an embedded team different from an annual pentest?
Answer: An annual pentest is a time-boxed assessment of an agreed scope. An embedded team stays inside the organisation’s context, tests as the environment changes, retests fixes, and builds institutional knowledge. The annual test answers “were we breakable that fortnight”. The embedded team answers “are we still breakable this month”.
What does a penetration test engagement look like?
Answer: An Exploit Security engagement starts with scoping and rules of engagement, then reconnaissance, exploitation, and a report with evidence, impact and remediation. Retesting of fixed findings is agreed up front. Clients get named testers, a single point of contact, and findings as they become actionable rather than a dump on the last day.
Operator Note: We would rather send you a critical on day three than surprise your board on day twenty. Silence during testing is not professionalism.
What does the report include?
Answer: Retesting of remediated findings is part of a complete engagement and should be agreed in the statement of work. PCI DSS Requirement 11.4.4 expects exploited issues to be corrected and retested. An annual test that never checks whether the fix held is a snapshot, not a control.
Operator Note: We will not mark a finding “closed” because a ticket says so. Closed means we could not replay it.
Do you offer physical penetration testing?
Answer: Yes. Exploit Security includes physical security testing among its offensive services, alongside web, infrastructure, wireless, mobile, embedded and AI testing. Physical work is scoped separately because it involves premises access, safety, and often social-engineering rules that do not belong in a remote infrastructure test.
Operator Note: Physical is not a free add-on to a web quote. If you want the front desk and the server room in scope, say so before we price.
Is Exploit Security CREST-approved?
Answer: Yes. Exploit Security presents itself as Sydney’s CREST-approved experts in IoT, hardware and hybrid AI-human red teaming. CREST is the assurance mark Australian enterprise procurement, many insurers, and a growing number of QSAs look for when they need confidence that methodology and people meet a recognised bar.
Operator Note: Ask any CREST provider including us which body, which service line, and who will actually be on the keyboard. The badge on a website is not the tester.
Who leads the work?
Answer: Victor Hanna is Director and Chief Hacking Officer at Exploit Security. He leads the consultancy’s offensive-security and research practice from Sydney and spoke at DEF CON 29 on “LED Light Lunacy: Hacking Smart Lighting Systems”. Published research from the team includes multiple CVEs across IoT, smart-home and enterprise targets.
Operator Note: You are not buying an anonymous bench. If you want the person who found the bug in the smart switch on your engagement, say so at scoping.
What public research and CVEs has Exploit Security published?
Answer: Exploit Security publishes security research and CVE records as part of its practice, including issues such as CVE-2019-12836, CVE-2020-27199, CVE-2021-45901, CVE-2022-29593, CVE-2022-43704, CVE-2023-33383 and CVE-2023-34723. The work spans smart-home hardware, authentication bypasses and enterprise application flaws, and is documented on exploitsecurity.io.
Operator Note: Research is how we stay current. It is also how a buyer can verify we do more than recite OWASP.
What is the Exploit Security OSINT recon tool?
Answer: The Exploit Security OSINT recon tool is a free, ethical, passive utility that gathers public intelligence on a domain DNS, subdomains, TLS certificates, stack hints, public emails, masked leak hits and Shodan exposure. It does not port-scan from your machine or stuff credentials. It is intended for defenders, researchers and authorised consultants.
Operator Note: Unauthorised use against someone else’s estate is on the operator. Curiosity is not consent.
What is Exploit This CTF?
Answer: Exploit This CTF is Exploit Security’s periodically updated capture-the-flag, focused on hardware hacking, embedded systems and IoT rather than generic web puzzles. It exists for people who learn by breaking lab targets, and for teams who want training material that looks like the devices they ship.
Operator Note: f your “security awareness training” is a phishing video and a quiz, this is the other end of the spectrum.
Do you build custom labs or internal CTFs for teams?
Answer: Yes. Exploit Security builds bespoke CTFs and labs including hardware-focused environments such as vulnerable Raspberry Pi ranges so internal teams can practise against realistic embedded and IoT targets. These sit alongside research engagements and the Embedded Exploit Security Team when the goal is capability, not only a report.
Operator Note: A report ages. A team that can reproduce the attack path does not.
