IT security · IT forensics · Incident response
Were you hacked — or does something just feel wrong?
We help you. With structured IT forensics, incident response and readable documentation we establish what the available evidence actually supports — and which steps make sense now.
Assess first, then act
Whether an acute incident, an unclear anomaly or preparation for the real thing: we start with a clean assessment and do not touch your systems unasked.
Where to start
Which entry point fits your situation?
Acute incident
Your website redirects unexpectedly, a system is unreachable, unknown accounts have appeared, or there are concrete signs of manipulation.
- avoid overwriting relevant traces
- narrow down affected systems and dependencies
- prioritise containment and recovery sensibly
- separate confirmed findings from assumptions
- document the next steps in a traceable way
This selection flags the situation. It does not constitute a promised response time.
Have a suspicion checked
Something feels different, but you do not know whether it is a security problem, a technical fault or a harmless change.
- confirmed: traceable through evidence
- unclear: not conclusively assessable with the available data
- not found: only within the named search scope and with a counter-check
- recommended: prioritised next steps with reasoning
You do not get a dramatic guess, you get a defensible assessment.
Prevention
Nothing has happened, which is exactly why now is the cheapest moment: hardening, preparation and evidence readiness can be built calmly.
- website and server hardening along named assessment frameworks
- security analysis of technical dependencies
- incident readiness with reachable responsibilities
- logging, backup and recovery concepts
- advice on encryption, keys and secrets
Prevention does not rule out incidents. It lowers their likelihood and their cost.
After the first conversation
Assess first, then act
What is actually proven?
We document sources, time reference and scope of review. That keeps it visible what a statement rests on — and where a conclusion is still open.
What has to happen now?
You get prioritised measures instead of an unstructured list of technical findings: limit damage first, then clarify cause and reach, then harden durably.
What can wait?
Not every anomaly is an emergency. We help separate acute risk from technical debt and ordinary improvements.
What stays unclear?
Good forensics names its limits. Missing logs, overwritten data or external platforms can prevent an unambiguous reconstruction. That is recorded transparently.
Services
Six building blocks — separately or building on each other
IT forensics
What happened, and how much of it can be proven?
- chronological reconstruction from available artefacts
- analysis of files, configurations, logs and redirects
- cross-checking domains, services and technical dependencies
- integrity and plausibility checks
- clear labelling of facts, hypotheses and evidence gaps
- a technical findings report for further work
Incident response
How do we contain the incident and move forward in a controlled way?
- a situation picture and an agreed scope
- prioritising containment, preservation and recovery
- coordinating technical measures within the granted approvals
- documentation of the decisions taken
- a follow-up with causes and measures
Security analysis
Where are the traceable risks and dependencies?
- attack surface and publicly visible exposure
- roles, accounts and permissions
- third parties, tracking, consent and external resources
- DNS, TLS, header and redirect configuration
- update, backup and monitoring processes
- prioritised recommendations
Server hardening
How do we reduce avoidable attack surface?
- limiting services and access to what is actually needed
- arranging permissions along the least-privilege principle
- making update and patch paths traceable
- secure TLS, header and secret configuration
- verifying backups and restorability
- aligning logging and alerting with the real need
Incident readiness
Are we prepared if something happens?
- responsibilities and escalation paths
- reachable contact and decision lists
- logging, backup and evidence-preservation requirements
- compact response runbooks
- exercises based on realistic scenarios
- verifiable handover and restart criteria
Cryptography advisory
Where does encryption actually protect, and how are keys managed safely?
- encryption in transit and at rest
- key, certificate and secret lifecycles
- hashes, signatures and integrity proofs
- rotation, revocation and recovery
- choosing established methods over self-invented algorithms
- decision material both engineering and management can follow
Assessment framework
What we assess against: recognised frameworks
An assessment without a named framework is an opinion. We therefore work along publicly documented references and make visible which part of them was actually examined in a given assignment.
OWASP Top 10:2021
Ordering framework for application and configuration risks.
OWASP ASVS
A depth-of-assessment grid when an application is to be reviewed systematically.
OWASP Web Security Testing Guide
Method reference for individual test steps.
CIS Benchmarks
Hardening guides for operating systems and services, or the vendor's own guidance.
BSI IT-Grundschutz
Orientation aid for organisational questions.
These frameworks are publicly available references. Using them is not a certification, not an accreditation and not an audit opinion. We do not act as a certified assessment body and issue no conformity statement.
Typical scenarios, ordered by OWASP Top 10:2021
The following examples describe how these risk classes show up in the daily life of websites, shops and server environments. They are illustrations, not statements about your system.
A01 · Broken access control
A former employee still reaches customer data through an old direct link, or an order or booking view can be opened for someone else's records by changing a number in the URL.
A02 · Cryptographic failures
Backups or exported form data sit unencrypted, an outdated TLS configuration is still active, or credentials are stored with an obsolete hashing method.
A03 · Injection
A contact form, a search field or a filter parameter passes input unchecked to the database, the mailer or system commands.
A04 · Insecure design
A process has no abuse limits: vouchers, appointment slots, registrations or dispatch actions can be triggered automatically at scale.
A05 · Security misconfiguration
A debug or admin interface is publicly reachable, a default account is still active, directories are listable, security headers are missing, or a CORS rule is too permissive.
A06 · Vulnerable and outdated components
A CMS, a plugin, a theme or a JavaScript package sits on a version with a publicly documented vulnerability.
A07 · Identification and authentication failures
The admin login has no second factor, login attempts are not rate limited, or existing sessions stay valid after a password change.
A08 · Software and data integrity failures
An embedded third-party script is altered at its source, or a delivery path accepts artefacts without an integrity check.
A09 · Security logging and monitoring failures
The incident only surfaces weeks later because logs are missing, rotated too early or never reviewed. This is also the most common reason a later reconstruction stays partial.
A10 · Server-side request forgery
A server function fetches addresses that can be chosen from outside, and thereby reaches internal services that should not be publicly reachable.
Hardening checkpoints
For server and website hardening we check verifiable individual points rather than an overall impression. Depending on the environment these include:
- reachable services and open ports against the actual need
- remote access, password login, key management and privilege separation
- patch level and the path by which future security updates will arrive
- TLS version, cipher selection, certificate chain and redirect behaviour
- security headers such as HSTS, Content-Security-Policy, X-Content-Type-Options, Referrer-Policy and Permissions-Policy
- storage and rotation of secrets, tokens and credentials
- backups including a restore test that was actually carried out
- log scope, retention period and alerting aligned with the real need
Process
How the work runs
Narrow down the situation
You briefly describe what was observed, which systems might be affected and whether changes were already made. For the first contact the key facts are enough; sensitive evidence is not sent through a form unasked.
Agree scope and safe method
We clarify access rights, contacts, systems, timeframe, permitted measures and the form of documentation. Active intervention only follows explicit agreement.
Preserve and examine evidence
Depending on the case, existing artefacts are preserved, technical relations reconstructed and findings counter-checked. The examined scope is documented as the denominator.
Prioritise measures
Acute containment, recovery and long-term hardening are assessed separately. Every recommendation carries a traceable reason and a priority.
Hand over results
You receive a readable summary, technical detail, open points and an actionable plan. Where a statement is not possible, that is stated explicitly.
How we work
Trust without decorative seals
Evidence instead of gut feeling
A statement is traced back to its search scope, its source and its time reference. A null finding is not confused with "does not exist".
Facts stay separate from hypotheses
Even the obvious explanation is not sold as fact. That protects decisions and avoids premature blame.
Passive examination first
Where possible we start read-only and non-invasive. Changes to systems require a clear scope and explicit approval.
Data-minimal communication
The first contact asks only for what the assessment needs. Passwords, private keys and complete data sets do not belong in a contact form.
Handover-ready documentation
Results are structured so that internal engineering, hosting, data protection, legal counsel or further specialists can pick them up directly.
What a technical report can contain
- a short version for decision makers
- scope, timeframe and examined systems
- a timeline of relevant observations
- findings with source and evidence class
- technical dependencies and possible chains of effect
- open questions and the limits of the analysis
- prioritised immediate, follow-up and preventive measures
The concrete content depends on the assignment, the data situation and the approval granted. A report does not replace legal advice and promises no court-proof attribution.
Where we are not the right partner
- You expect attribution to a named person as a promised outcome.
- You need a legal assessment, a notification decision or an expert opinion for ongoing proceedings.
- You expect active testing against a production system without an agreed scope and without approval.
- You are looking for a seal or a certification rather than an assessment with a named scope.
- You expect a guarantee that nothing can happen afterwards.
Frequently asked
Questions that come up before the first contact
No. "Something is off" is a sufficient starting point. First we check which observations hold up and which harmless or technical explanations are also in play.
For example an unexpected outage, unknown administrator accounts, manipulated content, malicious redirects or concrete signs of unauthorised access. Whether an attack actually occurred is only claimed after the assessment.
A short description of the observation, the approximate time, the type of system affected and a reachable contact. Credentials and sensitive files are not needed in the contact form.
No. Scope, authorisation and goal are agreed first. Active changes only follow explicit approval, and with care not to alter relevant traces unnecessarily.
Sometimes technical origins or chains of effect can be narrowed down. A reliable attribution to a person or organisation is often not possible and is not promised.
No. Absolute security and success guarantees would be dishonest. The goal is to reduce demonstrable risk, improve decisions and make a repeat less likely.
Yes. Server hardening, security analysis, incident readiness, response runbooks and cryptography advisory all start before an incident.
We use the OWASP Top 10, the ASVS and the Web Security Testing Guide as a publicly documented assessment framework and as a shared language for findings. That is a working basis, not a certification and not a conformity statement.
Not automatically. Much of the work starts read-only and non-invasive. Active testing against a running system requires an agreed scope, explicit approval from the authorised party and an agreed time window. Without that basis, no active testing takes place.
No. A single number hides what was examined and what was not. You get the examined scope as a denominator, the findings with an evidence class and a reasoned prioritisation.
No. We deliver technical findings and support the technical work-up. Legal assessment, notification duties and individual legal questions belong with appropriately qualified parties; the technical documentation can support their work.
That depends on system scope, data situation, access and the question asked. After the first assessment it can be defined which area of review makes sense and which steps depend on each other.
Depending on the assignment a structured overview of findings, a timeline, open points and prioritised measures. Scope and format are set in the scoping step.
You do not need to know what the incident is called.
Briefly describe what you observed. We help you find the right entry point — acute incident, suspicion check or prevention.
Get in touch with your questionsPlease do not send passwords, private keys, backups or complete log files through the contact form. If sensitive material is needed, we agree on a suitable transfer channel first.