BrickellTechnologies

Service

Penetration Testing

Somebody sits with your systems until they give. Then you get the route in, the evidence, and the specific change that closes it.

What we test

Scope is per-engagement, so nothing below is a package you have to buy whole. Most clients start with one or two of these and add more once they trust the reports.

External network

Everything reachable from the internet with your name on it. That means the hosts you know about and the ones you forgot: the staging box somebody stood up for a demo in 2023, the forgotten subdomain still pointed at a deprovisioned S3 bucket, the VPN appliance two firmware versions behind. We enumerate first, then attack what we find.

Internal network and Active Directory

Assume somebody clicked the link. From a single unprivileged workstation, how far does the blast radius go? Kerberoasting, delegation abuse, certificate template misconfiguration and the shares nobody has audited since the last acquisition tend to add up to Domain Admin faster than anyone expects. We map the path and give you the specific misconfigurations that shorten it.

Web applications

Manual testing against the OWASP Testing Guide, weighted heavily toward access control and business logic because those are the bugs scanners cannot see. Multi-tenant SaaS gets extra attention on the tenant boundary; if two customers can reach each other's data, nothing else on the report matters much.

APIs

REST, GraphQL and gRPC, against the spec if you have one and against the traffic if you do not. Broken object-level authorization is still the most common serious finding in this category, and it is still mostly invisible to automated tooling because the tool has no idea which object belongs to whom.

Mobile applications

Android and iOS, statically and at runtime, with pinning bypassed so we can see what the app actually says to your backend. Half the findings in a typical mobile test are really API findings the app was hiding. Tested by a GMOB-certified tester.

Phishing and social engineering

Pretext development, a landing page that resembles something your staff would plausibly click, and reporting that measures whether people reported it rather than just whether they fell for it. We do not name and shame individuals in the report; that trains people to hide clicks, which is worse than the click.

How we work

Methodology follows PTES and NIST SP 800-115 for structure, the OWASP Testing Guide for web and API work, OWASP MASTG for mobile, and MITRE ATT&CK for describing what we did in terms your detection team can map. That framing exists so the report is auditable and so your blue team can go looking for the telemetry afterwards.

Tools run constantly in the background because coverage matters and machines are better at it. They are not the deliverable. Anything a scanner produced gets verified by hand before it reaches you, and if we cannot reproduce it, it does not go in the report.

Severity, honestly

Ratings are CVSS v3.1 with a written justification, plus a plain-language line on what an attacker gets. Where CVSS disagrees with reality we say so in the finding rather than quietly bumping the number. A medium that chains into full account takeover gets called out as the priority even if the score says otherwise, and a "high" that requires physical access to a locked cabinet gets argued down.

Questions we get asked

Should we do black box or give you credentials?

Give us credentials. Black box is the more dramatic story, but a real attacker has months to find the door you paid us three days to hunt for; you get far more coverage per dollar by starting us where a phished employee would already be. We usually do a short unauthenticated pass first for the perimeter view, then switch to credentialed testing for the bulk of the work.

Production or staging?

Production, if you can stomach it, because staging is never quite the same and the differences are exactly where bugs hide. Where that is genuinely too risky we test a staging environment that mirrors production config, and then re-verify the handful of findings that depend on real data against production under supervision.

Should our security team know the test is happening?

Depends what you are buying. If you want coverage, tell them, because a blocked tester is a wasted week. If you want to know whether your detection works, keep it to two or three people and we will run it quieter, log our activity, and compare notes with your SOC afterwards. That second version costs more time and finds fewer bugs; both are legitimate, just pick on purpose.

How far do you take exploitation?

Far enough to prove impact, and then we stop and tell you. We take a screenshot of the data rather than exfiltrating it, we create a marked test account rather than modifying a real one, and anything that risks availability or integrity gets a phone call before we touch it. Those limits go in the rules of engagement, in writing, before the test starts.

What if you find something critical on day one?

You get a call that day, with enough detail to start fixing before the report exists. We have had clients patch a finding before the engagement ended, which is the point. It still goes in the report, marked as remediated during testing.

Is the retest extra?

No, for 90 days after the report. Fix things, tell us, we verify and reissue the report with those findings closed. Past 90 days it becomes a small separate engagement, mostly because by then the application has moved on.

Know what an attacker would reach first.

Tell us what you run and what worries you. We will come back with a scope, a fixed price and the earliest week we can start.