Hacking, phishing, ransomware: key differences between cyberattacks explained
First came a cyberattack on the Berlin state network, then a data protection incident at LMU Munich, and most recently ransomware at software provider FTAPI: within just a few weeks, several very different cyber incidents have attracted attention. In the case of the State of Berlin, data was copied and later published on the dark web, while LMU reported unauthorized access to its admissions and enrollment system. According to public reports, FTAPI confirmed a ransomware incident on an internally operated server.
Media interest in the incidents was high, even though it was not publicly known exactly what had enabled access in each case. After a security incident, terms such as “hacking attack,” “phishing,” or “ransomware” are quickly lumped together. In reality, however, they describe different things and are not always connected.
The recent cases also highlight a point that often receives too little attention in security communications: even companies and providers that themselves meet high security standards or offer security solutions are not invulnerable as organizations. The attack path, the areas affected, and the question of which controls limit further spread are therefore always important when assessing and classifying an incident.
Hacking and phishing are not the same
In everyday use, hacking and phishing are often used interchangeably. Technically, the distinction is clear: hacking is the broader term for unauthorized access to, manipulation of, or exploitation of IT systems. Phishing, by contrast, describes a specific attack method in which people are deceived into taking a security-critical action.
Hacking: Access may be gained, for example, through a software vulnerability, stolen credentials, a misconfiguration, or malware that has already been introduced.
Phishing: Attackers try to persuade users to take an action – for example, entering credentials, opening a link, or executing a file or command.
Ransomware: This is malware or an extortion method in which systems or data may be encrypted, stolen, and used to demand a ransom. Ransomware therefore does not automatically describe the original access path.
Hacking, phishing, and ransomware can therefore be parts of the same attack. A phishing message may, for example, provide credentials that an attacker then uses to log in to a legitimate system. From there, the attacker may try to gain additional privileges, copy data, or ultimately deploy ransomware. But an attack can just as easily begin without phishing, through a technical vulnerability.
A particularly targeted form of phishing is spear phishing. In our article “Spear phishing: why targeted attacks are becoming more dangerous”, we explain how attackers use names, roles, projects, and real business situations.
The attack path: the hardest piece of the puzzle
In cybersecurity, the original access path is referred to as the “Initial Intrusion Vector” (IIV) or “Initial Access” (IA). This part of an attack chain is often unclear – at least initially. A forensic analysis then has to determine whether a compromised login, an unpatched vulnerability, social engineering, or a misconfiguration enabled the cyberattack. Until then, the question of whether data has been exfiltrated or ransomware executed is usually of greater interest to the public. In such cases, spear phishing or a technical vulnerability can only be discussed as possible scenarios.
A security incident is not proof of a poor security strategy
One question that is often asked after a successful cyberattack is: Who is to blame? It is important to keep in mind that a security incident is always critical – but it is not necessarily evidence of a poor security strategy. Complete security does not exist in complex IT environments, especially as the threat landscape is constantly changing.
That does not mean every incident should be downplayed. What matters is realistically assessing the impact, reviewing the protective measures – and examining how the affected organization or company handles the incident.
Which systems were affected?
How quickly was the incident detected?
Were the attackers able to expand their access?
Were affected parties adequately informed?
Is there follow-up information – publications from data leaks, official statements, or suspicious activity?
Which measures were taken – both beforehand and afterward?
Certifications: important, but limited in what they demonstrate
This is exactly where independent certifications and attestations are often misunderstood. Many companies rely on seals and “audited” logos from IT service providers. These can demonstrate that defined security processes, controls, and management systems have been independently audited, but they are not a guarantee that a company or software cannot be attacked or compromised. Always check the scope of a certificate and what it actually demonstrates.
Read more: ISO certification for cloud providers: how to assess vendor security →
Zero Trust: a valid login is not proof of trust
Stolen or compromised credentials clearly show why traditional – primarily “technical,” perimeter-based – security boundaries are not enough on their own. In many cases, a single account with access to a corporate system is still enough to create serious risks. An attacker does not even need specialized technical hacking expertise to gain access to sensitive information or processes.
This is where the Zero Trust principle comes in: identities, permissions, and access are deliberately verified and limited to what is required. This includes strong authentication, least privilege, granular permissions, and traceable activity.
Learn more: How Zero Trust is shaping modern IT and security architectures →
In practice: combine multiple layers of protection
If hacking and phishing are viewed as possible parts of the same attack chain, a practical conclusion quickly follows: there is no single measure that closes every entry point at once. Security updates help protect against known technical vulnerabilities, but not against a stolen password. MFA or passkeys make identity misuse more difficult, but do not close an unpatched software vulnerability. Awareness reduces the risk of phishing but cannot eliminate human error.
Technical, organizational, and human protective measures must therefore work together. The strongest defense combines multiple measures – and includes the ability to respond if an attack occurs. These include:
Vulnerability management and updates: Close known technical vulnerabilities as quickly as possible.
Strong authentication: Passkeys and two- or multi-factor authentication make it more difficult to misuse compromised passwords.
Least privilege and access control: Accounts receive only the permissions and data access required for their tasks.
Monitoring and activity logs: Unusual logins, downloads, or permission changes can be identified and traced more quickly.
Awareness and incident response: Employees recognize common deception attempts, and the company knows what to do in an emergency.
What this means for sensitive business data
For particularly confidential information, the key question is how far a compromised account can reach. In a data room, users should therefore only see the documents and functions they need for their tasks. Passkeys and 2FA/MFA, SSO, granular permissions, download and print restrictions, and detailed activity logs help keep access under control on the technical side and make unusual activity traceable.
The most important point is less spectacular than many headlines about cyberattacks: security means continuously reducing risks, limiting access, and being prepared for one layer of protection to fail.
Protect sensitive data with multiple layers of security
Would you like to precisely control access to confidential business data and protect it with full traceability? Our experts will be happy to show you which security and permission features in netfiles are suitable for your use case.