GECTIV

What we test

Eight practices, from the application your customers see to the network behind it, the cloud under it, the people around it and the models on top. Each one ends with a report you can hand to the people who fix things. The lists below are a starting point, not a limit: the scope of every engagement is set with you.

Web application testing

Still where most of the ways in are.

Manual testing of the application as a logged-in user, then as a user who should not be able to do what they are doing. Scanners find the known problems; the logic flaws that matter are found by reading the application the way its builders did not.

What we look at

  • Authentication, session and account management
  • Access control across roles, accounts and objects
  • Business logic, workflows and state
  • Injection, deserialisation, file handling
  • Front-end and third-party components

What you receive

  • Proof of exploit wherever it is safe to produce one
  • An executive summary and full technical detail
  • Fix guidance with the specific code path where we can
  • Retest once fixed

Frameworks we map to OWASP Web Security Testing Guide, OWASP ASVS, OWASP Top 10

API testing

Where your services talk to each other, and to strangers.

APIs carry the business logic now, and they are tested less often than the screens in front of them. We test them as a client that cannot be trusted: wrong roles, replayed tokens, objects that belong to someone else, limits that were never enforced.

What we look at

  • Authentication and session handling
  • Authorisation on every object and every verb
  • Rate limits, mass assignment, injection
  • GraphQL introspection, batching, nested queries
  • Internal and partner APIs behind the public one

What you receive

  • Findings with a working request for each
  • Severity by real impact, not by scanner score
  • Fix guidance written for the team that owns the API
  • Retest once fixed

Frameworks we map to OWASP API Security Top 10, OWASP ASVS

Mobile application testing

Both platforms, static and at runtime.

A mobile app is a client that runs on hardware you do not control. We take it apart, watch it while it runs, and test the backend it talks to with the trust that a client should never have.

What we look at

  • Local storage, keychain and keystore use
  • Certificate pinning and transport security
  • Deep links, intents and inter-app communication
  • Reverse engineering and tamper resistance
  • The backend API, tested as a client that cannot be trusted

What you receive

  • Findings for the app and for the backend, separately
  • OWASP MASVS mapping where it helps your compliance
  • Fix guidance for both platforms
  • Retest once fixed

Frameworks we map to OWASP MASVS and MASTG

Network penetration testing

Everything inside the walls, and the walls.

Two questions, one engagement. From the outside: what does an attacker on the internet see, and how far does it get them? From the inside: with a laptop on the network or a standard user account, how long until they control the whole domain? Both are answered by hand.

What we look at

  • External perimeter: exposed services, VPNs, mail, remote access
  • Internal: Active Directory, Kerberos, relays, legacy protocols
  • Segmentation between office, server and production networks
  • Credential hygiene: reuse, defaults, service accounts
  • Escalation to domain administrator and the most sensitive systems

What you receive

  • The attack path from the first point of access to the systems that matter most, drawn out
  • Findings with the exact host, service and request
  • Fixes ordered by how much of the path they cut
  • Retest once fixed

Frameworks we map to PTES, MITRE ATT&CK for the internal path, CIS Benchmarks for the fixes

Cloud penetration testing

Somebody else’s computer, with your keys left in it.

Most cloud breaches are identity breaches. We start from where an attacker starts, a leaked key, a phished user, a storage bucket left public, and follow the permissions to see how far they go.

What we look at

  • Entra ID, IAM roles and the paths between them
  • Over-permissive policies and privilege escalation
  • Exposed storage, functions, queues and databases
  • Build pipelines, secrets and deployment identities
  • Network exposure between environments

What you receive

  • Attack paths drawn end to end, with the permissions that made them possible
  • Fixes ordered by how much of the path they cut
  • Configuration guidance for your platform team
  • Retest once fixed

Frameworks we map to CIS Benchmarks for Azure, AWS and Google Cloud, MITRE ATT&CK Cloud matrix

Red team

The team that attacks.

A red team answers a different question from a penetration test: not what is wrong, but whether anyone would notice. We take an objective, a set of rules and a window, and work towards it the way a real attacker would, quietly, using the tactics, techniques and procedures (TTPs) seen in current intrusions.

What we look at

  • Objectives agreed with a small trusted group
  • Getting in by phishing, through exposed services, or starting from inside as if an attacker already had access
  • Custom tools and attack infrastructure built for the engagement
  • Moving between systems, gaining higher privileges, staying in
  • Detection and response, observed from the attacker’s side

What you receive

  • A timeline of the operation, step by step
  • Every TTP used, mapped to MITRE ATT&CK
  • What was detected, what was not, and why
  • A debrief with your defenders, then a plan

Frameworks we map to MITRE ATT&CK

Purple team

Red plus blue.

A purple team is a red team that works in the open, together with your defenders. We run real attacker TTPs against your environment while your defenders watch their alerts and logs, and we stop after each one to answer the only question that matters: did you see it, and would you have acted?

What we look at

  • Tactics, techniques and procedures (TTPs) chosen from MITRE ATT&CK for the attackers you are most likely to face
  • Getting in, running code, staying in, stealing credentials, moving between systems
  • Detection coverage and alert quality for each TTP
  • Response playbooks, tested against the real thing

What you receive

  • A coverage map: detected, logged, missed
  • Detection improvements agreed with your team during the exercise
  • A prioritised list of what to build next
  • A debrief for leadership and for the security team

Frameworks we map to MITRE ATT&CK, with detections mapped per TTP

AI and LLM testing

A language model given tools, memory, and far too much trust.

Systems built on language models fail differently from web applications. The model is a component that follows instructions from anyone who can get text in front of it, and it is usually wired to tools, documents and other systems. We test the whole chain the way an attacker would use it, with the OWASP Top 10 for LLM Applications and MITRE ATLAS as the map and your architecture as the territory.

What we look at

  • Customer-facing chatbots and internal assistants: what they reveal, and what they can be talked into doing
  • Direct and indirect prompt injection, including through documents, email and web content the model reads
  • Tools, functions and MCP servers: what the model is allowed to call, with whose identity, and what the server checks before it acts
  • Retrieval and memory: tenant separation in the data the model can reach, and what leaks through it
  • Excessive agency: what an agent can do unattended, and what stops it
  • Guardrail and content filter bypass
  • The conventional web and API surface around the model

What you receive

  • Reproducible attack chains, not single prompts
  • Impact assessed on what the system can actually do
  • Mitigations at the architecture level, not only the prompt
  • Optional purple-team format with your AI team

Frameworks we map to OWASP Top 10 for LLM Applications, OWASP Agentic AI threats, MITRE ATLAS, NIST AI RMF

Scope one of these

Not sure which one you need? That is what the first call is for.

Book a scoping call