Skip to content
HACKTECH

About Hack Tech

We find the path an attacker would take, then help you close it.

Hack Tech is an offensive security team based in Israel, holding OSCP, CEH and eJPT certifications. We test web applications, APIs, mobile apps, cloud estates and internal networks, audit websites, databases and source code, and help organisations respond when an attacker is already inside. Engagements run remotely worldwide, and on-site work is arranged case by case.

  • OSCP
  • CEH
  • eJPT
  • Based in Israel, working worldwide
  • Report two to three days after testing ends

A test is worth what it changes. Scanners produce lists; attackers produce paths. The job is to find the path, prove it safely and explain it so the fix is obvious. A report full of low-severity noise has failed even if every line in it is true.

We also publish what we know, free and without signing up. The library holds field guides to network protocols, vetted tooling by mission profile, structured learning tracks, a practice lab blueprint, incident response checklists and breach breakdowns mapped to MITRE ATT&CK. Our guides help buyers scope and compare work, the cyber news digest cites at least two sources for every item, and the glossary explains the terms in our reports in plain language.

What you can hold us to

  • Written authorisation, every time

    Nothing is tested without signed permission from someone entitled to give it, naming the targets, the testing windows, the techniques allowed and the people to call. Where that authority is unclear we decline the work, however the request is framed.

  • Every finding reproduced by hand

    Scanners widen coverage, but nothing they raise reaches the report until a person has reproduced it and captured the request, response or screenshot that proves it.

  • Findings shown as attack paths

    We report how weaknesses combine into the route an attacker would take, so you can see which single fix breaks the chain.

  • Critical means now

    If we confirm a critical issue mid-test, your escalation contact hears from us immediately, so the fix can start before the report arrives.

  • Severity you can argue with

    We score with CVSS 4.0, adjust for your business context and show the reasoning in every finding. If the evidence says a score is wrong we change it; we never soften findings to make a report look cleaner, or inflate them to make it look busier.

  • The smallest proof that works

    We prove impact with the least intrusive action that demonstrates it, such as reading one record or writing a harmless marker file, and we leave no foothold on production. Destructive techniques are used only when they are explicitly scoped and scheduled.

  • Written for the person who fixes it

    Findings come with reproduction steps, evidence and a fix specific to your stack, so an engineer who was not in the test can act without a meeting. Links to a standard are not remediation advice.

  • We tell you when a test is the wrong purchase

    We point you to what will help more for where you are, whether that is a threat model, an audit or nothing yet.

How a test runs

Each phase names the public standards it draws on, so you can check our work against something other than our word.

  1. Before testing

    Scoping and threat modelling

    We start from what you are protecting and from whom: the data and functions that would hurt most to lose, the roles and tenants in the system, and the attackers who would plausibly want them. That threat model decides where testing time goes. It is written into a scope with named targets, test accounts for every role, testing windows, traffic identifiers and an escalation path, and anything outside the signed rules of engagement stays out of bounds.

    • PTES
    • NIST SP 800-115

  2. First days

    Reconnaissance

    We map the attack surface the way an outsider would before touching anything sensitive: subdomains and forgotten hosts, exposed services, technology fingerprints, public code and leaked credentials, and every API route the client applications call. Discovery often turns up systems that never made it into an inventory; we raise those with you and never test them unasked. The output is a map of entry points ranked by what they lead to.

    • PTES
    • OWASP Web Security Testing Guide
    • MITRE ATT&CK

  3. Most of the engagement

    Manual testing

    Testers work through each entry point: authentication and sessions, authorisation between roles and tenants, input handling, business rules and integrations, measured against the requirements in OWASP ASVS 5.0 and the test cases in the OWASP Web Security Testing Guide. You receive a short written update at the end of each testing day.

    • OWASP ASVS 5.0
    • OWASP Web Security Testing Guide
    • NIST SP 800-115

  4. When a weakness is confirmed

    Exploitation and chaining

    We prove impact safely, and then ask what the weakness connects to: a leaked token, an over-broad role, a reachable internal service. Chaining is where isolated medium findings become the critical path an attacker would take, and each step is mapped to MITRE ATT&CK.

    • PTES
    • MITRE ATT&CK

  5. Two to three days after testing

    Reporting

    The report is written for two readers at once: an executive summary leadership can act on, and per-finding detail an engineer can reproduce.

    • PTES
    • NIST SP 800-115

  6. Within 30 days of report delivery

    Remediation support and retest

    We walk your engineers through the findings, answer questions in a shared channel while fixes are built and settle any disagreement about severity in front of the evidence. When you tell us what is fixed, we retest each finding against its original reproduction steps, reissue the report with updated status and provide an attestation letter that reports only what we have verified. The retest is included in the engagement.

    • OWASP ASVS 5.0
    • NIST SP 800-115

What the report contains

Terms you meet in it are defined in the glossary.

  1. Executive summary

    Written for leadership and the board: what was tested, what was found, what it means for the business and what to fix first, with no term a non-engineer would need to look up.

  2. Scope and method

    Exactly what was and was not tested, the dates, the accounts and roles used, the approach, the standards followed and the testers' qualifications: the details auditors and customers look for.

  3. Attack narrative

    The most important paths told step by step, from first foothold to impact, and mapped to MITRE ATT&CK so defenders can see where detection could have stopped them.

  4. Findings at a glance

    Every finding in one table with its severity, affected asset and status, which doubles as the prioritised fix backlog your team works from.

  5. Detailed findings

    One entry per issue: description, affected assets, reproduction steps, request and response evidence, a CVSS 4.0 score adjusted for business context, impact in plain terms and a fix specific to your stack.

  6. Remediation plan

    Fixes grouped and ordered by risk and effort, separating quick configuration changes from structural work, so engineering can plan both the next sprint and the next quarter.

  7. Retest status

    After the retest every finding is marked fixed, partly fixed or still open and the report is reissued; the attestation letter carries the same status for customers and auditors, without technical detail.

  8. Evidence and activity log

    Supporting evidence too long for the findings, the tools used, the identifiers our test traffic carried and a timeline of testing activity your team can match against its own logs.

How we handle your data

These commitments cover what we see and collect during an engagement; what this website collects is set out in the privacy policy.

  • Your NDA, signed before the call

    We sign your NDA before the scoping call if you ask, and work under it for the whole engagement. A high-level walkthrough is enough to scope, so credentials, customer data and source code stay with you until the rules of engagement are signed.

  • A secure channel for sensitive details

    Credentials, test accounts and architecture documents travel over a secure channel we set up with you, not through the contact form or ordinary email.

  • Only what proves the point

    We collect the least data needed to demonstrate a finding, and personal data we encounter stays out of the report wherever a reference will do.

  • Encrypted, then destroyed

    Evidence, working notes and reports are encrypted at rest and destroyed when the engagement closes, or on a schedule you set if an audit needs them kept longer.

  • People are not the finding

    Social engineering tests carry no payload and stop at proof of access, and results are reported in aggregate, never by naming individuals.

  • Visible in your logs

    Our test traffic carries an identifier your team can filter on, and the escalation contacts in the rules of engagement can confirm whether any activity is ours before it is dismissed.

See the method on your own systems

A 45-minute scoping call ends with a fixed quote and a proposed start date; the written scope follows by email.

Scope an engagementHow the scoping call works