Hacking

Conceptual boundaries and criminal-law qualification

As a legal concept, hacking intersects with the criterion of “unlawful intrusion” into an automated system. In practice, this requires an analysis that goes beyond merely establishing that access occurred. Attention must be paid to the nature of the system, the method by which access was obtained, and whether there was a passage through a security measure, the breaking of a technical barrier, or the circumvention of an access control. An access control may be visible, such as a login screen with multi-factor authentication, but it may also be less visible, such as an API token policy, network access rules, role-based access control, or a policy that permits certain functions only via managed devices. The legal characterization is also influenced by the degree to which the organization consistently applies and makes such controls apparent, insofar as this relates to foreseeability and delineation of authority, without undermining the fundamental premise that unlawful access is not legitimized by lax administration.

It is further relevant that “intrusion” need not be confined to the initial moment of access. Digital environments operate with layered levels of access, where an initial entry may result only in a limited user session, while subsequent actions are directed at privilege escalation, lateral movement, accessing network shares, or opening administrative consoles. Against that backdrop, an incident may consist of a chain of steps in which new barriers are crossed repeatedly: establishing an initial foothold, dumping or stealing credentials, abusing service accounts, modifying group memberships, adding SSH keys, adjusting conditional access policies, or disabling logging. A legally robust reconstruction therefore does not describe only “the intrusion,” but also the concrete steps through which access was expanded and made persistent, as well as the extent to which those steps demonstrate a deliberate crossing of authorized boundaries.

A complicating factor is that qualification issues often overlap with interpretations of internal authorization regimes. An organization may, for example, have a broad IT role, where administrators are technically capable of seeing and doing a great deal, while policy and job descriptions impose strict limits. In such a setting, the decisive factor is not that technical capability existed, but whether actions were taken outside the granted authority and outside the permitted purpose, and whether security measures were bypassed in doing so. Consent may also be contested based on informal work practices, temporary escalations, or unclear delegations. Legal assessment therefore calls for making the relevant normative frameworks explicit, such as policy documents, mandates, change-management procedures, and access-authorization matrices, and for situating the concrete access act within those frameworks. An overly abstract approach leaves room for doubt; an overly technical approach without legal anchoring lacks persuasive force.

Technical access vectors and modus operandi

The practical manifestations of hacking range from opportunistic attacks to long-term, targeted intrusions. At the lower end of the spectrum are attacks that rely primarily on scale and repetition, such as password spraying, credential stuffing, and exploiting leaked credentials. In those cases, the focus lies on demonstrating abuse of authentication mechanisms: repeated login attempts, unusual user-agent patterns, use of known botnet IPs, or a sudden successful login following a series of failed attempts. At the higher end of the spectrum are intrusions involving zero-days or n-day exploits, exploitation of misconfigurations, or abuse of supply-chain elements. There the evidential focus shifts to exploit traces, anomalies in process creation, memory artifacts, unusual outbound connections, and signs of persistence, such as scheduled tasks, registry run keys, new services, or unauthorized OAuth applications.

In modern environments, the distinction between “external” and “internal” access is increasingly blurred. Cloud identities, single sign-on, federation, and API-driven integrations mean that an attacker with a single identity foothold may traverse a broad landscape without a classic perimeter breach. Abuse of refresh tokens, session hijacking, adding MFA-bypass methods through social engineering, or exploiting consent flows can yield access that appears, at a technical level, to be ordinary user behavior. Conversely, attackers frequently employ living-off-the-land techniques: built-in tools such as PowerShell, WMI, RDP, PsExec, or legitimate remote management agents are used in ways designed to remain inconspicuous. The legal relevance is that the absence of exotic malware does not, in itself, indicate the absence of unlawfulness; unlawfulness may emerge precisely from the context, the purpose, the pattern, and the overstepping of authorization.

A sound modus operandi analysis requires connecting technical findings to plausible attack pathways. A single IP address says little where VPN exit nodes, shared infrastructure, compromised routers, or proxy chains may be involved. A single successful login says little where credential stuffing by third parties, session replay, SIM swapping, or token theft are plausible. It is therefore necessary to combine indicators: timestamps, device fingerprints, geo-location inconsistencies, correlations with email phishing, changes to MFA settings, anomalous consent grants, and the emergence of lateral actions shortly after access. In a legal setting, it is particularly important that alternative scenarios are explicitly weighed and that the reconstruction does not depend on one type of artifact alone. A narrative resting solely on “a login occurred from a particular address” is fragile; a narrative that makes the chain of actions transparent is more resilient.

Authorization, scope, and the boundary of “access with a valid account”

A recurring point of contention concerns situations in which access occurs through a valid account but outside permitted boundaries. It is conceivable that an employee or contractor possesses credentials yet uses them to access data outside assigned duties, to modify systems outside change procedures, or to raise privileges without mandate. In that context, it is essential not to base the scope of authorization solely on technical rights, but also on formal granting decisions, role descriptions, policy, and explicit instructions. “Being able to” access is not the same as “being permitted to” access, particularly where sensitive datasets, production environments, security tooling, or administrative consoles are involved. A legally defensible assessment therefore articulates which boundaries applied, how those boundaries were made apparent, and which actions crossed them.

Internal role divisions may also create false certainty. A function-holder may, in practice, be called upon to resolve incidents while lacking formal authorization to access certain logs or to reset accounts. Conversely, formal authorization may exist, yet usage may plainly deviate from its purpose, for example by copying datasets into private environments, creating hidden accounts, exporting customer data, or systematically monitoring communications. In such situations, assessment of unlawfulness benefits from distinguishing operational necessity from proportional conduct and from documenting the underlying reasons. Actions that fit within an incident-response assignment, supported by ticketing, peer review, and traceable approvals, present differently from actions carried out covertly, selectively, and without formal record. Proof of overreach often lies in the absence of a legitimate business rationale, the circumvention of control mechanisms, and the pattern of conduct.

A particular point of attention concerns misconfigurations and “open doors.” A misconfigured share, a publicly accessible storage bucket, or an API endpoint lacking authentication may make access technically easy. Legally, this does not automatically mean that access was permitted. The discussion often shifts to whether a security measure was broken and how the absence or failure of that measure should be weighed. A careful analysis therefore distinguishes the existence of a vulnerability from the unlawfulness of exploiting it. It is also relevant whether signals of restricted access existed, such as warnings, access prohibitions, segmentation indicators, or the use of credentials not issued for that purpose. The central point remains that access outside authorization, particularly where aimed at obtaining data or privileges, is not normalized by poor administration.

Evidence and forensic interpretation

Evidence in hacking cases often depends on digital traces: authentication logs, remote access data, audit trails, change histories, endpoint telemetry, network flows, and artifacts of tool usage. These traces are rarely unambiguous and may be incomplete due to retention policies, logging gaps, cloud aggregation issues, or incident-response actions that overwrite artifacts. A forensically and legally usable analysis therefore describes not only what is visible, but also what may not be visible, and what uncertainties follow from that. Attention is also required for the integrity of the log chain: time synchronization, source reliability, any log forwarding mechanisms, and whether log records could have been manipulated from the compromised system. Without that context, evidential evaluation is vulnerable, because objections concerning “log tampering” or “missing logs” can easily gain traction.

Interpreting traces also requires distinguishing indicators of access from indicators of post-access activity. A successful login may indicate credential compromise, but it does not automatically identify the actor. A series of commands in a shell history may suggest interactive use, but could also be generated by scripts, remote tooling, or artifacts of administrative processes. Even a discovered malware binary does not automatically show who placed it, precisely when it was executed, or for what purpose. For that reason, chain evidence is often decisive: correlations among device identifiers, browser fingerprints, token issuance events, MFA reset requests, email phishing campaigns, and the occurrence of data access or privilege changes. Where multiple sources converge, evidential weight increases; where sources conflict, an explicit explanation is required.

Hacking cases must also contend with deception and anti-forensics. Attackers may manipulate traces through log cleansing, timestomping, disabling audit logging, or abusing third-party accounts to obscure attribution. Infrastructure may also be “rented” through VPS providers, bulletproof hosting, or stolen payment means, making the path to a natural person indirect. A persuasive legal approach anticipates these possibilities by making hypotheses explicit and testing them: which traces would be expected under a given scenario, which are present, which are missing, and which alternative scenarios remain realistic. Through such testing, the reconstruction becomes more than technical plausibility; it becomes a substantiated evidential reasoning capable of withstanding critical scrutiny.

Perpetration, involvement, and attribution

The question of perpetration concerns linking digital actions to a concrete actor with factual control. In many files, a tension arises between technical attribution and legal attribution. Technical attribution may point to an IP address, a device, an account, or a set of tactics, techniques, and procedures, but legal attribution requires a further step: identification of a person or legal entity and substantiation that this subject performed the actions or caused them to be performed. Shared devices, shared accounts, remote tooling used by multiple individuals, or compromise of an innocent third party’s account can all complicate that link. It is therefore critical not to equate “account use” automatically with “personal conduct,” but to assess what additional indicators exist, such as device binding, possession of MFA factors, correlation with physical presence, communication patterns, payment traces, or administrative activities.

In cases with multiple participants, the distinction between executor, facilitator, and principal becomes relevant. It is conceivable that an individual performs no direct access acts yet provides infrastructure, develops malware, manages phishing kits, or trades credentials. It is equally conceivable that an insider enables access by creating accounts, elevating rights, or manipulating logs, while actual exfiltration is carried out by another party. Legal characterization can then vary depending on intent, close and conscious cooperation, and the materiality of the contribution. Evidential difficulties arise where roles are intertwined and digital actions cannot easily be segmented. A robust analysis therefore describes role division on the basis of objective anchors, such as access entitlements, tooling used, action timelines, and communication or transaction traces, without sliding into speculation.

Finally, it is important to recognize that attribution in a digital context is often indirect and depends on probabilistic indicators. An IP address may be shared; a device may be stolen or compromised; a VPN may be used by multiple individuals; a cloud tenant may be administered by multiple administrators. It is therefore important to work with cumulative indicators and, where reasonably possible, to exclude alternative explanations. A file that relies on a single attribution anchor is fragile. A file that presents a consistent picture over time, in which access, privilege changes, data movements, and external traces such as communications or payments mutually support one another, is stronger. In that way, perpetration is not reduced to a technical fingerprint, but approached as a legal evidential construct that reflects the complexity of digital incidents.

Consequences, ancillary offences, and concurrence

After initial access is obtained, a second phase often follows in which conduct shifts from “getting in” to “making use” of the compromised position. In that phase, the emphasis may lie on data theft, the manipulation or deletion of data, disruption of services, or the preparation of further attacks. In practice, the legal weight of a hacking suspicion is frequently shaped by these subsequent acts, because they may reveal both the purpose and the gravity of the conduct. Data can be exfiltrated through standard protocols and cloud synchronization, but also via less conspicuous routes such as API calls, email forwarding, the creation of shared links, or the misuse of permitted export functionality. This means that the boundary between “normal use” and “abuse” may become visible primarily through volume, dataset selection, timing, and the absence of a legitimate business rationale. A legally defensible characterisation therefore requires a combination of technical findings and contextual information, such as authorisation matrices, process documentation, and explanations of typical workflows.

Concurrence with other offences is more often the rule than the exception. Accessing personal data may trigger suspicions relating to breaches of confidentiality, theft of trade secrets, or identity fraud, while manipulation of systems may coincide with suspicions of damage, sabotage, or obstruction of automated works. Extortion scenarios, such as ransomware or threats of publication, raise their own evidential and qualification issues, including communication channels, negotiation tactics, cryptocurrency wallets, leak sites, and the correlation between encryption events and contact moments. In these matters, it is essential to keep the factual layer sharply defined. Not every disruption amounts to intentional sabotage; not every data copy constitutes unlawful appropriation; not every encryption event amounts to extortion. The value lies in carefully distinguishing what has been factually observed, what is technically plausible, and what can be legally proven, without running ahead of the evidence based on assumptions about motive.

A further complication is that the impact of subsequent offences is often more visible than the initial access, which can cause an investigation to “lean” unintentionally on downstream harm as proof of unlawful access. That risk increases where the initial access vector is uncertain or where logging around the first access moment is limited. A robust approach therefore requires a timeline that carefully substantiates the causal relationship between access and consequences: when the first anomalies arose, which accounts and endpoints were involved, which privileges were changed, and how those events relate to the actual harm. Where such a relationship is assumed, it should be made explicit which alternative explanations remain plausible, such as misconfigurations, internal administrative actions, or pre-existing vulnerabilities that were exploited only later. This produces a file capable of withstanding the criticism that “impact” is being used as a substitute for proof.

Incident response, preservation of evidence, and integrity of traces

In virtually every substantial incident, tension arises between operational necessity and preservation of evidence. Cutting off access, resetting accounts, isolating endpoints, patching vulnerabilities, and restoring backups are measures often required immediately to limit further harm. At the same time, those very measures can affect traces: log files may rotate, volatile memory disappears, endpoints are reimaged, and cloud configurations are changed without the prior state being fully captured. In a criminal-law context, this regularly leads to disputes about the completeness and reliability of traces. A legally defensible approach therefore requires incident actions to be documented as far as possible, including timestamps, responsible individuals, the rationale, and the precise steps taken. That documentation is not merely “administrative”; it is often the key to explaining later why certain logs are missing or why particular artefacts have changed.

Integrity of traces concerns not only retaining data, but also being able to demonstrate that data has not been altered unnoticed. In forensic practice, this entails attention to chain of custody, hashing, write-blocking where relevant, securing log exports together with metadata, and recording the context in which data was acquired. In cloud environments, integrity is more complex: audit logs are often delivered through provider mechanisms, retention depends on licences and policies, and exports can be affected after the fact by configuration changes. It is also common for multiple parties to be involved in response efforts: internal IT, external incident responders, SOC teams, and sometimes insurers. Each of those parties may take actions that affect traces. For that reason, responsibilities and communication lines should be clear, and a central “logbook line” should be maintained in which measures, findings, and changes are recorded in real time.

A further issue concerns how to manage the tension between rapid recovery and forensic depth. Full forensic imaging of all systems is not always feasible or proportionate in practice, particularly in large environments. At the same time, selective preservation can lead to debates about “selection bias”: were the relevant systems preserved, or not? A legally robust approach therefore justifies the scope: which systems were preserved and why, which were not and why, which logs were exported, and what retention and gap risks existed. Where emergency measures were taken, it is important to record which alternatives were considered and why they were not feasible. In that way, a later evidential debate can be conducted on the basis of transparency and traceability rather than conjecture.

Chain evidence, correlation, and scenario analysis

Because individual digital indicators are rarely decisive, the centre of gravity in many hacking matters shifts toward chain evidence. Chain evidence involves linking multiple sources into a coherent picture: access moments, privilege changes, endpoint artefacts, network traffic, cloud audit trails, email traces, and, where available, financial and communicative anchor points. The core is not simply stacking isolated facts, but demonstrating consistency in time and behaviour. For example, a successful login may be followed by an MFA reset, then by additional token issuance, then by unusual data export, and then by outbound connections to specific infrastructure. Each element, viewed alone, may have an alternative explanation; combined, however, a pattern may emerge that is less compatible with coincidence or innocent explanation. From a legal perspective, this strengthens evidential value, provided that the provenance and reliability of each link are separately made transparent.

Scenario analysis is, in this context, often the difference between a persuasive and a vulnerable reconstruction. A reconstruction that presents only one interpretation invites the introduction of alternative scenarios, such as compromise by third parties, misuse of shared accounts, or artefacts produced by legitimate administrative processes. A strong analysis makes those alternatives explicit and tests them against the available material: which traces would be expected, which are present, which are absent, and how plausible the alternative scenario is in light of timelines, access patterns, and technical constraints. It is important that uncertainties are not masked, but structured and articulated. Acknowledging uncertainties can enhance the credibility of the analysis, provided it is clear why, despite those uncertainties, a particular conclusion is best supported by the evidence.

Correlation also carries risks. The co-occurrence of events does not automatically imply causation. A patch window may coincide with an incident moment without the patch being the cause; a VPN login may coincide with data export without the VPN user initiating the export. Correlations should therefore be supported by technical explanations, such as session binding, token linkages, process trees, and network-flow congruence. It is also important to harmonise time sources: logs may be recorded in different time zones, timestamps may drift, and cloud events may be registered with delay. A legally defensible chain approach shows that these pitfalls have been recognised and addressed, so that coherence does not rest on coincidental timing but on demonstrable connectedness.

International dimension, jurisdiction, and cooperation

Many hacking matters have a cross-border character because infrastructure, perpetrators, victims, and data are located in different jurisdictions. Cloud providers host data across multiple regions, attackers use globally distributed VPS infrastructure, and accounts may be abused from abroad. This raises questions about jurisdiction, applicable law, and the practical feasibility of evidence gathering. In practice, it is relevant where the victim is established, where the harm materialised, where servers are located, and where the suspect is presumed to have acted. Those elements may determine the investigative route, the use of international mutual legal assistance, and the ability to compel providers to disclose data. An approach that withstands scrutiny takes account of these dimensions from the outset, because later “surprises” about data location or provider authority can weaken the file.

International cooperation also affects the speed of digital evidence collection. Some logs have short retention periods, some providers release data only through formal procedures, and some data can be secured only through preservation requests. In addition, encryption or end-to-end communication may present practical barriers. This means that early-stage choices—such as preserving tenant logs, exporting audit trails, retaining email headers, and capturing relevant configurations—can be critical, even before international processes are underway. Where those early steps are absent, later evidential loss may occur that cannot be remedied. A legally robust approach therefore records which steps were taken, which requests were made, and which constraints applied, so that it can later be explained why certain data is unavailable.

The international dimension also influences the assessment of attribution. Infrastructure in a particular country says little about the actor’s location; domain registration may be structured through nominees; payment instruments may be stolen; and hosting may be arranged through resellers. Caution is therefore required when drawing conclusions about “where” an attack originated. At the same time, international traces can strengthen chain evidence when multiple independent sources point toward the same actor or group, for example through infrastructure reuse, identical configuration mistakes, repeated wallet addresses, or consistent tactics, techniques, and procedures. The core point is that attribution should not be presented as certainty where it is, in reality, probabilistic, but rather as a substantiated conclusion with explicitly stated assumptions and limitations.

Procedural strategy, positions of stakeholders, and legal characterisation

In the handling of hacking matters, not only the technical factual layer matters, but also procedural strategy concerning legal qualification, evidential valuation, and the positions of stakeholders. Suspects, injured parties, and third parties may have diverging interests: reputational protection, limitation of liability, maintenance of business continuity, and minimisation of disclosure. In that context, technical reports and incident narratives should be read with an eye to their purpose and how they were produced. An incident report written primarily for recovery and risk management often uses different terminology and levels of certainty than a report prepared with evidential objectives. Language used in the heat of an incident may also be categorical (“the attacker did X”), while the underlying finding in fact indicates only plausibility. A legally defensible approach translates such sources into a careful distinction between observation, interpretation, and conclusion, so that evidence does not “ride along” on incident phrasing.

The distinction between factual access and normative blameworthiness is also essential. The presence of a vulnerability or misconfiguration may explain how access was possible, but it does not, without more, establish intent or culpability. Likewise, use of a valid account may point to internal involvement, but may also fit an account-compromise scenario. From a procedural-strategy perspective, it is therefore relevant which elements of intent or knowledge can be substantiated: repeated attempts, measures taken to evade detection, the establishment of persistence, selective data collection, and the use of privileges that clearly fall outside ordinary job performance. Where such elements are absent, the evidential position may be more fragile and the characterisation may lean more heavily on context and scenario analysis. In all cases, legal qualification benefits from precision: terms such as “hacking,” “break-in,” or “breach” should be linked to concrete technical facts and to the relevant normative criteria.

Finally, it is important that a file safeguards proportionality and consistency in interpretation. Overstatement can be counterproductive: if a claim later proves incorrect, it creates room for doubt about the whole. A sound approach therefore opts for a controlled, verifiable presentation: what has been established, by which source, with what reliability, and what conclusions follow. This lays the foundation for a legally persuasive assessment, both during investigation and prosecution and in judicial evaluation. In hacking matters, where technical complexity and evidential uncertainty often go hand in hand, strength lies in analytical discipline: tightly defining the scope, carefully substantiating, and consistently distinguishing between fact and characterisation.