Testing

Someone actively trying to get in, on terms you signed.

Scope, windows and the list of things we will not touch are agreed in writing before the first packet. Where the scope includes a control network, anything that can fault a controller waits for a window or goes to the bench. Every finding comes back with the way in and the way to close it.

Why it matters

A scan dump relabelled as a pentest is the thing buyers fear paying for, and it is common. The difference is whether each finding comes with a reproduction, a business consequence and a specific fix, or just a severity colour.

The other fear is the test itself taking down production. So the rules are written first: a stop-work condition, an on-call contact, and passive-first on anything near live control gear.

What it covers

External and internal
External perimeter, internal network and Active Directory: attack paths, lateral movement and privilege escalation, using classes such as Kerberoasting and AD CS misconfiguration as examples, not promises.
Web, API and cloud
Web applications and APIs against OWASP WSTG and ASVS, and cloud tenant configuration where it is in scope.
Remote access and wireless
VPN and remote-access paths, and the remote-access path a vendor opens on a Friday afternoon and forgets. Wireless where it is in scope.
OT-side, carefully
The industrial DMZ, jump hosts, engineering workstations, historians and HMIs. Passive first; anything that touches live control gear either waits for a window or gets tested on a bench.

How it runs

  1. Agree the rules

    Scope, authorisation, test windows, safe-mode and out-of-bounds lists, and a named on-call contact at the site. Signed before anything starts.

  2. Work the paths

    Credentialed or uncredentialed, assumed-breach where it fits, following real attack paths rather than firing a scanner and printing the output. Methodology follows PTES and NIST SP 800-115.

  3. Report as we go

    A daily status note during the test, and immediate notification the moment we confirm a critical finding. You never learn about a serious problem for the first time in the final report.

  4. Score, write, retest

    Findings scored with CVSS v4.0 and the vector string shown, a report the engineer can act on and the budget holder can read, and a retest after you remediate.

A page of what you are handed

ARTA CYBER Representative deliverable — client and site redacted.

A finding page — sample

F-08 — Certificate template lets any domain user authenticate as a domain administrator (AD CS ESC1)

Severity: Critical · CVSS v4.0 9.4 · CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

What we found. The certificate template User-Legacy on the enterprise CA lets the requester supply the subject alternative name, carries the Client Authentication EKU, needs no manager approval, and grants Enroll to Domain Users. Any domain account can request a certificate naming a domain administrator and log on with it as that administrator.

How to reproduce. From a standard domain account created for the test, request a certificate from User-Legacy with the SAN set to a domain administrator’s UPN, then authenticate to a domain controller with it over PKINIT. The request, the issued certificate and the resulting ticket are in the evidence pack, f08-adcs.log.

Consequence. Any phished or guessed staff password becomes control of the domain in one step, and with it every server, mailbox and backup joined to it.

Fix. Remove the enrollee-supplied subject flag from the template, or restrict Enroll to the group that needs it and require CA manager approval. Review the other published templates for the same combination (see F-09). Verify by repeating the same request: it should be refused.

What you are left holding

  • Signed scope and rules of engagement.
  • Daily status note during the test.
  • Immediate notification of critical findings.
  • Report: executive summary, attack narrative, and each finding with evidence, reproduction, business consequence and a specific fix.
  • CVSS v4.0 scores with the vector string.
  • Retest letter after remediation.
  • Raw evidence handed over, and our copies destroyed on a date we agree.

Worked to

  • OWASP WSTG
  • OWASP ASVS
  • PTES
  • NIST SP 800-115
  • CVSS v4.0
OT Asset Simulator

Before a tool goes anywhere near a live PLC, we validate it against our OT Asset Simulator: virtual Modbus TCP and DNP3 targets that behave like the real thing, so we learn how the tool acts without a production line paying for the lesson. BACnet is in development there, and we say so.

OT Asset Simulator

Questions we are asked first

Could a test take down production?

Not the way we run it. Anything that could take a service down, such as a password test that might lock accounts or a load-sensitive application, is agreed in the rules first. Anything that can fault a controller waits for a booked window or gets tested on a bench, and there is a stop-work condition and an on-call contact for the whole engagement.

How is this different from a vulnerability scan?

A scan lists what a tool recognised. A test follows the paths a person would, and each finding arrives with a reproduction, the business consequence and a specific fix, scored with a CVSS v4.0 vector you can check.

What happens if you find something serious mid-test?

You hear about it the moment we confirm it, not at the end. Critical findings are reported immediately, with enough to act on that day.

Who sees the report, and what happens to your evidence?

You decide who receives it. We hand over the raw evidence and destroy our copies on a date we agree in the rules of engagement.

Tell us what is bothering you.

An email is enough to start with. A scoping call is free and there is nothing to commit to, and where we are not the right people we will say so and point you at someone who is.

Book a scoping call

A first call about one site. No charge, and nothing to commit to.

Ask about a Site Assessment

Our named next step: we come to one site and hand you an assessment you can act on.